4 5917815826890622794 PDF

APOYO A LA PROMOCIÓN ACCESO AL CUERPO DE GESTION
DE SISTEMAS E INFORMATICA 2018
Supuesto ADHESIONES.
Autor: Andrés García Cañizares.
La Secretaría General de Administración Digital(SGAD, hasta diciembre 2016 DTIC) , con rango
de Subsecretaría, y dependiente del Ministerio de Hacienda y Función Pública, es el órgano
encargado de impulsar el proceso de racionalización de las tecnologías de la información y
de las comunicaciones en el ámbito de la Administración General del Estado y sus Organismos
Públicos en los términos establecidos en el Real Decreto 769/2017, de 28 de julio, por el que se
desarrolla la estructura orgánica básica del Ministerio de Hacienda y Función Pública y en el
Real Decreto 806/2014, de 19 de septiembre sobre organización e instrumentos operativos de
las TIC en la AGE.
La SGAD mediante El Catálogo de Servicios de Administración Digital difunde los servicios

comunes, infraestructuras y otras soluciones que se ponen a disposición de las
Administraciones Públicas para contribuir a impulsar el desarrollo de la Administración Digital
y mejorar los servicios que se ofrecen a ciudadanos y a empresas, o internamente a los
empleados públicos.
Tanto las Entidades Locales como las Comunidades Autónomas pueden hacer uso de los
servicios comunes que ofrece la SGAD a través de la firma de convenios suscritos por las
distintas administraciones. Esta manera de formalizar el uso de servicios ofertados por la
SGAD, conlleva un esfuerzo tanto del personal de las distintas administraciones, así como del
personal propio de la SGAD, ralentizando el proceso formal por el que se pone a disposición el
servicio ofertado.
Con la entrada en vigor de la Ley 39/2015 y en concreto por la disposición adicional segunda,
el costoso y lento proceso de firma de convenio, será sustituido. Las Comunidades Autónomas
y las Entidades Locales podrán adherirse voluntariamente y a través de medios electrónicos a
las plataformas y registros establecidos al efecto por la Administración General del Estado.
En resolución de la anterior problemática, la SGAD desea implementar una nueva plataforma

online de Adhesiones mediante la cual se realizará el proceso online de firma de Adhesiones
siguiendo la nueva normativa, facilitando y agilizando el proceso de firma de adhesiones,
realizándolo acorde a la nueva ley 39/2015.
Los responsables de los distintos servicios ofertados podrán dar de alta en el aplicativo ofertas
de adhesión, a las que podrán adherirse las distintas administraciones u organismos siempre y
cuando estas ofertas especifiquen que el organismo es susceptible de firmar la adhesión. Estos
responsables, deberán ser notificados en el momento que un organismo se adhiere a las
ofertas que publican. Los responsables podrán definir la duración de la oferta, bien con una
duración determinada o bien sin fecha de fin. La oferta podrá ser cancelada en el momento
que los responsables estimen oportuno, no pudiendo entonces adherirse a la misma ningún
organismo.
Con respecto a la duración de la adhesión, los responsables podrán definir una duración de la
misma en meses o bien dejar la adhesión sin un límite de duración. En el caso de que la
duración sea fijada por los responsables, el sistema deberá cambiar el estado de la misma, en
el momento en el que el plazo se agote, dejando esta de tener validez.
Solo las personas con potestad contrastada (alcaldes, concejales… etc.) podrán firmar el
proceso de adhesión, si bien estas podrán delegar la firma de la misma a otra persona, para
una oferta específica, adjuntando un documento firmado de delegación de firma en la
plataforma. Los documentos firmados de adhesión deberán ser almacenados en el sistema. La
oferta de adhesión tendrá una parte fija en cuanto a campos que deberán rellenar los usuarios
de la oferta, y otra parte variable, que podrá definir el responsable. Las ofertas de adhesión
podrán contener varios documentos que serán subidos a la plataforma por el responsable.
Tras la firma de la adhesión, el Gabinete de la SGAD, deberá entrar en el aplicativo para

verificar los datos aportados por el usuario del servicio y aceptar la firma de la adhesión.
Una firma de adhesión a un servicio puede dar cobertura a varios organismos, dependientes
normalmente del organismo que firma. Existe una tipología de usuarios del aplicativo especial,
la Diputaciones Provinciales. Estas administraciones pueden realizar la firma de una adhesión,
para aquellas entidades locales dependientes de la misma, dando cobertura esta firma a
distintas Entidades Locales, si bien pueden existir Entidades Locales dentro de la provincia, que
no estén cubiertas por la firma.
Una vez terminado el proceso de adhesión el Centro de Atención a Integradores y

Desarrolladores de la SGAD, ha de poder comprobar en el aplicativo, las administraciones que
están cubiertas dentro de la firma de una adhesión. Se prevee que en un futuro, esta consulta
pueda realizarse desde los sistemas propios del Centro de Atención a Integradores y
Desarrolladores.
Los servicios ofertados se ofrecerán en dos modalidades:
- Servicio básico: Gratuito para las administraciones públicas. Las condiciones del
servicio serán las establecidas por el responsable del servicio y el plazo podrá variar
dependiendo del servicio. El plazo de adhesión al servicio podrá variar, siendo fijo o sin
fecha fijada. En algunos casos, el término del plazo del servicio básico puede conllevar
a la imposibilidad de adherirse a este servicio, obligando a que la siguiente adhesión
por parte del usuario del servicio, se realice con la modalidad premium.
- Servicio premium. Servicios que podrán tener un coste asociado para el usuario
dependiendo de varios factores, que deberán recogerse en la firma de la adhesión.
Estos servicios podrán ser de duración limitada o bien sin fecha de fin.
Preguntas:
1. Elabore el diagrama de casos de uso. Identificando los actores involucrados

2. Realice el diagrama de contexto del aplicativo, identificando posibles sistemas
externos y la funcionalidad que aportan en la solución.
3. Enumere los distintos servicios, funcionalidades y herramientas de seguridad que
utilizaría en el aplicativo. Explique las funcionalidades que aportan cada uno.
4. Diseñe diagrama Entidad - Relación de la solución aportada.
5. Realice el Diagrama de Actividad del proceso completo de una firma de Adhesión.
6. Responda razonadamente las siguientes cuestiones:
a. Dado el diagrama Entidad Relación del apartado anterior, realice la query que
ejecutaría sobre el modelo físico del diagrama anterior para obtener el
histórico de adhesiones canceladas de un organismo para un mismo servicio
ofertado.
b. Realice una breve descripción de las tecnologías y herramientas que usaría
para la implementación del sistema.
c. ¿Sería necesario el acceso al aplicativo vía internet? Justifique su respuesta.
Preguntas:
1. Elabore el diagrama de casos de uso. Identificando los actores involucrados.

2. Realice el diagrama de contexto del aplicativo, identificando posibles sistemas
externos y la funcionalidad que aportan en la solución aportada.
Autentica: Servicio que provee los perfiles de usuarios, que permitirá gestionar los distintos
perfiles que acceden al aplicativo y las funcionalidades que pueden realizar dentro del mismo.
@Firma: servicios de validación y firma electrónica multi-PKI @firma, como un servicio de

validación de certificados y firmas electrónicas desacoplado de las aplicaciones. Permitirá que
se pueda validar cualquier documento aportado.
DIR3: El Directorio Común proporciona un Inventario unificado y común a toda la

Administración de las unidades orgánicas / organismos públicos, sus oficinas asociadas y
unidades de gestión económica - presupuestaria, facilitando el mantenimiento distribuido y
corresponsable de la información. Permitirá la gestión de organismos, y las coberturas que dan
las firmas de las Adhesiones.
Cl@ve: Es la plataforma común de identificación y firma electrónica, permitirá la identificación

de los usuarios a la hora de entrar en el aplicativo. Dentro de las distintas tipologías de
identificación que permite clave, se utilizará el certificado electrónico, debido a la integridad
necesaria en los datos.
REC: Registro Electrónico Común de la AGE, se utilizará para registrar aquellos documentos
que aporten los usuarios para realizar las delegaciones de firma en terceros.
Usuario de Adhesiones: Personal de las AAPP que quieren realizar el proceso de adhesión a un
servicio ofertado.
Gabinete SGAD: Responsables de validar y confirmar que las adhesiones firmadas son
correctas.
Responsable del Servicio: Personal de las AAPP que ofertan el servicio al que adherirse y son
responsables del mismo.
Usuario CAID: Personal de ayuda a los integradores y desarrolladores. Deben comprobar antes
de atender las solicitudes relativas a un servicio que existe una Adhesión validada y que el
organismo está cubierto.
3. Enumere los distintos servicios, funcionalidades y herramientas de seguridad o

relacionados que utilizaría en el aplicativo. Explique las funcionalidades que aportan
cada uno.
- Red Sara: El aplicativo estaría desplegado dentro de la red Sara de las AAPP. Por un
lado sería un aplicativo menos expuesto a ataques por no estar expuesto a
internet y debido a los controles de seguridad de la red.
- Uso de protocolo seguro https. El aplicativo web cifrará las comunicaciones
extremo a extremo con un certificado de servidor.
- Cl@ve: Servicio de identificación de usuarios. Mediante el aplicativo Cl@ve se
independiza la gestión de la identificación, no teniendo que responsabilizarse el
aplicativo y la gestión de la misma de este servicio.
- REC. Presentación en el registro, de los documentos que aportan los usuarios.
Queda constancia con validez jurídica de la presentación de los documentos.
- NAS. Utilización de la NAS del ministerio. Aporta backups automáticos de los
archivos correspondientes de cada adhesión.
- @Firma. Utilización del servicio de firma y validación para los documentos
firmados.
- Uso de certificados electrónicos. Tanto para la identificación en el sistema, como
para la firma de documentos.
4. Diseñe diagrama Entidad - Relación de la solución aportada.

5. Realice el Diagrama de Actividad del proceso completo de una firma de Adhesión.
6. Responda razonadamente las siguientes cuestiones:

a. Dado el diagrama Entidad Relación del apartado anterior, realice la query
que ejecutaría sobre el modelo físico del diagrama anterior para obtener el
histórico de adhesiones canceladas de un organismo para un mismo servicio
ofertado.
SELECT A.* FROM ADHESION A, OFERTA_ADHESION O, ADHESION_ESTADO E
WHERE
A.IDOFERTA = O.ID AND O.ID=’IDSOOLOFERTADA’ AND A.IDESTADO =E.ID
AND E.NOMBRE=’CANCELADA’
b. Realice una breve descripción de las tecnologías y herramientas que usaría

para la implementación del sistema.
El desarrollo se podría realizar utilizando el lenguaje de programación PHP 7.1.3, sobre un

servidor web Apache 2. El framework de desarrollo PHP sobre el que se desarrollará el
aplicativo será Symphony 4. Para la realización del desarrollo sería recomendable el IDE
PHPStorm por su integración con symphony. La base de datos utilizada será MySQL 5.7 y como
herramienta de diseño y consulta a la base de datos se utilizará MySQL Workbench.
c. ¿Sería necesario el acceso al aplicativo vía internet? Justifique su respuesta.
La publicación de la solución web en internet no sería necesaria, debido a que la mayoría de

organismos tienen conexión con la Red Sara, el servicio se publicaría en la misma, evitando así
los posibles problemas de seguridad que pudieran ser ocasionados por tal exposición.
Apoyo formativo para la oposición al Cuerpo de Gestión de Sistemas e
Informática de la Administración del Estado
Convocatoria: 2018
Autor: Fernando García Vera
Bloque III: Desarrollo de Sistemas
Supuesto 2: Enunciado
Una vez al año, se publica en el Boletín Oficial del Estado la convocatoria anual de oferta de empleo público. Esta
convocatoria ofrece la participación en varios procesos selectivos, a otros tantos cuerpos de la Administración del
Estado. Tras ella, van publicándose en diferentes fechas el comienzo de cada uno de los procesos, indicando el
número de plazas ofertadas y de ejercicios eliminatorios que tendrán que superar los opositores.
Dado que el número de opositores no deja de aumentar, se ha decidido informatizar los procesos selectivos,
cubriendo desde la información referente a la convocatoria, hasta los resultados de cada uno de los ejercicios
realizados por los opositores.
Cada proceso selectivo comienza cuando se publica en el BOE. A partir de ahí, los opositores tienen un plazo de
15 días naturales, contados a partir del día siguiente a la publicación, para presentar sus solicitudes.
Cada proceso selectivo está asociado al año en que se publica, año en que el opositor debe –como mínimo-
cumplir la mayoría de edad. Se permite a un mismo ciudadano presentarse a tantos procesos selectivos como
considere. Por ello, no se pueden celebrar dos ejercicios de la misma convocatoria el mismo día.
Aquellos opositores que terminen el último ejercicio con una calificación igual o superior a la nota de corte,
habrán aprobado. La nota final será la suma de todas las puntuaciones obtenidas en el conjunto de los ejercicios,
y decidirá la posición en la lista.
Existen varias unidades con diferentes responsabilidades dentro del organismo encargado de realizar los procesos
selectivos, entre ellas:
 Depto. de admisión de solicitudes, encargado de elaborar la lista de admitidos a cada uno de los procesos
 Depto. de selección de tribunales, que se encarga de escoger mediante, un proceso de entrevistas, entre
los funcionarios de la Administración del Estado a aquellos que formarán parte de uno –y sólo uno- de los
tribunales de cada proceso selectivo. En base a ese proceso, mantiene una tabla con los datos personales
básicos de los miembros del tribunal, junto con la convocatoria y proceso para el que han sido
seleccionados.
 Depto. de gestión de procesos selectivos, que establece las condiciones de los ejercicios de cada proceso,
y entre ellos el número de ejercicios, la fecha de realización y la nota de corte para superar cada uno.
 El departamento de personal, que ya cuenta en tablas la información relativa a grupos, cuerpos y
provincias, dato este último requerido en la solicitud con fines estadísticos.
Se solicita:
1) Describir todas las entidades identificadas, normalizadas al menos a 3NF

2) Especificar todas las tablas, claves primarias, foráneas, y las relaciones y su cardinalidad entre todas las tablas
del modelo. Debe incluirse el tipo de dato de cada campo y su longitud, únicamente si se considera relevante
para la resolución. Por citar dos ejemplos, la nota de corte y la calificación obtenida en cada ejercicio deben
ser números reales redondeados al mismo número de decimales.
3) Realizar las consultas en SQL que permitan detectar:
Gestión de Sistemas e Informática. Bloque III. Enunciado Supuesto 2 Pág. 1 de 2
a) Solicitudes presentadas fuera de plazo
b) Solicitudes presentadas que incumplan el requisito de edad.
c) Procesos selectivos con ejercicios que coincidan en la misma fecha.
d) Lista de todos los opositores de Cuenca presentados a procesos selectivos de cuerpos que no pertenezcan
al grupo A1, con indicación descriptiva al menos de provincia y cuerpo al que se han presentado.
e) Recuento de ciudadanos presentados a cada ejercicio de la convocatoria de 2017 para el Cuerpo de
Gestión de Sistemas e Informática, y nota media de todas calificaciones que aprobaron el ejercicio.
f) Lista de todos los primeros ejercicios de cada convocatoria al Cuerpo de Gestión de Sistemas e
Informática (codificado como “GSI”), incluyendo el número de plazas ofertadas, el número de opositores
presentados, y el número de ellos que aprobó o suspendió el primer ejercicio.
g) Miembros de tribunales que en la misma convocatoria en la que son seleccionados hayan presentado
solicitud a algún proceso selectivo.
h) La lista de opositores de la convocatoria de 2018 que han aprobado en algún proceso selectivo,
mostrando primero los opositores con las mayores puntuaciones.
4) Responder a las siguientes cuestiones:
a) En relación a la integridad referencial del modelo, ¿Qué tablas y en qué orden deberían actualizarse en los
siguientes casos de uso?:
i) Inclusión de un nuevo proceso selectivo.
ii) Inclusión de una solicitud a un proceso selectivo, diferenciando si proviene de un ciudadano que ya ha
participado en otro proceso o es su primera solicitud.
b) Se pretende evitar que un funcionario pueda ser miembro, en la misma convocatoria, de más de un
tribunal. Explique razonadamente cuál sería el mecanismo más sencillo a implementar en la base de datos
para prevenir dicha situación.
c) En 2019 se ha decidido dividir la convocatoria anual en varios procesos selectivos para algunos de los
cuerpos, realizando en diferentes fechas cada uno de los ejercicios. Ante este cambio se plantea también,
para reducir la burocracia del proceso, el requisito de que la solicitud a un cuerpo de un opositor sirva
para todos los procesos selectivos del año a dicho cuerpo. Explique razonadamente si el modelo de datos
anterior seguiría siendo válido. En caso de no serlo, incluya en el modelo los cambios necesarios.
Gestión de Sistemas e Informática. Bloque III. Enunciado Supuesto 2 Pág. 2 de 2

Apoyo formativo para la oposición al Cuerpo de Gestión de Sistemas e
Informática de la Administración del Estado
Convocatoria: 2018
Autor: Fernando García Vera
Bloque III: Desarrollo de Sistemas
Supuesto 2: Solución
1. Describir todas las entidades identificadas, normalizadas al menos a 3NF1
Se observan las siguientes entidades, algunas de ellas ya especificadas en el enunciado del supuesto, y otras
deducibles directamente de éste:
 Provincias, tabla proporcionada por personal.

 Grupos, proporcionado por personal, que enumera los distintos grupos de la AGE.
 Cuerpos, también proporcionado por personal, que incluye los cuerpos de la AGE, con indicación de a qué
grupo pertenecen.
 Oposiciones, en la que se detalla cada uno de los procesos selectivos, indicando el año de convocatoria,
fecha de publicación, la oferta de plazas y el número de ejercicios que incluirá.
 Ciudadanos, con los datos personales mínimos para poder presentar una solicitud, como la fecha de
nacimiento, provincia, documento, apellidos y nombre.
 Tribunales, recabando la información de los miembros seleccionados, incluyendo la convocatoria y el
cuerpo del proceso selectivo para el que han sido elegidos como miembros del tribunal.
 Solicitudes, en la que la fecha de solicitud es un dato relevante, para posteriores comprobaciones de
plazos. El requisito de 3NF impide incluir los datos personales en la solicitud, más allá del documento para
la relación con la tabla de ciudadanos.
 Ejercicios, con la información relativa a cada uno de los ejercicios que se van a realizar, como son
convocatoria y cuerpo para el que se opta, la fecha de realización, el número de plazas y la nota de corta,
dato éste que podrá decidirse con posterioridad
 Calificaciones, que une a la asociación entre ejercicio y opositor, la nota obtenida en cada uno de ellos.
El siguiente gráfico muestra la descripción de tablas y campos, con los campos que forman las claves principales y
las relaciones entre tablas:
1
Sobre la tercera forma normal:
La descripción que hace Bill Kent, no exenta de humor, indica que el objetivo de cada atributo no clave en 3NF es
aportar información de “la clave, de toda la clave y de nada más que la clave … con la ayuda de Codd”
2. Especificar todas las tablas, claves primarias, foráneas, y las relaciones y cardinalidad entre todas las tablas del
modelo. Debe incluirse el tipo de dato de cada campo y su longitud, únicamente si se considera relevante para la
resolución.
Gestión de Sistemas e Informática. Bloque III. Solución Supuesto 2 Pág. 1 de 9
Con las siguientes especificaciones sobre alguno de los datos:
 El dato CONVOCATORIA es un valor entero que indica el año de la convocatoria, por ejemplo 2018, 2019,
etc.
 El dato TOTAL_EJERCICIOS indica el número de ejercicios que debe superar el opositor para aprobar el
proceso selectivo
 El dato NUMERO_EJERCICIO es un valor entero que representa el orden en que se realizan los ejercicios
de cada convocatoria.
 Los datos CALIFICACION y NOTA_CORTE son dos valores del conjunto de los reales que indican
respectivamente la puntuación obtenida y necesaria para aprobar cada ejercicio.
 Los datos FECHA_NACIMIENTO, FECHA_BOE y FECHA_SOLICITUD son datos de tipo fecha (aaaa/mm/dd).
 El dato FECHA_REALIZACION es un dato de tipo fecha + hora (aaaa/mm/dd hh:mm:ss)
3. Realizar las consultas en SQL que permitan detectar:

a) Solicitudes presentadas fuera de plazo
Las solicitudes en plazo son aquellas que se presentaron entre el día siguiente a la fecha de publicación en el BOE
y los quince días naturales siguientes. La consulta correspondiente para mostrar las solicitudes fuera de plazo será
entonces la siguiente:
SELECT
ciu.documento,
ciu.nombre,
ciu.apellidos,
sol.convocatoria,
sol.fecha_solicitud,
opo.fecha_boe

FROM
tCiudadanos ciu,
tSolicitudes sol,
tOposiciones opo
WHERE
ciu.documento=sol.documento
and sol.cd_cuerpo=opo.cd_cuerpo
and sol.convocatoria=opo.convocatoria
and not (sol.fecha_solicitud between opo.fecha_boe+1 and opo.fecha_boe+16)
b) Solicitudes presentadas que incumplan el requisito de la edad
El requisito de la mayoría de edad durante el año de convocatoria implica que la fecha de convocatoria menos la
fecha de nacimiento debe ser al menos igual a 18 años.
SELECT
ciu.documento,
ciu.nombre,
ciu.apellidos,
sol.convocatoria,
sol.fecha_solicitud,
opo.fecha_boe,
ciu.fecha_nacimiento
FROM
tCiudadanos AS ciu,
tSolicitudes AS sol,
tOposiciones AS opo
WHERE
ciu.documento=sol.documento
and year(fecha_boe)-year(fecha_nacimiento)>=18
c) Procesos selectivos con ejercicios que coincidan en la misma fecha
Serán aquellos cuya FECHA_REALIZACION coincida. Hay varias formas de resolver este ejercicio. Se ha
seleccionado una que permite ilustrar la forma de realizar un JOIN de una tabla con un subconjunto de la misma
tabla:
SELECT
eje1.fecha_realizacion,
eje2.coinciden,
eje1.convocatoria,
cue.cd_grupo,
cue.ds_cuerpo,
eje1.numero_ejercicio
FROM
tCuerpos cue,
tEjercicios eje1,
(SELECT
eje.fecha_realizacion,
Count(*)Coinciden
FROM tEjercicios
GROUP BY fecha_realizacion
HAVING Count(*)>1)
eje2
WHERE
eje1.fecha_realizacion=eje2.fecha_realizacion
and cue.cd_cuerpo=eje1.cd_cuerpo

ORDER BY
eje1.fecha_realizacion,
cue.cd_grupo,
cue.ds_cuerpo
d) Lista de todos los opositores de Cuenca presentados a procesos selectivos de cuerpos que no pertenezcan al
grupo A1, con indicación descriptiva al menos de provincia y cuerpo al que se han presentado.
Los datos solicitados requieren la relación de varias tablas en la consulta:
SELECT
pro.cd_provincia,
pro.ds_provincia,
cue.cd_grupo,
cue.ds_cuerpo,
opo.convocatoria,
ciu.documento,
ciu.apellidos,
ciu.nombre,
sol.fecha_solicitud
FROM
tProvincias pro,
tCiudadanos ciu,
tSolicitudes sol,
tOposiciones opo,
tCuerpos cue
WHERE
pro.cd_provincia=ciu.cd_provincia
and ciu.documento=sol.documento
and opo.cd_cuerpo=cue.cd_cuerpo
and pro.ds_provincia='CUENCA'
and cue.cd_grupo>'A1'
ORDER BY
pro.cd_provincia,
cue.cd_grupo,
cue.ds_cuerpo,
sol.fecha_solicitud
e) Recuento de ciudadanos presentados a cada ejercicio de la convocatoria de 2017 para el Cuerpo de Gestión de
Sistemas e Informática, y nota media de todas calificaciones que aprobaron el ejercicio
En este caso, lo destacable es la utilización de funciones agregadas en consultas con varias tablas:
SELECT
cue.cd_cuerpo,
cue.ds_cuerpo,
eje.convocatoria,
eje.numero_ejercicio,
eje.nombre_ejercicio,
nota_corte,
count(documento) aprobados,
avg(cal.calificacion) nota_media
FROM
tCalificaciones cal,
tEjercicios eje,
tCuerpos cue
WHERE
cal.cd_cuerpo=eje.cd_cuerpo
and cal.convocatoria=eje.convocatoria
and cal.numero_ejercicio=eje.numero_ejercicio
and eje.cd_cuerpo=cue.cd_cuerpo
and cal.calificacion>=eje.nota_corte
and cue.cd_cuerpo='GSI'
and eje.convocatoria=2017
GROUP BY
cue.cd_cuerpo,
cue.ds_cuerpo,
eje.convocatoria,
nota_corte
ORDER BY
eje.convocatoria,
eje.numero_ejercicio
f) Lista de todos los primeros ejercicios de cada convocatoria al Cuerpo de Gestión de Sistemas e Informática
(codificado como “GSI”), incluyendo en cada fila el número de plazas ofertadas, el número de opositores
presentados, y el número de ellos que aprobó o suspendió el primer ejercicio
En este caso, se pone de relieve la capacidad de condicionar las funciones agregadas al comportamiento de otros
valores. Se utiliza la función IIF, equivalente a CASE WHEN, IF … THEN …, NVL y similares.
Si se buscara la máxima simplicidad de la query, se podrían suprimir alguno de los campos en la cláusula SELECT y
en consecuencia en la WHERE, por ejemplo el nº de ejercicio, dado que ya se filtra en la cláusula WHERE, sin
embargo, se mantiene por claridad en la lista de resultados:
SELECT
cue.cd_cuerpo,
cue.ds_cuerpo,
opo.convocatoria,
opo.plazas_oferta,
count(cal.documento) presentados,
sum(iif(cal.calificacion<eje.nota_corte,1,0)) suspendidos,
sum(iif(cal.calificacion>=eje.nota_corte,1,0)) aprobados
FROM
tCuerpos cue,
tOposiciones opo,
tSolicitudes sol,
tEjercicios eje,
tCalificaciones cal
WHERE
cue.cd_cuerpo=opo.cd_cuerpo
and opo.cd_cuerpo=sol.cd_cuerpo
and opo.convocatoria=sol.convocatoria
and opo.cd_cuerpo=eje.cd_cuerpo
and opo.convocatoria=eje.convocatoria
and sol.documento=cal.documento
and sol.cd_cuerpo=cal.cd_cuerpo
and sol.convocatoria=cal.convocatoria
and cue.cd_cuerpo='GSI'
and eje.numero_ejercicio=1

GROUP BY
cue.cd_cuerpo,
cue.ds_cuerpo,
opo.convocatoria,
opo.plazas_oferta,
eje.nombre_ejercicio;
g) Miembros de tribunales que en la misma convocatoria que son seleccionados hayan presentado solicitud a algún
proceso selectivo
En este caso, la opción de un INNER JOIN es sin duda la más óptima, permitiéndonos detallar a qué pruebas está
optando un miembro del tribunal:
SELECT
tri.documento,
tri.APELLIDOS,
tri.NOMBRE,
TRI.CONVOCATORIA,
sol.cd_cuerpo,
cue.ds_cuerpo,
cue.cd_grupo
FROM
tTribunales tri,
tsolicitudes sol,
tCuerpos cue
WHERE
sol.documento=tri.documento
and sol.convocatoria=tri.convocatoria
and cue.cd_cuerpo=sol.cd_cuerpo
h) La lista de opositores de la convocatoria de 2018 que han aprobado en algún proceso selectivo, mostrando
primero los opositores con las mayores puntuaciones.
En esta consulta haremos un JOIN de cinco tablas, para obtener también los nombres de los cuerpos en los que se
han producido aprobados:
SELECT
cue.cd_cuerpo,
cue.ds_cuerpo,
opo.convocatoria,
opo.plazas_oferta,
opo.total_ejercicios,
sol.documento,
Count(cal.numero_ejercicio) Ejercicios_Realizados,
sum(cal.calificacion) Puntuacion_Total
FROM
tOposiciones opo,
tSolicitudes sol,
tEjercicios eje,
tCalificaciones cal,
tCuerpos cue
WHERE
sol.cd_cuerpo=cue.cd_cuerpo and
sol.cd_cuerpo=opo.cd_Cuerpo
And sol.convocatoria=opo.convocatoria
And cal.documento=sol.documento
And eje.cd_cuerpo=sol.cd_cuerpo
And eje.convocatoria=sol.convocatoria
And cal.cd_cuerpo=eje.cd_cuerpo
And cal.convocatoria=eje.convocatoria
And cal.numero_ejercicio=eje.numero_ejercicio
And cal.calificacion>=eje.nota_corte
GROUP BY
opo.cd_cuerpo,
cue.ds_cuerpo,
opo.convocatoria,
opo.plazas_oferta,
opo.total_ejercicios,
sol.documento
HAVING
opo.total_ejercicios=Count(cal.numero_ejercicio)
ORDER BY
opo.convocatoria,
opo.cd_cuerpo,
sum(cal.calificacion) DESC
4. Responder a las siguientes cuestiones:

a) Con especial atención a la integridad referencial del modelo, ¿Qué tablas y en qué orden deberían actualizarse
en los siguientes casos de uso?:
Cuando existen dos tablas A y B, con una relación A – (1:N) -> B, en la que para cada elemento de A pueden existir
entre ninguno y varios en la tabla B, no está permitido que existan elementos en sin su correspondiente en A.
i) Inclusión de un nuevo proceso selectivo

Para la inclusión de un nuevo proceso selectivo, y una vez confirmado que el cuerpo para el que se realiza ya está
dado de alta en la tabla tCuerpos, habría que incluir en primer lugar los datos principales en la tabla tOposiciones.
No se ha incluido ninguna restricción de obligatoriedad en los campos FECHA_BOE, PLAZAS_OFERTA,
TOTAL_EJERCICIOS, así que, por ilustrar una solución alternativa a la inmediata tOposiciones -> tEjercicios, se
propone este orden:
 tOposiciones: CD_CUERPO, CONVOCATORIA, y TOTAL_EJERCICIOS. Y a la espera de que se publique en el

BOE,
 tEjercicios: CD_CUERPO, CONVOCATORIA, NUMERO_EJERCICIO, NOMBRE_EJERCICIO, y tras publicarse en
el BOE la convocatoria,
 tOposiciones: FECHA_BOE, PLAZAS_OFERTA
Los campos FECHA_REALIZACION y NOTA_CORTE de tEjercicios se grabarán cuando se notifique y se corrija

respectivamente cada ejercicio.
ii) Inclusión de una solicitud a un proceso selectivo, diferenciando si proviene de un ciudadano que ya ha
participado en otro proceso o es su primera solicitud
En este caso, la presentación de la solicitud debe generar la siguiente secuencia:
 Comprobar si el ciudadano ya existe en la tabla tCiudadanos y en caso contrario darle de alta en dicha
tabla.
 A continuación se dará de alta en tSolicitudes.

b) Se pretende evitar que un funcionario pueda miembro, en la misma convocatoria, de más de un tribunal.
Explique razonadamente cuál sería el mecanismo más sencillo a implementar en la base de datos para prevenir
dicha situación.
De hecho, existen varias posibilidades que se podrían implementar para detectar o evitar el caso requerido:
 Se podría programar un trigger que, antes de realizar el alta de un miembro del tribunal, comprobara si ya
existe en esa misma convocatoria, y propusiera la sustitución de una membresía por otra
 Se podría programar otro trigger que, después de realizar el alta de un miembro de un tribunal,
comprobara si ya es miembro de otro en la misma convocatoria y avisara, borrara o tomara la acción más
conveniente sobre una de las membresías
 La grabación y consulta de datos son procesos concurrentes, por lo que se debe programar un job que,
periódicamente, ejecute una consulta que acumule el número de tribunales por convocatoria de cada
miembro y envíe una alerta al responsable
 Otro enfoque sería el de modificar las restricciones de la tabla tTribunales, conviertiendo el código de
cuerpo CD_CUERPO en nada más que una clave foránea. Pasando a estar compuesta únicamente por el
documento de identidad y la convocatoria, la propia integridad de la base de datos evitaría la pertenencia
de un funcionario a dos tribunales en la misma convocatoria.
Lo importante del enunciado es que se pide prevenir la situación, en lugar de detectarla una vez ocurrida.
Por ello, la tercera opción queda descartada, y la segunda estaría también en entredicho.
De las dos formas de abordar el problema, para más sencillo y elegante, a falta de requisitos que lo impidan,
utilizar la última opción, modificando la clave primaria de la tabla tTribunales, y convirtiendo el código de cuerpo
en clave foránea de la tabla de cuerpos.
c) En 2019 se pretende dividir la convocatoria anual en varios procesos selectivos para algunos de los cuerpos,
realizando en diferentes fechas cada uno de los ejercicios. Ante este cambio se plantea también, para reducir la
burocracia del proceso, el requisito de que la solicitud a un cuerpo de un opositor sirva para todos los procesos
selectivos del año a dicho cuerpo. Explique razonadamente si el modelo de datos anterior seguiría siendo válido. En
caso de no serlo, incluya en el modelo los cambios necesarios.
El problema se presenta por uno de los datos que forman parte de buena parte de las tablas del modelo. La
CONVOCATORIA es un dato entero que representa el año. La clave primaria formada por CD_CUERPO y
CONVOCATORIA no permite diferenciar varios procesos al mismo cuerpo en el mismo año. Así, por ejemplo, no se
podría diferenciar a cuál de los procesos de una convocatoria se refiere un determinado ejercicio y todas las
calificaciones obtenidas por los opositores.
Por tanto, con las tablas y relaciones proporcionadas, el modelo no cumpliría con el nuevo requisito.
Existen varias soluciones para cumplir con él. Describimos alguna de ellas a continuación:
 Podríamos modificar el tipo de dato CONVOCATORIA en todas las tablas en que aparece, convirtiéndolo
en un dato de tipo cadena, forzando a incluir el año, un separador y un número de secuencia, con
formato aaaa/pp, donde pp es el número correlativo que indica a qué proceso selectivo se refiere
 También sería factible añadir el dato PROCESO_SELECTIVO, de tipo entero a las tablas tOposiciones,
tEjercicios y tCalificaciones, e incluirlo en las relaciones (1:n) entre ellas. Este dato indicará el número de
proceso selectivo dentro del año.
 La solución más elegante, aunque quizá la más costosa, pasa por crear una nueva tabla
tProcesosSelectivos, añadiendo a CONVOCATORIA y CD_CUERPO el número de proceso y otros datos
asociados, sustituyendo la relación
tOposiciones –(1:n) -> tEjercicios
por
tOposiciones –(1:n)-> tProcesosSelectivos
Y añadiendo una nueva relación
tProcesosSelectivos –(1:n)-> tEjercicios
Esta solución, considerando que existirán datos adicionales asociados únicamente a cada uno de los
procesos selectivos, es la única que mantendría la 3NF. A cambio, sigue implicando la inclusión del
CD_PROCESO_SELECTIVO en las tablas tEjercicios y tCalificaciones

Supuesto:
Facturación de Material de oficina
Marzo 2018
Marta Lara Boto
Bloque III - Supuesto 3
Enunciado
Usted, como parte de la subdirección de informática y tecnologías de la información de uno de

los departamentos ministeriales de la AGE, debe analizar y desarrollar un sistema que permita
controlar la facturación de material de oficina que realizan las empresas al ministerio en todo el
ámbito nacional.
Una vez reunido con el departamento de Oficialía, la situación de partida es la siguiente:
- En la actualidad, existen 3 empresas que suministran material de oficina, aunque el

número puede aumentar o disminuir.
- Las empresas sirven material según un catálogo previamente pactado con la AGE y a
precios fijos y determinados previamente.
- Las empresas sirven a aproximadamente unas 40 subdirecciones diferentes (en adelante
llamadas unidades consumidoras)
- Se han encontrando ciertos problemas en lo relacionado a la cantidad de material
facturado y sus precios. En ocasiones los pedidos llegan con menos unidades de las
solicitadas, aunque la facturación final se realiza por el total. Además, los precios finales
no atienden a lo indicando en el acuerdo inicial.
- Dados los problemas encontrados, antes de ser emitidas a FACE, las empresas envían
las facturas a Oficialía en formato electrónico para que puedan ser revisadas.
- El control de las facturas se realiza manualmente a modo de muestreo. Es muy
complicado realizar un cuadre y punteo de las facturas electrónicas.
- Cuando se detecta un error, se avisa a la empresa en cuestión del problema, con el
objeto de que la empresa genere una nueva versión de factura. Esto conlleva el
consiguiente retraso en el pago.
- Si no se detecta error, las empresas remiten la información a FACE, siguiendo el
esquema de factura electrónica y el canal habitual. Oficialía emite un certificado que
se adjunta al trámite de la factura indicando que la factura puede ser pagada. En la
actualidad este certificado es un documento en papel que se firma manualmente.
- La solicitud de material a las empresas se realiza ahora mismo en formato papel,
rellenando una serie de documentos modelo que se remiten por correo electrónico.
Los requisitos, una vez analizados, quedan establecidos de esta manera:
- El sistema debe permitir gestionar el flujo completo, desde la realización del pedido
hasta su certificación.
- El sistema permitirá el acceso seguro a cada actor, quien tendrá acceso únicamente a la
parte que le corresponda según su función.
- Toda la información que actualmente se maneja en papel, debe transformarse a
formato electrónico.
- Las facturas y pedidos se almacenarán en el sistema según sean remitidos por la
empresa.
- El sistema debe proporcionar una manera en la que se pueda validar que lo solicitado
corresponde a la facturado, en cantidad y en precio de una manera sencilla.
- Aquellas facturas que tengan el visto bueno, podrán ser facturadas de acuerdo a la
normativa vigente.
- El sistema debe proporcionar unos informes que permitan controlar la facturación
mensual, para realizar un seguimiento del presupuesto y los informes necesarios para
optimizar el gasto en futuros acuerdos.
- A fin de realizar el proceso de la manera más transparente posible, se debe permitir a
las empresas acceder al sistema de información para que revisen el estado de sus
facturas.
- El objetivo final es disminuir el número de incidencias relacionadas con la facturación,
el volumen de facturas incorrectas en FACE/RCF y reducir los plazos en la tramitación de
facturas.
Para llevar a cabo este proyecto, debe realizar un análisis previo que contemple:
1. Descripción del sistema. Esquema general de la solución.

2. Matriz DAFO.
3. Diagrama de contexto.
4. Diagrama de subsistemas.
5. Modelo entidad/relación.
6. Diagrama de estados de pedidos y de facturas
En todo lo no contemplado en este supuesto, el opositor podrá efectuar las suposiciones que
considere conveniente, debiendo siempre hacerlas constar en su propuesta de solución
acompañadas de su correspondiente justificación.
Supuesto:
Facturación de Material de oficina
Marzo 2018
Marta Lara Boto
Bloque III - Supuesto 3
Enunciado
Usted, como parte de la subdirección de informática y tecnologías de la información de uno de

los departamentos ministeriales de la AGE, debe analizar y desarrollar un sistema que permita
controlar la facturación de material de oficina que realizan las empresas al ministerio en todo el
ámbito nacional.
Una vez reunido con el departamento de Oficialía, la situación de partida es la siguiente:
- En la actualidad, existen 3 empresas que suministran material de oficina, aunque el

número puede aumentar o disminuir.
- Las empresas sirven material según un catálogo previamente pactado con la AGE y a
precios fijos y determinados previamente.
- Las empresas sirven a aproximadamente unas 40 subdirecciones diferentes (en adelante
llamadas unidades consumidoras)
- Se han encontrando ciertos problemas en lo relacionado a la cantidad de material
facturado y sus precios. En ocasiones los pedidos llegan con menos unidades de las
solicitadas, aunque la facturación final se realiza por el total. Además, los precios finales
no atienden a lo indicando en el acuerdo inicial.
- Dados los problemas encontrados, antes de ser emitidas a FACE, las empresas envían
las facturas a Oficialía en formato electrónico para que puedan ser revisadas.
- El control de las facturas se realiza manualmente a modo de muestreo. Es muy
complicado realizar un cuadre y punteo de las facturas electrónicas.
- Cuando se detecta un error, se avisa a la empresa en cuestión del problema, con el
objeto de que la empresa genere una nueva versión de factura. Esto conlleva el
consiguiente retraso en el pago.
- Si no se detecta error, las empresas remiten la información a FACE, siguiendo el
esquema de factura electrónica y el canal habitual. Oficialía emite un certificado que
se adjunta al trámite de la factura indicando que la factura puede ser pagada. En la
actualidad este certificado es un documento en papel que se firma manualmente.
- La solicitud de material a las empresas se realiza ahora mismo en formato papel,
rellenando una serie de documentos modelo que se remiten por correo electrónico.
Los requisitos, una vez analizados, quedan establecidos de esta manera:
1
- El sistema debe permitir gestionar el flujo completo, desde la realización del pedido
hasta su certificación.
- El sistema permitirá el acceso seguro a cada actor, quien tendrá acceso únicamente a la
parte que le corresponda según su función.
- Toda la información que actualmente se maneja en papel, debe transformarse a
formato electrónico.
- Las facturas y pedidos se almacenarán en el sistema según sean remitidos por la
empresa.
- El sistema debe proporcionar una manera en la que se pueda validar que lo solicitado
corresponde a la facturado, en cantidad y en precio de una manera sencilla.
- Aquellas facturas que tengan el visto bueno, podrán ser facturadas de acuerdo a la
normativa vigente.
- El sistema debe proporcionar unos informes que permitan controlar la facturación
mensual, para realizar un seguimiento del presupuesto y los informes necesarios para
optimizar el gasto en futuros acuerdos.
- A fin de realizar el proceso de la manera más transparente posible, se debe permitir a
las empresas acceder al sistema de información para que revisen el estado de sus
facturas.
- El objetivo final es disminuir el número de incidencias relacionadas con la facturación,
el volumen de facturas incorrectas en FACE/RCF y reducir los plazos en la tramitación de
facturas.
Para llevar a cabo este proyecto, debe realizar un análisis previo que contemple:
1. Descripción del sistema. Esquema general de la solución.

2. Matriz DAFO.
3. Diagrama de contexto.
4. Diagrama de subsistemas.
5. Modelo entidad/relación.
6. Diagrama de estados de pedidos y de facturas
En todo lo no contemplado en este supuesto, el opositor podrá efectuar las suposiciones que
considere conveniente, debiendo siempre hacerlas constar en su propuesta de solución
acompañadas de su correspondiente justificación.
2
Solución propuesta
1. Descripción general del sistema

El sistema se ha bautizado como FaMo (Control de facturación de material de oficina).
Se han identificado cuatro actores principales:

- Empresas, que reciben los pedidos, envían las facturas y acceden a consultar el estado
de las mismas.
- Responsables FaMo, que introducen en el sistema el catálogo de productos de las
empresas y realizan otras labores de configuración y administración de la aplicación.
- Usuarios consumidores, que realizan los pedidos y validan las facturas enviadas por las
empresas.
- FACE/RCF, al que accede FaMO para consultar las facturas enviadas por las empresas
por el canal habitual y su estado final.
Se plantea el desarrollo de un proyecto web compuesto principalmente de dos aplicaciones

web:
- Una alojada en la granja de servidores web de la red interna, a la que accederán los
usuarios consumidores y responsables FaMo y desde la cual se accederá a FaCE/RCF a
través de la red SARA.
- Una alojada en la granja de servidores web de la DMZ, a la que accederán las empresas
para consultar sus pedidos, enviar los datos de facturación y consultar su estado.
El motivo de alojar la aplicación fuera de la red interna es que no se prevé que las
empresas estén conectadas a la red SARA. Si fuera así, por ejemplo, proporcionando una
conexión VPN, toda la aplicación podría alojarse en la red interna.
Otro posible escenario sería alojar una única aplicación web en la red DMZ, pero al
tener que conectarse con FACE/RCF a través de la red SARA, habría que habilitar
conexiones DMZ-RED SARA.
La aplicación externa será accedida, por tanto, desde Internet, previa autenticación de
las empresas con certificado electrónico. Será requisito que este certificado sea
reconocido por @Firma. Ambas aplicaciones contarán con las medidas de seguridad
oportunas, sin perder de vista que una aplicación en la DMZ puede estar más expuesta
a amenazas.
En cualquier caso, la base de datos siempre se alojará en la red interna.
Cabe la posibilidad de que la aplicación externa sea una aplicación móvil que las
empresas puedan instalarse en sus dispositivos móviles. Podría establecerse un sistema
de notificaciones que permitiera hacer un push de las actualizaciones en pedidos y
facturación desde FaMo.
3
En cuanto al funcionamiento genera, para la remisión de las facturas por parte de las
facturas, se prevén dos métodos:
- el despliegue de los servicios web oportunos, para aquellas empresas cuyo nivel
tecnológico permita utilizar este canal.
- la creación de un método en la aplicación externa que permita subir las facturas
electrónicas directamente, previa conexión segura al sistema.
Una vez validadas las facturas, las empresas tendrán la seguridad de que el contenido de las
mismas cuenta el visto bueno de las unidades consumidoras y podrán remitirlas a FACE para
su posterior pago. Este envío se realiza de manera externa al sistema. El motivo de
plantearlo así es que nos e cuenta con la seguridad legal de que un ministerio pueda enviar
las facturas a FACE en nombre de una empresa. Además, la responsabilidad final de este
envío debería recaer en la propia empresa. Desde luego, no se puede perder de vista que,
desde un punto de vista técnico, se podría contemplar un envío automático de las facturas
validadas desde FaMo a FACE/RCF, siendo este mecanismo más eficiente que el planteado
en la solución.
Ilustración 1. Diagrama general
4
2. Matriz DAFO
La matriz DAFO permite hacer un análisis de la realidad y facilitar la toma de decisiones en

caso necesario.
Obedece a cuatro ejes fundamentales que responden a los factores externos e internos a la
organización, y a lo positivo y negativo que se produce en el ámbito del proyecto. En función
de estos cuatro ejes se organiza la matriz:
Fortalezas: atributos propios del proyecto de carácter positivo.
Oportunidades: factores externos atractivos y positivos para el proyecto.
Amenazas: factores externos, más allá del control del proyecto, y que pueden poner en riesgo
la consecución de los objetivos propuestos.
Debilidades: rasgos que, aunque están bajo el control del proyecto, limitan su capacidad para
alcanzar los objetivos deseados.
Factores internos
Debilidades Fortalezas
Complejidad a la hora de determinar la Transparencia del proceso
responsabilidad en la validación de Optimización del gasto futuro
facturas (obtención de información para
Imposición del sistema a las unidades negociaciones futuras y posibles
Puede percibirse como una medida de previsiones)
Factores negativos
Factores positivos
control Puede generar ahorros reales
Reducirá el tráfico de facturas
incorrectas en FACE
Amenazas Oportunidades
Bajo interés de las empresas por Aplicación de modelos a otros tipos de
participar en el sistema. contratos
Fracaso total si no se utiliza el sistema Incentivo para la optimización del
por empresas y unidades consumidoras gasto
Disponibilidad de un modo de consulta Toma de conciencia del buen uso del
automático a RCF/FACE material
En línea con la política de ahorro de la
AGE
Factores externos
5
3. Diagrama de contexto
Ilustración 2. Diagrama de contexto
Los responsables introducirán en el sistema los datos relativos al catálogo de productos,

incluyendo los precios acordados. También se encargarán de realizar otras tareas de gestión
comunes, como la gestión de usuarios de las unidades consumidoras o de administración, como
la introducción y mantenimiento de empresas, etc. No se han introducido en el diagrama por
mantener la claridad del mismo y centrar la atención en la funcionalidad principal.
Las unidades consumidoras rellenarán en FaMo los pedidos sobre un formulario que mostrará
el catálogo de productos definido y disponible en cada momento.
Las empresas consultarán los pedidos, y los servirán en el modo habitual.
Con la periodicidad que sea necesaria, las empresas enviarán los datos de facturación en
formato electrónico. El sistema procesará y cargará esta información. Deberán realizarse unas
comprobaciones automáticas que aseguren que los datos facturados corresponden al catálogo
acordado (no hay productos fuera de catálogo, todos los precios corresponden al catálogo, etc).
Con esto se evitaría que, aunque el pedido se haya realizado sobre el catálogo, puedan surgir
discrepancias a la hora de facturar.
Las facturas comprobadas por el sistema, se ponen a disposición de las unidades consumidoras
para su validación quienes podrán revisar que, efectivamente el pedido ha sido servido en
tiempo y forma y puede ser pagado.
En caso de discrepancia, la unidad consumidora la marcará como rechazada, indicando el motivo

del rechazo (no ha llegado el pedido, no me han servido las unidades solicitadas, la calidad no
atiende a lo acordado, etc). La empresa deberá corregir y remitir de nuevo la información de
facturación al sistema.
Cuando la unidad consumidora está de acuerdo con la facturación, aprobará la factura.
6
Una vez aprobada la factura, los responsables FaMo deberán emitir el certificado de
conformidad de la misma firmada electrónicamente. Este certificado se remitirá, si es necesario,
a la unidad pagadora correspondiente. En principio se plantea realizar este envío via email,
externo al sistema, aunque si un análisis posterior encuentra un método más eficiente se
plantearía dentro del proyecto.
Una vez esté emitido el certificado, la empresa puede remitir esa factura a FACE. Para ello
seguirá el proceso de facturación habitual (más información en https://face.gob.es/es)
El sistema contará con una conexión a FACE/RCF para comprobar que la factura que finalmente
las empresas envían a FACE, corresponde con la validada por gestores del sistema. Con esto se
evitaría que la empresa manipulara la factura una vez ha sido certificada, antes de enviarla a
FACE/RCF.
4. Diagrama de subsistemas
Ilustración 3. Diagrama de subsistemas
En el diagrama se han obviado los subsistemas de uso general, como gestión de usuarios, gestión
de perfiles y permisos, gestión de tablas maestras, para no sobrecargar el esquema y mejorar la
claridad del mismo. En cualquier caso, existen dentro del ámbito de la AGE implementaciones
para estos sistemas comunes de uso horizontal, que permiten ser reutilizados. En el proyecto se
valorará esta posibilidad y en la medida de lo posible, se tenderá a su integración en FaMO.
Se han identificado los siguientes subsistemas:
1. S1. Gestión de catálogos:

a. Permitirá a los responsables introducir el catálogo de productos de las
empresas.
b. Alimentará al sistema de gestión de pedidos para obtener los productos
disponibles.
2. S2. Gestión de pedidos:
a. Permitirá a las unidades consumidoras redactar los pedidos sobre el catálogo
de productos acordado con las empresas. Los pedidos se almacenarán en
formato electrónico y además se generará un PDF que será remitido por correo
electrónico a la empresa para agilizar los trámites.
7
b. Permitirá a las empresas acceder a la información de pedidos para su consulta
y actualización del estado, si así se decide.
3. S3. Almacenamiento de facturación: permitirá a las empresas enviar los datos de
facturación (de dos maneras, como se ha comentado, vía servicio web, vía formulario).
Esta información se procesará, extraerá y almacenará en la base de datos. En cualquier
caso, la información electrónica enviada por la empresa (XML) será siempre almacenado
en bruto para posteriores consultas y asegurar la trazabilidad.
4. S4. Comprobación automática: procesado automático de los datos de facturación
enviados y procesados para comprobar la adecuación al catálogo. Este sistema se
alimenta de la información generada en el subsistema Almacenamiento de facturación
de la información gestionada en el subsistema Gestión de catálogos.
5. S5. Validación (aprobación y rechazo):
a. Permitirá a las unidades consumidoras revisar las facturas procesadas en el
subsistema Comprobación automática, y proceder a su aprobación o rechazo.
6. S6. Emisión de certificado:
a. Permitirá a los responsables emitir el certificado de aquellas facturas que hayan
sido aprobadas en el subsistema Validación.
b. Aquellas facturas para las que se haya emitido certificado, serán enviadas
posteriormente a FACE/RCF por las empresas. Existirá una conexión automática
que periódicamente lea las facturas en FACE/RCF (XML) y compruebe
previamente a la emisión del certificado, que los totales de la certificada y la
enviada a FACE/RCF son los mismos. En caso contrario, se creará una alerta para
responsables y empresas para que realicen las acciones oportunas.
7. S7. Consulta de facturas
a. Permitirá a las empresas consultar las facturas, con detalle del estado en el que
se encuentran. Este subsistema se alimentará de la información generada en
otros tres, el de Validación (para obtener el estado de validación de las facturas,
es decir, si han sido aprobadas o rechazadas o la unidad consumidora no las ha
validado por el momento), el de Emisión de certificados (para obtener si el
responsable FaMo ha emitido el certificado), y el acceso a FACE/RCF para poder
obtener el estado en este sistema externo.
b. En cualquier caso, nunca una empresa accederá a la funcionalidad de
modificación, solo a lectura.
En el diagrama no se pintan, por mantener la limpieza del mismo dos subsistemas:
8. S8. Gestión de informes: permitirá a todos los actores disponer de los informes
necesarios, según se defina en el momento del análisis.
9. S9. Gestión de Avisos: permitirá a todos los actores configurar la recepción de alertas a
través de correo electrónico. Por ejemplo, en lo relativo a empresas, rechazos de
facturas o certificación de las mismas. En caso de unidades consumidoras o
responsables, la llegada de nuevas facturas.
Aquellos sistemas horizontales ya implementado y disponibles para su integración, susceptibles

de ser reutilizados en el proyecto (sistemas de autenticación, autorización, gestión de usuarios)
8
5. Modelo entidad/relación
Ilustración 4 Modelo entidad relación
Los usuarios son UsuariosEmpresas, Responsables o UnidadesConsumidoras atendiendo a los 3

perfiles de la aplicación.
Las Empresas tienen catálogos, que contienen productos. Esos catálogos son introducidos por
los Responsables.
Las Unidades consumidoras redactan pedidos seleccionando productos de los catálogos.
Las Empresas generan facturas, que contienen líneas. Las líneas de la factura deben
corresponden a productos del catálogo.
Las UnidadesConsumidoras validan las facturas. Cabe la posibilidad de establecer esta relación
de modo que las UnidadesConsumidoras validen LineasFactura, de modo que el detalle
obtenido sea mayor. Por el momento, se decide dejar la primera relación.
Los Responsables generan certificados, que corresponden a facturas. Cabe la posibilidad de

que Certificados sea un atributo más de Facturas, ya que en principio, una factura solo puede
tener un certificado. Por el momento se decide separar estas entidades para que el modelo
sea más flexible.
9
6. Diagrama de estados
El diagrama de estados de pedido es el siguiente:
Ilustración 5 Estados pedido
Cuando la unidad consumidora redacta el pedido, rellenando el formulario que muestra el

catálogo de productos, grabará el mismo en el sistema. Posteriormente se solicita a la
empresa, lo que genera el envío de un mail y un cambio de estado del pedido. La empresa lo
recibirá, y cambiará el pedido a en proceso. Cabe la posibilidad de añadir un estado posterior
que sea enviado/en camino, aunque la integración por parte de las empresas de estos estados
(en proceso y en camino) probablemente complique el proceso. Cuando el pedido llegue a la
unidad, la unidad consumidora lo modificará a estado Recibido.
El diagrama de estados de factura es el siguiente:
Ilustración 6 Estados factura
Cuando la empresa envía la factura, se asigna el estado Enviada. Queda por determinar si es
posible y merece la pena hacer el procesamiento en ese mismo momento o sería preferible
programar un proceso nocturno. En cualquier caso, debe extraerse la información de la factura
electrónica para almacenar la información en el sistema. En ese momento la factura pasa a
estar Procesada. Posteriormente se procesarán las comprobaciones necesarias de manera
automática, y la factura pasa a estar Comprobada (las comprobaciones automáticas han sido
satisfactorias) o Errónea (se ha encontrado algún problema en la factura). En el primer caso,
las unidades consumidoras pasarán a realizar el trabajo su validación, aprobando (estado
Aprobada) o rechazando (estado Rechazada). En el segundo caso, la empresa debe volver a
enviar la factura, por lo que volverá al inicio del diagrama. En caso de que sea Aprobada, serán
los responsables FaMo quienes emitan el certificado de la factura. En caso de Rechazo, se
volverá al inicio del diagrama.
10
Ya que la conexión con FACE/RCF permite saber el estado en este sistema externo, puede ser
interesante obtener el estado de la factura FACE/RCF y almacenarlo en campo independiente
“Estado FACE/RCF” para tener la visión paralela en ambos sistemas.
11
Curso Apoyo a la Promoción Acceso al
Cuerpo de Gestión de Sistemas e
Informática
Supuesto Práctico: SISTEMA PARA LA GESTIÓN

PRESUPUESTARIA Y CONTRACTUAL DEL
SECTOR PÚBLICO
Autor: Israel Barroso Pérez
Marzo de 2018
pág. 1
SISTEMA PARA LA GESTIÓN PRESUPUESTARIA Y CONTRACTUAL
DEL SECTOR PÚBLICO
Aprobados los Presupuestos Generales del Estado (PGE) para un determinado ejercicio
económico, corresponde al Gobierno la ejecución del presupuesto aprobado. Según establece
la Ley General Presupuestaria, la gestión del presupuesto de gastos del Estado y de sus
Organismos Autónomos se realiza en las siguientes fases:
- Aprobación del gasto (Documento contable RC y Documento contable A).
o Documento “RC”, de retención de crédito. Se utilizan para que el órgano gestor

pueda bloquear un crédito para su destino a un fin concreto y evitar así que
pueda ser empleado en otra finalidad.
o Documento “A” de autorización de gasto. Aprobado un expediente de gasto, el

servicio proponente formulará un documento "A" por su importe con cargo a la
correspondiente anualidad, enviándolo a la Oficina de Contabilidad para su
registro contable.
- Compromiso de gasto o disposición (Documento contable D).
o Documento “D” de disposición o compromiso de gasto. Se expedirán por el

servicio competente y se remitirán a la Oficina de Contabilidad una vez
comprometido el gasto con un tercero.
- Reconocimiento de la obligación (Documento contable OK).

- Ordenación del pago.
- Pago material.
La gestión de los trámites y documentos asociados a la ejecución presupuestaria estarán

recogidos en un expediente de gasto, y serán tramitadas por un Órgano Gestor.
Un Órgano Gestor hace referencia a un centro directivo, delegación, subdelegación

territorial u organismo de la Administración General del Estado, Comunidad Autónoma o
Entidad Local a que corresponda la competencia sobre la aprobación del expediente de gasto.
Los Órganos Gestores se dividen a su vez en Unidades Tramitadoras, esto es, órganos
administrativos al que les corresponde la tramitación de los expedientes de gasto, sin perjuicio
de a quien competa su aprobación.
Por otro lado, un organismo está compuesto por Órganos de Contratación, encargado de
elaborar documentación administrativa en relación a la contratación. El Órgano de Contratación
es el órgano unipersonal o colegiado que, en virtud de norma legal o reglamentaria o disposición
estatutaria, tenga atribuida la facultad de celebrar contratos en nombre de los poderes
adjudicadores y demás entes, organismos y entidades del sector público.
Por tanto, un organismo estará compuesto por Órganos de Contratación y Órganos Gestores
(divididos a su vez en Unidades Tramitadoras).
pág. 2
Descripción del procedimiento
Con carácter previo, el Órgano Gestor inicia el Expediente, cursando la correspondiente

Retención de crédito para así disponer del Certificado de retención del crédito.
El expediente ha de estar integrado por un conjunto de documentos inicialmente, unos

troncales y otros variables en función de la tipología del mismo, que, sin ser exhaustivos,
podemos concretar, en los siguientes documentos administrativos:
- Memoria/Declaración de la necesidad e idoneidad.

- Pliego de prescripciones técnicas particulares
- Pliego de cláusulas administrativas particulares
o Redactado por el Órgano de Contratación, además de especificar con precisión
el tipo de contrato que va a regular (Obras, servicios, suministros, etc) y su
cobertura financiera (documento contable RC del Órgano Gestor).
o Debe estar creado por el Órgano de Contratación con anterioridad a la
aprobación del gasto (documento contable A).
- Certificado de existencia y retención de crédito (RC)
o Entregado por el Órgano Gestor
Así pues, una vez iniciado el expediente, el Órgano Gestor deberá formular la
correspondiente “Propuesta de gasto” (documento administrativo). La fiscalización de la
“Propuesta de Gasto” se debe llevar a cabo por la Intervención con anterioridad a la aprobación
del gasto.
Una vez fiscalizada la “Propuesta de Gasto” por la Intervención, el Órgano Gestor procederá
a la aprobación del gasto en los términos propuestos, no pudiendo alterar ya el expediente
tramitado. La aprobación del gasto se formaliza dando el “conforme” a la “propuesta de gasto”.
El Órgano de Contratación, al mismo tiempo que se aprueba el gasto, acuerda la apertura

del procedimiento de adjudicación, es decir, da la orden de que se inicien, de inmediato, las
actuaciones necesarias para la licitación del contrato.
Aprobado el gasto, el Órgano Gestor expedirá el documento contable A “Autorización de

gasto”, al que se adjuntará la “Propuesta de gasto”, el documento contable RC, y lo enviará a la
Intervención.
NOTA: La Intervención fiscaliza y contabiliza los documentos en el sistema propio IRIS.
Recibido en la Intervención, ésta contabilizará el documento “A”, y volverá a poner a

disposición del Órgano Gestor el documento “A” contabilizado.
Una vez aprobado el gasto por el Órgano Gestor, el Órgano de Contratación ordena la
licitación del contrato e impulsará el procedimiento de adjudicación establecido en el “pliego de
cláusulas administrativas particulares” para seleccionar al licitador que haya presentado “la
oferta económicamente más ventajosa”.
Una vez evaluadas las ofertas, el Órgano de Contratación entrega al Órgano Gestor el
documento administrativo “Propuesta de adjudicación”, y éste la pondrá a disposición de la
Intervención que la devolverá fiscalizada.
pág. 3
El Órgano de Contratación, a la vista de la “Propuesta de adjudicación” y la fiscalización de
la propuesta, sin más dilación, dictará la adjudicación del contrato.
El Órgano de Contratación procederá a su formalización en documento administrativo el

“Contrato”. Con la formalización del contrato queda comprometido el gasto por el importe del
contrato, IVA incluido, por lo que el Órgano Gestor procederá a expedir el correspondiente
documento contable D.
Formalizado, pues, el contrato, el Órgano Gestor expedirá el documento contable D

“Compromiso de gasto”, y lo remitirá a la Intervención para su contabilización.
Esta es la fase de ejecución del presupuesto de gastos que sigue a la fase inicial de
“aprobación del gasto”. En esta fase del compromiso el gasto queda fijado en un importe exacto,
apareciendo en escena el Contratista, con el que el Órgano de Contratación se obliga a ejecutar
el contrato.
Ha llegado el momento de ejecutar el contrato, debiéndose ejecutar la prestación

contractual en tiempo y forma, según lo pactado.
Finalizada la prestación, el Órgano de Contratación comprobará su efectivo cumplimiento,

en los términos establecidos por el legislador.
El Ministerio de Hacienda y Administraciones públicas le plantea la necesidad de crear un

sistema de gestión de expedientes para todos los organismos de la AGE.
Cuestiones a desarrollar
1. Diagrama de contexto del sistema que incluya los agentes intervinientes.
2. Diagrama de secuencia explicando el flujo de información entre los distintos agentes

intervinientes, haciendo énfasis en la información intercambiada entre los Órganos
Gestores, Órganos de Contratación y la Intervención.
3. Modelo de datos del sistema, señalando las principales entidades.
4. Diagrama de componentes justificando la arquitectura lógica y funcional de la solución

propuesta.
5. Diagrama de despliegue justificando la arquitectura.
pág. 4
Curso Apoyo a la Promoción Acceso al
Informática
Supuesto Práctico: SISTEMA PARA LA GESTIÓN

PRESUPUESTARIA Y CONTRACTUAL DEL
SECTOR PÚBLICO
Autor: Israel Barroso Pérez
Marzo de 2018
pág. 1
SISTEMA PARA LA GESTIÓN PRESUPUESTARIA Y CONTRACTUAL
DEL SECTOR PÚBLICO
1. Diagrama de contexto del sistema que incluya los agentes intervinientes.
pág. 2
2. Diagrama de secuencia explicando el flujo de información entre los distintos agentes
intervinientes, haciendo énfasis en la información intercambiada entre los Órganos
Gestores, Órganos de Contratación y la Intervención.
- Existen varias formas de realizar el diagrama de secuencia en función del nivel de

abstracción, y todos ellos son válidos para aprobar.
o A nivel de actores y sistemas.

o A nivel de actores y módulos o subsistemas.
o A nivel de actores y objetos.
o etc
- Lo más importante es mantener la coherencia con el resto de diagramas.
o A nivel de actores y sistemas: que los actores y sistemas aparezcan en todos los
diagramas.
o A nivel de actores y módulos o subsistemas: además de lo anterior, que los
módulos aparezcan en la arquitectura lógica.
o A nivel de actores y objetos: además de lo anterior, que los objetos aparezcan
como entidades en el diagrama de modelo de datos.
- En este caso habría que indicar que, por claridad del diagrama:
o Los funcionarios de los OGs y OCs se han autenticado previamente en el sistema

contra Autentica.
o Los documentos incorporan las firmas electrónicas de los funcionaros de los

OGs y OCs, haciendo uso del servicio Port@firmas.
o La fiscalización de los documentos puede ser “De conformidad” o “Con

reparos”. Si la intervención devuelve reparos, se produce un bucle en el que el
OG envia los documentos hasta que se obtenga la conformidad por parte de la
intervención.
pág. 3
pág. 4
3. Modelo de datos del sistema, señalando las principales entidades.
pág. 5
- Es importante tener en cuenta que hay elementos que suelen repetirse en los casos de
administración electrónica, como puede ser la clase expediente, la clase documento o
la clase registro, si bien es cierto que pueden existir otras fórmulas.
- Por otro lado, el hecho de poner de manifiesto clases que modelen la realidad del
problema y que expresen que se ha comprendido el peso de los diferentes elementos
del enunciado, implica demostrar que se ha comprendido mejor el ejercicio.
- Es esencial ser proporcionado en la forma del diagrama. Un exceso de atributos en las

clases puede aportar muy poco valor para el tiempo que se pierde. Por otro lado, si lo
que piden en el enunciado es establecer una gran cantidad de atributos, sí que habría
que reflejarlo.
- Conviene indicar las cardinalidades, siempre que sea posible. En UML, la cardinalidad de
las relaciones indica el grado y nivel de dependencia. Se anotan en cada extremo de la
relación y éstas pueden ser: o uno o muchos: 1..* (1..n) o 0 o muchos: 0..* (0..n) o
número fijo: m (m denota el número). Tener en cuenta que para las cardinalidades no
siempre hay una solución única: a veces es muy claro que un operador puede consultar
varios expedientes y que varios expedientes pueden ser consultados por varios
operadores. Sin embargo, un expediente podría ser consultado sólo por un funcionario
o no (se le da permiso a otros funcionarios a entrar), según cómo ideemos el sistema.
- Si no hay una pregunta en el enunciado específica para LOPD, sería conveniente incluir
lo que consideréis al respecto en este apartado.
pág. 6
4. Diagrama de componentes justificando la arquitectura lógica y funcional de la solución
propuesta.
El sistema GESPRECON se plantea como una solución basada en arquitectura web y centralizada
en el MINHAFP, por lo que se asume que se utilizarán las instalaciones del CPD del Ministerio.
A dicha plataforma se conectarán los funcionarios de los diferentes órganos gestores y órganos
de contratación a través de navegadores web utilizando certificado. Asimismo, se aplicará a los
documentos gestionados, contables y administrativos, las firmas recogidas en la Ley 40/2015
para la actuación administrativa automatizada, sello electrónico o csv, y se optará por formatos
como PDF/A que garanticen la conservación a lo largo del tiempo.
Por otro lado, las tecnologías escogidas en los módulos de GESPRECON se basan en fuentes y
estándares abiertos en línea con lo establecido en el RD 4/2010. En concreto, se opta por una
arquitectura JEE frente a .NET…
A continuación se muestra la arquitectura lógica del sistema GESPRECON
pág. 7
pág. 8
- Capa de presentación:
o Interfaz web que permite el acceso a los funcionarios de los OGs, funcionarios
de los OCs, Directivos de los OGs, Directivos de los OCs, perfil Administrador y
personal del CAU, mostrando una interfaz distinta en función de la
autenticación del mismo. El acceso se realizará a través de navegador Web
utilizando certificados.
o Tecnología: HTML5. Se permitirá el acceso mediante dispositivos de pantalla

reducida, por lo que las páginas web se programarán siguiendo los principios de
One Web del W3C y los criterios Responsive Design, utilizando CSS3 y media
queries.
o NOTA: si tuviéramos ciudadanos podríamos hacer mención a la Guía de

comunicación de la AGE.
o Principio Rector de la Estrategia TIC -> Orientación al usuario del servicio: “Es
necesario redefinir los servicios empezando por el lado del usuario, ya sea un
ciudadano o un empleado público, con una vocación de accesibilidad,
usabilidad, simplicidad y seguridad. Esa redefinición debe prolongarse hacia el
interior de la Administración para reformular procedimientos e informaciones
asociadas, con el propósito de avanzar hacia datos únicos, consistentes, no
redundantes, interoperables y compartidos entre procesos homogeneizados,
simplificados, interoperables y digitales de principio a fin.”
o Accesibilidad:
 Ley 11/2007 de Acceso electrónico de los ciudadanos a los servicios
públicos. Art. 4 c, Principio de accesibilidad a la información y a los
servicios;
 RD 1494/2007
 Norma UNE 139803:2012
 Usabilidad: Norma UNE 9241
 ¿Multilingüismo? -> D.A. 6ª Ley 11/2007 –> PLATA
- Lógica de Negocio: Cuenta con los siguientes módulos:
o Para dar solución a los diferentes módulos, se realizará un estudio en el CTT,

respaldado normativamente por el artículo 158 de la Ley 40/2015 y donde se
indica que “La Administración General del Estado, mantendrá un directorio
general de aplicaciones para su reutilización, prestará apoyo para la libre
reutilización de aplicaciones e impulsará el desarrollo de aplicaciones, formatos
y estándares comunes en el marco de los esquemas nacionales de
interoperabilidad y seguridad.” Este estudio permitirá reducir esfuerzos de
desarrollo del sistema GESPRECON al contemplar la reutilización como eje
vertebrador de la arquitectura.
o Módulo de Gestión de tramitación: Módulo encargado de la gestión del ciclo de

vida del expediente de gasto y del expediente de contratación en el
“backoffice”, por parte del personal funcionario de las OGs, UTs y OCs. Para cada
uno de los trámites realizados por el funcionario del OG y OC se desencadenará
pág. 9
una serie de revisiones, validaciones, generación y firma de documentos
contables a través del portafirmas. Para dar solución a estos módulos y dar
cumplimiento a lo descrito en el artículo 157 de la ley 49/2015 y el artículo 17.3
del ENI donde se indica que la Administración deberá consultar si existen
soluciones reutilizables que puedan satisfacer total o parcialmente las
necesidades a cubrir, se pueden valorar opciones como Inside, ofrecido por la
Dtic, que permitirá la gestión con documentos y expedientes electrónicos para
que cumplan los requisitos para que ambos puedan almacenarse y/o obtenerse
según el Esquema Nacional de Interoperabilidad y sus normas técnicas.
o Gestión de informes: módulo encargado de extraer los indicadores relevantes

para los directivos de los OGs y OCs. Se considera que el uso de librerías como
JasperReports no darían toda la información e indicadores que necesitan estos
directivos, por lo que se plantea la creación de procesos ETL para alimentar el
DWH ya existente en el Ministerio. De no existir este DWH, se pueden plantear
opciones libres como Pentaho frente a soluciones privativas como Oracle
Business Suite.
o Otros módulos que podrían haber aparecido:
 Comunicación Intervención: Módulo encargado de la comunicación

con el sistema IRIS para el intercambio de documentos contables
Permitirá el intercambio de los documentos contables y administrativos
que es necesario fiscalizar y contabilizar por parte de la Intervención.
 Administración: Módulo transversal encargado de tareas como por

ejemplo la gestión de usuarios (dar de alta funcionarios con perfil de OG
u OC, gestionar permisos, etc) o la configuración de la aplicación, todo
ello de acuerdo con las directrices de seguridad aplicables en el
MINHAP.
- Persistencia:
o Permite el acceso a la capa de datos y realiza tareas como gestión de la

persistencia de la información, que podrá implementarse por un paquete ORM
que facilite su desarrollo, por ejemplo Hibernate si utilizamos tecnología Java.
o Se trata de una capa protegida para evitar su acceso indebido. Dentro de esta
capa se incluyen tanto la Base de Datos (con los expedientes de gasto y de
contratación, referencias a los documentos contables y administrativos, etc),
como el gestor documental, repositorio común que contendrá los documentos
contables y administrativo y permitirá la gestión del ciclo de vida de los mismos.
- Servicios comunes y otros sistemas:
o Engloba tanto servicios comunes propios del Ministerio como servicios

horizontales a toda la administración. En este caso, Fire, Archive, Inside,
Autentica, o servicios ofrecidos por otros organismos a través de Servicios Web,
como es por ejemplo el caso de los servicios ofrecidos por la Intervención a
través del sistema IRIS.
pág. 10
5. Diagrama de despliegue justificando la arquitectura.
pág. 11
Curso de Apoyo a la Promoción Interna al
Informática
Convocatoria 2018 (OEP 2017)
BLOQUE III
Supuesto Práctico 5 – «Sistema AYES»
Enunciado
Autor: Alfonso Sancho Miró
Marzo de 2018
Curso de Apoyo a la Promoción Interna al Cuerpo de Gestión de Sistemas e Informática 2018
AYES – AYUDAS ESTATALES PARA LA SEQUÍA
España está dividida administrativamente en demarcaciones hidrográficas,

que son zonas compuestas por una o varias cuencas hidrográficas vecinas.
La gestión de estas demarcaciones hidrográficas está repartida entre la
Administración General del Estado (en adelante, AGE) y las Comunidades
Autónomas (en adelante, CCAA). La AGE gestiona las demarcaciones
hidrográficas que abarcan más de una Comunidad Autónoma; mientras que
las CCAA gestionan aquellas cuya extensión total queda geográficamente
enmarcada en el interior de sus límites autonómicos.
A nivel estatal, la gestión de las demarcaciones hidrográficas está

encomendada a las Confederaciones Hidrográficas, organismos autónomos
creados en 1926 y actualmente adscritos orgánicamente a la Dirección
General del Agua (en adelante, DGA) del Ministerio de Agricultura y Pesca,
Alimentación y Medio Ambiente (en adelante, MAPAMA).
Desde hace varios años, una importante tarea que han venido desarrollando
estos organismos es la gestión de la sequía. Cuando se produce una
situación de sequía en alguna demarcación hidrográfica estatal, el Gobierno
puede declarar, mediante Real Decreto, la situación de sequía en dicha
demarcación. Un Real Decreto declara la sequía para una demarcación
concreta e implica la puesta en marcha de medidas extraordinarias por
parte de la Confederación Hidrográfica correspondiente así como la
concesión de ayudas para los afectados. Cuando la situación de sequía
desparece, el Gobierno deroga la declaración del estado de sequía mediante
otro Real Decreto.
Debido a las recurrentes sequías que se producen en España, la DGA ha

decidido desarrollar AYES (AYudas Estatales para la Sequía), un sistema de
información para centralizar la tramitación de ayudas para paliar los efectos
producidos por la sequía en las demarcaciones hidrográficas estatales. Se
busca el máximo nivel de automatización posible.
Los requisitos generales para poder solicitar las ayudas son los siguientes:
- Ser titular de una explotación agrícola. Este requisito puede

comprobarse mediante la consulta del Registro General de la
Producción Agrícola. El titular de una explotación agrícola puede ser
una persona física o jurídica.
- La explotación agrícola debe estar ubicada en el ámbito de una
demarcación hidrográfica para la que esté vigente el estado de
sequía, declarado mediante Real Decreto.
Las ayudas consistirán en una contraprestación económica destinada a

compensar las pérdidas producidas por la sequía en las explotaciones
agrícolas afectadas. La ayuda se pagará mensualmente y se mantendrá
mientras esté vigente el Real Decreto de declaración del estado de sequía.
BLOQUE III. Supuesto Práctico 5 – «Sistema AYES». Enunciado. Página 2 de 4

Para poder disfrutar de esta ayuda, además de cumplir los requisitos

generales, se deberá tener en cuenta lo siguiente:
- El solicitante no puede haber recibido una subvención en el presente

año.
- El solicitante no podrá recibir subvenciones mientras esté disfrutando
de esta ayuda. En caso de incumplimiento de este requisito, el
afectado dejará de recibir la ayuda.
- Un perito deberá valorar los daños sufridos por la explotación agrícola
como consecuencia de la sequía. En base a la valoración realizada, se
establecerá la cantidad mensual que recibirá el afectado, que no
podrá superar la cantidad mensual máxima establecida en el Real
Decreto correspondiente.
El acceso al sistema por parte de los afectados se realizará a través de la

sede electrónica del MAPAMA. La solicitud de ayudas estará abierta mientras
haya algún Real Decreto de sequía vigente para alguna demarcación
hidrográfica. Los afectados adjuntarán, en su caso, la documentación que
sea necesaria. Recibida la solicitud en el sistema, se abre el correspondiente
expediente administrativo.
El personal tramitador de la DGA será el encargado de configurar en el

sistema los plazos de las convocatorias de ayudas vinculados al Real
Decreto correspondiente.
Para la tramitación de los expedientes de solicitud, la DGA contará con la

colaboración de las Confederaciones Hidrográficas. Cada Confederación
realizará la valoración de daños de las solicitudes que estén dentro del
ámbito de su demarcación.
En primer lugar, las solicitudes serán asignadas al personal tramitador de la

DGA; dicho personal comprobará si la documentación recibida es correcta
de cara a la concesión o no de la ayuda. Posteriormente, el expediente será
asignado a un perito de la Confederación correspondiente, el cual deberá
valorar los daños sufridos por la explotación del solicitante. Para ello podrá
desplazarse a la explotación si así lo estima oportuno. Cada perito deberá
rellenar el correspondiente informe de valoración que formará parte del
expediente administrativo. Para llevar a cabo la valoración es importante
que los peritos tengan acceso a cuanta documentación del expediente sea
precisa. Una vez realizada la valoración, el expediente volverá a asignarse
al personal tramitador de la DGA para proceder a su resolución.
La DGA valora positivamente que el sistema permita la obtención de

estadísticas e informes con los datos de concesión de ayudas.
La información de las ayudas concedidas deberá ser remitida a la Agencia

Tributaria y al Sistema Nacional de Publicidad de Subvenciones, que cuenta
con un registro de subvenciones. Debido a que muchas de las competencias

en agricultura están transferidas a las CCAA, éstas también deberán ser

informadas sobre las ayudas concedidas. En el sistema quedará constancia
de todas las remisiones realizadas.
Recuerde que la DGA busca que el sistema tenga el mayor nivel de

automatización posible. Puede efectuar las suposiciones que considere
conveniente, debiendo siempre hacerlas constar en su propuesta de
solución.
Se pide:
1- Diagrama de contexto del sistema.
2- Modelo conceptual de datos del sistema.
3- Represente los estados por los que pasa una solicitud de

ayuda. Utilice para ello el diagrama que crea conveniente.
4- Diagramas de casos de uso.
5- Proponga una arquitectura lógica para el sistema. Utilice el

diagrama que crea conveniente.

Curso de Apoyo a la Promoción Interna al
Informática
Convocatoria 2018 (OEP 2017)
BLOQUE III
Supuesto Práctico 5 – «Sistema AYES»
Propuesta de solución
Autor: Alfonso Sancho Miró
Marzo de 2018
Revisión 1: 11/06/2018
Comentarios para el opositor acerca del enunciado
Claramente se trata de un procedimiento administrativo. En estos casos, es

importante tener presente la Ley 39/2015, teniendo en cuenta lo siguiente:
 Del enunciado se desprende que sólo se realizarán solicitudes de

forma electrónica. Ante esto podemos optar por contemplar también
la solicitud en papel, que sería una postura válida. Otra opción es
contemplar la figura del funcionario habilitado que presentará la
solicitud electrónicamente en nombre del interesado.
 Los interesados tienen derecho a consultar sus expedientes.
Debemos contemplar la opción de que el interesado pueda consultar
el estado de tramitación de su expediente aunque el enunciado no lo
mencione.
 Igualmente debemos contemplar el envío de notificaciones.
 Al hablar de procedimiento administrativo, debemos tener presente
las NTI de expediente y documento electrónico, que nos ayudan a
establecer cuál será el modelo de datos.
BLOQUE III. Supuesto Práctico 5 – «Sistema AYES». Propuesta de solución. Página 2 de 10

1. Diagrama de contexto del sistema.
Se ha utilizado la notación propuesta en Métrica v3.
Comentarios para el opositor sobre el diagrama
Recuerde que el diagrama de contexto pretende dar una visión de alto nivel
del sistema, mostrando las principales entidades que interactúan con él.
Además se detallan los principales flujos de información, sin necesidad de
ser exhaustivos.

2. Modelo conceptual de datos del sistema.
Se ha utilizado la técnica del modelo entidad/relación extendido, con la

notación propuesta en Métrica v3. Los atributos de las entidades y
relaciones se han representado con un rectángulo situado al lado de la
entidad o relación correspondiente.
Comentario de revisión:
En las cardinalidades
marcadas en rojo,
podemos cambiar (1,1)
por (1,n)

3. Represente los estados por los que pasa una solicitud de ayuda.
Utilice para ello el diagrama que crea conveniente.
Se ha utilizado el diagrama de máquina de estados de UML.

4. Diagramas de casos de uso.
Comentarios para el opositor
Un concepto básico que hay que respetar a la hora de hacer el examen es la

coherencia. Siempre tenemos que tratar de mantener la coherencia entre
todos los apartados del ejercicio.
En este ejercicio se nos ha pedido anteriormente un diagrama de contexto.

Es importante que las entidades externas que hemos representado en
nuestro diagrama de contexto aparezcan también en nuestros diagramas de
caso de uso como actores.
Diagramas de casos de uso 1

Dentro de este caso de uso, conviene destacar que será el sistema el que
automáticamente abra el correspondiente expediente administrativo al
realizar la comprobación inicial de requisitos de la solicitud presentada.


Comentario de revisión
Sería más coherente
etiquetar esta relación
como <<extiende>>, con
la flecha en sentido contrario

5. Proponga una arquitectura lógica para el sistema. Utilice el

diagrama que crea conveniente.
Se propone una arquitectura en 3 capas. Se separa en capas para conseguir

mayor cohesión y menor acoplamiento. A continuación se muestra un
diagrama donde se recogen los principales componentes de cada capa.
Además se implementarían mecanismos de seguridad y monitorización en
todas las capas.

Gestión de Sistemas e Informática de la Administración del Estado
Supuesto práctico: PUNTO ÚNICO DE NOTIFICACIONES

PARA TODAS LAS ADMINISTRACIONES PÚBLICAS
Autora: Carmen Romero Raposo
BLOQUE III - SUPUESTO 6
Marzo 2018
PUNTO ÚNICO DE NOTIFICACIONES PARA TODAS LAS ADMINISTRACIONES PÚBLICAS
La Ley 39/2015, de 1 de Octubre, del Procedimiento Administrativo Común de las Administraciones Públicas
establece, en materia de notificaciones, que las mismas se practicarán preferentemente por medios
electrónicos. Adicionalmente establece que las notificaciones se practicarán obligatoriamente por este
medio cuando los destinatarios sean personas jurídicas, entidades sin personalidad jurídica y diversas
figuras que por razón de su capacidad económica o técnica, dedicación profesional u otros motivos quede
acreditado que tienen acceso y disponibilidad de los medios electrónicos necesarios.
Asimismo, la ley establece que las notificaciones electrónicas se practicarán mediante comparecencia en la
sede electrónica de la Administración u Organismo actuante, a través de la dirección electrónica habilitada
única o mediante ambos sistemas, según disponga cada Administración u Organismo. Independientemente
del medio elegido, deberá quedar constancia de la puesta a disposición, de la recepción o acceso por el
interesado o su representante, de sus fechas y horas, del contenido íntegro, y de la identidad fidedigna del
remitente y destinatario de la misma. Cuando el interesado sea notificado por distintos cauces, se tomará
como fecha de notificación la de aquella comparecencia que se produzca en primer lugar.
Ante el elevado número de sedes electrónicas y de vías de puesta a disposición, y para facilitar el acceso de
los ciudadanos a las notificaciones y comunicaciones emitidas por las Administraciones Públicas en el
ejercicio de su actividad, surge la necesidad de analizar y desarrollar un Punto Único de Notificaciones para
todas las Administraciones Públicas (en adelante PUN), que recoja al menos los siguientes requisitos:
El PUN ofrecerá a los interesados dos vías de puesta a disposición:
- Interfaz Web provista por Carpeta Ciudadana donde las personas físicas y jurídicas podrán acceder y
comparecer a sus notificaciones y comunicaciones. Vía Carpeta Ciudadana podrán consultarse todos los
envíos (notificaciones y comunicaciones) pendientes y realizados.
- Servicios Web para los denominados Grandes Destinatarios (personas jurídicas, incluyendo otras
Administraciones, que reciben un gran número de notificaciones y comunicaciones por parte de los
Organismos Emisores). A los Grandes Destinatarios se les dará de alta en el sistema y esta opción les
permitirá implementar un proceso automático para acceso, distribución interna y comparecencia de sus
envíos. Estos Servicios Web no proporcionarán un listado de los envíos ya comparecidos, debiendo recurrir
para ello a la Carpeta Ciudadana.
El PUN integrará las notificaciones y comunicaciones de todo el ámbito estatal a través de los Puntos Únicos
Concentradores (en adelante PUCs). Cada Comunidad Autónoma se constituirá en PUC y recogerá las
notificaciones en su ámbito, pudiendo además publicarlas en sus propias sedes electrónicas además de en el
PUN. Para los casos en que esto ocurra deberán existir mecanismos de sincronización de la información
entre el PUN y las sedes con el objetivo de no generar confusión al ciudadano.
Las Comunidades Autónomas que no quieran constituirse en PUC podrán adherirse a la plataforma Notific@,
siendo esta el PUC de la AGE. De este modo, se daría cumplimiento a todos los requisitos planteados en el
presente documento.
El PUN dispondrá de una interfaz de administración interna para gestionar el alta de los PUCs, además de
otras funcionalidades de administrador que se requieran en sucesivas fases.
El PUN almacenará las auditorias necesarias para garantizar que ante cualquier incidencia, se tenga la
trazabilidad completa de todos los envíos.
Cada PUC tendrá diversos parámetros de configuración ampliables, siendo los iniciales:
- Si es responsabilidad del PUC o del PUN indicar la fecha de puesta a disposición al ciudadano. La fecha
podrá ser distinta a la de alta en el PUN en caso de que el PUC decida poner el envío a disposición en su sede
antes de enviarlo al mismo. Si la fecha la gestiona el PUC, entonces él debe ser el encargado de controlar la
caducidad de los envíos.
- Si es responsabilidad del PUC o del PUN enviar un email de aviso al interesado para indicarle que tiene a su
disposición un nuevo envío. En caso de ser responsabilidad del PUN, la dirección a la que se realice el envío
se consultará al Registro Electrónico de Contactos.
- Si el PUC publica en una sede electrónica además de en el PUN.
Los PUCs podrán anular envíos que hayan sido enviados al PUN cuando haya algún error en los mismos, para
poder emitirlos de nuevo.
En cuanto al contenido de los envíos, el PUN almacenará los metadatos mínimos necesarios para servirlos a
los destinatarios, pero en ningún caso almacenará los documentos referentes a esos envíos. Estos deberán
ser consultados al PUC origen de uno en uno, a través del PUN, cuando el destinatario lo solicite. Cuando la
comparecencia se realice en el sistema, bien sea para aceptar o rechazar un envío, el PUN generará
automáticamente un documento acreditativo firmado que se enviará al PUC como resguardo.
Como responsable técnico del proyecto se le solicita realizar:
1. Determinación de los factores críticos de éxito del sistema.
2. Representar los requisitos software del PUN a través de diagramas de casos de uso.
3. Representar el modelo de datos a alto nivel del sistema.
4. Realizar un diagrama de secuencia explicando los distintos flujos de información para un alta de
notificación en el PUN, una comparecencia en Carpeta Ciudadana y una comparecencia en otra sede.
5. Esbozar brevemente un planteamiento de un piloto, expresando duración e intervinientes, para asegurar

que se han recogido todos los requisitos y que la implantación del proyecto sea un éxito.
En todo lo no contemplado en este supuesto, el opositor podrá efectuar las suposiciones que considere
convenientes, debiendo siempre hacerlas constar en su propuesta de solución acompañadas de su
correspondiente justificación.
PUNTO ÚNICO DE NOTIFICACIONES PARA TODAS LAS ADMINISTRACIONES
PÚBLICAS.
BLOQUE III - SUPUESTO 6 (Marzo 2018)
SOLUCIÓN:
A continuación se propone una aproximación de lo que podría ser una de las múltiples posibles
soluciones al enunciado planteado. Lo importante sería justificar las decisiones tomadas a lo
largo de la resolución del mismo.
1. Factores críticos de éxito
Para los factores críticos de éxito, seguiremos los siguientes pasos:
1. Elaborar una lista de objetivos del sistema, como pueden ser:
- Facilitar y simplificar la recepción de notificaciones electrónicas a los ciudadanos, de

manera que se consiga la eliminación o limitación de los envíos en papel.
- Ahorro de costes para las Administraciones.
- La seguridad del sistema, puesto que transitan por él datos sensibles como pueden
ser notificaciones de multas, desahucios, etc.
- La eficiencia del mismo y la disminución de los plazos de cierre de expedientes.
- Dar cumplimiento a las Leyes aplicables, como la Ley 39/2015 del Procedimiento
Administrativo Común de las Administraciones Públicas, el ENS y el ENI.
2. Identificamos los factores de éxito, entendiendo como tales los medios necesarios para
alcanzar los objetivos especificados:
- Integración de todos los PUCs en el sistema para conseguir un verdadero Punto

Único, puesto que de no hacerlo y seguir existiendo múltiples puntos, el sistema no generará la
confianza necesaria y fracasará.
- La integración con Servicios Comunes como Autentica, Notific@ y @firma para

favorecer la eficiencia y seguridad del sistema, además del uso de otros estándares de
seguridad en las comunicaciones vía servicio web.
- La migración de los envíos ya existentes en otros sistemas.
- Catalogar el sistema según el ENS y hacer las pertinentes evaluaciones o auditorias.

Seguir las guías de los estándares del ENI. Exponer en internet solo los servicios que den
soporte a los Grandes Destinatarios (puesto que en su gran mayoría pertenecerán al sector
privado). En cuanto a los PUCs, son Administraciones Públicas por lo que estarán dentro de
Red SARA.
- Cumplir con el Real Decreto 1494/2007 que exige un nivel de accesibilidad que
cumpla con las prioridades 1 y 2 de la UNE 139.803:2012.
3. Marcamos los factores críticos de éxito, entendiendo como tal aquellos que si no se
cumplen no se alcanzan los objetivos.
Descartamos como crítico la migración de los datos, puesto que no es necesaria ya que
el ciudadano siempre podrá consultarlos en los sistemas previos.
2. Diagramas de Casos de usos:
Por clarificar, se separaran en varios.
Se parte de un PUC no integrado en Notific@.
Caso de uso 1: Acceso de un ciudadano al que llamaremos persona, pudiendo ser física o
jurídica, a una notificación por Carpeta Ciudadana.
Estableceremos la precondición de que la persona que realizará los trámites se identificará a

través de cl@ve:
Adicionalmente, en caso de tratarse de un apoderado o un funcionario habilitado, para cada

trámite a realizar habrá que consultar a habilit@ o apodera y verificar si la persona que accede
tiene legitimidad para realizar el trámite en cuestión. Por simplicidad, también se establece en
un diagrama aparte, que quedaría de la siguiente manera:
El resto del diagrama, donde se recogen las acciones que pueden realizar los destinatarios de
las notificaciones, quedaría:
Caso de uso 2: Alta de un envío en el PUN por parte de un PUC:
Para el envío de alertas se usará la plataforma SIM. Adicionalmente, se consultará al Registro

electrónico de Contactos (REC) por si el ciudadano ha informado sus preferencias a este
efecto.
En este diagrama se recoge la sincronización entre sedes y PUN, pues en caso de producirse
una comparecencia fuera del sistema, el PUC lo actualizará mediante el caso de uso "Actualiza
envío PUN".
Caso de uso 3: Administración. Queda recogida la principal funcionalidad que indica el
enunciado, dejándose abierto a una ampliación de las mismas.
3. Modelo de datos a alto nivel:
Para el diagrama, se ha asumido que las altas se darán en remesas y no de 1 en 1.
En cuanto a trazabilidad, se almacenarán todas las peticiones y comparecencias de los Grandes

Destinatarios, así como un histórico de estado de cada envío.
En cuanto a los PUC, al tratarse de Organismos pertenecientes a las Administraciones Públicas,

se asume que tendrán asociados un código DIR3, por lo que se ha reflejado en la relación con
la entidad "Organismo".
4. Diagramas de secuencias:
Los diagramas están a alto nivel y muestran el intercambio de información entre los sistemas
con los que se comunica el PUN.
A continuación se refleja cómo quedaría un diagrama de secuencia del alta de una notificación
en el PUN. En este caso, el envío del email de aviso correrá a cargo del PUC:
A continuación se muestra el diagrama de secuencia de la comparecencia de un ciudadano

(persona física o jurídica) en Carpeta Ciudadana. Como precondición tenemos que quien
accede ya se ha autenticado mediante cl@ve.
A continuación mostramos el diagrama de secuencia de la comparecencia de un ciudadano en
otra sede, donde queda reflejada la actualización del cambio de estado en PUC y PUN:
5. Piloto:
Desarrollando el sistema siguiendo una metodología ágil como SCRUM, se podría plantear un
piloto (con una duración estimada de 3-4 meses) con un número de intervinientes controlados,
por ejemplo, en cuanto a PUC, Notific@ y dos CCAA que quieran participar, y como Grandes
Destinatarios, dos representantes del sector público y dos del sector privado.
Este piloto no tendría que esperar a que todos los desarrollos estén completos, sino que se
elegirían un subconjunto de funcionalidades elementales e ir iterando sobre las mismas hasta
refinar por completo el sistema. Tampoco habría que esperar a que todos los PUCs estén
integrados, pudiendo hacerlo progresivamente conforme avancen las pruebas y completen sus
desarrollos.
En cuanto a las funcionalidades elegidas para el piloto, se podría comenzar con el alta de una
notificación al PUN y la consulta de un documento al PUC, dejando para las siguientes
iteraciones la actualización y anulación de notificaciones y la generación del resguardo.

4 5917815826890622794 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

4 5917815826890622794 PDF

Cargado por

Copyright:

Formatos disponibles

APOYO A LA PROMOCIÓN ACCESO AL CUERPO DE GESTION

DE SISTEMAS E INFORMATICA 2018

Autor: Andrés García Cañizares.

La SGAD mediante El Catálogo de Servicios de Administración Digital difunde los servicios

En resolución de la anterior problemática, la SGAD desea implementar una nueva plataforma

Tras la firma de la adhesión, el Gabinete de la SGAD, deberá entrar en el aplicativo para

Una vez terminado el proceso de adhesión el Centro de Atención a Integradores y

Los servicios ofertados se ofrecerán en dos modalidades:

1. Elabore el diagrama de casos de uso. Identificando los actores involucrados

1. Elabore el diagrama de casos de uso. Identificando los actores involucrados.

@Firma: servicios de validación y firma electrónica multi-PKI @firma, como un servicio de

DIR3: El Directorio Común proporciona un Inventario unificado y común a toda la

Cl@ve: Es la plataforma común de identificación y firma electrónica, permitirá la identificación

3. Enumere los distintos servicios, funcionalidades y herramientas de seguridad o

4. Diseñe diagrama Entidad - Relación de la solución aportada.

6. Responda razonadamente las siguientes cuestiones:

b. Realice una breve descripción de las tecnologías y herramientas que usaría

El desarrollo se podría realizar utilizando el lenguaje de programación PHP 7.1.3, sobre un

c. ¿Sería necesario el acceso al aplicativo vía internet? Justifique su respuesta.

La publicación de la solución web en internet no sería necesaria, debido a que la mayoría de

1) Describir todas las entidades identificadas, normalizadas al menos a 3NF

Gestión de Sistemas e Informática. Bloque III. Enunciado Supuesto 2 Pág. 2 de 2

 Provincias, tabla proporcionada por personal.

3. Realizar las consultas en SQL que permitan detectar:

Gestión de Sistemas e Informática. Bloque III. Solución Supuesto 2 Pág. 2 de 9

Gestión de Sistemas e Informática. Bloque III. Solución Supuesto 2 Pág. 3 de 9

Gestión de Sistemas e Informática. Bloque III. Solución Supuesto 2 Pág. 5 de 9

4. Responder a las siguientes cuestiones:

i) Inclusión de un nuevo proceso selectivo

 tOposiciones: CD_CUERPO, CONVOCATORIA, y TOTAL_EJERCICIOS. Y a la espera de que se publique en el

Los campos FECHA_REALIZACION y NOTA_CORTE de tEjercicios se grabarán cuando se notifique y se corrija

Gestión de Sistemas e Informática. Bloque III. Solución Supuesto 2 Pág. 7 de 9

tOposiciones –(1:n) -> tEjercicios

tOposiciones –(1:n)-> tProcesosSelectivos

Y añadiendo una nueva relación

tProcesosSelectivos –(1:n)-> tEjercicios

Gestión de Sistemas e Informática. Bloque III. Solución Supuesto 2 Pág. 9 de 9

Marta Lara Boto

Bloque III - Supuesto 3

Usted, como parte de la subdirección de informática y tecnologías de la información de uno de

Una vez reunido con el departamento de Oficialía, la situación de partida es la siguiente:

- En la actualidad, existen 3 empresas que suministran material de oficina, aunque el

Los requisitos, una vez analizados, quedan establecidos de esta manera:

1. Descripción del sistema. Esquema general de la solución.

Marta Lara Boto

Bloque III - Supuesto 3

Usted, como parte de la subdirección de informática y tecnologías de la información de uno de

Una vez reunido con el departamento de Oficialía, la situación de partida es la siguiente:

- En la actualidad, existen 3 empresas que suministran material de oficina, aunque el

Los requisitos, una vez analizados, quedan establecidos de esta manera:

1. Descripción del sistema. Esquema general de la solución.

1. Descripción general del sistema

Se han identificado cuatro actores principales:

Se plantea el desarrollo de un proyecto web compuesto principalmente de dos aplicaciones

En cualquier caso, la base de datos siempre se alojará en la red interna.

Ilustración 1. Diagrama general

La matriz DAFO permite hacer un análisis de la realidad y facilitar la toma de decisiones en

Fortalezas: atributos propios del proyecto de carácter positivo.

Oportunidades: factores externos atractivos y positivos para el proyecto.

Ilustración 2. Diagrama de contexto

Los responsables introducirán en el sistema los datos relativos al catálogo de productos,

Las empresas consultarán los pedidos, y los servirán en el modo habitual.

En caso de discrepancia, la unidad consumidora la marcará como rechazada, indicando el motivo