pliego de condiciones técnicas para la … · web viewtitle pliego de condiciones técnicas para...

Pliego de Bases Técnicas

‘Implantación de los Sistemas de Gestión de Transportes Especiales y Gestión de

Escuelas Particulares de Conductores de la Dirección de Tráfico’

Erandio, 06 de Octubre de 2010

Larrauri Mendotxe bidea, 18 – 48950 ERANDIO (Bizkaia)Tel. 94 6078000 – Fax 94 6078302

Contenido

1. OBJETO DEL CONTRATO...............................................................................4

2. TRABAJOS A DESARROLLAR.......................................................................5

2.1. Alcance de los trabajos a realizar................................................................................52.1.1. Tareas a realizar 62.1.2. Funciones que debe cubrir el sistema 62.1.3. Entregables a obtener 182.1.4. Entorno tecnológico 20

2.2. Ámbito del contrato.....................................................................................................23

2.3. Formación....................................................................................................................23

2.4. Equipo mantenimiento................................................................................................24

2.5. Seguridad de acceso.....................................................................................................24

2.6. Auditoria......................................................................................................................24

2.7. Seguridad de funcionamiento.....................................................................................24

3. METODOLOGÍA A UTILIZAR.........................................................................26

4. EJECUCIÓN DEL CONTRATO.......................................................................28

4.1. Lugar de ejecución de las prestaciones y plazo........................................................28

4.2. Supervisión del contrato.............................................................................................28

4.3. Asignación del personal..............................................................................................29

4.4. Registro y control........................................................................................................29

ANEXO I: NORMAS DE SEGURIDAD RELATIVAS A LOS SISTEMAS DE INFORMACIÓN...............................................................................................................30

División de Tecnologías de la Información y Telecomunicaciones

2

ANEXO II: METODOLOGIA DE DESARROLLO DE SISTEMAS DE INFORMACION (M.D.S.I.)..........................................................................................................................33


3

1. OBJETO DEL CONTRATOEl objeto del contrato es la implementación de los nuevos sistemas dirigidos a la Dirección de Tráfico del Departamento de Interior del Gobierno Vasco. El objetivo del primero de los sistemas es la gestión, seguimiento y emisión de Autorizaciones Complementarias de Circulación, mientras que el objetivo del segundo es la gestión de todo lo relativo a las Escuelas Particulares de Conductores así como a las Inspecciones sobre las mismas, tanto por parte de la Dirección de Tráfico como por parte de las tres Oficinas Territoriales de la Dirección de Tráfico.

Por lo tanto, como resultado del cumplimiento del presente pliego, la Dirección de Tráfico obtendrá un sistema que cubrirá el conjunto de procesos y sus relaciones, necesarios tanto para la emisión de las Autorizaciones Complementarias de Circulación (ACC) para los vehículos especiales (VE) y en régimen de transporte especial (VERTE), como para la satisfacción de los módulos funcionales de las escuelas particulares de conductores y las inspecciones sobre las mismas.


4

2. TRABAJOS A DESARROLLAR

2.1. Alcance de los trabajos a realizarEl alcance de este expediente se divide en dos Hitos, que corresponden con cada uno de los sistemas a desarrollar:

Hito 1: Transportes Especiales Gestión de los Transportes Especiales.

Informes de Gestión.

Servicios e-Administración.

Hito 2: Escuelas Particulares de Conductores Gestión de las Escuelas Particulares de Conductores.

Gestión de Inspecciones.

Informes de Gestión.

Servicios e-Administración.

Migración de datos históricos del actual aplicativo existente.

Cada proyecto deberá contener las siguientes tareas dividas en diversas Fases:

Fase I: Plan de Proyecto.

Fase II: Análisis y Diseño.

Fase III: Desarrollo de las funcionalidades establecidas e integración con los

diferentes módulos afectados.

Fase IV: Implantación del proyecto que incluirá:

o Redacción del plan de pruebas de validación del sistema implantado.

o Soporte a la gestión del cambio facilitando la adaptación de los usuarios al nuevo sistema.

o Redacción del plan de arranque del sistema.


5

o Formación a usuarios previa a la puesta en marcha del proyecto. Esta formación deberá asegurar la consolidación del uso de todas las funcionalidades implantadas, así como el establecimiento de un periodo de soporte en el cual se pondrán en práctica los conocimientos adquiridos, realizándose un seguimiento durante y al final del proceso.

o Soporte post-implantación.

o Definición de los procesos de explotación y monitorización del sistema.

o Puesta en producción.

Para la realización de estas tareas se tendrán en cuenta las necesidades y requerimientos objeto de desarrollo, que les serán facilitados al adjudicatario por la División de Tecnologías de la Información y Telecomunicaciones.

Una vez realizados los trabajos, la aplicación será testada por el grupo de trabajo que a tal fin se defina, realizando las pruebas de usuario y de sistemas que se estimen oportunas para verificar la fiabilidad de los resultados y del rendimiento obtenido. Los errores detectados en estas pruebas serán corregidos por el adjudicatario como parte del trabajo, sin coste adicional.

2.1.1. Tareas a realizarLa realización de los desarrollos lleva implícita labores de análisis, programación y pruebas para una correcta implantación. Así mismo deberán tenerse en cuenta los impactos que puedan ocasionar los mantenimientos en otros sistemas y/o aplicaciones.

2.1.2. Funciones que debe cubrir el sistema

Hito 1: Transportes Especiales

Aunque el análisis funcional es parte del alcance del presente pliego, se propone una agrupación de las funcionalidades demandadas en los siguientes subsistemas funcionales:

Home: Subsistema donde se informan de los cambios a realizar en los expedientes, nuevos comunicados y se facilita la descarga de documentación.


6

Gestión de Expedientes: Este subsistema engloba los casos de uso relacionados con la gestión de los expedientes, desde la creación de una simulación hasta que la solicitud pasa a estado de Datos Completos, además de las posibles alternativas que se tienen una vez que el expediente está en dicho estado.

Consulta: Relaciona las opciones disponibles de consultas de expedientes (histórico de expedientes, seguimiento de expedientes…) y de elementos asociados a los mismos (matrículas, límites, prescripciones…).

Control de Viajes: Este subsistema incluye tanto la entrada de datos de los viajes comunicados por el titular de la autorización, como la entrada de datos de las verificaciones realizadas en cualquiera de los tramos de carretera que componen el itinerario del viaje comunicado, en el supuesto de que sea parado y verificado el transportista.

Estadísticas: Se trata de aquellas funcionalidades que permiten consultar las estadísticas de situación de tramitación de los expedientes.

Administración: Para cada uno de los subsistemas anteriormente citados, existen ciertas características como el mantenimiento de las diferentes tablas de diccionario implicadas y gestión de las redes de carreteras, accesibles solo por los administradores del sistema, que serán agrupados en un subsistema funcional específico de Administración.

Formularios: Formularios PDF que faciliten al usuario la presentación de las instancias, pudiendo ser enviados vía web evitando así la entrega física de las mismas en cualquier oficina territorial.

Como consecuencia del estudio de necesidades y requerimientos realizado, se utilizarán los siguientes servicios comunes, cuyo consumo se deberá implementar:

Identificación de acceso mediante certificado electrónico: El acceso a las aplicaciones desde Internet, bien por parte de las empresas o bien por los ciudadanos, se realiza mediante certificado digital reconocido o DNI electrónico.

Pago de tasas mediante la integración con SIPCA (Sistema Integrado de Pagos y Cobros de la Administración).

Integración con el Registro de Entrada / Salida de la Dirección de Tráfico.

Gestión de expedientes (workflow): Cada uno de los expedientes podrá tener diferentes estados y tareas. El sistema deberá guiar a los usuarios en cada uno de los diferentes trámites por los que puedan pasar los expedientes e informar a los involucrados en los mismos cuando así se requiera.


7

Archivo digital: Se guardará en formato digital toda aquella documentación aportada a lo largo del proceso, así como la documentación generada de manera automática desde el sistema.

Proceso de notificación: Este proceso deberá contemplar la posibilidad de enviar las notificaciones de forma telemática.

Toda esta información se almacenará en el sistema y servirá para transitar por los diferentes estados y tareas.

Integración con Gurenet, el portal departamental del Departamento de Interior: Gurenet es el Portal que aglutina todos los contenidos y aplicaciones de las Direcciones del Departamento.

Integración con el portal de tráfico:

o Consulta por el ciudadano, con el fin de que el ciudadano pueda conocer en todo momento el estado de su expediente, así como toda la documentación asociada al expediente.

o Tramitación de los trámites a realizar por el interesado, tanto para iniciar el expediente como para completar alguno de sus procesos.

o Gestión de Subsanación: Gestión que se lleva a cabo cuando la documentación presentada no es válida.

A continuación se detallan las funcionalidades específicas que debe cumplir:

Gestión de la Autorización especial de circulación para determinados transportes. Toda autorización conllevará la gestión un expediente con las siguientes tareas:

o Apertura del expediente: Presentación del formulario de solicitud, in-situ o a través de la web, junto con los documentos correspondientes. Integración con la aplicación de Registro de Entradas y Salidas. Creación del expediente para su gestión.

o Validación del expediente: Las tareas dependerán del trámite solicitado. El sistema detectará las acciones a realizar. Asociado con la validación, coexistirá el proceso de subsanación en aquellos casos que corresponda.

o Resolución: Proceso de gestión de resoluciones, que podrá ser favorable o desfavorable.


8

o Proceso de desistimiento: Como consecuencia del inicio del proceso de subsanación si éste no finaliza satisfactoriamente.

o Seguimiento: Proceso que permitirá en todo momento a la Ertzaintza registrar el acompañamiento realizado. Se generará el documento de pago asociado a dicho acompañamiento y se notificará al transportista.

o Cierre de Expediente: Una vez finalizada la tramitación.

Integración con la aplicación de gestión de incidencias de los operadores del CGTE con el fin de que quede constancia de la circulación del transporte.

Informes de Gestión

Aunque el alcance del presente pliego sólo abarca la extracción de la información necesaria para la confección de los informes de gestión, a continuación se indican las características generales de los informes estáticos y dinámicos demandados:

Datos a contemplar: Expedientes (Solicitante, Titular, Vehículos, Remolques, Itinerarios, Estado de tramitación, Lugar de salida, Lugar de Llegada); Acompañamientos (Tipo, Fecha, Itinerario, Expediente); Relevos de escoltas (Transporte, Expediente);

Indicadores: Expedientes (Nº Expedientes, Nº vehículos, Nº Expedientes por territorio, Nº Expedientes por estado, Nº Expedientes por carretera); Acompañamientos (Nº acompañamientos, Nº acompañamientos por carretera); Relevos de escoltas (Nº relevos, Nº de relevos realizados por expediente);

Modalidades: Dato del mes; Dato acumulado año; Dato porcentaje desvío.

Dimensiones de Análisis: Localización (Carretera, Municipio, Territorio); Expediente (Estado); Titular (Documento identificativo , Nombre/Razón social); Vehículos (Matrícula, Tipo).

Servicios eAdministración

Por un lado se deberá de implementar la utilización del servicio reutilizable de Notificación Telemática ya existente, y por otro, se deberá de implementar un servicio reutilizable de pago telemático.

Existe un proceso que hará uso del servicio de pago, y otro proceso que hará uso del servicio de notificación.

Hito 2: Escuelas Particulares de Conductores

Gestión de las Escuelas Particulares de Conductores


9

A continuación se describen los aspectos generales de las escuelas particulares de conductores que servirá para percibir mejor el ámbito funcional a abordar.

Una escuela de conductores se configura como una unidad de ámbito estatal que engloba la totalidad de las secciones, con objeto de que pueda conseguir mayor disponibilidad de los elementos materiales y personales.

Una sección es cada sucursal autorizada de la escuela matriz en distinto emplazamiento y con la misma titularidad y denominación. Las secciones de una escuela pueden estar situadas en distintos territorios históricos.

Toda escuela deberá disponer de los elementos personales y materiales necesarios para poder desarrollar sus funciones.

Los elementos personales son el titular, el personal directivo y docente y el personal administrativo. Los materiales están constituidos por los locales, terrenos o zonas de prácticas, los vehículos y el material didáctico. Todos los elementos mencionados pueden compartirse en el conjunto de la escuela (escuela matriz y sus secciones), excepto los locales, las zonas de prácticas y el material didáctico (exceptuando los intercomunicadores) que es propio de cada sección y constituyen los elementos diferenciales a la hora de determinar el alcance de la autorización.

Una agrupación de vehículos es la asociación de diferentes escuelas de conductores con el fin de compartir los vehículos.

Las escuelas y sus secciones, así como sus elementos personales y materiales, y las agrupaciones de vehículos, pueden pasar por distintas situaciones a lo largo de su existencia. Asimismo, pueden ser objeto de distintos tipos de expedientes, los podrán tener su origen, bien en una solicitud o comunicación de su titular, bien iniciados “de oficio” por la Administración.

El sistema deberá mantener el histórico de expedientes asociados a una escuela y sus secciones y los trámites derivados de dichos expedientes.

Los distintos tipos de expedientes son los siguientes:

Autorización de apertura.

Modificación de la autorización de apertura.

o Apertura de sección.

o Cambio denominación escuela.

o Cambio de locales.

o Cambios de terrenos o zonas de prácticas.


10

o Personal directivo: Alta; Baja; Modificación autorización ejercicio.

o Personal docente: Alta; Baja; Modificación autorización ejercicio.

o Vehículos: Alta; Baja; Reformas.

o Otros: Ampliación permisos; Disminución permisos; Cambio forma social del titular.

Suspensión voluntaria de las actividades (Se indicará inicio y final hasta un máximo de un año).

Extinción de la autorización de apertura:

o Por disolución de la sociedad, por renuncia o por transmisión de la empresa.

o Por muerte del titular o suspensión de actividades durante más de un año.

Agrupaciones de vehículos.

o Inscripción.

o Asignar / Desasignar escuelas/secciones de las agrupaciones.

o Asignar / Desasignar vehículos de las agrupaciones.

o Baja agrupaciones.

Autorización provisional por transmisión 'inter-vivos'.

Transmisiones 'mortis-causa'.

Sellado libro registro.

Sellado placas.

Duplicado de distintivo y autorización de ejercicio.

Duplicado de autorización de apertura.

Pérdida de vigencia de la autorización de apertura.

Pérdida de vigencia de las autorizaciones de ejercicio de director/profesor.

Suspensión de las autorizaciones de ejercicio del personal directivo/docente.

Plantillas asociadas a la tramitación de expedientes


11

Para la correcta implementación de las diferentes tramitaciones mencionadas con anterioridad, el sistema ha de disponer de una serie de plantillas predefinidas. Dichas plantillas contarán con información fija o plantillada, y de valores variables recogidos del sistema.

Una vez generados los documentos resultado de informar las plantillas con los datos variables provenientes del sistema, el usuario ha de tener potestad de variar la información contenida en el documento. O lo que es lo mismo, dicho documento ha de ser editable.

A continuación se listan las plantillas identificadas para cada uno de los diferentes expedientes existentes:

Autorización de apertura

o Notificación de falta de documentación.

o Resolución de autorización de apertura.

o Resolución de desistimiento de autorización de apertura.

o Resolución de caducidad de autorización de apertura.

Autorización de Funcionamiento


o Notificación de inspección previa.

o Resolución de autorización de funcionamiento.

o Resolución de desistimiento de autorización de funcionamiento.

Modificación de autorizaciones


o Resolución de denegación de modificación de autorización de apertura y funcionamiento.

o Resolución de desistimiento de la modificación de autorización de apertura y funcionamiento.

o Resolución de modificación de autorización de apertura y funcionamiento.

Agrupaciones



12

o Resolución alta o modificación agrupación con inspección.

o Resolución alta o modificación agrupación sin inspección.

o Resolución denegatoria agrupación.

o Resolución desistimiento agrupación.

Transmisión Inter-Vivos

o Notificación falta documentación.

o Resolución autorización provisional por transmisión inter vivos.

o Resolución desistimiento solicitud autorización provisional por transmisión inter vivos.

o Resolución revocación autorización provisional por transmisión inter vivos.

Transmisión Mortis-Causa


o Resolución autorización titularidad provisional por transmisión mortis causa.

o Resolución desistimiento autorización titularidad provisional mortis causa.

Obtención de certificados

o Ejercicio como profesor.

Extinción de autorizaciones


o Resolución extinción de la autorización de apertura y funcionamiento.

Inspecciones

o Acta de inspección agrupaciones.

o Acta de inspección.

o Inspección aviso.

o Inspección incidencias que conllevan sanción.


13

o Notificación incidencias inspección agrupación.

o Notificación incidencias inspección.

Notificaciones de caducidad

o Caducidad permisos profesores.

o Caducidad seguro e ITV vehículos.

Pérdida de Vigencia

o Resolución inicio de procedimiento.

o Resolución pérdida de vigencia.

Suspensión voluntaria


o Notificación caducidad suspensión voluntaria.

o Resolución autorización funcionamiento - fin suspensión voluntaria.

o Resolución desistimiento suspensión voluntaria.

o Resolución extinción autorización de apertura y funcionamiento.

o Resolución suspensión voluntaria de autorización.

Solicitud

o Impreso solicitud.

Además existen una serie de autorizaciones y distintivos que se han de poder emitir desde el nuevo sistema:

Autorización y Distintivo de Profesor.

Autorización y Distintivo de Director.

Requisitos

El sistema deberá comprobar una serie de requisitos una vez que se ha concedido la autorización de apertura y se hayan dado de alta todos los elementos asociados y en general siempre que se realice alguna modificación en cualquiera de ellos.

Cada escuela particular de conductores constituye una unidad formada por los elementos personales y materiales.


14

El conjunto de permisos que se pueden impartir en una escuela/sección depende tanto de los permisos asociados a los vehículos, de los permisos que puede impartir cada profesor, del material didáctico y del terreno de prácticas.

Los elementos personales sobre los que existen requisitos son:

El titular.

El personal directivo.

El personal docente.

Los elementos materiales sobre los que existen requisitos son:

Local.

Vehículos.

Terrenos o zonas de prácticas.

Material didáctico.

Gestión de Mínimos

La gestión de mínimos podrá ser activada desde cualquiera de los expedientes indicados anteriormente por un usuario, y de la misma manera será necesario implementar un proceso nocturno automático que comprueba los mínimos requeridos en la totalidad de elementos sujetos a los mismos.

Este proceso automático también podrá ser ejecutado bajo demanda de un usuario.

Desde el sistema se accederá a una consulta donde diariamente se visualizarán aquellas escuelas que no están cumpliendo los requisitos mínimos. De ese modo el usuario de la aplicación, si procede, iniciará un expediente de oficio de pérdida de vigencia, bien de la autorización de apertura, bien de la autorización de ejercicio del personal.

Gestión de Caducados

La gestión de caducados se llevará a cabo a través de la activación de un proceso desde el sistema. Este proceso afectará tanto a los permisos de los profesores como a los seguros e ITV de los vehículos.

Se deberá iniciar mediante consulta diaria a la DGT. Tanto a los registros de personas y a los registros de vehículos. Cuando se detecte que algún profesor tiene el permiso caducado se notificará a los usuarios de la aplicación para que inicie la gestión de mínimos y, si procede, inicie un expediente de pérdida de vigencia, bien de la autorización de apertura, bien de la autorización de ejercicio del personal.


15

Gestión de Inspecciones

La Gestión de inspecciones es el módulo responsable de todos los trámites asociados a las inspecciones a realizar en las escuelas. Las principales funcionalidades a desarrollar son:

Calendario de las inspecciones.

Gestión de las inspecciones.

Consultas.

Existen tres tipos de inspecciones:

Ordinaria avisada.

Ordinaria no avisada.

Extraordinaria por modificación de la autorización de apertura.

Las inspecciones siempre se realizarán por personal de la Dirección de Tráfico.

Siempre se realizará una inspección previamente a la concesión de la autorización de apertura (ordinaria avisada) y por modificación de dicha autorización (cambio de locales, terrenos o zonas para prácticas y alta de vehículos).

Calendario de inspecciones

El calendario de inspecciones permitirá planificar dichas inspecciones a lo largo del año. Este calendario recoge tanto las inspecciones ordinarias como extraordinarias.

El sistema permitirá parametrizar el número mínimo de autoescuelas a inspeccionar. El calendario de inspecciones deberá contar con la siguiente funcionalidad:

Alta de fecha de inspección: se registrarán los datos de la autoescuela, la causa y la fecha planificada.

Cambio de fecha o motivo de inspección. Una vez registrada una cita, sólo será posible modificar su fecha o motivo.

Anulación de la fecha de inspección. Se podrán anular las citas planificadas.

Gestión de inspecciones

Las inspecciones se realizarán conforme a diferentes modelos de acta (dependiendo del tipo de inspección) que el usuario podrá llevar en parte cumplimentadas con los datos básicos de la escuela/sección.


16

El resto de datos a cumplimentar en el acta durante la inspección lo podrá realizar el usuario eligiendo una de las dos opciones:

En formato papel.

Con la ayuda de un portátil y una impresora. Una vez introducidos los datos, imprimirá el acta y la firmarán tanto el inspector como el director de la autoescuela.

Informes de Gestión

Aunque el alcance del presente pliego solo abarca la extracción de la información necesaria para la confección de los informes de gestión, a continuación se indican las características generales de los informes estáticos y dinámicos demandados:

Datos a contemplar: Escuelas y Secciones (Tipo, Titular, Municipio, T.H., Permisos); Personal Directivo y Docente (Tipo, Edad, Sexo, Tipo permiso, Fecha alta, T.H., Estado); Vehículos (Tipo, Permiso, T.H.); Agrupaciones (T.H.) e Inspecciones (Tipo, Resultado, Subsanado).

Indicadores: Escuelas y Secciones (Nº Escuelas, Nº Secciones, Nº Escuelas por territorio según nº secciones); Personal Directivo y Docente (Nº Personal, Nº Profesores alta en mas de una escuela, Nº Directores alta en mas de una escuela); Vehículos (Nº Vehículos); Agrupaciones (Nº Agrupaciones); Inspecciones (Nº Inspecciones) e Indicadores de Gestión (Nº Expedientes, Nº Expedientes con subsanación, Tiempo tramitación, Nº Expedientes inicio web, Nº Expedientes pérdida vigencia, Nº Autorizaciones, Nº Autoescuelas, Nº Altas, Nº Bajas, Nº Modificaciones).

Modalidades: Dato del mes; Dato acumulado año; Dato porcentaje desvío.

Dimensiones de Análisis: Localización (T.H., Municipio); Escuela (Tipología, Secciones, Permisos); Personal (Tipo, Sexo, Edad, Permisos); Vehículos (Permisos); Inspecciones (Resultado, Tipo); Tiempo (Año, mes); Estado; Expediente (Tipo).

Servicios eAdministración

Se deberá de implementar la utilización de los servicios de Pago y Notificación Telemáticos ya existentes.

A continuación se indica el número de procesos que harán uso de cada uno de los servicios:

Pago telemático: 22 procesos.

Notificación Telemática: 16 procesos.


17

Migración de Datos

Se deberá de llevar a cabo una migración inicial de los datos actualmente existentes en la actual aplicación de autoescuelas y relativos a entre otras, las siguientes entidades:

Escuelas.

Secciones.

Personal.

Vehículos.

Agrupaciones.

Terrenos.

Dicha migración posibilitará el disponer del histórico de dichas entidades, pero no el histórico de las tramitaciones.

2.1.3.Entregables a obtenerPor las fases de análisis, diseño, desarrollo, pruebas e implantación de las diferentes fases se deberán cumplimentarse todos los documentos definidos como obligatorios por la M.D.S.I., incluyendo como mínimo:

1. Análisis Funcional:

Incluyendo las estructuras de las bases de datos/ficheros (modelo lógico y físico de datos).

2. Diseño Técnico:

Arquitectura del sistema.

Componentes de presentación (pantallas, navegación y validaciones).

Componentes de negocio (unidades de despliegue y diseño de servicios).

Componentes de controlador (correspondencias entre presentación y negocio).

Componentes de integración (flujos y descripción de actividades de integración).

Seguridad y Operación (control de acceso, auditoria, credenciales, control de flujo, integridad).

3. Documento de trabajo


18

Contiene de forma claramente perceptible y comparable, las situaciones anteriores y posteriores a las modificaciones obradas respecto de:

Interfaz de usuario: se reproducirán las pantallas y listados.

Condiciones, controles y validaciones de datos.

Bases de datos/ ficheros de nueva creación o cuya estructura se modifique, con indicación de los nombres de los campos y sus atributos.

Descripción del comportamiento de las funcionalidades modificadas.

4. Inventario de Programas y Funciones Generales

Para los grupos generales nuevos, el registro y una descripción de lo que hacen.

Para programas nuevos, además de la descripción y características detallar si tiene WHERE dinámicos:

o Tablas Auxiliares que utiliza (nombre de la BD y nº tabla, dentro de ésta, de condiciones).

o Programas que le llaman y a los que llaman.

Nombre de los campos de bases de datos que contengan nº o código de identificación de Personas, Empresas y Vehículos, nombres de los campos que contengan códigos de leyes y los nombres de los campos que contengan códigos de calles y los nombres de los campos que contengan nombres de calles.

5. Fuentes de los desarrollos realizados.

6. Documentación javadoc generada a partir de los fuentes.

7. Plan de migración de datos (detalle de todas las acciones necesarias para llevar a cabo la correcta migración de los mismos). Exclusivo Hito 2.

8. Plan de formación a usuarios (incluirá manuales de usuario diferenciados por roles).

9. Plan de pruebas de validación del sistema (incluirá la redacción de las pruebas a realizar).

10. Plan detallado de arranque del sistema (incluye el plan de implantación, procesos de explotación, si los tuviera y medidas de monitorización).

Cabe destacar como entregables de gran importancia, los prototipos que se demandarán y que servirán para establecer un seguimiento pormenorizado del avance de los desarrollos de cada uno de los dos hitos.


19

2.1.4. Entorno tecnológicoLa DTIT dispone de una arquitectura de ejecución de servicios basada en la plataforma SOA estándar de mercado agrupada en niveles de consumo y provisión de servicios, en el que los servicios de presentación se basan en tecnología de portales J2EE y gestión de contenidos, en procesos de negocio (BPM) descritos en BPEL y servicios de negocio (Enterprise Java Beans y Web Services) sustentados sobre el framework o arquitectura de componentes de ejecución “Oinarri” y que colaboran con aplicativos y servicios desarrollados en otras tecnologías a través de un Bus de Integración de Servicios.

La arquitectura de ejecución de producción resultante de la topología es el siguiente:

Base de Datos DB2 v8.2 para Z-OS.

Base de Datos Oracle

Portal WebSphere Portal Server v6.1 para AIX.

Gestor de Contenidos Workplace Web Content Management v6.1 para AIX.

Servidor de lógica de negocio WebSphere Application Server v6.1 para Z-OS.

Servidor de procesos de negocio WebSphere Process Server v6.1 para AIX.

Gestor Documental IBM Content Manager v8.4 para AIX.

Bus de integración de servicios WebSphere Message Broker v6.1 para AIX.

Tivoli Access Manager v6.1 para AIX.

IBM Directory Server v6.1 para Z-OS.

Navegadores del mercado.


20

La arquitectura de desarrollo adecuada a la arquitectura de ejecución descrita se compone:

Herramienta IDE - Rational Application Developer, que cubre el ciclo

completo de desarrollo de la D.T.I.T.

Probar yDepurar

Importar y Desplegar

Construir

Servidor de PortalServidor de aplicaciones

Probar yDepurar

Importar y Desplegar

Construir

Servidor de PortalServidor de aplicaciones

Desarrollo de portlets Desarrollo de portales Desarrollo de servicios de negocio

Asistentes para importación de portalesy despliegue

El framework de ejecución Oinarri basado en modelo de 3 capas (MVC v2),

que se traduce a una secuencia de ejecución de componentes distribuidos

orientados a solucionar problemáticas de soporte e integración (control de

navegación, captura de excepciones, validaciones genéricas...) y en la que

los desarrolladores “encajan” componentes que solucionan las tareas

funcionales de las aplicaciones. Su fundamento técnico es:

o Portlets basados en Struts para capa de presentación.

o Fachada de sesión con EJBs 2.0 de sesión para capa de negocio.

o DAOs o EJB de entidad y conectores dedicados para acceso a datos.


21

WID: Herramienta para el desarrollo de procesos de negocio

MB Toolkit: Herramienta para el desarrollo de flujos de integración

Rational ClearClase, como repositorio de código a compartir entre los

desarrolladores y como herramienta con soporte al versionado de

entregables.

A modo orientativo se indican los perfiles y funciones que se estiman se requieren para la realización de los sistemas objeto de este pliego.

Perfiles Funciones

Jefe de proyecto

• Control y Coordinación del proyecto.• Realizar informes de seguimientos mensuales.• Interlocutor con los responsables del proyecto.

Analistas • Elaboración del Análisis Funcional y preparación de documentación técnica y de usuario y cuanta documentación le sea encomendada en relación con el proyecto.

• Definición y descripción de las estructuras de datos a nivel lógico.• Definición y descripción de procedimientos e interfaz de usuario.• Formación a personal técnico y usuario.• Pruebas de integración y optimización del sistema.


22

Analistas-Programadores

• Diseño detallado de aplicaciones informáticas a partir de la especificación de los requisitos funcionales de las mismas.

• Definición y descripción de las estructuras de datos a nivel lógico y físico.

• Definición y descripción de procedimientos e interfaz de usuario.• Especificación de directrices para la realización de pruebas

unitarias y de integración de los módulos o programas.• Elaborar y mantener documentación descriptiva de las

aplicaciones informáticas y cuanta documentación le sea encomendada en relación con el proyecto.

Programadores • Elaborar nuevos o modificar programas, rutinas e interfaces que cumplan las especificaciones establecidas en el diseño.

• Integrar y enlazar programas y rutinas siguiendo las especificaciones establecidas en el diseño por el analista.

• Desarrollo y ejecución de pruebas unitarias.• Elaborar y mantener documentación descriptiva de programas y

plan de pruebas que permitan la consulta y actualización por terceras personas y cuanta documentación le sea encomendada en relación con el proyecto.

2.2. Ámbito del contratoEl ámbito del presente contrato es el relativo a los sistemas completos necesarios para la gestión, seguimiento y emisión de Autorizaciones Complementarias de Circulación, así para la gestión integral de Escuelas Particulares de Conductores, incluida la gestión de las inspecciones sobre las mismas.

A pesar de que ambos hitos se dividan en módulos, no implica necesariamente que el desarrollo de los mismos se tenga que abordar de forma secuencial.

2.3. FormaciónSe presentará el plan con los cursos de formación proporcionados, y/o recomendados, para el uso de las funcionalidades de los sistemas, especificando, para cada caso, tipo


23

de curso, perfiles de alumnos, número de participantes, duración estimada y temario contemplado.

2.4. Equipo mantenimientoSe definirá el equipo de mantenimiento, sin incluir nuevos desarrollos, necesario para mantener en funcionamiento activo ambas soluciones, especificando, principalmente, perfil y número de integrantes.

2.5. Seguridad de accesoSe describirán las funcionalidades ligadas con los aspectos de seguridad de acceso y uso de los sistemas, indicando niveles de seguridad, gestión de perfiles, control de acceso a funcionalidades y datos, etc. Para ello, se deberán seguir las pautas y criterios establecidos por la D.T.I.T. en su Plan de Seguridad relativo al desarrollo de aplicaciones J2EE.

2.6. AuditoriaSe describirán las funcionalidades asociadas a dejar rastros de las operaciones realizadas en los sistemas, fundamentalmente en el acceso a datos de carácter personal conforme a lo establecido en la LOPD.

Para ello, se utilizará el componente de auditoría en el framework de ejecución J2EE de la D.T.I.T.

2.7. Seguridad de funcionamientoSe indicará la posibilidad de control de funcionamiento correcto de los sistemas y sus componentes, tolerancia a fallos, planes de salvaguarda, planes de contingencia, disponibilidad de los sistemas cara al usuario, etc.

La D.T.I.T. cuenta con ITCAM como herramienta para monitorizar y gestionar su entorno orientado a servicios. Será parte del alcance del presente pliego, realizar las


24

pertinentes tareas que permitan que el software de gestión de infraestructura, ayude a acelerar y simplificar la identificación y resolución de problemas.


25

3. METODOLOGÍA A UTILIZAREl proyecto se realizará siguiendo la Metodología adoptada por el Departamento de Interior del Gobierno Vasco, M.D.S.I. y documentada mediante su gestor metodológico. Además, para cumplimentar los requerimientos de definición establecidos por la Metodología, se utilizan las siguientes herramientas complementarias:

MS Project, para seguimiento del plan.

ABC FlowCharter o MS Visio para la descripción de flujos en la fase de definición.

Lotus Notes Versión 5 ó superior para la documentación y anexado de entregables de todo el proyecto.

En el apartado 2.1.4 (Entorno Tecnológico) se numeran las herramientas de desarrollo de aplicaciones J2EE de la DTIT.

La D.T.I.T. entregará una versión de la base de datos Lotus Notes correspondiente al proyecto y manuales de la metodología. Se deberán cumplimentar todos los documentos obligatorios establecidos por dicha Metodología, así como los optativos designados por el Jefe de Proyecto responsable del mismo.

Además de la metodología fijada para la documentación del proyecto, debe indicarse que, con el fin de garantizar la calidad en los desarrollos J2EE orientados a servicios sobre una plataforma SOA, una persona designada por la D.T.I.T. validará los diseños realizados antes del comienzo de su desarrollo.

El diseño y el desarrollo se realizarán siguiendo los criterios, mejores prácticas y normas establecidos en el Marco del Desarrollador definido por la D.T.I.T. para sus desarrollos J2EE, que será entregado al equipo que se designe antes del inicio del proyecto. En el mismo existe un apartado de normativas de seguridad a aplicar en la plataforma cuyas directrices deberán aplicarse en los desarrollos a realizar. Así mismo, se deberán seguir los criterios establecidos en la guía de estilos que se proporcionará al adjudicatario.

La D.T.I.T. dispone del framework J2EE denominado “Oinarri” que será la arquitectura de aplicación sobre la que se ejecutarán todos los desarrollos J2EE. El adjudicatario deberá hacer uso sólo de los componentes aportados por dicho framework. No podrán utilizarse librerías de terceros sin previa validación y autorización por la persona designada por la D.T.I.T para tal fin.

En aquellos casos que existan servicios reutilizables ya definidos por la D.T.I.T. que cubran alguna de las funcionalidades o requerimientos de los proyectos, se utilizarán éstos o se identificarán las modificaciones a realizar sobre los mismos, con el fin de garantizar la estandarización y aprovechamiento de los recursos.


26

Una vez realizados los trabajos de desarrollo, éstos serán testados por la D.T.I.T., realizando las pruebas de usuario y de sistemas que estime oportuno para verificar la fiabilidad de los resultados y del rendimiento obtenido. Así mismo, se compilarán los programas fuentes entregados según las librerías existentes en el Departamento. Tanto los errores detectados en estas pruebas como las deficiencias originadas por el uso de librerías no autorizadas serán corregidos por el adjudicatario como parte del trabajo, sin coste adicional.

Así mismo, se indica que la apariencia visual de los desarrollos deberá seguir unas guías de estilo que se entregarán al comienzo del proyecto y que fijan la imagen corporativa tanto para aplicaciones de intranet, como para internet. En tiempo de validación del diseño, una persona de la D.T.I.T. se encargará de validar el cumplimiento de dichas normas de imagen.


27

4. EJECUCIÓN DEL CONTRATOEl adjudicatario será responsable de la correcta ejecución de los trabajos en que el contrato consiste.

4.1. Lugar de ejecución de las prestaciones y plazoLos nuevos desarrollos y pruebas del sistema se realizarán principalmente en las dependencias del Departamento de Interior, sitas en Erandio - La Campa (Bizkaia), aunque no se excluye la posibilidad de acudir a otros centros de trabajo para temas formativos, de toma de requerimientos, etc. La Administración, mediante oportuna notificación, señalará el comienzo de los trabajos, con el fin de que el contratista pueda proceder a su ejecución.

Una vez iniciados los trabajos previstos, el equipo contratado deberá estar a disposición de la D.T.I.T. No obstante, en el caso de que se prevean circunstancias que aconsejen la suspensión temporal del plan, se procederá a su comunicación a la empresa adjudicataria.

El plazo de ejecución del presente contrato será de seis meses a partir de la fecha de notificación de inicio de los trabajos por parte de la Administración. En dicho plazo deberá estar finalizado el desarrollo, formados los usuarios e implantados los dos sistemas. En el caso de que existan servicios reutilizables comunes, será el adjudicatario el responsable de planificar la realización de los mismos de forma que se garantice su reutilización en ambos proyectos en el plazo establecido.

4.2. Supervisión del contratoSe formará un Comité Director formado por los responsables que la D.T.I.T. designe y por los responsables de la empresa ejecutora. La dirección del trabajo será ejercida por un técnico de la D.T.I.T quien actuará como coordinador y supervisor de la correcta realización de los compromisos contraídos por el adjudicatario. A su vez, el adjudicatario designará, al menos, un Responsable de la empresa.

El técnico responsable, por parte de la D.T.I.T., tiene las más amplias atribuciones, y sus órdenes e instrucciones serán inmediatamente ejecutivas.

El adjudicatario vendrá obligado a dar total cumplimiento a las condiciones que al efecto de control establezca la Administración. Las discrepancias sobre el desarrollo de los servicios serán resueltas al nivel más alto de representación.


28

El trabajo realizado deberá recibir la aprobación del técnico que lleve a cabo la dirección del trabajo, mediante la recepción definitiva del mismo.

4.3. Asignación del personalLos perfiles del personal técnico requerido para la ejecución de los trabajos objeto de este expediente serán definidos por la empresa adjudicataria. La designación de técnicos realizada por la empresa adjudicataria podrá ser modificada, a simple petición de la Administración, y en este caso, el adjudicatario se obliga a proponer otras personas.

La elección por la Administración de ésas u otras personas no alterará en ningún caso el precio ofertado por la adjudicataria.

4.4. Registro y controlComo parte del contrato, el adjudicatario estará obligado a dar total cumplimiento a las condiciones que al efecto de control establezca la Administración. El adjudicatario deberá proporcionar la información requerida por la Administración para conocer la situación y desarrollo de los trabajos contratados.


29

ANEXO I: NORMAS DE SEGURIDAD RELATIVAS A LOS SISTEMAS DE INFORMACIÓN

Compromisos del adjudicatario en materia de seguridad e interoperatividad de los servicios de e-administración

El adjudicatario asumirá el cumplimiento de lo establecido en el Esquema Nacional de Seguridad (ENS) y en el Esquema Nacional de Interoperabilidad (ENI) en lo referido a la adopción de medidas de seguridad e interoperabilidad de los servicios de e-administración. En este sentido, el adjudicatario asumirá expresamente que los servicios de e-administración incluidos en el presente contrato se realizarán a través de la infraestructura tecnológica común dispuesta por el Gobierno Vasco (PLATEA, Plataforma Tecnológica para la e-Administración), cumpliendo así lo legalmente establecido en cuanto a la adopción de las medidas de seguridad indicadas (Reales Decretos 3/2010, de 8 enero –ENS, Esquema Nacional de Seguridad- y 4/2010, de 8 de enero –ENI, Esquema Nacional de Interoperabilidad- ).

Acceso y protección de datos

El adjudicatario quedará expresamente obligado a mantener absoluta confidencialidad y reserva sobre cualquier dato que pudiera conocer con ocasión del cumplimiento del contrato, especialmente los de carácter personal, que no podrá copiar o utilizar con fin distinto al que figura en este Pliego de Prescripciones Técnicas, ni tampoco ceder a otros ni siquiera a efectos de conservación.

A estos efectos, deberán establecerse las máximas cautelas en el acceso a los datos. Cualquier infracción en este sentido será calificada como grave y será causa de resolución del contrato, sin perjuicio de las responsabilidades penales, o de otro tipo, en que se puedan incurrir.

El adjudicatario quedará obligado al cumplimiento de lo dispuesto en la Ley orgánica 15/1999 de 13 de diciembre sobre protección de datos de carácter personal, y en el correspondiente reglamento de desarrollo de la LOPD (aprobado por real Decreto 1720/2007, de 21 de diciembre, en vigor desde el 19 de abril de 2008); y especialmente en lo indicado en su artículo número 12, que a continuación se transcribe:


30

“Artículo 12.- Acceso a los datos por cuenta de terceros.1.- (…)2.- La realización de tratamientos por cuenta de terceros deberá estar regulada en un contrato que deberá constar por escrito o en alguna otra forma que permita acreditar su celebración y contenido, estableciéndose expresamente que el encargado del tratamiento únicamente tratará los datos conforme a las instrucciones del responsable del tratamiento, que no los aplicará o utilizará con fin distinto al que figure en dicho contrato, ni los comunicará, ni siquiera para su conservación, a otras personas.En el contrato se estipularán, asimismo, las medidas de seguridad a que se refiere el Artículo 9 de esta Ley que el encargado del tratamiento está obligado a implementar.3.- Una vez cumplida la prestación contractual, los datos de carácter personal deberán ser destruido o devueltos al responsable del tratamiento, al igual que cualquier otro soporte o documentos en que conste algún dato de carácter personal objeto del tratamiento.4.- En el caso de que el encargado del tratamiento destine los datos a otra finalidad, los comunique o los utilice incumpliendo las estipulaciones del contrato, será considerado también responsable del tratamiento, respondiendo de las infracciones en que se hubiera incurrido personalmente.”A tal fin, y conforme el Real Decreto 994/1999, de 11 de junio, por el que se aprueba el Reglamento de medidas de seguridad de los ficheros automatizados que contengan datos de carácter personal, el oferente incluirá en su oferta Memoria Descriptiva de las medidas de seguridad que adoptarán para asegurar la disponibilidad, confidencialidad e integridad de los datos manejados y de la documentación facilitada.

Propiedad intelectual

Los derechos de propiedad intelectual relacionados con el trabajo realizado pertenecerán a la Administración. Cualquier producto o subproducto derivado del mismo no podrá ser utilizado para otros fines fuera del ámbito que le corresponda, sin el permiso expreso por escrito de la Administración.Asimismo, todos los entregables que deban facilitarse a los Departamentos y Organismos Autónomos del Gobierno Vasco (salvo las ofertas previas) únicamente deberán llevar como logotipo o señas de identidad el escudo del Gobierno Vasco o logotipos aceptados por el propio Departamento y Organismo Autónomo.El Contratista se verá también obligado a guardar las normas vigentes sobre, Copyright, propiedad intelectual y documentación clasificada o de difusión restringida que, por necesidades del contrato, se vea obligado a manejar.


31

Seguridad laboral

El Contratista cumplirá con todas las normas vigentes de Seguridad e Higiene Industrial.

Normas de comportamiento respecto a los sistemas de información

El contratista se compromete a cumplir las siguientes normas de comportamiento respecto a los sistemas de información del D.I.G.V.

No introducir software informático ajeno al D.I.G.V. No difundir ni publicar los sistemas de seguridad existentes o previstos. No revelar la información obtenida de los sistemas de información del D.I.G.V.,

ni la documentación que se le suministre o la que pudiera tener acceso en el desempeño de sus funciones, con independencia del soporte en que se encuentre contenida.

Acceso exclusivo a la información necesaria para el desempeño de las funciones encomendadas.

Utilizar exclusivamente la password-clave a él asignada y adquirir el compromiso de actuar de forma cuidadosa para que nadie conozca su palabra de paso.

Utilizar adecuadamente y de forma cuidadosa los sistemas de seguridad implantados, de forma que se respeten y mantengan los niveles de seguridad.

No utilizar el sistema de correo u otro medio alternativo para sacar fuera de la organización la información a la que se tenga acceso en el desempeño de sus funciones.

Además, el adjudicatario adquirirá los siguientes compromisos, que a continuación se describen en cuanto a materia de seguridad se refiere:

Los equipos conectados a la red corporativa del D.I.G.V. no podrán conectarse a ningún sistema informático o de telecomunicaciones ajeno al Departamento.

Los equipos o sistemas que por su actividad requieran conexión a servicios externos al Departamento deberán estar aislados, es decir, separados física y lógicamente de la red informática del D.I.G.V.

Está expresamente prohibida la instalación de módems (o similar) en equipos (PCs, Servidores, etc.) conectados a la red del Departamento de Interior.


32

ANEXO II: METODOLOGIA DE DESARROLLO DE SISTEMAS DE INFORMACION (M.D.S.I.)

FASE 1: ANALISIS DE SISTEMAS La fase de análisis de sistemas de la totalidad de los módulos se encuentra realizada.

FASE 2: DISEÑO DE SISTEMAS MODULO DTS: DISEÑO TÉCNICO DEL SISTEMA

DTS 1: Diseñar la arquitectura física del sistema.

DTS 1.1. Diseño de la estructura modular del sistema.

- Diagrama de estructura de cuadros de alto nivel, que muestra la comunicación entre subsistemas.

- Diseño de la estructura modular del sistema.

DTS 1.2. Descripción de interfases entre módulos del sistema.

- Diseño de la estructura modular del sistema completado, incluyendo los flujos de datos y de control.

DTS 1.3. Descripción de interfases con otros sistemas.

- Diseño de la estructura modular del sistema completado, incluyendo las interfases con otros sistemas.

DTS 1.4. Descripción de interfases de usuario.

- Diseño de pantallas revisado, incluyendo la descripción de los interfases de usuario.

- Modelo control/evento/respuesta revisado, incluyendo la descripción de los interfases de usuario.

- Documento de descripción de los diálogos del sistema revisado, incluyendo la descripción de los interfases de usuario.

- Diseño de informes revisado, incluyendo la descripción de los interfases de usuario.

DTS 1.5. Definición de componentes del sistema.


33

- Diseño de la estructura modular del sistema completado, incluyendo descripción (en forma de pseudocódigo o lenguaje estructurado), de cada componente a desarrollar.

- Inventario de transacciones y programas.

- Cuadernos de carga de cada programa (Agrupación de módulos en programas y breve descripción de su función y funcionamiento).

- Organigrama de cada programa.

- Diseño de la seguridad del sistema.

- Diseño de la seguridad por programa.

DTS 2: Diseñar la estructura física de datos del sistema.

DTS 2.1. Elaboración del modelo físico de datos.

- Inventario de tablas y ficheros.

- Modelo físico de datos.

DTS 2.2. Optimización del modelo físico de datos.

- Entidades de datos y sus atributos, revisadas y completadas.

- Modelo físico de datos revisado y completado.

DTS 3: Especificar el entorno tecnológico del sistema.

DTS 3.1. Definición del entorno tecnológico del sistema.

- Especificación del entorno tecnológico del nuevo sistema.

DTS 3.2. Especificación de requisitos de comunicaciones del sistema.

- Especificación del entorno tecnológico revisado, incluyendo una descripción y diseño de la configuración de la red de comunicaciones del sistema.

DTS 3.3. Especificación de requisitos de operación, seguridad y control.

- Descripción de los procedimientos de operación de los componentes del sistema (tanto periódicos como mediante petición), y de los procedimientos de seguridad y control.

DTS 3.4. Distribuir datos y funciones.

- Matriz Entidad/Localización.

- Matriz Función/Localización.

DTS 4: Completar especificaciones de diseño.


34

DTS 4.1. Revisión de la planificación inicial.

- Planificación inicial revisada.

DTS 4.2. Revisión del diseño técnico del sistema.

DTS 5: Puntos función.

DTS 5.1. Cálculo de los puntos función.

DTS 6: Actas de reuniones.

DTS 6.1. Actas de reuniones.

FASE 3: CONSTRUCCION DE SISTEMAS MODULO DCS: DESARROLLO DE COMPONENTES DEL SISTEMA

DCS 1: Preparar el entorno de desarrollo, pruebas y procedimientos de operación.

DCS 1.1. Implantación de la base de datos física o ficheros de datos.

DCS 1.2. Preparación del entorno de desarrollo.

- Descripción completa del entorno de desarrollo que se ha preparado.

DCS 1.3. Preparación del entorno de pruebas.

- Definición del entorno de pruebas.

DCS 2: Desarrollar y probar componentes del sistema.

DCS 2.1. Generación del código de los componentes del sistema.

- Código fuente de los componentes del sistema.

- En entorno micros, control de copias de seguridad durante el desarrollo de la aplicación.

DCS 2.2. Preparación, ejecución y evaluación de las pruebas unitarias.

- Preparación y ejecución de las pruebas unitarias.

- Informe de las pruebas unitarias de cada componente.

DCS 2.3. Control de cambios en el desarrollo, sobre las especificaciones iniciales.

- Informe de control de cambios.

DCS 3: Realizar pruebas de integración.

DCS 3.1. Preparación, ejecución y evaluación de las pruebas de integración.


35

- Preparación y ejecución de las pruebas de integración.

- Informe de pruebas de integración del sistema.

DCS 4: Revisar la planificación inicial.

DCS 4.1. Revisión de la planificación inicial.

- Planificación inicial revisada.

DCS 5: Actas de reuniones.

DCS 5.1. Actas de reuniones.

MODULO DPU: DESARROLLO DE PROCEDIMIENTOS DE USUARIO

DPU 1: Elaborar procedimientos de usuario.

DPU 1.1. Diseño de la estructura de los procedimientos de usuario.

- Documento sobre las actividades y tareas para los procedimientos de usuario.

DPU 1.2. Elaboración de procedimientos de usuario.

- Manual de usuario del nuevo sistema.

DPU 2: Determinar necesidades especiales para el funcionamiento del sistema.

DPU 2.1. Identificación de perfiles de usuario.

- Definición de perfiles de usuario requeridos.

- Seguridad por perfil de usuario.

DPU 3: Desarrollar plan de formación de usuarios.

DPU 3.1. Identificación de requisitos y recursos necesarios para la formación de usuarios.

- Plan de formación en el nuevo sistema.

DPU 3.2. Preparación de los materiales de formación de usuarios.

DPU 4: Consolidar procedimientos de usuario.

DPU 4.1. Organización y consolidación de la documentación de procedimientos de usuario.

DPU 5: Actas de reuniones.

DPU 5.1. Actas de reuniones.


36

pliego de condiciones técnicas para la … · web viewtitle pliego de condiciones técnicas para...

Documents