Tema16.3 Madeja

Published on Marco de Desarrollo de la Junta de Andalucía (http://madeja.i-administracion.
junta-
andalucia.es/servicios/madeja)
Definición
MADEJA es el Marco de Desarrollo de la Junta de Andalucía. Su misión es proporcionar un entorno que permita a todos los
implicados en el desarrollo y en la explotación del software tener una referencia clara de cuáles son las directrices que han de
guiar esta actividad, así como dar a conocer los recursos y herramientas que están a su disposición.
MADEJA aplica sobre los productos de software de la Junta de Andalucía, pero no se limita a intervenir en el proceso de
desarrollo. Su objetivo es estar presente desde que surge la necesidad de poner en marcha un Sistema de Información hasta
que este se encuentra en explotación, incluyendo la fase de mantenimiento. Aportará indicadores que permitirán realizar mejoras
en la distintas fases del ciclo de vida de un Sistema de Información.
A la hora de plantear MADEJA y durante su proceso de construcción, se han seguido y se seguirán los siguientes principios
básicos:
Lo s co ntenido s tendrán un carácter práctico . Por ello, en MADEJA podemos encontrar guías de uso y manuales acerca
de las tecnologías recomendadas, definiciones de normativas y procedimientos de aplicación interna o exigibles a los que
desarrollen para la Junta de Andalucía. Además, se propondrá el uso de herramientas, preferentemente de software libre,
existentes o desarrolladas a medida para cubrir en la medida de lo posible las necesidades de todos.
Las directrices indicadas en MADEJA seguirán la siguiente clasificación:
Directrices con carácter de recomendación. En este apartado trataremos aquellos aspectos que pueden ser de referencia
cuando no existan restricciones o incompatibilidades con lo existente.
Directrices obligatorias. Serán de obligado cumplimiento en todos los desarrollos de los Sistemas de Información.
Tiene un planteamiento independiente y abierto MADEJA. Su primera versión es fundamentalmente fruto de la
dedicación de recursos internos y de la aportación de información de todas las Consejerías y Organismos, además de la
aportación de expertos independientes. Posteriormente se han ido incorporando contenidos fruto de la aportación de empresas
especializadas sobre áreas concretas.
Hay que destacar que MADEJA no tiene intención de ser un flujo unidireccional de directrices y normas. Al contrario, y como se
informa en otras secciones de este portal como la guía de uso, se ha planteado como un producto que necesita ser
realimentado por los distintos actores implicados para que su validez y cobertura sea la óptima, ajustándose a las necesidades
reales de los desarrollos de la Junta de Andalucía. Además, se proporcionará un soporte en la medida en que sea necesario y
cuya cobertura se irá ajustando en función de la demanda y las necesidades concretas de todos.
Por último, es necesario aclarar que MADEJA no está ligado a un único entorno tecnológico, pudiéndose encontrar tanto pautas de
carácter general, independientes de la tecnología, junto a otras ligadas a ésta. Aunque inicialmente MADEJA se centra en el
desarrollo de aplicaciones Java EE, progresivamente se irán incorporando otras tecnologías que sean de aplicación, en función
del contexto y la finalidad del producto a desarrollar.
Source URL: http://madeja.i-administracion.junta-andalucia.es/servicios/madeja/contenido/definicion
1
Published on Marco de Desarrollo de la Junta de Andalucía (http://madeja.i-administracion.junta-
Objetivos
Los objetivos principales MADEJA son:
Ho mo geneizar y no rmalizar lo s desarro llo s de so ftware en la Junta de Andalucía, incluyendo tanto al producto en sí
como al proceso de producción. Para lograrlo se reducirán las alternativas tecnológicas mediante la propuesta de opciones
verificadas y de amplia aceptación en el mundo del desarrollo y se propondrán procedimientos y herramientas que den soporte
al desarrollo, entre otras medidas.
Mejo rar la calidad y facilitar el mantenimiento de lo s Sistemas de Info rmació n. Para ello se ha definido un
modelo certificación de software, basado en verificaciones, niveles de certificación y servicios de testing, como se describe en
el subsistema de Verificación.
Aunar esfuerzo s, permitiendo la co labo ració n entre to do s lo s acto res implicado s. Con ese fin se irán poniendo
en marcha las herramientas y procedimientos que hagan posible que todos los implicados puedan aportar al marco de
desarrollo. Además se potenciará la reutilización de código con el fin de simplificar futuros desarrollos y se definirán normas de
buen uso para el empleo de componentes o herramientas horizontales.
Ser una referencia en las distintas áreas, tanto tecnológicas como metodológicas o de otra índole. Se persigue reducir
el esfuerzo necesario para que cada Consejería u Organismo se mantenga al día. Esto se consigue gracias al esfuerzo destinado
al mantenimiento, la incorporación de nuevas tendencias y la integración de las aportaciones de los agentes involucrados.
Seleccio nar, desarro llar e implantar las herramientas que dan so po rte al desarro llo del So ftware y a la
verificació n del mismo . Gracias a los mecanismos de atención al usuario de MADEJA se permitirá la recolección y
catalogación de nuevas necesidades que permitirán iniciar una búsqueda activa de soluciones existentes, preferentemente de
software libre, o la definición de nuevos proyectos que, bajo la cobertura de MADEJA, puedan lanzarse en paralelo e integrarse en
el marco de desarrollo.
Como puede observarse, son constantes las referencias a la colaboración y la aportación de todos los agentes implicados.
Existe una descripción de los mecanismos que permitirán dicha colaboración en el apartado Guía de Uso. Estos mecanismos,
como el resto de MADEJA, están sometidos a la mejora continua que nos proporcione la experiencia de su uso.
Los objetivos principales de MADEJA de cara a las empresas desarrolladoras son los siguientes:
Servirá como punto de referencia sobre las tecnologías por las que va a apostar la Junta de Andalucía.
Será un mecanismo que favorecerá la reutilización a nivel de componentes
Aportará los mecanismos necesarios que permitan medir objetivamente el nivel de excelencia de los desarrollos de la Junta
de Andalucía
Aportará información interna útil para que la integración de los desarrollos sea lo más fácil posible
Establecerá procedimientos homogéneos de funcionamiento e interacción con los distintos Organismos de la Junta de
Andalucía.
En un futuro, establecerá un marco de homologación de las empresas y los técnicos que participan en los desarrollos.
Source URL: http://madeja.i-administracion.junta-andalucia.es/servicios/madeja/contenido/objetivos
1
Subsistemas
Este epígrafe cubre los distintos subsistemas en los que está estructurado MADEJA, definiendo cada uno de ellos y dando
acceso a su contenido.
La visión por subsistemas permite un acceso estructurado por áreas de conocimiento a los contenidos de MADEJA.
A continuación se muestra un gráfico visual de los subsistemas que forman MADEJA:
Source URL: http://madeja.i-administracion.junta-andalucia.es/servicios/madeja/contenido/subsistemas
1
Arquitectura
El subsistema de arquitectura recoge la propuesta de mo delo de arquitectura so ftware a utilizar en las aplicaciones,
inicialmente en JEE; además se documentan las distintas tecnologías disponibles para facilitar el desarrollo de aplicaciones. Se
incluye también un área sobre la arquitectura de sistemas de información de la Junta de Andalucía, estableciendo las
recomendaciones de uso de los sistemas de información horizontales, las herramientas horizontales y las infraestructuras
software. Por último, el subsistema contempla directrices y recomendaciones sobre integración de sistemas de información,
utilizando los conceptos de arquitectura basada en servicios apoyándose en el bus de interoperabilidad de la Junta de Andalucía.
En cuanto a las tecnologías disponibles, MADEJA propondrá una selección de las mismas que serán las recomendadas, aunque
también se documentarán otras que, no siendo las recomendadas, son utilizadas en proyectos preexistentes y sobre las cuales
habrá que establecer unas condiciones de uso.
Objetivos
Homogeneizar la arquitectura de aplicaciones.
Uso y reutilización de los sistemas de información de la Junta de Andalucía.
Proporcionar un modelo de interoperabilidad de las aplicaciones y los sistemas de información.
Documentar y seleccionar las distintas tecnologías que dan soporte a la arquitectura propuesta.
Arquitectura de Sistemas de Información

Có digo : ASI
Esta área presenta la Arquitectura de Sistemas de Información existente en la Junta de Andalucía para el desarrollo de
aplicaciones. Dan forma a esta arquitectura los Sistemas de Información Horizontal, Herramientas Software e Infraestructura
Software. Cada nuevo sistema de información a desarrollar se apoyará en esta área para identificar sus interrelaciones con otros
sistemas y las pautas que rigen tales relaciones.
Definiciones de tipos de sistemas de información en la Junta de Andalucía:
"Sistema de Información Sectorial", como el software destinado a la gestión de la información de uno o varios
procedimientos administrativos que afectan al ámbito de una única Consejería.
"Sistema de Información Horizontal", como el software destinado a la gestión de la información de uno o varios
pro cedimiento s administrativo s que afectan al ámbito de varías Co nsejerías, incluso cuando la competencia
en la gestión y definición de los procedimientos afectados recaiga en una sola Consejería.
"Herramientas Software", como el software que cubre una determinada funcionalidad que no se corresponde con ningún
procedimiento administrativo.
"Infraestructuras Software", como el software que cubre una determinada funcionalidad y está destinado a ser utilizado como
so ftware de base para el desarrollo de los Sistemas de Información Sectoriales y Horizontales de la Junta de Andalucía.
GUIA: Gestión Unificada de Identidades de Andalucía

Có digo : AREA_GUIA
GUIA es una solución global de seguridad, que permite la gestión unificada de las identidades digitales de los usuarios de los
sistemas de información de la Junta de Andalucía, y trata de una forma directa la autenticación e identificación de las
identidades, proporcionando garantías de privacidad y seguridad sobre las aplicaciones y sistemas.
El contenido de este área ofrece pautas y recursos para la integración de aplicaciones con GUIA. Estas pautas son de
aplicación para nuevos desarrollos y aplicaciones están sujetas a mantenimiento. Como primera toma de contacto y para
hacerse una composición de lugar acerca de la información gestionada y ofrecida por GUIA a las aplicaciones que se integren,
se recomienda consultar los primeros recursos que se muestran más abajo en la tabla del mismo nombre.
En el apartado de "Ayuda y Soporte > Glosario" se puede consultar el "Glo sario del Pro yecto GUIA"
Para resolver cualquier duda que pueda surgir en relación a esta información, visite siguiente enlace: Gestión del servicio - GUIA
Pautas
Có digo Título Tipo Carácter
PAUT-0116 Integración de Aplicaciones en GUIA Directriz Obligatoria
LIBP-0202 Integración en Autenticación Directriz Recomendada
LIBP-0203 Integración en Autorización Directriz Recomendada
1
LIBP-0204 Integración en Uso del directorio Directriz Recomendada
LIBP-0205 Integración en Aprovisionamiento Directriz Recomendada
LIBP-0206 Integración Durante la Fase de Transición Directriz Recomendada
Gestión de la información de usuarios en
LIBP-0207 Directriz Obligatoria
aplicaciones integradas
Integración de aplicaciones con el Single
Sign-On de Escritorio
Matriz de compatibilidad de versiones de
PAUT-0187 Directriz Obligatoria
SSO Windows
Procedimientos
Có digo Título Carácter
PROC-0024 Procedimiento de Integración de Aplicaciones Existentes Recomendado
Recursos
RECU-0425 Gestión del servicio - GUIA Referencia Recomendado
RECU-0426 Información gestionada Referencia Recomendado
RECU-0427 Acceso a la información Referencia Recomendado
RECU-0428 Modelos de Integración Referencia Recomendado
RECU-0429 Entornos de trabajo disponibles Referencia Recomendado
RECU-0430 Arquitectura GUIA Referencia Recomendado
RECU-0431 Selección del tipo de integración Referencia Recomendado
RECU-0432 Cuenta de servicio Referencia Recomendado
Obtención e instalación de certificados en clientes
RECU-0433 Referencia Recomendado
J2EE
Clasificación de atributos de OID y estructura del
Directorio.
RECU-0435 Autenticación LDAP en el Directorio de GUIA Referencia Recomendado
RECU-0437 Autenticación LDAP con Spring Security Manual Recomendado
Configuración en Spring Security para autenticación
LDAP en GUIA
RECU-0439 API del Servicio Web del Directorio API Recomendado
RECU-0440 API del Servicio Web de Roles API Recomendado
API del servicio web para integración en
RECU-0441 API Recomendado
aprovisionamiento
Solución para la integración de aplicaciones a través
RECU-0442 Manual Recomendado
de OVD
RECU-0495 Librería JAVA para la Integración de Aplicaciones Técnica Recomendado
Uso librería de integración java: Servicio web de
RECU-0496 Ejemplo Recomendado
Directorio
Uso librería de integración java: Servicio web de
Roles
RECU-0507 Uso librería de integración java: Autenticación Ejemplo Recomendado
Uso librería de integración java: Autenticación y filtro
J2EE
Seguridad
SIGC: Sistema de Información Geográfica Corporativo

Có digo : ARQ_SIGC
El Sistema de Información Geográfica o SIG Corporativo de la Junta de Andalucía es un proyecto de carácter horizontal cuyo
objetivo es facilitar los mecanismos de acceso a sistemas, aplicaciones, herramientas, datos y servicios espaciales existentes
en la Junta de Andalucía. Así mismo, es objeto del SIGC asegurar la independencia tecnológica, aportando soluciones basadas
en el uso de estándares que favorezcan la integración de sistemas.
En el apartado de "Ayuda y Soporte > Glosario" se puede consultar el "Glo sario del SIG Co rpo rativo "
Pautas
PAUT-0004 Aplicación de Normativa Legal Directriz Obligatoria
2
PAUT-0005 Aplicación de Normativa Técnica Directriz Recomendada
PAUT-0006 Uso de Herramientas SIG en Software Libre Directriz Recomendada
PAUT-0007 Elaboración de Metadatos Directriz Recomendada
PAUT-0008 Uso del Sistema Geodésico ETRS89 Directriz Obligatoria
PAUT-0009 Uso del Servicio Mashup del SIG Corporativo Consejo
Uso de Calar como Herramienta de
PAUT-0010 Consejo
Transformación Geodésica
Uso del Servicio de Geodesia del SIG
PAUT-0011 Consejo
Corporativo
Uso de los Servicios de Callejero del SIG
PAUT-0012 Consejo
Corporativo
PAUT-0013 Uso de los Servicios de la IDEAndalucía Consejo
Uso del Servicio de Descargas del SIG
PAUT-0014 Consejo
Corporativo
Recursos
RECU-0004 Geonetwork Herramienta Recomendado
RECU-0005 Mapserver y Geoserver Herramienta Recomendado
RECU-0006 Deegree Herramienta Recomendado
RECU-0007 Enebro Herramienta Recomendado
RECU-0008 gvSig Herramienta Recomendado
RECU-0009 Open Layers Herramienta Recomendado
RECU-0010 MapFish Herramienta Recomendado
RECU-0011 Oracle Spatial Herramienta Recomendado
RECU-0012 Postgis Herramienta Recomendado
RECU-0013 Calar Herramienta Recomendado
RECU-0014 Mashup Herramienta Recomendado
RECU-0015 Manual de usuario de Calar Manual Recomendado
RECU-0016 Manual de Usuario del Callejero Manual Recomendado
RECU-0017 ISO 19119. Servicios Espaciales Especificación Recomendado
RECU-0018 ISO 19115 Metadatos Especificación Recomendado
RECU-0019 Estándares del Open Geospatial Consortium (OGC) Especificación Recomendado
ISO 19139 Metadatos. Especificación de
RECU-0024 Especificación Recomendado
Implementación
Directiva 2007/2/CE para la Infraestructura de
RECU-0020 Información Espacial en la Comunidad Europea Legislación Recomendado
INSPIRE
Real Decreto 1071/2007 de 27 de Julio por el que se
RECU-0021 Regula el Sistema Geodésico de Referencia Oficial Legislación Recomendado
en España
RD 141/2006 por el que se Regula la Actividad
RECU-0022 Legislación Recomendado
Cartográfica de Andalucía
RECU-0023 Plan Cartográfico de Andalucía Legislación Recomendado
Ejemplo de Petición del Servicio de Cartografía
Urbana del Callejero Digital de Andalucía
Ejemplo de Petición del Servicio de Cartografía
Urbana desde gvSIG
Ejemplo de Petición de Servicio de Cartografía
Urbana desde ArcGIS
Ejemplo de como Cargar Información Geográfica en
Postgis y Oracle
Consejos para la Instalación y Configuración de
Geonetwork
RECU-0030 Ejemplo de llamada al Servicio de Mashup Ejemplo Recomendado
RECU-0031 Web Mapping Service (WMS) Especificación Recomendado
RECU-0032 Web Feature Service (WFS) Especificación Recomendado
RECU-0033 Web Coverage Service (WCS) Especificación Recomendado
RECU-0034 Catalog Service for the Web (CSW) Especificación Recomendado
3
RECU-0035 Gazetteer (WFS-G) Especificación Recomendado
RECU-0036 Web Processing Service (WPS) Especificación Recomendado
RECU-0037 Keyhole Markup Language (KML) Especificación Recomendado
RECU-0423 Servicio de Cartografía Urbana Herramienta Recomendado
Cliente de Referencia del Callejero Digital de
RECU-0424 Herramienta Recomendado
Andalucía
La Infraestructura de Datos Espaciales de España
RECU-0011 Ficha Recomendado
(IDEE)
sig
Alfresco
Có digo : ARQ_ALFRESCO
El contenido de este área ofrece las pautas para el desarrollo de aplicaciones que usen el gestor documental Alfresco.
Pautas
PAUT-0023 Opciones de desarrollo con Alfresco Consejo
Uso de Alfresco desde Terceras Aplicaciones

Có digo : ASIALF_UATA
El gestor de contenidos Alfresco contempla un conjunto de casos de uso de negocio, que soporta a través de servicios
web de acceso al repositorio remoto para aplicaciones y procesos de negocio.
Pautas
PAUT-0029 Configuración de acceso al Repositorio Directriz Obligatoria
Construccion de una capa de acceso
PAUT-0024 Directriz Recomendada
personalizada
PAUT-0025 Limitación de registros devueltos Directriz Recomendada
Recurso s
RECU-0041 Ejemplos de uso de servicos web Ejemplo Recomendado
RECU-0040 Servicios Web de Alfresco Manual Recomendado
RECU-0004 Servicios Web en Alfresco Ficha Recomendado
RECU-0043 Tipos de datos para los servicios web Manual Recomendado
RECU-0045 Uso de Web Scripts Manual Recomendado
RECU-0046 Ejemplos de Web Scripts Ejemplo Recomendado
RECU-0005 Web Scripts Ficha Recomendado
RECU-0047 API de JavaScripts Manual Recomendado
RECU-0048 Scripts de Ejemplo Ejemplo Recomendado
RECU-0006 API JavaScript Ficha Recomendado
Ejemplos Ampliados de Acceso a Alfresco

Có digo : EjemplosAlfresco
Se han recopilado ejemplos de acceso al repositorio de Alfresco para facilitar el desarrollo de aplicaciones donde se
requiera este tipo de vínculo con el gestor de contenidos. Los ejemplos se han estructurado por lenguajes,
funcionalidades y uso avanzado.
Estructuras por Lenguajes

Interfaces
Consulta de Documentos
Gestión de Documentos
Consulta de Espacios
Gestión de Espacios
Java API
Búsquedas
Gestión Integrada de Usuarios
4
Categorías y Aspectos
Reglas y Procedimientos
Java JCR API
Búsquedas
Java Script
Búsquedas
Web Script
Búsquedas
Estructura por Funcionalidades

Uso Básico
Tabla de Funcio nalidades
Java API
Java JCR API
Consulta
JavaScript
WebScript
Documentos
Java API
Java JCR API
Gestión
JavaScript
WebScript
Java API
Java JCR API
Consulta
JavaScript
WebScript
Espacios
Java API
Java JRC API
Gestión
JavaScript
WebScript
Uso Avanzado
Tabla de funcio nalidades
Java API
Java JCR API
Búsquedas
JavaScript
WebScript
Java API
Java JCR API
5
Java JCR API
JavaScript
WebScript
Java API
Java JCR API
JavaScript
WebScript
Java API
Java JCR API
Reglas y procedimientos
JavaScript
WebScript
Recurso s
RECU-0056 Consulta de Documentos con Java API Ejemplo Recomendado
RECU-0062 Gestion de los documentos con Java API Ejemplo Recomendado
RECU-0057 Consulta de Espacios con Java API Ejemplo Recomendado
RECU-0058 Gestión de Espacios con Java API Ejemplo Recomendado
RECU-0059 Búsquedas con Java API Ejemplo Recomendado
RECU-0060 Gestión de Usuarios con Java API Ejemplo Recomendado
RECU-0061 Categorías y Aspectos con Java API Ejemplo Recomendado
RECU-0063 Reglas y Procedimientos con Java API Ejemplo Recomendado
RECU-0064 Consulta de Documentos con Java JCR API Ejemplo Recomendado
RECU-0065 Gestión de Documentos con Java JCR API Ejemplo Recomendado
RECU-0066 Consulta de Espacios con Java JCR API Ejemplo Recomendado
RECU-0067 Gestión de Espacios con Java JCR API Ejemplo Recomendado
RECU-0068 Búsquedas con Java JCR API Ejemplo Recomendado
RECU-0069 Consulta de Documentos con JavaScript Ejemplo Recomendado
RECU-0070 Gestión de Documentos con JavaScript Ejemplo Recomendado
RECU-0071 Consulta de Espacios con JavaScript Ejemplo Recomendado
RECU-0072 Gestión de Espacios con JavaScript Ejemplo Recomendado
RECU-0073 Búsquedas con JavaScript Ejemplo Recomendado
RECU-0074 Gestion de Usuarios con JavaScript Ejemplo Recomendado
RECU-0075 Categorías y Aspectos con JavaScript Ejemplo Recomendado
RECU-0076 Reglas y Procedimientos con JavaScript Ejemplo Recomendado
RECU-0077 Consulta de Documentos con WebScript Ejemplo Recomendado
RECU-0078 Gestión de Documentos con WebScript Ejemplo Recomendado
RECU-0079 Consulta de Espacios con WebScript Ejemplo Recomendado
RECU-0080 Gestión de Espacios con WebScript Ejemplo Recomendado
RECU-0081 Búsquedas con WebScript Ejemplo Recomendado
RECU-0082 Gestion de Usuarios con WebScript Ejemplo Recomendado
RECU-0083 Categorías y Aspectos con WebScript Ejemplo Recomendado
RECU-0084 Reglas y Procedimientos con WebScript Ejemplo Recomendado
Extensión de Alfresco
Có digo : ASIALF_EA
El gestor de contenidos Alfresco ofrece la posibilidad de ampliar sus funcionalidades y características básicas mediante
extensiones de su modelo de contenidos y de sus servicios. Se han establecido directrices respecto a estas extensiones
y a su despliegue.
Pautas
PAUT-0026 Extension de clases base Directriz Obligatoria
Metodo de despliegue de extensiones
en Alfresco
LIBP-0002 Desarrollo del modelo de contenidos Directriz Obligatoria
6
Recurso s
Métodos para el despliegue de extensiones de
Alfresco
RECU-0050 Extensiones en el modelo de contenidos Manual Recomendado
RECU-0051 Creación de acciones personalizadas Manual Recomendado
RECU-0052 Comportamientos Manual Recomendado
RECU-0053 Desarrollo de extracción de datos Manual Recomendado
RECU-0054 Workflows Manual Recomendado
RECU-0055 Nuevos Objetos para motor JavaScript Manual Recomendado
Arquitectura Tecnológica
Có digo : ARQ_TEC
El subsistema de arquitectura recoge la propuesta de modelo de arquitectura software a utilizar en las aplicaciones JEE, así como
de documentar las distintas tecnologías disponibles para facilitar el desarrollo de aplicaciones.
MADEJA recomienda el uso del modelo arquitectónico basado en capas, para conseguir la independencia y robustez de cada una
de ellas centrándose en sus objetivos específicos.
Las pautas referentes a las buenas prácticas de desarrollo, procedimientos y recursos que tratan estas tecnologías pueden
consultarse en el área de construcción por capas del subsistema de desarrollo.
Objetivos
Capa de presentación y control
Capa que contiene la lógica de negocio
Capa de acceso a la información persistente
Pautas
LIBP-0005 Arquitectura Tecnológica de Referencia Directriz Recomendada
Buenas prácticas en el diseño de la
escalabilidad
LIBP-0073 Buenas prácticas en el manejo de la caché Directriz Obligatoria
Buenas practicas en el manejo de la caché en
Seam
PAUT-0324 Cacheo de scripts de PHP en Drupal Directriz Obligatoria
LIBP-0346 Configuración del php.ini Directriz Obligatoria
LIBP-0357 Configuración del log Directriz Recomendada
Estrategias de concurrencia de caché por
entidad en Hibernate
LIBP-0026 Mecanismos de configuración Directriz Obligatoria
Recursos
RECU-0123 Arquetipo para proyectos grandes Arquetipo Software Recomendado
RECU-0124 Arquetipos para proyectos medianos Arquetipo Software Recomendado
RECU-0125 Arquetipos para proyectos medianos de transición Arquetipo Software Recomendado
RECU-0266 APC Ficha Técnica Recomendado
RECU-0756 Cache de código intermedio Ejemplo Obligatorio
RECU-0219 Conceptos sobre la cache de objetos Referencia Recomendado
RECU-0220 Conceptos sobre la escalabilidad Referencia Recomendado
Definición de la estrategia de concurrencia de caché
RECU-0661 Ejemplo Obligatorio
por entidad en Hibernate
RECU-0222 EHCache Referencia Recomendado
RECU-0279 Estructura y manejo de la cache en Drupal Referencia Recomendado
RECU-0265 Memcached Ficha Técnica Recomendado
RECU-0747 Operaciones en modo asíncrono Ejemplo Recomendado
7
RECU-0223 OSCache Referencia Recomendado
RECU-0737 Políticas de expulsión Técnica Obligatorio
Capa de Presentación
Có digo : AT_CP
La programación por capas es un estilo de programación en el que el objetivo primordial es la separación de la lógica de
negocios de la lógica de diseño; un ejemplo básico de esto consiste en separar la capa de datos de la capa de presentación al
usuario. La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que
sobrevenga algún cambio, sólo es necesario actuar sobre el nivel requerido sin que sea necesario realizar modificaciones en el
código de los restantes niveles.
La capa de presentación es la que ve el usuario (también se la denomina "capa de usuario"), presenta el sistema al usuario, le
comunica la información y captura la información del usuario en un mínimo proceso (realiza un filtrado previo para comprobar
que no hay errores de formato). Esta capa se comunica únicamente con la capa de negocio. También es conocida como
interfaz gráfica y debe tener la característica de ser "amigable" (comprensible y fácil de usar) para el usuario.
Recursos
RECU-0007 Comparativa JSF Ficha Recomendado
RECU-0101 JavaServer Faces(JSF) Ficha Técnica Recomendado
RECU-0102 Ficha de JSF2 Ficha Técnica Recomendado
RECU-0103 ICE Faces Ficha Técnica Permitido
RECU-0085 RichFaces Ficha Técnica Recomendado
RECU-0086 Tomahawk Ficha Técnica Permitido
RECU-0087 Apache Trinidad Ficha Técnica Permitido
RECU-0088 Tobago Ficha Técnica Permitido
RECU-0089 AJAX Ficha Técnica Recomendado
RECU-0090 DWR Ficha Técnica Permitido
RECU-0091 GWT Ficha Técnica Permitido
RECU-0092 Mojarra Ficha Técnica Recomendado
Capa de Negocio
Có digo : AT_CN
La capa lógica de negocios ocupa un lugar preeminente en la construcción de una infraestructura de software, al permitir el
crecimiento y la extensión de servicios para todas las aplicaciones existentes y futuras.
La definición de los limites de cada capa nos permitirá definir correctamente la colaboración que proporcionará cada una de
ellas y descubriremos que la capa intermedia es inevitablemente la lógica de negocios. Esto dará lugar a una infraestructura
robusta y lista para la extensión y el crecimiento como proveedora de servicios.
Para la construcción de esta capa se emplearán los componentes tecnológicos más adecuados en cada caso.
Recursos
RECU-0093 Spring Ficha Técnica Recomendado
RECU-0094 Seam Ficha Técnica Recomendado
RECU-0095 Enterprise JavaBeans 3 Ficha Técnica Recomendado
Capa de Acceso a Datos

Có digo : AT_CD
En la capa de datos se gestiona el acceso a los datos de la aplicación. Se emplean gestores de bases de datos que realizan la
recuperación y el almacenamiento físico de los datos a partir de solicitudes de la capa de negocio.
En esta capa se puede hacer uso de una propiedad denominada persistencia de o bjeto s, que permite vincular objetos de
bases de datos relacionales a objetos de lenguajes de programación como Java, para aumentar el nivel de abstracción y
facilitar el acceso a los datos desde la capa de negocio. Existen varias implementaciones tecnológicas sobre persistencia que
deberán emplearse atendiendo a las necesidades de cada aplicación.
Recursos
RECU-0096 JPA Ficha Técnica Recomendado
RECU-0097 Hibernate Ficha Técnica Recomendado
8
RECU-0098 iBatis Ficha Técnica Permitido
Integración
Có digo : ARQ_INT
El área de Integración contiene pautas para el desarrollo de aplicaciones con arquitectura orientada a servicio, con la finalidad de
aumentar el grado de interoperabilidad de los sistemas de información y con la capacidad de atender de forma más eficiente los
procesos de negocio.
Se recogerán las recomendaciones de la Plataforma de Interoperabilidad de la Junta de Andalucía (PLATINA) y una propuesta
tecnológica de referencia, agilizando el desarrollo de nuevos servicios y el uso de los existentes.
En el futuro se añadirá el catálogo de servicios disponibles en la Junta de Andalucía, para dar una descripción funcional y
procedimental de su uso, registro de usuarios y recomendaciones.
Además de las indicaciones dadas en este subsistema, se ha creado un área específica en Desarrollo, Seguridad, Servicios Web
donde se resumen las recomendaciones sobre el uso y diseño de servicios web seguros.
Pautas
LIBP-0006 Creación de Servicios Web Directriz Obligatoria
Identificación de Mensajes y EndPoints (WS-
Addressing)
PAUT-0033 Manejo de Errores Directriz Obligatoria
PAUT-0030 Política de Versionado Directriz Obligatoria
LIBP-0007 Reglas de Codificación Directriz Obligatoria
LIBP-0321 Uso de Apis y Frameworks de Servicios Webs Directriz Obligatoria
Uso de especificaciones y estándares de
LIBP-0320 Directriz Recomendada
servicios web
Recursos
RECU-0100 Especificaciones y estándares de servicios web Especificación Recomendado
Plataforma de Interoperabilidad de la Junta de
Andalucía
Source URL: http://madeja.i-administracion.junta-andalucia.es/servicios/madeja/contenido/subsistemas/arquitectura
9
Catálogo
El subsistema de catálogo se centra en aspectos de gestión de configuración, con el objetivo principal de fomentar la
compartición y reutilización del código fuente, librerías y componentes asociados a los sistemas de información desarrollados
para la Junta de Andalucía.
El subsistema de catálogo proporcionará herramientas que posibiliten el acceso a información, componentes, código y
documentación de los desarrollos realizados en la Junta.
Objetivos
Proporcionar un repositorio de fuentes y documentación
Dar acceso a componentes de reutilización
Suministrar aplicaciones piloto
Publicar un catalogo de servicios
Catálogo de Software de la Junta de Andalucía

Có digo : catalogo_de_software
Este área se centra en proporcionar pautas, procedimientos y recursos sobre el uso de la herramienta "Catálogo de Software de
la Junta de Andalucía", cuyo fin principal es el de fomentar la reutilización del código fuente y componentes de los sistemas de
información desarrollados para la Junta de Andalucía.
Pautas
PAUT-0034 Disponibilidad del software Directriz Obligatoria
Incorporación del Software al Catálogo de
Software de la Junta de Andalucía
Incorporación de librerías al Catálogo de
Software de la Junta de Andalucía
Procedimientos
PROC-0002 Procedimiento Publicación en el Catálogo y Repositorio Obligatorio
Recursos
RECU-0001 Catálogo de Software de la Junta de Andalucía Herramienta Recomendado
RECU-0003 API para Interoperar con el Catálogo de Software API Recomendado
Source URL: http://madeja.i-administracion.junta-andalucia.es/servicios/madeja/contenido/subsistemas/catalogo
1
Desarrollo
El subsistema de Desarrollo contempla las normativas y estándares para la elaboración de un código fuente homogéneo y
estándar con el objeto de minimizar las tareas de mantenimiento. También se incorporan las especificaciones para la obtención
de sistemas de información seguros, con un rendimiento óptimo y adaptados a las necesidades de las tecnologías definidas en
el subsistema de Arquitectura de MADEJA con el que está ampliamente vinculado.
Enlaces rápidos a tablas resumen:
Tabla resumen de las tecnologías asociadas al subsistema de desarrollo.
A partir de las pautas del subsistema se han elaborado la verificaciones que pueden realizarse. Estas verificaciones se ha
agrupado en matrices de verificación en función del área al que pertenecen. Puede descargar las matrices en el siguiente
enlace. Posteriormente estas verificaciones estará almacenadas en el sistema VerificA.
Se ha hecho un esfuerzo inicial para automatizar estas verificaciones utilizando la herramienta sonar. Existen para sonar una
serie de plugins como pmd, checktyles, findbugs, que se han usado. Para usar estas primeras verificaciones automáticas
puede descargar el perfil del proyecto sonar en el siguiente enlace.
Objetivos
Promover la generación de código fuente de calidad.
Unificar el uso de librerías y utilidades de apoyo.
Proponer plugins para el desarrollo con IDEs.
Promover el uso de patrones de diseño software.
Licenciamiento
Fases del ciclo de vida: Construcción del Sistema de Información (CSI)

Perfiles: Responsable de Calidad
Có digo : DES_LICENCIAMIENTO
La Junta de Andalucía trata desde hace años de impulsar el uso de software libre. Como parte de este objetivo nace la ORDEN DE
21 DE FEBRERO DE 2005, en la que se hace constar que el software desarrollado por o para la Junta de Andalucía debe estar
disponible públicamente. Para dar cumplimiento a esta orden se crea el Repositorio de Software Libre de la Junta de Andalucía.
Para que el software publicado sea libre, tiene que ir acompañado de una licencia de software libre. En concreto dentro del marco
de la Junta de Andalucía se debe usar siempre que se pueda la licencia EUPL (European Union Public License)
Pautas
PAUT-0035 Licenciamiento del Software Directriz Obligatoria
Recursos
RECU-0104 EUPL (European Union Public License) Legislación Recomendado
RECU-0105 Guía de licenciamiento de aplicaciones Ejemplo Recomendado
RECU-0106 Herramienta para añadir la Licencia EUPL Herramienta Recomendado
RECU-0876 Matriz de verificación de licenciamiento Plantilla Recomendado
RECU-0012 Maven License Plugin Ficha Recomendado
Especificaciones de Codificación y Construcción

Có digo : DES_ESPEC_COD_CONS
El establecimiento de la normativa para la codificación de aplicaciones se organizará en base a los diferentes elementos que
configuran la arquitectura del Subsistema MADEJA, profundizando con un mayor nivel de detalle sobre aquellos elementos que se
1
consideran la base de esta arquitectura.
También se tendrán en cuenta el conjunto de reglas que son ya contempladas por diferentes herramientas de control de calidad
software, y que proporcionan una importante referencia para extraer la normativa y directrices que debe ser tenida en cuenta
para el desarrollo de las aplicaciones, y que posteriormente son controladas y supervisadas por estas herramientas. El enfoque
de esta línea de trabajo busca establecer la normativa de aquellas verificaciones que son contempladas en estas herramientas.
Pautas
LIBP-0008 Convenio de codificación general Directriz Obligatoria
Convenio de codificación específico para
Drupal
LIBP-0015 Convenio de codificación específico para Java Directriz Obligatoria
LIBP-0089 Convenio de codificación específico para PHP Directriz Obligatoria
Convenio de codificación específico para
PL/SQL
LIBP-0010 Convenio de codificación específico para XML Directriz Obligatoria
LIBP-0018 Reglas de construcción en Java Directriz Obligatoria
LIBP-0102 Reglas de construcción en PHP Directriz Obligatoria
LIBP-0014 Reglas de construcción en PL/SQL Directriz Obligatoria
LIBP-0337 Reglas de construcción en J2ME Directriz Obligatoria
LIBP-0359 Reglas de construcción en sistemas SIG Directriz Obligatoria
Recursos
RECU-0205 Concepto sobre el desarrollo SIG Referencia Recomendado
RECU-0206 Conceptos sobre el diseño de los sistemas SIG Referencia Recomendado
RECU-0207 Conceptos sobre J2ME Referencia Recomendado
RECU-0110 Doxygen Referencia Permitido
Implementación de convenios de codificación en
RECU-0620 Referencia Obligatorio
Drupal
general
RECU-0734 Implementación de convenios de codificación en Java Ejemplo Obligatorio
RECU-0739 Implementación de convenios de codificación en PHP Ejemplo Obligatorio
PL/SQL
RECU-0731 Implementación de convenios de codificación en XML Ejemplo Obligatorio
RECU-0745 Implementación de reglas de construcción en Java Ejemplo Recomendado
RECU-0764 Implementación de reglas de construcción en PHP Ejemplo Obligatorio
RECU-0736 Implementación de reglas de construcción en PL/SQL Ejemplo Recomendado
RECU-0109 Javadoc Herramienta Recomendado
RECU-0107 Manual de desarrollo en PL/SQL Manual Recomendado
RECU-0256 Manual de PHP Manual Recomendado
Matriz de verificación de especificaciones de
RECU-0877 Plantilla Recomendado
codificación y construcción
RECU-0749 Niveles de Prioridad de Logging Ficha Obligatorio
RECU-0255 PHPDocumentor Ficha Técnica Recomendado
RECU-0270 PHP_CodeSniffer (phpcs) Ficha Técnica Recomendado
Construcción de Aplicaciones por Capas

Có digo : CONST_APLIC_CAPAS
La programación por capas es un estilo de programación en el que el objetivo primordial es la separación de la lógica de
negocios de la lógica de diseño; un ejemplo básico de esto consiste en separar la capa de datos de la capa de presentación al
usuario. La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que
sobrevenga algún cambio, sólo se ataca al nivel requerido sin tener que revisar código entremezclado.
Se agrupan por cada capa una serie de recomendaciones basadas en el modelo de tres capas propuesto en el subsistema de
2
Arquitectura, en el área Arquitectura Tecnológica, de MADEJA. Se han realizado estudios y recomendaciones sobre de las
tecnologías más recomendables para la arquitectura propuesta y se presentan una serie de pautas tanto a nivel funcional como
para la construcción e integración de cada capa.
La ventaja de la variedad de tecnologías disponibles para el desarrollo de las diferentes capas de las aplicaciones Java, presenta
el inconveniente de la utilización conjunta de varias de ellas. Debido a esto se deben establecer unos criterios que hagan posible
una integración óptima entre las tecnologías empleadas. Estos criterios se han recogido en forma de pautas que se describen en
esta área.
Pautas
PAUT-0321 Separación por capas Directriz Recomendada
Java

LIBP-0049 Integración JSF - JPA Directriz Recomendada
LIBP-0053 Integración JSF - Seam Directriz Recomendada
LIBP-0054 Integración JSF - Spring Directriz Recomendada
LIBP-0051 Integración Seam - EJB3 Directriz Recomendada
LIBP-0052 Integración Seam - JPA Directriz Recomendada
LIBP-0050 Integración Spring - JPA Directriz Recomendada
PHP

Buenas prácticas en el desarrollo de
aplicaciones con ZEND
aplicaciones con CakePhp
aplicaciones con Symfony
aplicaciones con Codeigniter
Recursos
PHP

RECU-0262 CakePHP Referencia Recomendado
RECU-0264 CodeIgniter Referencia Recomendado
RECU-0263 Symfony Referencia Recomendado
RECU-0261 ZEND Referencia Recomendado
Java

RECU-0822 Integración de JSF y JPA Referencia Recomendado
RECU-0826 Integración de JSF y Seam Referencia Recomendado
RECU-0827 Integración de JSF y Spring Referencia Recomendado
RECU-0824 Integración de Seam y EJB3 Referencia Recomendado
RECU-0825 Integración de Seam y JPA Referencia Recomendado
RECU-0823 Integración de Spring y JPA Referencia Recomendado

Matriz de verificación de construcción de aplicaciones
por capas
Capa de Presentación
Có digo : CAPA_PRESENTACION
Mediante la capa de presentación se separa la interacción del usuario respecto a la lógica de negocio.
El uso extendido de la arquitectura en 3 niveles en el desarrollo de aplicaciones Java, ha favorecido la aparición de tecnologías
que facilitan la implantación de esta capa, como JSF o Richfaces, además de un conjunto de buenas prácticas que mejoran el
proceso complejo de elaboración de la capa de presentación. Este área está muy relacionada con el subsistema Interfaz de
usuario y con el área Capa de Presentación del subsistema Arquitectura.
3
Se recogen en esta área las pautas a seguir en la construcción de esta capa.
Pautas
LIBP-0011 Funcionalidades de la capa de presentación Directriz Obligatoria
LIBP-0030 Buenas Prácticas en el uso de JSF2 Directriz Obligatoria
Uso de validadores de la capa de
presentación
LIBP-0029 Buenas Prácticas en el uso de RichFaces Directriz Recomendada
LIBP-0352 Buenas prácticas en el uso de AJAX Directriz Recomendada
Tecnologías permitidas para el
mantenimiento de sistemas de información
Buenas prácticas en el uso de Direct Web
Remoting (DWR)
LIBP-0355 Buenas prácticas en el uso de GWT Directriz Recomendada
LIBP-0353 Buenas prácticas en el uso de ICEfaces Directriz Recomendada
Procedimientos
PROC-0008 Proceso de construcción de la capa de presentación Recomendado
Recursos
RECU-0132 AJAX Referencia Recomendado
RECU-0127 Arquetipo JSF con Richfaces Arquetipo Software Recomendado
RECU-0128 Controles RichFaces incluidos en el UI Referencia Recomendado
RECU-0138 DWR Referencia Permitido
RECU-0140 Facelets Referencia Recomendado
RECU-0129 Guía para personalizar un control RichFaces Referencia Recomendado
RECU-0139 GWT Referencia Permitido
RECU-0133 ICEfaces Referencia Permitido
RECU-0819 Implementación de la capa de presentación con JSF Referencia Recomendado
RECU-0131 JSF2 Referencia Recomendado
RECU-0130 Manual de JSF Manual Recomendado
RECU-0879 Matriz de verificación de capa de presentación Plantilla Recomendado
RECU-0134 RichFaces Referencia Recomendado
RECU-0136 Tobago Referencia Permitido
RECU-0137 Tomahawk Referencia Permitido
RECU-0135 Trinidad Referencia Permitido
RECU-0141 Validadores de la capa de presentación Referencia Recomendado
Capa de Negocio
Có digo : CAPA_NEGOCIO
La capa de negocio expone la lógica necesaria a la capa de presentación para que el usuario, a través de la interfaz, interactúe
con las funcionalidades de la aplicación.
Se define el uso de componentes de negocio para abstraer la lógica de negocio de otros problemas generales de las
aplicaciones empresariales como la concurrencia, transacciones, persistencia, seguridad, etc.
Este área está muy relacionada con el área Capa de Negocio, del subsistema Arquitectura, y se incluyen pautas para el uso
correcto de diferentes tecnologías Java y PHP.
Pautas
Buenas prácticas en la construcción de la
capa de negocio
capa de negocio con EJB3
capa de negocio con Seam
4
capa de negocio con Spring
Vulnerabilidades de Spring con la capa de
presentación
Procedimientos
PROC-0007 Procedimiento de construcción de la capa de negocio Recomendado
Recursos
RECU-0169 Estudio comparativo entre JBoss Seam y Spring Técnica Recomendado
RECU-0171 Integración de Spring con otras capas del modelo Experiencia Recomendado
RECU-0880 Matriz de verificación de capa de negocio Plantilla Recomendado
RECU-0144 Referencia de EJB3 Referencia Recomendado
RECU-0143 Seam Referencia Recomendado
RECU-0142 Spring Manual Recomendado
RECU-0170 Transacciones en la capa de negocio en Spring Referencia Recomendado
Capa de Persistencia
Có digo : CAPA_PERSISTENCIA
La necesidad de vincular los datos guardados en una base de datos relacional, con los objetos de una aplicación orientada a
objetos, determinó la aparición del concepto de persistencia de objetos. Siguiendo el estilo de desarrollo en tres capas, la
persistencia queda recogida en su propia capa, separada de la lógica de negocio y de la interfaz de usaurio.
Este área esta estrechamente ligada al área Capa de Acceso a Datos del subsistema de Arquitectura de MADEJA.
Pautas
Java

PAUT-0286 Uso de Apache Cayenne Directriz No Recomendada
LIBP-0046 Buenas prácticas en el uso de Hibernate Directriz Obligatoria
capa de persistencia con JPA
LIBP-0047 Buenas prácticas en las consultas con JPA Directriz Obligatoria
PAUT-0311 Uso de iBatis Directriz Recomendada
PAUT-0312 Uso de TopLink Directriz Recomendada

LIBP-0013 Funcionalidades de la capa de persistencia Directriz Obligatoria
PHP

LIBP-0105 Buenas prácticas en el uso de Doctrine Directriz Recomendada
PAUT-0317 Uso de Propel Directriz Recomendada
Procedimientos
PROC-0009 Procedimiento de construcción de la capa de persistencia Recomendado
Recursos
RECU-0680 Acceso a campos BFILE con JDBC Ejemplo Permitido
RECU-0180 Comparación de las tecnologías de acceso a datos Técnica Recomendado
Conceptos sobre la funcionalidad de la capa de
persistencia
RECU-0881 Matriz de verificación de capa de persistencia Plantilla Recomendado
Java
5
RECU-0676 Apache Cayenne Referencia No recomendado
Configuración del "pool" de conexiones en
Hibernate
RECU-0177 Referencia a iBatis Referencia Permitido
Implementando equals() y hashCode() utilizando
igualdad de negocio en Hibernate
RECU-0662 Implementando una NamingStrategy en Hibernate Ejemplo Obligatorio
RECU-0702 MyBatis Ficha Permitido
RECU-0176 Referencia JPA Referencia Recomendado
RECU-0178 Referencia a Hibernate Referencia Recomendado
RECU-0179 Referencia a Toplink Referencia Permitido
PHP

RECU-0260 Doctrine Referencia Recomendado
RECU-0258 PDO Ficha Técnica Recomendado
RECU-0259 Propel Referencia Recomendado
Seguridad
Có digo : DES_Seguridad
En este área se incluyen conceptos, recomendaciones, consejos y ejemplos de seguridad en los procesos de desarrollo de
aplicaciones informáticas, teniendo en cuenta las indicaciones del Plan Director de Seguridad de los Sistemas de Información y
Telecomunicaciones de la Administración de la Junta de Andalucía, del Esquema Nacional de Seguridad, de las normas ISO 27000
y de la Ley Orgánica de Protección de Datos.
Además de seguir estas consideraciones en los desarrollos de las aplicaciones, es muy importante prestar atención en los
casos en que se utilicen componentes de terceros. En este sentido, el ENS recomienda disponer de un procedimiento
documentado para la adquisición de componentes cuya evaluación se haya realizado conforme a normas europeas o
internacionales (p.ej: cumple la ISO/IEC 15408, etc). Hay que tener en cuenta que la inclusión de un componente con
vulnerabilidades en un sistema producirá probablemente un detrimento de la seguridad del mismo.
Una parte importante de los problemas de seguridad de los sistemas de información tiene su origen en defectos o carencias en
las aplicaciones que los integran, lo cual eleva enormemente el riesgo de sufrir un incidente.
En una aplicación web, dividimos la seguridad en:
Dispo nibilidad: Asegurar que las entidades o procesos autorizados tienen acceso a los activos cuando lo requieren.
Autenticidad: Verificamos quien es el usuario. Generalmente, esto se hace pidiéndole un nombre de usuario y un
password, es decir, se verifica que una entidad es quien dice ser o bien que garantiza la fuente de la que proceden los datos
Integridad: Asegurar que los datos que se envían entre el cliente y el servidor no hayan sido alterados de forma no
autorizada. Para esto, se utilizan generalmente algoritmos de encriptación.
Co nfidencialidad: Asegurar que la información ni se pone a disposición, ni se revela a individuos, entidades o procesos
no autorizados. Esto puede hacerse con algoritmos de encriptación y con certificados digitales.
Trazabilidad: Verificar que las actuaciones de una entidad pueden ser imputadas exclusivamente a dicha entidad.
El análisis de las vulnerabilidades potenciales es un objetivo básico para el incremento de la seguridad en las aplicaciones web,
que en ocasiones es subestimado como factor de riesgo crítico. El mantener parámetros que no son verificados, roles sin
controlar, desbordamientos que se producen en la memoria son algunas de las situaciones que pueden provocar brechas de
seguridad en las aplicaciones.
Objetivos
Asegurar la autenticación de los usuarios
Gestionar los permisos de acceso a los recursos
Evitar la corrupción de los datos enviados entre cliente y servidor
Asegurar la no visibilidad de la información por terceros en las comunicaciones
Pautas
LIBP-0360 Uso de applets Directriz Obligatoria
Recursos
6
RECU-0656 Acunetix Web Vulnerability Scanner Herramienta Recomendado
RECU-0651 AndalucíaCERT Referencia Recomendado
RECU-0546 Agencia Española de Protección de Datos Especificación Recomendado
RECU-0212 Conceptos de seguridad en aplicaciones WEB Referencia Recomendado
RECU-0545 Esquema Nacional de Seguridad Especificación Recomendado
RECU-0548 Familia ISO 27000 Especificación Recomendado
RECU-0552 Framework de testeo ISAFF Especificación Recomendado
RECU-0567 Ley Orgánica de Protección de Datos Legislación Obligatorio
Manual de la Metodología Abierta de Testeo de
Seguridad (OSSTMM)
RECU-0659 Matriz de verificación de seguridad Plantilla Recomendado
RECU-0657 Meta-extractor FOCA Herramienta Recomendado
RECU-0215 Open Web Application Security Project (OWASP) Especificación Recomendado
RECU-0553 OWASP Testing Project Especificación Recomendado
Plan Director de Seguridad de los Sistemas de
RECU-0547 Información y Telecomunicaciones de la Legislación Recomendado
Administración de la Junta de Andalucia
RECU-0550 Portal CCN-CCERT Especificación Recomendado
RECU-0617 Tipología de Vulnerabilidades del Software Especificación Recomendado
RECU-0654 W3af Herramienta Recomendado
Seguridad
Control de Acceso y Autenticación

Có digo : SEG_Acceso
Se analizan la vulnerabilidades que pueden darse en las aplicaciones a la hora de identificar sus usuarios y los permisos que
estos poseen. Recogiendo una serie de recomendaciones para el desarrollo de aplicaciones, que tenidas en cuenta, ayuden a
mitigar los riesgos de producirse situaciones como el escalado de privilegios o la suplantación de identidad.
Hay dos procesos distintos que intervienen cuando se trata de permitir a un usuario acceder a páginas específicas de un sitio
web:
La autenticació n es el proceso de identificación de un individuo sobre la base de sus credenciales (normalmente nombre de
usuario y contraseña)
El objetivo de la autenticació n es decidir si "alguien es quien dice ser". Hay tres formas de reconocer a un usuario, que
se conocen como factores:
Algo que saben, como una contraseña o PIN
Algo que tienen, tal como una licencia de conducir o tarjeta de crédito
Algo que son, como las huellas digitales o la inserción de los patrones
El co ntro l de acceso es el proceso de decidir si el usuario tiene permiso para ejecutar algo o no.
También llamado auto rizació n, se refiere a la gestión del acceso a los recursos protegidos y al proceso de determinar si un
usuario está autorizado a acceder a un recurso particular. Por ejemplo, muchas aplicaciones web cuentan con recursos que
sólo están disponibles para los usuarios autenticados, recursos que sólo están disponibles para los administradores, y los
recursos que están disponibles para todos.Así, al establecer privilegio s de acceso a lo s usuario s podemos asegurar la
confidencialidad y disponibilidad de la información; pero, además, podemos:
Que sólo las perso nas auto rizadas podrán acceder a ciertos recursos (sistemas, equipos, programas, aplicaciones,
bases de datos, redes, etc…) por sus funciones laborales.
Nos permiten identificar y auditar los accesos realizados, estableciendo controles de seguridad internos.
Documentar los pro cedimiento s de acceso a las diferentes aplicaciones que tratan datos personales.
En definitiva, co ntro lar lo s acceso s desde diferentes vertientes: red, sistemas y aplicaciones.
Hoy en día es muy común la escalada de privilegio s, que no es más que la obtención de los privilegios del administrador.
Por ello, debe existir una política o normativa específica que establezca el uso de mecanismos para impedir intentos de
escalado de privilegios en nuestras aplicaciones web.Se considera que un sistema aplica políticas para evitar el escalado de
privilegios cuando: No es posible acceder a información del sistema que pueda ser utilizada para la escalada de privilegios, no
es posible ejecutar acciones haciéndose pasar por otro usuario, etc.
Objetivos
Asegurar la identidad de los usuarios que acceden a las aplicaciones
Garantizar el acceso a recursos protegidos
Pautas
7
LIBP-0271 API's privilegiadas Directriz Obligatoria
LIBP-0253 Autenticación Directriz Obligatoria
PAUT-0234 Autorizaciones personalizadas Directriz No Recomendada
LIBP-0269 Canal de comunicación Directriz Obligatoria
LIBP-0272 Contraseñas Directriz Obligatoria
LIBP-0254 Control de acceso Directriz Obligatoria
LIBP-0263 Listas de control Directriz Recomendada
LIBP-0285 Manejo de contraseñas perdidas Directriz Obligatoria
LIBP-0258 Nombres de usuario Directriz Recomendada
LIBP-0264 Uso de permisos en recursos críticos Directriz Obligatoria
Recursos
RECU-0563 Ataques de reflexión sobre la autenticación en Java Ejemplo Obligatorio
RECU-0559 Autenticación Referencia Obligatorio
Cacheo del resultado de una operación privilegiada
en Java
RECU-0562 Canal accesible por un punto no final en Java Ejemplo Obligatorio
Comprobación de la perdida de autenticación sobre
funciones significativas en Java
Comprobar los permisos de un nodo específico
utilizando node_access en Drupal
Comprobar los permisos mediante la función
user_access en Drupal
Conceptos de seguridad en la capa de negocio
mediante Spring
RECU-0213 Configuración de Spring Security Referencia Recomendado
Consultas para el acceso a nodos restringidos en
Drupal
RECU-0622 Controlador Java del DNI electrónico Referencia Recomendado
Envío de credenciales por correo electrónico en
RECU-0675 Ejemplo No recomendado
Drupal
RECU-0664 Limitación del número de autenticaciones en Java Ejemplo Recomendado
Manejar los permisos mediante la función
hook_perm() en Drupal
RECU-0582 Manejo de las contraseñas perdidas en PHP Ejemplo Obligatorio
RECU-0544 Manejo de permisos en métodos de EJB Ejemplo Obligatorio
RECU-0621 Portal CERES Referencia Recomendado
RECU-0666 Retardo tras autenticación fallida en PHP Ejemplo Recomendado
RECU-0650 Sistemas anti-bots Referencia Recomendado
RECU-0603 Uso de getPermissions() Ejemplo Obligatorio
RECU-0601 Uso de java.security.AllPermission Ejemplo Obligatorio
RECU-0674 Uso del modulo Login Security en Drupal Ejemplo Obligatorio
RECU-0602 Variables externas en bloques doPrivileged Ejemplo Obligatorio
Seguridad
Codificación y Validación de entrada/salida

Có digo : SEG_Codificacion_y_Validacion
La debilidad de seguridad más común en aplicaciones web es la falta de validación apropiada de las entradas del cliente o del
entorno.Teniendo en cuenta una serie de indicaciones y consejos a la hora de codificar nuestras aplicaciones podremos evitar
problemas como la inyección de código SQL, de comandos, LDAP, XPath, XML o por XSS.
Esta debilidad lleva a casi todas las principales vulnerabilidades en las aplicaciones, tales como intérprete de inyección,
ataques locale/Unicode, ataques al sistema de archivos y desbordamientos de memoria.
Nunca se debe confiar en los datos introducidos por el cliente, ya que podría manipularlos. Hay que garantizar que la aplicación
sea robusta contra todas las formas de ingreso de datos, ya sea obtenida del usuario, de la infraestructura, de entidades
externas o de sistemas de base de datos.
Existen vulnerabilidades asociadas a la validación de los datos,
8
Vulnerabilidad de la integridad de lo s dato s El atacante manipula los datos introduciendo intencionadamente datos
erróneos que manipulan la función de negocio.
Vio lació n del fo rmato de lo s dato s Un atacante consigue introducir datos sin la sintaxis correcta, fuera de los limites
de longitud, que contenga caracteres no permitidos, con signo incorrecto o fuera de los límites del rango. Esto provoca un
mal funcionamiento de la aplicación.
Incumplimiento de las reglas de nego cio Se introducen datos que no cumplen con las reglas de negocio. Lo que
provoca un comportamiento no esperado de la aplicación.
Objetivos
Aplicar técnicas de codificación que mejoren la seguridad de las aplicaciones
Evitar los ataques por inyección con la validación de la entrada / salida
Pautas
PAUT-0203 Campos ocultos Directriz No Recomendada
LIBP-0273 Desbordamiento del buffer de memoria Directriz Obligatoria
PAUT-0196 Exposición del código fuente Directriz Recomendada
LIBP-0276 Inyección de código basada en SQL Directriz Obligatoria
LIBP-0277 Inyección de código sobre argumentos Directriz Obligatoria
PAUT-0252 Limpieza de documentos Directriz Obligatoria
Métodos de control de seguridad privados o
finales
Protección de la información en los
procesos del sistema
PAUT-0251 Pruebas con datos reales Directriz No Recomendada
LIBP-0309 Referencia directa a objetos Directriz Obligatoria
PAUT-0208 Salida de las funciones Directriz Obligatoria
LIBP-0255 Validación de los datos de entrada Directriz Obligatoria
Recursos
RECU-0616 Escapado de caracteres en PHP Ejemplo Obligatorio
RECU-0558 Exposición de código fuente en PHP Ejemplo Recomendado
RECU-0610 Expresiones regulares basadas en PERL (PCRE) Experiencia Obligatorio
RECU-0599 Fallos al filtrar la sintaxis en Java Ejemplo Obligatorio
RECU-0604 Filtrado de entrada de datos en Java Ejemplo Recomendado
RECU-0615 Inclusión de ficheros en PHP (allow_url_fopen) Experiencia Obligatorio
RECU-0578 Inyección en Hibernate con SQL Ejemplo Obligatorio
RECU-0543 Inyección en LDAP en Java Ejemplo Obligatorio
RECU-0575 Inyección sobre el sistema operativo Técnica Obligatorio
RECU-0613 Llamadas a programas externos en PHP Ejemplo Obligatorio
RECU-0609 Manejo de cabeceras HTTP (inyección CRLF) Ejemplo Obligatorio
RECU-0608 Manejo de identificadores de recursos Ejemplo Obligatorio
RECU-0612 Métodos de control de seguridad privados o finales Ejemplo Obligatorio
RECU-0605 Neutralización de datos en las expresiones XPATH Ejemplo Obligatorio
RECU-0606 Neutralización de datos en las expresiones XQuery Ejemplo Obligatorio
Obtención de información de la lista de procesos del
sistema en Java
Uso de check_plain() y t() para limpiar los caracteres
de las salida en PHP
Uso de la función filter_xss() para proteger de los
ataques de Cross-Site Scripting en PHP
RECU-0614 Validación de los datos de entrada en PHP Ejemplo Obligatorio
RECU-0619 Validación de salidas en Java Ejemplo Obligatorio
Seguridad
9
Cifrado
Có digo : SEG_Cifrado
Una de las principales medidas para asegurar la integridad y la confidencialidad de la información que se transmite a través de
la red es la encriptación o codificación de los mensajes, evitando que, aún interceptando nuestra comunicación, no sea posible
su entendimiento. Para ello, se resumen diversas situaciones en las que se debe cifrar la información y los algoritmos a utilizar.
El cifrado de dato s es el proceso por el que una información legible se transforma mediante un algoritmo (llamado cifra) en
información ilegible, llamada criptograma o secreto.
Esta información ilegible se puede enviar a un destinatario con muchos menos riesgos de ser leída por terceras partes. El
destinatario puede volver a hacer legible la información (descifrarla) introduciendo la clave del cifrado .
La seguridad de un buen sistema de cifrado depende enteramente de la clave, y no debe depender del algoritmo de
cifrado usado. Es decir, el algoritmo de cifrado a menudo es público, y es conocido por los posibles atacantes, pero si el
algoritmo es bueno, esto no debe bastarles para descifrar el mensaje.
Los algoritmos usados en las comunicaciones seguras de Internet son públicos prácticamente siempre, por lo que es
necesario centrarse en crear claves suficientemente seguras.
Además, la capacidad computacional de los ordenadores crece constantemente y cada vez son capaces de probar más y más
claves por segundo de forma que puedan encontrar la clave simplemente probando una y otra vez.
No debe confundirse la clave del cifrado con las palabras de paso usadas para acceder a algunas aplicaciones: por ejemplo,
para acceder a un cliente de correo online es necesaria una contraseña, que es enviada desde la ventana del explorador al
servidor para que procese la petición de login. En este caso, la fuerza bruta (probar sucesivamente todas las claves posibles),
es inútil, ya que casi todas las aplicaciones tienen limitado el número de intentos. No obstante, esa contraseña que enviamos
desde el navegador, se envía cifrada al servidor a través de Internet. Si alguien consiguiera captar la información en la que viaja
la contraseña sí podría introducir ese texto cifrado en una aplicación de criptoanálisis e intentar descifrarla y después usarla.
Objetivos
Asegurar la confidencialidad e integridad de la información
Pautas
LIBP-0270 Algoritmos de cifrado Directriz Obligatoria
LIBP-0256 Almacenamiento de claves Directriz Obligatoria
LIBP-0274 Encriptación de la información sensible Directriz Obligatoria
PAUT-0235 Espacio de claves apropiado Consejo
PAUT-0202 Generación de tokens seguros Directriz Obligatoria
PAUT-0200 Transmisiones de datos Directriz Obligatoria
Recursos
RECU-0581 Almacenamiento de las contraseñas en PHP Ejemplo Obligatorio
Almacenar datos encriptados en una base de datos
o un fichero en PHP
RECU-0574 Código vulnerable con contraseña sin encriptar Ejemplo Recomendado
RECU-0570 Conexión sin encriptación de la información Ejemplo Obligatorio
Criptología de empleo en el Esquema Nacional de
Seguridad
RECU-0593 Encriptación de los identificadores de sesión en PHP Ejemplo Obligatorio
RECU-0583 Encriptar y desencriptar datos en PHP Ejemplo Obligatorio
RECU-0607 Generar números aleatorios fuertes en Java Ejemplo Recomendado
Guía de referencia sobre la arquitectura de
criptografía en Java
RECU-0554 Introducción al cifrado Referencia Recomendado
RECU-0595 Protección de los datos a direfentes niveles Referencia Recomendado
RECU-0669 Uso de claves en el código fuente Ejemplo No recomendado
Seguridad
Gestión de Sesiones y Usuarios

Có digo : SEG_Sesiones
El manejo de la sesión es uno de los aspectos críticos de la seguridad WEB. Veremos cómo es posible mejorar la seguridad en
el control de acceso y la autenticación a través del manejo de las sesiones y de la información de los usuarios de nuestras
aplicaciones.
10
Se detectan las siguientes vulnerabilidades significativas.
Fijació n de sesió n que intenta explotar la vulnerabilidad de un sistema que permite a una persona fijar el identificador
de sesión de otra persona. La mayoría de ataques de fijación del período de sesiones están basados en la web, y la
mayoría depende de los identificadores de sesión que han sido aceptados de URL o datos POST
Identificado r de la sesió n vulnerable, si no se reserva un tamaño adecuado el atacante, mediante técnicas de
fuerza bruta atacante puede conocer el identificador de una sesión autenticada y por lo tanto hacerse con el control de la
sesión.
Manejo de la info rmació n de sesió n erró nea, ya sea por estar en un espacio compartido o mal encriptada, el
atacante puede obtener datos de la sesión de otro usuario.
Ataques de pro xys o cachés, las aplicaciones web deben especificar mecanismos para impedir estos ataques de tal
manera que no sea posible suplantar sesiones de otros usuarios.
Objetivos
Los usuarios autenticados tengan una asociación con sus sesiones robusta y criptográficamente segura.
Se hagan cumplir los controles de autorización.
Se prevengan los típicos ataques web, tales como la reutilización, falsificación e intercepción de sesiones.
Pautas
LIBP-0310 Generación de la sesión Directriz Obligatoria
LIBP-0311 Gestión de la sesión Directriz Obligatoria
LIBP-0312 Desconexión de la sesión Directriz Obligatoria
Recursos
Almacenamiento de objetos no serializables en
HttpSession
RECU-0591 Cambio del identificador de sesión en PHP Ejemplo Obligatorio
Configuración de la carpeta donde se almacenan las
sesiones
Denegación al JavaScript del navegador del acceso a
las cookies
Eliminación de sesiones antes de un nuevo acceso
en Java
Identificador de sesión generado por el servidor en
PHP
RECU-0587 Mal uso de la desconexión de sesión en Java Ejemplo Obligatorio
RECU-0594 Manejo de sesiones en Drupal Referencia Obligatorio
RECU-0557 Proteger los datos expuestos en sesión en php Ejemplo Recomendado
Seguridad
Gestión de Errores y Excepciones

Có digo : SEG_Errores
Uno de los focos que originan vulnerabilidades en nuestras aplicaciones se basa en la falta de control sobre los errores que se
producen en su ejecución y el tratamiento correcto de las excepciones. Veremos cómo disminuir los riesgos de ser atacados
a partir de la generación de un error o excepción en la aplicación.
El manejo de errores y excepciones son dos aspectos para realizar un seguimiento de fallos dentro de una aplicación. En
términos generales, hay tres situaciones que hacen que las excepciones sean lanzadas:
Excepcio nes que se pro ducen en el có digo del cliente: El código cliente intenta hacer algo que no esta permitido
por la API, de esta forma viola el contrato. El cliente puede tomar algún camino alternativo, si hay información útil
proporcionada en la excepción. Por ejemplo: una excepción es lanzada cuando se está analizando un documento XML que
no está bien formado. La excepción contiene información útil acerca de la localización en el documento XML donde se
produce el problema. El cliente puede utilizar esta información para recuperarse del problema.
Excepcio nes po r fallo s en lo s recurso s mantenido s: Las excepciones se producen si existe un fallo derivado de
un recurso. Por ejemplo, el agotamiento de memoria o el fallo de conexión cuando se cae una red. La respuesta del cliente
a los recursos que fallan depende del contexto. El cliente puede reintentar la operación después de algún tiempo o
simplemente registrar el fallo del recurso y detener la aplicación.
Excepcio nes po r erro res derivado s del có digo pro gramado : En esta categoría, las excepciones se producen
en la ejecución del código. El código cliente usualmente no puede hacer nada con estos errores.
11
Objetivos
Asegurar la gestión de errores y excepciones en las aplicaciones desarrolladas
Pautas
LIBP-0280 Información facilitada en la página de error Directriz Obligatoria
PAUT-0239 Inmutabilidad de la excepción Directriz Obligatoria
LIBP-0281 Tratamiento de excepciones Directriz Obligatoria
Recursos
RECU-0585 Excepciones propias de la lógica de negocio en PHP Experiencia Recomendado
RECU-0586 Nivel de error E_Strict Ejemplo Obligatorio
Limpieza en el código después de ejecutar código
propio en Java
RECU-0214 Tratamiento de las excepciones en Java Referencia Recomendado
Seguridad
Auditoría y Registro
Có digo : SEG_Auditoria
La auditoría y el registro de los eventos que suceden al ejecutar nuestras aplicaciones nos permite monitorizarlas y detectar
posibles intentos de ataques o intrusiones. Además, veremos cómo mejorar la gestión de los archivos de log para que sean
más seguros.
Un log es un registro oficial de eventos durante un rango de tiempo en particular. Para los profesionales en seguridad
informática se utiliza para registrar datos o información sobre quién, qué, cuándo, dónde y por qué un evento ocurre en un
dispositivo en particular o aplicación.
La mayoría de los logs son almacenados o desplegados en el formato estándar, el cual es un conjunto de caracteres para
dispositivos comunes y aplicaciones. De esta forma cada log generado por un dispositivo en particular puede ser leído y
desplegado en otro diferente.
También se le considera como aquel mensaje que genera el programador de un sistema operativo, alguna aplicación o algún
proceso, en virtud del cual se muestra un evento del sistema.
Objetivos
Garantizar la monitorización de los eventos que se producen en la aplicación
Asegurar la información de los ficheros de registro
Pautas
PAUT-0207 Archivos de registro Directriz Obligatoria
PAUT-0246 Denegación de servicio Directriz Obligatoria
LIBP-0275 Diseño del log Directriz Obligatoria
LIBP-0278 Información del log Directriz Recomendada
LIBP-0279 Manejo de los registros de auditoría Directriz Obligatoria
Recursos
RECU-0580 Generar trazas para la depuración en PHP Ejemplo Obligatorio
RECU-0579 Log de errores en PHP Manual Obligatorio
Seguridad
Servicios Web
Có digo : SEG_Servicios
Dada la particularidad de los servicios web, se ha creado este apartado para que, además de tener en cuenta todas las
indicaciones de seguridad dadas para el control de acceso y la autenticación, la codificación y validación de entrada/salida, el
cifrado, etc. se tengan en cuenta otras actuaciones concretas para garantizar la seguridad en el uso de servicios web: la
integridad, el no repudio y la confidencialidad de los mensajes, así como habilitar mecanismos para la identificación y
autorización de servicios y usuarios.
12
Un Servicio Web es una aplicación que reside en un servidor centralizado y que utiliza una serie de protocolos estándares
controlados por las organizaciones W3C, OASIS y el organismo WS-I como, por ejemplo, Simple Object Access
Pro to co l (SOAP), Web Service Definitio n Language (WSDL) y Universal Descriptio n Disco very and
Integratio n (UDDI), para intercambiar datos e información entre otras aplicaciones, independientemente del lenguaje de
programación en el que estén desarrolladas y de la plataforma dónde se ejecuten.
W3C (World Wide Web Consortium) y OASIS (Organization for the Advancement of Structured Information Standards) son
los comités responsables de la arquitectura y reglamentación de los Servicios Web.
WS-I es el organismo creado para mejorar la interacción y operatividad entre diferentes implementaciones de Servicios
Web.
Un Servicio Web dispone de un interfaz público (API) descrito en un formato procesable por cualquier equipo o sistema
llamado WSDL. WSDL es, además, el lenguaje de programación de esa interfaz pública que está basado en XML y contiene
los requisitos funcionales necesarios para establecer una comunicación con el Servicio Web. El proveedor de los servicios es
responsable de establecer y publicar los requisitos de seguridad que crea adecuados para proteger su servicio.
Un equipo cliente que se conecta a un Servicio Web puede leer ese fichero WSDL para determinar qué funciones están
disponibles en el servidor. Los tipos de datos especiales se incluyen dentro del archivo WSDL en forma de XML Schema y el
cliente utiliza SOAP para hacer la llamada a una de las funciones listadas en el WSDL.
SOAP es el protocolo que define cómo se establece el intercambio de información mediante XML
UDDI es el protocolo empleado para publicar la información del Servicio Web y que permite comprobar qué Servicios Web
están disponibles.
Los Servicios Web se utilizan normalmente bajo el protocolo HTTP o HTTPS en los puertos TCP 80 y 443, respectivamente.
Desde el punto de vista de la seguridad, un Servicio Web presenta los mismos problemas que cualquier otra aplicación Web
presente y accesible por Internet:
Robo de sesiones
SQL Injection
XML Injection
XPATH Injection
Denegación de Servicio (DoS)
Cross Site Scripting (XSS)
Errores de configuración
etc.
Los archivos XML que conforman la estructura de los ficheros WSDL y mensajes SOAP, que se utilizan en el funcionamiento
de un Servicio Web, se intercambian entre el equipo cliente del usuario, el servidor frontal Web y el servidor de aplicaciones en
forma de formularios en una petición SOAP.
Incluso se ejecutan en el servidor Web y son una puerta de entrada para diferentes ataques y vulnerabilidades Web. Es
importante destacar que casi todos los Servicios Web están conectados a bases de datos.
Objetivos
Utilizar políticas de seguridad en el diseño y codificación de servicios web
Garantizar la disponibilidad de los servicios web
Asegurar que las transacciones en los servicios web se realizan
Garantizar la identidad y privilegios en la utilización de los servicios web
Pautas
PAUT-0280 Autenticación de usuarios Directriz Recomendada
LIBP-0282 Autenticación entre servicios Directriz Obligatoria
LIBP-0308 Confidencialidad e Integridad Directriz Recomendada
LIBP-0283 Definición de políticas Directriz Obligatoria
LIBP-0284 No repudio Directriz Obligatoria
Recursos
RECU-0211 Conceptos de seguridad en los servicios WEB Especificación Recomendado
13
RECU-0598 WS-Addressing Especificación Recomendado
RECU-0597 WS-Policy Especificación Recomendado
RECU-0217 WS-Security Especificación Recomendado
Seguridad
Rendimiento
Có digo : DES_RENDIMIENTO
En informática entendemos el rendimiento como la medida o cuantificación de la velocidad/resultado con que se realiza una
tarea o proceso. En una computadora, su rendimiento no depende sólo del microprocesador como suele pensarse, sino de la
suma de sus componentes, sus softwares y la configuración de estos.
Las mediciones de rendimiento pueden estar orientadas al usuario (tiempos de respuesta) o hacia el sistema (utilización de la
recursos).
Las siguientes mediciones son probabilísticas y se consideran como variables aleatorias en estudio de simulación.
Tiempo de respuesta: tiempo que transcurre desde la entrega del trabajo hasta que regresa al usuario
Tiempo de reacció n del sistema: tiempo que transcurre desde que se da la orden hasta que empieza a ejecutarse
Otras medidas de rendimiento son:
Capacidad de ejecució n: cantidad de trabajo ejecutado por unidad de tiempo
Carga de trabajo : cantidad de trabajo con la que el sistema es capaz de procesar de manera aceptable, sin que se vean
afectados los tiempos de respuesta
Capacidad: medida de la capacidad del rendimiento máxima que un sistema puede tener siempre que este pueda aceptar
más carga de trabajo
Al igual que la Seguridad de las Aplicaciones, la temática de rendimiento debe ser contemplada desde el inicio del Diseño de
los Sistemas de Información. En este sentido, se incorporará bajo este apartado las directrices que permitan alinear las
infraestructuras y necesidades específicas de los Sistemas de Información objeto de desarrollo, con las directrices y
recomendaciones de esta área.
Pautas
LIBP-0343 Búsquedas en Drupal Directriz Recomendada
PAUT-0308 Compresión de páginas Directriz Obligatoria
LIBP-0341 Configuración de bases de datos Oracle Directriz Recomendada
Configuración de la conexión de la base de
datos
Rendimiento de las consultas a la base de
datos
LIBP-0071 Rendimiento de los Servicios Web Directriz Obligatoria
LIBP-0334 Optimización del código Directriz Obligatoria
PAUT-0306 Rendimiento frente a Seguridad Directriz Recomendada
PAUT-0309 Tabla de sesiones Directriz Recomendada
Recursos
RECU-0719 Database Buffer Caché Referencia Recomendado
RECU-0718 Particionado de Tablas Técnica Obligatorio
RECU-0720 Índices en consultas Ejemplo Obligatorio
RECU-0721 Shared Pool Referencia Recomendado
RECU-0218 Manejo del pool de conexiones Referencia Recomendado
RECU-0725 db_block_checksum Referencia Recomendado
RECU-0726 Optimización de código Ejemplo Obligatorio
Rendimiento aplicando directivas de seguridad en
RECU-0221 Experiencia Recomendado
servicios WEB
RECU-0267 PHP Quick Profiler Ficha Técnica Recomendado
RECU-0268 Quercus Ficha Técnica Recomendado
RECU-0765 Compresión de páginas en PHP Ejemplo Obligatorio
14
RECU-0698 Consulta de validación Referencia Recomendado
RECU-0699 Configuración de consulta de validación en Hibernate Referencia Recomendado
RECU-0700 Configuración de consulta de validación en iBatis Referencia Recomendado
RECU-0701 Configuración de consulta de validación en MyBatis Referencia Recomendado
RECU-0788 Poda de la tabla de sesiones en Drupal Ejemplo Recomendado
RECU-0882 Matriz de verificación de rendimiento Plantilla Recomendado
Librerías y Módulos
Có digo : DES_LIB_UTI
El objetivo de esta área temática busca establecer un catálogo de librerías o elementos software reutilizables para los lenguajes
Java, PHP o Drupal. Además, para cada una de estas librerías se proporciona una descripción y unas normas o recomendaciones
de uso.
Se ofrece, principalmente, un catálogo que cubre los principales aspectos funcionales de un desarrollo. Para ello se han escogido
las librerías más reconocidas dentro de la comunidad de desarrollo, tanto Java como PHP y Drupal, con el objetivo de mejorar la
eficiencia y rendimiento de las aplicaciones desarrolladas bajo este marco.
Este área está relacionada con el área Repositorio de Artefactos, del subsistema Entorno, de MADEJA.
Pautas
Java

LIBP-0344 Librerías para aplicaciones Java Directriz Recomendada
LIBP-0348 Librerías para el tratamiento de XML en Java Directriz Recomendada
PHP

LIBP-0350 Librerías para aplicaciones PHP Directriz Recomendada
LIBP-0351 Módulos para Drupal Directriz Recomendada
Recursos
Módulos para Drupal

RECU-0282 ACL Ficha Técnica Recomendado
RECU-0289 Backup and Migrate Ficha Técnica Recomendado
RECU-0769 CacheRouter Ejemplo Obligatorio
RECU-0296 CAPTCHA Ficha Técnica Recomendado
RECU-0297 CCK Ficha Técnica Recomendado
RECU-0294 Classroom Ficha Técnica Recomendado
RECU-0685 Comandos Drush para la administración de Drupal Referencia Recomendado
RECU-0285 Data Ficha Técnica Recomendado
RECU-0280 Devel Ficha Técnica Recomendado
RECU-0283 FileField Ficha Técnica Recomendado
RECU-0281 GraphMind Ficha Técnica Recomendado
RECU-0292 Hierarchical Select Ficha Técnica Recomendado
RECU-0293 ImageCache Ficha Técnica Recomendado
RECU-0684 Instalación de Drush Referencia Recomendado
RECU-0301 Internationalization Ficha Técnica Recomendado
RECU-0287 Pathauto Ficha Técnica Recomendado
RECU-0300 Print Ficha Técnica Recomendado
RECU-0298 Quiz Ficha Técnica Recomendado
RECU-0284 Schema Ficha Técnica Recomendado
RECU-0286 SimpleTest Ficha Técnica Recomendado
RECU-0291 Site Map Ficha Técnica Recomendado
RECU-0295 Storm Ficha Técnica Recomendado
15
RECU-0290 Taxonomy Ficha Técnica Recomendado
RECU-0288 Token Ficha Técnica Recomendado
RECU-0299 Views Ficha Técnica Recomendado
Librerías para el Tratamiento de XML

RECU-0230 API JDK javax.xml Ficha Técnica Recomendado
RECU-0740 DOM Ficha Técnica Recomendado
RECU-0231 JAXB Ficha Técnica Recomendado
RECU-0228 JDom Ficha Técnica Recomendado
RECU-0233 JiBX Ficha Técnica Recomendado
RECU-0741 SAX Ficha Técnica Recomendado
RECU-0229 Xalan Ficha Técnica Recomendado
RECU-0227 Xerces2 Ficha Técnica Recomendado
RECU-0234 XMLBeans Ficha Técnica Permitido
RECU-0744 XML Schema Ficha Técnica Recomendado
RECU-0743 XSLT Ficha Técnica Recomendado
RECU-0232 XStream Ficha Técnica Recomendado
Librerías para Seguridad

RECU-0235 Bouncy Castle Ficha Técnica Recomendado
RECU-0236 Spring Security Ficha Técnica Recomendado
Librerías para Logging

RECU-0225 Commons Logging Ficha Técnica Recomendado
RECU-0226 Log4j Ficha Técnica Recomendado
Librerías para Pruebas

RECU-0249 DBUnit Ficha Técnica Recomendado
RECU-0247 JSFUnit Ficha Técnica Recomendado
RECU-0248 JUnit Ficha Técnica Recomendado
RECU-0273 PHPUnit Ficha Técnica Recomendado
Librerías para Generación de Informes

RECU-0276 FPDF Ficha Técnica Recomendado
RECU-0886 Google Chart Ficha Técnica No recomendado
RECU-0238 IReport Ficha Técnica Recomendado
RECU-0239 IText Ficha Técnica Recomendado
RECU-0237 JasperReports Ficha Técnica Recomendado
RECU-0240 JFreeChart Ficha Técnica Recomendado
RECU-0275 JpGraph Ficha Técnica Recomendado
RECU-0274 PHPExcelReader Ficha Técnica Recomendado
RECU-0241 POI Ficha Técnica Recomendado
Librerías para Comunicaciones

RECU-0245 GeoTools Ficha Técnica Recomendado
RECU-0243 HttpComponents Ficha Técnica Recomendado
RECU-0242 JavaMail Ficha Técnica Recomendado
RECU-0244 OpenLayers Ficha Técnica Recomendado
RECU-0278 PHPMailer Ficha Técnica Recomendado
RECU-0246 Smack API Ficha Técnica Recomendado
16
Librerías para la Construcción de Aplicaciones

RECU-0277 PEAR Ficha Técnica Recomendado
RECU-0269 Librería estándar de PHP Ficha Técnica Recomendado
RECU-0272 Smarty Ficha Técnica Recomendado
RECU-0271 Spoon Ficha Técnica Recomendado

RECU-0883 Matriz de verificación de librerías y módulos Plantilla Recomendado
Patrones de Diseño
Có digo : PATRONES_DIS
Los patrones de diseño aportan una posible solución a un problema concreto, usualmente relacionado con la estructura básica
de una aplicación. Teniendo en cuenta las características de la aplicación a desarrollar y el tipo de problemas detectados durante
el diseño de dicha aplicación, es posible determinar qué patrón de diseño será el más apropiado para resolver dichos
problemas.
Al plantear el diseño de una aplicación pueden surgir problemas relacionados con la funcionalidad a desarrollar o con la relación
con otras aplicaciones. Para solucionar estos problemas MADEJA recomienda el empleo de patrones de diseño, que son
soluciones ya probadas a estos tipos de problemas, de efectividad comprobada y reutilizables.
Objetivos
Enumerar los patrones de diseño recomendados en cada caso que se pueda plantear
Establecer los patrones de diseño en J2EE en función de la capa del desarrollo afectada: presentación, negocio o
persistencia
Pautas
PAUT-0318 Antipatrones de Diseño Directriz Recomendada
LIBP-0342 Uso de Patrones de diseño Directriz Recomendada
LIBP-0358 Uso de Patrones de diseño en J2ME Directriz Recomendada
Capa de presentación

Uso de Patrones J2EE de la Capa de
Presentación
Capa de negocio

LIBP-0347 Uso de Patrones J2EE de la Capa de Negocio Directriz Recomendada
Capa de persistencia

Uso de Patrones J2EE de la Capa de
Persistencia
Recursos
RECU-0013 Patrones de diseño Ficha Recomendado
RECU-0181 Adaptador Patrón Recomendado
RECU-0182 Cadena de Responsabilidades Patrón Recomendado
RECU-0183 Comando Patrón Recomendado
RECU-0184 Composite Patrón Recomendado
RECU-0185 Constructor Patrón Recomendado
RECU-0186 Decorador Patrón Recomendado
RECU-0187 Estado Patrón Recomendado
RECU-0188 Estrategia Patrón Recomendado
RECU-0189 Fachada Patrón Recomendado
17
RECU-0190 Factoría Patrón Recomendado
RECU-0191 Factoría Abstracta Patrón Recomendado
RECU-0192 Intérprete Patrón Recomendado
RECU-0193 Iterador Patrón Recomendado
RECU-0194 Mediador Patrón Recomendado
RECU-0195 Memento Patrón Recomendado
RECU-0196 Observador Patrón Recomendado
RECU-0197 Peso Ligero Patrón Recomendado
RECU-0198 Plantilla Patrón Recomendado
RECU-0199 Prototipo Patrón Recomendado
RECU-0200 Proxy Patrón Recomendado
RECU-0201 Puente Patrón Recomendado
RECU-0202 Singleton Patrón Recomendado
RECU-0203 Visitor Patrón Recomendado
RECU-0014 Wizard Ficha Recomendado
Especificación de los Antipatrones de diseño de
Desarrollo
Especificación de los Antipatrones de diseño de
Arquitectura de Software
RECU-0208 Patrones de diseño de J2ME Referencia Recomendado
RECU-0257 Aplicación del patrón MVC en PHP Referencia Recomendado
RECU-0122 Patrón Modelo Vista Controlador Patrón Recomendado
RECU-0884 Matriz de verificación de patrones de diseño Plantilla Recomendado
Capa de presentación

RECU-0113 Intercepting Filter Patrón Recomendado
RECU-0114 Front Controller Patrón Recomendado
RECU-0118 Service To Worker Patrón Recomendado
RECU-0119 View Helper Patrón Recomendado
RECU-0120 Composite View Patrón Recomendado
RECU-0121 Dispatcher View Patrón Recomendado
Capa de negocio

RECU-0146 Business Delegate Patrón Recomendado
RECU-0147 Service Locator Patrón Recomendado
RECU-0148 Session Facade Patrón Recomendado
RECU-0149 Value List Handler Patrón Recomendado
RECU-0150 Transfer Object Patrón Recomendado
RECU-0167 Composite Entity Patrón Recomendado
RECU-0168 Transfer Object Assembler Patrón Recomendado
Capa de persistencia

RECU-0174 Data Access Object Patrón Recomendado
RECU-0175 Service Activator Patrón Recomendado
Source URL: http://madeja.i-administracion.junta-andalucia.es/servicios/madeja/contenido/subsistemas/desarrollo
18
Interfaz de usuario
Este subsistema se centra en la definición de las pautas y condiciones que deben cumplir los sistemas de la Junta de Andalucía
en cuanto a su interacción con los usuarios.
Los objetivos a cubrir por el subsistema son:
Usabilidad y uniformidad de las aplicaciones, destacando los aspectos de disposición y navegación sobre los meramente de
estilo. Se incluyen los mecanismos y modelos de manipulación de la información.
Accesibilidad de las aplicaciones, en cumplimiento de las normativas y estándares internacionales y propios de la Junta de
Andalucía.
Reducción de los costes del desarrollo accesible y usable, en aplicación de los principios de este subsistema.
Fundamentalmente mediante la reutilización de los elementos de diseño y los propios componentes que los generan.
Usabilidad
Có digo : Usabilidad
En este área se establecen las pautas, procedimientos y recursos para asegurar una adecuada usabilidad de las aplicaciones
desarrolladas bajo el marco de MADEJA.
La Usabilidad mide la calidad de la experiencia del usuario al interactuar con un producto o sistema, ya sea un sitio web, una
aplicación de software, tecnología móvil o cualquier dispositivo de usuario. Según la ISO 9241-11, la Usabilidad puede definirse
como “la medida en la que un producto puede ser utilizado por diferentes usuarios para conseguir objetivos específicos con
efectividad, eficiencia y satisfacción en un contexto de uso concreto“.
Objetivos
Reducción de los costes de aprendizaje
Disminución de los costes de asistencia y ayuda al usuario.
Disminución en la tasa de errores cometidos por el usuario.
Aumento de la satisfacción y comodidad del usuario.
Mejora la imagen y el prestigio.
Mejora la calidad de vida de los usuarios, ya que incrementa la satisfacción y la productividad.
Recursos
RECU-0151 Información general sobre usabilidad Referencia Recomendado
RECU-0539 Usabilidad - Aplicación del principio de Pareto Técnica Recomendado
usable usabilidad interfaz interaccion personas ordenador
Usabilidad General – Interacción Personas Ordenador (IPO)

Có digo : usabilidad_general
Área que trata la interacción entre personas y ordenadores con el objetivo de mejorar el intercambio de información entre
ambos, consiguiendo los beneficios de la usabilidad. Se incluyen pautas para cumplir los objetivos de un intercambio de
información más eficiente: minimizar errores, incrementar la satisfacción, etc. Se tienen en cuenta elementos como una
jerarquía visual clara, mostrar información de la ubicación del usuario en todo momento, un diseño similar en toda la aplicación y
existencia de una navegación global.
Objetivos
Eficiencia. Relacionada con el tiempo y esfuerzo que realiza el usuario para llegar a su objetivo. La eficiencia depende de la
facilidad de aprendizaje, que es una medida del tiempo requerido para trabajar con facilidad con una herramienta, y de
alcanzar una retención de estos conocimientos tras cierto tiempo de usar la herramienta o sistema. Es decir, cuanto menos
tiempo necesite un usuario para aprender a usar una aplicación, más eficiente será el uso de ésta.
Fidelización. Se da a través de la creación de una aplicación dinámica y con contenidos que susciten el interés de los
distintos usuarios. El objetivo es que el usuario encuentre ventajas y beneficios para sus tareas en el uso de la aplicación;
1
esto hará que haga de ella una herramienta de trabajo de uso frecuente.
Perdurabilidad. Los diseños para aplicaciones deben prescindir de modas tendenciosas que rápidamente quedan
obsoletas. El diseño debe ser corporativo y consistente. Deberá ser coherente con la identidad global de la entidad.
Reducción de errores. Una herramienta muy fácil de usar permitirá a su usuario efectuar más operaciones por unidad de
tiempo, o consumir menos tiempo para la misma operación, disminuyendo la probabilidad de que ocurran errores.
Pautas
LIBP-0031 Jerarquía visual clara Directriz Obligatoria
LIBP-0032 Navegación Directriz Obligatoria
LIBP-0033 Contenidos Directriz Obligatoria
LIBP-0034 Formularios Directriz Obligatoria
LIBP-0035 Búsqueda y filtro de contenidos Directriz Obligatoria
Recursos
RECU-0157 Asociación Interacción Persona-Ordenador Referencia Recomendado
RECU-0386 Informe de corrección - STILUS Herramienta Recomendado
usable usabilidad interacción persona ordenador
Usabilidad en aplicaciones web

Có digo : USA_APLW
Área que ofrece información para asegurar el desarrollo de interfaces usables en aplicaciones web. Alberga un conjunto de
pautas que tienen en cuenta elementos desde el acceso a la aplicación, hasta conseguir que la aplicación sea más eficiente,
pasando por una navegación rápida e intuitiva y por la forma de mostrar los contenidos.
Este área co mplementa la info rmació n o frecida en Usabilidad General - Interaccio n Perso nas Ordenado r.
Objetivos
Eficiencia. Relacionada con el tiempo y esfuerzo que realiza el usuario para llegar a su objetivo. La eficiencia depende de la
facilidad de aprendizaje, que es una medida del tiempo requerido para trabajar con facilidad con una herramienta, y de
alcanzar una retención de estos conocimientos tras cierto tiempo de usar la herramienta o sistema. Es decir, cuanto menos
tiempo necesite un usuario para aprender a usar una aplicación, más eficiente será el uso de ésta.
Fidelización. Se da a través de la creación de una aplicación dinámica y con contenidos que susciten el interés de los
distintos usuarios. El objetivo es que el usuario encuentre ventajas y beneficios para sus tareas en el uso de la aplicación;
esto hará que haga de ella una herramienta de trabajo de uso frecuente.
Perdurabilidad. Los diseños para aplicaciones deben prescindir de modas tendenciosas que rápidamente quedan
obsoletas. El diseño debe ser corporativo y consistente. Deberá ser coherente con la identidad global de la entidad.
Reducción de errores. Una herramienta muy fácil de usar permitirá a su usuario efectuar más operaciones por unidad de
tiempo, o consumir menos tiempo para la misma operación, disminuyendo la probabilidad de que ocurran errores.
Pautas
LIBP-0036 Acceso a la aplicación Directriz Obligatoria
LIBP-0037 Navegación Directriz Obligatoria
LIBP-0041 Contenidos Directriz Obligatoria
PAUT-0037 Eficiencia Directriz Recomendada
PAUT-0038 Consistencia Directriz Obligatoria
LIBP-0045 Búsqueda y filtro de contenidos Directriz Recomendada
LIBP-0235 Listados Directriz Obligatoria
Recursos
RECU-0153 Desarrollo de aplicaciones Web Referencia Recomendado
RECU-0164 Pingdom Tools Herramienta Recomendado
RECU-0165 Page Speed Herramienta Recomendado
2
RECU-0166 YSlow Herramienta Recomendado
web usabilidad
Accesibilidad
Có digo : Accesibilidad
La accesibilidad es el grado en el que todas las personas pueden utilizar un objeto, visitar un lugar o acceder a un servicio,
independientemente de sus capacidades técnicas, cognitivas o físicas. La accesibilidad web se refiere a la capacidad de acceso
a la Web y a sus contenidos por todas las personas independientemente de la discapacidad (física, intelectual o técnica) que
presenten o de las que se deriven del contexto de uso (tecnológicas o ambientales). En este área se ofrece un conjunto de
pautas y recursos que ofrecen información para desarrollar de interfaces web accesibles.
La incorporación de los contenidos de Accesibilidad Web en MADEJA se basará fundamentalmente en la adaptación de las pautas
propuestas por el W3C (World Wide Web Consortium), iniciativa Web Accessibility Initiative (WAI), con objetivo de facilitar el
acceso a las personas con discapacidad y a las que poseen dificultades de acceso debido a limitaciones tecnológicas. Para esto
se desarrollarán pautas de accesibilidad y se ofrecerán herramientas para la evaluación y reparación de accesibilidad Web.
Objetivos
Lograr que las aplicaciones sean utilizables por el mayor número de personas posibles, independientemente de la
discapacidad (física, intelectual o técnica) que puedan presentar o de las que se deriven del contexto de uso (tecnológicas o
ambientales).
Recursos
RECU-0115 Evaluación de accesibilidad - AChecker Herramienta Recomendado
RECU-0254 Inspector de accesibilidad - aInspector Herramienta Recomendado
RECU-0306 WAI-ARIA - Juicy Studio Accessibility Toolbar Herramienta Recomendado
RECU-0380 Servicios accesibilidad - TAW Herramienta Recomendado
RECU-0382 Accesibilidad - Pista Herramienta Recomendado
RECU-0383 Accesibilidad - HERA FFX Herramienta Recomendado
RECU-0384 Accesibilidad - Total Validator Herramienta Recomendado
RECU-0387 Accesibilidad - aDesigner Herramienta Recomendado
RECU-0117 Legislación sobre accesibilidad Legislación Recomendado
RECU-0116 Discapacidad y Accesibilidad en la Red Referencia Recomendado
RECU-0489 Photosensitive Epilepsy Analysis Tool Herramienta Recomendado
RECU-0517 Accesibilidad - eXaminator Herramienta Recomendado
RECU-0518 Pdf Accessibility Checker Herramienta Recomendado
RECU-0540 Accesibilidad - Aplicación del principio de Pareto Técnica Recomendado
interfaz acceso accesibilidad
Accesibilidad en aplicaciones web (WCAG)

Có digo : accesibilidad_aplicaciones_web
Las pautas de accesibilidad al contenido web (Web Content Accessibility Guidelines - WCAG) son unos documentos que
explican cómo hacer el contenido Web accesible para personas con discapacidad. Cuando se habla de contenido se refiere a
la información en una página web o aplicación, incluyendo texto, imágenes, formas, sonidos, etc. En la actualidad existen dos
conjuntos de pautas de accesibilidad de contenidos Web: WCAG1.0 y WCAG2.0. Estos dos conjuntos están organizados y
estructurados de diferente forma:
WCAG1.0. Son 14 pautas que engloban los principios generales del diseño accesible. En total poseen 65 puntos de
verificación y cada uno de ellos está asociado a una prioridad: Simple A, Doble A y Triple A.
WCAG2.0. Se organiza en cuatro principios fundamentales para la accesibilidad del contenido:
Perceptible
Operable
Comprensible
Robusto
Cada uno de estos principios tiene asociadas una o más pautas y en total forman 61 criterios de conformidad, organizados
según su nivel de cumplimiento asociado: Simple A, Doble A y Triple A.
Existe cierta equivalencia entre los puntos de verificación de WCAG1.0 y WCAG2.0 y con la Norma UNE 139803, que
3
actualmente regula el acceso de las personas con discapacidad a las tecnologías, productos y servicios relacionados con la
Sociedad de la Información y medios de comunicación social. A pesar de que esta norma es compatible las pautas WCAG1.0,
existe una petición por parte de AENOR de que se actualice la regulación existente con las pautas WCAG2.0, por lo que será en
las que se base el presente texto.
En las WCAG2.0 existen tres niveles de conformidad:
Existen tres niveles de conformidad:
WCAG 2.0 Nivel A: para lograr conformidad con el Nivel A (el mínimo), la página web debe satisfacer todos los Criterios
de Conformidad del Nivel A, o proporcionar una versión alternativa conforme.
WCAG 2.0 Nivel AA: para lograr conformidad con el Nivel AA, la página web debe satisfacer todos los Criterios de
Conformidad de los Niveles A y AA, o proporcionar una versión alternativa conforme al Nivel AA.
WCAG 2.0 Nivel AAA: Para lograr conformidad con el Nivel AAA, la página web debe satisfacer todos los Criterios de
Conformidad de los Niveles A, AA y AAA, o proporcionar una versión alternativa conforme al Nivel AAA.
Además, existen las siguientes especificaciones:
El nivel de conformidad es para páginas completas, no para fragmentos de ella.
Cuando varias páginas forman parte de un proceso, todas las páginas implicadas deben ser conformes con el nivel
especificado o un nivel superior.
Si una aplicación está implementada en una tecnología que no es compatible con las pautas de accesibilidad, debe
proporcionarse una versión que sí lo sea.
Si una página posee una tecnología que no es compatible con la accesibilidad o no es conforme con cierto nivel, no debe
impedir el acceso al contenido del resto de la página.
La declaración de conformidad es opcional, pero si se añade debe incluir la siguiente información:

1. Fecha de la declaración de conformidad
2. Título, versión y URI de las Pautas: "Web Content Accessibility Guidelines 2.0 en http://www.w3.org/TR/WCAG20/"
3. Nivel de conformidad: A, AA o AAA
4. Listado de las páginas que están incluidas en la declaración de conformidad
5. Listado de tecnologías de contenido web de las que se depende (se recomienda un enlace al software concreto)
Si se emplea un logo de conformidad, éste constituye una declaración y debe ir acompañado de todos los componentes
requeridos para la conformidad.
Aquí describen las pautas que debe adoptar una web para cumplir con los niveles de accesibilidad.
Objetivos
Independencia tecnológica. Se pretende conseguir que sean aplicables sobre diferentes tecnologías. El W3C promueve un
buen número de tecnologías para la Web y estas pautas deben ser de aplicación a todas ellas, ya sean presentes o
futuras. Para cumplir con este objetivo, las Pautas deben ser lo suficientemente genéricas y es por ello que esta nueva
versión conlleva un mayor grado de abstracción que los anteriores respecto a cuestiones técnicas.
Claridad en los requisitos. Se busca una mayor claridad en cuanto a los requisitos a cumplir, ya que en vistas a una
valoración objetiva de la accesibilidad es importante establecer de forma lo más precisa posible cuáles son los requisitos
mínimos exigibles. De esta manera, se pretende conseguir que varias herramientas y/o personas puedan llegar a alcanzar
una misma conclusión partiendo del mismo análisis.
Aumento de la audiencia. Las WCAG 2.0 pretenden conseguir el mayor grado de difusión de la accesibilidad posible,
identificando con claridad los beneficios y beneficiarios del diseño accesible.
Pautas
LIBP-0077 Simple A Directriz Obligatoria
LIBP-0078 Doble A Directriz Obligatoria
LIBP-0079 Tiple A Directriz Obligatoria
Recursos
RECU-0253 Pautas WCAG2.0 Referencia Recomendado
RECU-0250 Validador de contenidos Herramienta Recomendado
RECU-0251 Contraste de color Herramienta Recomendado
Accesibilidad en aplicaciones web enriquecidas (WAI-ARIA)

Có digo : WAI_ARIA
4
WAI-ARIA es una iniciativa del W3C que define cómo hacer accesibles contenidos y aplicaciones web, específicamente el
contenido dinámico y los controles avanzados de interfaz desarrollados con Ajax y tecnologías relacionadas.
Desde su aparición, las páginas web han sufrido cambios en cuanto a su objetivo y estructura. En un primer momento, el
lenguaje HTML (Hyper Text Markup Language) fue concebido para la presentación de documentos con hiperenlaces pero
posteriormente han surgido nuevas necesidades que han convertido estas páginas en documentos más complejos y más
parecidos a las aplicaciones de escritorio.
Se ha incorporado una nueva tipología de contenido más dinámico, caracterizado por la presentación y las actualizaciones de
datos del lado del cliente con tecnologías como AJAX (Asyncronous JavaScript And XML). El W3C (World Wide Web
Consortium), atendiendo a tales necesidades, ha propuesto una vía para conseguir que este tipo de tecnología sea accesible;
su propuesta es WAI ARIA (Web Accessibility Initiate Accessible Rich Internet Application).
WAI ARIA es una tecnología que tiene como principal objetivo aportar información acerca de las diferentes partes que
constituyen los contenidos dinámicos generados, normalmente, por medio de scripts. Toda esta información será utilizada por
los productos de apoyo para la interacción con el usuario final. Para realizar esta tarea se basa en una serie de atributos que
funcionan como identificadores de las diferentes partes de la aplicación que interactúa con el usuario. Dispone de roles que
describen tanto los widgets (componentes con funcionalidad propia de las interfaces de escritorio o web) de la aplicación
como la estructura de la página web, como por ejemplo los encabezados y las regiones. También dispone de varias
propiedades como los estados de los widgets, las regiones activas de actualización de contenidos y sobre características
drag-and-drop. A su vez, provee una manera de navegar mediante teclado dentro de los componentes.
Ventajas
Al añadir valor semántico al contenido y a los widgets se puede situar al usuario exactamente en donde está.
Las actualizaciones de contenido dinámico, normalmente realizado con tecnologías de script, son notificadas al usuario por
medio de su producto de apoyo.
Accesibilidad de los widgets por medio del teclado.
Se dota de información de cómo se utiliza un widget y qué tipo de datos proporciona.
Inco nvenientes
Al aplicar esta tecnología, los documentos web que se desarrollen no validarán tanto en HTML 4 como en XHTML 1.0. El
primero no soporta espacio de nombres,por lo que no se podrán incluir los atributos específicos de WAI ARIA. Con XHTML
1.0, su validación no sería posible porque no estaría incluido en el esquema que define al lenguaje.Para solucionar este
inconveniente, existen dos posibles soluciones:
Incluir los atributos de WAI ARIA mediante DOM, es decir, incluir con JavaScript, dinámicamente, los atributos en los
elementos destinados a ellos. Dicha solución haría dependiente de la tecnología script cualquier tipo de
implementación.
Utilización de XHTML 1.1. Este lenguaje es una especificación de lenguaje modular y extensible que permitiría
personalizar el DTD incorporando el esquema de WAI ARIA. DTD: "http://www.w3.org/WAI/ARIA/schemata/xhtml-aria-
1.dtd"
Características de WAI ARIA

WAI ARIA describe roles y propiedades con la finalidad de dotar de información a los productos de apoyo y de que interactúen
adecuadamente con los componentes más normales de las aplicaciones web.
Roles. Los roles pueden ser de dos tipos:
Describen el tipo de widget del que se trata. Los widgets pueden ser de varios estilos, desde menús desplegables en
forma de árbol, hasta sliders, pasando por barras de medición de progreso.
Aquel que define la estructura de la página web. Estos roles pueden definir elementos de encabezado o incluso tablas
o grid. Es muy común definir diferentes regiones.
Estados y propiedades. Las propiedades pretenden ser una guía a los productos de apoyo que proporciona información de
cómo interactuar con ciertos widgets que se encuentran en una página web. Existen estados y propiedades de carácter
global, es decir, pueden ser utilizados independientemente del elemento o del tipo de rol que tenga. Pero en la mayoría de
los casos la clasificación de los estados y propiedades viene distribuida de la siguiente forma:
Atributos Widget: específicos para las interfaces de usuario más comunes. Están orientados a componentes en los
que el usuario ha de introducir una entrada de datos para procesarla.
Atributos de regiones activas: son los destinados a las regiones activas, aquellas susceptibles de incorporar contenido
dinámico actualizable. Pueden ser aplicados a cualquier elemento.
Atributos de Drag and Drop: proporcionan información sobre los efectos Drag and Drop (arrastrar y soltar) que se
encuentran en algunas aplicaciones.
Atributos de relaciones: tienen la función de relacionar elementos que no se puede establecer mediante la estructura
del documento.
5
En este área se definen las pautas WAI-ARIA a las que hace referencia la norma WCAG2.0.
Objetivos
Aportar información acerca de las diferentes partes que constituyen los contenidos dinámicos generados, normalmente,
por medio de scripts. Toda esta información será utilizada por los productos de apoyo para la interacción con el usuario
final
Pautas
PAUT-0051 Propiedad aria-describedby Directriz Obligatoria
PAUT-0052 Propiedad aria-required Directriz Obligatoria
PAUT-0053 Propiedades aria-valuemin y aria-valuemax Directriz Obligatoria
Recursos
RECU-0303 Accessible Rich Internet Applications (WAI-ARIA) 1.0 Referencia Recomendado
RECU-0305 WAI-ARIA 1.0 Authoring Practices Ejemplo Recomendado
Accesibilidad para contenidos multimedia

Có digo : acc__contenidos_multimedia
Este área trata de proveer los conocimientos necesarios para desarrollar contenidos multimeda accesibles. Debido a su
difusión, se centra en los siguientes elementos: ficharos de audio, ficheros de vídeo y flash.
El término multimedia se utiliza para referirse a cualquier objeto o sistema que utiliza múltiples medios de expresión para
presentar o comunicar información. Los medios pueden ser varios, desde texto e imágenes, hasta animación, sonido, vídeo,
etc. En este área se presentan las pautas para hacer accesibles los elementos multimedia.
Dentro de los objetos multimedia encontramos:
1. Ficheros de audio, que pueden almacenarse en diferentes formatos y sus principales diferencias radican en los siguientes
aspectos
Capacidad de compresión: influye en la cantidad de almacenamiento requerido, muy importante cuando se presenta
multitud de archivos de audio.
Calidad: los formatos con pérdida de calidad comprimen más el fichero a cambio de una reproducción menos fiel.
Dependencia del software: existen formatos que pueden ser reproducidos por gran cantidad de software y otros que
están diseñados para utilizarse en uno concreto.
2. Vídeo. Cuando se utiliza en una aplicación, se deben tener en cuenta tres aspectos principales:
Tamaño del fichero: es importante un tamaño lo más reducido posible para incrementar la velocidad de carga. Sin
embargo existen formatos de vídeo que pueden ser visualizados directamente mientras son descargados, evitando
así tener que esperar hasta su descarga completa.
Resolución y calidad: el vídeo debe tener una calidad suficiente para transmitir la información que pretende.
Compatibilidad: un vídeo debe poder ser reproducido por la mayor cantidad de usuarios posibles, por lo que debe
tener un formato ampliamente difundido y aceptado.
3. Flash. ¿Por qué usar Flash?
Proporciona características multimedia completas
Para su reproducción requiere de un plugin ligero disponible en la mayoría de los equipos que tienen conexión a
intenernet
Compatible con casi todos los navegadores y sistemas operativos
Ha evolucionado para proveer componentes estandarizados y soluciones de comercio electrónico
Su respuesta a la Web 2.0: Adobe Flex
A partir de su versión 6 proporciona capacidades que pueden hacerlo accesible:
Todo el contenido es susceptible al uso de tecnologías asistivas
Sus componentes son accesibles a través de teclado
Accesibilidad para sus componentes interactivos
4. Imágenes. Existen muchas imágenes de diferentes tipos, pero sólo unos pocos son útiles en la web. Según la compresión,
existen dos tipos:
Con pérdidas: una vez que se descomprime no se obtiene imagen inicial, existe pérdida de calidad. Sin embargo, esto
sólo es visible en una mirada cercana. La compresión con pérdida es muy útil para la web, ya que proporciona una gran
reducción del peso de la imagen y agiliza la carga de la misma.
6
Sin pérdidas: al descomprimirla se obtiene una imagen exactamente igual que la original, aunque la reducción de peso
que proporcionan es mucho menor que con el tipo anterior.
5. PDF. Los documentos PDF necesitan visualizarse con aplicaciones externas a los navegadores Web. Es necesario
asegurarse que este tipo de documentos sigan siendo accesibles: deben poder manejarse de forma independiente del
tipo de dispositivo y deben ser compatibles con ayudas técnicas como los lectores de pantalla. Existen dos formas
principales de generar un pdf:
Documento escaneado: no es susceptible de ser accesible
Documento creado por procesadores de textos: sí puede ser accesible
Objetivos
Hacer que los contenidos en sí mismos sean accesibles.
Conseguir que la forma de llegar a los contenidos sea accesible.
Reproducir el contenido de forma accesible.
Pautas
LIBP-0191 Audio Directriz Obligatoria
PAUT-0057 Vídeo en formato FLV Directriz Recomendada
LIBP-0139 Contenido Flash Accesible Directriz Obligatoria
LIBP-0192 Imágenes Directriz Obligatoria
LIBP-0193 PDF Directriz Obligatoria
Recursos
RECU-0307 Comparativas de imágenes para la Web Referencia Recomendado
RECU-0309 Formatos de audio y video para la Web Referencia Recomendado
RECU-0312 Técnicas Flash para WCAG2.0 Referencia Recomendado
RECU-0313 Accesibilidad en PDF Referencia Recomendado
RECU-0519 OptiPNG Herramienta Recomendado
RECU-0525 JPEGMini Herramienta Recomendado
Interfaces adaptativos
Có digo : interfaces_adaptativos
Las interfaces adaptativas son aquellas que se adaptan a las diferencias o cambios existentes entre los usuarios. Un sistema
puede ser utilizado por diversos usuarios (y su perfil o nivel puede cambiar, puede necesitar más opciones o cubrir más
funciones), por eso sus interfaces se deberían ir adaptando a la situación que requiera la persona que las utiliza.
En la actualidad se está produciendo un cambio continuo en la interacción de los usuarios con sistemas informáticos. Cada día
se hace más necesario el uso de interfaces accedidas desde diferentes medios (ordenadores, móviles, cajeros, etc) por
personas con distintas necesidades y capacidades. A su vez, los sistemas informáticos son cada vez más completos, más
complejos y tienen mayor interacción con otros sistemas.
Aunque es posible llevar un desarrollo separado para cada familia de dispositivos, asumiendo el alto coste de desarrollo y
mantenimiento que ello supone, es todavía más difícil si no imposible diseñar interfaces de usuario para cada una las
situaciones en las que la interfaz de usuario puede ser potencialmente usada. Una solución más eficiente es la generación de
interfaces de usuario capaces de acomodarse a los distintos tipos de dispositivos, entornos de uso, e incluso tipos de
usuarios de forma automática, aunque ello supone sin duda la modificación de los actuales métodos de desarrollo de
interfaces de usuario.
La adaptatividad es la capacidad del sistema de adaptarse automáticamente al usuario, basado en información que obtiene
sobre el mismo.
Objetivos
Mejorar la eficacia y eficiencia de los sistemas informáticos
Extender el ciclo de vida, facilitando su mantenimiento
Extender el rango de usuarios, desde el novato al experto
Satisfacer las demandas del usuario, reduciendo temores y aumentando el atractivo y la flexibilidad, logrando así una mejor
aceptación
Incrementar la productividad
Reducir la curva de aprendizaje
Facilitar el uso a personas con discapacidades
7
Pautas
PAUT-0068 Hardware Consejo
PAUT-0069 Comunicaciones Consejo
PAUT-0070 Entrada y salida de datos Consejo
PAUT-0071 Usuario Consejo
PAUT-0072 Idioma Consejo
Recursos
RECU-0314 Desarrollo de interfaces adaptativas Referencia Recomendado
Buenas prácticas para elaborar contenidos alternativos

Có digo : elaborar_contenidos_alternativos
Área centrada en la realización de buenas prácticas de elaboración de contenido alternativo para elementos comunes en el
contenido web.
Objetivos
Conseguir que todo el contenido sin texto también esté disponible en texto, referido al texto electrónico, no a una imagen
de texto. El texto electrónico tiene la ventaja de que es una forma neutral que puede representarse de forma visual,
auditiva, por tacto o cualquier combinación de ellas.
Pautas
PAUT-0073 Contenido alternativo imágenes Directriz Obligatoria
PAUT-0074 Contenido alternativo multimedia Directriz Obligatoria
PAUT-0075 Controles de formulario Directriz Obligatoria
Recursos
RECU-0317 Uso del texto alternativo Referencia Recomendado
Herramientas de edición de contenidos (ATAG)

Có digo : atag
Las ATAG (Authoring Tool Accessibility Guidelines) o Pautas de Accesibilidad para Herramientas de Autor, son un conjunto de
normas que deben cumplir las herramientas de autor para ser accesibles y generar contenidos también accesibles. Estas
herramientas son software que se utiliza para crear páginas y contenido Web, siendo uno de los objetivos principales de las
ATAG definir la forma en la que las herramientas ayudan a los desarrolladores a producir contenido que cumpla las WCAG
(Pautas de Accesibilidad al Contenido en la Web).
Las pautas ATAG 2.0 dan las recomendaciones para que las herramientas de autor sean capaces de producir contenido web
que se ajuste a las WCAG 2.0, por lo que serán las pautas que se traten en este área.
Objetivos
Garantizar la accesibilidad de la herramienta de creación de interfaces de usuario de los autores con discapacidades.
Garantizar el apoyo de herramientas de autor para la creación de contenido web que sea accesible a los usuarios finales
con discapacidad.
Pautas
LIBP-0150 Herramienta accesible Directriz Obligatoria
LIBP-0151 Contenido accesible Directriz Obligatoria
Tecnologías y recursos
Có digo : Tecnologias_y_recursos
Área que recoge las tecnologías recomendadas para el desarrollo de contenidos web accesibles así como los requisitos
mínimos de los navegadores para su correcta visualización. Trata elementos como el tipo de documento, las hojas de estilos,
los navegadores web y la redifusión web.
8
1. Tipo de documento.
De acuerdo con las normas HTML, cada página requiere una declaración de tipo de documento. El "DOCTYPE" es la primera
declaración del documento y dice la versión de HTML/XHTML utilizada, para que pueda ser verificada por un validador y
controlar así la sintaxis del documento. El estándar que se utiliza se define utilizando un DTD (Definition Type Document),
que es una declaración del lenguaje. Dicho de otra manera, un DTD marca las reglas para la definición de un lenguaje y en el
Doctype se indica qué DTD se utiliza para interpretar el documento.
Ejemplo de uso:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-
transitional.dtd">
Donde:
"-//W3C//DTD XHTML 1.0 Transitional//EN": indica que el documento se valida con la especificación XHTML1.0 tipo
Transitional
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd": es la URL del DTD de validación"
2. Hojas de estilo.
Las hojas de estilo proporcionan un lenguaje usado para describir la semántica de la presentación (la apariencia y formato)
de un documento escrito en un lenguaje de marcas. Su aplicación más común es el estilo de las páginas web escritas en
HTML y XHTML, pero el lenguaje también se puede aplicar a cualquier tipo de documento XML, incluyendo SVG y XUL.
CSS está diseñado principalmente para permitir la separación del contenido de un documento (escrito en HTML o un
lenguaje de marcas similares) de la presentación del mismo. Esta separación puede mejorar la accesibilidad al contenido,
dar una mayor flexibilidad y control en la especificación de las características de presentación, permitir que varias páginas
compartan un formato y reducir su complejidad estructural (por ejemplo, al permitir el diseño de páginas web sin tablas ).
También puede permitir que una página que sea presentada con diferentes estilos para diferentes métodos de
representación: en la pantalla, impresión, por voz (cuando es leído por un navegador basado en el habla o lector de
pantalla ) y en Braille, en dispositivos táctiles, etc.
CSS especifica un esquema de prioridades para determinar qué reglas de estilo se aplican si existe más de una que
coincide para un elemento en particular. Por esto se llaman en cascada, porque las prioridades se calculan y asignan según
las normas de modo que los resultados sean predecibles. Define una serie de términos que permiten describir cada una de
las partes que componen los estilos CSS. Los diferentes términos se definen a continuación:
- Regla: cada uno de los estilos que componen una hoja de estilos CSS. Cada regla está compuesta de una parte de
selectores, un símbolo de llave de apertura "{", otra parte denominada declaración y por último, un símbolo de llave de
cierre "}".
- Selector: indica el elemento o elementos HTML a los que se aplica la regla CSS.
- Declaración: especifica los estilos que se aplican a los elementos. Está compuesta por una o más propiedades CSS.
- Propiedad: permite modificar el aspecto de una característica del elemento.
- Valor: indica el nuevo valor de la característica modificada en el elemento.
Un archivo CSS puede contener infinitas reglas CSS, cada regla puede contener infinitos selectores y cada declaración
puede estar formada por un número infinito de pares propiedad/valor.
3. Redifusión Web.
La redifusión web es el reenvío de contenidos desde una fuente original hasta otro destino que a su vez se puede convertir
en emisor, si pone a disposición de sus usuarios los contenidos a los que en un principio sólo se podía tener acceso en el
sitio web de origen. Cuando un proveedor publica un enlace, los usuarios finales pueden suscribirse con un programa
llamado lector de noticias que se ejecuta en sus propias máquinas. Estas aplicaciones comprueban la aparición de nuevos
contenidos de forma periódica, por lo que mantienen actualizados a los usuarios.
Los tipos de contenidos distribuidos suelen codificarse como XML aunque el formato puede ser cualquiera que pueda
transportarse por HTTP, como enlaces a páginas web y otros tipos de medios digitales. A menudo, cuando se
proporcionan vínculos para notificar actualizaciones de contenido, sólo se incluyen resúmenes en lugar del contenido
completo.
Para indicar la disponibilidad de la redifusión, se utiliza el siguiente icono:
Identifica al documento web como una fuente de contenidos.
Ventajas para el autor:

Integración con estándares
Facilita la suscripción de lectores
Facilita la redistribución
Ventajas para el lector:
No tiene la necesidad de realizar ninguna acción, sólo esperar actualizaciones
Integra contenidos externos en medios propios
Inconvenientes para el autor:
9
Estadísticas de lectura distorsionadas
Dificultades para controlar la situación de lectura y los usos posteriores del contenido
Inconvenientes para el lector:
Sobrecarga informativa
Dificultad para gestionar múltiples fuentes
4. Navegadores.
Un navegador web o explorador de Internet es una aplicación que permite recuperar y presentar las fuentes de información
almacenadas en servidores web. Una fuente de información se identifica mediante un identificador de recursos uniforme
(URI) y puede ser una página web , imagen, vídeo, u otra tipo de contenido. Los hipervínculos presentes en los recursos
permiten que los usuarios puedan navegar fácilmente con sus navegadores a los recursos relacionados.
Aunque los navegadores se destinan principalmente para acceder a la Web, también pueden utilizarse para acceder a la
información proporcionada por los servidores Web en redes privadas o archivos locales.
Objetivos
Seleccionar una declaración de tipo de documento o DOCTYPE.
Elegir una versión adecuada para las hojas de estilo.
Mostrar las diferencias entre los diferentes formatos de difusión Web y establecer un formato para las aplicaciones.
Mostrar los navegadores más utilizados, sus características y el cumplimiento que llevan a cabo de los estándares web.
Pautas
PAUT-0093 XHTML 1.1 Directriz Recomendada
PAUT-0094 CSS 2.1 Directriz Recomendada
PAUT-0095 Atom 1.0 Directriz Recomendada
PAUT-0092 Navegadores Web Directriz Recomendada
Recursos
RECU-0334 Validador de fuentes de redifusión Herramienta Recomendado
RECU-0335 Validador CSS Herramienta Recomendado
RECU-0336 Especificación y guía de referencia de CSS 2.1 Referencia Recomendado
RECU-0330 Mozilla Firefox Ficha Técnica Recomendado
RECU-0331 Opera Ficha Técnica Recomendado
RECU-0332 Google Chrome Ficha Técnica Recomendado
RECU-0333 Safari Ficha Técnica Recomendado
Normalización de Interfaces
Có digo : normalizacion_interfaces
El objetivo de este área es el de establecer un esquema general de las aplicaciones que sean desarrolladas bajo las directrices
de MADEJA. Se proporcionarán prototipos de pantallas esquematizadas para normalizar la distribución de los elementos visuales
y componentes dinámicos en las pantallas de las aplicaciones.
Se incluyen guías de decisión para la implantación tanto de los prototipos planteados como para el uso de los componentes de
interfaz normalizados por el SIU. Adicionalmente, se dispone de recursos descargables para su implantación directa: elementos
gráficos, arquetipos maven, etc.
Respecto a los estilos, para aquellos elementos que puedan ser personalizados, se indicarán las recomendaciones y
restricciones para su contextualización, de manera que se disponga de un manual de estilo que normalice y homogeneice las
diferentes aplicaciones de la Junta de Andalucía que hagan uso de MADEJA, pero que permita personalizar las aplicaciones en
base al organismo que hace uso de él y en base al Sistema de Información para el que sea utilizado.
Objetivos
Estandarizar el esquema general de las aplicaciones que sean desarrolladas bajo las directrices de MADEJA
Procedimientos
PROC-0005 Guía de decisión de componentes Recomendado
10
Recursos
RECU-0521 Librería de Iconos Plantilla Obligatorio
RECU-0523 Arquetipo Subsistema Interfaz de Usuario Arquetipo Software Recomendado
RECU-0524 Caso práctico Ejemplo Recomendado
RECU-0529 Hojas de Estilos Plantilla Recomendado
Normalización de interfaces - Aplicación del principio
RECU-0541 Técnica Recomendado
de Pareto
prototipos normalizar interfaz interfaces
Esquema general de la aplicación

Có digo : esquema_general_aplicacion
Este área trata de la organización y estructura de las pantallas de la aplicación en función de su tipología.
Se describen dos libros de pautas que recogen las especificaciones para las pantallas de primer y segundo nivel.
Objetivos
Identificar las distintas secciones de las pantallas, aportando al mismo tiempo un dimensionamiento para cada una de ellas
y permitiendo en todo caso ciertas variaciones en función de las necesidades específicas de las aplicaciones.
Pautas
Esquema general de las pantallas de primer
nivel
Esquema general de las pantallas de
segundo nivel
Funcionamiento general de aplicaciones

Có digo : funcionamiento_general_aplicaciones
Área que pretende normalizar una serie de comportamientos de las aplicaciones que faciliten su uso. Trata aspectos como el
funcionamiento al acceder y salir de una aplicación, el comportamiento al desplazarse entre los resultados de una búsqueda,
validaciones de datos realizadas por el usuario, etc. De esta manera se pretende conseguir que se pueda garantizar similitud
en el comportamiento de aplicaciones que se desarrollen de forma independiente.
Objetivos
Establecer disposiciones destinadas a usos comunes y repetidos, con el fin de mejorar y obtener un nivel de
ordenamiento óptimo en las aplicaciones.
Pautas
LIBP-0083 Acceso a la aplicación Directriz Obligatoria
PAUT-0059 Desconexión Directriz Obligatoria
PAUT-0060 Atrás Directriz Obligatoria
LIBP-0085 Formularios de introducción de datos Directriz Obligatoria
PAUT-0061 Ayuda Directriz Obligatoria
PAUT-0054 Ampliar imágenes o sus descripciones Directriz Obligatoria
PAUT-0055 Nombre de usuario y desconexión Directriz Obligatoria
PAUT-0056 Anclajes Directriz Obligatoria
Prototipos de pantallas
Có digo : Prototipos_pantallas
El objetivo de este área es el de normalizar las funcionalidades a presentar por los prototipos de pantalla más comunes dentro
del desarrollo de aplicaciones, definiéndose pautas para cada prototipo, así como imágenes que ilustran el formato que
deberán tener cada una de ellos.
Para cada tipo de pantalla se define un prototipo que la describe y se establece un libro de pautas asociado en el que se
enumeran las características y funcionalidades que deben ser cumplidas.
Se dispone de los siguientes recursos:
Prototipos de pantalla en lenguaje HTML
Los prototipos en formato HTML están disponibles dentro del área "Manual de estilo para el SGISI" y su propósito es que
11
puedan ser reutilizados con cualquier tecnología.
Prototipos de pantalla generados con JSF y Facelets
El código fuente está incluido dentro del caso práctico, disponible como recurso del área "Normalización de Interfaces".
Adicionalmente, se ofrece información para ayudar a las agencias administrativas a determinar qué prototipos utilizar en función
de diferentes criterios: funcionales, tecnológicos y organizativos.
Objetivos
Ofrecer prototipos para los tipos de pantallas más comunes.
Definir y enumerar las características y funcionalidades que debe cumplir cada prototipo.
Ofrecer objetos que puedan utilizarse en el desarrollo de las aplicaciones en diferentes tecnologías.
Pautas
LIBP-0140 Prototipo de pantalla de búsqueda avanzada Directriz Obligatoria
LIBP-0136 Prototipo de pantalla de búsqueda simple Directriz Obligatoria
LIBP-0141 Prototipo de pantalla de login Directriz Obligatoria
LIBP-0142 Prototipo de pantalla de consulta de detalle Directriz Obligatoria
Prototipo de pantalla de introducción de
datos
LIBP-0144 Prototipo de pantalla de ayuda Directriz Obligatoria
LIBP-0161 Prototipo de pantalla de error Directriz Obligatoria
LIBP-0162 Prototipo de pantalla de listado simple Directriz Obligatoria
LIBP-0163 Prototipo de pantalla de listado avanzado Directriz Obligatoria
Prototipo de pantalla de confirmación de
eliminación
LIBP-0234 Prototipo de pantalla de inicio Directriz Obligatoria
LIBP-0236 Prototipo de pantalla de contenidos Directriz Obligatoria
Catálogo de componentes de interfaz

Có digo : componentes_interfaz
El objetivo de este área es el de la definición de los elementos, pautas de uso y diseño de los componentes más utilizados
dentro del desarrollo de aplicaciones, normalizando los componentes de interfaz que podrán ser utilizados en los nuevos
desarrollos.
Se han creado un conjunto de libros de pautas que agrupan las pautas de utilización de componentes de interfaz en función de
su tipología y/o finalidad.
Adicionalmente, se incluyen como recurso unas fichas detalladas de los componentes propuestos para describir sus atributos,
controles de negocio, validaciones asociadas y valores por defecto de los mismos. Se indican aquellos que se consideran
obligatorios y cuales pueden ser adaptados o personalizados.
Por útlimo, se incluyen los cambios que han sufrido en la nueva especificación de HTML, la versión 5.
Objetivos
Definir los elementos más utilizados en el desarrollo de interfaces de usuario.
Normalizar el uso de componentes de interfaz.
Pautas
LIBP-0145 Componentes básicos de un formulario Directriz Obligatoria
LIBP-0147 Elementos de agrupación de componentes Directriz Obligatoria
LIBP-0152 Componentes de selección Directriz Obligatoria
LIBP-0155 Otros componentes permitidos Directriz Recomendada
Recursos
RECU-0015 Fichas de componentes de interfaz Referencia Recomendado
Catálogo de componentes de interfaz en JSF RichFaces

Có digo : catalogo_componentes_richfaces
En este área se realiza un estudio de los componentes proporcionados por la implementación de JSF recomendada por MADEJA
12
denominada RichFaces. Se especifican los componentes recomendados, permitidos y sus pautas de utilización, así como las
alternativas basadas en la implementación estándar de JSF cuando no se disponga de un componente específico.
Para cada componente recogido en el catálogo recogido en “Catálogo de componentes de interfaz”, se realiza una propuesta
de implementación JSF RichFaces incluyendo ejemplos de uso y pautas de utilización. En aquellos casos en los que existen
varias alternativas, se propone la que mejor se ajusta a las pautas de usabilidad y accesibilidad.
Objetivos
Definir los componentes RichFaces más utilizados en el desarrollo de interfaces de usuario.
Normalizar el uso de los componentes más habituales de RichFaces.
Pautas
Componentes básicos de un formulario en
RichFaces
Elementos de agrupación de componentes
en RichFaces
LIBP-0158 Componentes de selección en RichFaces Directriz Obligatoria
LIBP-0159 Componente menú en RichFaces Directriz Obligatoria
Otros componentes permitidos en
RichFaces
Catálogo de componentes de interfaces de impresión

Có digo : Componentes_inerfaces_impresion
Este área contempla la especificación de los elementos que componen los informes y formularios impresos, para que puedan
disponer de cierto nivel de normalización de elementos comunes.
Las pautas relacionadas con la normalización de los elementos de los informes se agrupan en dos libros de pautas, uno para el
catálogo de componentes permitidos y otro para las recomendaciones con respecto a la visualización de las páginas html
mediante hojas css que permitan su impresión.
Objetivos
Mostrar una relación de componentes básicos que deberán ser utilizados en el diseño y construcción de informes y
listados para las aplicaciones.
Establercer las pautas para diseñar formatos de pantallas y hojas de estilos CSS que permitan una visualización adecuada
para su impresión.
Pautas
LIBP-0179 Componentes de interfaz para informes Directriz Obligatoria
LIBP-0194 Formato de impresión para interfaces web Directriz Obligatoria
Prototipos de manipulación de datos

Có digo : prototipos_manipulacion_datos
Establece los componentes de manipulación de datos más comunes, indicando los requisitos de formato y validación. Engloba
los tipos de datos más utilizados como dirección, email, cuenta bancaria, etc.
Los componentes de manipulación de datos se utilizan normalmente en formularios. Éstos suelen incluir una secuencia de
comandos en cliente que valida los datos proporcionados por el usuario antes de enviar la información al servidor. Las
secuencias de comandos de validación pueden comprobar si el usuario introduce datos válidos en campos con formatos
conocidos. En general, lo mejor es realizar en el cliente tantas comprobaciones como sea posible pero todas deben repetirse
en el servidor. Con la validación en cliente se consigue mejor tiempo de respuesta, reducción de la carga del servidor y
reducción del ancho de banda consumido. Con la validación en servidor se consigue ampliar las posibilidades, por ejemplo
consultando una base de datos, y asegurar que se ejecutarán validaciones similares a las que existen en el cliente. La doble
validación formada por cliente y servidor garantiza que aunque el cliente tenga desactivado Javascript, las validaciones en el
lado del servidor siempre se encargarán de comprobar todos los datos introducidos por el usuario, asegurando así la fiabilidad
de los mismos.
Objetivos
Establecer los componentes de manipulación de datos para los tipos de datos más comunes.
Indicar los requisitos de formato y validación para los tipos de datos más comunes.
Pautas
LIBP-0195 Usuario y contraseña Directriz Obligatoria
13
LIBP-0196 NIF Directriz Obligatoria
LIBP-0197 Correo electrónico Directriz Obligatoria
LIBP-0198 Teléfono Directriz Obligatoria
LIBP-0199 Dirección postal Directriz Obligatoria
LIBP-0200 Código cuenta corriente Directriz Obligatoria
LIBP-0201 Campos numéricos Directriz Obligatoria
LIBP-0209 Fechas Directriz Obligatoria
LIBP-0210 Horas Directriz Obligatoria
LIBP-0211 URL Directriz Obligatoria
LIBP-0212 Sintaxis de búsquedas Directriz Obligatoria
PAUT-0117 Nombre y apellidos Directriz Obligatoria
Recursos
RECU-0678 Algoritmo de validación del DNI Ejemplo Recomendado
RECU-0679 Algoritmo de validación de NIF distinto al DNI Ejemplo Recomendado
RECU-0677 Formatos válidos para el NIF Referencia Recomendado
Manual de estilo genérico

Có digo : manual_estilo_generico
El objetivo del manual es normalizar la estructura de los contenidos y el diseño de las aplicaciones software homogeneizando
estilos y estructuras para facilitar el desarrollo de nuevas páginas y actualizaciones posteriores. La coherencia resulta
imprescindible en aplicaciones cargadas de información procedentes de varias fuentes. Por ello se definen las pautas de estilo,
identificando los elementos que deben considerarse para definir el estilo de los componentes de interfaz, así como sus
características y posibilidades de personalización: iconografía, fuentes, colores, imágenes, etc.
El manual está ideado para ser usado por todos aquellos que participen en el desarrollo de navegación y flujo de páginas así
como por todos aquellos desarrolladores de interfaz gráfica que no puedan, no sepan o tengan dudas sobre cómo generar la
estructura de una nueva página. Su objetivo es solucionar eficientemente los problemas de maquetación ofreciendo criterios
lógicos y ayudando a tomar conciencia de la línea de estilo que utiliza la web, a la vez que aclara dudas de aspecto gráfico para
la interfaz.
Objetivos
Normalizar la estructura de los contenidos y el diseño de las aplicaciones.
Definir pautas de estilos y sus características.
Ayudar a tomar conciencia de la línea de estilo que utilizan las aplicaciones desarrolladas bajo MADEJA.
Pautas
LIBP-0213 Gama cromática Directriz Obligatoria
LIBP-0214 Tipografía Directriz Obligatoria
LIBP-0215 Elementos gráficos Directriz Obligatoria
LIBP-0216 Creación de página Directriz Obligatoria
LIBP-0217 Estructura Directriz Obligatoria
LIBP-0218 Menú vertical Directriz Obligatoria
LIBP-0219 Buscador genérico Directriz Obligatoria
LIBP-0220 Tablas Directriz Obligatoria
LIBP-0221 Menú horizontal Directriz Obligatoria
LIBP-0228 Cabecera Directriz Obligatoria
LIBP-0229 Enlaces Directriz Obligatoria
Recursos
RECU-0478 Imagen genérica Plantilla Recomendado
14
Source URL: http://madeja.i-administracion.junta-andalucia.es/servicios/madeja/contenido/subsistemas/interfaz-usuario
15
Entorno
El subsistema de Entorno es el encargado de definir de forma general los distintos entornos de ejecución, así como aquellos
aspectos del ciclo de vida del desarrollo del software que tienen una fuerte dependencia e interacción con los mismos: entrega
y recepción del software, paso del software entre entornos para promoción, etc.
Objetivos
Normalizar la estructura y procedimiento para realizar las entregas
Especificar el uso y configuración de herramientas necesarias para la gestión de entregas: Gestión de estructura y
despliegue de aplicaciones, Control de versiones, Control de librerías, Gestión documental
Definir los distintos entornos de ejecución y sus características
Normalizar los procedimientos de paso de software entre entornos
Preparación del Entorno de Desarrollo

Có digo : DES_PREP_ENTORNO
La preparación del entorno de desarrollo es una parte muy importante dentro de la construcción de aplicaciones ya que permite
que el trabajo en equipo se realice de forma sencilla al contar el equipo de desarrollo con las mismas herramientas.
Por este motivo, MADEJA presenta una serie de recomendaciones y ejemplos necesarios para la preparación del entorno de
desarrollo.
A partir de los contenidos de este área, el equipo de desarrollo puede ampliar los conocimientos en el Área Gestión de la
Entrega donde se especifican las configuraciones necesarias de los proyectos de desarrollo para su entrega, como el uso de
Maven, Subversion y Artifactory; en el área Arquitectura Tecnológica del subsistema de Arquitectura se recogen
recomendaciones y ejemplos específicos de configuraciones tecnológicas recomendadas en función del tipo de proyecto. Por
último, el equipo de desarrollo deberá contemplar las recomendaciones dadas en el subsistema de Desarrollo referentes a los
Especificaciones de codificación a emplear en función del lenguaje elegido, recomendaciones sobre Seguridad y Rendimiento,
así como indicaciones sobre el uso de determinadas librerías y tecnologías en cada una de las capas de las aplicaciones.
Pautas
PAUT-0289 Uso de Java7 Directriz Recomendada
PAUT-0323 IDE de desarrollo Directriz Recomendada
Recursos
RECU-0683 Características de Java7 Referencia Recomendado
RECU-0887 Eclipse Ficha Técnica Recomendado
RECU-0682 EOL de Java6 Referencia Recomendado
RECU-0889 JDeveloper Ficha Técnica Recomendado
RECU-0885 Mapa de Tecnologías Página Recomendado
RECU-0888 Netbeans Ficha Técnica Recomendado
Área Gestión de la Entrega

Có digo : ENT_GES_ENT
El área de Gestión de la Entrega proporciona el conjunto de pautas, procedimientos, y recursos necesarios para la gestión
completa de las entregas realizadas durante el desarrollo de un proyecto, tanto productos de software como documentales.
Trata tanto aspectos necesarios a tener en cuenta de forma previa a la realización de la entrega, durante su preparación, así
como el propio acto de formalización de la entrega o el archivado posterior de la misma.
Objetivos
1
Gestionar de forma homogénea todas las entregas, software y documentales, asociadas a un proyecto, facilitando su
revisión y tratamiento
Responsabilidades: seleccionar las herramientas que ofrezcan soporte adecuado a la gestión de la entrega, y facilitar los
recursos necesarios para realizar una correcta entrega.
Pautas
Uso de herramientas para la gestión de
entregas
Uso de procedimientos para la gestión de
entregas
Definición del entorno de entrega o recepción
del software
Herramienta de integración continua en la
gestión de entregas
PAUT-0076 Nomenclatura de documentos entregables Directriz Obligatoria
PAUT-0077 Entrega del código fuente Directriz Obligatoria
PAUT-0078 Estructura estándar de los fuentes Directriz Obligatoria
PAUT-0079 Acuerdo y marcado de la versión Directriz Obligatoria
LIBP-0148 Política de versionado de productos software Directriz Recomendada
PAUT-0088 Organización de los productos documentales Directriz Recomendada
Localización en el código fuente de ficheros
de Base de Datos
Procedimientos
PROC-0010 Procedimiento de Entrega de Software Recomendado
PROC-0011 Procedimiento de Entrega de Documentación Recomendado
Recursos
RECU-0320 Plantilla Descripción de la Entrega Plantilla Recomendado
RECU-0321 Plantilla Novedades de la Entrega Plantilla Recomendado
RECU-0328 Manual de implantación del entorno de entrega Manual Recomendado
RECU-0016 Introducción a Maven2 Ficha Recomendado
RECU-0322 Maven Manual Recomendado
RECU-0681 Características de Maven3 respecto a Maven2 Referencia Recomendado
RECU-0323 Guía de la Estructura del Software Manual Recomendado
RECU-0324 Guia de integración del uso de Maven con Eclipse Manual Recomendado
RECU-0017 Introducción a Subversión Ficha Recomendado
RECU-0325 Subversion Ficha Técnica Recomendado
Manual para el uso de branches y merges con
subversion
Repositorio de Artefactos
Có digo : ENT_REPO
En esta sección se tratan todos los aspectos relacionados con el sistema de control de librerías o artefactos utilizado como
parte del entorno de entrega o recepción del software.
Entre otros, se describe el procedimiento para la solicitud de actualización de artifactory en el caso de entregas de software
basadas en maven.
Para conocer la URL de acceso al Repositorio de Artefactos de MADEJA consultar el recurso " Repo sito rio de Artefacto s
de MADEJA"
Objetivos
Mantener un control de versiones en las librerías utilizadas en el desarrollo
Controlar el origen y licenciamiento de las librerías utilizadas en el desarrollo
Pautas
2
Aseguramiento de la compilación de las
entregas software
Uso del Repositorio de Artefactos de
MADEJA
Homogeneización de la coordenada
"groupId" en los proyectos maven
PAUT-0085 Uso del plugin MAVEN ENFORCER Directriz Recomendada
LIBP-0146 Gestión de las dependencias y repositorios Directriz Obligatoria
Inclusión del Repositorio de Artefactos de
PAUT-0181 MADEJA en el de una Consejería u Directriz Obligatoria
Organismo
Actualización del Repositorio de Artefactos
de MADEJA desde Organismos de la Junta
Publicación de artefactos propios de una
Consejería u Organismo
Recomendaciones a la administración del
repositorio
Desplegar artefactos no libres en un
repositorio
Procedimientos
PROC-0013 Procedimiento Solicitud de Actualización de Artifactory Recomendado
Recursos
RECU-0520 Repositorio de Artefactos de MADEJA Herramienta Obligatorio
RECU-0319 Plantilla Solicitud de Actualización del Artifactory Plantilla Recomendado
RECU-0327 Artifactory Manual Recomendado
RECU-0329 Arquitectura del repositorio de librerías MADEJA Ficha Técnica Recomendado
Despliegue de artefactos en Artifactory desde
Hudson
Área Gestión de Entornos y Despliegues

Có digo : ENT_ENTO
En este área se recogen los distintos requisitos necesarios para llevar a cabo la actualización de los entornos disponibles.
Objetivos
Definir y normalizar los distintos entornos necesarios
Estandarizar los mecanismos y procedimientos para solicitud de promoción de cambios en los diferentes entornos
Pautas
Solicitud de Despliegues en Entornos de
Producción
PAUT-0305 Uso de URLs semánticas Directriz Recomendada
Procedimientos
PROC-0012 Procedimiento Gestión de Despliegues Recomendado
Recursos
RECU-0727 Definición de URLs semánticas en Apache Ejemplo Recomendado
RECU-0728 Definición de URLs semánticas mediante PrettyFaces Ejemplo Recomendado
Definición de URLs semánticas mediante
3
UrlRewriteFilter
RECU-0777 Configuración del servidor de aplicaciones JBoss Referencia Recomendado
RECU-0111 Configuración del servidor de aplicaciones Tomcat Referencia Recomendado
Source URL: http://madeja.i-administracion.junta-andalucia.es/servicios/madeja/contenido/subsistemas/entorno
4
Ingeniería
El subsistema de Ingeniería contempla el conjunto de pautas y procedimientos de trabajo bajo los que se debe regir el desarrollo
de cualquier proyecto IT con independencia de su tipologa, con la finalidad de establecer una forma de trabajo homogénea y
común para todos los proyectos.
Incluye la definición de los productos a generar durante el desarrollo de los proyectos atendiendo a aspectos formales y
procedimentales, y aportando plantillas autodescriptivas de soporte para la elaboración de los productos.
De esta forma, se estandarizará y garantizará la calidad de las distintas fases del ciclo de vida del software y de los distintos
modelos de desarrollo, testing y prestación de servicios.
Se establecen las actividades necesarias en la gestión y desarrollo del producto, entendiendo el producto como un proyecto
guiado, procedimentado y perfectamente establecido.
No hay vinculación a un ciclo de vida de desarrollo en concreto, sino que son actividades genéricas adaptables a cualquier
metodología de desarrollo (en cascada, espiral, etc).
Las atribuciones que competen a este área de MADEJA son las de:
Dentro de este subsistema, se han recogido contenidos generales y horizontales a todas las áreas, relacionados con actores y
uso de herramientas, que complementan la información recogida en las distintas áreas. A continuación exponemos las pautas y
recursos comunes:
Pautas:
Pauta sobre entregables asociados al subsistema de Ingeniería
Pauta sobre uso de plantillas
Recursos:
Listado de plantillas
Definición de roles
Propuesta de Plataforma Tecnológica de Soporte
Estos contenidos se pueden consultar también en el área Contenidos generales.
Objetivos
Calidad de los productos
Ajuste y precisión en los plazos
Ajuste y precisión en los costes
Satisfacción de las necesidades definidas por los usuarios
1
Contenidos generales
Có digo : ING_GEN
En esta sección se incluyen todos aquellos contenidos que son horizontales a todas las áreas del subsistema de Ingeniería y que
por tanto se asocian con el subsistema completo.
Pautas
Pauta sobre entregables asociados al
subsistema de Ingeniería
PAUT-0150 Uso de plantillas Directriz Obligatoria
Recursos
RECU-0492 Propuesta de Plataforma Tecnológica Página Obligatorio
RECU-0494 Roles propuestos por MADEJA Página Obligatorio
RECU-0514 Herramientas de Soporte Página Recomendado
RECU-0515 Listado de plantillas Página Recomendado
Comunicación y Difusión
Có digo : ING_COM
El área de "Comunicación y Difusión" proporciona el conjunto de pautas, procedimientos y recursos necesarios para para dar a
conocer tanto interna como externamente las iniciativas y proyectos acometidos desde la Consejería u Organismo, y presentar
aquellos resultados obtenidos durante el desarrollo de los proyectos susceptibles de ser comunicados.
Además, se establecen los mecanismos de feedback que permiten conocer si lo que se quiere transmitir a las audiencias es lo
que se ha transferido, el grado de comprensión y de aceptación de los implicados, recoger sus sugerencias y dudas, así como
detectar la necesidad de adoptar acciones para alcanzar los objetivos previamente establecidos.
De forma estructurada, se presentan los objetivos, responsabilidades y productos de esta área.
Respo nsabilidades:
Seleccionar las herramientas que ofrezcan soporte adecuado a las acciones de comunicación y difusión.
Facilitar los recursos necesarios para llevar a cabo las acciones de comunicación de forma correcta.
Objetivos
Difundir el alcance de los proyectos, sus objetivos y la planificación de los principales hitos.
Recoger ideas y obtener un feedback constructivo.
Mantener a todos los actores interesados informados del estado del proyecto.
Minimizar el impacto generado por los cambios.
Reducir la incertidumbre y desconocimiento entre todos los involucrados.
Pautas
LIBP-0230 Uso de las listas de distribución Directriz Recomendada
LIBP-0231 Desarrollo de un Plan de Comunicación Directriz Recomendada
Carácter de los entregables de Comunicación
y Difusión en función del tamaño del proyecto
Uso de procedimientos de Difusión y
Comunicación
Procedimientos
PROC-0031 Procedimiento Comunicación y Difusión de Proyectos Recomendado
PROC-0032 Procedimiento Participación Grupos de Interés Recomendado
Recursos
RECU-0471 Plantilla Plan de Comunicación Plantilla Recomendado
2
RECU-0472 Documento Canales y Acciones de Comunicación Referencia Recomendado
1291:2

RECU-0473 Plantilla Material de Comunicación Plantilla Recomendado
Creación y Evolución de Sistemas

Có digo : ING_SIS
El área "Creación y Evolución de Sistemas" describe de manera global las distintas fases que componen el ciclo de vida de un
proyecto software, desde el inicio hasta la finalización del mismo, especificando los objetivos y entregables a generar en cada
una de las fases.
Puesto que se trata de un área que abarca el ciclo de vida de forma global, se han establecido enlaces con otras áreas y
subsistemas en las que se profundiza en cada una de las fases, como es el caso de Ingeniería de Requisitos, en la cual se detalla
la metodología propuesta por MADEJA para las fases iniciales del proceso (Especificación de Requisitos y Análisis), o el
subsistema de Verificación, en el cual se detallan las pruebas a realizar durante el proceso completo, y su relación con las fases
de desarrollo. Además, en este área se incluye un conjunto de plantillas autoexplicativas que ayudan a la elaboración de la
documentación a generar en cada una de las fases del ciclo de vida del producto software.
Hay que resaltar el carácter configurable de este proceso metodológico, en función de la naturaleza del proyecto, necesidades
de la organización, complejidad, etc. Por ello, en cualquier aplicación práctica este método podrá adaptarse, aunque se deberán
mantener las directrices aportadas. No obstante, el proceso metodológico descrito es válido por su generalidad para cualquier
tipo de proyecto de desarrollo de software con independencia del tamaño y complejidad. Matices de este tipo condicionarán el
grado de detalle al que se llegue en un determinado apartado.
En concreto, el método propuesto seguirá un modelo de desarrollo en W que surge como evolución y mejora de los modelos en
V. El modelo en W contempla los procesos definidos por Métrica v3, añadiendo además al modelo en V una revisión de las fases
de desarrollo y una depuración y corrección de los posibles errores detectados en las fases de pruebas. Así, el modelo en W
refleja mejor la interdependencia que existe entre equipo de proyecto, el equipo de testing y el área usuaria a lo largo de todo el
proceso de desarrollo del sistema, donde básicamente:
En las primeras etapas se consideran las fases de desarrollo y algunas labores de pruebas como son la elaboración de los
planes de prueba y la revisión de estas fases.
En las etapas finales se desglosan las fases de pruebas y las labores de depuración y corrección de los errores detectados.
Las peticiones de cambio se pueden dar en todas las fases de desarrollo y surgen por el cliente o por el propio equipo de
desarrollo.
La siguiente figura representa el mo delo de desarro llo en W:
W exterio r, corresponde a las fases del desarrollo software.
W interio r, hace referencia a las fases de testing (distinguiéndose las fases de testing temprano de las de testing de
software)
Descripció n de las fases:

Especificació n de Requisito s.
Descripción: En esta fase se identificarán las necesidades de negocio de clientes y usuarios del sistema y se realizará la
definición de las características que deberá cumplir el producto software a desarrollar. Para ello, durante esta fase será
fundamental interactuar con los usuarios finales y así concretar los requisitos del sistema. El catálogo completo de
requisitos del sistema a desarrollar se especificará en el documento de Especificació n de Requisito s. En él se
incluirán tanto los requisitos generales del sistema, como requisitos específicos (funcionales, no funcionales, de
integración, y restricciones técnicas).
3
A partir de los requisitos generales definidos en el documento de Especificación de Requisitos se elaborará el Plan de
Pruebas de Aceptació n, el cuál servirá de guía a los usuarios finales en la realización de las pruebas que verifiquen
los requisitos funcionales solicitados, en cuyo caso se aceptará el sistema. Conviene resaltar que el Equipo de Testing
generará el Plan de Pruebas de Aceptación como parte de la ejecución del servicio Testing Temprano - Requisitos.
Entregables:
Especificación de Requisitos de Sistema
Plan de Pruebas de Aceptación
Análisis.
Descripción: En esta fase se se realizará en primer lugar, la definición del modelo de la estructura interna del sistema
software y de sus relaciones con otros sistemas, y por otro, la elaboración del modelo de clases y descripción de los
diagramas de secuencia y diagramas de flujo de trabajo mediante el modelo de casos de uso. Esta información se
recogerá en el documento de Análisis del Sistema.
Además, en esta fase deberá comenzarse la elaboración del Plan de Pruebas Funcio nales a partir de la
documentación ya generada (Especificación de Requisitos y Análisis del Sistema). El Plan de Pruebas Funcionales tienen
como guía los requerimientos establecidos por el cliente, y se busca analizar si los satisfacen, tanto en los
requerimientos positivos (qué se deseaba que hiciera) como las limitaciones (qué se deseaba que no hiciera). El Plan de
Pruebas Funcionales deberá contener, al menos, la siguiente información:
Definición de los casos de pruebas: identificador único, descripción, prerequisitos, pasos a seguir para la ejecución
del caso de prueba y el resultado esperado.
Matriz de trazabilidad de casos de pruebas y requisitos funcionales, con el objetivo de verificar que se han definido
los casos de pruebas necesarios para ofrecer cobertura a todos los requisitos funcionales y de integración definidos.
Definición de la estrategia a seguir para la ejecución del Plan de Pruebas Funcionales definido.
Para más información a cerca de como elaborar el Plan de Pruebas Funcionales se recomienda consultar la pauta Diseño y
Ejecución de pruebas funcionales.
Entregables:
Análisis del Sistema
Plan de Migración y Carga Inicial (si aplica)
Plan de Pruebas Funcionales
Diseño .
Descripción: En esta fase se detallan los principios técnicos del sistema a partir de los modelos funcionales diseñados
en la fase anterior. Se realiza el diseño de los componentes software del sistema especificando las necesidades de
infraestructura tecnológica, arquitectura software y estándares de desarrollo según MADEJA.
En esta fase de elabora el documento de Diseño del Sistemay los siguientes planes de pruebas:
Plan de Pruebas Unitarias. El Plan de Pruebas Unitarias debe recoger el conjunto de pruebas que el Equipo de
Proyecto deberá realizar para comprobar el correcto funcionamiento de cada componente de código por separado.
Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. El Plan de Pruebas
Unitarias deberá recoger tantas pruebas como componentes se vayan a probar, especificando para cada uno de
ellos los datos de entrada y la salida esperada. Se trata de un documento interno de trabajo que el Equipo de
Proyecto deberá elaborar para posteriormente llevar a cabo la implementación en la herramienta correspondiente
(por ejemplo, JUnit).
Plan de Pruebas de Integració n. El Plan de Pruebas de Integración debe recoger el conjunto de pruebas que el
Equipo de Proyecto deberá realizar para verificar la correcta integración entre todos los componentes/módulos del
sistema. Se deberán definir los casos de pruebas que comprueben la integración entre los módulos del sistema,
especificando la relación de los componentes a probar, así como lo datos de entrada y la salida esperada. Se trata
de un documento interno de trabajo que el Equipo de Proyecto deberá elaborar para posteriormente llevar a cabo la
implementación de las pruebas en la herramienta correspondiente (por ejemplo, JUnit).
Para más información, se recomienda consultar la pauta Diseño y ejecución de pruebas de componentes de código
Plan de Pruebas Funcio nales (actualizació n). Se realizará la actualización del Plan de Pruebas Funcionales a
partir de la información generada en la fase de Diseño.
Entregables:
Diseño del Sistema
Plan de Pruebas Unitarias
Plan de Pruebas de Integración
Plan de Pruebas Funcionales
Prototipos
Co nstrucció n.
Descripción: Es la fase central del método. MADEJA aporta recomendaciones específicas desde el punto de vista
4
metodológico para el desarrollo del software. En concreto, el Subsistema Desarrollo de MADEJA efectúa sugerencias en
lo que respecta a aspectos clave como son la gestión de la configuración, guías de estilo de codificación, etc. Además
de la construcción de todos los componentes software, se deberá elaborar la documentación necesaria para asegurar la
correcta instalación, explotación, instalación y uso del sistema.
Entregables:
Manual de Usuario
Manual de Instalación
Manual de Actualización
Manual de Administración
Manual de Integración
Manual de Explotación
Soporte
Pruebas.
Descripción:Esta fase se llevará a cabo la ejecución de los distintos planes de pruebas definidos en fases anteriores.
Será necesario conseguir el objetivo que persigue cada tipo de prueba, evitando arrastrar errores que debieron
solucionarse en pruebas precedentes. Por tanto, en esta fase se llevarán a cabo las siguientes acciones:
Ejecució n de las pruebas de có digo : Un alto porcentaje de estas pruebas pruebas se podrán automatizar en
herramientas, tales como Checkstyle, PMD, Findbugs.
Ejecució n del Plan de Pruebas Unitarias: Para la ejecución del Plan de Pruebas Unitarias se deberá utilizar una
herramienta que automatice el proceso de ejecución de dichas pruebas, por ejemplo, JUnit. El Equipo de Proyecto
deberá entregar los ficheros fuentes que implementen las pruebas JUnit y los ficheros de recursos asociados
(properties, xml de config,etc.) de forma que puedan ser ejecutadas las pruebas posteriormente durante el proceso
de revisión de la entrega.
Ejecució n del Plan de Pruebas de Integració n: Para automatizar las pruebas de integración se pueden
emplear las mismas herramientas que para las pruebas unitarias (por ejemplo, JUnit), pero los casos de pruebas por
regla general serán más largos y la verificación de resultados puede requerir más de una comprobación.
Ejecució n de las Pruebas Funcio nales: Se deberán ejecutar cada uno de los casos de pruebas funcionales
siguiendo la estrategia definida. Como resultado de la ejecución del plan de pruebas el Equipo de Proyecto deberá
entregar un informe en el que se indique el resultado obtenido de la ejecución de cada caso de prueba.
Entregables:
Implementación de Pruebas Unitarias
Implementación de Pruebas de Integración
Informe Pruebas Funcionales
Además de las pruebas que el Equipo de Proyecto deberá realizar antes de formalizar la entrega software,
posteriormente, durante la revisión de la entrega, la Oficina de Testing ejecutará un conjunto de pruebas que
aseguren la calidad del software desarrollado. Para ello se ha definido un conjunto de verificaciones las cuáles están
contempladas en el Subsistema de Verificación de MADEJA. Como resultado de las pruebas realizadas, en base a los
criterios establecidos, se obtendrán los siguientes informes resultado.
Informe de revisión de la entrega software
Informe de revisión del testing temprano
Informe de revisión de verificación y ajustes en entornos
Informe completo del resumen de las pruebas realizadas
Despliegue.
Descripción: El despliegue deberá tener en cuenta tanto los aspectos técnicos (componente de software/hardware)
como los humanos: formación, gestión del cambio, etc.
Respo nsabilidades:
Seleccionar las herramientas que ofrezcan soporte adecuado a la creación y evolución de sistemas.
Facilitar los recursos necesarios para desarrollar un sistema de información.
Objetivos
Establecer una metodología para llevar acabo el proceso de desarrollo y evolución de un sistema de información.
Generar el código que implementa el funcionamiento de los componentes del sistema y comprobar su corrección de forma
individual.
Garantizar la calidad del sistema a lo largo del ciclo de vida completo, incluido el mantenimiento.
Pautas
5
LIBP-0223 Especificación de Requisitos Directriz Recomendada
LIBP-0224 Análisis del Sistema Directriz Recomendada
LIBP-0225 Diseño del Sistema Directriz Recomendada
LIBP-0226 Construcción del Sistema Directriz Recomendada
LIBP-0227 Pruebas del Sistema Directriz Recomendada
Carácter de los entregables de Creación y
PAUT-0139 Evolución de Sistemas en función del tamaño Directriz Recomendada
del proyecto
Procedimientos
PROC-0030 Creación y Evolución de Sistemas Recomendado
Recursos
RECU-0456 Plantilla Especificación de Requisitos Plantilla Obligatorio
RECU-0457 Plantilla Análisis del Sistema Plantilla Obligatorio
RECU-0458 Plantilla Diseño del Sistema Plantilla Obligatorio
RECU-0459 Plantilla Plan de Migración y Carga Inicial Plantilla Recomendado
RECU-0460 Plantilla Plan de Pruebas Unitarias Plantilla Recomendado
RECU-0461 Plantilla Plan de Pruebas de Integración Plantilla Recomendado
RECU-0462 Plantilla Plan de Pruebas Funcionales Plantilla Obligatorio
RECU-0463 Plantilla Plan de Pruebas de Aceptación Plantilla Recomendado
RECU-0464 Plantilla Manual de Explotación Plantilla Obligatorio
RECU-0465 Plantilla Manual de Usuario Plantilla Obligatorio
RECU-0466 Plantilla Manual de Instalación Plantilla Obligatorio
RECU-0467 Plantilla Manual de Actualización Plantilla Obligatorio
RECU-0468 Plantilla Manual de Administración Plantilla Obligatorio
RECU-0469 Plantilla Manual de Integración Plantilla Obligatorio
RECU-0470 Plantilla Soporte Plantilla Obligatorio
Ingeniería de requisitos
Có digo : ING_REQ
La ingeniería de requisitos es el conjunto de actividades y tareas del proceso de desarrollo de sistemas software que tiene
como o bjetivo s:
Definir, con la mejor calidad posible, las características de un sistema software que satisfaga las necesidades de negocio de
clientes y usuarios y que se integre con éxito en el entorno en el que se explote. La definición de dicho sistema se realiza
mediante lo que se conoce como una especificación de requisitos.
Gestionar las líneas base y las peticiones de cambios que se vayan produciendo en la especificación de requisitos,
manteniendo la trazabilidad entre los requisitos y otros productos del desarrollo.
MADEJA recoge la ingeniería de requisitos como pieza clave para proporcionar un sistema de información con calidad. Esta
calidad debe entenderse como la satisfacción del usuario ante el sistema de información proporcionado, que cubre las
expectativas, deseos y necesidades que los usuarios manifestaron y que se supieron recoger e implementar.
El resultado de esta tarea o actividad no es estático, ya que a lo largo del proyecto pueden aparecer nuevos requisitos,
ampliaciones, incluso eliminaciones o modificaciones de los existentes. Cuanto más tarde descubramos requisitos nuevos o
haya desviaciones entre los requisitos y el producto, mucho mayor impacto tendrá en tiempo y coste.
Desde este punto de vista, se tiene que considerar la trazabilidad de los requisitos como aspecto fundamental en la gestión
de un proyecto. Es decir, actualizar los requisitos del proyecto conforme se vayan produciendo tales cambios, pero sin olvidar la
actualización , el impacto y la coherencia de la documentación asociada al mismo: análisis del sistema, diseño, pruebas de
validación, etc. A continuación se muestra un gráfico que refleja las dependencias que se establecen entre la definición de
requisitos y su gestión de proyectos, el desarrollo del mismo y la documentación de soporte que se genera.
6
La Ingeniería de Requisitos es una de las partes cruciales en el éxito de todo proyecto software. La aparición de errores o
carencias durante la recogida de requisitos implica un descenso en la productividad del proceso de desarrollo y, por lo tanto, un
incremento del coste del mismo. Incluir una adecuada ingeniería de requisitos en el ciclo de vida del software minimizará la
posibilidad de que esto ocurra. La Ingeniería de Requisitos se convierte en pieza clave para poder medir la calidad de un sistema
informático al poder iniciar la definición de la batería de pruebas que el sistema debe pasar, garantizando que éstas satisfacen
los requisitos establecidos y por lo tanto el sistema es válido y funcionalmente es correcto.
Tener herramientas y mecanismos que recojan las necesidades de los usuarios y que se alimenten de las opiniones de los
mismos, así como integrar los requisitos en todo el proceso de desarrollo, son parte de los objetivos que cubrimos en estos
apartados dentro del proyecto MADEJA.
De forma estructurada, se presentan los objetivos, responsabilidades y productos de esta área.
Objetivo s:
Fomentar la realización de una ingeniería de requisitos de acuerdo a los principios de calidad y eficiencia en el desarrollo
establecida por MADEJA
Trasmitir la importancia de la ingeniería de requisitos y la trazabilidad de los requisitos como aspecto de un impacto directo
en la calidad del sistema de información.
Respo nsabilidades:
Definir y establecer pautas que ayuden a estandarizar el desarrollo de procesos y actividades relacionadas con la ingeniería
de requisitos de acuerdo a las buenas prácticas propuestas por MADEJA. Establecer recursos que faciliten la integración de
estas buenas prácticas dentro del desarrollo común de aplicaciones
Facilitar herramientas que ayuden en la automatización, adopción y mantenimiento de las buenas practicas establecidas por
MADEJA para el conjunto de actividades y procesos relacionadas
Facilitar la plantilla del documento de Especificación de Requisitos del Sistema (ERS).
Actividades:
Identificar las necesidades de negocio de clientes y usuarios
Desarrollar los requisitos de un sistema software que satisfaga las necesidades de negocio
Gestionar los requisitos del sistema software a desarrollar
La metodología de ingeniería de requisitos de MADEJA define una serie de pautas y procedimientos.
Como conceptos básicos en la Ingeniería de Requisitos se dispone de un modelo de roles que intervienen en el procedimiento
general a realizar para seguir las actividades de la Ingeniería de Requisitos.
La aplicación de una metodología que guíe la Ingeniería de Requisitos es esencial para una adecuada realización de esta fase del
desarrollo de software. Las contribuciones e influencias en la realización de esta metodología son las siguientes:
Influencias en la pro puesta meto do ló gica de Madeja
La propuesta de contenido que se hace en Madeja está basada principalmente en las siguientes fuentes: la metodología
Métrica versión 3; el Capability Maturity Model Integration para desarrollo en su versión 1.2 (CMMI-DEV 1.2); las normas
ISO/IEC-12207 e ISO/IEC-9126; los trabajos previos de los Drs. Amador Durán y Beatriz Bernárdez del Dpto. de Lenguajes y
Sistemas Informáticos de la Universidad de Sevilla; y las recomendaciones del personal del proyecto del área de ingeniería
Madeja (Rosa María Torres de Paz) de la Consejería de Economía, Innovación y Ciencia de la Junta de Andalucía, en especial las
relativas a arquitecturas orientadas a servicios.
Objetivos
Definir, con la mejor calidad posible, las características de un sistema software que satisfaga las necesidades de negocio de
clientes y usuarios y que se integre con éxito en el entorno en el que se explote. La definición de dicho sistema se realiza
mediante lo que se conoce como una especificación de requisitos.
Gestionar las líneas base y las peticiones de cambios que se vayan produciendo en la especificación de requisitos,
manteniendo la trazabilidad entre los requisitos y otros productos del desarrollo.
7
Procedimientos
PROC-0023 Procedimiento General en la Ingeniería de Requisitos Obligatorio
PROC-0022 Procedimientos de Análisis de Requisitos Obligatorio
Recursos
RECU-0411 Análisis del Sistema Manual Recomendado
RECU-0409 Atributos de los requisitos Referencia Recomendado
RECU-0407 Especificación de Requisitos del Sistema Manual Recomendado
RECU-0416 Guía para la redacción de casos de uso Manual Recomendado
Herramientas para la Gestión y Documentación de
Requisitos
RECU-0413 Modelo de calidad de requisitos Referencia Recomendado
RECU-0493 Modelo de roles de la ingeniería de requisitos Página Obligatorio
Plantilla con la estructura de Desarrollo para Enterprise
Architect
Posibilidades de Infraestructura y Mantenimiento de
proyectos con Enterprise Architect
RECU-0408 Taxonomía de requisitos Referencia Recomendado
RECU-0415 Técnicas de elicitación de requisitos Técnica Recomendado
RECU-0419 Técnicas de validación de requisitos Técnica Recomendado
RECU-0418 Técnicas de verificación de requisitos Técnica Recomendado
Técnicas para el modelado de procesos de negocio y
el análisis de requisitos
RECU-0414 Verificación de Requisitos Técnica Recomendado
Desarrollo de requisitos de un sistema que satisfaga las necesidades de negocio

Có digo : ING_REQ_DES
A continuación se van a presentar las pautas y procedimientos que deben de seguirse para elaborar los requisitos de un
sistema software que pueda satisfacer las necesidades de negocio que se establezcan por parte del cliente.
El conjunto de pautas se fundamentan en las actividades que forman parte del procedimiento Desarrollar los requisitos de un
sistema que satisfaga las necesidades de negocio del procedimiento general de Ingeniería de Requisitos.
Pautas
LIBP-0181 Elaborar la visión general del sistema Directriz Recomendada
LIBP-0182 Documentar los requisitos del sistema Directriz Obligatoria
LIBP-0183 Analizar los requisitos del sistema Directriz Obligatoria
LIBP-0184 Verificar los requisitos del sistema Directriz Obligatoria
LIBP-0185 Validar los requisitos del sistema Directriz Obligatoria
Registrar problemas en los requisitos del
sistema
Registrar la trazabilidad los requisitos del
sistema
Procedimientos
Procedimiento para desarrollar los requisitos de un sistema software que
PROC-0020 Obligatorio
satisfaga las necesidades de negocio
Gestión de requisitos del sistema software a desarrollar

Có digo : ING_REQ_GES
La gestión de los requisitos es un aspecto fundamental dentro de la ingeniería de requisitos. Los objetivos que se busca con
una gestión del cambio al nivel de requisitos. Es especialmente importante remarcar que esta gestión de cambio esta dirigida
exclusivamente para los proyectos cerrados. Vamos a identificar que conseguimos con la gestión del cambio:
Co ntro lar el cambio . Con frecuencia se producen cambios dentro de una organización. El cambio debe de estar
8
estandarizado y controlado. Un control deficiente puede hacer que la organización se convierta en menos productiva y los
errores e incidencias aumenten de manera considerable en frecuencia e impacto. Los cambios son los que provocan un
avance en la misión de alinearse con el negocio, nacen por cuestiones de negocio y buscan una estructura estable cercana
a la visión real de negocio
To do es un cambio . Pasar de un estado definido de la infraestructura a uno nuevo siempre supone un cambio y debe
de ser gestionado. Habrá que estudiar el impacto, el coste, etc pero deben de ser tratados como “cambios”. El objetivo
no es burocratizar el proceso los procedimientos, sino la de controlar el mismo, lo que se aprueba y lo que se lleva
finalmente a construcción e implementación
No rmalizar y estandarizar el cambio . El cambio esta íntimamente relacionado con la gestión de proyectos. Debe de
desarrollarse una metodología estándar para la gestión del cambio que se apoye en la gestión de proyectos, para manejar
con rapidez y minimizando, en lo posible, el impacto de los cambios. Se procedimienta a la organización ante cualquier
evento que impida la prestación adecuada de un servicio. Una vez establecida la metodología se comunica, se enseña e
implemente y, muy importante, se hace respetar. Todo cambio se somete a lo que indique la metodología.
Visió n del co ste. Normalmente, a la hora de realizar un cambio no tenemos mucha información acerca del coste que
supone el mismo. El identificar a un responsable de su estudio, análisis y planificación, permite ajustar mejor el impacto y la
viabilidad del cambio. Es importante que el gestor del cambio se vea suficientemente respaldado por la organización, para
el éxito de sus actividades.
Planificació n del cambio . Es muy importante pensar que el cambio se adapta a la agenda del negocio, no a la de TI. Es
interesante mantener un calendario de cambios con las fechas propuestas para la implementación de los mismos. No debe
de perderse la perspectiva, que el cambio por insignificante que parezca esta orientado a apoyar al negocio.
El conjunto de pautas de esta área se fundamentan en las actividades que forman parte del Procedimiento para la gestión de
requisitos del proceso general de Ingeniería de Requisitos.
Pautas
Gestionar las lineas base y peticiones de
cambio a los requisitos del sistema
Gestionar los problemas de los requisitos
del sistema
Mantener la trazabilidad de los requisitos del
sistema
Procedimientos
PROC-0021 Procedimiento para la gestión de requisitos Obligatorio
Identificación de las necesidades de negocio

Có digo : ING_REQ_NEG
El objetivo principal de un sistema a desarrollar se centra en el alineamiento de las necesidades de negocio del sistema, con
las posibilidades técnicas reales. Una fase muy importante , por ende, es la identificación de las necesidades de negocio.
A continuación se van a establecer un conjunto de pautas y procedimientos para poder identificar las necesidades de negocio
de un sistema a desarrollar bajo el marco de desarrollo de MADEJA
Este conjunto de pautas se fundamentan en las actividades que forman parte del Procedimiento para identificar las
necesidades de negocio de clientes y usuarios del procedimiento general de Ingeniería de Requisitos.
Pautas
LIBP-0175 Estudiar el dominio del problema Directriz Recomendada
Identificar aspectos positivos y negativos
LIBP-0176 Consejo
de la situación actual
LIBP-0177 Estudiar el modelo de negocio del cliente Directriz Recomendada
LIBP-0178 Estudiar el entorno tecnológico del cliente Directriz Obligatoria
Obtener y documentar las necesidades de
clientes y usuarios
Procedimientos
Procedimiento para Identificar las necesidades de negocio de clientes y
PROC-0019 Obligatorio
usuarios
9
Gestión de Proyectos
Có digo : ING_GESPRO
El área "Gestión de Proyectos" proporciona el conjunto de pautas, procedimientos y recursos necesarios para realizar una
correcta gestión de los proyectos durante el ciclo de vida completo: inicio, planificación, seguimiento y control, y finalización, de
forma que se asegure que los proyectos se realizan cumpliendo el alcance, plazos y requisitos de calidad establecidos. Para
cada una de las fases, se define el conjunto de actividades a realizar, y la documentación que se deberá elaborar, aportando
plantillas autoexplicativas que ayuden a su generación.
La gestión de proyectos permite al gestor del proyecto, y a todos los demás participantes implicados, la elaboración de
planificaciones y mantener controlados todos los aspectos relevantes de un proyecto de una forma homogénea. El proceso de
gestión de proyectos se aplica a cualquier tipología del proyecto, pudiendo ser entre otros: desarrollo, consultoría, etc.
A continuación se describen las principales fases en las que se divide la Gestión de Proyectos:
Inicio : El inicio de un proyecto consiste en la realización de las actividades encaminadas a lograr el correcto arranque del
proyecto y establecer los aspectos internos y logísticos necesarios para la ejecución del mismo. Durante esta fase se
establecerán las normas de ejecución y el modelo de relación con el cliente para el desarrollo del proyecto, identificando las
personas y recursos claves. Se deberá realizar una puesta en común de los distintos puntos de vista y comprensión de los
objetivos del proyecto por parte de la dirección del mismo y de las áreas participantes.
Planificació n: Durante la fase de Planificación se llevará a cabo la elaboración de la planificación del proyecto, la cuál
contendrá las tareas que se van a realizar, cuándo se realizarán y los entregables que se obtendrán como resultado de
dichas tareas. Durante el ciclo de vida del proyecto, la planificación deberá ser revisada para ajustarla a los cambios
ocurridos (tiempos y alcance).
Seguimiento y Co ntro l: Durante esta fase se realizará un seguimiento de la ejecución de las tareas incluidas en la
planificación para comprobar que se están realizando satisfaciendo los objetivos establecidos en calidad, coste y tiempo. Su
propósito es proporcionar un entendimiento del progreso del proyecto de forma que se puedan tomar las acciones
correctivas apropiadas cuando la ejecución del proyecto se desvié significativamente de su planificación.
Finalizació n: Durante la fase de finalización se establecen las actividades necesarias para formalizar la aceptación del
producto y/o servicio proporcionado. Una vez finalizado el proyecto, se llevarán a cabo la liberación de los recursos
utilizados durante el desarrollo del proyecto.
Los contenidos del ámbito de gestión de proyecto siguen recomendaciones, guías metodológicas y estándares de alto prestigio
como PMBOK
Respo nsabilidades:
Seleccionar herramientas que ofrezcan el soporte adecuado a la gestión de proyectos.
Facilitar las plantillas necesarias para elaborar los documentos de gestión.
Objetivos
Gestionar de forma eficaz el arranque y evolución de un proyecto.
Controlar y actuar frente a las desviaciones que se produzcan en un proyecto.
Facilitar la consecución del cierre técnico y aprobación del proyecto.
Pautas
Carácter de los entregables de Dirección de
Proyectos en función del tamaño del proyecto
Uso de los procedimientos de 'Gestión de
Proyectos'
Uso de herramientas de soporte a la gestión
de proyectos
Recursos
RECU-0447 Organización Gestor Documental Plantilla Recomendado
RECU-0446 Nomenclatura de Documentación Plantilla Recomendado
RECU-0443 Checklist Ciclo de Vida del Proyecto Técnica Recomendado
RECU-0486 Plantilla de Entregable Genérico Plantilla Obligatorio
10
Finalización del Proyecto
Có digo : ING_FINPRO
Durante la fase de finalización se establecen las actividades necesarias para formalizar la aceptación del producto y/o servicio
proporcionado y proceder al cierre formal del proyecto. Una vez finalizado el proyecto, se llevará a cabo la liberación de los
recursos utilizados durante el desarrollo del proyecto.
Pautas
PAUT-0133 Finalización del proyecto o hito relevante Directriz Recomendada
PAUT-0134 Liberación de recursos Directriz Obligatoria
PAUT-0135 Liberación del Software Directriz Obligatoria
Procedimientos
PROC-0029 Procedimiento Finalización del Proyecto Recomendado
Recursos
RECU-0455 Plantilla Informe de Resultados y Cierre Plantilla Obligatorio
Gestión de la Planificación del Proyecto

Có digo : ING_PLNPRO
Durante la fase de Planificación se llevará a cabo la elaboración de la planificación del proyecto, la cuál contendrá las tareas que
se van a realizar, cuándo se realizarán y los entregables que se obtendrán como resultado de dichas tareas. Durante el ciclo de
vida del proyecto, la planificación deberá ser revisada para ajustarla a los cambios ocurridos (tiempos y alcance).
Pautas
PAUT-0124 Elaboración de la planificación Directriz Obligatoria
PAUT-0125 Planificación de entregas parciales Directriz Recomendada
PAUT-0126 Gestión de la planificación del proyecto Directriz Obligatoria
PAUT-0127 Replanificación del proyecto Directriz Obligatoria
Procedimientos
PROC-0027 Procedimiento Gestión de la Planificación del Proyecto Recomendado
Recursos
RECU-0452 Plantilla Solicitud de Replanificación Plantilla Recomendado
RECU-0451 Plantilla Plan de Entregas Plantilla Recomendado
Inicio del Proyecto

Có digo : ING_GESPRO_INI
El inicio de un proyecto consiste en la realización de las actividades encaminadas a lograr el correcto arranque del proyecto y
establecer los aspectos internos y logísticos necesarios para la ejecución del mismo.
Durante esta fase se establecerán las normas de ejecución y el modelo de relación con el cliente para el desarrollo del
proyecto, identificando las personas y recursos claves. Se deberá realizar una puesta en común de los distintos puntos de
vista y comprensión de los objetivos del proyecto por parte de la dirección del mismo y de las áreas participantes.
Pautas
Adecuación a la metodología propuesta por
MADEJA
Alta de recursos necesarios para el
proyecto
PAUT-0121 Definición de roles implicados Directriz Obligatoria
PAUT-0122 Creación del Comité de Seguimiento Directriz Obligatoria
11
PAUT-0123 Celebración de la reunión de arranque Directriz Recomendada
Procedimientos
PROC-0026 Procedimiento Inicio del Proyecto Recomendado
Recursos
1291:9

RECU-0444 Plantilla Presentación de Arranque Plantilla Recomendado

RECU-0445 Plantilla Normas de Gestión del Proyecto Plantilla Obligatorio
Seguimiento y Control de Proyectos

Có digo : ING_SGMCTR
Durante esta fase se realizará un seguimiento de la ejecución de las tareas incluidas en la planificación para comprobar que se
están realizando satisfaciendo los objetivos establecidos en calidad, coste y tiempo. Su propósito es proporcionar un
entendimiento del progreso del proyecto de forma que se puedan tomar las acciones correctivas apropiadas cuando la
ejecución del proyecto se desvíe significativamente de su planificación.
Pautas
PAUT-0128 Seguimiento del avance del proyecto Directriz Obligatoria
PAUT-0129 Gestión del alcance Directriz Obligatoria
PAUT-0130 Gestión de riesgos Directriz Recomendada
PAUT-0131 Comunicación y Difusión de Proyecto Directriz Recomendada
PAUT-0132 Nomenclatura de documentación Directriz Recomendada
Procedimientos
PROC-0028 Procedimiento Seguimiento y Control del Proyecto Recomendado
PROC-0025 Procedimiento Gestión de Peticiones de Proyecto Recomendado
Recursos
RECU-0450 Plantilla Acta de Reunión Plantilla Obligatorio
RECU-0449 Plantilla Informe de Seguimiento Plantilla Obligatorio
RECU-0448 Plantilla Agenda de Reunión Plantilla Recomendado
RECU-0454 Plantilla Informe de Incurridos Plantilla Recomendado
RECU-0479 Plantilla Petición de Cambio Plantilla Obligatorio
Formación
Có digo : ING_FOR
El área de "Formación" proporciona el conjunto de pautas, procedimientos y recursos necesarios para realizar una correcta
gestión de las acciones formativas TIC identificadas, ya sea de carácter general, o como consecuencia de la gestión del cambio
durante la ejecución de un proyecto.
Se describirán las actividades a realizar para la ejecución del Plan de Formación definido, así como la importancia de coordinar las
distintas acciones formativas con las acciones de comunicación; de esta forma, se asegurará que las distintas convocatorias de
formación son comunicadas a todo el público objetivo.
Son aplicables, al menos, a los siguientes tipos de actividades:
Actividades formativas asociadas a proyectos: Los diferentes proyectos llevados a cabo, frecuentemente, tienen asociadas
actividades formativas que tienen como objetivo la divulgación de los proyectos y la difusión y transferencia de
conocimientos relacionados directamente con los mismos y dirigido tanto al área usuaria como a personal técnico.
Actividades de carácter general: Se trata de actividades genéricas (tecnológicas o no) dirigidas a la formación de personal
con competencias en el área de las TIC.
12
Respo nsabilidades:
Seleccionar las herramientas que ofrezcan soporte adecuado a las acciones de formación TIC.
Facilitar los recursos necesarios para llevar a cabo las acciones de formación de forma correcta.
Objetivos
Responder a las necesidades de formación identificadas, garantizando la capacitación de los usuarios relacionados con el
uso, administración y explotación del sistema/proyecto objeto de desarrollo.
Definir y planificar las acciones formativas necesarias para cubrir las necesidades identificadas, elaborando el Plan de
Formación correspondiente.
Evaluar la calidad del Plan de Formación elaborado, de tal forma que se determine la utilidad del mismo y el grado de
cobertura de las necesidades detectadas.
Pautas
PAUT-0145 Uso del procedimiento 'Gestión de Formación' Directriz Recomendada
PAUT-0141 Elaboración del Plan de Formación Directriz Obligatoria
Verificación y evaluación del Plan de
Formación
PAUT-0148 Formato de los materiales de formación Directriz Obligatoria
PAUT-0147 Difusión del material de Formación Directriz Recomendada
PAUT-0149 Propiedad de los materiales de formación Directriz Obligatoria
Carácter de los entregables de Formación en
función del tamaño del proyecto
Uso de un procedimiento para la 'Gestión de
solicitudes a actividades formativas'
Procedimientos
PROC-0034 Procedimiento Gestión de Formación Recomendado
PROC-0035 Procedimiento Gestión de Solicitudes de Formación Recomendado
Recursos
RECU-0474 Plantilla Plan de Formación Plantilla Recomendado
RECU-0475 Plantilla Hoja de Firmas Plantilla Recomendado
RECU-0476 Plantilla Encuesta de Formación Plantilla Recomendado
RECU-0477 Plantilla Informe de Formación Plantilla Recomendado
Source URL: http://madeja.i-administracion.junta-andalucia.es/servicios/madeja/contenido/subsistemas/ingenieria
13
Verificación
El subsistema de verificación trata los procesos asociados a las pruebas y validacio nes de las aplicaciones y sistemas de
información de acuerdo a las directrices y reco mendacio nes marcadas en MADEJA, junto a las especificaciones propias de
cada proyecto y entrega.
Se establece la ejecución de pruebas de calidad desde el inicio de los proyectos hasta su finalización, definiendo un conjunto
de procesos que aplican de forma coordinada con los procesos de desarrollo, con la finalidad de incrementar la calidad de los
proyectos, y establecer un conjunto objetivo de criterios de validación y verificación de las entregas a lo largo del ciclo de vida
de las aplicaciones. Para conseguirlo se ha tenido en cuenta el enfoque de MADEJA acerca del ciclo de vida de desarrollo,
prestando especial atención a los productos esperados en cada etapa (documentación y software). Como resultado se va a
adoptar un mo delo en W para la revisión de estos productos:
Para la ejecución y realización de los servicios a los productos entregados en el ciclo de vida de los proyectos, se establecen
cuatro procesos principales en el subsistema de Verificación: Definició n de la Estrategia de las Pruebas, Testing
Temprano , Entrega So ftware y Validació n y Ajuste de Ento rno s.
Estos procesos se definen en detalle en este subsistema, debiendo ejecutarse de forma ordenada. La importancia del proceso
de Definició n de la Estrategia de Testing es crítica para conseguir articular el resto de los procesos, ya que es donde se
indican las planificacio nes de las entregas, lo s o bjetivo s de las mismas, lo s servicio s co ncreto s de testing
que se quieren ejecutar en cada una de ellas... es el proceso que asegura la coordinación e integración de los objetivos
de los distintos involucrados en el desarrollo y explotación de los sistemas, marcando las directrices y coordinando los trabajos
entre todos.
Además se han introducido las pautas y el procedimiento para la Gestió n de Defecto s que permiten registrar los defectos
detectados durante la ejecución de los servicios de testing solicitados. De esta forma, se comunicarán los defectos detectados
a todos los participantes implicados, permitiendo realizar un seguimiento de los mismos durante el desarrollo del proyecto.
Se asume que las entregas de software se ha realizado de acuerdo a lo especificado en el subsistema de Entorno, área de
Entrega, lo que en resumen implica:
dispo nibilidad del có digo fuente de la aplicación.
Todos los procedimientos de este subsistema se han especificado siguiendo una definición de roles genérica que se deben
especificar en cada Organismo y Consejería de la Junta de Andalucía, para su correcta aplicación.
Estrategia de las Pruebas

Có digo : estrategia_pruebas
La definición de la estrategia de las pruebas de Testing es una parte fundamental dentro del ámbito de la verificació n.
El objetivo perseguido es doble:
Mo delar el pro ceso de verificació n que se va a aplicar sobre las diversas entregas y proyectos en función de la
tipología, criticidad, urgencia y tecnología, así como fijar lo s mínimo s exigibles.
Además se encarga de certificar el grado de adecuación y por tanto la viabilidad de puesta en producción de un determinado
proyecto o entrega, definiendo criterios e indicadores mínimos exigibles para garantizar una evaluació n o bjetiva de lo s
aplicativo s, y registrando las pruebas que se van superando.
1
Esta área constituye el punto de partida para el resto de las áreas del subsistema de verificación, cuyos servicios se
desencadenarán en base a las planificaciones recogidas en el Plan de Testing, además de proporcionar información acerca de
la marcha de los servicios que se están ejecutando sobre una entrega o proyecto.
Pautas
PAUT-0096 Definir la estrategia al inicio del Proyecto Directriz Obligatoria
PAUT-0097 Validar la propuesta de servicios Directriz Obligatoria
PAUT-0098 Establecer los servicios que se van a aplicar Directriz Obligatoria
PAUT-0099 Fijar el nivel de certificación Directriz Recomendada
PAUT-0100 Definir el Plan de Testing Directriz Recomendada
PAUT-0101 Revisar el Plan de Testing Directriz Recomendada
PAUT-0102 Medir los niveles de servicio Directriz Recomendada
Procedimientos
PROC-0014 Procedimiento de Definición de la Estrategia de Pruebas Recomendado
Recursos
Workflow para la implementación de la Estrategia de
las pruebas en NAOS
RECU-0339 Catálogo de Servicios de Testing Técnica Recomendado
RECU-0406 Verificaciones Técnica Recomendado
RECU-0340 Niveles de Certificación Técnica Recomendado
RECU-0341 Documentación del proyecto Técnica Recomendado
RECU-0342 Matriz de Certificación de Entornos Técnica Recomendado
RECU-0343 Plan de Testing Plantilla Recomendado
RECU-0344 Informe Resumen del Testing Plantilla Recomendado
Testing Temprano
Fases del ciclo de vida: Análisis del Sistema de Información (ASI), Diseño del Sistema de Información (DSI)
Perfiles: Comité de Dirección, Responsable de Mantenimiento
Có digo : testing_temprano
El Testing Temprano persigue incrementar la calidad de las aplicaciones mediante la detecció n eficaz de erro res en fases
tempranas del ciclo de vida de un proyecto o entrega, disminuyendo así mismo el impacto que tendría sobre el desarrollo
si estos errores se detectaran con posterioridad.
Para conseguirlo, es necesario revisar la documentación presentada inicialmente por el equipo de desarrollo, y comprobar que
está completa y alineada con las necesidades formuladas inicialmente por el usuario, y que es correcta desde el punto de vista
metodológico. Las comprobaciones más críticas giran en torno a los requisito s recogidos en el documento de requisitos del
sistema, ya que pueden cometerse imprecisiones en su definición que acarrearían graves problemas posteriormente. También
es importante comprobar que la solución propuesta a través del análisis y el diseño no ha obviado o malinterpretado ninguno de
estos requerimientos.
La importancia de los costes asociados a los errores que se pretenden detectar con el Testing Temprano, a veces no es
suficientemente conocido por lo que esta verificación puede considerarse secundaria y no prioritaria. Sin embargo el Testing
Temprano debe estar a la cabeza de las verificaciones planificadas ya que sus resultados son determinantes para el proyecto.
Pautas
LIBP-0164 Verificar los requisitos Directriz Recomendada
PAUT-0103 Definir el Plan de Aceptación Directriz Recomendada
LIBP-0165 Verificar el análisis Directriz Recomendada
LIBP-0166 Verificar el diseño Directriz Recomendada
LIBP-0167 Verificar el Plan de Formación Directriz Recomendada
2
Procedimientos
PROC-0015 Procedimiento de Verificación de Testing Temprano Recomendado
Recursos
RECU-0345 Revisión de Requisitos Servicio Recomendado
RECU-0346 Revisión del Análisis Servicio Recomendado
RECU-0347 Revisión del Diseño Servicio Recomendado
RECU-0348 Revisión del Plan de Formación Servicio Recomendado
RECU-0349 TestLink y el Testing Temprano (versión 1.8.4) Herramienta Recomendado
Configuraciones y recomendaciones de uso de
TestLink (versión 1.8.4)
RECU-0351 Enterprise Architect y el Testing Temprano Herramienta Recomendado
Workflow para la implementación del Testing
Temprano en NAOS
RECU-0354 Informes de revisión para el Testing Temprano Plantilla Recomendado
ASI DSI Requisitos Revisión Testing Temprano Validación Verificación
Verificación de Entrega Software

Fases del ciclo de vida: Implantación y Aceptación del Sistema (IAS)
Perfiles: Responsable de Implantación, Responsable de Sistemas, Responsable de Calidad
Có digo : verificacion_entrega_software
El grueso de las tareas a acometer para la verificación de un producto software se desarrollan sobre los entornos de Pruebas y
Preproducción. El área de Verificació n de Entrega So ftware se encarga exclusivamente de las certificaciones que se
realicen en el ento rno de pruebas, o entorno donde se efectue la entrega del producto software. En este área tienen cabida
dos tipos de pruebas:
Pruebas Técnicas, en este grupo se incluyen las pruebas y los servicios de verificación técnica, orientados a asegurar el
cumplimiento de las diferentes normativas técnicas vigentes. En general estas pruebas aplican sobre el código fuente y los
resultados no son directamente percibidos por el usuario final, aunque permiten una mejora de la calidad en términos de
claridad, mantenibilidad y rendimiento del código.
Pruebas Funcio nales, en este grupo se incluyen las pruebas de verificación funcional, orientadas a asegurar que la
aplicación está libre de errores funcionales. Estas pruebas se ejecutan directamente sobre el aplicativo desplegado y están
muy directamente relacionadas con la percepción de calidad del usuario final, de ahí su extrema importancia.
Pautas
LIBP-0171 Automatización de pruebas funcionales Directriz Recomendada
Buenas prácticas en el diseño de pruebas de
rendimiento
PAUT-0295 Filtros de supresión Directriz Recomendada
PAUT-0106 Generar y evolucionar los planes de prueba Directriz Recomendada
LIBP-0170 Realizar pruebas funcionales Directriz Recomendada
LIBP-0172 Realizar pruebas técnicas Directriz Recomendada
Revisar la documentación sobre las pruebas
de desarrollo
PAUT-0105 Verificar el código estático Directriz Recomendada
LIBP-0169 Verificar la instalación Directriz Recomendada
Procedimientos
PROC-0017 Procedimiento de Verificación de Entrega Software Recomendado
3
Recursos
RECU-0394 Achecker y las pruebas de accesibilidad Herramienta Recomendado
RECU-0364 Certificación de Entornos Servicio Recomendado
RECU-0373 CheckStyle Herramienta Recomendado
RECU-0391 Construcción de Planes de Prueba con JMeter Manual Recomendado
Ejemplo de como hacer configurable un testplan de
JMeter
RECU-0513 Evaluación del Rendimiento de la aplicación Servicio Recomendado
RECU-0703 Filtros de supresión en CheckStyle Referencia Recomendado
RECU-0704 Filtros de supresión en PMD Referencia Recomendado
RECU-0361 Generación de Pruebas de Regresión Servicio Recomendado
RECU-0376 Generación de Reglas para PMD con XPath Herramienta Recomendado
RECU-0367 Generación y diseño de pruebas de rendimiento Servicio Recomendado
RECU-0358 Generación y Evolución de Planes de Pruebas Servicio Recomendado
RECU-0516 GenerateData Herramienta Recomendado
RECU-0385 Grabación de pruebas con Selenium y JUnit Ejemplo Recomendado
Herramientas para la generación y evolución de planes
de pruebas
RECU-0393 Herramientas para la grabación de pruebas Herramienta Recomendado
Herramientas para la verificación de la instalación y del
código estático
RECU-0368 Hudson y la integración continua Herramienta Recomendado
RECU-0396 Informes de revisión de la Entrega de Software Plantilla Recomendado
RECU-0371 Integración de las pruebas unitarias con Maven Herramienta Recomendado
RECU-0388 Introducción a JMeter: Conceptos Básicos Manual Recomendado
RECU-0890 Matrices de verificación del desarrollo Referencia Obligatorio
RECU-0828 Perfil de proyecto sonar para automatización Referencia Recomendado
RECU-0369 Plugins de Hudson Herramienta Recomendado
RECU-0375 Plugin de PMD para Eclipse Herramienta Recomendado
RECU-0126 Plugin Xpath Arquetipo Software Recomendado
RECU-0374 PMD y la calidad estática del código Herramienta Recomendado
RECU-0370 Reporting de Maven Herramienta Recomendado
RECU-0381 Selenium y la automatización de las pruebas Herramienta Recomendado
RECU-0209 SoapUi Referencia Recomendado
RECU-0372 Sonar Herramienta Recomendado
RECU-0378 TestLink y la Gestión de las pruebas Herramienta Recomendado
RECU-0357 Verificación Estática de Código Fuente Servicio Recomendado
RECU-0359 Verificación de Pruebas de Regresión Servicio Recomendado
RECU-0360 Verificación Funcional Servicio Recomendado
RECU-0355 Verificación Proceso de Compilación Servicio Recomendado
RECU-0356 Verificación Proceso de Despliegue Servicio Recomendado
RECU-0363 Verificación y Validación de la Accesibilidad Servicio Recomendado
RECU-0366 Verificación y Validación de Procesos de Migración Servicio Recomendado
RECU-0362 Verificación y Validación de la Usabilidad Servicio Recomendado
RECU-0365 Verificación y Validación del Modelo de Datos Servicio Recomendado
Workflow para la implementación de la Entrega de
Software en NAOS
Testing pruebas entrega software
Verificación y Ajustes en Entorno

Có digo : ver_ajust_ent
En este área se tendrán en cuenta diversas pruebas para el software relacionadas con el comportamiento del mismo ante
4
situaciones extremas, como por ejemplo condiciones de carga y estrés, o bien accidentes o ataques malintencionados que
comprometan la seguridad.
Por tanto el área se centra en aspectos como:
Verificar si el rendimiento de la aplicación es bueno ante situaciones de carga y estrés. Con este objetivo, se situa a la
aplicación ante una serie de condiciones extremas para analizar cómo reacciona.
Verificar el comportamiento de la aplicación ante accidentes, acciones ilícitas o ataques malintencionados que comprometan
la disponibilidad, autenticidad, integridad y confidencialidad de los datos almacenados o transmitidos, poniendo de relieve las
vulnerabilidades de la aplicación o de la infraestructura en la que está montada.
Para la ejecución de este tipo de pruebas se necesita una instalación de la aplicación en un entorno que reúna ciertas
características, que entre otras son:
Que sea un entorno similar al ento rno de pro ducció n, ya que el resultado de este tipo de pruebas puede depender
del entorno en el que nos encontremos, y solo nos interesa el comportamiento que vaya a suceder en producción.
Que sea exclusivo para este tipo de pruebas, para no desvirtuar los resultados debido a las actuaciones que puedan
realizarse sobre la aplicación de forma simultánea.
Pautas
PAUT-0109 Verificar la seguridad de las aplicaciones Directriz Recomendada
PAUT-0110 Verificar la seguridad de los sistemas Directriz Recomendada
PAUT-0111 Realizar pruebas dinámicas Directriz Recomendada
PAUT-0112 Verificar los servicios Web Directriz Recomendada
Procedimientos
PROC-0018 Procedimiento de Verificación y Ajustes en Entornos Recomendado
Recursos
RECU-0397 Verificación y Validación de la Seguridad Servicio Recomendado
RECU-0398 Verificación y validación de los sistemas Servicio Recomendado
RECU-0399 Ajuste y valoración del rendimiento Servicio Recomendado
RECU-0400 Verificación y Validación de Servicios Web Servicio Recomendado
RECU-0401 Ejecución de Pruebas con JMeter Manual Recomendado
Pruebas de rendimiento con ventanas emergentes y/o
protocolo HTTPS
Workflow para la implementación de la Verificación y
Ajustes en NAOS
Productos a generar como salida de la ejecución de un
test con JMeter
Informes de revisión de la Verificación y Ajustes en
Entornos
RECU-0224 JMeter Ficha Técnica Recomendado
Procesos transversales
Fases del ciclo de vida: Análisis del Sistema de Información (ASI), Diseño del Sistema de Información (DSI), Construcción
del Sistema de Información (CSI)
Perfiles: Comité de Dirección, Responsable de Mantenimiento
Có digo : procesos_transversales
Los procesos transversales del subsistema de verificación se dividen en proceso de formalización de defectos y en la definición
y seguimiento de los acuerdos de niveles de servicio en la ejecución de los mismos.
La formalización de los defectos es un proceso que se ejecuta constantemente dentro de los servicios de testing, cada vez que
se encuentra una discrepancia entre la definición del alcance de la aplicación y los resultados obtenidos en las pruebas.
A partir del catálogo de servicios definido en este subsistema se hace necesario establecer los indicadores que van a medir los
resultados obtenidos de la implantación y aplicación de este catálogo. Estos indicadores no sólo van a servir para medir la
calidad de lo s servicio s definidos, sino que persiguen la calidad última de lo s sistemas de info rmació n o bjeto
del testing. La implementación de los indicadores va a depender de:
5
Las herramientas elegidas como soporte para la gestión del testing.
Del mo delo utilizado para la gestión del testing.
Pautas
LIBP-0168 Formalización de Defectos Directriz Recomendada
PAUT-0104 Elaborar un informe Directriz Recomendada
Procedimientos
PROC-0016 Procedimiento Formalización de los Defectos Recomendado
Recursos
RECU-0491 Indicadores de Nivel de Servicio Página Obligatorio
RECU-0353 Defecto Técnica Recomendado
ANS Defectos Fallos Incidencias SLA Testing
Source URL: http://madeja.i-administracion.junta-andalucia.es/servicios/madeja/contenido/subsistemas/verificacion

Tema16.3 Madeja

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Tema16.3 Madeja

Încărcat de

Drepturi de autor:

Formate disponibile

Published on Marco de Desarrollo de la Junta de Andalucía (http://madeja.i-administracion.

Source URL: http://madeja.i-administracion.junta-andalucia.es/servicios/madeja/contenido/definicion

Source URL: http://madeja.i-administracion.junta-andalucia.es/servicios/madeja/contenido/objetivos

Source URL: http://madeja.i-administracion.junta-andalucia.es/servicios/madeja/contenido/subsistemas

Arquitectura de Sistemas de Información

GUIA: Gestión Unificada de Identidades de Andalucía

SIGC: Sistema de Información Geográfica Corporativo

Uso de Alfresco desde Terceras Aplicaciones

Ejemplos Ampliados de Acceso a Alfresco

Estructuras por Lenguajes

Estructura por Funcionalidades

Capa de Acceso a Datos

Source URL: http://madeja.i-administracion.junta-andalucia.es/servicios/madeja/contenido/subsistemas/arquitectura

Catálogo de Software de la Junta de Andalucía

Source URL: http://madeja.i-administracion.junta-andalucia.es/servicios/madeja/contenido/subsistemas/catalogo

Fases del ciclo de vida: Construcción del Sistema de Información (CSI)

Especificaciones de Codificación y Construcción

Construcción de Aplicaciones por Capas

Có digo Título Tipo Carácter

Có digo Título Tipo Carácter

Có digo Título Tipo Carácter

Có digo Título Tipo Carácter

Có digo Título Tipo Carácter

Có digo Título Tipo Carácter

Có digo Título Tipo Carácter

Có digo Título Tipo Carácter

Có digo Título Tipo Carácter

Control de Acceso y Autenticación

Codificación y Validación de entrada/salida

Gestión de Sesiones y Usuarios

Gestión de Errores y Excepciones

Có digo Título Tipo Carácter

Có digo Título Tipo Carácter

Có digo Título Tipo Carácter

Librerías para el Tratamiento de XML

Có digo Título Tipo Carácter

Librerías para Seguridad

Có digo Título Tipo Carácter

Librerías para Logging

Có digo Título Tipo Carácter

Librerías para Pruebas

Có digo Título Tipo Carácter

Librerías para Generación de Informes

Có digo Título Tipo Carácter

Librerías para Comunicaciones

Có digo Título Tipo Carácter

Có digo Título Tipo Carácter

Có digo Título Tipo Carácter

Có digo Título Tipo Carácter

Có digo Título Tipo Carácter

Có digo Título Tipo Carácter

Có digo Título Tipo Carácter

Có digo Título Tipo Carácter

Có digo Título Tipo Carácter

Source URL: http://madeja.i-administracion.junta-andalucia.es/servicios/madeja/contenido/subsistemas/desarrollo

usable usabilidad interfaz interaccion personas ordenador

Usabilidad General – Interacción Personas Ordenador (IPO)

usable usabilidad interacción persona ordenador

Usabilidad en aplicaciones web

interfaz acceso accesibilidad

Accesibilidad en aplicaciones web (WCAG)

La declaración de conformidad es opcional, pero si se añade debe incluir la siguiente información:

Accesibilidad en aplicaciones web enriquecidas (WAI-ARIA)