Documentos de Académico
Documentos de Profesional
Documentos de Cultura
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.
1
Published on Marco de Desarrollo de la Junta de Andalucía (http://madeja.i-administracion.junta-
andalucia.es/servicios/madeja)
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.
1
Published on Marco de Desarrollo de la Junta de Andalucía (http://madeja.i-administracion.junta-
andalucia.es/servicios/madeja)
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:
1
Published on Marco de Desarrollo de la Junta de Andalucía (http://madeja.i-administracion.junta-
andalucia.es/servicios/madeja)
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.
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
LIBP-0208 Directriz Obligatoria
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
Có digo Título Tipo Carácter
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
RECU-0434 Referencia Recomendado
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
RECU-0438 Referencia Recomendado
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
RECU-0506 Ejemplo Recomendado
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
RECU-0512 Ejemplo Recomendado
J2EE
Seguridad
Pautas
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
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
RECU-0025 Ejemplo Recomendado
Urbana del Callejero Digital de Andalucía
Ejemplo de Petición del Servicio de Cartografía
RECU-0026 Ejemplo Recomendado
Urbana desde gvSIG
Ejemplo de Petición de Servicio de Cartografía
RECU-0027 Ejemplo Recomendado
Urbana desde ArcGIS
Ejemplo de como Cargar Información Geográfica en
RECU-0028 Ejemplo Recomendado
Postgis y Oracle
Consejos para la Instalación y Configuración de
RECU-0029 Ejemplo Recomendado
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
Có digo Título Tipo Carácter
PAUT-0023 Opciones de desarrollo con Alfresco Consejo
Pautas
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
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
4
Categorías y Aspectos
Reglas y Procedimientos
Consulta de Documentos
Gestión de Documentos
Consulta de Espacios
Gestión de Espacios
Java JCR API
Búsquedas
Gestión Integrada de Usuarios
Categorías y Aspectos
Reglas y Procedimientos
Consulta de Documentos
Gestión de Documentos
Consulta de Espacios
Gestión de Espacios
Java Script
Búsquedas
Gestión Integrada de Usuarios
Categorías y Aspectos
Reglas y Procedimientos
Consulta de Documentos
Gestión de Documentos
Consulta de Espacios
Gestión de Espacios
Web Script
Búsquedas
Gestión Integrada de Usuarios
Categorías y Aspectos
Reglas y Procedimientos
Uso Avanzado
Tabla de funcio nalidades
Java API
Java JCR API
Búsquedas
JavaScript
WebScript
Java API
Java JCR API
5
Java JCR API
Gestión Integrada de Usuarios
JavaScript
WebScript
Java API
Java JCR API
Categorías y Aspectos
JavaScript
WebScript
Java API
Java JCR API
Reglas y procedimientos
JavaScript
WebScript
Recurso s
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
PAUT-0026 Extension de clases base Directriz Obligatoria
Metodo de despliegue de extensiones
PAUT-0027 Directriz Recomendada
en Alfresco
LIBP-0002 Desarrollo del modelo de contenidos Directriz Obligatoria
6
Recurso s
Có digo Título Tipo Carácter
Métodos para el despliegue de extensiones de
RECU-0049 Manual Recomendado
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
Có digo Título Tipo Carácter
LIBP-0005 Arquitectura Tecnológica de Referencia Directriz Recomendada
Buenas prácticas en el diseño de la
LIBP-0074 Directriz Obligatoria
escalabilidad
LIBP-0073 Buenas prácticas en el manejo de la caché Directriz Obligatoria
Buenas practicas en el manejo de la caché en
LIBP-0356 Directriz Obligatoria
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
LIBP-0323 Directriz Obligatoria
entidad en Hibernate
LIBP-0026 Mecanismos de configuración Directriz Obligatoria
Recursos
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
RECU-0093 Spring Ficha Técnica Recomendado
RECU-0094 Seam Ficha Técnica Recomendado
RECU-0095 Enterprise JavaBeans 3 Ficha Técnica Recomendado
Recursos
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
LIBP-0006 Creación de Servicios Web Directriz Obligatoria
Identificación de Mensajes y EndPoints (WS-
PAUT-0031 Directriz Obligatoria
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
Có digo Título Tipo Carácter
RECU-0100 Especificaciones y estándares de servicios web Especificación Recomendado
Plataforma de Interoperabilidad de la Junta de
RECU-0019 Ficha Recomendado
Andalucía
9
Published on Marco de Desarrollo de la Junta de Andalucía (http://madeja.i-administracion.junta-
andalucia.es/servicios/madeja)
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
Pautas
Có digo Título Tipo Carácter
PAUT-0034 Disponibilidad del software Directriz Obligatoria
Incorporación del Software al Catálogo de
PAUT-0002 Directriz Obligatoria
Software de la Junta de Andalucía
Incorporación de librerías al Catálogo de
LIBP-0237 Directriz Obligatoria
Software de la Junta de Andalucía
Procedimientos
Có digo Título Carácter
PROC-0002 Procedimiento Publicación en el Catálogo y Repositorio Obligatorio
Recursos
Có digo Título Tipo Carácter
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
1
Published on Marco de Desarrollo de la Junta de Andalucía (http://madeja.i-administracion.junta-
andalucia.es/servicios/madeja)
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
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
Có digo Título Tipo Carácter
PAUT-0035 Licenciamiento del Software Directriz Obligatoria
Recursos
Có digo Título Tipo Carácter
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
Pautas
Có digo Título Tipo Carácter
LIBP-0008 Convenio de codificación general Directriz Obligatoria
Convenio de codificación específico para
LIBP-0124 Directriz Obligatoria
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
LIBP-0009 Directriz Obligatoria
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
Có digo Título Tipo Carácter
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
Implementación de convenios de codificación en
RECU-0735 Ejemplo Obligatorio
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
Implementación de convenios de codificación en
RECU-0733 Ejemplo Recomendado
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
Pautas
Có digo Título Tipo Carácter
PAUT-0321 Separación por capas Directriz Recomendada
Java
PHP
Recursos
PHP
Java
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
Có digo Título Tipo Carácter
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
PAUT-0320 Directriz Recomendada
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
PAUT-0322 Directriz Recomendada
mantenimiento de sistemas de información
Buenas prácticas en el uso de Direct Web
LIBP-0354 Directriz Recomendada
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
Có digo Título Carácter
PROC-0008 Proceso de construcción de la capa de presentación Recomendado
Recursos
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
Buenas prácticas en la construcción de la
LIBP-0012 Directriz Obligatoria
capa de negocio
Buenas prácticas en la construcción de la
LIBP-0043 Directriz Obligatoria
capa de negocio con EJB3
Buenas prácticas en la construcción de la
LIBP-0042 Directriz Obligatoria
capa de negocio con Seam
4
Buenas prácticas en la construcción de la
LIBP-0339 Directriz Obligatoria
capa de negocio con Spring
Vulnerabilidades de Spring con la capa de
LIBP-0340 Directriz Recomendada
presentación
Procedimientos
Có digo Título Carácter
PROC-0007 Procedimiento de construcción de la capa de negocio Recomendado
Recursos
Có digo Título Tipo Carácter
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
PHP
Procedimientos
Có digo Título Carácter
PROC-0009 Procedimiento de construcción de la capa de persistencia Recomendado
Recursos
Có digo Título Tipo Carácter
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
RECU-0818 Referencia Recomendado
persistencia
RECU-0881 Matriz de verificación de capa de persistencia Plantilla Recomendado
Java
5
Có digo Título Tipo Carácter
RECU-0676 Apache Cayenne Referencia No recomendado
Configuración del "pool" de conexiones en
RECU-0660 Ejemplo Obligatorio
Hibernate
RECU-0177 Referencia a iBatis Referencia Permitido
Implementando equals() y hashCode() utilizando
RECU-0663 Ejemplo Recomendado
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
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
Có digo Título Tipo Carácter
LIBP-0360 Uso de applets Directriz Obligatoria
Recursos
6
Có digo Título Tipo Carácter
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
RECU-0551 Especificación Recomendado
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
Objetivos
Asegurar la identidad de los usuarios que acceden a las aplicaciones
Garantizar el acceso a recursos protegidos
Pautas
7
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
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
RECU-0564 Ejemplo Obligatorio
en Java
RECU-0562 Canal accesible por un punto no final en Java Ejemplo Obligatorio
Comprobación de la perdida de autenticación sobre
RECU-0667 Ejemplo Obligatorio
funciones significativas en Java
Comprobar los permisos de un nodo específico
RECU-0555 Ejemplo Obligatorio
utilizando node_access en Drupal
Comprobar los permisos mediante la función
RECU-0566 Ejemplo Obligatorio
user_access en Drupal
Conceptos de seguridad en la capa de negocio
RECU-0210 Referencia Recomendado
mediante Spring
RECU-0213 Configuración de Spring Security Referencia Recomendado
Consultas para el acceso a nodos restringidos en
RECU-0556 Ejemplo Recomendado
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
RECU-0565 Ejemplo Obligatorio
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
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
Có digo Título Tipo Carácter
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
PAUT-0249 Directriz Obligatoria
finales
Protección de la información en los
PAUT-0248 Directriz Obligatoria
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
Có digo Título Tipo Carácter
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
RECU-0600 Ejemplo Obligatorio
sistema en Java
Uso de check_plain() y t() para limpiar los caracteres
RECU-0670 Ejemplo Obligatorio
de las salida en PHP
Uso de la función filter_xss() para proteger de los
RECU-0671 Ejemplo Obligatorio
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
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
RECU-0581 Almacenamiento de las contraseñas en PHP Ejemplo Obligatorio
Almacenar datos encriptados en una base de datos
RECU-0584 Ejemplo Obligatorio
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
RECU-0596 Especificación Recomendado
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
RECU-0571 Referencia Recomendado
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
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
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
Almacenamiento de objetos no serializables en
RECU-0588 Ejemplo Obligatorio
HttpSession
RECU-0591 Cambio del identificador de sesión en PHP Ejemplo Obligatorio
Configuración de la carpeta donde se almacenan las
RECU-0589 Ejemplo Obligatorio
sesiones
Denegación al JavaScript del navegador del acceso a
RECU-0590 Ejemplo Recomendado
las cookies
Eliminación de sesiones antes de un nuevo acceso
RECU-0665 Ejemplo Obligatorio
en Java
Identificador de sesión generado por el servidor en
RECU-0592 Ejemplo Obligatorio
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
Pautas
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
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
RECU-0668 Ejemplo Obligatorio
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
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
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
LIBP-0332 Directriz Obligatoria
datos
Rendimiento de las consultas a la base de
LIBP-0333 Directriz Obligatoria
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
Có digo Título Tipo Carácter
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
PHP
Recursos
Módulos para Drupal
15
RECU-0290 Taxonomy Ficha Técnica Recomendado
RECU-0288 Token Ficha Técnica Recomendado
RECU-0299 Views Ficha Técnica Recomendado
16
Librerías para la Construcción de Aplicaciones
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
Có digo Título Tipo Carácter
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
Capa de negocio
Capa de persistencia
Recursos
Có digo Título Tipo Carácter
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
RECU-0204 Especificación Recomendado
Desarrollo
Especificación de los Antipatrones de diseño de
RECU-0820 Especificación Recomendado
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
Capa de negocio
Capa de persistencia
18
Published on Marco de Desarrollo de la Junta de Andalucía (http://madeja.i-administracion.junta-
andalucia.es/servicios/madeja)
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
Có digo Título Tipo Carácter
RECU-0151 Información general sobre usabilidad Referencia Recomendado
RECU-0539 Usabilidad - Aplicación del principio de Pareto Técnica Recomendado
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
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
RECU-0157 Asociación Interacción Persona-Ordenador Referencia Recomendado
RECU-0386 Informe de corrección - STILUS Herramienta Recomendado
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
Có digo Título Tipo Carácter
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-0044 Formularios Directriz Obligatoria
LIBP-0045 Búsqueda y filtro de contenidos Directriz Recomendada
LIBP-0235 Listados Directriz Obligatoria
Recursos
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
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
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
Có digo Título Tipo Carácter
LIBP-0077 Simple A Directriz Obligatoria
LIBP-0078 Doble A Directriz Obligatoria
LIBP-0079 Tiple A Directriz Obligatoria
Recursos
Có digo Título Tipo Carácter
RECU-0253 Pautas WCAG2.0 Referencia Recomendado
RECU-0250 Validador de contenidos Herramienta Recomendado
RECU-0251 Contraste de color Herramienta Recomendado
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"
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
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
RECU-0303 Accessible Rich Internet Applications (WAI-ARIA) 1.0 Referencia Recomendado
RECU-0305 WAI-ARIA 1.0 Authoring Practices Ejemplo Recomendado
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
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
RECU-0314 Desarrollo de interfaces adaptativas Referencia Recomendado
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
Có digo Título Tipo Carácter
PAUT-0073 Contenido alternativo imágenes Directriz Obligatoria
PAUT-0074 Contenido alternativo multimedia Directriz Obligatoria
PAUT-0075 Controles de formulario Directriz Obligatoria
Recursos
Có digo Título Tipo Carácter
RECU-0317 Uso del texto alternativo Referencia Recomendado
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
Có digo Título Tipo Carácter
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:
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
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
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
Có digo Título Carácter
PROC-0005 Guía de decisión de componentes Recomendado
10
Recursos
Có digo Título Tipo Carácter
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
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
Có digo Título Tipo Carácter
Esquema general de las pantallas de primer
LIBP-0122 Directriz Obligatoria
nivel
Esquema general de las pantallas de
LIBP-0123 Directriz Obligatoria
segundo nivel
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
Có digo Título Tipo Carácter
LIBP-0083 Acceso a la aplicación Directriz Obligatoria
PAUT-0059 Desconexión Directriz Obligatoria
PAUT-0060 Atrás Directriz Obligatoria
LIBP-0084 Listados 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
Có digo Título Tipo Carácter
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
LIBP-0143 Directriz Obligatoria
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
LIBP-0174 Directriz Obligatoria
eliminación
LIBP-0234 Prototipo de pantalla de inicio Directriz Obligatoria
LIBP-0236 Prototipo de pantalla de contenidos Directriz Obligatoria
Objetivos
Definir los elementos más utilizados en el desarrollo de interfaces de usuario.
Normalizar el uso de componentes de interfaz.
Pautas
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
RECU-0015 Fichas de componentes de interfaz Referencia Recomendado
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
Có digo Título Tipo Carácter
Componentes básicos de un formulario en
LIBP-0156 Directriz Obligatoria
RichFaces
Elementos de agrupación de componentes
LIBP-0157 Directriz Obligatoria
en RichFaces
LIBP-0158 Componentes de selección en RichFaces Directriz Obligatoria
LIBP-0159 Componente menú en RichFaces Directriz Obligatoria
Otros componentes permitidos en
LIBP-0160 Directriz Recomendada
RichFaces
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
Có digo Título Tipo Carácter
LIBP-0179 Componentes de interfaz para informes Directriz Obligatoria
LIBP-0194 Formato de impresión para interfaces web Directriz Obligatoria
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
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
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
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
Có digo Título Tipo Carácter
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-0222 Formularios Directriz Obligatoria
LIBP-0228 Cabecera Directriz Obligatoria
LIBP-0229 Enlaces Directriz Obligatoria
LIBP-0088 Listados Directriz Obligatoria
Recursos
Có digo Título Tipo Carácter
RECU-0478 Imagen genérica Plantilla Recomendado
14
Source URL: http://madeja.i-administracion.junta-andalucia.es/servicios/madeja/contenido/subsistemas/interfaz-usuario
15
Published on Marco de Desarrollo de la Junta de Andalucía (http://madeja.i-administracion.junta-
andalucia.es/servicios/madeja)
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
Pautas
Có digo Título Tipo Carácter
PAUT-0289 Uso de Java7 Directriz Recomendada
PAUT-0323 IDE de desarrollo Directriz Recomendada
Recursos
Có digo Título Tipo Carácter
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
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
Có digo Título Tipo Carácter
Uso de herramientas para la gestión de
LIBP-0137 Directriz Obligatoria
entregas
Uso de procedimientos para la gestión de
LIBP-0138 Directriz Obligatoria
entregas
Definición del entorno de entrega o recepción
PAUT-0082 Directriz Recomendada
del software
Herramienta de integración continua en la
PAUT-0091 Directriz Recomendada
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
PAUT-0089 Directriz Obligatoria
de Base de Datos
Procedimientos
Có digo Título Carácter
PROC-0010 Procedimiento de Entrega de Software Recomendado
PROC-0011 Procedimiento de Entrega de Documentación Recomendado
Recursos
Có digo Título Tipo Carácter
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
RECU-0326 Manual Recomendado
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
Có digo Título Tipo Carácter
Aseguramiento de la compilación de las
PAUT-0080 Directriz Obligatoria
entregas software
Uso del Repositorio de Artefactos de
PAUT-0083 Directriz Obligatoria
MADEJA
Homogeneización de la coordenada
PAUT-0084 Directriz Obligatoria
"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
PAUT-0179 Directriz Obligatoria
de MADEJA desde Organismos de la Junta
Publicación de artefactos propios de una
PAUT-0180 Directriz Obligatoria
Consejería u Organismo
Recomendaciones a la administración del
LIBP-0149 Directriz Recomendada
repositorio
Desplegar artefactos no libres en un
PAUT-0178 Directriz Obligatoria
repositorio
Procedimientos
Có digo Título Carácter
PROC-0013 Procedimiento Solicitud de Actualización de Artifactory Recomendado
Recursos
Có digo Título Tipo Carácter
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
RECU-0018 Ficha Recomendado
Hudson
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
Có digo Título Tipo Carácter
Solicitud de Despliegues en Entornos de
PAUT-0058 Directriz Recomendada
Producción
PAUT-0305 Uso de URLs semánticas Directriz Recomendada
Procedimientos
Có digo Título Carácter
PROC-0012 Procedimiento Gestión de Despliegues Recomendado
Recursos
Có digo Título Tipo Carácter
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
RECU-0729 Ejemplo Recomendado
3
RECU-0729 Ejemplo Recomendado
UrlRewriteFilter
RECU-0777 Configuración del servidor de aplicaciones JBoss Referencia Recomendado
RECU-0111 Configuración del servidor de aplicaciones Tomcat Referencia Recomendado
4
Published on Marco de Desarrollo de la Junta de Andalucía (http://madeja.i-administracion.junta-
andalucia.es/servicios/madeja)
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
Có digo Título Tipo Carácter
Pauta sobre entregables asociados al
PAUT-0151 Directriz Obligatoria
subsistema de Ingeniería
PAUT-0150 Uso de plantillas Directriz Obligatoria
Recursos
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
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
PAUT-0140 Directriz Recomendada
y Difusión en función del tamaño del proyecto
Uso de procedimientos de Difusión y
LIBP-0232 Directriz Recomendada
Comunicación
Procedimientos
Có digo Título Carácter
PROC-0031 Procedimiento Comunicación y Difusión de Proyectos Recomendado
PROC-0032 Procedimiento Participación Grupos de Interés Recomendado
Recursos
Có digo Título Tipo Carácter
RECU-0471 Plantilla Plan de Comunicación Plantilla Recomendado
2
RECU-0472 Documento Canales y Acciones de Comunicación Referencia Recomendado
1291:2
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
Có digo Título Tipo Carácter
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
Có digo Título Carácter
PROC-0030 Creación y Evolución de Sistemas Recomendado
Recursos
Có digo Título Tipo Carácter
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
Có digo Título Carácter
PROC-0023 Procedimiento General en la Ingeniería de Requisitos Obligatorio
PROC-0022 Procedimientos de Análisis de Requisitos Obligatorio
Recursos
Có digo Título Tipo Carácter
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
RECU-0420 Herramienta Recomendado
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
RECU-0421 Plantilla Recomendado
Architect
Posibilidades de Infraestructura y Mantenimiento de
RECU-0422 Herramienta Recomendado
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
RECU-0417 Técnica Recomendado
el análisis de requisitos
RECU-0414 Verificación de Requisitos Técnica Recomendado
Pautas
Có digo Título Tipo Carácter
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
LIBP-0186 Directriz Obligatoria
sistema
Registrar la trazabilidad los requisitos del
LIBP-0187 Directriz Obligatoria
sistema
Procedimientos
Có digo Título Carácter
Procedimiento para desarrollar los requisitos de un sistema software que
PROC-0020 Obligatorio
satisfaga las necesidades de negocio
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
Có digo Título Tipo Carácter
Gestionar las lineas base y peticiones de
LIBP-0188 Directriz Obligatoria
cambio a los requisitos del sistema
Gestionar los problemas de los requisitos
LIBP-0189 Directriz Obligatoria
del sistema
Mantener la trazabilidad de los requisitos del
LIBP-0190 Directriz Obligatoria
sistema
Procedimientos
Có digo Título Carácter
PROC-0021 Procedimiento para la gestión de requisitos Obligatorio
Pautas
Có digo Título Tipo Carácter
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
LIBP-0180 Directriz Obligatoria
clientes y usuarios
Procedimientos
Có digo Título Carácter
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
Có digo Título Tipo Carácter
Carácter de los entregables de Dirección de
PAUT-0136 Directriz Recomendada
Proyectos en función del tamaño del proyecto
Uso de los procedimientos de 'Gestión de
PAUT-0137 Directriz Recomendada
Proyectos'
Uso de herramientas de soporte a la gestión
PAUT-0138 Directriz Recomendada
de proyectos
Recursos
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
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
Có digo Título Carácter
PROC-0029 Procedimiento Finalización del Proyecto Recomendado
Recursos
Có digo Título Tipo Carácter
RECU-0455 Plantilla Informe de Resultados y Cierre Plantilla Obligatorio
Pautas
Có digo Título Tipo Carácter
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
Có digo Título Carácter
PROC-0027 Procedimiento Gestión de la Planificación del Proyecto Recomendado
Recursos
Có digo Título Tipo Carácter
RECU-0452 Plantilla Solicitud de Replanificación Plantilla Recomendado
RECU-0451 Plantilla Plan de Entregas Plantilla Recomendado
Pautas
Có digo Título Tipo Carácter
Adecuación a la metodología propuesta por
PAUT-0118 Directriz Recomendada
MADEJA
Alta de recursos necesarios para el
PAUT-0120 Directriz Obligatoria
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
Có digo Título Carácter
PROC-0026 Procedimiento Inicio del Proyecto Recomendado
Recursos
1291:9
Pautas
Có digo Título Tipo Carácter
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
Có digo Título Carácter
PROC-0028 Procedimiento Seguimiento y Control del Proyecto Recomendado
PROC-0025 Procedimiento Gestión de Peticiones de Proyecto Recomendado
Recursos
Có digo Título Tipo Carácter
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
Có digo Título Tipo Carácter
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
PAUT-0142 Directriz Recomendada
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
PAUT-0143 Directriz Recomendada
función del tamaño del proyecto
Uso de un procedimiento para la 'Gestión de
PAUT-0144 Directriz Recomendada
solicitudes a actividades formativas'
Procedimientos
Có digo Título Carácter
PROC-0034 Procedimiento Gestión de Formación Recomendado
PROC-0035 Procedimiento Gestión de Solicitudes de Formación Recomendado
Recursos
Có digo Título Tipo Carácter
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
13
Published on Marco de Desarrollo de la Junta de Andalucía (http://madeja.i-administracion.junta-
andalucia.es/servicios/madeja)
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.
Pautas
Có digo Título Tipo Carácter
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
Có digo Título Carácter
PROC-0014 Procedimiento de Definición de la Estrategia de Pruebas Recomendado
Recursos
Có digo Título Tipo Carácter
Workflow para la implementación de la Estrategia de
RECU-0338 Herramienta Recomendado
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
Có digo Título Tipo Carácter
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
Có digo Título Carácter
PROC-0015 Procedimiento de Verificación de Testing Temprano Recomendado
Recursos
Có digo Título Tipo Carácter
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
RECU-0350 Herramienta Recomendado
TestLink (versión 1.8.4)
RECU-0351 Enterprise Architect y el Testing Temprano Herramienta Recomendado
Workflow para la implementación del Testing
RECU-0352 Herramienta Recomendado
Temprano en NAOS
RECU-0354 Informes de revisión para el Testing Temprano Plantilla Recomendado
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
Có digo Título Tipo Carácter
LIBP-0171 Automatización de pruebas funcionales Directriz Recomendada
Buenas prácticas en el diseño de pruebas de
LIBP-0075 Directriz Obligatoria
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
PAUT-0107 Directriz Recomendada
de desarrollo
PAUT-0105 Verificar el código estático Directriz Recomendada
LIBP-0169 Verificar la instalación Directriz Recomendada
Procedimientos
Có digo Título Carácter
PROC-0017 Procedimiento de Verificación de Entrega Software Recomendado
3
Recursos
Có digo Título Tipo Carácter
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
RECU-0392 Ejemplo Recomendado
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
RECU-0379 Herramienta Recomendado
de pruebas
RECU-0393 Herramientas para la grabación de pruebas Herramienta Recomendado
Herramientas para la verificación de la instalación y del
RECU-0377 Herramienta Recomendado
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
RECU-0395 Herramienta Recomendado
Software en NAOS
Pautas
Có digo Título Tipo Carácter
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
Có digo Título Carácter
PROC-0018 Procedimiento de Verificación y Ajustes en Entornos Recomendado
Recursos
Có digo Título Tipo Carácter
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
RECU-0402 Herramienta Recomendado
protocolo HTTPS
Workflow para la implementación de la Verificación y
RECU-0403 Herramienta Recomendado
Ajustes en NAOS
Productos a generar como salida de la ejecución de un
RECU-0404 Técnica Recomendado
test con JMeter
Informes de revisión de la Verificación y Ajustes en
RECU-0405 Plantilla Recomendado
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
Có digo Título Tipo Carácter
LIBP-0168 Formalización de Defectos Directriz Recomendada
PAUT-0104 Elaborar un informe Directriz Recomendada
Procedimientos
Có digo Título Carácter
PROC-0016 Procedimiento Formalización de los Defectos Recomendado
Recursos
Có digo Título Tipo Carácter
RECU-0491 Indicadores de Nivel de Servicio Página Obligatorio
RECU-0353 Defecto Técnica Recomendado