Propuesta de Plataforma Tecnológica

En esta sección se describirá una propuesta de la plataforma tecnológica que deberá dar soporte al conjunto de procedimientos definidos. Para ello, se describen cada una de las herramientas identificadas a formar parte del mapa de aplicaciones objetivo, delimitando el alcance y ámbito en el que se utilizarán cada una de las herramientas dentro de la operativa diaria.

La identificación de las herramientas que automatizarán la actividad se ha basado por un lado, en el análisis de las herramientas actualmente en uso para conocer su grado de adecuación a las necesidades identificadas, y por otro, en comparativas de herramientas de mercado realizadas en aquellas áreas en las que no existía una herramienta claramente implantada y definida. En la siguiente figura se presenta una propuesta del mapa de aplicaciones.

Con el fin de conocer la plataforma tecnológica necesaria para dar soporte a los procedimientos definidos, se ha identificado para cada procedimiento, la herramienta que debería utilizarse para la realización de cada una de las actividades. Como resultado de este estudio, se presenta a continuación el modelo de relación propuesto (usuarios – herramientas).

Relación de Herramientas

Naos

Sistema unificado de soporte y gestión de incidencias y peticiones de servicio que actuará como Ventanilla Única en la resolución de incidencias, peticiones y problemas relativos a los servicios que la Junta de Andalucía presta internamente a sus empleados. El sistema dispondrá de un Catálogo General de Servicios como carta de servicios y operativa habitual.

A continuación se describe una propuesta de la finalidad para la que se puede utilizar NAOS en la operativa de trabajo.

• Registro de incidencias (consultas e incidencias) y peticiones de servicio (propuesta de mejora, instalación, formación, correctivo, evolutivo, problema, etc.) por parte de los usuario finales.
• Registro de solicitud de entrega software: Incluye el proceso completo de una entrega software, desde que se realiza la entrega por parte del proveedor, hasta que es revisada, aceptada o rechazada por la Dirección del Proyecto. En dicho procedimiento se incluye además la ejecución de los servicios de testing asociados a la entrega software por parte de la Oficina de Ejecución del Testing (Pruebas Funcionales, Pruebas Técnicas, Área de Seguridad, Área de Calidad de Servicio, etc.).
• Aceptación y rechazo de las entregas. Será desde la herramienta NAOS, donde el Gestor de Proyecto y/o Director Técnico acepten o rechacen la entrega, mediante la transición a una fase u otra. Para ello, se basarán en el informe de resultado de pruebas que el Equipo de Testing deberá haber incorporado en el espacio correspondiente del Gestor Documental. El rechazo de la entrega supondrá una replanificación en la herramienta de Gestión de Proyectos.
• Registro de las solicitudes de servicios a la Oficina de Testing (catálogo de servicios).
• Registro de las solicitudes de servicio a la Oficina de Ejecución del Testing:
  • Solicitud del Servicio Definición y Estrategia de Pruebas.
  • Solicitud de Servicios de Revisión de Testing Temprano: Revisión Requisitos, Revisión Análisis, Revisión Diseño y Revisión Plan de Formación.
  • Solicitud de Servicios de Validación y Ajuste.
• Solicitud de Gestión de Despliegues: El Director Técnico de Proyecto podrá solicitar la promoción entre los diferentes entornos (preproducción, producción y formación) de la entregas aprobadas.
• Solicitud de Actualización del Artifactory: El Equipo de Proyecto podrá solicitar la actualización del Artifactory con las librerías que sean necesarias (propias o externas) para la correcta compilación del software desarrollado.

Herramienta de Gestión de Proyectos

La herramienta de gestión de proyectos debe permitir el acceso a todos los participantes del proyecto, proporcionando información actualizada de la planificación del proyecto, replanificaciones realizadas, grado de avance del proyecto, etc.

A continuación se describe la finalidad para la que se puede utilizar la herramienta de Gestión de Proyectos en la operativa de trabajo.

• Alta de los proyectos. El Gestor de Proyecto deberá dar de alta el proyecto en la herramienta de Gestión de Proyectos.
• Planificación del proyecto (fases – actividades – hitos). El proveedor deberá dar de alta en la herramienta de Gestión de Proyectos la planificación del proyecto. Posteriormente, el Gestor de Proyecto y/o Director Técnico de Proyecto deberá revisar y validar la planificación, solicitando los cambios que consideren oportunos. Para aprobar la planificación se deberá crear una línea base del proyecto, de forma que a partir de ese momento, cualquier modificación en la planificación suponga una replanificación del proyecto.
• Planificación del Plan de Testing. La Oficina de Ejecución del Testing deberá dar de alta el plan de testing correspondiente a cada uno de los proyectos en certificación, el cuál se elaborará a partir de los servicios acordados.
• Seguimiento y control del proyecto.
• El proveedor deberá actualizar el grado de avance de cada una de las actividades que componen la planificación del proyecto.
• Replanificación del proyecto. Durante el desarrollo y ejecución del proyecto, se producirán situaciones que impliquen replanificar el proyecto. Todas las solicitudes de replanificación que surjan durante el desarrollo del proyecto, deberán ser registradas en la herramienta de Gestión de Proyectos, con el fin de ser evaluadas. En caso de ser aprobadas por el Director Técnico de Proyectos, será el proveedor el que realice los cambios oportunos en la planificación; por ejemplo:
• El proveedor deberá crear un nuevo hito de entrega correspondiente a la nueva entrega en la planificación del proyecto. Deberá indicar la fecha en la que se producirá dicha entrega.
• La Oficina de Ejecución del Testing deberá elaborar una nueva planificación de los servicios asociados a la nueva entrega planificada.

Redmine

Redmine es una herramienta con interfaz web, orientada a la coordinación de tareas, comunicación de participantes, y que puede especializarse en proyectos de desarrollo gracias a la integración con un repositorio de código.

A continuación se describe la finalidad para la que puede utilizarse Redmine en la operativa de trabajo.

• Registro de los siguientes tipos de peticiones:
• Consultas: Facilitarán la comunicación entre Equipo de Proyecto y otros participantes (p.e.Equipo de Testing), permitiendo la resolución de dudas que surjan , de forma ágil.
• Defectos: Cualquier error o carencia detectadas en los productos software y documental por la Oficina de Ejecución del Testing durante la ejecución de los servicios acordados en la Estrategia de Pruebas. Dichos defectos serán registrados en la herramienta Redmine con el fin de que el Equipo de Proyecto tenga constancia de los defectos registrados y pueda comenzar a trabajar en su resolución. Se han considerado dos tipos de defectos: bloqueantes y no bloqueantes.
• Defectos bloqueantes: Son aquellos defectos que impiden a la Oficina de Ejecución del Testing la ejecución de algunos de los servicios acordados. Por tanto, serán comunicados al Equipo de Proyecto correspondiente, con la finalidad de que el defecto sea resuelto de forma inmediata (dentro de un plazo establecido). La resolución de dicho defecto permitirá a la Oficina de Ejecución del Testing continuar con la ejecución del servicio bloqueado.
• Defectos no bloqueantes: Son aquellos defectos detectados durante la ejecución de los servicios, pero que no impiden su ejecución. Se han identificado dos tipos de defectos no bloqueantes:
• Con revisión: El Gestor de Proyectos correspondiente deberá evaluar si realmente se trata de defectos como tal y por tanto requieren ser resueltos por el Equipo de Proyecto, o si por el contrario, consideran necesario desestimarlos.
• Sin revisión: El Equipo de Proyecto deberá encargarse de la resolución del defecto registrado.
• Actualización del estado de los distintos tipos de peticiones.
• El Equipo de Proyecto conforme vaya trabajando en la resolución de las peticiones comunicadas, deberá ir actualizando el estado de la petición, según los flujos de estados descritos.
• La Oficina de Ejecución del Testing durante la ejecución de los servicios acordados, deberá verificar que los defectos que se habían acordado resolver en la entrega, efectivamente están resueltos. En ese caso, deberá actualizar el estado del defecto a 'cerrado por resuelto'. En caso contrario, deberá actualizar el estado a 'reabierto' para indicar que no es correcta la solución propuesta.

Verifica

Verifica es una solución para la gestión del testing, en la que se describen las actividades a realizar para asegurar la calidad de las entregas software y documentales, de forma que desde una única herramienta se gestionen y controlen todas las verificaciones realizadas. Está formado por dos subsistemas principales: el Catálogo de Verificaciones, centralizado, que es el repositorio de la información de las verificaciones y las herramientas que automatizan dichas verificaciones, y el SIV, de instalación distribuida en cada organismo, que implementa el Proceso de Verificación, administra los proyectos, sus entregas, da soporte a las verificaciones manuales, recopila las métricas de calidad de las verificaciones y proporciona informes y un cuadro de mandos de dichas métricas. Ambos disponen de una interfaz web.

El SIV implementa el Proceso de Verificación, es decir permitirá automatizar y apoyar los procesos de verificación definidos para MADEJA, facilitando la aplicación de las metodologías de verificación definidas para MADEJA. Ha de cumplir estas características:

• Automatización de la verificación de los entregables software.
• Disponibilidad para todos los actores implicados en el proceso de desarrollo software (proveedores, oficinas de aseguramiento de la calidad, directores de proyecto, etc.).
• Compatibilidad con el modelo de desarrollo bajo integración continua.
• Plena integración con el procedimiento de entrega de software definido. Además permitirá integrarse con otros procedimientos de entrega del ciclo de vida de desarrollo de software cuando estén definidos por MADEJA (ASI, DSI, CSI).
• Ejecución de verificaciones automáticas y manuales.

A continuación se describe la finalidad para la que puede ser utilizada Verifica en la operativa de trabajo.

• Sistematización de los servicios de testing. Permite la automatización de las verificaciones, aunque también da soporte a verificaciones manuales. Tanto las verificaciones automáticas como las manuales, se podrán realizar sobre aspectos estáticos (de código fuente), dinámicos (de ejecución) o documentales de la entrega software. Permite al Equipo de Testing ir imputando cada uno de los estados positiva o negativamente. En caso de no imputar el estado, permanecerá en estado 'pendiente'.
• Consulta de los estados asociados a las diferentes entregas, con el fin de conocer el progreso y estado en el que se encuentra la ejecución de cada uno de los servicios.
• Imputación de horas empleados en tratar cada uno de los estados.
• Registro de los defectos/no conformidades detectadas durante la comprobación de cada una de las verificaciones asignadas a cada servicio. Además, la información asociada a cada uno de los defectos se registrará en Redmine, con el fin de comunicar al Equipo de Proyecto los defectos encontrados, y que así puedan empezar a trabajar en su resolución.
• Generación de informe resultado de las verificaciones realizadas para cada uno de los servicios. Dicho informe deberá incorporarse en el espacio reservado en el gestor documental.

Alfresco

Alfresco es una solución de software libre que permite la gestión documental de una organización, dispone de gestión de roles, workflow, seguridad, área personal y publicación de contenidos.

A continuación se describe la finalidad para la que se puede utilizar Alfresco en la operativa de trabajo.

• Repositorio de toda la documentación relacionada con los proyectos desarrollados. Cada proyecto deberá tener su espacio de carpetas en el gestor documental Alfresco, el cuál deberá crearse al inicio del proyecto siguiendo la plantilla definida en función de las tipologías de proyectos.
• Realización de entregas documentales por parte del equipo de proyecto del proveedor. La documentación que el proveedor genere durante el desarrollo del proyecto deberá incorporarla al espacio correspondiente en el gestor documental, con el fin de que pueda ser revisada, aprobada o rechaza por la Oficina Técnica.
• Aprobación y rechazo de la documentación. Desde la herramienta de gestión documental Alfresco, el Gestor de Proyectos y Director Técnico de Proyectos podrán aprobar o rechazar un documento incorporado por el proveedor. Para ello, se han definido asociado a cada plantilla, un workflow de revisión y validación de los documentos.
• Obtención de toda la documentación necesaria para la prestación de los servicios solicitados. En la petición naos del servicio correspondiente se deberá indicar el espacio de Alfresco en el que se encuentra dicha documentación.
• Incorporación de los informes resultado de la ejecución de los servicios de testing. La Oficina de Ejecución del Testing tras la prestación de todos los servicios acordados, elaborará un informe en el que reflejará el resultado de todas las verificaciones realizadas correspondiente a cada uno de los servicios prestados. Dicho informe, lo deberá incorporar en el espacio correspondiente del gestor documental.

Subversion

Subversion es un software de sistema de control de versiones de software libre que permite el desarrollo concurrente por personas del mismo o varios equipos de desarrollo.

A diferencia de otros sistemas de gestión de versiones, se caracteriza porque los archivos versionados no tienen cada uno un número de revisión independiente. Es decir, todo el repositorio tiene un único número de versión que identifica un estado común de todos los archivos del repositorio en un instante determinado.

A continuación se describe la finalidad para la que se puede utilizar Subversion en la operativa de trabajo.

• Incorporación en subversión. El proveedor incorporará en subversión todos los productos (software, scripts, herramientas) que compongan una determinada entrega software.
• Obtención de los productos que componen la entrega. La Oficina de Ejecución del Testing obtendrá todos los productos de la entrega para poder prestar los servicios de testing acordados de la rama del svn especificada en la petición naos asociada a dicha entrega.

Hudson

Es un sistema de integración continua de proyectos java con soporte completo para proyectos Maven. Permite a los usuarios automatizar la gestión del ciclo maven de las aplicación, pudiendo incluir distintos alcances:

• Compilación
• Despliegue
• Verificación de código estático

Hudson permite realizar una programación de todas las tareas que realiza a partir de una configuración de tiempo o basada en eventos.

A continuación se describe la finalidad para la que se puede utilizar Hudson en la operativa de trabajo:

• La Oficina de Ejecución del Testing utilizará Hudson para lanzar Maven y realizar la compilación y despliegue de las diferentes entregas. Además, lo utilizará para lanzar Sonar y realizar la revisión estática del código.
• El Equipo de Explotación de Sistemas de Información obtendrá los binarios para llevar a cabo la gestión de despliegues en los diferentes entornos (preproducción, producción y formación).

Enterprise Architect

Enterprise Architect es una herramienta CASE para el diseño y construcción de sistemas de software, para el modelado de procesos de negocios, y para objetivos de modelado más generalizados. Trabaja con el análisis y diseño UML comprensivo, cubriendo el desarrollo de software desde la obtención de los requisitos, diseño del modelo, pruebas, cambio de control y mantenimiento para la implementación, con completa trazabilidad.

A continuación se describe la finalidad para la que se puede utilizar Enterprise Architect en la operativa de trabajo.

• Gestión de los requisitos. El Equipo de Proyecto deberá registrar en Enterprise Architect todos los requisitos que se decidan abordar desde el proyecto, con el fin de mantener la trazabilidad de los mismos durante el ciclo de vida completo del proyecto.
• Generación de documentación a partir de plantillas previamente definidas para cada tipo de documento.

OVCTIC

La OVCTIC es la Oficina Virtual de Coordinación de las TIC de la Junta de Andalucía. Es un portal de publicación del estado de los proyectos TIC de carácter horizontal de la Junta de Andalucía y el punto de referencia para el personal con competencias TIC. El portal OVCTIC está soportado en el Gestor de Contenidos Drupal. A continuación se describe la finalidad para la que se utilizará la OVCTIC en la operativa de trabajo de la OPSH:

• Publicación de la ficha de proyecto. En la OVCTIC se deberá publicar una ficha descriptiva de cada uno de los proyectos horizontales que se lleven a cabo. En ficha ficha se deberá presentar, entre otra, la siguiente información: descripción, objetivos, estado, licencia, empresa proveedora, etc.
• Publicación de noticias relacionadas con:
• Lanzamiento de un nuevo proyecto. Al inicio de proyecto se deberá publicar en la OVCTIC una noticia en la que se comunique el proyecto que se va a iniciar, así como una breve descripción del mismo. Se deberá hacer referencia a la ficha descriptiva del proyecto que deberá estar disponible en la OVCTIC.
• Temas de interés relacionados con los proyectos. Durante el ciclo de vida del proyecto, cuando se alcancen hitos relevantes, ante la celebración de eventos, etc. se deberá comunicar en la OVCTIC para asegurar que el personal con competencias TIC está informado de los avances de cada uno de los proyectos TIC de carácter horizontal de la Junta de Andalucía.
• Liberación en el Catálogo de Software de la Junta de Andalucía. Se deberán comunicar en la OVCTIC las nuevas versiones que se vayan liberando en el Catálogo de Software de la Junta de Andalucía.
• Información general relacionada con las TIC (entorno corporativo).
• Publicación de convocatorias de formación. Se deberá publicar en la OVCTIC la convocatoria de formación de los diferentes cursos que se se vayan a impartir. Además se deberá hacer referencia al material de formación, que deberá estar publicado en la plataforma de formación (o en la OVCTIC en caso de no disponer de plataforma de formación).

Agatav2

Aplicativo de Agenda Compartida con interfaz amigable, que permite el uso de todas sus funcionalidades de una manera sencilla, integral y completa. Principalmente se pretende potenciar la organización de citas tanto desde una perspectiva de uso individual como, en próximas versiones, de grupo, permitiendo el envío de convocatorias en las que participen empleados de la Junta de Andalucía que dependen de diferentes organismos. A continuación se describe la finalidad para la que se puede utilizar Agata en la operativa de trabajo:

• Gestión de citas. Durante la ejecución del proyecto se deberán ir realizando reuniones de seguimiento de forma periódica, y reuniones de trabajo según se estimen oportunas. Dichas reuniones deberá ser convocadas desde Agata con el fin de que los participantes puedan aceptar/rechazar la convocatoria. Además, es posible compartir los calendarios, lo que permite conocer la disponibilidad de los distintos participantes, y así poder agendar las reuniones con mayor facilidad.
• Gestión de contactos. Como parte de la operativa diaria, se podrá consultar el listín corporativo de contactos, así como crear, editar y borrar contactos de libretas de direcciones.

Acciones y Roles

A continuación se presenta, a modo de resumen, las acciones a realizar en cada una de las herramientas, así como los roles que intervienen en cada una de ellas.

Naos

Herramienta de Gestión de Proyectos

Redmine

Verifica

Alfresco

Subversion

Hudson

Enterprise Architect

OVCTIC

AgataV2