Source: https://es.scribd.com/document/59052224/guia-alial-v1-0
Timestamp: 2020-08-05 23:01:43+00:00

Document:
guia_alial_v1.0 | Software libre | Software
guardarGuardar guia_alial_v1.0 para más tarde
Expo-3-1
Guía ALIAL
Buenas Prácticas Para la Licitación
De Desarrollos Libres Por Parte De
Guía ALIAL de Buenas Prácticas para la licitación de desarrollos libres por parte de las
Administraciones Locales Versión 1.0
Guía ALIAL de Buenas Prácticas Para la Licitación De Desarrollos Libres Por Parte De Administraciones Locales (Versión 1.0)
La Guía ALIAL es un trabajo del proyecto ALIAL, desarrollado por ASOLIF en colaboración con CENATIC.
Copyright © 2010 ASOLIF y CENATIC
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later ver- sion published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of this license is included in the section entitled “GNU Free Documentation License”
Se concede permiso para copiar, distribuir y/o modificar este documento bajo los términos de la Licencia de Documentación Libre de GNU Versión 1.3 o cualquier otra versión posterior publicada por la Free Software Foundation ; sin Secciones Invariantes, textos de Cubierta Delantera ni textos de Cubierta Trasera. Una copia de la licencia está incluida en la sección titulada “GNU Free Documen- tation License”.
0 Índice general del documento
CONSIDERACIONES PREVIAS A
LA GUÍA ALIAL
1.1. Antecedentes y Justificación 5
1.2. Objetivo de la Guía ALIAL
1.3. Consideraciones Generales de la
Guía ALIAL (Aplicables a los Pliegos)
LA GUÍA ALIAL DE BUENAS
PRÁCTICAS PARA LA LICITACIÓN DE DESARROLLOS LIBRES POR PARTE DE AA.PP. LOCALES
2.3. Acatamiento de las condiciones
2.5. Presupuesto
2.7. Plazo de entrega
2.8. Penalizaciones
2.9. Prórroga
Especificaciones Funcionales 51
El presente documento se divide en tres grandes apartados:
1 Consideraciones previas a la Guía ALIAL de Buenas Prácticas.
2 Guía ALIAL de Buenas Prácticas.
3 Licencia aplicada a todo el documento (como Anexo).
2. OBJETIVO DE LA GUÍA ALIAL
3. CONSIDERACIONES GENERALES DE LA GUÍA ALIAL
(APLICABLES A LOS PLIEGOS)
3.2. Consideraciones Legales Relacionadas con la Guía ALIAL
3.3. Consideraciones Funcionales Relacionadas con la Guía ALIAL
3.4. Consideraciones Sobre Procedimientos y Metodologías Relacionadas con la
3.5. Consideraciones Sobre el Plan de Trabajo que Afectan a la Guía ALIAL
3.6. Consideraciones Técnicas Relacionadas con la Guía ALIAL
3.7. Consideraciones Organizativas Relacionadas con la Guía ALIAL
3.8. Consideraciones Económicas Relacionadas con la Guía ALIAL
3.9. Consideraciones Sobre los Criterios de Evaluación de la Guía ALIAL
3.9.1. Criterio: Valoración Económica de la Oferta
3.9.2. Criterio: Propuesta de Ejecución del Proyecto
3.9.3. Criterio: Reducción del Plazo de Ejecución del Proyecto
3.9.4. Criterio: Solvencia Económica/Financiera
3.9.5. Criterio: Solvencia Técnica
3.9.6. Criterio: Mejoras Propuestas
3.10. Otras consideraciones
Buena parte de las Administraciones Locales que pretenden incorporar aplicaciones libres tienen dificultades a la hora de elaborar pliegos específicos para licitaciones de desarrollos que incorporen las nuevas condiciones que es- tos proyectos requieren. El hecho de que el proyecto ALIAL pretenda que estas aplicaciones se desarrollen de manera abierta, con metodologías y herramientas propias del movimiento del Software Libre, aumenta el nivel de complejidad de las condiciones a establecer en los pliegos de contratación. Además, son escasos los ejemplos disponibles sobre los que basarse para su redacción.
Existen particularidades referidas a este tipo de software que deben ser tenidas en cuenta y que no lo eran anteriormente, en licitaciones de software privativo. Esto se debía a causas diversas, pero en general, todas derivan de tres principales:
1. El cliente no podía acceder al código fuente del programa.
2. El proveedor o el fabricante imponía la licencia (condiciones de uso y explotación), es decir, primaba sus intereses comer- ciales frente a los del cliente, que en el caso de las AA.PP., no son otros que el interés público.
3. El desarrollo era cerrado.
La independencia que permite el Software Libre a la Administración Pública en general, y a las Corporaciones Locales en particular, no puede ser debidamente explotada si no se dispone de los conocimientos necesarios. Muy al
Consideraciones Previas a la Guía ALIAL
contrario, dicha falta de experiencia previa puede generar frustraciones iniciales contraproducentes.
Es por ello que, en esta primera fase, el Proyecto ALIAL pretende aportar a las Administraciones Locales algunos instrumentos que les ayuden en la incorpo- ración de aplicaciones libres.
La Guía ALIAL de Buenas Prácticas para la Licitación de Desarrol- los Libres por parte de las Administración Locales, en adelante Guía ALIAL, representa el primero de un conjunto de pasos esenciales dentro de la estrategia global que plantea el proyecto ALIAL.
Una de las principales barreras iniciales para la adopción de Software Libre por parte de las Administraciones Locales es la necesidad de definir las condicio- nes generales que deben cumplir los proveedores a la hora de desarrollar solu- ciones para ellos. Así, este primer entregable del proyecto ALIAL, La Guía ALIAL, pretende disminuir esa barrera aportando información sobre pliegos de licitación, que incluye las condiciones adecuados para favorecer la oferta de desarrollos libres por parte del sector TIC.
Dado que el proyecto ALIAL pretende que estos nuevos desarrollos se realicen de manera abierta y siguiendo las metodologías que han hecho posibles la aparición y expansión de proyectos de comunidad en torno al Software Libre, se determinó que era necesario un documento como este, que pueda ser utilizado por los Ayuntamientos como referencia a la hora de licitar desarrollos internos, y para servicio a ciudadanos, basados en Software Libre.
Para más información sobre todos los aspectos definidos hasta la fecha por el proyecto ALIAL, consulte la web: http://www.alial.es
Con el fin de que las Administraciones Locales puedan desarrollar pliegos de licitación de aplicaciones libres, desarrolladas con metodologías y procedi- mientos habituales en los proyectos de comunidad, siguiendo estándares abiertos y resultando interoperables entre sí, ASOLIF, con la colaboración de CENATIC, en el marco de un acuerdo de colaboración, ha desarrollado la primera versión de esta Guía ALIAL, con recomendaciones útiles que abarcan ámbitos muy diversos.
Esta Guía tiene, como es lógico, los mismos objetivos que el proyecto en general, además de algunos específicos que se enumeran a continuación:
• Asegurar condiciones mínimas en los pliegos que permitan que aquellos desarrollos que se pretende sean libres y desarrollados en abierto, no puedan desviarse de los objetivos marcados en sus apartados fundamentales.
• Establecer una línea clara a los proveedores con el fin de fomen- tar el retorno a la sociedad de la inversión pública en desarrollo de aplicaciones informáticas.
• Que dicho retorno sea útil para otras AA.PP. y empresas.
• Que las condiciones impuestas sean asumibles por cualquier em- presa, primando criterios integradores frente a los excluyentes.
• Asegurar el cumplimiento de la normativa nacional y europea en torno al uso y promoción de estándares abiertos y formatos libres, como único camino hacia la interoperabilidad real de las soluciones informáticas.
En resumen, la Guía ALIAL pretende servir de apoyo a los técnicos de los Ayuntamientos de menor tamaño en su tarea de adaptar sus pliegos a las nuevas normativas, directivas y recomendaciones en materias como interoperabilidad, uso de estándares abiertos, seguridad, y promoción de Software Libre, entre otras.
Por otro lado, esta Guía define algunas condiciones necesarias para fa- vorecer que los proveedores de los Ayuntamientos puedan interactuar con más empresas que proveen a otras Corporaciones de un modo transparente, com- partiendo la tecnología en un marco claro y público, en el que no se promocione el establecimiento de trabas técnicas ni comerciales encaminadas a reducir las posibilidades de los clientes a la hora de elegir proveedor.
Otro de los objetivos de la Guía es que esas condiciones puedan ser asu- mibles por cualquier empresa y Corporación, es decir, que se abra el abanico de empresas que pueden proveer de servicios y productos a los Ayuntamientos a través de modelos colaborativos.
Esta Guía de Buenas Prácticas, tiene sentido por sí misma, sin necesi- dad de que el Ayuntamiento esté de acuerdo o se adhiera cualquiera de los pre- ceptos, recomendaciones o condiciones del proyecto ALIAL. Se trata por tanto de un documento que, aunque enmarcado dentro de una estrategia global, tiene vida propia, más allá del resto de entregables que se irán publicando durante los próxi- mos meses. Prueba de ello es la licencia con la que se publica, que, en esencia, permite (y fomenta) su copia, modificación y distribución.
3. Consideraciones Generales de la Guía ALIAL (Aplicables a los Pliegos)
El presente documento se divide en dos partes principales:
1. Consideraciones Generales a la Guía ALIAL, relacionadas con la licitación de desarrollos libres
2. Descripción punto por punto de las recomendaciones que realiza el proyecto ALIAL a las Corporaciones Locales para cualquier pliego de desarrollo de Software Libre.
Existe un tercer punto que es la licencia del documento, que se presenta como anexo.
Cada parte irá siendo depurada conforme avance el proyecto, en espe- cial, a medida que los Ayuntamientos vayan aportando su experiencia conforme avancen las diferentes fases de ALIAL. Con el fin de atender sugerencias, se han establecidos dos canales básicos de comunicación:
• Correo electrónico: contacto@asolif.es
• Formulario de la web: http://www.alial.es/unete/
La Guía ALIAL no hace referencia a:
• Cláusulas administrativas.
• Procedimiento de distribución de la información en sobres.
• Formato exacto que debe tener la oferta de cada empresa.
Este documento realiza una breve descripción el contenido de los diferen- tes apartados, de modo que cada Corporación pueda adaptarlos a su formato habitual si lo estima oportuno. Sí que se advierte en diversos puntos, que una homogeneización de los pliegos (y a ser posible de los formatos de las ofertas) es deseable. Esto suele facilitar las tareas de redacción y posterior evaluación, así como el análisis de los pliegos por parte de otras Administraciones y proveedores.
3.2. consIderacIones LegaLes reLacIonadas con
En el pasado, a menudo eran los fabricantes de software quiénes deter- minaban las condiciones de uso, distribución y comercialización del software, que venía detallado en licencias complejas. El Software Libre permite a los Ayunta- mientos establecer sus propias políticas en estos apartados, que deben traducirse en un licenciamiento acomodado a ellas.
La Guía ALIAL simplifica este tipo de decisiones basándose en la experiencia que atesoran las empresas de ASOLIF y CENATIC, de modo que, respetando la libertad de los Ayuntamientos en esta materia, ALIAL propone el uso de algunas de las licencias más extendidas dentro del Software Libre, aceptadas por el mer- cado y la legislación vigente. Estas licencias aseguran posibilidad de copia, modi- ficación y distribución de las aplicaciones desarrolladas.
Además del código, la documentación y los grafismos deben ser objeto de licenciamiento con el fin de que puedan formar parte del proyecto al mismo nivel que el código. La Guía ALIAL realiza recomendaciones básicas que deben cumplir las licencias de estos apartados. Otro detalle relevante y a menudo ignorado, son las licencias de las herramientas utilizadas para el desarrollo de las aplicaciones, la documentación o el grafismo. En ocasiones imponen condiciones a la apli- cación resultante que deben ser analizadas por expertos.
Las soluciones libres a licitar por parte de Ayuntamientos u otras Adminis- traciones deben seguir, en general, los requisitos legales y recomendaciones definidas, entre otras, por:
• Ley 30/1992 de Régimen Jurídico de las Administraciones Públi- cas y Procedimiento Administrativo Común.
• Ley Orgánica 15/1999 de Protección de Datos de Carácter Per- sonal.
• Real Decreto 772/1999 por el que se regula la presentación de solicitudes, escritos y comunicaciones ante la Administración General del Estado, la expedición de copias de documentos y devolución de originales y el régimen de las oficinas de registro.
• Ley 34/2002 de Servicios de la Sociedad de la Información y de Comercio Electrónico.
• Real Decreto 209/2003 por el que se regulan los registros y las notificaciones telemáticas.
• Ley 59/2003 de Firma Electrónica.
• Orden PRE/1551/2003, por la que se desarrolla la Disposición final primera del Real Decreto 209/2003.
• Ley 11/2007 de Acceso Electrónico de los Ciudadanos a los Ser- vicios Públicos.
• Ley 37/2007 Reutilización de la información del Sector Público
• Ley 49/2007 por la que se establece el régimen de infracciones y sanciones en materia de igualdad de oportunidades, no discrimi- nación y accesibilidad universal de las personas con discapaci- dad.
• Ley 56/2007 de Medidas de Impulso de la Sociedad de la Infor- mación.
• Real Decreto 1494/2007 por el que se aprueba el Reglamento sobre las condiciones básicas para el acceso de las perso- nas con discapacidad a las tecnologías, productos y servicios relacionados con la sociedad de la información y medios de co- municación social.
• Real Decreto 1545/2007 del Sistema Cartográfico Nacional (BOE
30-11-2007)
• Real Decreto 1671/2009 por el que se desarrolla parcialmente la Ley 11/2007
• Orden FOM/956/2008 sobre la política de difusión de la IG en el IGN
• Real Decreto 3/2010, de 8 de enero (BOE de 29 de enero), por el que se regula el Esquema Nacional de Seguridad en el ámbito de la administración electrónica, y normativa técnica derivada.
• Real Decreto 4/2010, de 8 de enero (BOE de 29 de enero), por el que se regula el Esquema Nacional de Interoperabilidad en
el ámbito de la administración electrónica, y normativa técnica derivada.
Y el siguiente marco legal de la Unión Europea:
• Directive 2004/18/EC of the European Parliament that stablish the legal basis for procurement in the EU.
• Directive 2007/2/EC of the European Parliament and of the Coun- cil of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE)
• Reglamento (CE) no 1205/2008 de la Comisión de 3 de diciembre de 2008 por el que se ejecuta la Directiva 2007/2/CE del Parla- mento Europeo y del Consejo en lo que se refiere a los metada- tos
• Commission Decision of 5 June 2009 implementing Directive 2007/2/EC of the European Parliament and of the Council as re- gards monitoring and reporting
• Commission Regulation (EC) No 976/2009 of 19 October 2009 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards the Network Services
• European Directive 98/34/EC of standards and technical regula- tions
• European Interoperability Framework v1.0 (EIFv1.0):
• Guidelines of Procurement and Open Source Software (GPOSS):
http://www.osor.eu/idabc-studies/guidelines-for-public-adminis-
trations-on-procurement-and-open-source-software-2008-draft-
Existe legislación de carácter autonómico igualmente relevante que no se incluye en este listado, así como, en función del objeto del desarrollo, legislación adicional a tener en cuenta.
La presente Guía no establece las descripciones o recomendaciones que, desde el punto de vista funcional, estimamos que deben tenerse en cuanta en el apartado Descripción Funcional de cualquier pliego de desarrollo de software (en las condiciones del proyecto). Cada Ayuntamiento debe establecer sus propias necesidades, o personalizaciones de las necesidades generales de cualquier Cor- poración Local.
Tal como se establece en la Guideline on Public Procurement of Open Source Software (ver sección anterior) se recomienda realizar una definición lo más precisa posible, de una manera neutral y sin especificidades asociadas a vendedor o producto alguno, de los requerimientos funcionales de la solución a licitar.
Con el fin de ayudar en este apartado a los Ayuntamientos, el proyecto ALIAL publicará un segundo entregable, que incluye la descripción funcional de infinidad de módulos útiles para cualquier Ayuntamiento. Esta información, actual­ mente en diseño, servirá de base para completar este apartado del pliego en la mayoría de casos.
3.4. consIderacIones sobre ProcedImIentos y metodoLogías reLacIonadas con La guía aLIaL
El desarrollo de Software Libre bajo el paraguas ALIAL no sólo implica el uso de tecnologías diferentes al privativo, así como la asignación de diferentes licencias al trabajo desarrollado y herramientas, sino que propone procedimientos de desarrollo, gestión, comunicación y evolución del producto distintos, que apor- tan una serie de ventajas al cliente, al desarrollador, a su empresa y, en especial, a terceros. ALIAL pretende con esta Guía que se asegure, a través del pliego, que todas estas ventajas pueden ser plenamente explotadas por todas las partes, sobre todo, tras la finalización de su desarrollo.
Otro de los entregables del proyecto describirá estos procedimientos en diferentes ámbitos. Cualquier corporación podrá recomendar o imponer a sus proveedores el seguimiento de estos procedimientos y metodologías elaboradas por expertos en el desarrollo de aplicaciones libre desarrolladas de manera abier- ta, de modo que se facilite la posibilidad de incorporar soluciones licitados por otros Ayuntamientos a costes asumibles.
ALIAL, tal como se anuncia en la web del proyecto, definirá un Comité de Calidad encargado de la evaluación del cumplimiento de esas condiciones, lo que facilitará la colaboración entre empresas que debe desembocar en que cada módulo sea interoperable de serie con cualquier otro. La participación de este Comité será opcional. Sus resoluciones serán públicas.
Tras la publicación de la Guía ALIAL, se abrirá un proceso de depuración de la misma con las entidades que han mostrado interés en el proyecto, con el fin de adaptarla al máximo a sus necesidades.
Se recomienda que la metodología de desarrollo sea conocida con detalle y que los procedimientos de gestión sean análogos a los utilizados por las comuni- dades de desarrollo, que se han mostrado altamente eficaces en el cumplimiento de los objetivos del proyecto en entornos de alta complejidad. Una parte relevante del éxito de la iniciativa depende de que las aplicaciones sean interoperables e incluso integrables en mayor o menor medida a corto plazo.
Por estos y otros motivos, el proyecto ALIAL, basándose, entre otros facto- res, en la amplia experiencia de las empresas de ASOLIF, establecerá un conjunto de recomendaciones en futuros entregables en el apartado de procedimientos y metodologías de desarrollo.
En el pliego, la Corporación Local debe aportar los siguientes datos de con-
► Teléfono:
► Correo:
Separar el contacto administrativo del contacto técnico permite a la em- presa dirigirse a la Administración a dos niveles diferentes, lo que facilita la com- prensión del pliego. Esto requiere el conocimiento en profundidad del proyecto por parte de dos personas de perfil diferente, lo que no siempre es posible.
El equipo ALIAL pondrá a disposición del proyecto herramientas públicas que faciliten los procesos de diseño, ejecución, seguimiento y gestión de los dife- rentes desarrollos. Su uso estará sujeto al acuerdo entre el proyecto ALIAL y cada corporación.
La Guía ALIAL propone una organización del trabajo a desarrollar que se corresponden con simplificaciones de algunas de las más extendidas meto­ dologías en gestión de proyectos informáticos, especialmente de desarrollo de Software Libre. Dado que se pretende que diferentes proveedores desarrollen aplicaciones que interoperen con otras desarrolladas por terceros, una visión general común del Plan de Trabajo es positiva. Así, esta Guía realiza una serie de recomendaciones a este respecto, resultado del acuerdo de numerosas empresas del sector.
Se busca que la metodología a utilizar por cualquier proveedor sea compa-
tible con las que aplican buena parte de las empresas que desarrollan Software
Libre en todo el mundo. Se recomienda que el Plan de Trabajo sea estructurado
código de dos letras,
una mayúscula y otra
número de un dígito
código de una letra
Las fases principales de los desarrollos podrán ser las siguientes (y su co- rrespondiente código para la identificación):
Toma de datos y diseño del proyecto
Desarrollo de la aplicación y documentación asociada al desarrollo
Pruebas de calidad y testeos
Implantación de la aplicación en la Corporación Local
Soporte y mantenimiento de la aplicación implantada
Fase de garantía del producto
§ Tabla 0.1.10
El Pliego debe definir los principales Hitos de cada Fase, enumerando los diferentes entregables en cada caso, que pueden ser:
• Versiones instalables del software (según hoja de ruta o road- map)
◦ Versión Alfa
◦ Versión Beta
◦ Candidatos de lanzamiento (Release Candidates)
◦ Versión estable
• Documentación asociada al desarrollo
• Guías, manuales, informes y actas de certificación
3.6. consIderacIones técnIcas reLacIonadas con
Uno de los elementos necesarios para la correcta realización de cualquier proyecto es la disponibilidad de un inventario completo de la infraestructura téc- nica, servicios y aplicaciones del Ayuntamiento. Del mismo modo, es positivo disponer de información sobre el conocimiento informático previo de los traba- jadores y las tareas que desempeñan. Debe entenderse que estos datos estarán a disposición de la dirección del proyecto de manera previa a la realización de la aplicación. Se trata de un punto crítico en la fase de diseño y con alta incidencia en los costes globales del proyecto.
Se recomienda a los Ayuntamientos incluir en el programa de formación a todo su personal con cualificación técnica en informática, de modo que puedan aprender a evaluar y realizar modificaciones en los diferentes programas, con el fin de aumentar la independencia de la Corporación respecto del proveedor. Se recomienda también incluir a técnicos de empresas locales en este Plan.
A continuación se enumeran algunas normas que recomendamos seguir a la empresa a la hora de desarrollar el software, y que pueden añadirse al pliego. Estas recomendaciones serán ampliadas debidamente por el proyecto ALIAL en los futuros entregables:
SOBRE LA DOCUMENTACIÓN TÉCNICA
Î En la cabecera de cada clase o fichero que se cree, se incluirá un comentario de bloque con (en función de licencia aplicable):
• Nombre y breve descripción de la clase.
• Autor y fecha de creación.
Î En la definición de cada función se incluirá un comentario de bloque con:
• Nombre y descripción de la función.
• Parámetros de entrada y salida de la función.
Î En los fragmentos con funcionalidad compleja, se añadirán comen- tarios de línea con explicaciones del código utilizado.
Î Se desarrollarán documentos técnicos que jerárquicamente expli- quen las capas de desarrollo las capas de desarrollo:
SOBRE LA LEGIBILIDAD DEL CÓDIGO
Se pretende que el código se legible para otros desarrolladores, de modo pueda realizar pruebas y seguimiento (tracear por ejemplo) cualquier fracción del código.
Î Seguir las recomendaciones del proyecto ALIAL de estan- darización en cuanto a nombres, nombre a clases, funciones, constantes, variables, tablas, ficheros (ontología ALIAL que se desarrollará en futuros entregables).
SOBRE LA ESTRUCTURA LÓGICA DEL CÓDIGO
Se debe conseguir consistencia de datos, seguridad ante vulnerabilidades y optimización de los recursos del hardware.
SOBRE EL DESARROLLO DE LA APLICACIÓN POR CAPAS (EN FUN- CIÓN DE ARQUITECTURA)
Desarrollo por capas, mínimo tres. Cada capa debería ser independiente en la medida de lo posible.
• Modelo. Capa encargada de gestionar la base de datos.
• Controlador. Capa de negocio encargada de gestionar las peticiones entre la interfaz (vista) y la base de datos (mo- delo).
• Vista. Capa encargada de gestionar la interfaz que se uti- lizará.
Î En caso de que el proyecto necesite administración de usuarios de alto nivel (en tiempo de ejecución), separar el desarrollo del proyecto en:
• BackEnd (para la administración del servicio).
• FrontEnd (para el uso de la aplicación).
Î Preparar el código para evitar ataques externos. Como mínimo se debería estudiar las formas más comunes de ataque para la tecnología utilizada.
Î Creación y reutilización de clases y funciones en la medida de lo posible (para evitar código repetido).
Î Cuando sea posible, destruir o eliminar de la memoria las varia- bles y objetos que no se utilizarán más.
Î Llevar un correcto control de excepciones y si fuera posible un control de trazas para las funciones críticas. Este control de tra- zas puede crearse periódicamente (mensualmente)a través de un fichero LOG con las acciones críticas.
Î Preparar el código para que sea fácilmente actualizable, perso- nalizable y modulable.
Î Permitir el uso de plugins (teniendo en cuenta siempre la segu- ridad).
Î Permitir plantillas estéticas para la interfaz.
Existen otras muchas recomendaciones que se irán aportando conforme avance el proyecto.
El proyecto ALIAL establece que el desarrollo de las diferentes aplicaciones libres (módulos) que requiere cualquier Administración Local ( y que recordamos, serán descritas en futuros entregables), requiere de tres actores básicos y uno opcional:
• La Administración Local que licita el desarrollo del módulo y en la que se realizará la implantación, además de publicar el código.
• La Dirección de Proyecto, que se encargará de asegurar el estricto cumplimiento de las condiciones del proyecto, ase- gurándose de que evoluciona conforme a las expectativas de la administración Local, ayudando a la empresa adjudicataria a que así sea. Será quien ostente la responsabilidad máxima en el desarrollo del proyecto.
• La empresa adjudicataria, que se encargará de desarrollar e implantar la solución licitada.
• Comité de Calidad ALIAL (opcional), formado por expertos en las tecnologías y metodologías relacionadas con el proyecto, designados por los actores del proyecto, cuya función es asegu- rar que el trabajo desarrollado en cada fase definida en el Plan de Trabajo cumple con las condiciones establecidas por el proyecto ALIAL. Su tarea es de asesoría y control de calidad. Su ámbito de actuación será definido previo acuerdo entre Ayuntamiento y el propio Proyecto ALIAL y será plasmado en el pliego de condi- ciones (esta relación se establecerá a través del Convenio ALIAL, uno de los próximos entregables).
El pliego deberá incluir las condiciones que rigen la relación entre los tres actores implicados, en especial, aquellas que afectan al adjudicatario. Éste, a su vez, deberá describir en la oferta la organización de su equipo así las relaciones entre las diferentes unidades organizativas, con especial atención a aquellas que tendrán relación con el resto de actores.
Si en cualquiera de las etapas del proyecto están implicadas terceras entidades o proveedores, será el Ayuntamiento quien facilite las tareas de coordi- nación y comunicación con ellos a la Dirección del Proyecto. Estos procedimientos básicos de comunicación deben formar parte del pliego, así como los ámbitos de responsabilidad y los procedimientos de gestión de posibles conflictos con ellos.
Recomendamos por tanto establecer en el documento las condiciones generales de modo que las ofertas realizadas por las empresas se centren en desarrollar dichas tareas con terceros, no en definirlas. Este apartado es crítico a menudo para el cumplimiento de los plazos previstos en el proyecto y, por tanto, para el control de costes.
Con el fin de facilitar las labores de control de procedimientos, meto­ dologías, calidad y, sobre todo, coordinación con otros proveedores que desarro- llen aplicaciones dentro del marco del proyecto ALIAL, se publicará próximamente la definición, características, ámbito de actuación, composición, etc. del comité de expertos, denominado Comité ALIAL de Calidad, que se pondrá a disposición de los Ayuntamientos. En caso de no existir este Comité ALIAL, será la dirección del proyecto quien ejerza funciones de control de calidad.
La información sobre éste y otros aspectos del proyecto será publicada en la web: http://www.alial.es
Uno de los principales y más complejos objetivos del proyecto ALIAL es la reducción de costes de desarrollo, implantación y mantenimiento de las aplicacio- nes libres necesarias para cualquier Administración Local.
A menudo, algunos de estos objetivos resultan incompatibles entre sí, por lo que debe buscarse un compromiso entre ellos. Para la reducción de costes de implantación y mantenimiento, es imprescindible que la solución sea altamente modular, siga estándares abiertos y utilice formatos libres a todos los niveles, esté debidamente documentada, use licencias libres y sea desarrollada en abierto con herramientas también libres.
El pliego establece algunas condiciones que persiguen este objetivo, siem- pre que sea posible. Cuando no lo sea, se debe solicitar en la oferta una justi- ficación a tal circunstancia, de modo que pueda identificarse rápidamente una alternativa.
Desde el punto de vista económico, el coste de un desarrollo debe tener en cuenta tres conceptos diferentes:
1. Dirección de proyecto, que corresponderá para la empresa designada por el Ayuntamiento para el desarrollo de esta tarea (puede ser el adjudicatario, si bien no es recomendable). Se establecerá en un pliego o contrato independiente si se pretende asignar a una empresa distinta de la que desarro- llará la aplicación.
2. Ejecución, que será asignada a la empresa adjudicataria a través del pliego correspondiente.
3. Control de Calidad, que será asignada a la Dirección de Proyecto o a una entidad externa (lo ideal).
El pliego establece recomendaciones sobre cómo realizar los pagos, qué porcentajes de los mismo pueden realizarse en relación con el Plan de Trabajo y las penalizaciones en caso de incumplimientos. Esta Guía no establece los costes recomendados asociados a cada desarrollo.
Cada uno de los módulos que se desarrolle con éxito, podrá ser implantado en otras Corporaciones Locales. Es por tanto relevante medir los tiempos y costes
de cada fase de proyecto. Estos costes deben tender a reducirse a medida que el proyecto madure, si bien, dependerá de la situación previa de cada Corporación.
En todo caso, esta es una condición imprescindible para ayudar a otras En- tidades, y por tanto, ayudarse a sí misma. Se recomienda por tanto hacer hincapié en el pliego en la medición y suministro de datos económicos que permitan reali- zar un análisis de estos costes, para su posterior publicación.
Finalmente, se recomienda seguir las recomendaciones que realiza la Unión Europea en materia de licitación de Software Libre, establecidas en el documento Guideline on Public Procurement of Open Source Software (pag. 37) que establece que los criterios de sostenibilidad financiera requeridos a las em- presas deben ser proporcionales al ámbito del proyecto. El principal criterio para al imposición de condiciones financieras es asegurar que la empresa podrá dar soporte y mantenimiento durante el periodo de uso del desarrollo.
Debe tenerse en cuenta que, con Software Libre, este argumento debe ser modificado puesto que, una vez terminado el período de soporte y mantenimiento, cualquier empresa podrá asegurar la perdurabilidad en el uso de la aplicación. En el caso del proyecto ALIAL, esto será más cierto puesto que será publicado el código fuente de todos los desarrollos.
ALIAL recomienda que las aplicaciones necesarias por cualquier Ayunta- miento de pequeño tamaño se compartimenten en módulos simples, de manera que su desarrollo no sea complejo. De este modo el coste del mismo se verá también reducido y estará al alcance de cualquier Corporación. Las condiciones de solvencia económica que debe cumplir la empresa para desarrollarlo serán también menores, lo que aumentará la oferta y disminuirá los riesgos así como la carga de gestión.
Uno de los objetivos del proyecto ALIAL es aumentar tremendamente, como ya se ha dicho, el número de posibles proveedores de los Ayuntamientos, en es- pecial, de los pequeños. Desarrollando las aplicaciones de manera abierta y con licencias libres, las pequeñas empresas de informática de todos los rincones del país podrán acceder al código, a la documentación y a buena parte de la experien- cia resultado del desarrollo de cada solución.
Podrán así convertirse en proveedores de servicios de esos Ayuntamientos de varias maneras:
• Integrando sus soluciones con las desarrolladas para el proyecto ALIAL
• Aportando valor añadido a los Ayuntamientos sobre las herramien- tas ya desarrolladas (soporte y mantenimiento, personalizaciones, arreglo de fallos, migraciones, integraciones, formación, etc)
• Convirtiéndose en desarrolladores de los módulos del catálogo, acudiendo a los concursos junto a otras empresas más expertas, en condiciones de igual a igual, puesto que la tecnología es trans- parente para todas las partes.
Para asegurar que este nuevo ecosistema puede desarrollarse, deben establecerse unas reglas de juego justas, claras e iguales para todos, basándose en criterios de excelencia y no en la exclusividad en el acceso a la información o el código. Uno de los puntos relevantes para alcanzar este objetivo es la valoración de las ofertas (criterios).
La Guía ALIAL no hace referencia a criterios de admisión de índole adminis- trativo. No obstante, dada la magnitud (reducida) e importe (reducido) de los desa- rrollos previstos (al menos aquellos que se preparan en el Proyecto ALIAL), así como el perfil de empresas al que va dirigido el proyecto (PyMEs), recomendamos adecuar las garantías financieras solicitadas, así como los requisitos administrati- vos imperativos para la consideración de la oferta, al perfil de las empresas espe- radas.
A continuación se realizan referencias sobre los principales criterios de evaluación que plantea la Guía ALIAL:
• Valoración Económica de la oferta.
• Propuesta de ejecución del Proyecto
• Reducción del Plazo de Ejecución del Proyecto
• Solvencia Económica/Financiera
• Solvencia Técnica
• Mejoras Propuestas
El peso recomendado de cada uno de los criterios se determina en la pro- puesta de pliego de condiciones.
El hecho de que cada solución desarrollada pueda ser compartida, con- vierte en recomendable que la calidad de las aplicaciones sea alta. Si a esto sumamos el hecho de que las empresas que pretendemos opten al desarrollo de estos módulos, son de pequeño tamaño, fomentar reducciones drásticas de pre- supuesto en la oferta no es una política adecuada. Se debe promover la máxima calidad en el desarrollo de las soluciones que serán reutilizadas, de modo que sea posible construir adaptaciones sobre ellas e integrarlas con otras.
La valoración económica de las propuestas de mejora, aún cuando van incluidas en el máximo del presupuesto de la licitación, recomendamos que sean valoradas económicamente de manera individual. Esto permitirá evaluar adecua- damente su calidad e impacto.
Recomendamos definir las aplicaciones como módulos de reducido tamaño y coste, de modo que la totalidad de los desarrollos sean abordables desde un punto de vista económico por Administraciones Locales y empresas de pequeña dimensión. Esta política nos parece más acertada que la promoción de grandes soluciones monolíticas.
3.9.2.1.ProPuesta tecnológica
La propuesta tecnológica tendrá que ver con las soluciones técnicas que se aporten a las condiciones planteadas por el proyecto, las tecnologías utilizadas y las herramientas a emplear. Se evaluarán favorablemente aquellas soluciones que tiendan a facilitar la interoperabilidad con otros desarrollos ALIAL, que reduz- can los costes de implantación, favorezcan el mantenimiento y perdurabilidad del software así como su legibilidad. Otros criterios como el rendimiento, la modulari- dad, la usabilidad o la accesibilidad serán también establecidos como criterios de evaluación.
Las herramientas deberán, lógicamente, cumplir los requisitos establecidos de licenciamiento. La publicación de los futuros entregables del proyecto ALIAL contribuirá notablemente a establecer criterios objetivos claros y comunes dentro de este apartado.
3.9.2.2.Metodología de desarrollo y estandarización
Dada la naturaleza del proyecto ALIAL, este apartado cobra una gran importancia, puesto que el desarrollo será realizado de manera abierta con el fin de que pueda ser evaluado y utilizado por terceros. Se evaluarán favorablemente aquellas metodologías, herramientas, soluciones y medidas que:
• Cumplan con estándares abiertos
• Utilicen formatos abiertos y libres.
• Sigan recomendaciones o acuerdos orientados a la estan- darización seguidos o recomendados por proyectos relevantes de Software Libre.
• Promuevan la interoperabilidad a todos los niveles.
3.9.2.3.organización y gestión
ALIAL recomienda que la experiencia en organización y gestión en proyec- tos libres, sean de comunidad o de carácter comercial, debe tener un impacto alto a la hora de asignar una valoración positiva en este apartado. Dado que la
participación en el proyecto está abierta a cualquier empresa, estamos ante una oportunidad importante para quiénes no disponen de experiencia previa en este apartado, de adquirirla a través de ALIAL.
3.9.2.4.soPorte y ManteniMiento
El hecho de que la empresa ofertante tenga como ámbito de actuación presencial el Municipio o la provincia donde se encuentra el Ayuntamiento es un criterio de interés a la hora de dar soporte y mantenimiento presencial. Dado que el software se desarrollará en abierto y con licencias libres, no existen impedi- mentos a priori para que una empresa local pueda aportar este servicio, en una primera fase o posteriormente. Establecer criterios objetivos que primen el soporte presencial directo cuando sea necesario, puede favorecer el desarrollo local de empresas, uno de los objetivos del proyecto ALIAL.
La experiencia en la realización de servicios de soporte y mantenimiento de aplicaciones libres de desarrollo en comunidad facilitará la interacción de esta empresas con otras del proyecto, por lo que recomendamos sea un criterio a con- siderar en este apartado.
Cada uno de los desarrollos del proyecto ALIAL debe considerarse como una parte de un todo. Desde el punto de vista de terceros desarrollos relaciona- dos con el objeto del pliego, lo importante es que la planificación se cumpla, esto es, que no sufra adelantos ni retrasos. Promocionar reducciones de plazos en la planificación previa tiene un impacto negativo en un contexto global, además de promover planificaciones laxas en las tareas previas a la publicación del pliego, que se traducen en el mismo. Debe tenderse a realizar un análisis y diseño previo ajustado a la realidad.
Esto se logra con la reducción al mínimo en los criterios de evaluación del peso asignado a las posibles reducciones sobre el plazo previsto, que se pretende sea siempre muy realista y, por tanto, ajustado en la descripción de las condicio- nes presentes en cada pliego.
Este apartado suele formar parte de las condiciones impuestas dentro de las cláusulas administrativas. En la presente Guía se incluye como un criterio de evaluación frente a un criterio previo a la valoración del resto de la oferta. Te - niendo en cuenta las recomendaciones aportadas sobre la reducción del tamaño de las aplicaciones a desarrollar así como su modularización, como elementos básicos para una necesaria reducción de costes, la flexibilización de los criterios de solvencia económica, atendiendo en todo caso a lo que establece la legislación vigente a este respecto, es posible.
Más aún, si lo que se pretende es aumentar la oferta de posibles empresas que puedan apostar por el desarrollo de estas aplicaciones, la flexibilización de las condiciones de solvencia económica son deseables, en especial, en la coyun- tura actual, en la que AA.PP. y empresas no desean asumir costes financieros y administrativos innecesarios, muy por encima del riesgo que se asume en la contratación.
La Guía ALIAL realiza recomendaciones sobre las condiciones de solven- cia económica a exigir a las empresas, en función del riesgo que se asume con la adjudicación de un desarrollo para una Corporación de pequeño tamaño.
La solvencia técnica se mide en dos apartados fundamentales:
• La experiencia de la empresa, en especial, en trabajos similares al ofertado.
• La experiencia del equipo que va a desarrollar el proyecto y el ajuste de sus perfiles a las necesidades planteadas.
La Guía ALIAL propone una serie de tablas con el fin de homogeneizar una evaluación preliminar. Teniendo en cuenta que estamos ante un ámbito novedoso, será necesario disponer de los CV de los miembros del equipo técnico así como de las empresas que se presentan. Debe establecerse un límite en cuanto a la extensión de estos CV con el fin de asegurar que sólo aparecen aquellos datos relevantes para la evaluación de apartados relacionados directamente con el proyecto.
Existen dentro del mundo del Software Libre, tanto para profesionales como para empresas, algunas certificaciones válidas que deben ser tenidas en cuenta, si bien, la popularidad dentro de este sector de las mismas es muy inferior a otros ámbitos, puesto que la experiencia y conocimiento son claramente valida- bles sin necesidad de la intervención de fabricantes. Esto es así puesto que el trabajo trabajo desarrollado es, en muchos casos, totalmente público y, por tanto, evaluable.
3.9.5.1.la exPeriencia de la eMPresa
Además de los criterios tradicionales de evaluación de las empresas, la ex- periencia de las empresas en desarrollos libres y/o abiertos, sean propios, lidera- dos por otras empresas o por comunidades de desarrollo, representan nuevos criterios que deben debidamente considerados. Dentro del sector del Software Libre, y dada su especial naturaleza, las referencias públicas de éxito obtenidas por las empresas permiten una evaluación clara de su grado de madurez y cono- cimiento.
Así, las referencias dentro de proyectos liberados de comunidad y corpora- tivos son tan válidas como las de cualquier cliente, con el añadido de que el nivel de exposición es muy alto y la posibilidad de evaluar su calidad, también.
3.9.5.2.la exPeriencia del equiPo de trabajo
Al igual que en el apartado anterior, existen nuevos criterios claramente identificables y que deben ser también tenidos en cuenta a la hora de evaluar la idoneidad de un profesional. La experiencia previa en proyectos de Software Libre abiertos, su pertenencia a una comunidad de desarrollo, el rol que desempeña en ésta o sus contribuciones son elementos que pueden identificar sin género de du- das conocimiento en las metodologías y herramientas que se pretenden en ALIAL, además de experiencia y conocimiento en una tecnología, herramienta, lenguaje o tipo de proyecto concreto. Estamos por tanto ante unos indicadores fiables tan válidos como cualquier otro y en algunos casos, incluso más.
Todos estos nuevos indicadores pueden ser indicados en las ofertas por las empresas y comprobados por los evaluadores. Se trata por tanto, de un elemento nuevo y positivo para una evaluación fiable de la solvencia técnica de un equipo de trabajo.
ALIAL recomienda evaluar positivamente todas aquellas mejoras en- caminadas a adoptar procedimientos, metodologías y herramientas propias del Software Libre, además de aquellas encaminadas a mejorar la interoperabilidad mediante la adopción de estándares abiertos y el uso de formatos libres. Aque- llas medidas orientadas a preparar los productos para su internacionalización así como otras medidas tractoras deben ser también bienvenidas.
Teniendo en cuenta que estamos ante un proyecto novedoso y no exento de cierto riesgo, aquellas medidas encaminadas a aumentar el nivel de cono- cimiento y/o adopción por parte de otras empresas proveedoras de modelos pro- pios del desarrollo en comunidades abiertas, son positivas. Esto fomentará que estas y otras empresas tengan la posibilidad de desarrollar las futuras versiones de sus productos de modo que interoperen o se integren con aquellas desarrolla- das dentro del ámbito del proyecto ALIAL.
Consideraciones Relacionadas con la Disponibilidad de Información Previa Necesaria.
Si la Administración Local tiene en marcha proyectos que pueden afectar al desarrollo solicitado en el pliego o dispone de un plan para la implantación de soluciones futuras, que va tener lugar durante el período de desarrollo o implan- tación del proyecto, o inmediatamente despues, es necesario que se informe debidamente a las empresas a través del pliego, con el fin de que puedan diseñar su oferta conociendo el impacto de estos proyectos.
Del mismo modo, si la Corporación dispone de una planificación tecnológi- ca o de otra índole, que afectan al proyecto durante la fase de soporte y man- tenimiento, o más allá, será positivo para todas las partes que se transfiera a las empresas la máxima información posible con antelación. Se trata de evitar inne- cesarios cambios una vez desarrollado el módulo.
Tan importante como la pública disponibilidad del código, es la disponibi- lidad de la información asociada a los diferentes procesos complementarios al desarrollo del proyecto. Es positivo que el conocimiento derivado de todos ellos (implantación, soporte y mantenimiento, etc.) sea puesto a disposición del proyec- to ALIAL, que lo hará público con licencias libres. También puede realizar esta tarea el propio Ayuntamiento si dispone de conocimientos para ello.
El objetivo es que otras corporaciones y proveedores lo conozcan y puedan incorporar la información o sus conclusiones a sus propios desarrollos, de modo que reduzca el nivel de dificultad y costes de sucesivas implantaciones y modifica- ciones. Por otro lado, generará un conocimiento colectivo derivado de gran valor para el proyecto y sus actores. Esta disponibilidad no debe realizarse al final del proyecto, sino a medida que se va desarrollando el mismo (desarrollo abierto).
En cualquier caso, siguiendo el criterio general, la elección de las empre- sas proveedoras, y por tanto los criterios de evaluación, deben centrarse en la obtención de un código de calidad, que sea interoperable, altamente modular, con un alto nivel de sencillez y bien documentado. En esta primera etapa del proyecto, estos factores son tan relevantes (o más) que la disposición de un gran número de funcionalidades en cada módulo.
La Guía ALIAL pretende ser un instrumento útil para Ayuntamientos de modo que les permita licitar aplicaciones basadas en Software Libre, desarrolla- das de manera abierta, siguiendo una serie de pautas y condiciones que facili- tarán enormemente las tareas de ejecución y control del proyecto a todas las partes.
Se trata del primer entregable del Proyecto ALIAL y se ha planteado como un documento vivo, publicado por tanto con una licencia libre (FDL), y que está respaldado por la experiencia acumulada por el sector de las PyMEs del Software Libre españolas. No obstante, esta Guía se plantea como un documento con sentido propio, independiente del resto del proyecto. Para sacar partido del docu- mento, no es necesario, por tanto, involucrarse en el proyecto ALIAL.
Esta Guía no pretende establecer el formato ni contenido exacto de pliego alguno. Se trata de un conjunto de recomendaciones que deben ser sometidas al juicio de las Corporaciones Locales interesadas en realizar desarrollos libres de manera abierta.
Estas condiciones imponen el uso de estándares abiertos y formatos libres como único camino conocido hacia una interoperabilidad real entre diferentes soluciones desarrolladas por proveedores diferentes, independientemente de que sean impulsados por uno varios Ayuntamientos. Este camino queda debidamente trazado por las directivas europeas y la propia legislación española.
La Guía ALIAL es, además una clara declaración de intenciones sobre los siguientes pasos que va a adoptar el proyecto, y que se resumen en los siguien- tes conceptos:
• Licencias Libres.
• Desarrollos abiertos.
• Estándares abiertos y formatos Libres: Interoperabilidad.
• Independencia del proveedor por parte del cliente.
• Impulso del mercado local favoreciendo la aparición de más fabricantes de Software.
• Trabajo colaborativo mediante la compartición de la tec- nología.
• Libre competencia basada en reglas asumibles por cualquier empresa.
• Retorno de la inversión pública a la sociedad de modo útil y eficiente.
La Guía ALIAL de Buenas Prácticas para la Licitación de Desarrollos Libres por parte de AA.PP. Locales
3. ACATAMIENTO DE LAS CONDICIONES DEL PLIEGO
9. PRÓRROGA
11. DESCRIPCIÓN GENERAL DE LA SOLUCIÓN
12. ESPECIFICACIONES FUNCIONALES
14. ESPECIFICACIONES LEGALES
14.1. Licencias del programa
16. IMPLANTACIÓN
17.1. Consideraciones Generales Sobre la Documentación
17.2. Guías y Manuales
17.2.1. Manual de Usuario
17.2.2. Manual de Instalación e Implantación
17.2.3. Guía de Análisis y Diseño
17.2.4. Guía de Desarrollo
17.2.5. Guía de Pruebas
17.2.6. Guía de Soporte y Mantenimiento
17.3. Informes y Certificaciones
17.4. Memoria del Proyecto
17.4.1. Actas de Reuniones
17.4.2. Informe de Soporte
17.4.3. Actas de Finalización de Hito/Fase/Proyecto
18. PLAN DE TRABAJO
19. ENTREGABLES
20. EQUIPO DE TRABAJO
20.1. Roles
20.2. Formación y Experiencia del Equipo de Trabajo
22. GESTIÓN DEL PROYECTO
22.1. Metodología de Desarrollo
23. CALIDAD Y SEGURIDAD
23.1. Calidad de los Procesos
23.2. Calidad del
23.3. Seguridad
24. SOLVENCIA ECONÓMICA
25. SOLVENCIA TÉCNICA
A continuación se describen los apartados que, al menos, debería incluir un pliego de cualquiera de los módulos libres, desarrollados a modo de comunidad abierta, para cualquier Administración Local. En cada apartado se enumeran recomenda- ciones sobre el contenido a desarrollar o, en algunos casos, el contenido mismo.
Cualquier consideración a consecuencia del presente documento o del proyecto en general, puede ser realizada a través del formulario que figura en la web de ALIAL: http://www.alial.es/unete/
Guía ALIAL de Buenas Prácticas para la licitación de desarrollos libres por parte de las Administraciones Locales Versión 1.0
Esta sección debe describir el estado actual de la Administración Local en lo que respecta a:
• La aplicación que se pretende desarrollar.
• Otras cuestiones relevantes sobre servicios digitales internos y externos, así como otros proyectos que puedan ser de interés para el posible proveedor.
• Política del Ayto. respecto al Software Libre en general, al apoyo al proyecto ALIAL u otros acuerdos disponibles en materia de Software Libre que sean relevantes para la Corporación.
• Tienen cabida en este apartado las posibles directrices europeas, nacionales o autonómicas en materia de interoperabilidad, es- tándares abiertos y Software Libre que el Ayuntamiento estime deben ser conocidas por los posibles proveedores. No debe ignorarse la facultad pedagógica de los pliegos de licitación entre empresas noveles o con escasa experiencia en estos apartados.
La empresa debe aportar el contacto del Director o coordinador de los tra- bajos así como del responsable técnico:
Contacto Responsable Técnico:
► Empresa:
La dirección y el contacto general de la empresa es recomendable que se incluya también.
La oferta deberá incluir una declaración expresa del acatamiento de las condiciones del pliego por parte del representante legal de la empresa.
Además de la información habitual en este apartado, el objeto del pliego debe incluir una referencia clara a que la aplicación a desarrollar, no sólo debe realizarse con Software Libre, sino que será desarrollada de modo abierto, será multiplatafoma, cumplirá estándares abiertos, utilizará únicamente formatos libres y criterios básicos orientados a favorecer la interoperabilidad con soluciones de terceros, y en especial, con otras aplicaciones desarrolladas en el seno del proyecto ALIAL.
La única particularidad que debe reflejarse en el apartado presupuestario, son los costes, si los hubiere, de las licencias de software necesarias para el desarrollo de la aplicación, los posibles costes derivados del uso de patentes o módulos orientados a comunicar o interoperar con otras aplicaciones, además de las posibles restricciones de explotación. Estos costes tienen únicamente sentido en el caso de que las aplicaciones deban interactuar inexorablemente con aplica- ciones privativas.
En general, estos costes deben soportarlos las empresas que desarrollan software privativo o aquellas que, utilizando Software Libre, no entregan el có- digo fuente a las Corporaciones Locales, puesto que son gastos derivados de sus modelos de negocio. ALIAL pretende precísamente erradicar este tipo de prácti- cas, al menos, en aquellos casos en los que existen alternativas viables.
No obstante, el objetivo del proyecto ALIAL es la reducción a cero de estos costes. Todos ellos, así como los asociados al equipamiento, herramientas y des- plazamientos necesarios para el desarrollo del proyecto, correrán a cargo de la adjudicataria y deben justificarse debidamente, asegurando que no existe posibili- dad alguna de obviarlos en los apartados correspondientes del pliego.
Se plantea la realización de pagos a la finalización de cada fase con las siguientes consideraciones:
• Si cualquiera de las fases supera los cuatro meses, recomenda- mos se fraccione el pago en función de los hitos previstos, de modo que empresas de menor tamaño puedan asumir los costes financieros derivados del desarrollo de la solución. La forma de pago es, a menudo, uno de los principales obstáculos para que aumente el número de proveedores.
• Los trabajos a realizar durante la Fase de Soporte y Manteni- miento recomendamos sean abonados periódicamente en función de los resultados de los informes entregados en cada hito de esta fase.
• Dada la naturaleza de las soluciones previstas, recomendamos asignar el presupuesto a cada fase con el siguiente peso (orienta- tivo):
Di+De+Pr
Fase de Diseño+Fase de Desarrollo + Fase de Pruebas
Fase de Soporte y Mantenimiento
§ Tabla 0.1.9
El plazo de entrega establecerá las fechas o periodos de entrega para cada una de las fases que componen el proyecto, y no sólo la fecha final, haciendo especial hincapié en aquellas que generen certificaciones, y por tanto, pagos. A continuación se establece una tabla de ejemplo:
01/069/2010
Versión estable del desa- rrollo + Guías de desarrollo, Usuario e Instalación
Fase de Garantía
Certificación de finalización de Garantía
§ Tabla 0.1.8
Teniendo en cuenta que la Fase de Soporte y Mantenimiento posee una naturaleza distinta al resto de fases, deben figurar explícitamente los plazos correspondientes a esta Fase.
El esquema de penalizaciones dependerá de, al menos, los siguientes fac-
• La duración del desarrollo
• La complejidad técnica y procedimental
• La interrelación de la solución propuesta con otros desarrollos ya establecidos en la Administración Local.
• La complejidad de la implantación de la solución.
Con todo esto, la penalización por retrasos no sobrepasará el 5% del valor total del contrato. Se entenderá por retraso aquellas variaciones por exceso del proceso de desarrollo y ejecución del proyecto, achacables directamente a la adjudicataria del pliego.
ALIAL no aporta novedad alguna en este apartado salvo el caso en el que se establezca la realización de los trabajos por lotes.
La garantía mínima de los proyectos será de un año a partir de la finaliza­ ción del periodo de soporte y mantenimiento, de modo que los fallos de la versión estable del programa que se encuentren durante ese tiempo, serán subsanados por la adjudicataria. También serán aplicados los parches de seguridad necesarios durante ese tiempo.
Para que la garantía sea ejecutable, la versión del software implantado debe ser la misma que al inicio del periodo de garantía, salvo aquellos parches aplicados por la propia adjudicataria. En el momento que el código implantado sea modificado o actualizado por terceros, se considerará anulada la garantía.
El ciclo de vida del software deberá por tanto contemplar que debe man- tenerse una versión estable (en producción) del programa disponible para casos de conflicto administrativo o problemas técnicos relacionados con el software en garantía. Se establecerá un método técnico (firma, certificado u otro) que asegure la autenticidad e invariabilidad de la versión estable.
En la descripción general del programa, se recomienda incluir, al menos, referencias explícitas a los siguientes apartados:
Î Aplicación libre
Î Aplicación multilingüe. Las aplicaciones libres serán desarrolladas en inglés siguiendo procedimientos de internacionalización, lo que permitirá su entrega al cliente en castellano. En aquellas regiones donde existen lenguas co­oficiales, el seguimiento de estos proce­ dimientos estándar de internacionalización es esencial, del mismo modo que lo será con el fin de internacionar el impacto del desa­ rrollo.
Î Multiplataforma
Î Cumplimiento de estándares abiertos y formatos libres, tanto en el apartado de protocolos como de formatos de datos.
Î Interoperable con otras aplicaciones libres.
Î Características funcionales: debe describirse claramente las características funcionales de la aplicación. Se hará especial men- ción de los procedimientos y casos de uso previos al desarrollo de la aplicación, así como los esperados tras su desarrollo.
Î Características técnicas: descripción de las características técni- cas deseadas.
Este apartado debe incluir, al menos, los siguientes contenidos:
Î Procedimientos actuales que afectan a la aplicación a licitar.
Î Procedimientos esperados que debe incorporar el desarrollo.
Î Casos de uso habituales debidamente documentados.
Î Descripción de los principales datos y acciones de entrada y salida de la aplicación.
Î Análisis funcional básico de la aplicación a desarrollar.
Î Otros detalles como:
• Nomenclatura y formatos.
• Reglas básicas de usabilidad e imagen corporativa.
• Funcionalidades relacionadas con la seguridad y protección de datos que debe cumplir la aplicación.
• Interacción con terceras aplicaciones.
Este apartado describirá las especificaciones técnicas del desarrollo tenien- do en cuenta, al menos, los siguientes puntos:
Î Arquitectura de la aplicación a desarrollar.
Î Plataformas sobre las que debe funcionar la aplicación. Si el desarrollo es local, el módulo debe funcionar, al menos, en las plataformas que se enumeran con posterioridad. Si por razones económicas u otras, no es posible el desarrollo del módulo local o cliente en todas las plataformas debe, al menos, utilizar tecnología multiplataforma que permita el empaquetado del módulo para fun- cionar en ellas. Plataformas a considerar:
Î Lenguaje de desarrollo y herramientas (BBDD, entorno de desa- rrollo, aplicaciones, etc.) utilizadas.
Î Acceso a la aplicación por parte de usuarios/técnicos/editores, etc.
Î Distribución de la aplicación (sistema de paquetes, .exe, etc.)
Î Instalación/implantación de la aplicación
Î Recursos hardware necesarios/disponible.
Î Actualización de la aplicación: condiciones de la actualización,
periodos obligatorios, procedimientos de actualización, validación de las actualizaciones, etc.
Î Integración con otros servicios disponibles en el Ayuntamiento y/o externos.
Î Tratamiento de los datos: formatos, codificación, importación/expor­ tación de datos, presentación e impresión de datos
• Intercambio de datos con otras aplicaciones de la propia Adminis- tración Local, otras Administraciones (Diputaciones, Cabildos, Gobierno Autonómico, AEAT, SS.SS. etc.) y empresas privadas (bancos, cajas, etc)
• Intercambio de datos con otras aplicaciones: E/S
Este apartado del pliego dará cuenta, al menos, de las siguientes cuestio-
Î Licencias asociadas a:
• Al los gráficos y diseño (artwork)
• Las herramientas utilizadas para el desarrollo del software, docu- mentación y trabajo artístico.
Î Consideraciones legales sobre la LOPD.
• Relación justificada entre las funcionales y características técni- cas del desarrollo y las consideraciones legales derivadas de la LOPD.
El software resultado del proyecto deberá tener consideración de Software Libre. A efectos del Proyecto ALIAL, se entenderá por Software Libre aquél que reúna los siguientes requisitos:
Î Acceso si restricción al código fuente y de ejecución del código binario, para cualquier propósito o finalidad.
Î Libertad de copia del software sin restricción, así como de distribu- ción y difusión del software y derivados del mismo.
Î Libertad para modificar el código con cualquier propósito y finalidad.
En el caso extraordinario de que sea imprescindible el uso de algún com- ponente con una licencia diferente a la establecida en el pliego, debe indicarse claramente, justificarse debidamente y notificarse a todas las partes implicadas, para su consideración y evaluación de impacto. El objetivo debe ser siempre elu- dir licencias no libres.
La adjudicataria se hará responsable de cualquier implicación legal derivada posibles litigios relacionados con las licencias establecidas durante el periodo de vigencia del proyecto y con posterioridad. Todos los trabajos resultantes del pre- sente concurso tendrán asignados los derechos de explotación a la Administración Local licitadora.
Siguiendo las bases del proyecto ALIAL, recomendamos que todos los desarrollos, trabajos intermedios y derivados sean publicados con licencia libres, de modo que no existan trabas legales para que otras Administraciones Públicas puedan copiar, distribuir, evaluar y modificar el código, los trabajos artísticos o la documentación asociada al trabajo realizado.
El software deberá poder ser suministrado al Ayuntamiento de modo que éste pueda, sin restricción alguna, licenciarlo bajo una licencia del tipo:
• EUPL, Licencia Pública de la Unión Europea http://www.osor.
eu/eupl/european-union-public-licence-eupl-v.1.1
• GPLv3, Licencia Pública General versión 3, http://www.gnu.org/
licenses/gpl-3.0.html
• Otra compatible con cualquiera de las anteriores.
Toda la documentación suministrada por la adjudicataria podrá ser licen- ciada por el Ayuntamiento bajo una licencia libre compatible con la licencia GNU FDL http://www.gnu.org/licenses/fdl.html o con las licencias de documentación admitidas por la Debian Foundation http://www.debian.org/social_contract. es.html .
Si no estuviera traducida al castellano, la licencia deberá ser traducida por la adjudicataria, adjuntada a la Guía de Desarrollo y publicada, además de hacer referencia a ella en las cabeceras de los archivos. Si estuviera traducida, debe hacerse referencia a ella en la Guía de Desarrollo, la web y las cabeceras de los archivos.
Las cabeceras de cada uno de los archivos del programa debe contener, al menos, los siguientes campos:
Î Nombre del Autor/es original/es
• Nombre de la empresa/entidad para la que trabaja el autor/es y URL
• Correo corporativo del autor/es
Î Nombre/es de los desarrollador/es que han realizado modificacio- nes posteriores
• Nombre de la empresa/entidad para la que trabaja el autor/es y URL (si lo hubiera)
Î Licencia
• URL de la licencia
Î Entidad financiadora del código
• URL de la entidad
Además de estos campos, debe seguirse las instrucciones de la licencia a este respecto.
Las herramientas a utilizar para el desarrollo del software deben ser libres, o no establecer restricción alguna incompatibles con las licencias enumeradas, sobre las partes del programa realizadas con ella, que invaliden las condiciones expuestas en este apartado. La Guía de Desarrollo incluirá un apartado de licen- cias de las herramientas utilizadas.
15. Soporte y Mantenimiento
El aparado de soporte y mantenimiento del pliego tratará, al menos, los siguientes puntos:
Î Plazo: debe quedar claramente establecido el plazo que abarca esta fase del proyecto.
Î Condiciones generales del servicio. Este apartado es especial- mente relevante si la Administración Local ya cuenta con un Centro de Atención a Usuarios (CAU) propio, tiene el servicio externalizado o dispone de normativa al respecto.
Î Condiciones específicas: definición de los elementos básicos del servicio que se pretende obtener. Entre ellos:
• Roles y grupos
• Tiempos de respuesta y horario del servicio
• Workflow de los estados relacionados con el servicio de soporte y mantenimiento.
• Perfil de los trabajadores de la adjudicataria que van a dar el ser- vicio de soporte y mantenimiento.
• Canales y procedimientos de comunicación de las incidencias y sus respuestas.
• Periodicidad y características de los informes regulares de la prestación del servicio.
◦ Análisis estadístico del servicio.
En caso de que el Ayuntamiento ya disponga de procedimientos consoli- dados de soporte y mantenimiento, o incluso infraestructura definida (CAU), será necesario establecer un plan de adaptación a las nuevas metodologías teniendo en cuenta el nivel de madurez del servicio.
Se recomienda que toda la información posible relacionada con el servicio de soporte y mantenimiento realizado durante el proyecto, sea enviada al proyecto ALIAL para su publicación con licencias libres según acuerdo previo entre ambas partes, con el fin de que el conocimiento útil derivado sirva, al menos, a otras em- presas y Corporaciones.
El pliego debe establecer las condiciones para la implantación de la so- lución en los sistemas de la Corporación Local. Las principales condiciones de implantación serán:
Î Se habilitará un canal seguro de comunicación entre la Adminis- tración Local y la sede de la adjudicataria con el fin de poder re- alizar tareas remotas de control. La habilitación de este canal, no obstante, debe estar controlada por la propia Corporación. El proveedor debe establecer las medidas técnicas para que así sea, además de asumir los riesgos que ello conlleva. Esta medida es imprescindible para rebajar los costes de implantación (también los de mantenimiento y gestión de incidencias).
Î La implantación de la solución debe realizarse sin interrupción del servicio que se presta en la actualidad, siempre que sea posible.
Î La implantación debe venir precedida de un plan pactado entre ambas partes, de acuerdo con las condiciones del pliego. Dicho plan formará parte de la Guía de Análisis y Diseño del proyecto (ver apartado de Documentación).
Î Esta fase contemplará un programa de formación para los usuarios así como las medidas de acompañamiento necesarias (gestión del cambio).
Î La dirección del proyecto establecerá una propuesta de control de las acciones relacionadas con la Implantación de la solución, en es- pecial, de las actuaciones de campo, de modo que pueda evaluarse el coste y dificultad de las mismas.
Toda la documentación del proyecto será entregada al Ayuntamiento por el Director del Proyecto, tras la validación del formato y la metodología de generación de las mismas. Las condiciones generales aplicables a toda la documentación son las siguientes:
Î La documentación técnica será desarrolladas en XML™ (eXtensible Markup Language) DocBook, estándar en la documentación técnica de buena parte de los proyectos maduros y globales de desarrollo de Software Libre.
Î Además, las guías se presentarán, al menos, en formato estándar .pdf y html. Serán redactadas en herramientas colaborativas (wikis, por ejemplo).
Î Su peso en formato .pdf no será superior a 2 Mb. Si lo fueran, se dividirán en archivos diferentes.
Î Todas las ayudas y documentos se elaborarán al menos en castella- no, siguiendo las normas de internacionalización de documentación publicadas por el proyecto Freedesktop.org u otras directrices acep- tadas por desarrollos de comunidad de primer nivel.
Î Las Guías orientadas a usuario se traducirán a las lenguas co­ofi- ciales de cada región, si fuera el caso. Su traducción al inglés debe entenderse como una mejora deseable.
Î Todas las guías serán actualizadas regularmente, conforme lo sea el programa o alguno de los servicios asociados.
Î La información que no sea confidencial o de carácter únicamente interno, debe ser publicada conforme se vaya elaborando.
Î Se recomienda que toda la documentación sea puesta a disposición del proyecto ALIAL para su publicación, excepto los contenidos de carácter confidencial, que estarán acotados a anexos de cualquiera de los documentos entregables.
• El proveedor, el Ayuntamiento o el proyecto ALIAL publicará la documentación con licencias libres con el fin de que sea útil a terceros sin restricciones.
Las Guías y Manuales que ALIAL recomienda formen parte complementa- ria al desarrollo son:
2. Manual de Instalación/Implantación
3. Guía de Análisis y Diseño
4. Guía de Desarrollo
5. Guía de Pruebas: este documento es básico para conocer las pruebas técnicas realizadas, de modo que pueda ser evalua- do el resultado del trabajo asegurando que:
1. La calidad del trabajo es adecuada
2. El desarrollo sigue estándares abiertos, formatos libres y los procedimientos y metodologías relacionados con todas las fases del proyecto son compatibles con los habituales dentro del desarrollo de aplicaciones libres y abiertas.
6. Guía de Soporte y Mantenimiento
Se desarrollará un Manual de Usuario que tendrá en cuenta, al menos, los siguientes aspectos:
• Descripción de las opciones que presenta la aplicación, rela- cionándolas directamente con la interfaz de usuario.
• Dispondrá de capturas de pantalla aclaratorias .
• Descripción de los principales casos de uso correspondientes a las funcionalidades descritas en la Guía de Diseño.
• Incluirá una breve sección dedicada a las licencias del producto.
• Se recomendarán otras opciones como vídeos explicativos, screencasts, etc., publicados con formatos y licencias libres.
Manual de Instalación e Implantación
Este Manual está orientado a los técnicos que vayan a implantar la solu- ción, así como a otras personas involucradas en dicho proceso.
Debe asegurar que técnicos que no hayan desarrollado la herramienta puedan implantarla en diferentes entornos. Se asume que en las Administraciones Locales conviven sistemas y servicios multiplataforma, por lo que es importante que el manual sea lo suficientemente genérico como para ser útil en diferentes escenarios. El primer objetivo, no obstante, es que contemple con detalle la im- plantación en el entorno para el que ha sido desarrollado.
Si se tratara de una aplicación local, debe incluir las instrucciones para una instalación paso a paso en el equipo del usuario.
Guía de Análisis y Diseño
Documento básico para el seguimiento del desarrollo por parte de los inte- grantes del desarrollo, así como de terceros interesados en participar en el futuro. Se reflejará en este documento el procedimiento y resultados del estudio por parte de la empresas ejecutante y la Dirección del Proyecto de la solución a implantar.
A nivel técnico, esta Guía definirá claramente las funcionalidades que es-
tarán disponibles en cada versión del desarrollo, los esfuerzos y tiempos previstos para su realización y los procedimientos a llevar a cabo por la empresa ejecutora
y la Dirección del Proyecto. Por tanto, la Hoja de Ruta definitiva del Proyecto (roadmap), será una de los principales resultados de esta Guía.
Debe existir una correspondencia entre las características funcionales
y técnicas que defina el pliego con los diferentes entregables, en especial, las
versiones de desarrollo y RC. Esta correspondencia estará claramente reflejada en la Hoja de Ruta del Proyecto, de modo que sea simple realizar un seguimiento
de esas funcionalidades asegurando que no se duplican innecesariamente, o se obvian algunas relevantes.
Incluirá también el Plan de Formación a usuarios y técnicos así como el Plan de Implantación y el Plan de Comunicación a los trabajadores, entidades y proveedores afectados.
Se realizará una Guía de Desarrollo con el fin de disponer de un docu- mento que permita realizar mejoras o modificaciones en el programa en un futuro. Esta Guía describirá en detalle, al menos, los siguientes apartados:
Î Documentación del código. Esta documentación debe incluir, al menos:
• Licencias de código de terceros utilizado.
• Descripción y enlaces a documentación relacionada con código de terceros utilizados.
• Descripción de las modificaciones realizadas en código de ter- ceros y su correspondiente licenciamiento.
• Descripción del código desarrollado para este proyecto.
• Estructura de los datos y archivos de configuración de la apli- cación .
• Descripción de las funcionalidades de cada versión, evolución de una versión a otra y principales decisiones técnicas realizadas durante el proceso de desarrollo.
Î Descripción de la metodología de desarrollo utilizada.
Î Descripción de las herramientas de desarrollo que se utilizaron en el proyecto. Cada descripción debe incluir, al menos, los siguientes apartados:
• Licencia de la herramienta
• Breve descripción de la herramienta (o enlace a web oficial donde se realice dicha descripción en castellano). La versión debe ser consistente.
• Enlaces a la versión utilizada.
• Enlaces a la guía de instalación y manual de usuario de la herra- mienta.
• Breve descripción del uso dado en relación con la solución desa- rrollada.
Î Procedimientos y herramientas de generación de documentación y traducción utilizadas.
Î Descripción de la generación de los paquetes o formatos de insta- lación y distribución del programa, así como actualizaciones en las diferentes plataformas.
Î Información técnica y metodológica relacionada con todas las ver- siones del programa.
En la actualidad, existen herramientas que aportan parte de la información solicitada en esta Guía. Asimismo, si el código está realizado de manera legible y bien documentado, algunos de los apartados solicitados en este apartado de la Guía ALIAL pueden obviarse.
Se pretende que la Guía sea un documento que permita encontrar fácil- mente la información que se solicita. No es necesario que la incluya directamente (información referenciada). Esta filosofía es válida para el resto de documenta­ ción a entregar, excepto para el Manual de Usuario y de Instalación. No obstante, deberá incluirse información concreta de manera explícita si así lo solicita el Ayun- tamiento.
Esta Guía describirá las pruebas realizadas en cada hito así como las he- rramientas utilizadas para ello. Contemplará también los resultado de los tests y descripción de las correcciones realizadas. Los resultados serán debidamente justificados y analizados.
La Guía de Soporte y Mantenimiento describirá, al menos:
Î Los procedimientos de notificación, aceptación, resolución, rechazo, etc. de incidencias por parte de la adjudicataria, así como los tiem- pos de respuesta, priorización y gestión de las mismas
Î El procedimiento de aceptación, corrección, elaboración y distribu- ción de parches para la aplicación.
Î Aplicación de estos procedimientos a la gestión de incidencias en la herramienta a utilizar.
Î Dispondrá una sección específica de:
• FAQ (Preguntas Frecuentes Realizadas).
• Descripción de los mensajes de error y cómo resolverlos.
Î La descripción del proceso de elaboración, publicación, distribución e instalación de parches de seguridad.
Î Análisis de datos y estadísticas simples relacionadas con las inci- dencias y la respuesta dada.
Recogerá los diferentes informes de soporte y se realizará un breve análi- sis de la evolución del proyecto en función del estudio de las incidencias.
Esta Guía se considera un documento vivo. ALIAL recomienda que esté disponible, como el resto de documentación, en la web del Proyecto de modo que puedan aportar contenidos a ella terceras empresas (referidas a versiones dife- rentes de la estable o en producción).
Estos documentos se consideran de carácter interno entre los actores del desarrollo:
1. Dirección de Proyecto
3. Empresa adjudicataria
Si se ha involucrado al Comité ALIAL, éste deberá tener acceso a la infor- mación en las mismas condiciones que los actores enumerados arriba.
Los informes de soporte y mantenimiento serán parte de la Memoria del proyecto. Las Actas de finalización podrán ser consideradas documentos admi­ nistrativos a modo de certificación, lo que constituye un justificante para todas las partes implicadas del cumplimiento de objetivos previstos. Algunos de ellos irán asociados a la realización de pagos, según la sección Forma de Pago.
La Memoria del Proyecto resumirá todos aquellos apartados del proyecto relacionados con la gestión del mismo, incluyendo:
Î Entregables.
Î Actas de las reuniones de coordinación y seguimiento.
Î Diagrama de Gantt del proyecto con su correspondiente asignación de recursos y personal.
Î Descripción de recursos y personal involucrados.
Î Memoria económica.
Î Informe de Soporte y Mantenimiento en el que se incluya, al menos:
• Estadísticas y análisis de datos derivados de la acción de soporte y mantenimiento.
• Informe de evaluación del Mantenimiento de la aplicación.
Î Otros datos de conclusión de interés para el cliente.
Î Referencias al resto de documentación y código, así como impacto del proyecto hasta esa fecha.
Será la Dirección de Proyecto la encargada de la elaboración de las actas de reuniones, que serán aprobadas por las partes afectadas y entregadas regu- larmente a la Administración Local. Todas ellas formarán parte de la Memoria del Proyecto.
Al término de cada periodo de la Fase de Soporte y Mantenimiento se en- tregará un informe sobre, al menos:
• Las incidencias más relevantes.
• La medidas adoptadas para la resolución de las mismas.
• Sugerencias para la mejora del servicio que se presta a los usua- rios.
Cada informe de soporte aportará también una visión empírica de las inci- dencias más relevantes, las que tienen más impacto, sus tiempos de resolución, las que permanecen abiertas, su justificación, etc. Se trata por tanto de un informe orientado a conocer el estado del proyecto en el momento de su presentación.
Documento legal de certificación de finalización de hito/fase/proyecto. De adjuntarán también a la Memoria (copia).
La empresa incluirá en este apartado la descripción del plan de trabajo. También debe definir claramente las funcionalidades que incorporarán las distintas versiones del programa, las fechas previstas de publicación y estabilización de cada una de ellas, así como la persona de contacto de cada una de las unidades que componen La Hoja de Ruta (roadmap) del proyecto.
El roadmap del proyecto se considera un documento vivo. Debe estar per- manentemente actualizado en en cualquier instante a lo largo del desarrollo del proyecto y ser accesible públicamente, con el fin de que terceros conozcan con detalle su evolución. La finalización de cada hito lleva asociado la comprobación y certificación correspondiente por parte del cliente (Ayuntamiento o quién éste designe).
Será responsabilidad de la Dirección del Proyecto coordinar los traba- jos realizados por el personal de la empresa adjudicataria y verificar su nivel de calidad, registrando y entregando al responsables de la Administración Local ofertante los informes, guías y memorias de verificaciones realizadas, además del software y otros entregables en formatos estándar.
El plan de trabajo que presente la empresa establecerá claramente las fe- chas de las reuniones de coordinación mínimas. Recomendamos que se produz- can, al menos, al comienzo, final y ecuador de cada hito. Deberá estar claramente reflejado quién realiza labores de dirección, gestión e interlocución. Se aportará un Diagrama de Gantt, además de la asignación de recursos y horas de trabajo por acción, correspondiente a los diferentes hitos que componen las distintas fases del proyecto. Asimismo, serán descritas las principales tareas que compo- nen cada acción.
A modo de resumen, además del Diagrama de Gantt, debe presentarse:
• Un Plan de descomposición de Trabajo (EDT/WBS): diagrama jerárquico de descomposición de entregables a unidades míni- mas de gestión (acciones en este pliego, no tareas)
• Una tabla con todos las fases/hitos/acciones/tareas tal como plantea el ejemplo. Por otro lado deberán describirse las fechas relativas, expresadas en semanas, de inicio y finalización de las fases/hitos/acciones del proyecto en esa misma tabla o en otra asociada al diagrama de Gantt.
§ Tabla 0.1.6
Una vez adjudicado el proyecto, como parte de la fase de diseño, la em- presa adjudicataria, de acuerdo con la Dirección de Proyecto, deberá presentar un plan de trabajo completo definido a nivel de tarea, con su correspondiente asig- nación de recursos, cumpliendo todos los requisitos establecido en el contrato que se firmará tras la adjudicación del pliego. Este plan se resume en:
• Plan de descomposición de Trabajos a nivel de tareas (EDT/ WBS) definitivo.
• Diagrama de Gantt a nivel de tareas y con asignación de recur- sos.
• Tabla resumen con la descripción de las tareas y asignación de horas de trabajo a cada una.
Como mínimo, a la finalización de cada hito se generará un entregable. Los entregables serán presentados en el pliego mediante una tabla simple. Cada uno de los ellos debe ser descrito, con el fin de conocer su objetivo y alcance. El pro- cedimiento de entrega y verificación del entregable debe describirse en la sección de gestión del proyecto correspondiente al pliego, así como su responsable. De esta manera, este apartado no generará duda alguna y se tenderá a homogenei- zar.
En los hitos relacionados con el desarrollo de código, la certificación de finalización de cada uno llevará aparejada, además de la entrega de la documen­ tación correspondiente, la demostración del funcionamiento de la versión de soft- ware correspondiente (Alfa, Beta, Candidatos de Lanzamiento y estable) así como las pruebas realizadas.
Las versiones de desarrollo (Alfa y Beta) serán plenamente instalables al menos, en una plataforma. Esto facilitará tremendamente cualquier labor de evaluación del Comité de Calidad del proyecto ALIAL, de otras empresas y Ayun- tamientos interesados en el desarrollo.
Debe incluirse en el pliego la temporalización relativa de los entregables, de acuerdo con el plan de trabajo, expresado en semanas, de modo similar a como se establece en el ejemplo.
Guía de Análisis y
Diseño v0.1
- Sem. 1
Diseño v1.0
- Sem. 2
Manual de Insta-
lación / Implan-
Fase de im- plantación
tación v0.1
lación/Implan-
tación v1.0
§ Tabla 0.1.7
Esto permitirá a las empresas disponer de una información clara sobre los periodos de trabajo que desembocará en una buena planificación de horas, y por tanto, de un presupuesto fiable.
Para muchas Administraciones Públicas, el apartado Equipo de Trabajo forma parte del apartado Solvencia Técnica, que se establece como condición de aceptación de ofertas. En contraposición a esta idea, se propone incluir este apartado junto a las recomendaciones relacionadas con los roles que deben estar presentes en cada proyecto.
Esta sección será dividida en dos apartados:
1. Roles del Equipo de Trabajo.
2. Formación y Experiencia del Equipo de Trabajo.
En este apartado se enumerarán los roles así como sus competencias. Debe tenerse en cuenta que en el apartado de Gestión del Proyecto se pedirá el organigrama y la relación entre los roles. Su ámbito de responsabilidad puede ser descrito aquí y añadir un gráfico en la sección posterior. El ámbito mínimo de actuación a definir debe ser:
► Dirección/coordinación
del proyecto si la adjudica- taria dirige el proyecto
► Gestión de proyecto
► Dirección Técnica
► Diseño gráfico y usabili-
► Soporte y Mantenimiento
Puesto que el proyecto ALIAL se diseña de modo que cada una de los módulos sea de reducido tamaño, si así lo cree conveniente la empresa, una per- sona podrá desempeñar más de un rol, siempre que disponga de la experiencia necesaria.
Debe adjuntarse a la oferta el CV de cada miembro del equipo de trabajo en formato estándar (.pdf por ejemplo). Debe limitarse su extensión y peso por motivos operativos. Se recomienda 4 páginas y 1 Mb. como límite.
En la propia oferta se recomienda definir dos tablas en las que se visuali- cen fácilmente las características principales de cada uno de los miembros del equipo que forma parte de la oferta. A continuación presentamos un ejemplo de estas tablas (Tabla 0.1.1 y Tabla 0.1.3) con su correspondiente leyenda:
ASOLI F
§ Tabla 0.1.1
Leyenda de la tabla Equipo de Trabajo (Tabla 0.1.1)
La leyenda aplicable a la tabla del equipo de trabajo es la siguiente:
Id: letra del abecedario para identificar a cada profesional en los dis- tintos apartados donde sea necesario
Rol: rol que ocupa dentro del equipo o perfil del profesional. En el apartado correspondiente han sido indicados los obligatorios. Pueden plantearse otros en función de nomenclatura estándar o ampliamente aceptada
Empresa: empresa u organización contratante. Este campo sólo es necesario si se presenta más de una empresa al concurso o existe subcontratación.
Nombre: nombre de la empresa. Si trabaja como autónomo/ profesional, debe indicarse (Profesional)
Antigüedad: antigüedad del trabajador en la empresa en número de meses.
Formación : se plantean a efectos de resumen las siguientes posibi- lidades, que serán ampliadas o matizadas en el CV de cada profe- sional que se adjunta.
Ing. Superior : Doctor, Licenciado, Ingeniero Superior o equivalente
Ing. Técnico : Diplomado, Ingeniero Técnico o equivalente
Tec. Superior : Técnico Superior o equivalente
Tec. Medio : Técnico de grado medio o equivalente
Otro : otro nivel de titulación académica. debe especificarse en el apartado Comentario de la tabla.
Experiencia General : este apartado hace referencia a la experiencia general en las áreas que abarca el proyecto, como podría ser desa- rrollo web, bb.dd., desarrollo de aplicaciones locales, diseño gráfico, etc.
Experto: más de 15 años de experiencia profesional en las áreas de actuación asignadas
Senior: entre 5 y 15 años de experiencia profesional en las áreas de actuación asignadas
Junior: entre 2 y 5 años de experiencia profesional en las áreas de actuación asignadas
Novel: entre 0 y 2 años de experiencia profesional en las áreas de actuación asignadas
Experiencia específica : deben especificarse los meses de experien- cia en cada una de las tecnologías/herramientas más relevantes que se propone utilizar en el proyecto. Se sustituirá en la Tabla Tec 1, Tec 2, etc. por el nombre de la tecnología.
Comentario : debe aportarse un dato relevante que ayude a determi- nar el nivel de experiencia, conocimiento y/o idoneidad del profesional que forma parte del equipo propuesto.
de €)
a ASOLIF
§ Tabla 0.1.3
Leyenda de la tabla Experiencia Equipo de Trabajo (Tabla 0.1.3)
Esta tabla hará únicamente referencia, como máximo, a los cinco proyec- tos más relevantes para la evaluación de su experiencia en las tecnologías/he- rramientas planteadas en el proyecto. La leyenda aplicable a la tabla del equipo de trabajo es la siguiente:
Id : letra del abecedario para identificar a cada profesional en los dis- tintos apartados donde sea necesario
Nombre : Nombre del trabajador

References: Real Decreto 
 Real Decreto 
 Real Decreto 
 Real Decreto 
 Real Decreto 
 Real Decreto 
 Real Decreto 
 Real Decreto 
 resolución