 Según la aplicación del ENI, se utilizarán estándares abiertos.

 Formatos estándares aprobados por las NTI:

o GZIP, ZIP
o MP4 vídeo
o OGG Vorbis
o JPEG, PNG
o PDF, PDF/A, TXT
o HTML, XML
 Metadatos mínimos de documento electrónico (NTI documento electrónico):
o Versión NTI
o Identificador
o Órgano (generador del documento)
o Fecha captura
o Origen (ciudadano=0, admon=1)
o Estado de elaboración
o Nombre de formato
o Tipo documental
o Tipo de firma
o Valor CSV
o Definición generación CSV
o Identificador de documento origen
 Metadatos mínimos de documento electrónico digitalizado (NTI digitalizaciones):
o Mismos que documento electrónico
o Firma electrónica
 Resolución (mínimo de 200 ppp) [Opcional]
 Tamaño [Opcional]
 Idioma (mayoritario si hay varios) [Opcional]
 Metadatos mínimos de copia electrónica de documento (NTI procedimientos copiado):
o Mismos que documento electrónico
 Estado de elaboración  “Copia electrónica auténtica con cambio de
formato”, “Copia electrónica auténtica de documento papel”, “Copia
electrónica auténtica con cambio de formato”, “Copia electrónica
parcial auténtica”
o Firma electrónica
 Componentes de expediente electrónico (RD 4/2010):
o Documentos electrónicos
o Índice electrónico
o Firma del índice electrónico
o Metadatos
 Metadatos mínimos de expediente electrónico (NTI expediente electrónico):
o Versión NTI
o Identificador
o Órgano (tramitador del procedimiento)
o Fecha apertura expediente
o Clasificación
 o Estado (Abierto, Cerrado, Índice para remisión cerrado)
o Identificador interesado
o Tipo de firma
o Valor CSV
o Definición generación CSV
 Metadatos mínimos de asientos electrónicos (Ley 39/2015):
o Número
o Epígrafe
o Fecha y hora presentación
o Identificación interesado
o Órgano administrativo remitente
o Persona u Órgano administrativo destino
o Referencia del contenido
o Justificante firmado
 Solicitud de inicio de procedimiento, campos mínimos:
o Nombre y apellidos de los interesados y de su representante.
o Petición.
o Lugar y fecha.
o Firma solicitante.
o Órgano destino.
 Intercambio de documentos y expedientes electrónicos  INSIDE
 Archivo de documentos y expedientes electrónicos  ARCHIVE
MODELOS DE CICLO DE VIDA (MCV)
El objetivo es identificar el MCV más adecuado, para lo cual tendremos que seguir los siguientes pasos:
1. Evaluación de las características de nuestro proyecto.
2. Identificación de alternativas de MCV.
3. Análisis de ventajas e inconvenientes.

A continuación se describen las principales características de un proyecto que influyen en la determinación del MCV más
adecuado y se describen los MCV habituales proporcionándose un análisis de ventajas e inconvenientes.

ELEMENTOS DE SELECCIÓN

Como principales criterios de selección tendremos que evaluar las siguientes características de nuestro proyecto:
 Estabilidad de los requisitos.
 Comprensión de requisitos.
 Tamaño del proyecto.
 Novedad y experiencia en el área de aplicación.
 Plazo para el desarrollo del proyecto.

MODELOS DE CICLO DE VIDA HABITUALES

CASCADA O CLÁSICO

Se avanza de una fase a la siguiente de una forma secuencial estableciéndose revisiones al final de cada etapa, siendo
necesario completar cada una de ellas para pasar a la siguiente.

Típicamente se definen las siguientes fases: Análisis, Diseño, Codificación, Pruebas e Integración, Implantación y
aceptación, y Mantenimiento.

Este MCV es adecuado si:

 Requisitos no cambiantes.
 Experiencia previa en productos análogos.

Ventajas:
 Organización de las etapas de un modo lógico.
 Facilita la organización y gestión del proyecto.
 Aplicación sencilla.

Inconvenientes:
 Dificultad para establecer al principio todos los requisitos.
 Inseguridad por parte del cliente que quiere ir viendo los avances en el producto.

EVOLUTIVO

Se lleva a cabo una implementación parcial del producto con los requisitos conocidos, que se utiliza para comprender la
totalidad de los requisitos. La solución evoluciona en iteraciones hasta cumplir con las necesidades.

Este MCV es adecuado si los requisitos no están claros y pueden cambiar.

Ventajas:
 Buen punto de partida para identificar mejoras.
 Se pueden ir refinando los requisitos en las iteraciones, por lo que no es necesario que los requisitos estén
completamente definidos al inicio del desarrollo.
 Mitiga los riesgos por malentendidos durante la etapa de especificación de requisitos.

Inconvenientes:
 Necesidad de flexibilidad en los desarrollos para poder incorporar las evoluciones.
 Problemas de arquitectura o mantenibilidad por la introducción de modificaciones en los ciclos.
 Puede crear falsas expectativas en los clientes en cuanto a la disponibilidad del producto final

Fecha: Mayo 2017 1/5

INCREMENTAL

Se basa en la realización de ciclos secuenciales que van incrementando las funcionalidades del producto. En este modelo
se entrega un producto operativo con cada incremento. Se asume que los requisitos están claros.

Este MCV es adecuado si:

 Se conocen los requisitos.
 Las restricciones temporales/recursos impiden alcanzar los plazos requeridos.

Ventajas:
 Se genera un producto operativo de forma rápida y de forma temprana.
 Flexibilidad en alcance y requisitos.
 Facilita las pruebas y gestión de riesgos.
 Fácil gestión.

Inconvenientes:
 Es necesaria una definición de los incrementos.
 Puede crear falsas expectativas en los clientes en cuanto a la disponibilidad del producto final.

EN ESPIRAL

Puede verse como un modelo evolutivo que conjuga la naturaleza del modelo de incremental con los aspectos controlados
y sistemáticos del Modelo Cascada y el agregado de la gestión de riesgo, el énfasis en la calidad y mejora del sistema.

Se basa en aplicar un proceso de iteraciones de cuatro cuadrantes con las siguientes actividades:

1. Crear planes para identificar los objetivos del Software (requisitos) y determinar sus restricciones.
2. Análisis de riesgos de las alternativas para conseguir los objetivos.
3. Desarrollar y probar.
4. Planificar el siguiente ciclo. En este cuadrante además se lleva el control del proyecto que se define en 2
dimensiones, el coste (dimensión radial) y el grado de avance del proyecto (dimensión angular).

Un primer ciclo podría usarse para construir un prototipo del sistema.

Algunas variaciones del modelo son el de 6 regiones y el modelo WIN WIN en el que se enfatiza la participación del
cliente.

Nota de aplicación práctica: El IEEE clasifica al desarrollo en espiral como modelo no operativo en sus clasificaciones
de MCV.

Este MCV es adecuado si:

 Se trata de un sistema complejo y disponemos de mucho tiempo para su desarrollo.
 Contamos con una plantilla amplia y con experiencia en gestión de riesgos.
 Tenemos grandes restricciones de calidad.
 No se aplica de forma pura, dado que es un modelo no operativo.

Ventajas:
 Adaptabilidad del sistema a cambios.
 Reduce los riesgos del proyecto e incluye objetivos de calidad (descarta soluciones no adecuadas en fases
tempranas).
 Integra desarrollo y mantenimiento.
 No es un ciclo de vida rígido.

Inconvenientes
 Dispara los tiempos de desarrollo y es un modelo costoso.
 Requiere amplia experiencia.
 No se puede determinar a priori el número de iteraciones con lo que la planificación es imposible.

Fecha: Mayo 2017 2/5

METODOLOGÍAS

Tendremos que analizar las ventajas e inconvenientes de las metodologías tradicionales y las metodologías ágiles, y en
función de las características de nuestro proyecto decidir qué tipo aplicamos.

Los elementos de un proyecto a tener en cuenta para decidir el tipo de metodología son:
 Criticidad del proyecto.
 Experiencia del equipo de desarrollo.
 Tamaño y distribución del equipo.
 Estabilidad de los requisitos.
 Cultura organizativa.

La estabilidad y claridad de los requisitos podría ser un buen punto para elegir la metodología. Con requisitos muy
definidos al principio podemos acudir a metodologías tradicionales. En los otros extremos, cuando no existe tanta claridad
debería utilizarse una aproximación adaptativa o ágil y cuando hay mucha incertidumbre se recurre a la programación
extrema. No obstante, lo anterior es discutible, dado que hay nichos en los que las metodologías agiles funcionan muy
bien con requisitos estables, y hay otros ambientes donde pierden su efectividad o deben ser modificadas con requisitos
menos claros.

METODOLOGÍAS TRADICIONALES.

Características:

 Enfoque predictivo: énfasis en la planificación.

 Documentación exhaustiva.
 Resistencia a los cambios.
 Proceso muy controlado.
 Facilita la contratación y el seguimiento de los entregables.
 Grupos grandes de trabajo.
 Muchos entregables.

Adecuados si:

 Alta criticidad.
 Equipos de desarrollo grandes o con poca experiencia.
 Requisitos estables.
 Cultura organizativa orientada a una fuerte planificación.

Si empleamos una metodología tradicional, típicamente aplicaremos MetricaV3 que cubre tanto desarrollo estructurado
como orientado a objetos.

En desarrollo estructurado tendremos que proporcionar modelos de flujos de datos, procesos y estructuras de los datos a
través de los diagramas de flujos de datos, diccionario de datos, especificaciones de proceso, diagramas entidad-relación
y diagramas de transición de estados (ver guías de los principales diagramas).

En desarrollo orientado a objetos, típicamente, tendremos que proporcionar diagramas de casos de uso, clases,
interacción y estados (ver guías de los principales diagramas).

Fecha: Mayo 2017 3/5

METODOLOGÍAS ÁGILES DE DESARROLLO.

Características:

 Enfoque adaptativo con planificaciones a corto plazo.

 Versiones rápidas.
 Preparados para cambios durante el proyecto.
 Contratación más compleja.
 Mayor integración y proximidad del cliente en el equipo.
 Grupos pequeños de trabajo.
 Pocos entregables.
 Ausencia de documentación rigurosa.
 Usar una metodología ágil no se contrapone con la aplicación de mejores prácticas en gestión de proyectos.

Adecuados si:

 Baja criticidad.
 Equipos de desarrollo pequeños y con experiencia.
 Los requisitos cambian con mucha frecuencia.
 Cultura organizativa no orientada a una fuerte planificación.
 Plazos de desarrollo muy ajustados.

METODOLOGÍA EXTREME PROGRAMMING (XP)

CARACTERÍSTICAS

 Los valores de la programación extrema son: simplicidad, comunicación, retroalimentación ( feedback) y coraje y
respeto.
 Desarrollo iterativo e incremental.
 Pruebas unitarias continuas, frecuentemente repetidas y automatizadas. Uso de herramientas de prueba como
JUnit, NUnit o PHPUnit.
 Programación en parejas.
 Integración del equipo de programación con el cliente.
 Corrección de todos los errores antes de añadir nueva funcionalidad.
 Refactorización y simplicidad del código.
 Propiedad del código compartida. Todo el personal puede corregir y extender cualquier parte del proyecto.
 Versiones pequeñas.
 Trabajar a ritmo sostenible sin días muertos y sin horas extra.
 El sistema se define mediante metáforas o historias compartidas que actúan como vocabulario para hablar sobre
el dominio del problema.

ROLES

 Programador.
 Cliente: Escribe las historias de usuario.
 Tester.
 Tracker: se encarga del seguimiento del proyecto, estimación real vs planificada, comunicación de resultados,
etc.
 Coach: Responsable del proceso global. Guía al equipo en el proceso.
 Consultor: ayuda al equipo a resolver un problema específico.
 Gestor (Big Boss): Es el dueño o el promotor con poder decisión sobre el proyecto. Su labor es la
coordinación.

Fecha: Mayo 2017 4/5

DOCUMENTOS/ARTEFACTOS

 Historias de usuarios: tarjetas en las cuales el cliente describe brevemente las características que el sistema
debe poseer, sean requisitos funcionales o no funcionales. (Cada una debe llevar entre 1 a 3 semanas máximo
de desarrollo).
 Tareas de ingeniería (Task cards): son tarjetas con las tareas concretas que implementan la historia de
usuario, asignación, descripción de la tarea y fecha de inicio y fin.
 Tarjetas CRC (Clase – Responsabilidad - Colaborador): se usan para el diseño del sistema y contienen la
información del nombre de la clase, sus responsabilidades y sus colaboradores.
 Soluciones temporales (Spike Solutions): se usan para requerimientos de cliente que presentan problemas
desde el punto de vista de diseño e implementación. Se trata de pequeñas aplicaciones desconectadas del
proyecto que proponen una solución potencial. Pueden ser muy simples.

Consultar el documento Scrum y Kanban para obtener más información sobre otras metodologías.

Fecha: Mayo 2017 5/5

 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo
Superior de Sistemas y Tecnologías de la
Información de la Administración del Estado

PLANIFICACIÓN

Tareas previas
A la hora de planificar nuestro proyecto se deberá haber decidido previamente una
metodología y un ciclo de vida a aplicar (más información en el apartado
“Metodologías y Ciclos de Vida”) y habrá que ser coherentes con la elección que se
realice. Es decir, si escogemos Métrica como metodología y un ciclo de vida en
cascada, la planificación debe reflejar precisamente eso.

El diagrama de Gantt.

Salvo que en el enunciado nos obliguen a utilizar otro tipo de diagrama o

representación, la forma más habitual de plasmar la planificación es el Diagrama de
Gantt, mostrando el horizonte temporal en el eje horizontal y las tareas que se vayan
a realizar en el eje vertical, marcando el tiempo requerido para cada una de ellas con
barras (se incluye un ejemplo en la última página).

Consejos a la hora de planificar

Tenemos una metodología, un ciclo de vida, el Diagrama de Gantt y el enunciado del

examen. Con estos ingredientes hay que planificar. Es FUNDAMENTAL no tirar de
plantilla en esta pregunta ya que es una de las que más se presta a ello debido a
que casi todos los proyectos van a tener una serie de tareas comunes. Hay que
ADAPTAR lo máximo posible nuestra planificación al enunciado que se nos plantea.

Algunas recomendaciones a la hora de realizar la planificación son:

 Mucho cuidado con los plazos que se nos establezca en el enunciado pues
deben guiar nuestra planificación. Si nos dicen que debe estar en 6 meses no
puedes plantear un Gantt de un año.

 Es importante buscar hitos relevantes en el enunciado e incluirlos dentro de la

planificación. Y no sólo hitos relevantes sino que es importante adaptar la
planificación al enunciado; un ejemplo, si nos plantean en una de las
preguntas que hay que del sistema se deben obtener indicadores para
volcarlos a un cuadro de mando, es recomendable incluir en ASI una tarea
para el análisis de los indicadores requeridos, en DSI diseñarlos y en CSI
implementarlos. Evidentemente no es viable hacer esto con cada requisito del
sistema pero sí con los más significativos.

 En el Estudio de Viabilidad se puede incluir una tarea dedicada a buscar

opciones de reutilización dentro del propio Organismo, en el CTT … (Centro
de Transferencia de Tecnología). La reutilización hoy en día es muy
importante.

1
 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo
Superior de Sistemas y Tecnologías de la
Información de la Administración del Estado

 No todo es desarrollar software:

o También hay tareas de carácter legal que hay que llevar a cabo en un
proyecto, sin ir más lejos, todas las destinadas a contratar los bienes y
servicios necesarios. Es importante incluir estas tareas en el momento.
o O tareas relacionadas con la formación, elaborar manuales de usuario,
impartir cursos … etc.
o Si se elige alguna forma de implantación especial como los pilotos es
recomendable plasmarlo igualmente en la planificación.

 A la hora de realizar la planificación, es importante que el tiempo, el esfuerzo,

y el equipo estimados encajen. Es decir, si se da el caso de que pidan una
estimación de esfuerzo y el resultado de la estimación son unas 24 personas-
meses, si hace falta una planificación a seis meses de desarrollo, debería
estimarse un equipo de 4 personas. Estos tres valores están interrelacionados
y es importante no olvidarlo para que todo el examen sea coherente.

A continuación incluimos un ejemplo genérico de diagrama de Gantt del que se

puede partir para adaptarlo posteriormente pero, insistimos, cuanto más
personalizado y más adaptado al enunciado sea nuestro Gantt más valor tendrá
nuestro ejercicio.
Destacar que el proyecto señalado como ejemplo tiene como duración 12 meses +
duración de las tareas preliminares al desarrollo, lo cual representa una planificación
adecuada para un proyecto de larga duración. Habitualmente las planificaciones
propuestas generalmente por los opositores han tenido una duración inferior
(habitualmente entre 6-9 meses). No obstante, en este apartado como en el resto del
exámen no hay una respuesta correcta, toda respuesta que tenga coherencia puede
ser adecuada si está correctamente justificada.
En referencia a esta coherencia, uno de los aspectos más importantes de este
apartado en la planficación de la contratación. Debemos destacar que:

 Tal y como se ha visto en el apartado correspondiente, la contratación (en

función de su tipo de procedimiento) tiene unos plazos que dificilmente
pueden ser reducidos. Este plazo debe estár reflejado correspondientemente
en la planificación.

 La finalización de la contratación puede ser necesaria para el desarrollo de

ciertas actvidades (no podemos empezar a desarrollar sin el equipo externo
que hemos dicho que necesitamos, o sin la infraestructura hardware, por
ejemplo)

2
 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo
Superior de Sistemas y Tecnologías de la
Información de la Administración del Estado

Ejemplo de Gantt genérico para un proyecto de un año.

(*) Si optáis por aplicar una metodología ágil, una forma de indicarlo en el gantt puede ser como la que se observa en la figura. Por
ejemplo, podéis aplicar Scrum en una fase o en todo el proyecto, indicando los Sprints en los que se dividirán las distintas fases.

3
 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo
Superior de Sistemas y Tecnologías de la
Información de la Administración del Estado

FACTORES CRÍTICOS DE ÉXITO

Identificación de factores críticos de éxito.

Los factores críticos de éxito son los aspectos prioritarios para desarrollar cada
una de las líneas del proyecto, y que consideramos claves para el éxito final. Para
identificarlos, se procede de la siguiente manera:

 Se definen los objetivos fundamentales del proyecto.

 Se identifican los factores claves que contribuyen al cumplimiento de cada

objetivo. Preguntas que ayudan a identificarlos son:

o ¿Qué factores son determinantes para que haya éxito?

o ¿Qué factores harían que el sistema fracasara?
o ¿En qué han fracasado otros proyectos similares?

 Se identifican las relaciones causa-efecto entre objetivos y factores clave (si la

relación no está clara o no existe, debe descartarse el factor).

Si preguntan por factores críticos de éxito, lo ideal es realizar una lista adaptada al
examen, que refleje las particularidades del enunciado. No obstante, a modo de
ejemplo, citamos aquí algunos factores críticos de éxito posibles en numerosos
proyectos.

Ejemplos de factores críticos de éxito.

 Adecuada gestión del cambio.

 Rapidez, si se trata de un proyecto con un impacto muy positivo o con mucha
urgencia.
 Proactividad en la integración de actores relevantes.
 La implicación y liderazgo de la alta dirección, con el objetivo de obtener el
compromiso de todos los participantes en el sistema.
 Impulso o respaldo legal de la iniciativa.
 Cumplimiento legal.
 Coordinación entre todos los entes implicados.
 Usabilidad y accesibilidad.
 Utilizar sistemas abiertos para garantizar:
o Interoperabilidad.
o Escalabilidad, para crecer a medida que las funcionalidades, la
cantidad de accesos o la información lo requiera.

1
 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo
Superior de Sistemas y Tecnologías de la
Información de la Administración del Estado
o Portabilidad, para permitir la reutilización de los desarrollos ya
realizados en la AAPP.
 Seguridad para conseguir la confianza de los usuarios.
 Disponibilidad, especialmente importante en:
o Arquitecturas centralizadas.
o Aplicaciones que funcionan en zonas con diferentes horarios.
o Aplicaciones que deban ser 24x7 (registro electrónico).
 Formación a los actores principales del sistema.
 Calidad.
 Mantenibilidad de todos los desarrollos.
 En el caso de una agencia: asegurar la obtención del informe anual para el
Congreso de los Diputados.
 Formación a los usuarios.
 Formación al equipo de desarrollo.
 Comunicación y promoción del nuevo servicio.
 Reuniones de seguimiento del proyecto.
 Comunicación fluida entre todos los actores.
 Participación satisfactoria de los usuarios expertos en la fase de análisis.
 Adecuación a los estándares.

2
 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo
Superior de Sistemas y Tecnologías de la
Información de la Administración del Estado

DESARROLLO DE APLICACIONES (APPS) HÍBRIDAS PARA

MÓVILES

Decisiones iniciales.
Consiste en una “carcasa” desarrollada mediante aplicación pero que obtiene datos
de la web. Su complejidad es mayor ya que tiene la desventaja de la dependencia
de la plataforma y las restricciones de la web. Sin embargo es util para vistas
complejas y actualizaciones constantes.

Este tipo de tecnologías no permite un desarrollo único, quese adapte

automáticamente al tamaño del dispositivo (smatphones, tablets, tv…). Suele
requerir un desarrollo extra que suele aumentar el presupuesto en un 20-40%.

Gestión del proyecto.

1.- Gestiones previas.

Si nos inclinamos por el uso de Apps nativas, habrá que pagar una licencia anual
para el desarrollo y despliegue con las plataformas más populares:

 Apple Store: en torno a 90 € (pago anual).

 Google Play: en torno a 25 € (único pago).

2.- Planificación temporal del desarrollo.

En función de su dimensión, el tiempo que habrá que planificar para la fase de

construcción (desarrollo) sería:

 Simple: Datos offline, sin conexión con servidores. Entre 2 y 4 semanas.

 Medio: Datos estáticos con conexión a un servidor externo. Entre 4 y 8
semanas.
 Complejo: Si tiene bases de datos, integración web, sistemas de pago o redes
sociales. Entre 8 y 12 semanas.
 Experto: Procesos de negocio con integraciones complejas. Unas 15
semanas.

3.- Despliegue.

 La subida a producción, sobre todo a Apple Store, requiere una revisión

basada en aspectos técnicos, de usabilidad y contenido, por parte de Apple,
Google etc. En el caso de Apple, puede tardar alrededor de unos 7 días en
enviar el informe. Si no pasase la revisión, habrá que corregir los "errores" y
volver a enviarlo. Esto en Apple, en el caso de los informes sobre otras
plataformas los tiempos y requisitos suelen ser menores.

1
 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo
Superior de Sistemas y Tecnologías de la
Información de la Administración del Estado

Proceso de desarrollo de aplicaciones híbridas

Las aplicaciones híbridas aúnan lo mejor de los otros dos modelos, nativo y web.
Este tipo de aplicaciones permite el uso de tecnologías multiplataforma como HTML,
Javascript y CSS pero permiten acceder a buena parte de los dispositivos y
sensores del teléfono. Buena parte de la infraestructura es tipo web y la
comunicación con los elementos del teléfono se hace mediante comunicadores tales
como phonegap (http://phonegap.com). Un buen ejemplo de aplicaciones híbridas es
Facebook. Se descarga de la app store y cuenta con todas las características de una
aplicación nativa pero requiere ser actualizada ocasionalmente.

El proceso de desarrollo para este tipo de aplicaciones es algo más complicado. Al

igual que para las aplicaciones nativas, el código una vez creado se compila a un
ejecutable. Además, también como en las aplicaciones Web se genera código
HTML, CSS y Javascript a ejecutar en un navegador. Ambos códigos se compilan
para ser subidos mediante un paquete distribuible a la app store.

2
 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo
Superior de Sistemas y Tecnologías de la
Información de la Administración del Estado

Nos queda por contaros los que es y representa el phonegap, es decir, el vínculo
que une la tecnología web con los elementos propios del teléfono. El phonegap
tiene dos objetivos:

 Primero, permite que un código fuente cualquiera se pueda ejecutar en

diversas plataformas. Segundo, el phonegap permite que la aplicación web
acceda a los diferentes elementos del teléfono.

TECNOLOGÍAS.
Algunas de las herramientas más utilizadas hoy en día para crear aplicaciones
híbridas son:

 Phonegap: Quien permite realizar aplicaciones con HTML5, CSS3 y

JavaScript, pero que serán empaquetadas como aplicaciones nativas.
Seguramente si vas a utilizar Phonegap necesitarás ojear Sencha Touch o
jQuery Mobile para la interfaz.

 Trigger.io: Básicamente, casi igual que Phonegap. Ellos se adjudican ser 5

veces más rápidos que Phonegap.

 Titanium Appcelerator: Utilizando Web Views para embeber un navegador

web dentro de alguna ventana nativa.

 hasta Java (+ Android SDK) u Objective-C (+ Xcode), utilizando vistas web

embebidas en la aplicación.

3
DESARROLLO DE APLICACIONES NATIVAS PARA MÓVILES

DECISIONES INICIALES

Elegiremos esta opción cuando:

- Sea importante la usabilidad de la aplicación y el proporcionar una rica experiencia de usuario.

- Necesitemos velocidad de respuesta alta y buen rendimiento. 


- Necesitemos identificación y hacer transacciones de manera segura.

- Necesitemos acceso a las utilidades del sistema operativo del dispositivo: cámara, geolocalización, acelerómetro etc. 


Inconvenientes:
- Desarrollo más complejo.
- Mayores costes: suele aumentar el presupuesto en un 20-40%.
- Para abarcar al 95% de los usuarios, tendremos que desarrollar en las 3 plataformas más importantes (iOS, Android y
Windows).

Fecha: Mayo 2017 1/4

GESTIÓN DEL PROYECTO

Gestiones previas.


Habrá que pagar una licencia anual para el desarrollo y despliegue con las plataformas más populares:

- Apple Store: en torno a 90 € (pago anual). 


- Google Play: en torno a 25 € (único pago).

Planificación temporal del desarrollo. 


En función de su dimensión, el tiempo que habrá que planificar para la fase de construcción (desarrollo) sería: 

- Simple: Datos offline, sin conexión con servidores. Entre 2 y 4 semanas. 

- Medio: Datos estáticos con conexión a un servidor externo. Entre 4 y 8 semanas. 

- Complejo: Si tiene bases de datos, integración web, sistemas de pago o redes sociales. Entre 8 y 12 semanas. 

- Experto: Procesos de negocio con integraciones complejas. Unas 15 semanas. 


Despliegue.
La subida a producción, sobre todo a Apple Store, requiere una revisión basada en aspectos técnicos, de usabilidad y
contenido. En el caso de Apple, puede tardar alrededor de unos 7 días en enviar el informe. Si no pasase la revisión, habrá
que corregir los "errores" y volver a enviarlo. En el caso de los informes sobre otras plataformas, los tiempos y requisitos
suelen ser menores.

TECNOLOGÍAS DE DESARROLLO

iOS.
- Todavía existen aplicaciones que han sido desarrolladas con Objective-C, sin embargo la tendencia actual es utilizar
Swift.
- Entorno de desarrollo: Xcode.
- Pruebas y despliegue con Instruments.
- Herramientas adicionales: Interface Builder.

Android.
- Programación Java Native Android.
- Posibles entornos de desarrollo: Android Studio, Eclipse, AVD Manager.
- Pruebas con JMETER y TestUnit.

Windows.

- Desarrollo con Microsoft Visual Studio o Windows App Studio.

Fecha: Mayo 2017 2/4

DESARROLLO MULTIPLATAFORMA CON XAMARIN

Xamarin es una plataforma de Microsoft para el desarrollo de aplicaciones móviles, que permite construir aplicaciones nativas
iOS, Android y Windows utilizando .NET (normalmente con lenguaje C#).
Su principal ventaja es que permite la reutilización de gran parte del código entre las plataformas (según la
documentación de Microsoft es habitual conseguir más de un 75% de reutilización). Para ello se utilizan PCLs (Portable
Class Libraries), en las cuales se ubica el código común, como puede ser el acceso a bases de datos (normalmente SQLite),
llamadas a servicios web, gestión de logs, interfaces de usuario comunes (mediante Xamarin.Forms) etc. Este código no
varía entre plataformas.
Xamarin.Forms proporciona un conjunto de APIs que permiten construir componentes de interfaz de usuario comunes para
todas las plataformas. Estos componentes serán renderizados adecuadamente en cada plataforma de forma automática, es
decir, internamente se realiza la transformación del código común a controles nativos específicos de cada plataforma.
Además del código común, será necesario disponer de código específico para cada plataforma para aquellos aspectos de la
aplicación que no puedan ser gestionados de manera global. A continuación se muestran un par de ejemplos de elementos
que requieren implementaciones específicas, puesto que la forma de manejarlos varía entre plataformas:

Gestión en iOS Gestión en Android

Notificaciones push Mediante Apple Push Notification Service Mediante Google Cloud Messaging
Geolocalización Mediante CoreLocation framework Mediante Android Location Service API

Cuándo utilizar Xamarin:

- Disponemos de personal con conocimientos de .NET, pero no tenemos personal especializado en desarrollo iOS, Android
y Windows Phone.
- Necesitamos desarrollo de aplicaciones nativas para todas las plataformas (iOS, Android, Windows Phone). Esto es
conveniente en el caso de las aplicaciones desarrolladas por la Administración, puesto que el objetivo es llegar a todos
los ciudadanos.
- La mayor parte de las funcionalidades pueden ser gestionadas en las PCLs y NO requieren implementaciones específicas
para cada plataforma.
- NO se requiere la integración de SDKs complejos. Estos SDKs (Software Development Kits) están preparados para ser
añadidos fácilmente a aplicaciones iOS o Android, pero para ser utilizados en Xamarin requieren de un proceso de
transformación que puede resultar complejo, costoso en tiempo y propenso a errores. Por ejemplo, si en lugar de utilizar
el reproductor de vídeo estándar, se requiere un SDK de reproducción de vídeo con unas características específicas, es
probable que la integración del SDK sea compleja.

Ventajas:
- Reutilización de código.
- Entorno de desarrollo conocido si tenemos personal con conocimientos de .NET.

Desventajas:
- Curva de aprendizaje sobre el desarrollo de aplicaciones nativas en iOS, Android y Windows, ya que serán necesarios
conocimientos específicos de las plataformas para desarrollar ciertas funcionalidades y/o para mejorar la experiencia de
usuario.
- Integración compleja de SDKs.

Fecha: Mayo 2017 3/4

PRUEBAS DEL DESARROLLO

Para todas las plataformas existen simuladores en los que poder realizar las pruebas. Como ejemplos tenemos el iOS
Simulator, o los emuladores Android. Esto permite realizar pruebas de forma más rápida y fácil durante el desarrollo.
Sin embargo, una vez realizadas estas pruebas, es necesario probar también en dispositivos físicos, puesto que algunos
errores no se producen al ejecutar la aplicación en los simuladores. Por otra parte, en el caso de Android la posibilidad de
que aparezcan errores es mayor, ya que el número de modelos de dispositivos que existen es enorme. Para evitar este
problema, es necesario realizar pruebas en el mayor número de modelos posible (Motorola, Samsung, Nexus etc.).
Por último, es necesario tener en cuenta las diferentes versiones de los Sistemas Operativos que vayamos a soportar (por
ejemplo, iOS 9 e iOS 10, Android Lollipop, Android Marshmallow, Android Nougat etc.), ya que algunos errores son
específicos de una versión de SO concreta.

FUNCIONALIDADES EXTRA

Notificaciones:
Esta funcionalidad sólo tendría sentido para las aplicaciones nativas.
Consiste en poder enviar a los usuarios actualizaciones o notificaciones referentes a la aplicación.
Existen dos formas: o programarlo o contratar el servicio con plataformas específicas. La primera opción es más costosa de
desarrollar y de mantener. La segunda opción está más extendida, con las plataformas Push como por ejemplo Apple Push
Notification Server, C2DM de Android o Google Cloud Messagging entre otras.

Firma móvil:
Consiste en proporcionar al móvil la capacidad de firmar digitalmente.
Básicamente habría que instalar un cliente o applet de firma electrónica para el sistema operativo móvil que se pretende.
Para lograr esta funcionalidad, existen soluciones de mercado como Viafirma platform, pero además, desde la Administración
se ha lanzado la aplicación “Cliente @firma móvil” disponible para plataformas con sistema operativo Android, iOS y
Windows, (más información en el documento “Cliente @firma móvil” de la carpeta Material Adicional).
Para más información sobre firma móvil, se puede consultar en el apartado de “Identificación y Autenticación” del apartado
Transversal.

UN CASO DE ÉXITO: EADMON

Es una aplicación que publica los recursos de la Administración disponibles en redes sociales, habilitando el diálogo continuo
con la sociedad desde donde ciudadanos y empresas lo deseen. La aplicación ofrece también a ciudadanos y empresas los
servicios orientados a la vida en movilidad desarrollados por ministerios y organismos públicos. Si se creara una aplicación
nativa, sería importante gestionar su inclusión en el catálogo que recoge esta aplicación.

Fecha: Mayo 2017 4/4

 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo
Superior de Sistemas y Tecnologías de la
Información de la Administración del Estado

DESARROLLO DE APLICACIONES (APPS) WEB PARA

MÓVILES

Decisiones iniciales.

La mayor ventaja consiste en la independencia de la plataforma. El inconveniente

principal es que todavía está limitado en el acceso a las características más
avanzadas.

Elegiremos esta opción cuando:

 Se necesiten enlaces con otras webs.

 Se requieran actualizaciones frecuentes.
 Se necesite desarrollar en poco tiempo y con poco presupuesto.
 Para englobar un amplio abanico de dispositivos (tablets, móviles, TV).

Al ser web móvil sólo habría que asegurar que funciona correctamente en los
navegadores web móviles (Firefox, Opera, Mirem etc).

Gestión del proyecto.

1.- Planificación temporal del desarrollo.

En función de su dimensión, el tiempo que habrá que planificar para la fase de

construcción (desarrollo) sería:

 Simple: Datos offline, sin conexión con servidores. Entre 2 y 4 semanas.

 Medio: Datos estáticos con conexión a un servidor externo. Entre 4 y 8
semanas.
 Complejo: Si tiene bases de datos, integración web, sistemas de pago o redes
sociales. Entre 8 y 12 semanas.
 Experto: Procesos de negocio con integraciones complejas. Unas 15
semanas.

2.- Despliegue.

 El despliegue es similar al propio de una web normal.

Tecnologías de desarrollo.

 HTML5: El uso de esta tecnología permite la unificación del diseño del

interfaz de usuario para cada uno de las plataformas móviles del mercado,
mejorando la usabilidad y experiencias del usuario en la utilización del

1
 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo
Superior de Sistemas y Tecnologías de la
Información de la Administración del Estado
dispositivo móvil. Además se desacopla de los elementos diseñados con
futuribles dispositivos móviles que puedan aparecer. Hay que tener en
cuenta que es una tecnología muy nueva y por tanto aún no está lo
suficientemente expandida, lo que podría provocar aumentos en los
tiempos de desarrollo y pruebas.

Entorno de desarrollo de HTML5:

o Desarrollo orientado HTML + CSS3
o Constructores nativos de aplicaciones multiplataforma: PhoneGap,
ADTAIR
o JQuery Mobile
o Pruebas JMETER y TestUnit

Pruebas del desarrollo.

Si se ha escogido la opción de Apps webs, la fase de pruebas es similar a la de un
desarrollo web normal sólo que con un simulador de dispositivo.

Proceso de desarrollo de aplicaciones web móviles

Las aplicaciones web móviles, a diferencia de las aplicaciones nativas, se ejecutan

dentro del navegador del teléfono. Por ejemplo, en la plataforma iOS, se ejecutan en
el navegador Safari. Estas aplicaciones están desarrolladas con HTML, CSS y
Javascript.

2
 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo
Superior de Sistemas y Tecnologías de la
Información de la Administración del Estado
Al contrario que las aplicaciones nativas, las aplicaciones web se pueden ejecutar en
múltiples dispositivos evitando así las complejidades de tener que crear varias
aplicaciones. El proceso de desarrollo es más sencillo ya que emplean tecnologías
ya conocidas como HTML, CSS y Javascript. Estas aplicaciones se pueden
encontrar con los tradicionales buscadores. No necesitan de la aprobación de ningún
fabricante para ser publicadas.

Como desventajas tenemos que el acceso a los elementos del teléfono son
limitados. Además, estas aplicaciones no se pueden vender en los market place.

Herramientas.

 Responsive Web Design:

o Se trata de una tecnología que permite crear pantallas adaptables al

tamaño de cualquier dispositivo mediante CSS y Media-queries. Su uso se
limita a apps web móviles y no es recomendable si tenemos que
desarrollar una lógica compleja.

3
MÓDULOS SOFTWARE HABITUALES.

De cara a la resolución del supuesto práctico, es importante conocer varios productos comerciales (código abierto o
propietarios) que permitan cubrir las funcionalidades más típicas: gestión de contenidos, gestión de portales, gestión de
documentos, etc. Conocer varias alternativas dentro de cada una de esas categorías, con sus principales características,
tecnologías soportadas, etc., resulta fundamental de cara a la resolución del cuarto ejercicio.
Es también muy importante conocer las soluciones reutilizables disponibles en el Centro de Transferencia de Tecnología
(CTT) del Portal de Administración Electrónica (PAe: https://administracionelectronica.gob.es) que puedan cubrir las
funcionalidades requeridas sin tener que recurrir a una solución comercial. Las principales ventajas de estas soluciones son:
i) que el control de la misma está dentro de la administración y no en una empresa externa; ii) que ya están adaptadas a
la normativa de administración electrónica; y iii) que el grado de parametrización necesario es menor (precisamente por la
adaptación al negocio de la administración), reduciéndose por tanto los esfuerzos requeridos para su implantación.
Respecto a la opción de la reutilización, ha de asegurarse de que la tecnología subyacente sea coherente con la integración
planteada en la resolución del supuesto; es decir: si se trata de tecnología Java, .NET, etc., el conjunto de la solución
desarrollada debe ser coherente con la opción elegida. Muy importante también: si se trata de un software ofrecido como
SaaS, ha de plasmarse adecuadamente en la arquitectura lógica como un servicio externo y no en nuestra capa de negocio,
debiendo estudiar si la solución ofrece la posibilidad de integración vía Web Services (WS) u otros mecanismos, de modo
que se pueda integrar con el resto de nuestra solución.
Por último, respecto a la reutilización hay que estudiar cada solución reutilizable en particular, ya que en ningún caso
sustituyen en funcionalidades a una solución comercial, puesto que suelen enfocarse a una necesidad concreta que puede
no abarcar nuestras necesidades.

→ Ver más información en el documento "Aplicaciones reutilizables" en la sección 04. Transversal > 01. Servicios
Red SARA.

En los documentos de la sección actual se recogen los principales productos existentes que permiten llevar a cabo las
funcionalidades típicas. Las categorías en las que se han agrupado las soluciones son las siguientes:

 Gestores de contenido.
 Gestores de portales.
 Gestores documentales.
 Sistemas de Workflow (WF).
 Herramientas de Business Intelligence (BI).
 Herramientas Enterprise Service Bus (ESB).
 Herramientas varias.
 Herramientas para integración continua.

Nota: Es importante tener en cuenta que la diferencia entre gestor de contenido y gestor de portal (e incluso gestor
documental en algunos casos) no resulta clara. Por ello, gran parte de los productos que se han clasificado como gestores
de contenido también se pueden considerar gestores de portales y a la inversa.

Fecha: Mayo 2017 1/1

GESTORES DE CONTENIDOS.

Un Sistema Gestor de Contenidos (CMS, Content Management System) facilita la gestión de los contenidos y simplifica su
administración. Normalmente, se utiliza para administrar contenidos de una página web, también denominándose en este
caso Web Content Manager (WCM).
Consiste en una interfaz que controla una o varias BBDD donde se encuentra el contenido. El sistema permite manejar de
manera independiente el contenido y la presentación (o diseño) de la página. Así, es posible manejar el contenido y darle
en cualquier momento un diseño distinto al sitio web sin tener que darle formato al contenido de nuevo, además de permitir
a varios editores la publicación fácil y controlada.
Entre las alternativas reutilizables para la implantación de un gestor de contenidos están:
 ROLSAC (Tecnología: Java. Responsable: Gobierno de las Islas Baleares).
 ACCEDA (Tecnología: PHP/SaaS con web services. Responsable: MINHAP).

→ Ver más información el documento "Aplicaciones reutilizables" en la sección 04. Transversal > 01.
Servicios Red SARA, así como en el CTT-PAe.

En el mercado existen diferentes soluciones de gestores de contenido. De cara a la preparación del cuarto examen, es
importante tener en cuenta las siguientes premisas:
 ¿El gestor de contenidos es de software abierto o es propietario? Esta cuestión resulta crucial para poder determinar
si en el presupuesto de nuestro sistema debemos incluir la licencia por la utilización de esa herramienta.
Nota: aunque elijamos una alternativa de código abierto, puede que decidamos contratar soporte y, en ese caso,
deberíamos considerarlo en el presupuesto.
 ¿Qué tecnología utiliza el gestor de contenidos? Las típicas son PHP y Java, pero también podemos encontrar, por
ejemplo: .NET, Python o Ruby on Rails.
Nota: al elegir el gestor de contenidos debemos considerar la tecnología que utiliza. No tiene sentido que
planteemos un sistema .NET y que incluyamos un gestor de contenidos en Java. Todo el sistema debe ser coherente.
 ¿Qué BD, sistema operativo, servidor de aplicaciones, etc., soporta el gestor de contenidos? Tal y como se ha
comentado en el punto anterior, debemos asegurarnos de que el planteamiento de nuestro sistema sea coherente.
Por tanto, de cara a la elección del gestor de contenidos se deberá tener en cuenta con qué BBDD es compatible,
con qué servidores, etc.

A continuación, se incluye un detalle con los principales gestores de contenido disponibles en el mercado (tanto de código
abierto como propietario).

Recomendación: Teniendo en cuenta la amplia oferta de soluciones existente, lo más interesante es que seleccionéis al
menos uno para cada tecnología y conozcáis sus principales características de cara a la resolución del supuesto práctico .

Nota: aunque otros productos como pueden ser empleados como CMS, debido a sus funcionalidades más amplias, se han
encuadrado en gestores de portales, por ejemplo: Liferay, IBM WebSphere…

Fecha: Mayo 2017 1/6

 Herramienta Características Tecnología Licencia Información adicional Ejemplos
Drupal  Multiplataforma PHP Código abierto Drupal es muy adecuado cuando hay que hacer Sitios web creados con
 Independencia del gestor de (GPL) pequeños desarrollos, porque se pueden Drupal:
BD realizar aplicaciones relativamente sofisticadas
La casa blanca:
 Multi-idioma sin apenas programar. Su gran cantidad de
http://www.whitehouse.gov
 Administración web módulos de integración con otros servicios y
/
 Generación de estadísticas y productos permite además incluir funcionalidad
reporting avanzada en una web con poco esfuerzo. AOL: http://www.aol.com/
 Gran cantidad de módulos:
Como puntos fuertes destacar:
foros, blogs, encuestas…
 Control de versiones - Dispone de gran cantidad de
 Plantillas predefinidas documentación, en concreto un área
 Sistema de permisos basado de formación con diversos recursos
en roles/grupos multimedia.
 Ayuda online - La gestión de permisos destaca por
 Gartner lo incluye en su encima de cualquier otra
cuadrado mágico durante característica: ofrece un sistema muy
muchos años avanzado y completamente
 Entorno de personalización personalizable a nivel de rol y páginas
robusto, tanto el contenido - Amplia comunidad de desarrolladores
como la presentación pueden Como aspectos a mejorar destaca que la
ser tratados de forma actualización del sistema no está automatizada.
individual de acuerdo a unas Además, Drupal también es criticable desde el
preferencias definidas por el punto de vista de su complejidad (en
usuario. comparación con otros productos similares)
 Posibilidad de gestionar las
taxonomías y la estructuración
de contenidos de forma
personalizable.
 Rendimiento y escalabilidad
(cacheo avanzado)
Joomla  Ofrece un alto nivel de PHP Código abierto Está dirigido a proyectos de pequeña y mediana Sitios web creados con
flexibilidad y versatilidad en el (GPL) envergadura. Joomla:
diseño de aspecto y estructura
Si necesitamos ofrecer mucha información en Ebay:
de un sitio web.
nuestra web y esa información puede http://www.ebay.com/
 Se encuentra en constante
organizarse jerárquicamente, Joomla puede ser
evolución gracias a la mejora Ikea:
la mejor opción.
continua del sistema http://www.ikea.com/es/es/

Fecha: Mayo 2017 2/6

  Permite su instalación en Es muy recomendable para la publicación de
servidores Linux, Mac y revistas electrónicas.
Windows.
Como puntos fuertes podemos destacar:
 Dispone de gran velocidad de
carga de sus páginas gracias - Su máximo potencial se obtiene de la
al sistema de caché. integración, adaptación y desarrollo
• Requiere BD MySQL y servidor de nuevos módulos.
web apache. - Amplia comunidad.
 Multi-idioma - Versatilidad que ofrece a través de
 Administración web plantillas, extensiones y
 Generación de estadísticas y adaptaciones. Existen módulos,
reporting componentes y plugins que extienden
 Cacheo avanzado la funcionalidad original del CMS:
 URL’s amigables gestión de archivos, gestión de
contactos, sistema de búsqueda,
tiendas online, bolsas de trabajo,
integración con redes sociales,
gestión de noticias y newsletter,
sistemas de encuestas, etc.
Como inconveniente, indicar que la
actualización del sistema no está automatizada

OpenCMS  Multiplataforma Java Código abierto Puntos destacados: Sitios web creados con
 Multi-idioma (UTF-8) (LGPL) OpenCMS:
- Cuenta con una extensa red de
 Soporte de tecnología AJAX
proveedores Abengoa
 Motor de búsqueda Lucene
- Existen abundante documentación.
 Edición directamente en http://www.abengoa.com
Puntos a mejorar:
producción (Direct Edit).
Posibilidad de editar los F.C. Barcelona:
- La licencia es LGPL y no presenta un
contenidos desde el front- http://www.fcbarcelona.es/
copyleft fuerte, pues permite enlazar
office sin necesidad de con módulos privativos.
acceder al back-office - La comunidad del proyecto no es
 Previsualización de los demasiado activa
cambios - La instalación y actualización del
 Posibilidad de programar la sistema no está automatizada
puesta en producción de un
cambio (time warp)
 Cacheo avanzado
 Posibilidad de construir una
secuencia de tareas para
facilitar el trabajo en grupo,
de forma que se puedan

Fecha: Mayo 2017 3/6

 ejecutar flujos de trabajo
específicos
 Utiliza Apache Tomcat como
servidor de despliegue
Plone  Basado en el servidor de Python Código abierto Puede utilizarse para desarrollar portales, Sitios web creados con
aplicaciones Zope (GPL) tiendas online, intranets, sitios colaborativos o Plone:
 Compatible con las principales repositorios de contenidos.
Auditorio Nacional de
plataformas (Windows, MAC,
Dispone de una documentación abundante. Música:
BSD, Linux y Solaris)
http://www.auditorionacion
 Gran cantidad de La versión 4 de Plone, en general, es más rápida
al.mcu.es
extensiones/módulos que casi todos los CMS disponibles en el
disponibles: wikis, calendario, mercado. Ayuntamiento de Sevilla:
foros, encuestas, blogs… www.sevilla.org
 URL’s amigables El principal problema de Plone es que está
 Workflow de publicación desarrollado en Python, lenguaje no demasiado
 Permite corregir o modificar implantado a nivel de empresas proveedoras,
en tiempo real un contenido por lo que puede resultar más difícil encontrar
 Histórico de acciones (permite programadores.
deshacer/restaurar)
 Incluye motor de búsqueda
completo y en tiempo real
 Realizar copias de seguridad
fiables, aunque existan
usuarios trabajando en ese
momento
Wordpress  Personalización especialmente PHP Código abierto Si lo que buscamos es tener listo rápidamente Sitios web creados con
sencilla a través de la gran (GPL) un sitio sencillo, con un buen diseño y que sea Wordpress:
variedad de temas adaptables fácil de actualizar, podemos usar WordPress.
La revista People:
y extensiones.
Además, el sistema de instalación y http://stylenews.peoplestyle
 Protección de la privacidad de
actualización es uno de sus puntos fuertes ya watch.com/
los contenidos, a través de la
que entre otras opciones puede ser instalado y
definición de niveles de El Blog de Flickr:
actualizado desde algunos repositorios de
usuario, protección de http://blog.flickr.net/es
sistemas GNU/Linux.
contenidos por contraseña,
filtros antispam o controles de
comentarios.
 Generación de estadísticas de
acceso al sitio Web
 Infinidad de extensiones:
plugins, themes y mobile

Fecha: Mayo 2017 4/6

  Utiliza MySQL como motor de
BD
 Utiliza Apache o Nginx como
servidor Web
Magnolia  Está basado en el estándar Java Código abierto Magnolia CMS permite la edición en línea
JSR-170 instantánea.
 Flujo de trabajo (Workflow)
Proporciona muchos módulos que integran
basado en openwfe
frameworks como Struts, Spring, Stripes o
 Multi-idioma
Wicket para facilitar la integración con
 Gestión de roles
aplicaciones.
 Capacidad de clustering y
balanceo de carga También integra JAAS (un estándar Java para
 Conectores con otros gestores la autentificación y autorización de usuarios).
de contenidos. Esto le permite aprovechar la infraestructura de
 Compatible con Tomcat, gestión de usuarios basada en LDAP o AD o
JBoss, Websphere / Weblogic proporcionar un solo punto de autentificación
 Interfaz Webdav, CMIS, LDAP (Single Sign-on).

exoPlatform  Multiplataforma Java Código abierto La principal ventaja es que se puede

 Independencia de gestor de personalizar, mejorando su funcionalidad a
BD (soporta MySQL, Postgres, través de APIs, plugins, extensiones y haciendo
Oracle, MS SQLServer, uso del IDE.
Sybase, DB2)
Existe la posibilidad de exo cloud, una nube
 Lenguaje Java
pública SaaS.
 Wizards para la creación
rápida de páginas El principal problema es que su presencia en el
 JSR 168 y JSR 286 mercado aún no está muy extendida.
 JSR 170
 CMIS, WebDAV, FTP
 CAS, Kerberos, SAML, LDAP
 Servidor de aplicaciones:
Tomcat.
 Soporte de tecnología AJAX
 Single-Sign-On (SSO)
 Interfaz de usuario Web 2.0
 Sistema de permisos basado
en roles/grupos
 Utiliza las siguientes
tecnologías:
o Bonita
o jBPM
o Hibernate

Fecha: Mayo 2017 5/6

 o Lucene
XimDEX  Multiplataforma Código abierto Permite gestionar cualquier portal de forma
 Independencia de gestor de independiente a la tecnología de explotación a
base de datos (se recomienda utilizar (HTML5, XHTML, J2EE, PHP, .NET, RoR,
MySQL) Django, TDT, ...), lo que permite una evolución
 Multi-idioma (UTF-8) sencilla del portal sin afectar a los contenidos
 URL’s amigables almacenados para, por ejemplo, adaptarlo a
 Cacheo avanzado HTML5
 Workflow de publicación
 Administración web
 Soporte Webdav
Apache  Implementa el estándar JSR- Java Código abierto Ofrece menos funcionalidades que los CMS
Jackrabbit 170 anteriores
 Multiplataforma
IBM  Herramientas de edición de Java SW Se requiere pago por licencia
WebContent texto enriquecido propietario
Management  Amplio soporte de
personalización
 Herramientas sociales y
móviles (Facebook, Twitter,
LinkedIn).
 Integración con los
repositorios existentes de IBM
Content Management
Interoperability Services e IBM
Enterprise Content
Management
 Soporta los siguientes
sistemas operativos: M AIX,
IBM i, Linux, Solaris, Microsoft
Windows, z/OS

Fecha: Mayo 2017 6/6

GESTORES DE PORTALES.

Permiten la creación y administración de portales web, facilitando la integración con las aplicaciones existentes y agilizando
la construcción del mismo.
Al igual que en el caso de los gestores de contenidos, en el mercado existen diferentes soluciones de gestores de portales.
De cara a la preparación del cuarto examen, es importante tener en cuenta las siguientes premisas:
 ¿El gestor de portales es de código abierto o es propietario? Esta cuestión resulta crucial para poder determinar si
en el presupuesto de nuestro sistema debemos incluir la licencia por la adquisición o utilización de esa herramienta.
Nota: aunque elijamos una alternativa de código abierto, puede que decidamos contratar soporte y, en ese caso,
deberíamos considerarlo en el presupuesto.
 ¿Qué tecnología utiliza el gestor de portales?
Nota: al elegir el gestor de portales debemos considerar la tecnología que utiliza. No tiene sentido que planteemos
un sistema .NET y que incluyamos un gestor de portales basado en Java. Todo el sistema debe ser coherente.
 ¿Qué BD, sistema operativo, servidor de aplicaciones, etc., soporta el gestor de portales? Tal y como se ha
comentado en el punto anterior, debemos asegurarnos de que el planteamiento de nuestro sistema sea coherente.
Por tanto, de cara a la elección del gestor de portales se deberá tener en cuenta con qué BBDD es compatible, con
qué servidores, etc.

A continuación, se incluye un resumen con los principales gestores de portales disponibles en el mercado (tanto de código
abierto como propietario).

Recomendación: Teniendo en cuenta la amplia oferta de soluciones existente, lo más interesante es que seleccionéis al
menos uno para cada tecnología y conozcáis sus principales características de cara a la resolución del supuesto práctico.

Fecha: Mayo 2017 1/3

 Herramienta Características Tecnología Licencia Información adicional
Liferay  Corre en la mayoría de los Java Código abierto Dado que soporta el estándar JSR 286 (versión 2.0 de la especificación de
servidores de aplicaciones y (LGPL) portlets) permite la integración de portlets en los portales que se diseñen
contenedores de servlets, bases con esta solución. Es de software libre y se encuentra ampliamente
de datos y sistemas implantado.
(multiplataforma)
Su facilidad de integración con Alfresco es un punto a su favor (de hecho, la
 Utiliza MySQL como motor de
combinación Liferay + Alfresco tiene una amplia aceptación).
base de datos, pero funciona
con PostgreSQL, SQLite, IBM Está dirigido a todo tipo de escenarios, tanto portales corporativos como
DB2 para el desarrollo de Intranets o nuevas aplicaciones que requieran ser
 Servidores de aplicaciones integradas con los sistemas de una organización.
soportados: Apache Tomcat,
Resin o Jetty Destaca la oferta formativa disponible, a través de un completísimo
 Soporta los estándares: programa formativo específico que incluye seminarios presenciales, online,
o AJAX formación en sede propia, etc.
o iCalendar
o JSR-168
o JSR-127
o JSR-170
o JSR-286 (Portlet 2.0)
o JSF-314 (JSF 2.0)
o OpenSearch
 Lenguajes de scripting
soportados: Javascript, Ruby,
PHP, Python
 Proporciona herramientas de
colaboración
 Existen numerosos portlets ya
desarrollados (>60)
 Incluye workflow
 Soporta Kerberos, autenticación
LDAP
 Registro de auditoría
 Buen rendimiento: balanceo de
carga, cacheo de páginas,
replicación de BD
 Estadísticas web
 Soporte Webdav, cumplimiento
XHTML, cumplimiento WAI y
soporte FTP limitado

Fecha: Mayo 2017 2/3

  Conversión de formatos
comunes como Microsoft Office,
PDF, TXT y HTML
(importación/exportación)

Microsoft Office  Dispone de los elementos más NET SW Si en el organismo donde se quiere implantar la solución utilizan .NET,
SharePoint Server esenciales de un portal: Framework propietario SharePoint sería una buena solución.
(MOSS) o Gestión de contenidos
(documentos, páginas
web, centro de Sin embargo, un sistema de alto volumen de transacciones no es buena idea
registros) para esta plataforma, especialmente si los datos se almacenan en las listas
o Integración de de SharePoint (no diseñadas para este tipo de carga). Del mismo modo, no
aplicaciones debe utilizarse SharePoint para aplicaciones intensivas en cuanto al uso de
(desarrollos .NET) datos, tales como procesos por lotes o software de procesamiento en
o Tecnologías de paralelo. SharePoint tampoco suele ser la plataforma adecuada para la
búsquedas integración de aplicaciones. Un proyecto de integración de Microsoft debe
o Diferentes basarse en BizTalk Server.
arquitecturas de
sistemas
 Requiere SQL Server
 Necesita Windows Server con
IIS para el rol de presentación.
 Requiere Active Directory para la
validación de Windows Server
IBM WebSphere  Funciona bajo Linux, Microsoft Java SW Es válido en entornos de alto rendimiento, así como si se requiere un entorno
Portal Server Windows, HP-UX, Solaris, i5/OS, propietario escalable.
and z/OS.
Una de sus principales desventajas es su dificultad de implantación, así como
 Requiere un directorio LDAP.
la importante inversión que hay que realizar tanto en tecnología como en
 Requiere BD IBM DB2
personal cualificado.
 Se integra con Lotus Web
Content Manager
 Dispone de tecnologías
complementarias: gestión de
contenidos, mashups, entornos
de colaboración sociales,
seguridad y gestión.
 Soporta estándar JSR 286.

Fecha: Mayo 2017 3/3

GESTORES DOCUMENTALES.

Este tipo de herramientas permiten administrar el flujo de documentos (o activos digitales) de todo tipo en una organización,
recuperar información desde ellos, determinar el tiempo que los documentos deben guardarse, eliminar los que ya no sirven
y asegurar la conservación indefinida de los documentos. En definitiva, facilitan y gestionan el almacenamiento seguro, la
indexación y la recuperación de contenidos documentales. Están especializados en el escaneado de documentos, indexación,
optimización del almacenamiento, archivo y gestión de procesos y flujos de trabajo.
Entre las alternativas reutilizables para la implantación de un gestor documental están:
 Espacios de Colaboración (Tecnología: Java. Basado en Liferay. Responsable: MINHAP).
 Inside (Tecnología: Java. Responsable: MINHAP).
 G-Inside (Tecnología: SaaS con web services. Responsable: MINHAP).
 @Doc (Tecnología: Java. Responsable: Ministerio de la Presidencia).

→ Ver más información el documento “Aplicaciones reutilizables" en la sección 04. Transversal > 01. Servicios
Red SARA, así como en el CTT-PAe.

En el mercado existen diferentes soluciones de gestores documentales. De cara a la preparación del cuarto examen, es
importante tener en cuenta las siguientes premisas:
 ¿El gestor documental de software abierto o es propietario? Esta cuestión resulta crucial para poder determinar si
en el presupuesto de nuestro sistema debemos incluir la licencia por la adquisición o utilización de esa herramienta.
Nota: aunque elijamos una alternativa de código abierto, puede que decidamos contratar soporte y, en ese caso,
deberíamos considerarlo en el presupuesto.
 ¿Qué tecnología utiliza el gestor documental?
Nota: al elegir el gestor documental debemos considerar la tecnología que utiliza. No tiene sentido que planteemos
un sistema .NET y que incluyamos un gestor documental en Java. Todo el sistema debe ser coherente.
 ¿Qué BD, sistema operativo, servidor de aplicaciones, etc. soporta el gestor documental? Tal y como se ha
comentado en el punto anterior, debemos asegurarnos de que el planteamiento de nuestro sistema sea coherente.
Por tanto, de cara a la elección del gestor documental se deberá tener en cuenta con qué BBDD es compatible, con
qué servidores, etc.

A continuación, se incluye un detalle con los principales gestores documentales disponibles en el mercado (tanto de código
abierto como propietario).

Recomendación: Teniendo en cuenta la amplia oferta de soluciones existente, lo más interesante es que seleccionéis al
menos uno para cada tecnología y conozcáis sus principales características de cara a la resolución del supuesto práctico.

Nota: La JSR 170 es la correspondiente a gestión documental.

Nota: En el caso de que sea necesario plantear un gestor documental en la resolución del cuarto examen, es interesante
que la solución escogida permita cumplir con las NTIs (Normas Técnicas de Interoperabilidad) correspondientes.

Fecha: Mayo 2017 1/2

Herramienta Características Tecnología Licencia Información adicional
Alfresco  Tiene integrado el motor jBPM Java Código Utiliza componentes de software libre ampliamente difundidos (Hibernate,
(definición de procesos) y el abierto Lucene, etc.)
(también se
motor Activiti
considera gestor
 Está basado en la JSR 170
de contenidos)
(gestión documental) La combinación Liferay+Alfresco tiene una amplia aceptación.
 Dispone de soporte comercial
en su versión Enterprise
 Proporciona acceso al Destacar que, aunque sea de código abierto, existe el compromiso de pagar
repositorio mediante CIFS, el mantenimiento (por CPU).
FTP y WebDAV
 Posibilidad de instalación en
clúster
 Altamente escalable
 Especialmente pensado para
integrarse con Liferay Portal
Magnolia  Multiplataforma Java Código
 Proporciona módulos que abierto
integran frameworks como
struts, spring, stripes o
wickets para facilitar la
integración con aplicaciones
propias del usuario
 Integra JAAS (estándar Java
para la autenticación y
autorización de usuarios)
Documentum  Multiplataforma Java SW Muchas empresas han migrado o se están migrando de Documentum a
 Proporciona acceso al propietario Alfresco. Algunos de los motivos que han propiciado estos cambios son los
repositorio mediante servicios siguientes:
web, WebDAV, FTP y
 Agresiva revisión de licencias por parte de Documentum
SMB/CIFS
 Licencia vinculada al número de usuarios (Alfresco presenta un
modelo simple de precios de mantenimiento por CPU).
 Retrasos en lanzamiento de productos y falta de actualización en
los componentes.

Fecha: Mayo 2017 2/2

SISTEMAS DE WORKFLOW
El flujo de trabajo permite estructurar las tareas: cómo se realizan, cuál es su orden correlativo, cómo se sincronizan,
cómo fluye la información que soporta las tareas y cómo se le hace seguimiento al cumplimiento de las tareas.
Los sistemas de workflow permiten modelizar, por ejemplo, un procedimiento administrativo. Si por ejemplo el sistema a
diseñar tuviera que gestionar expedientes, tramitados por diferentes personas y que pasan por diferentes fases, un
sistema de workflow sería muy interesante en ese caso.
Las funcionalidades serían:
- Asignación de tareas al personal.
- Aviso al personal de tareas pendientes.
- Control y seguimiento de procesos y del estado de cada una de las etapas de las tareas.

Es importante tener en cuenta que, a la hora de diseñar el flujo de trabajo, generalmente se utiliza la notación gráfica
BPMN. Esta notación permite modelar procesos que corren dentro de aplicaciones. Posteriormente, esta representación
gráfica se debe transformar a un flujo ejecutable por una herramienta. Para ello, podemos utilizar:
a. El metalenguaje BPML
b. El lenguaje XPDL
c. El lenguaje BPEL

Entre las alternativas reutilizables para la implantación de un sistema de workflow están:

• SISTRA (Tecnología: Java. Responsable: Gobierno de las Islas Baleares)
• Acceda (Tecnología: PHP/SaaS con web services. Responsable: MINHAP)
• PRO@ (Tecnología: .NET. Responsable: MINETUR)
• Solicit@ (Tecnología: .NET. Responsable: Ministerio de la Presidencia)

→ Ver más información el documento "Aplicaciones reutilizables" en la sección 04.Transversal >

01.Servicioes Red SARA así como en el CTT-PAe.
Recomendación: Este tipo de soluciones puede tener un coste muy elevado, por tanto, de cara a la realización del
cuarto examen sería recomendable asumir que se utilizará el sistema de workflow existente en el organismo y que se
adaptará al caso concreto del sistema a diseñar.

Fecha: Mayo 2017 1/2

 Tecnol
Herramienta Características Licencia Información adicional
ogía

JBoss jBPM • Utiliza jPDL como su Java Apache jBPM es un motor de flujo de trabajo que toma
propio lenguaje de License descripciones gráficas de proceso como
definición de 2.0 entrada.
procesos
Se basa en la Máquina Virtual de Procesos
• Puede ejecutar los
que es el fundamento de la comunidad JBoss,
procesos de negocio
para soportar múltiples lenguajes de proceso
que se describen en
de forma nativa.
BPMN 2.0
• Basado en el Proporciona varias herramientas, tanto para
estándar BPEL de los desarrolladores (Eclipse) y usuarios finales
OASIS (basado en la web) para crear, implementar,
• Multiplataforma ejecutar y gestionar los procesos de negocio a
lo largo de su ciclo de vida.
Alfresco tiene integrado el motor jBPM.
Se distribuye a través de jBoss.

Activiti • Utiliza BPMN 2.0 Java Apache Alfresco tiene integrado el motor Activiti.
como lenguaje de License
definición de 2.0
procesos Se distribuye a través de Alfresco o de la
• Multiplataforma comunidad Activiti

BizTalk • Compatible con .NET SW Si en el organismo donde se quiere implantar

Server BPEL, BPMN, propietario la solución utilizan .NET, BizTalk Server en
RFID, WSDL, combinación con el gestor documental y
UDDI, WS-* plataforma de colaboración Sharepoint sería
una buena solución.

Open ESB • Permite integrar Java CDDL Java Business Integration (JBI) es una
sistemas legacy especificación desarrollada bajo la Java
Community Process (JCP) con el objetivo de
• Compatible con
implementar en Java una Enterprise
JBI, XML, XML Application Integration (EAI), siguiendo los
Schema, WSDL, principios de la Arquitectura Orientada a
BPEL Servicio (SOA), Open ESB es una
• Pertenecía a Sun implementación libre basada en JBI.
pero ahora lo
gestiona la
OpenESB Otras soluciones open source son:
Community (año Mule, WSO2, ServiceMix o Jboss Fuse.
2010)

En el siguiente enlace se muestra un cuadro resumen muy interesante con diferentes motores BPEL y BPMN:
http://en.wikipedia.org/wiki/Comparison_of_BPEL_engines

Fecha: Mayo 2017 2/2

 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo Superior de
Sistemas y Tecnologías de la Información de la
Administración del Estado

HERRAMIENTAS DE BUSINESS INTELLIGENCE

Estas herramientas se encargan del análisis y presentación de datos, lo que permite el

soporte a la toma de decisiones, elaboración de estadísticas e informes, análisis de los
datos involucrados en el sistema (OLAP, Data mining, cuadros de mando, etc.).

Estas herramientas son muy útiles ya que permiten:

 Utilizar los propios datos de una organización como punto de partida para la toma de
decisiones.
 Realizar una optimización de procesos.
 Realizar reportes operacionales.
Las herramientas de business intelligence pueden ser de cinco estilos diferentes:

 Reporte empresarial.
 Cubos de análisis.
 Vistas Ad Hoc Query y análisis.
 Data mining y análisis estadísticos.
 Entrega de reportes y alertas.

Recomendación: Normalmente, en el cuarto examen no se suele pedir una solución de

business intelligence de forma explícita. No obstante, en algunos casos resulta aconsejable
incluir algún módulo de explotación/análisis de datos para la toma de decisiones de forma
complementaria y adicional.

A continuación se indican algunas de las herramientas de business intelligence existentes

en el mercado:

1
 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo Superior de
Sistemas y Tecnologías de la Información de la
Administración del Estado

Herramienta Características Tecnología Licencia Información adicional

Pentaho  Corre bajo los sistemas Java Código Incluye herramientas integradas para generar informes,
operativos Windows, abierto minería de datos, ETL, etc.
Linux y Mac OS X (Pentaho
 Genera los informes en Communit
diferentes formatos: y Edition
HTML, Excel, CSV, PDF (CE):
y RTF. Apache
 Interfaz web muy version
intuitive 2.0)
 Acceso a datos
relacionales, OLAP y
XML
JasperReports  Multiplataforma Java Código Es una librería que se puede embeber en una aplicación
 Soporta los formatos abierto Java, incluyendo Java EE o aplicaciones web.
PDF, HTML, Microsoft (LGPL)
Excel, RTF, ODT, Es útil si sólo deseamos elaborar informes y estadísticas.
Comma-separated
values o XML. Varios IDEs de Java (NetBeans, Eclipse, IBM Websphere
 Lee las instrucciones Studio Application Developer) proporcionan instrucciones
desde un fichero XML o para integrar JasperReports en un proyecto.
.jasper
Oracle BI  Utiliza interfaces ODBC Java SW
2.0 y JDBC propietario

2
 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo Superior de
Sistemas y Tecnologías de la Información de la
Administración del Estado

CLASIFICACION AUTOMÁTICA DE DOCUMENTOS

Un tipo de sistemas que no está muy extendido en la Administración pero que puede
ser interesante tener en cuenta en algunas situaciones son los clasificadores
automáticos de documentos. Su utilización aporta las siguientes mejoras:

 permite emplear un menor número de personal en la tarea de lectura y

clasificación de documentos, y emplearlos en otras unidades donde aporten
más valor.
 optimiza el tiempo de respuesta.
 homogeniza el resultado en la clasificación al no incorporar la subjetividad
humana.

Estos sistemas son útiles cuando se reciben documentos de texto libre por parte de los
ciudadanos, y se encargan de clasificarlos de forma automática y reenviarlos a la
unidad encargada de tratar cada tipo de documento o procedimiento.

Los clasificadores automáticos son herramientas no deterministas, y hay que tener

muy en cuenta que nunca van a llegar a un 100% de acierto, de hecho, en los
sistemas con unos documentos de buena calidad se suele llegar como máximo a un
90%.

Elementos de un sistema de clasificación de documentos

1. Carga de documentos

El primer elemento del sistema es el encargado de la carga de documentos en el

sistema. Puede ser de cualquier tipo: sistema de ficheros, servicios web, cargas batch,
etc.

2. OCR

Si el sistema permite el envío de documentos manuscritos escaneados es necesario la

utilización de un OCR (Optical Character Recognition). Hay que tener en cuenta que la
necesidad de un OCR tiene dos implicaciones:

 el tiempo de proceso aumenta considerablemente, ya que los OCR suelen ser

lentos.
 la precisión del sistema disminuye.

3. Módulo de análisis del lenguaje natural (NLP)

Este módulo se encarga de realizar un procesamiento muy diverso sobre el lenguaje.

Desde eliminación de stoptwords, aplicación de sinónimos, hasta algoritmos más
avanzados que realizan identificación sintáctica de los elementos del texto.

3
 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo Superior de
Sistemas y Tecnologías de la Información de la
Administración del Estado
4. Módulo de clasificación

A partir de la información que se ha obtenido del módulo de análisis del lenguaje, se

aplican algoritmos matemáticos para la clasificación en grupos. Los más utilizados
suelen ser Máquinas de Vector Soporte, y clasificadores bayesianos.

4
 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo Superior de
Sistemas y Tecnologías de la Información de la
Administración del Estado

Herramienta Características Tecnología Licencia Información adicional

OCR Tesseract  Corre bajo los sistemas C SW libre:
operativos Windows y Linux Apache
 Desarrollado por Google version 2.0
 Se trata de uno de los OCR más
usados
 No soporta layout de páginas
OCR Abbyy  Windows SW Debido a su elevado coste en la muchos proyectos se suele
 Ofrece una gran calidad de propietario utilizar Tesseract
reconocimiento, en la mayoría
de los casos por encima de
Tesseract
 Soporta layout de páginas
Mahout  Multiplataforma Java SW libre: Muchas de sus funciones tienen implementación para
 Librería de minería de datos Apache desplegar en infraestructuras Hadoop / Cloudera de Big Data
ampliamente utilizada. version 2.0
 Se integra muy bien en el
ecosistema Apache
R  Dispone de versiones para C SW libre: Permite tanto su uso como aplicación de escritorio en que un
Windows, Linux y Mac GNU usuario realiza cálculos estadísticos, como la programación de
 Plataforma de estadística y funciones que se pueden integrar con otros sistemas.
minería de datos muy utilizada
 Incluye su propio lenguaje de
scripting para definir los análisis
que se realicen

5
 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo Superior de
Sistemas y Tecnologías de la Información de la
Administración del Estado

HERRAMIENTAS ESB

Un ESB es el elemento software que media entre las aplicaciones de una organización y
permite la comunicación entre ellas. Idealmente el ESB tendría que ser capaz de sustituir
todo contacto directo con las aplicaciones en el bus, de modo que toda la comunicación
tenga lugar a través del bus.

La necesidad de un ESB surge de la complejidad de las organizaciones que deben

coordinar e integrar sus procesos de negocio, sistemas operacionales y datos sin renunciar
a la innovación tecnológica.

Un ESB puede distribuirse a lo largo de una organización, no necesitando un punto central

de integración y permitiendo la interoperabilidad entre sistemas implementados en diversas
tecnologías.

Permite:

- Enrutamiento y direccionamiento de mensajes.

- Comunicación síncrona/asíncrona
- Orquestación y coreografía de los procesos de negocio
- Multiplicidad de tipos de transporte y protocolos de enlace.
- Procesamiento de eventos.
- Presencia de adaptadores a múltiples plataformas.
- Herramientas de diseño de la integración, de implementación y despliegue.
- Características de garantía de la calidad del servicio (QoS), como transaccionalidad,
seguridad y persistencia.
- Auditoría, registro y métricas.
- Gestión y monitorización.

Nota: Sería muy raro que en el cuarto examen plantearan un sistema en el que fuera
necesario la inclusión de un ESB. En cualquier caso, siempre es positivo llevar preparados
todas las posibles opciones.

A continuación se indican algunas ESB comerciales existentes en el mercado:

1
 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo Superior de
Sistemas y Tecnologías de la Información de la
Administración del Estado

Herramienta Características Tecnología Licencia Información adicional

Oracle  El servidor ESB soporta Java SW Simplifica la interacción y comunicación entre los productos
Enterprise HTTP/SOAP, JMS, JCA, propietario Oracle existentes o entre aplicaciones de terceros.
Service Bus WSIF and Java
(BEA Logic)  Se integra con Oracle El servicio ESB se diseña y configura con las interfaces de
BPEL Process Manager usuario Oracle JDeveloper y Oracle ESB Control. Luego se
registra en un servidor ESB
IBM  Alta disponibilidad Java SW Está construido sobre estándares abierto, SOA, mensajería y
WebSphere  Soporta los protocolos propietario tecnologías de servicios web
ESB JMS, MQ, EJB, Web
Services, REST, HTTP,
etc.
 Soporta los formatos
XML, Text, delimited,
COBOL, etc.
JBoss ESB  Multiplataforma Java Código Se utiliza para conectar sistemas, especialmente sistemas no
 Desarrollado por RedHat abierto interoperables
(GNU)
Apache  Multiplataforma Java Código Se puede utilizar en Java SE o en un servidor de
ServiceMix  Proporciona federación abierto aplicaciones Java EE.
y clustering (Apache
 Cumple con la License Normalmente se utiliza con Apache ActiveMQ, Apache
especificación JBI JSR 2.0) Camel and Apache CXF en proyectos de infraestructura
208 SOA.
 Cumple con la
especificación OSGi 4.2 Especialmente interesante por su alto grado de adecuación a
a través de Apache Felix estándares, sumando a los propios de un ESB como XML y

2
 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo Superior de
Sistemas y Tecnologías de la Información de la
Administración del Estado
WSDL, otros propios del universo Java como JBI (Java
Business Integration) y OSGi.
Open ESB  Corre bajo Windows, Java Código Es el único ESB de código abierto que soporta los estándar
Linux y Mac OS abierto JSR-208 (JBI, Java Business Integration), XML, XML
 Permite integrar (CDDL) Schema, WSDL, BPEL
sistemas legacy en los
procesos de negocio
Mule  Multiplataforma (JVM) Java Código Es un ESB más ligero.
 Arquitectura escalable abierto Basado en java pero puede gestionar peticiones de otras
(CPAL) plataformas (como .NET) mediante servicios web o sockets.
WSO2  Soporta la creación de Java Código Es un ESB simple, ligero y de alto rendimiento
servicios proxy de forma abierto
gráfica

3
 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo Superior de
Sistemas y Tecnologías de la Información de la
Administración del Estado

HERRAMIENTAS VARIAS

En este apartado se enumeran algunas herramientas software no incluidas dentro de las

categorías anteriores.

Nota: estas herramientas presentan diversas funcionalidades y probablemente no sean

objeto de pregunta de forma explícita en el cuarto examen, aunque se pueden considerar
como alternativa para generar valor añadido.

Las herramientas consideradas son las siguientes:

 Herramientas de monitorización de red:

o Nagios: código abierto
o HP Openview: propietario

 Herramienta de monitorización de aplicativos:

o Hyperic

 Herramienta para vigilar la disponibilidad del sistema:

o Jmeter: código abierto.

 Herramienta para generar informes (análisis web):

o AWStat: código abierto.

 Herramientas para generar logs en una aplicación web:

o Java: Log4J
o PHP: Log4PHP

 Herramienta para controlar el rendimiento y el funcionamiento de una

aplicación Java:
o Introscope

 Herramienta para realizar el control del código:

o SourceSafe: propietario.
o TeamFoundation (de Microsoft).

 Herramienta para generar carga:

o Apache JMeter (simula diferentes tipos de carga)
o Surge (genera peticiones web con características estadísticas que simulan
con mucha precisión la demanda típica de un servidor web)
o Ms Web Application Stress (prueba un sitio con IIS + ASP)

1
INTEGRACIÓN DE COMPONENTES, SERVICIOS Y APLICACIONES
El objetivo de esta guía es enumerar las diferentes opciones que tenemos a la hora de conseguir que varias
aplicaciones trabajen de forma conjunta, sin entrar a describir en profundidad las diversas tecnologías. Se
consideran las situaciones en las que puede ser conveniente emplear cada tecnología, así como los
escenarios de uso habituales.

SERVICIOS WEB (WS)

Actualmente es la tecnología por excelencia para integrar aplicaciones. Es la primera opción que debemos
contemplar, salvo que se den circunstancias que desaconsejen su uso.

Existen multitud de especificaciones en torno a los servicios web, mayoritariamente emitidas por los
consorcios W3C y OASIS. En la mayoría de los casos, es suficiente con emplear el conjunto de protocolos
incluidos en el WS-I Basic Profile (perfil básico definido por la Organización para la Interoperabilidad de
Servicios Web): SOAP para describir el formato de los mensajes y WSDL como descriptor de los servicios
son los protocolos principales.

Los WS son neutrales desde el punto de vista del lenguaje de programación y las plataformas de ejecución.
Existen implementaciones certificadas en el perfil básico WS-I para múltiples plataformas y lenguajes: Zend
Framework para PHP, gSOAP para C/C++, ASP.Net 2.0 o WCF para la plataforma .Net, etc. En el entorno
JavaEE, las implementaciones de la API JAX-WS (JSR 224) son conformes al perfil básico WS-I. Apache
Axis 2 es una implementación bastante popular de la JSR 224, distribuida bajo licencia libre Apache Software
Foundation.

SOAP es independiente del transporte. Lo que se entiende normalmente al hablar de WS es SOAP sobre
HTTP o HTTPS, pero también sería válido el intercambio de mensajes SOAP sobre FTP, SMTP,
directamente sobre conexiones TCP/UDP, etc. La principal ventaja de SOAP sobre HTTP es que no presenta
problemas para atravesar los firewalls, ya que estos se configuran habitualmente para dejar pasar el tráfico
HTTP.

REST nace como una alternativa para simplificar la comunicación entre procesos. Está basado en un
esquema cliente-servidor, y utiliza el protocolo HTTP como modelo central de comunicación. Mientras que
trabajar con SOAP en JavaScript, por ejemplo, implicar escribir una importante cantidad de código porque la
estructura XML debe ser creada cada vez, REST resuelve este conflicto basándose en simples direcciones
URL. En casi todas las situaciones los servicios se comunicarán vía URL, a través de comandos GET, POST,
PUT y DELETE. Esta notable sencillez es el gran punto fuerte de REST. Prácticamente no tiene costos de
aprendizaje, y de manera directa se pueden desarrollar servicios web sin la necesidad de pesados protocoles
de comunicación.

Comparación SOAP - REST

Si bien ambos proveen la misma funcionalidad (comunicar dos servicios web), sus raíces son distintas. REST
está basado en un esquema cliente-servidor, mientras que SOAP es un protocolo dedicado al intercambio de
datos entre dos puntos dedicados. Esto ya saca a relucir una diferencia importante desde el punto de vista
arquitectónico. Con respecto a seguridad, ninguno es particularmente más “seguro” que el otro, aunque
SOAP cuenta con extensiones que garantizan seguridad punto a punto. Si tiene ventajas SOAP desde el
punto de vista de transacciones, contemplando nociones como Two-Phase commit, y otros enfoques para el
manejo de transacciones distribuidas. REST, priorizando un protocolo simple y ligero, adolece de este tipo de
cuestiones. En cuanto a la posibilidad de adaptarse a diferentes plataformas, si bien REST depende del
protocolo HTTP, SOAP ofrece muchas extensiones, con sutiles diferencias entre sí, y comunicarlas a todas
en un lenguaje común no es tan simple en muchas ocasiones. Luego, REST parece salir mejor parado de
esta situación, teniendo como única precondición la comunicación via URLs.
REST permite inúmeros formatos de datos, dando por ejemplo al desarrollador la posibilidad de utilizar JSON
que normalmente es más rápido y como permite la utilización de JSON, permite también un mejor soporte a
los clientes del explorador. SOAP solamente permite XML.

Fecha: Mayo 2017 1/3

Lo más habitual al hablar de WS es considerar un modelo petición-respuesta síncrono, pero las
especificaciones son suficientemente flexibles para permitir otros modelos: petición-respuesta asíncrona,
notificación en un solo sentido (sin respuesta del servidor), etc.

Es importante, a la hora de plantear una integración a través de Servicios Web, identificar claramente al
proveedor del servicio (despliega y escucha) y al consumidor del servicio (invoca al servicio).

MECANISMOS DE INTEGRACIÓN DE APLICACIONES TRADICIONALES

Deben ser tenidos en cuenta como posible alternativa al uso de WS. Los principales son los siguientes:

Envío de ficheros.- Es el mecanismo de integración más primitivo, en el que una aplicación genera un
fichero con un formato preestablecido y lo deposita en una ruta determinada (posiblemente mediante envío
FTP a un servidor remoto); otra aplicación lee este fichero y lo procesa, y genera ficheros de respuesta que
luego pueden ser recogidos por la primera aplicación. Aunque presenta desventajas evidentes que lo hacen
poco mantenible (falta de formatos estandarizados, alto grado de acoplamiento entre las aplicaciones,...),
puede ser una buena solución cuando se requiere una transmisión y procesado de grandes volumenes de
datos, especialmente en entornos de comunicación cerrados (en los que las aplicaciones que van a generar y
consumir la información se conocen de antemano). En el ámbito tributario y de la Seguridad Social, todavía
existen mecanismos de este tipo para la consulta y/o envío masivo de información, utilizados frecuentemente
por empresas y otros organsimos públicos.

Base de datos compartida.- Supone una mejor respecto al envío de ficheros. Múltiples aplicaciones
comparten un esquema de datos sobre una misma base de datos física. Evita duplicidad en el
almacenamiento y la transferencia de datos entre aplicaciones. El empleo de vistas lógicas permite cierto
grado de aislamiento entre las aplicaciones. Es una buena solución para compartir información e integrar
aplicaciones dentro de la propia organización. Es complicado implementar un patrón de interacción del tipo
petición-respuesta.

Remote Procedure Call (RPC).- Nombre genérico para todos los mecanismos en los que un programa es
capaz de llamar a una rutina de otro programa que se está ejecutando en una máquina remota y obtener una
respuesta. En su día fueron populares los estándares DCOM o CORBA. SOAP es un tipo de mecanismo
RPC; de hecho, es la evolución del antiguo estandar XML-RPC. La única ventaja que pueden presentar estos
mecanismos clásicos respecto a los servicios web es que introducen menos sobrecarga de información (las
cabeceras SOAP y la serialización XML no resulta óptima para transmitir grandes volumenes de información).
No obstante, no hay demasiados motivos para considerar este tipo de integración, salvo que haya que dar
soporte a la integración de aplicaciones heredadas (legacy) que no permitan otro tipo de interacción.

MIDDLEWARE DE INTEGRACIÓN DE APLICACIONES

Son productos software cuya finalidad es facilitar la integración de aplicaciones heterogéneas. Son
características habituales de este tipo de productos:
 Independencia del fabricante, la plataforma o el lenguaje de programación de las aplicaciones,
ofreciendo adaptadores para múltiples transportes y protocolos (HTTP, FTP, REST, SOAP, SAP
RFC, DCOM, CORBA, objetos Java simples,...)
 Mapeo entre productores y consumidores de información y enrutado de mensajes dinámico y basado
en reglas.
 Encolado y priorización de mensajes.
 Orquestación de servicios.
 Calidad de servicio: validación de mensajes, seguridad (autenticación, encriptación), entrega
confiable, gestión de transacciones,etc.
 Herramientas de gestión: monitorización, métricas, auditoría, registro de eventos,etc.

Básicamente, los productos que se definen como middleware de integración caen en una de las siguientes
categorías: Buses de Servicios Empresariales (Enterprise Service Bus o ESB) o Colas/Brokers de
Mensajería Asíncrona (Message Queues o MQ). Los primeros están más orientados al paradigma
petición/respuesta, mientras que los segundos se orientan hacia el paradigma publicación/subscripción. Para
una descripción más detallada de los ESB, véase la guía “Módulos Software > Herramientas ESB”.

Fecha: Mayo 2017 2/3

El cuadrante mágico de Gartner para herramientas de integración de aplicaciones publicado en junio de 2013
sitúa como líderes del mercado a los fabricantes Software AG (webMethods), IBM (WebSphere MQ,
WebSphere Registry and Repository), Oracle (Oracle SOA Suite), Tibco Software (ActiveMatrix ESB,
ActiveMatrix BusinessWorks, Business Connect) y Microsoft (BizTalk Server).

ESCENARIOS HABITUALES DE INTEGRACIÓN DE APLICACIONES

Servicios comunes dentro de la Organización.- En los sistemas de información de todos los organismos
administrativos existen aplicaciones horizontales cuya finalidad es ofrecer un determinado servicio a otro
conjunto de aplicaciones internas. Ejemplos de este tipo de servicios son el registro electrónico, el gestor
documental/archivo de expedientes, el portafirmas electrónico, servicios de autenticación mediante certificado
electrónico, servicio de notificaciones electrónicas, plataforma de envío de SMS, etc. Es recomendable que
todos estos componentes de servicio horizontales implementen una interfaz WS, de forma que se consiga
maximizar la interoperabilidad con distintas plataformas y lenguajes de programación y minimizar la
dependencia con las aplicaciones consumidoras. Es habitual encapsular las llamadas a estos WS comunes
en librerías que puedan ser integradas y utilizadas fácilmente por las aplicaciones.
En el caso concreto de los gestores de contenidos, es habitual usar el estándar CMIS (Content Management
Interoperability Services), que es una extensión de SOAP.

Servicios compartidos entre Administraciones.- La mayor parte de servicios reutilizables de las

Administraciones Públicas accesibles a través de la red SARA implementan una interfaz de servicios web
para su utilización, permitiendo que cada organismo integre estos servicios en sus propias aplicaciones de
tramitación. Algunos de estos servicios transversales de uso muy común y que cuentan con una interfaz WS
son: el servicio Valide para verificación de validez de certificados y firmas electrónicas, los servicios de la
plataforma de sellado de tiempo TS@, la pasarela de pago telemático, la consulta del punto general de
entrada de facturas electrónicas (FACE), los servicios de publicación de licitaciones y adjudicaciones en la
Plataforma de Contratación del Estado (PLACE), INSIDE, GEISER, ARCHIVE, el portafirmas de la suite
@firma, etc..

Plataforma de Intermediación.- Como caso particular de servicio horizontal accesible a través de la Red
SARA, la Plataforma de Intermediación se utiliza para recabar, previa autorización, determinada información
sobre ciudadanos que obra en poder de otros organismos: datos fiscales y de la seguridad social, titulaciones
académicas oficiales, datos catastrales,... La obtención de datos se realiza mediante llamadas a WS
síncronas o asíncronas. El proveedor de información debe publicar también sus propios WS para que la
Plataforma de Intermediación los invoque cuando sea necesario.

Obligaciones de suministro de información.- Determinados organismos públicos ejercen una función de

control o fiscalizadora sobre otros organismos, por ejemplo, en los ámbitos de la contratación pública, la
ejecución del presupuesto o la concesión de ayudas y subvenciones. Los sistemas informáticos que
mantienen estos órganos de control para la remisión de información, además de tener una interfaz web de
consulta y envío, suelen incorporar diversos mecanismos de integración (tales como interfaces WS o
procesamiento masivo de ficheros), con el fin de que los organismos obligados al suministro de información
puedan automatizar estos procesos incorporándolos a sus propios sistemas de tramitación.

Federación de sistemas de información.- Puede aparecer también el caso de una Administración que
tenga que compartir determinados registros o catálogos de información con otras administraciones de ámbito
nacional o internacional, con el fin de crear un registro o catálogo federado: catálogos de biblioteca, historial
sanitario, registros policiales, catálogo de bienes protegidos, etc. En estos escenarios, cada administración
mantiene su propio sistema, pero debe habilitar mecanismos de integración que permitan al resto de
administraciones extender sus servicios de búsqueda y consulta. Lo habitual es que se defina una interfaz y
un formato de intercambio normalizados, y puede haber un organismo que haga de intermediario o pasarela
de consultas.

Fecha: Mayo 2017 3/3

 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo
Superior de Sistemas y Tecnologías de la
Información de la Administración del Estado

Análisis de alternativas software y hardware.

El objetivo es proporcionar alternativas a alto nivel para el software y hardware,
evaluar las ventajas e inconvenientes de dichas alternativas y proponer aquellas
opciones que mejor se ajusten a las características de nuestro proyecto.

Con respecto al software, podemos identificar las siguientes alternativas:

 Producto cerrado, desarrollo a medida o producto parametrizable.
 Desarrollo con personal interno o externo.

Para el hardware podemos evaluar las siguientes alternativas:

 Financiación: compra, alquiler o equipos usados.
 Ubicación: oficinas de la organización o localización externa.

Alternativas software.
Producto cerrado o desarrollo a medida.

PRODUCTO CERRADO.

Adecuado si tenemos que cubrir necesidades “habituales”.

Ventajas:
 Más económico.
 Puesta en producción rápida.
 No necesidad de recursos humanos para desarrollo ni mantenimiento.

Inconvenientes:
 Menos flexibilidad, adaptado a necesidades generales.
 Dependencia de proveedores externos, y por lo tanto, posibles problemas
para evoluciones, soporte y continuidad del producto.
 Modificaciones y adaptaciones caras y complejas.

Ver guía Módulos software habituales con indicaciones y ejemplos de alternativas

concretas de productos propietarios y libres.

DESARROLLO A MEDIDA.

Adecuado si tenemos que cubrir necesidades “no habituales”.

Ventajas:
 Flexibilidad, adaptado a nuestras necesidades concretas.
 Control sobre el producto.
 No dependencia de proveedores externos.

1
 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo
Superior de Sistemas y Tecnologías de la
Información de la Administración del Estado

Inconvenientes:
 Más caro.
 Mayor tiempo hasta solución en producción.
 Necesidad de recursos humanos.
 Mayores costes de mantenimiento debido a las especificidades.

PRODUCTO PARAMETRIZABLE.

Solución intermedia entre el desarrollo a medida y un producto cerrado. Tenemos

dependencia externa.

Desarrollo con personal interno o externo.

DESARROLLO PERSONAL INTERNO.

Ventajas:
 Mayor control.
 Mayor conocimiento interno sobre el funcionamiento del sistema.
 Reducción de dependencia con empresas externas.
 Mejor adaptación a las necesidades de la organización.
 No es necesario formalizar un contrato.

Inconvenientes:
 Requiere disponibilidad de personal suficiente y cualificado.
 Menor flexibilidad para adaptar el número de recursos a las necesidades de
cada momento.

DESARROLLO PERSONAL EXTERNO.

Ventajas:
 No necesidad de disponer de una plantilla numerosa de personal cualificado.
 Se puede disponer de personal experto en ámbitos muy específicos.

Inconvenientes:
 Se pierde control.
 Menor conocimiento interno sobre el funcionamiento del sistema.
 Dependencia con empresas externas.
 Mayor coste.
 Tiempo necesario para la realización de la contratación de los servicios.

DESARROLLO MIXTO.

Solución intermedia basada en la composición de grupos de trabajo formados por

personal interno y externo.

2
 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo
Superior de Sistemas y Tecnologías de la
Información de la Administración del Estado

Alternativas hardware.
Financiación: Compra, alquiler o equipos usados.
Factores a tener en cuenta:
 Presupuesto actual y previsto.
 Conocimiento de los requisitos.
 Riesgos de obsolescencia.

COMPRA.

Adecuado si:
 Disponibilidad de presupuesto suficiente en la actualidad y previsto.
 No se contemplan cambios a corto/medio plazo.
 Bajos riesgos de obsolescencia.

Es la opción más frecuente.

ALQUILER.

Adecuado si:
 No se dispone de presupuesto suficiente para comprar.
 Cambios previstos a corto/medio plazo.
 Requisitos no estables.
 Altos riesgos de obsolescencia.

EQUIPOS USADOS.

Adecuado si se busca una solución transitoria.

Ubicación: Oficinas de la organización o localización externa.

OFICINAS DE LA ORGANIZACIÓN.

Ventajas:
 Control del HW.
 Facilita intervenciones por parte de los empleados de la organización.

Inconvenientes:
 Espacio dedicado para alojar el equipamiento hardware y acondicionamiento
del mismo.

3
 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo
Superior de Sistemas y Tecnologías de la
Información de la Administración del Estado
LOCALIZACIÓN EXTERNA.

Desvincula a la organización del mantenimiento físico pero se pierde control sobre

los equipos.

Nube.

Alternativa para hardware y software en auge. Ver detalles en la guía Cloud

Computing.

Aspectos a tener en cuenta a nivel de producto.

 Explotación/Administración interna o externa: Mismas consideraciones que
para el desarrollo con personal interno o externo (ver sección “Desarrollo con
personal interno o externo”).
 Interoperabilidad: Búsqueda de soluciones interoperables para reducir la
dependencia con el proveedor.
 Escalabilidad.
 Seguridad.
 Calidad.
 Formación.
 Soporte: horario, tiempo medio y máximo de resolución de incidencias,
responsable (fabricante, distribuidor).

Análisis de alternativas
Para un análisis de alternativas a bajo nivel de productos podríamos plantear una
matriz de evaluación.

En la primera columna pondríamos las alternativas a evaluar, mientras que en la

primera fila pondríamos los criterios de evaluación con sus pesos. En las celdas se
realiza la valoración concreta de cada alternativa en el criterio correspondiente.

4
 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo
Superior de Sistemas y Tecnologías de la
Información de la Administración del Estado

ANÁLISIS DAFO.

Qué es un Análisis DAFO.

El análisis DAFO pretende identificar las Debilidades, Amenazas, Fortalezas y
Oportunidades para poder, de esa forma, conocer la situación real en que se
encuentra una organización, empresa o proyecto, y planificar una estrategia de
futuro.

En el caso del cuarto examen, si preguntaran por un DAFO, lo harían probablemente

orientándolo al sistema que se implementa o a la situación de cambio que se plantea
en el enunciado.

Conceptos importantes.
Para elaborar un DAFO hay que realizar un análisis externo y un análisis interno.

Análisis externo.

Amenazas: toda fuerza del entorno que puede impedir la implantación del sistema o
bien reducir su efectividad, o incrementar los riesgos de la misma, o los recursos que
se requieren para su implantación, o bien reducir los beneficios esperados.

Oportunidades: es todo aquello que pueda suponer una ventaja para la

organización, o bien representar una posibilidad para mejorar la misma.

Análisis interno.

Debilidades: aspectos que limitan o reducen la capacidad de desarrollo efectivo de

la estrategia de la organización, constituyen una amenaza para la organización y
deben, por tanto, ser controladas y superadas.

Fortalezas: ventajas competitivas que deben y pueden servir para explotar

oportunidades.

1
 Grupo de apoyo a la preparación de la XXIII
convocatoria de oposiciones al Cuerpo
Superior de Sistemas y Tecnologías de la
Información de la Administración del Estado
Propuestas para un DAFO.
AMENAZAS OPORTUNIDADES

● Desconfianza de los usuarios. ● Ventajas del sistema.

● Falta de promoción y comunicación que derive en una ● Dado el carácter estratégico del procedimiento en el
falta de conocimiento de los usuarios. que se aplica, es una gran oportunidad para introducir el
● Resistencia al cambio por parte de los usuarios. uso de la administración electrónica en colectivos muy
● Resistencia en el interior de los organismos por el amplios.
cambio cultural que supone la introducción de las TIC. ● Mejora de la gestión: mayor transparencia y fiabilidad
● Dependencia del buen funcionamiento del sistema, de este tipo de procedimientos
riesgos ante problemas de disponibilidad. ● Posibilidad de extender este sistema a otras
● Aumento del número de solicitudes como consecuencia administraciones.
de la mayor difusión y facilidad del servicio. ● Posibilidad que ofrece la administración electrónica
● Necesidad de colaboración con entidades externas al para realizar la tramitación desde cualquier punto.
Organismo. ● Reducción significativa de la carga de trabajo generada
● Dependencia de proveedores de tecnologías de la en el Servicio, fomentando que los recursos se dediquen
información. a tareas que aporten un mayor valor.
● Cambios rápidos en el entorno tecnológico. ● Posibilidad de tramitación 24 horas al día.
● Aparición de nuevas amenazas de seguridad. ● Reducción en la documentación que se exige.
● Coste elevado de las inversiones. ● Mayor nivel de difusión.
● Ciclo político, los cambios y orientaciones en las ● Mejora de la imagen de la AAPP ante el ciudadano.
políticas pueden dificultar la implantación de los ● Ahorro de costes tanto para la AAPP como para el
sistemas. ciudadano.
● Que existan problemas de usabilidad y accesibilidad ● Sirve para avanzar en la experiencia ante proyectos
para los usuarios. similares futuros.
● Simplificación administrativa.
● Benchmarking con otras unidades administrativas.
● Proporcionar servicios de calidad a los ciudadanos o a
otras AAPP.

DEBILIDADES FORTALEZAS

● Resistencia al cambio de toda organización ● Apoyo y liderazgo de la Dirección del proyecto.

administrativa. ● Impulso de la eAdmin desde la perspectiva legal.
● Necesidad de formación en el nuevo aplicativo. ● Políticas de Seguridad, Planes de Calidad
● Fusión de datos anteriores con el nuevo aplicativo. existentes en los Organismos.
● Falta de conocimientos tecnológicos especialmente en ● Modelos y metodologías que definen el marco
personas mayores. conceptual de la Administración Digital.
● Necesidades de formación sobre TIC y mayor ● Concienciación en aumento sobre la utilidad de las
despliegue de éstas. TIC.
● Limitaciones económicas debido a los planes de ● Concienciación en aumento sobre seguridad.
austeridad. ● Reutilización y aprovechamiento de sinergias (Centro
● Necesidad de una visión compartida, un alto nivel de de Transferencia de Tecnología y Servicios Comunes).
coordinación y alianzas internas y externas que, en ● Estándares y Normativas sobre Interoperabilidad y uso
ocasiones, es complejo. de Sistemas Abiertos.
● Si es un nuevo organismo: poca experiencia y personal ● Experiencia acumulada (proyectos parecidos).
que proviene de otros centros. ● Capacidad de adaptación al cambio y de introducir
nuevas TIC al servicio de la AAPP.
● Apoyo específico del personal TIC que lleva años
obteniendo experiencia en eAdministración.