PLIEGO DE CONDICIONES TÉCNICAS PARA LA CONTRATACION DEL DESARROLLO DE UN SOFTWARE DE GESTIÓN DE PALACIOS DE CONGRESOS
PLIEGO DE CONDICIONES TÉCNICAS PARA LA CONTRATACION DEL DESARROLLO DE UN SOFTWARE DE GESTIÓN XX XXXXXXXX DE CONGRESOS
ÍNDICE
1. DEPARTAMENTO QUE INICIA EL PROCEDIMIENTO 3
2. OBJETO DEL PROYECTO 3
3. ANTECEDENTES Y SITUACIÓN ACTUAL 3
4. ALCANCE DEL PROYECTO 3
5. DESCRIPCIÓN DE LAS TAREAS A REALIZAR 5
6. COMPATIBILIDAD 6
7. ENTORNO TECNOLÓGICO 6
8. METODOLOGÍA 7
9. PLANIFICACIÓN Y ORGANIZACIÓN 7
10. MECANISMOS DE SEGUIMIENTO Y CONTROL 8
11. GARANTÍA DE LOS TRABAJOS 8
12. FORMACIÓN 9
13. LOPD 9
14. DOCUMENTACIÓN 9
15. IDIOMA 10
16. ESTRUCTURA NORMALIZADA DE LAS OFERTAS 10
17. ANEXO I: EPÍGRAFES SCB 11
1. DEPARTAMENTO QUE INICIA EL PROCEDIMIENTO
Departamento de Empleo y Desarrollo Económico Sostenible
2. OBJETO DEL PROYECTO
El objeto principal del proyecto es el desarrollo o adaptación de alguna solución software existente, implantación y puesta en marcha de una aplicación Web para que el Servicio de Congresos y Turismo del Ayuntamiento de Vitoria-Gasteiz pueda gestionar de manera más eficiente las salas de los diferentes xxxxxxxx de la ciudad en las que organizan sus eventos/actividades/reuniones.
3. ANTECEDENTES Y SITUACIÓN ACTUAL
En la actualidad el Servicio de Congresos y Turismo dispone de una aplicación en Access desarrollada por personal municipal, para la Gestión de los Xxxxxxxx de Congresos de la ciudad:
▪ Xxxxxxx de Congresos y Exposiciones Europa
▪ Xxxxxxx xx Xxxxxxxxx
▪ Xxxxxxx Eskoriaza-Xxxxxxxx
Esta aplicación dispone de las siguientes funcionalidades:
▪ Clientes
▪ Gestión de eventos y reservas
▪ Facturación
▪ Informes
Periódicamente se han ido resolviendo incidencias priorizando y planificando las mismas, pero debido a los problemas que les está ocasionando se plantea la necesidad de cambiar de aplicativo.
4. ALCANCE DEL PROYECTO
El nuevo Sistema de Gestión de Congresos debe abarcar las siguientes funcionalidades:
4.1. Clientes
Información adecuada al Xxxxxxx sobre las personas y entidades/empresas con las que trabajan.
4.2. Gestión de eventos y reservas
Información necesaria sobre el evento que se está organizando y la/s sala/s dónde tendrá lugar el mismo.
4.3. Disponibilidad xx xxxxx
Información visual sobre la disponibilidad de las salas, para evitar solapamientos de horas/salas. Poder mostrar de un vistazo la ocupación xx Xxxxxxx por sala.
4.4. Facturación
Aunque el Xxxxxxx actualmente no factura, la aplicación debe contemplar la posibilidad de que en el futuro pueda facturar, por lo tanto debe estar preparada. Actualmente genera una proforma que se envía al Departamento de Hacienda.
4.5. Comunicaciones
A través del módulo de comunicación se permitirá el envío de mails, la generación de cartas y etiquetas para cartas de una forma sencilla. Se permitirá seleccionar bien un grupo de contactos previamente generado con la herramienta de informes, o bien añadir uno a uno los contactos que se deseen. Toda la información que se envíe a un cliente (persona/entidad) quedará reflejada en su ficha.
4.6. Intercomunicación con web del Palacio de Congresos Europa
Debe existir intercomunicación entre la nueva aplicación web objeto de este contrato y la página web del Palacio de Congresos Europa, de tal forma que se pueda consultar la disponibilidad de una sala, hacer una solicitud de reserva xx xxxx desde la web de Congresos y que se valide en la aplicación de Gestión de Congresos para que esta reserva (reserva, cliente, sala/s) pasen a la aplicación directamente, eventos de la agenda congresual (eventos) visible o no según convenga. Pero que la agenda congresual de la web de Congresos lea la información de la nueva aplicación de Gestión de Congresos.
4.7. Administración de las relaciones con el cliente
Debe existir un módulo de administración de las relaciones con los clientes, que nos permita realizar un seguimiento de nuestros contactos y clientes potenciales.
Las funcionalidades que debe cubrir son:
• Clasificaciones de cliente (contactos, clientes potenciales, cuentas, oportunidades y notas personalizadas)
• gestión de datos (importación y exportación de datos, copias de seguridad de datos, y más)
• organización (tareas, calendarios, eventos, recordatorios, notas y más)
• comercialización (integración con cuenta de correo electrónico, redes sociales y más)
• analítica (informes de ventas, tendencias y más)
4.8. Informes
Generación de informes de forma rápida, que permitan obtener cualquier dato de forma automática, resultados fiables evitando duplicidades, generación de grupos de entidades/empresas y contactos (clientes) para poder utilizar en campañas: mailing, navidad, eventos, etc.
Poder exportar los informes a los formatos más habituales para poder trabajar con ellos: excel, word, PDF.
4.9. Integración con SCADA
La aplicación debe estar totalmente integrada con el Sistema de Control de
Climatización del Palacio de Europa (SCADA) de manera que evitaremos introducir los datos de los eventos en los dos sistemas.
4.10. Cumplimiento epígrafes Spain Convention Bureau (SCB)
Al estar asociados al SCB, se debe cumplir con los códigos (códigos tipo de actividad que se utilizan en el Spain Convention Bureau
El SCB es una asociación de ciudades y provincias compuesta actualmente por 57 destinos con medios técnicos y humanos suficientes para la organización de reuniones y eventos, dirigidos a un aforo mínimo de 500 personas.
4.11. Generación de datos abiertos
La aplicación deberá ser capaz de generar los datos abiertos para poder publicarlo en el portal de datos abiertos del Ayuntamiento de Vitoria-Gasteiz, el cual es un punto de acceso único a gran variedad de datos elaborados por la institución, los cuales se pueden utilizar, reutilizar, enlazar y redistribuir gratuitamente y sin restricciones (ver Términos de uso).
4.12. Migración BD actual y carga de datos
Se deben migrar los datos de la BD de la aplicación actual en acces a BD de la nueva aplicación.
5. DESCRIPCIÓN DE LAS TAREAS A REALIZAR
El adjudicatario será el encargado de coordinar los distintos módulos del proyecto desde el punto de vista técnico y organizativo, de forma que:
▪ tenga la visión global del avance del proyecto y la situación de cada uno de los módulos o subproyectos en los que se ha dividido.
▪ Sea un interlocutor único con el Ayuntamiento de Vitoria-Gasteiz que permita mejorar la gestión, control y seguimiento del proyecto por parte del Ayuntamiento de Vitoria-Gasteiz.
Las actividades a realizar en estos subproyectos se clasifican en:
▪ definición y análisis funcional y técnico del sistema.
▪ construcción del modelo.
▪ implantación.
▪ pruebas integradas y despliegue en producción.
6. COMPATIBILIDAD
El sistema propuesto debe ser compatible con el sistema de comunicación y la infraestructura de tecnología de la información existente en el Ayuntamiento de Vitoria- Gasteiz descrita en el apartado Entorno Tecnológico.
7. ENTORNO TECNOLÓGICO
7.1. Desarrollos a medida entorno web
Para desarrollos a medida en entorno web, se ajustará a los siguientes componentes:
o El framework de desarrollo será preferentemente Grails aunque se pueden aceptar otros previa consulta y autorización. Por ejemplo Java + Struts.
o El servidor de aplicaciones será WebSphere 8.5.x con IBM JDK 7 en entorno Linux (RedHat)/AIX 7 usando como frontal Apache 2.
o El entorno de desarrollo estará basado en Eclipse, repositorio SVN, Maven, Artifactory y despliegues automáticos mediante Xxxxxxx.
o Se integrarán las aplicaciones con sistemas SSO existentes para Intranet o Internet/Sede basado en JA-SIG CAS.
o Para el desarrollo de Web Services se utilizará el estándar JAX-WS y no implementaciones (AXIS, CXF, …).
o Existe la posibilidad de usar Alfresco 3 como gestor Documental
o SIG: (ArcGIS versión 10.2, Spatial Data Engine SDE 9.3, DB2/UDB 9.7).
o El sistema de Base de Datos central es un AS/400 DB2/UDB iSeries 7.1, MySQL 5.0.
o Gestor de Contenidos Municipal es un desarrollo propio en JAVA sobre base de datos MySQL.
o El indexador de contenidos está basado en Google Search Appliance.
o Xxx Xxxxxxx-Gasteiz: Desarrollo propio en JAVA usando las siguientes APIs:
o Mapstraction
o OpenLayers
o OpenTripPlanner
▪ Business intelligende: Cognos 7.4
7.2. Implantación de productos
Para implantación de productos será necesario un análisis de requisitos por parte
del departamento de Administración Municipal (TI), aunque se dispone de los mismos componentes descritos para de desarrollo de aplicaciones u otros como:
▪ Servidores Windows 2003/2008.
▪ BBDD MS SQLServer 2008 o MySQL 5,0.
▪ Ofimática LibreOffice v4 para Windows XP y v5 para Windows 7.
8. METODOLOGÍA
Las propuestas técnicas deberán contener una descripción detallada de las metodologías propuestas en cada caso y respetar los estándares del Ayuntamiento de Vitoria-Gasteiz.
Se exigirá la aplicación de métodos ágiles con el objetivo de lograr:
▪ Entregas frecuentes de software.
▪ Adopción de cambios sugeridos por el cliente.
▪ Comunicación fluida con los equipos de desarrollo.
▪ Generación de conjuntos de pruebas y su adopción desde las fases más tempranas de todos los proyectos.
▪ Integración continúa entre proyectos.
▪ Atención continúa a la calidad y al buen diseño.
▪ Definición de estándares o reglas de codificación.
▪
9. PLANIFICACIÓN Y ORGANIZACIÓN
Se deberá presentar un programa de trabajo y Plan de Proyecto ajustado a lo prescrito en este Pliego y conteniendo cuantos aspectos complementarios sobre la forma de realización de cada una las tareas descritas en el mismo se consideren oportunas, detallando las actividades y la organización de los recursos humanos ofertados.
La empresa adjudicataria identificará en su oferta la persona o personas que formarán parte de su equipo de trabajo para este proyecto:
▪ Jefe de Proyecto
▪ Técnicos y/o Consultores.
En la oferta se habrá de incluir los siguientes aspectos relativos al equipo de trabajo:
▪ Historial profesional de cada una de las personas que participan en el proyecto.
▪ Responsabilidades y roles asignados a cada una de las personas.
▪ Organización del equipo de trabajo.
10. MECANISMOS DE SEGUIMIENTO Y CONTROL
Se realizarán reuniones de seguimiento periódicas presenciales entre el adjudicatario y el Jefe de proyecto del Ayuntamiento de Vitoria-Gasteiz, en las que este último determinará las pautas a seguir. Así mismo tendrán lugar reuniones periódicas de seguimiento del proyecto global. Se presentará una propuesta concreta de seguimiento y control en la que por lo menos se tengan en cuenta los siguientes mecanismos:
▪ Reuniones operativas.
En base a una solicitud presentada por cualquiera de los Jefes de Proyecto, el Jefe de Proyecto del Ayuntamiento convocará la reunión, invitando a la misma al personal municipal que considere oportuno.
▪ Reuniones de seguimiento.
Con una periodicidad quincenal se celebrarán reuniones de seguimiento y revisiones técnicas, en las que participarán el Jefe de Proyecto del Ayuntamiento y el Jefe de Proyecto de la empresa adjudicataria, así como el personal municipal o los miembros del equipo de trabajo que se consideren oportunos por cada una de las partes.
El Jefe de Proyecto de la empresa adjudicataria entregará un informe de avance y situación del proyecto.
▪ Actas de las reuniones de seguimiento.
El Jefe de Proyecto de la empresa adjudicataria realizará y enviará al Ayuntamiento el acta correspondiente a cada una de las reuniones. Estas actas serán contrastadas y aprobadas por ambas partes.
▪ Documento de trabajo de instalación.
Cuando se deban realizar trabajos de instalación o similares en las dependencias municipales, el Jefe de Proyecto de la empresa adjudicataria presentará un documento detallando los trabajos a realizar, quién los llevará a cabo, la duración aproximada de los mismos y los medios técnicos o humanos necesarios por parte del Ayuntamiento de Vitoria- Gasteiz.
▪ Documento de reasignación de personal. Cuando, por el motivo que sea, se produzca algún cambio en el equipo de trabajo de la empresa adjudicataria, el Jefe de Proyecto presentará un documento indicando los motivos por los que se produce el cambio, el personal afectado y el historial profesional de los nuevos miembros del equipo. Así mismo se indicará si este cambio supone alguna alteración de los planes de trabajo, o de la organización del equipo. En cualquier caso, toda modificación del equipo de trabajo deberá contar con el visto bueno del Jefe de Proyecto del Ayuntamiento, que podrá rechazar el mismo si considera que no se cumplen los requisitos mínimos establecidos.
11. GARANTÍA DE LOS TRABAJOS
Condiciones generales
El adjudicatario deberá garantizar por un año los productos derivados de la presente
contratación, a contar desde la fecha de recepción de los mismos, obligándose a realizar durante dicho período los cambios necesarios para solventar las deficiencias detectadas imputables a la firma adjudicataria si así lo solicita el Ayuntamiento.
Esta garantía incluirá la corrección de errores o fallos ocultos que se pongan de manifiesto en los trabajos realizados. Los productos originados como consecuencia de la corrección de errores tendrán que entregarse de conformidad con lo exigido en este pliego.
12. FORMACIÓN
La formación se diferenciará en:
▪ Formación para los Técnicos del Sistema.
▪ Formación para los Usuarios del Sistema.
En todos los casos el adjudicatario deberá proponer un plan de formación especificando duración y contenido de las distintas sesiones de formación e impartir la formación de acuerdo al plan.
13. LOPD
La empresa adjudicataria está obligada al cumplimiento íntegro de La Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal (LOPD) y su normativa de desarrollo.
14. DOCUMENTACIÓN
A lo largo del proyecto se irá entregando la documentación recogida en este pliego de condiciones, que será validada por el Jefe de Proyecto del Ayuntamiento de Vitoria- Gasteiz. A modo resumen se incluye a continuación la lista de entregables del proyecto.
▪ Documento de Análisis Funcional de los procedimientos a implantar
▪ Ficha completa por procedimiento incluyendo su gráfico de modelado.
▪ Documento de integración y documento de especificación técnica de la construcción.
▪ Documento de Análisis Técnico.
▪ Plan detallado pruebas.
▪ Plan detallado de instalación e implantación por fases.
▪ Manuales de usuario.
▪ Manual de instalación.
▪ Manual de explotación.
▪ Guía de Puesta en marcha en producción.
▪ Plan de Gestión del Cambio.
La documentación generada durante la ejecución del contrato de propiedad exclusiva del Ayuntamiento de Vitoria-Gasteiz sin que el contratista pueda conservarla, ni obtener copia De la misma o facilitarla a terceros sin la expresa autorización de este Ayuntamiento, que
la daría en su caso previa petición formal del contratista con expresión del fin.
Toda la documentación se entregará correctamente encuadernada y con la cantidad de Copias que se determinen para cada documento. Asimismo, se entregará dicha documentación en el soporte magnético que se acuerde para facilitar el tratamiento y reproducción de los mismos.
La empresa adjudicataria deberá suministrar al Ayuntamiento de Vitoria-Gasteiz, en plazos razonables, las nuevas versiones de la documentación que se vayan produciendo.
También se entregarán, si es el caso, los documentos sobre los que se haya basado el desarrollo, en las mismas condiciones que los anteriores.
En todos los documentos que se hayan de entregar constará, como mínimo, el responsable, la fecha de finalización y la versión.
15. IDIOMA
Todos los contenidos y componentes desarrollados (los elementos de entrada/salida) se han de presentar de tal forma que, en cualquier momento, se pueda optar por el idioma
castellano o euskera. Las labores previas de traducción deberán poderse realizar de forma fácil, sencilla y abierta.
16. ESTRUCTURA NORMALIZADA DE LAS OFERTAS
La oferta se entregará tanto en formato papel como en formato electrónico.
Con independencia de que el licitador pueda adjuntar a su oferta cuanta información complementaria considere de interés, deberá estar obligatoriamente estructurada de la siguiente forma:
1. Índice
2. Características generales
• Identificación de la oferta.
• Compresión y alcance del proyecto propuesto
3. Memoria justificativa del cumplimiento de los requisitos con descripción de la solución tecnológica propuesta
Se incorporará al inicio de este apartado el resumen de los aspectos más significativos y relevantes de la solución ofertada.
Se deberá incluir información detallada de la oferta en relación con los requisitos de este pliego.
4. Metodología de trabajo propuesta
5. Equipo de trabajo
• Datos relativos al equipo de trabajo. Curriculum vitae
• Composición del equipo de trabajo que se propone ordenado por categorías profesionales.
6. Funcionalidades superiores o complementarias a las exigidas
7. Organización del proyecto y Plan de Proyecto
Con la especificación del cronograma donde se indique de forma clara los hitos principales del proyecto y los entregables de cada fase.
17. ANEXO I: EPÍGRAFES SCB
Anualmente el Spain Convention Bureau, solicita anualmente a todos los xxxxxxxx de congresos asociados diferentes informes que deben seguir una nomenclatura concreta para lo cual nuestra herramienta debe tener estructurada la información de la siguiente manera:
Tipos de actividad y ámbito:
• Congresos
o Internacionales
o Nacionales
o Regionales
• Convenciones
o Internacionales
o Nacionales
o Regionales
• Jornadas, seminarios y simposios
o Internacionales
o Nacionales
o Regionales
Tipología de los organizadores de estas actividades:
Para cada organizador se debe introducir entre otros los siguientes datos:
• Carácter
o Público
o Privado
• Ambito
o Municipal
o Supramunicipal
• Sector de actividad
o Científico
o Cultural
o Medico-Sanitario
o Economía/Comercial
o Docencia/investigación
o Tecnología
o Público
o Quimico-Farmacia
o Social
o Universidad
o Otros
Listados para cada actividad (congreso, convención, …) por número de asistentes:
• Hasta 50
• Hasta 150
• Hasta 250
• Hasta 500
• Hasta 2000
• Más de 2000
Tipo de alojamiento utilizado por los congresistas:
• Hotelero con distinción del nº de estrellas
• No hotelero Actividades complementarias:
• Culturales (museos, conciertos, exposiciones, etc.)
• Turísticas (excursiones, visitas guiadas, etc.)
• Deportivas (especificar actividad)
• Gastronómicas
• Shopping