Oficina técnica en un departamento de informática de las AAPP

PROYECTO FINAL DE CARRERA OFICINA TÉCNICA EN UN DEPARTAMENTO DE INFORMÁTICA DE LAS AAPP TITULACIÓN: Ingeniería Informática Autora: María Mauri Esteras Directora: María Carmen Penadés Gramage Tutora en la empresa: María Luisa Alemany López Dedicado a mis padres, Miguel Angel y Elisa AGRADECIMIENTOS Bueno, por fin estoy aquí, hoy es Miércoles 24 de Septiembre son las 21.00 de la noche y dentro de unos días, en cuanto haya entregado este proyecto final de carrera seré por fin Ingeniera Superior en Informática, una carrera que todos lo que me conocen bien saben lo que me ha costado terminar. En primer lugar me gustaría dar las gracias a mis padres. Porque si no fuera por ellos yo me habría echado atrás hace muchísimo tiempo. A mi padre, porque sé lo importante que es para él que yo haya llegado hasta aquí ¡Gracias papá, lo conseguiste tu pequeña Paulova se ha licenciado!! Y a mi madre porque hay mil formas de ser una buena madre pero ella ha sufrido conmigo todos y cada uno de mis mejores y peores momentos y es insuperable. A mis hermanos Víctor y Carol por el amor y el cariño que me han dado siempre. A Javi porque aunque a veces no lo ha entendido, siempre ha estado ahí. A mi tío Roberto por su paciencia infinita conmigo. A Ainoha por ser mi gran compañera en este viaje que parecía tan interminable y por ser una de esas personas que me encuentre en la situación que me encuentre siempre consigue hacerme reír a carcajadas. Y, en general, a todos mis amigos de la facultad (Jordi, David, Héctor, Luis, Mireya, Víctor, Carlos Alberto, Alex,….) por hacerme pasar los mejores años de mi vida. A todo el equipo de calidad de Capgemini, las quality girls, por darme la oportunidad de trabajar y aprender con ellas y en particular a Marisa por su confianza en mí. A Mª Carmen por aceptar dirigirme este proyecto. Muchísimas gracias a todos. Resumen En el presente proyecto se ha desarrollado un modelo de Oficina Técnica viable y útil para un departamento de informática de una Administración Pública, aportando para ello el diseño de un marco general que podría servir de prototipo para la implantación de una Oficina Técnica en el ámbito de la e-Administración. Se ha realizado un análisis de las diferentes metodologías de desarrollo de software existentes hoy en día y de los procedimientos generales que sigue la administración pública a la hora de contratar un proyecto, y en base al mismo, se ha realizado una propuesta de modelo de Oficina Técnica. Dicho modelo no es sólo teórico, sino que se han descrito las distintas partes de que se compone y se ha dado soporte a las mismas mediante una herramienta colaborativa, así como un conjunto de posibles mejoras. El modelo propuesto y el desarrollo realizado contiene las bases poder implantar una Oficina Técnica que consiga guiar a los responsables de un proyecto determinado a la par que adaptarse a las necesidades específicas que el proyecto requiera. El proyecto se ha realizado en el marco de las prácticas en una empresa de consultoría, concretamente en el equipo de calidad. Palabras clave: Gestión de Proyectos, Oficina Técnica, Calidad, Métrica 3, Administraciones Públicas. INDICE DE CONTENIDOS NºPág. INTRODUCCIÓN .......................................................................................................... - 15 - 1. Introducción ........................................................................................................ - 17 - 1.1 Motivación................................................................................................... - 17 - 1.2 Objetivos ..................................................................................................... - 19 - 1.3 Estructura del documento ........................................................................... - 20 - PRELIMINARES ............................................................................................................ - 21 - 2. Marco de trabajo ................................................................................................. - 23 - 2.1 Métrica V3 ................................................................................................... - 23 - 2.1.1 Definición de Proyecto .......................................................................... - 23 - 2.1.2 Fases ...................................................................................................... - 24 - 2.1.3 Actividades de Gestión de Proyectos .................................................... - 26 - 2.1.3.1 Actividades de Inicio del Proyecto .................................................. - 29 - 2.1.3.2 Actividades de Seguimiento y Control ............................................ - 32 - 2.1.3.3 Actividades de Finalización ............................................................. - 43 - 2.1.4 Participantes .......................................................................................... - 44 - 2.2 Oficina Técnica ............................................................................................ - 49 - 2.2.1 Nacimiento de las Oficinas Técnicas ...................................................... - 49 - 2.2.2 ¿Por qué una OT? .................................................................................. - 50 - 2.2.3 Tipos de Oficinas Técnicas ..................................................................... - 50 - 2.2.4 Ventajas de una OT ................................................................................ - 52 - 2.2.5 Oficina Técnica y Administración Pública .............................................. - 53 - 2.2.5.1 Administración electrónica ............................................................. - 53 - 2.3 Empresa ....................................................................................................... - 55 - 2.4 Planificación ................................................................................................ - 56 - DESARROLLO .............................................................................................................. - 59 - 3. Propuesta Oficina Técnica ................................................................................... - 61 - 3.1 Fases ............................................................................................................ - 62 - 3.2 Definición de Modelo de Gobierno ............................................................. - 68 - 3.2.1 Definición de Roles y Responsabilidades ............................................... - 69 - 3.2.2 Definición de Comités ............................................................................ - 71 - 3.3 Definición de Proyecto. Líneas de Trabajo y Procedimientos ..................... - 74 - 3.2.1 Gestión en la Organización y Recursos de los proyectos ...................... - 74 - 3.2.2 Seguimiento, Coordinación y Control .................................................... - 76 - 3.2.3 Gestión de riesgos ................................................................................. - 77 - 3.2.4 Gestión de incidencias ........................................................................... - 79 - 3.2.5 Gestión de Cambios ............................................................................... - 80 - 3.2.6 Apoyo a la comunicación y gestión del cambio ..................................... - 81 - 4. Tecnología ........................................................................................................... - 83 - 4.1 Microsoft Office SharePoint ........................................................................ - 84 - 4.2 Alfresco ........................................................................................................ - 86 - 4.3 Drupal .......................................................................................................... - 88 - 4.4 Decisión de Tecnología ................................................................................ - 91 - 5. Prototipo de Diseño ............................................................................................ - 93 - 5.1 Modelo de Gobierno ................................................................................... - 93 - 5.1.1 Matriz RECI de Roles y Responsabilidades ............................................ - 94 - 5.1.2 Reunión de Comité de la Oficina Técnica .............................................. - 97 - 5.1.3 Reunión de Comité de Seguimiento de los Proyectos ........................... - 98 - 5.1.4 Reunión de Comité de Gestión Operativa ............................................. - 99 - Oficina Técnica en un Departamento de Informática de las AAPP Página - 16 - Oficina Técnica en un Departamento de Informática de las AAPP Página - 17 - Capítulo 1 1. Introducción En primer lugar destacar que el desarrollo del proyecto se realiza en colaboración con la empresa Capgemini, S.L., donde la autora del mismo está realizando prácticas en empresa. 1.1 Motivación Dentro del ámbito del desarrollo de los Sistemas de Información, el actual entorno de evolución de las nuevas tecnologías supone un reto relevante para los departamentos de informática que se suman al proceso. Este entorno, competitivo dentro de la empresa privada, cobra también importancia en las Administraciones Públicas (en adelante AAPP) donde el reto es Acercar la Administración a los Ciudadanos a través de la Ley 11/2007 [LY-11], de 22 de JUNIO de ACCESO ELECTRÓNICO DE LOS CIUDADANOS A LOS SERVICIOS PÚBLICOS. El tiempo actual, tiene como uno de sus rasgos característicos la revolución que han supuesto las comunicaciones electrónicas. En esa perspectiva, una Administración a la altura de los tiempos, tiene que acompañar y promover en beneficio de los ciudadanos el uso de las comunicaciones electrónicas. Al servicio del ciudadano, la Administración pública queda obligada a transformarse en una administración electrónica regida por la Ley 11/2007. Los departamentos o áreas de informática de las AAPP (tanto grandes administraciones como entidades locales) tienen un número de recursos finito. Con estos recursos deben de generar y desarrollar las nuevas necesidades de productos que se convierten muchos de ellos en el desarrollo de proyectos de software con tecnologías y enfoques punteros. Oficina Técnica en un Departamento de Informática de las AAPP Página - 18 - Proceso Procedimientos Herramientas Personas Sin embargo, hay proyectos que no acaban en presupuesto o tiempo o que no logran los resultados esperados. Una solución para asegurar una adecuada gestión de los mismos y que se cumpla con los plazos establecidos, las calidades acordadas dentro de los presupuestos estimados y la satisfacción del cliente, es introducir dentro del departamento de informática de la entidad una “Oficina Técnica/Oficinas Técnicas.” liderada por los responsables del departamento. Hoy en día las Oficinas Técnicas (OT) han llegado a ser un elemento importante en la organización de proyectos. Una OT es esencial para obtener un buen rendimiento de los mismos y para prevenir problemas. La OT actúa como un centro de información, y da soporte a la organización de los proyectos como órgano de gobierno. Puede estar ubicada en diferentes niveles de la organización gestionando un solo proyecto (grande), un programa de varios proyectos o un portafolio de múltiples programas/proyectos. La principal ventaja de implementar una OT es la de asegurar a la organización la calidad del proyecto, aportando para ello una metodología de gestión y de desarrollo de software que permitirá tener un mayor control sobre la gestión y la administración de los recursos y actividades. De hecho, es muy amplio el alcance de lo que una OT puede o debería hacer para una organización, pero siempre debe aportar tres beneficios clave a la organización de los proyectos: Estructura, Control y Transparencia. El diseño de una Oficina Técnica de éstas características considera como relevantes los tres vértices que siempre se han de considerar en cualquier proyecto bajo una metodología de calidad y que se muestran en la figura 1. Estas líneas de trabajo están descritas en el manual de calidad interna de la empresa donde se realizan las prácticas [CAP-2008]: Figura 1. Líneas de trabajo de un proyecto de calidad Personas: Son la pieza clave del éxito. Deben estar formadas y concienciadas. El eje de Personas requiere un modelo bien definido de roles y responsabilidades Procedimiento: Compendio escrito y gráfico del proceso, identificando los pasos y estados a seguir. Es importante que estos procedimientos estén basados en una metodología de desarrollo software, para abordar las líneas de trabajo que tienen relación directa con la gestión de proyectos. Herramientas: Simples o complejas, deben soportar el proceso. Capgemini ha desarrollado numerosos proyectos de consultoría en la Administración Pública, con un equipo dedicado en exclusiva al sector. La experiencia adquirida proporciona a Oficina Técnica en un Departamento de Informática de las AAPP Página - 19 - la empresa un profundo conocimiento de los retos y de la problemática del Sector Público, un sector cuya evolución no es sólo tecnológica sino que incluye aspectos estratégicos, organizativos, operativos y, por supuesto, tecnológicos. Trabaja conjuntamente con los principales organismos, tanto a nivel nacional, autonómico como local. Es por ésta razón que el desarrollo del presente proyecto, pueda ser motivo de un especial interés por parte de la empresa. 1.2 Objetivos El objetivo de este proyecto es desarrollar un modelo de OT viable y útil para un departamento de informática de una AAPP, aportando para ello el diseño de un marco general que podría servir de prototipo para la implantación de una Oficina Técnica en el ámbito de la e-Administración. Trataremos de dar un concepto muy detallado del significado de una Oficina Técnica y demostrar los beneficios que éstas nos aportan. Este objetivo general se desglosa en los siguientes subobjetivos: 1) Estudio de la metodología de gestión de proyectos y creación del marco teórico del proyecto. Realizando un análisis de las diferentes metodologías de desarrollo de software existentes hoy en día y de los procedimientos generales que sigue la administración pública a la hora de contratar un proyecto, se elegirá la metodología más adecuada y se elaborará un marco teórico sobre esta metodología y otros aspectos relacionados con el concepto de Oficina Técnica. 2) Realizar una propuesta de modelo de Oficina Técnica. Una vez sentadas las bases teóricas sobre qué es una Oficina Técnica se presentará la propuesta de Oficina Técnica describiendo las partes de las que esta se compone. 3) Estudio de herramientas colaborativas. Una vez se ha definido qué es lo que se quiere desarrollar, se necesita una herramienta que dé soporte. Para ello se hará un estudio de las diferentes herramientas existentes en el mercado y se escogerá la que más se ajuste. 4) Diseño del modelo. Elegida la herramienta más apropiada y definido el prototipo, se diseña la Oficina Técnica. 5) Especificación de propuestas de mejora. Finalizado el proyecto, se observará que por falta de tiempo o cualquier otro motivo, no se ha podido implementar todo lo deseado. Por ello, se escribirá un apartado con posibles propuestas de mejora para el futuro. Oficina Técnica en un Departamento de Informática de las AAPP Página - 20 - Consiguiendo éstos objetivos, se tendrán las bases para poder implantar una Oficina Técnica que consiga guiar a los responsables de un proyecto determinado a la par que adaptarse a las necesidades específicas que el proyecto requiera. Dado que la autora del presente proyecto está realizando las prácticas en una empresa de consultoría, concretamente en el equipo de calidad, que está plenamente relacionado con el tema del proyecto como objetivos personales se destacarían: 1) Desarrollar el proyecto de tal forma que pudiera ser implantado incluso en la misma empresa. 2) Fijar las bases teóricas del concepto de oficina técnica, conceptos que son utilizados en el trabajo diario al que se dedica la autora en la empresa donde desarrolla las prácticas. 3) Adquirir formación en metodologías de desarrollo y control de calidad de proyectos. 1.3 Estructura del documento A continuación se detalla la estructura del presente documento; compuesto por 7 capítulos y 1 anexo: En primer lugar, a modo de introducción (capítulo 1) se explica la motivación que ha dado lugar a este proyecto, los objetivos perseguidos y la manera en que éste está estructurado. Seguidamente, se desarrolla el marco teórico de trabajo (capítulo 2) en el que se explica entre otras cosas qué es la gestión de proyectos, qué es una oficina técnica y demás cuestiones teóricas detalladas más adelante en el propio capítulo. En el capítulo 3, se detalla la propia propuesta de oficina técnica. Una vez comprendido qué es y qué debe tener, se da una propuesta de cómo podría ser. Más adelante, en el capítulo 4, se discute sobre las tecnologías empleadas, hablando de pros y contras de cada una y finalmente se explica el porqué de la decantación por una determinada. En el capítulo 5, se diseña la oficina técnica. Se trata de la implementación del sistema especificado en el capítulo 3. Posteriormente, en el capítulo 6, se detallan las conclusiones obtenidas tras todo el trabajo realizado, así como las propuestas que se considera que mejorarían la oficina técnica diseñada en el apartado anterior. Por último en el capítulo 7 se presenta la Bibliografía y un anexo con el manual de usuario de la OT desarrollada. PRELIMINARES Oficina Técnica en un Departamento de Informática de las AAPP Página - 22 - Oficina Técnica en un Departamento de Informática de las AAPP Página - 23 - Capítulo 2 2. Marco de trabajo Puesto que se trata de definir una oficina técnica, como preliminares consideramos de interés definir qué es un proyecto, cuáles son sus fase, entradas y salidas de forma general. Son varios los estudios que se pueden encontrar en relación a la gestión de proyectos [CHY-2002], [CRA1999] pero el siguiente apartado está basado el estándar Métrica V3 [MET-3]. Métrica es una metodología de desarrollo elaborada por el Consejo Superior de Informática del Ministerio de Administraciones Públicas. Métrica tiene ya varios años de vida y su actual versión, la 3, se crea con la finalidad de incorporar las nuevas técnicas derivadas de la programación y el análisis orientado a objetos, al proceso de desarrollo de software que a través de esta metodología las administraciones públicas españolas pretenden llevar a cabo. Métrica está presente en la mayoría de los contratos de desarrollo de software que realiza la administración pública, sin embargo su uso aún no está lo suficientemente universalizado; todavía es frecuente ver concursos públicos donde no se establece la obligatoriedad para el contratante de seguir las pautas de Métrica a la hora de llevar a cabo un proceso de construcción de software 2.1 Métrica V3 2.1.1 Definición de Proyecto Para seguir adelante se debe definir uno de los protagonistas de este texto: el Proyecto. Un proyecto es un conjunto de recursos interrelacionados cuyo objetivo es entregar uno o más productos de desarrollo software a un cliente o usuario final. Un proyecto consta de un principio definido y típicamente se desarrolla de acuerdo a un plan. Este plan es Oficina Técnica en un Departamento de Informática de las AAPP Página - 24 - frecuentemente documentado y especifica qué ha de ser entregado o implementado, los recursos y materiales que necesita, el trabajo a realizar y la planificación detallada para abordar este trabajo. 2.1.2 Fases Métrica tiene un enfoque orientado al proceso, ya que la tendencia general en los estándares se encamina en este sentido y por ello, se ha enmarcado dentro de la norma ISO12.207 [ISO-12.207], que se centra en la clasificación y definición de los procesos del ciclo de vida del software. Como punto de partida y atendiendo a dicha norma, Métrica cubre el Proceso de Desarrollo y el Proceso de Mantenimiento de Sistemas de Información. Ha sido concebida para abarcar el desarrollo completo de Sistemas de Información sea cual sea su complejidad y magnitud, por lo cual su estructura responde a desarrollos máximos y deberá adaptarse y dimensionarse en cada momento de acuerdo a las características particulares de cada proyecto. La metodología descompone cada uno de los procesos en actividades, y éstas a su vez en tareas. Para cada tarea se describe su contenido haciendo referencia a sus principales acciones, productos, técnicas, prácticas y participantes. El orden asignado a las actividades no debe interpretarse como secuencia en su realización, ya que éstas pueden realizare en orden diferente a su numeración o bien en paralelo, como se muestra en los gráficos de cada proceso. Sin embargo, no se dará por acabado un proceso hasta no haber finalizado todas las actividades del mismo determinadas al inicio del proyecto. Así los procesos de la estructura principal de Métrica quedan reflejados en la figura 2 y son los siguientes: Figura 2. Procesos Métrica 3 Planificación de Sistemas de Información PSI Desarrollo EVS ASI DSI CSI IAS Mantenimiento de Sistemas de Información MSI Aseguramiento de la Calidad Gestión de Proyecto Gestión de Configuración Seguridad PROCESOS INTERFAZ INTERFAZ INTERFAZ INTERFAZ Oficina Técnica en un Departamento de Informática de las AAPP Página - 25 - El enfoque del Proceso de Planificación de Sistemas de Información, al no estar dentro del ámbito de la norma ISO-12.207, de Procesos del Ciclo de Vida de Software, se ha determinado a partir del estudio de los últimos avances en este campo, la alta competitividad y el cambio a que están sometidas las organizaciones. El entorno de alta competitividad y cambio en el que actualmente se encuentran las organizaciones, hace cada vez más crítico el requerimiento de disponer de los sistemas y las tecnologías de la información con flexibilidad para adaptarse a las nuevas exigencias, con la velocidad que demanda dicho entorno. La existencia de tecnología de reciente aparición, permite disponer de sistemas que apoyan la toma de decisiones a partir de grandes volúmenes de información procedentes de los sistemas de gestión e integrados en una plataforma corporativa. Métrica ayuda en la planificación de sistemas de información facilitando una visión general necesaria para posibilitar dicha integración y un modelo de información global de la organización. En cuanto al Proceso de Desarrollo de Sistemas de Información, para facilitar la comprensión y dada su amplitud y complejidad se ha subdividido en cinco procesos: ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS): La finalidad es proponer una solución a las necesidades que tenga en cuenta restricciones técnicas, económicas, legales y operativas. Los proyectos que se propongan como solución pueden afectar a los sistemas en funcionamiento. Para la definición de esos proyectos se identifican los requisitos a satisfacer y se estudia la situación actual. A partir del estado inicial, la situación actual y los requisitos se estudian las alternativas de solución y se describen indicando sus requisitos. ANÁLISIS DEL SISTEMA DE INFORMACIÓN (ASI): El objetivo es obtener una especificación que responda a las necesidades de los usuarios y se pueda emplear como entrada para el diseño. DISEÑO DEL SISTEMA DE INFORMACIÓN (DSI): Los objetivos del diseño son definir la arquitectura, el entorno tecnológico, especificar los componentes del sistema de información. CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN (CSI): Se escribe el código del sistema, se desarrollan los procedimientos de operación y seguridad, se escriben los manuales de usuario y de explotación, se realizan las pruebas: unitarias, de integración y de sistema, se define la formación del usuario, se construyen los procedimientos de migración y de carga de datos. IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA (IAS): El objetivo es que el sistema sea aceptado por el cliente y que empiece a funcionar. Desde el enfoque de la norma ISO-12.207, el Proceso de Mantenimiento de Sistemas de Información comprende actividades y tareas de modificación o retirada de todos los componentes de un sistema de información (hardware, software, software de base, operaciones manuales, redes, etc.). Este marco de actuación no es el objetivo de Métrica Versión 3, ya que esta metodología está dirigida principalmente al proceso de desarrollo del software. Por lo tanto, Métrica refleja los aspectos del Mantenimiento, correctivo y evolutivo, que tienen relación con el Proceso de Desarrollo. Oficina Técnica en un Departamento de Informática de las AAPP Página - 32 - Los recursos del proyecto se especifican mediante la Estructura de Descomposición de Trabajo y la planificación de actividades y tareas del método PERT [PERT] y el Diagrama de Gantt, que se complementa con la Asignación de recursos, Histograma de recursos, Patrón de límites o la Planificación de actividades y recursos. Tarea GPI 2.5 Presentación y Aceptación de la Planificación General del Proyecto El Comité de Dirección había aprobado con anterioridad la Solución Propuesta junto con las normas y criterios que deben regir su desarrollo. El objetivo de esta tarea es la presentación de la Planificación General del Proyecto al Comité de Seguimiento para su aprobación. 2.1.3.2 Actividades de Seguimiento y Control El seguimiento y control del proyecto tiene como objetivo fundamental la vigilancia de todas las actividades de desarrollo del sistema. Es una de las labores más importantes en todo desarrollo de sistemas, ya que un adecuado control hace posible evitar desviaciones en costes y plazos, o al menos detectarlas cuanto antes. Para poder ejercer un correcto seguimiento y control del proyecto es necesario que el Jefe de Proyecto dedique todo el tiempo que sea preciso a vigilar el estado de cada una de las tareas que se están desarrollando, prestando especial interés a aquellas que están sufriendo algún retraso. En el momento en que se detecta cualquier desviación hay que analizar las causas para poder efectuar las correcciones oportunas y recuperar el tiempo perdido. Las Actividades de Seguimiento y Control de un proyecto se llevan a cabo desde la asignación de las tareas hasta su aceptación interna por parte del equipo de proyecto, previa a la aceptación del Cliente. Las tareas propias del Seguimiento y Control del proyecto se realizan a medida que se ejecutan las distintas tareas de los procesos de Análisis, Diseño, Implementación, Pruebas, Validación y Mantenimiento del Sistema. Actividad GPS 1: Asignación detallada de tareas El objetivo de esta actividad es la asignación de tareas a los miembros del equipo de proyecto, documentando los datos necesarios para su control posterior. Esta actividad contempla una única tarea la cual se muestra en la tabla 3. Es una labor que habrá que realizar para que todas las tareas que figuran en la Planificación detallada del proyecto (GPI 2), tengan asignado personal del equipo de proyecto para su desarrollo. Tarea Productos Técnicas y Prácticas Participantes GPS 1.1 Asignación de tarea - Ficha de asignación de tarea:  Identificador de la tarea en la planificación  Nombre de la tarea  Descripción de la tarea  Fecha prevista Asignación de recursos - Jefe de Proyecto Oficina Técnica en un Departamento de Informática de las AAPP Página - 33 - Tarea Productos Técnicas y Prácticas Participantes de comienzo  Esfuerzo estimado  Fecha prevista de terminación Tabla 3. GPS 1 Asignación detallada de tareas Tarea GPS 1.1 Asignación de Tarea El Jefe de Proyecto debe velar por el cumplimiento de la planificación establecida y que las tareas se vayan realizando según el calendario previsto, ya que de lo contrario se producirán desviaciones en el desarrollo del proyecto que en último término supondrán un incremento en su coste. Para que una tarea finalice con éxito es importante asignarla a un técnico capaz de desarrollarla, por lo que el Jefe de Proyecto debe estudiar muy bien cada tarea antes de su asignación y ser consciente de los conocimientos y capacidades de los componentes del equipo de proyecto. El Jefe de Proyecto debe reflejar en la planificación las asignaciones realizadas, indicando el nombre del técnico, nombre y descripción de la tarea, esfuerzo estimado, fecha real de comienzo y fecha prevista de finalización. Actividad GPS 2: Comunicación al equipo del proyecto Una vez que el Jefe de Proyecto dispone de la asignación de tareas, convoca una reunión para informar al equipo de proyecto de las características del mismo y comunicar a cada miembro las tareas específicas que va a desarrollar. Esta actividad se muestra en la tabla 4: Tarea Productos Técnicas y Prácticas Participantes GPS 2.1 Informar al equipo de Proyecto Reuniones - Jefe de Proyecto - Equipo de Proyecto Tabla 4. GPS 2 Comunicación al equipo de del Proyecto Tarea GPS 2.1 Informar al equipo del Proyecto El Jefe de Proyecto informa a los integrantes del equipo de las características del proyecto, haciendo especial énfasis en sus características particulares: estándares de desarrollo diferentes de los habituales, y peculiaridades en materia de calidad, seguridad y gestión de la configuración. Una vez que todos los miembros del equipo conocen el proyecto global, comunica la asignación de trabajos a cada uno de los miembros, quienes se ocupan de su realización. Actividad GPS 3: Seguimiento de Tareas Esta actividad tiene como objetivo el control de todas las tareas que están siendo desarrolladas, revisando con cada uno de los responsables de las tareas cuál es su estado en el momento del seguimiento, su evolución previsible y los problemas que están encontrando para su desarrollo. La utilización de herramientas automatizadas que existen en el mercado Oficina Técnica en un Departamento de Informática de las AAPP Página - 34 - puede facilitar el seguimiento de las tareas, contrastando la situación en que se encuentran con la prevista en la planificación del proyecto. En la tabla 5 se especifican las tareas que comprende esta actividad. Tarea Productos Técnicas y Prácticas Participantes GPS 3.1 Seguimiento de Tareas - Fichas de seguimiento de tareas - Entrevistas - Jefe de Proyecto - Equipo de Proyecto Tabla 5. GPS 3 Seguimiento de Tareas Tarea GPS 3.1 Seguimiento de Tareas El seguimiento se lleva a cabo revisando el estado de cada tarea con el miembro del equipo asignado para su realización y verificando su estado con los responsables de dichas unidades de trabajo. El responsable de cada tarea debe informar de: - La fecha real de comienzo. - El tiempo empleado hasta el momento en su realización. - Apreciación del tiempo que queda para terminarla. - El tanto por ciento de avance sobre el total. - Los problemas o incidencias encontradas. Para calcular el porcentaje de avance, el responsable de la ejecución de una tarea no debe tener en cuenta el esfuerzo previsto para su realización, sino el tiempo empleado y su apreciación del tiempo que le queda para terminarla. Por ejemplo: una tarea tiene prevista su realización en 64 horas; si se realiza el seguimiento cuando van empleadas 24 horas en su desarrollo y la opinión del técnico es que lleva un 25% de avance, significa que la tarea tendrá una desviación positiva (retraso) de 32 horas, mientras que si su grado de avance es del 75%, tendrá una desviación negativa (adelanto) de 32 horas; en el primer caso, el esfuerzo total final será de 96 horas, mientras que en el segundo será de 32 horas. A partir de la información obtenida del equipo de desarrollo, el Jefe de Proyecto debe determinar el estado de cada tarea, indicando la previsión de finalización de cada una. Asimismo, debe prestar atención a las incidencias y desviaciones, positivas y negativas, encontradas por el equipo de desarrollo, ya que puede existir una fuente de problemas que precise atención inmediata. Gestión de Incidencias Dentro de las actividades de Seguimiento y Control se trata de manera especial la Gestión de Incidencias, que puede ser la clave del éxito o fracaso de un proyecto. Incidencias son aquellos hechos inesperados y anómalos que se presentan durante la realización de las actividades y tareas del proyecto, y que producen desviaciones en la planificación. Ejemplos de incidencias que se pueden presentar en un proyecto son los retrasos en la entrega de un software, fallos en la infraestructura de desarrollo, enfermedad de alguien del equipo de proyecto, etc. Mención especial merecen los cambios de requisitos, ya que son un tipo especial de incidencia que exige un tratamiento especial, motivo por el cual se abordan aparte. Oficina Técnica en un Departamento de Informática de las AAPP Página - 35 - Las siguientes actividades se realizarán en el caso de que durante el seguimiento de tareas (GPS 3.1) se detecte alguna incidencia, y luego se seguirá con la actividad GPS 10. Actividad GPS 4: Análisis y Registro de la Incidencia Con esta actividad se persigue conocer el impacto producido por una incidencia en cuanto a: - Tareas afectadas por la incidencia. - Horas de trabajo perdidas. - Retrasos ocasionados. Para ello es necesario realizar la tarea expresada en la tabla 6. Tarea Productos Técnicas y Prácticas Participantes GPS 4.1 Analizar Impacto - Fichas de incidencia  Impacto sobre tareas  Impacto en horas  Impacto en fechas - Jefe de Proyecto - Equipo de Proyecto GPS 4.2 Propuesta de Solución de la Incidencia - Fichas de incidencia  Solución propuesta - Jefe de Proyecto - Equipo de Proyecto GPS 4.3 Registrar la Incidencia - Registro de incidencias - Catalogación - Jefe de Proyecto Tabla 6. GPS 4 Análisis y Registro de la Incidencia Tarea GPS 4.1 Analizar Impacto Es fundamental conocer que tareas se verán afectadas por una incidencia, en mayor o menor grado, para poder realizar una evaluación del coste de la misma. Para ello ha de realizarse un estudio cuidadoso de todos los trabajos que puedan verse implicados, directa o indirectamente, como consecuencia de cualquier problema y que tendrán que volverse a realizar. Una vez identificadas las tareas a las que afecta la incidencia se evalúa su impacto en términos de: - Horas necesarias para resolverla. - Retrasos previstos. - Recursos afectados. Tarea GPS 4.2 Propuesta de Solución de la Incidencia Dependiendo del tipo de incidencia se plantean posibles alternativas de solución, por ejemplo incorporar más miembros al equipo de proyecto, asumir el retraso que pueda ocasionar su resolución compensándolo con la realización de tareas en un tiempo inferior al previsto, cambiar la estrategia si se trata de una incidencia grave, etc. Oficina Técnica en un Departamento de Informática de las AAPP Página - 36 - El Jefe de Proyecto elegirá entre las alternativas propuestas la forma de solucionar la incidencia, designando en su caso al miembro o miembros del equipo de proyecto encargados de realizar los trabajos que conlleve su resolución. De acuerdo con la solución adoptada habrá que revisar y ajustar la planificación del proyecto en la actividad Actualización de la Planificación (GPS 10). Tarea GPS 4.3 Registrar la Incidencia El objetivo de esta tarea es doble: por una parte se intenta resaltar los sucesos que inciden negativamente sobre el desarrollo del proyecto para que se adopten las medidas necesarias de forma que no vuelvan a producirse o, al menos, que se reduzcan en la mayor medida posible, y por otra parte para que los costes originados por dichas incidencias sean imputados a quien corresponda. Al registrar la incidencia se deja constancia de todos aquellos sucesos que han dificultado o imposibilitado el desarrollo normal del sistema. Se pretende con ello documentar los retrasos generados en el desarrollo del proyecto y los motivos que los han provocado, evitándose una imputación indebida como consecuencia de las incidencias y que el responsable directo o indirecto de la anomalía tome las medidas necesarias para evitar que se repitan. Toda incidencia producida durante el desarrollo del proyecto debe reflejarse en el Registro de Incidencias, de manera que pueda apreciarse con rapidez cualquier problema habido durante el desarrollo. Gestión de Cambio en los Requisitos Los cambios de requisitos constituyen el último recurso al que acudir para resolver un problema, y no deberían presentarse. No obstante, si durante el desarrollo se solicitan cambios de requisitos deben plantearse al Comité de Seguimiento. La inclusión de las modificaciones pertinentes se someterá a la aprobación del Comité de Seguimiento, previo análisis del impacto en la planificación y el coste asociado. Los acuerdos alcanzados se registrarán mediante actas. La Gestión del Proyecto de desarrollo precisa de un mecanismo formal que analice el tratamiento que se aplicará en el caso de que surjan variaciones en los requisitos o nuevos requerimientos durante el desarrollo del sistema, con posterioridad al proceso de Análisis del Sistema de Información. Uno de los propósitos del establecimiento de procedimientos para la Gestión de Cambios en los Requisitos es el de asegurar que, cuando existan cambios en los requerimientos, su impacto en el proyecto pueda cuantificarse y acordarse con el Cliente o Usuario en cuanto a plazo, esfuerzo y compensación económica si corresponde. Todos los cambios de requisitos que se produzcan durante el desarrollo de un proyecto se mantendrán debidamente clasificados en un documento específico, el Registro de Cambios, donde se anotarán todas las peticiones de cambio realizadas por los usuarios. Además, para cada cambio, se registrará la siguiente información: Oficina Técnica en un Departamento de Informática de las AAPP Página - 37 - - Formulario de Petición de Cambio. - Catálogo de Necesidades. - Análisis Funcional del Cambio. - Estimación de Esfuerzo. - Variaciones en Coste y Plazos. Es importante mencionar que las actividades de control y seguimiento de los cambios de requisitos se diluyen dentro de las actividades normales de seguimiento y control de todo el proyecto. Todos los cambios de requisitos posteriores a la entrega del sistema y su paso a producción se tratan en el proceso de Mantenimiento del sistema de información. Actividad GPS 5: Petición de Cambio de Requisitos La primera actividad en la Gestión de Cambios es la petición realizada por el usuario para alterar las especificaciones iniciales. En la tabla 7 se especifica la tarea que comprende esta actividad. Tarea Productos Técnicas y Prácticas Participantes GPS 5.1 Petición de Cambio de Requisitos - Registro de Cambios  Formulario de Petición de cambio - Catalogación - Usuario - Jefe de Proyecto Tabla 7. GPS 5 Petición de Cambio de Requisitos Tarea GPS 5.1 Registro de la Petición de Cambio de Requisitos El usuario formula una petición de cambio de los requisitos iniciales, que hace llegar al Jefe de Proyecto. Esta petición debe ser tan expresiva y completa como sea posible para facilitar la labor de análisis y evaluación. Cuando el Jefe de Proyecto recibe una Petición de Cambio debe registrarla de inmediato, de forma que no pueda pasar desapercibida. Actividad GPS 6: Análisis de la Petición de Cambio de Requisitos Toda petición de cambio debe ser analizada en detalle por el Equipo del Proyecto, contemplando los posibles cambios en la funcionalidad y el impacto que el cambio pedido tendría sobre el resto del Sistema de Información. En la tabla 8 se expresan las tareas que componen esta actividad. Tarea Productos Técnicas y Prácticas Participantes GPS 6.1 Estudio de la Petición de Cambio de Requisitos - Registro de Cambios  Catálogo de necesidades - Catalogación - Entrevistas - Usuario - Equipo del Proyecto GPS 6.2 Impacto de la Petición de Cambio - Registro de Cambios  Catálogo de - Las propias de Análisis y - Equipo del proyecto Oficina Técnica en un Departamento de Informática de las AAPP Página - 38 - Tarea Productos Técnicas y Prácticas Participantes de Requisitos necesidades Diseño GPS 6.3 Estudio de Alternativas y Propuesta de Solución - Registro de Cambios  Propuesta de Solución - Sesiones de trabajo - Jefe de Proyecto - Equipo del Proyecto Tabla 8. GPS 6 Análisis de la Petición de Cambio de Requisito Tarea GPS 6.1 Estudio de la Petición de Cambio de Requisitos El Jefe de Proyecto entrega la petición de cambio al Equipo del Proyecto para su estudio. El miembro del equipo encargado de realizarlo deberá mantener las entrevistas necesarias con el usuario para aclarar todas las dudas y poder efectuar un análisis completo. Tarea GPS 6.2 Impacto de la Petición de Cambio de Requisitos Una vez conocidas las nuevas necesidades, el Equipo del Proyecto por medio de sus analistas realizará un análisis funcional de alto nivel de los nuevos requerimientos y el correspondiente diseño técnico a grandes rasgos, ya que es necesario contemplar ambos para poder estimar adecuadamente el esfuerzo de desarrollo que conlleva. Tarea GPS 6.3 Estudio de Alternativas y Propuesta de Solución A partir del Análisis Funcional y Diseño Técnico obtenido en la tarea anterior, el Jefe de Proyecto y el Equipo de Proyecto estudiarán las posibles alternativas de solución, considerando para cada alternativa los recursos, esfuerzo, tiempo y coste que supone, presentando la más adecuada al Comité de Seguimiento para su aprobación. Actividad GPS 7: Aprobación de la Solución Esta actividad tiene como objeto que el Comité de Seguimiento considere la solución propuesta en la actividad anterior y decida sobre la procedencia o improcedencia del cambio de requisitos. En la tabla 9 se resume la tarea que comprende esta actividad. Tarea Productos Técnicas y Prácticas Participantes GPS 7.1 Aprobación de la Solicitud - Registro de Cambios  Aprobación / Rechazo de la solicitud - Comité de Seguimiento - Jefe de Proyecto Tabla 9. GPS 7 Aprobación de la Solución Tarea GPS 7.1 Aprobación de la solución Es necesario que el Comité de Seguimiento esté de acuerdo con los costes que el cambio va a ocasionar y con la dilatación que se producirá en los plazos de entrega. Como consecuencia de esta evaluación pueden darse cuatro posibilidades: Oficina Técnica en un Departamento de Informática de las AAPP Página - 39 - El Comité de Seguimiento rechaza la petición. En este caso la petición se archiva como rechazada indicándose los motivos. El Comité de Seguimiento estima que la petición es necesaria pero que el coste o la dilatación son excesivos. Se pide al Equipo del Proyecto que revise las condiciones. El Comité de Seguimiento aprueba la petición. En este caso se desarrolla como se había previsto. El Comité de Seguimiento aprueba la petición pero decide aplazar su desarrollo hasta otro momento. Actividad GPS 8: Estimación del Esfuerzo y Planificación de la solución Una vez aprobada la petición de cambio de requisitos y previo a iniciar el desarrollo de la solución, es preciso estimar con mayor detalle el esfuerzo que el cambio supone y planificar las actividades necesarias para la realización del cambio de requisitos. En la tabla 10 aparecen las tareas en que se descompone esta actividad. Tarea Productos Técnicas y Prácticas Participantes GPS 8.1 Estimación de Esfuerzo para el Cambio - Registro de Cambios  Estimación de Esfuerzo.  Variaciones en Coste y Plazos -Estimación - Equipo del Proyecto GPS 8.2 Planificación de los Cambios - Planificación General del Proyecto  Planificación de las actividades. -Planificación - Jefe de Proyecto Tabla 10. GPS 8 Estimación del esfuerzo y Planificación de la solución Tarea GPS 8.1 Estimación de Esfuerzo para el Cambio A partir de la solución aprobada para la petición de cambio, es necesario hacer una estimación del esfuerzo requerido para llevarla a cabo. Para ello habrá que realizar las mismas operaciones que en la actividad GPI 1, pero con una importante característica que es fundamental tener en cuenta: cuando se pide un cambio, se pueden dar las siguientes circunstancias: La parte del sistema que hay que modificar está totalmente desarrollada. En este caso la estimación del esfuerzo para el cambio es neta. La parte del sistema que hay que modificar está parcialmente desarrollada. En este caso hay que descontar el esfuerzo correspondiente a la parte no desarrollada en la estimación original del total del esfuerzo estimado para el cambio. La parte del sistema que hay que modificar está sin desarrollar. En este caso hay que descontar el esfuerzo correspondiente en la estimación original del total del esfuerzo estimado para el cambio. Oficina Técnica en un Departamento de Informática de las AAPP Página - 40 - Tarea GPS 8.2 Planificación de los Cambios Una vez hecha la estimación del esfuerzo es necesario planificar las actividades necesarias para la realización del cambio, de la misma forma que en la actividad GPI 2.4 o la GPS 11.1, utilizando la técnica de planificación más apropiada. Actividad GPS 9: Registro del Cambio de Requisitos En la tabla 11 siguiente se especifica la tarea que comprende esta actividad. Tarea Productos Técnicas y Prácticas Participantes GPS 9.1 Registro del cambio de Requisitos - Registro de Cambios  Solución Adoptada -Catalogación - Jefe de Proyecto Tabla 11. GPS 9 Registro del Cambio de Requisitos Tarea GPS 9.1 Registro del Cambio de Requisitos Al registrar el cambio de requisitos se deja constancia de la solución adoptada en respuesta a la solicitud de cambio de requisitos. Se pretende con ello documentar en detalle su impacto en el desarrollo del proyecto. Todo cambio de requisitos producido durante el desarrollo del proyecto debe reflejarse en el Registro de Cambios de Requisitos, de manera que pueda apreciarse con rapidez cualquier variación sobre los requisitos iniciales habido durante el desarrollo. Actividad GPS 10: Finalización de la Tarea La única tarea que compone esta actividad se muestra en la tabla 12: Tarea Productos Técnicas y Prácticas Participantes GPS 10.1 Comprobación de la tarea - Ficha de asignación de tarea - Jefe de Proyecto - Equipo de Proyecto Tabla 12. GPS 10 Finalización de la Tarea Tarea GPS 10.1 Comprobación de la tarea El miembro del equipo del proyecto al que se le ha asignado al desarrollo de una tarea es quien está en disposición de darla por concluida, reflejando en la ficha de asignación de tarea la fecha de finalización y el esfuerzo real empleado. El Jefe de Proyecto, o el responsable del miembro, deberán comprobar que la tarea ha finalizado correctamente, firmando la ficha de asignación de tareas con los datos relativos a su finalización. Actividad GPS 11: Actualización de la Planificación Oficina Técnica en un Departamento de Informática de las AAPP Página - 41 - A medida que se van finalizando las tareas y una vez que son comprobadas habrá que actualizar la planificación, ya que puede que se hayan producido desviaciones sobre la planificación prevista en GPI 2. Además se preparará una previsión de lo que puede ocurrir en el futuro al considerar la nueva situación, y se elaborará un informe de seguimiento que recoja todo lo relacionado con la situación actual del proyecto y las previsiones para el siguiente periodo. En la tabla 13 se especifican las tareas que comprende esta actividad. Tarea Productos Técnicas y Prácticas Participantes GPS 11.1 Actualización de Tareas - Planificación General del Proyecto  Planificación Detallada del Proyecto - Planificación - Jefe de Proyecto GPS 11.2 Obtención de la Extrapolación - Diagrama de extrapolación - Diagrama de extrapolación - Jefe de Proyecto GPS 11.3 Elaboración del informe de seguimiento - Informe de seguimiento en el periodo  Objetivos alcanzados durante el periodo  Incidencias habidas durante el periodo  Análisis de las desviaciones  Previsión actual  Acciones correctoras  Objetivos previstos para el siguiente periodo  Movimiento de recursos: humanos y materiales - Catalogación - Jefe de Proyecto Tabla 13. GPS 11 Actualización de la Planificación Tarea GPS 11.1 Actualización de Tareas Con los datos obtenidos en el Seguimiento de Tareas (GPS 3.1), Gestión de Incidencias (GPS 4.2) y Cambios de Requisitos (GPS 8.2), el Jefe de Proyecto debe actualizar la Planificación detallada del Proyecto para adecuar el estado de cada tarea a la situación real. De esta forma se tendrá una visión de conjunto que será la que habrá que tener en cuenta a la hora de evaluar la marcha del proyecto. Partirá de la Planificación General del Proyecto aceptada en la actividad GPI 2, de la realizada en GPS 8.2 como consecuencia de cambios en los requisitos, o bien de la que haya resultado de esta misma tarea si es que ya ha habido otras actualizaciones anteriores. Tarea GPS 11.2 Obtención de la Extrapolación Oficina Técnica en un Departamento de Informática de las AAPP Página - 48 - Equipo de Proyecto Grupo de Aseguramiento de la Calidad La responsabilidad de los Analistas es elaborar un catálogo detallado de requisitos que permita describir con precisión el sistema de información, para lo cual mantendrán entrevistas y sesiones de trabajo con los responsables de la organización y usuarios, actuando del interlocutor entre estos y el equipo de proyecto en lo que a requerimientos se refiere. Estos requisitos permiten a los analistas elaborar los distintos modelos que sirven de base para el diseño, obteniendo los modelos de datos y de procesos en el caso del análisis estructurado y los modelos de clases e interacción de objetos en análisis orientado a objeto. Así mismo realizan la especificación de las interfaces entre el sistema y el usuario. El Administrador de Bases de Datos participa en la obtención del diseño físico de datos, definiendo la estructura física de datos que utilizará el sistema a partir del modelo lógico de datos normalizado o del modelo de clases, teniendo presentes las características específicas del sistema de gestión de base de datos concreto a utilizar, los requisitos establecidos para el sistema de información, y las particularidades del entorno tecnológico, se consiga una mayor eficiencia en el tratamiento de los datos. Si se va a realizar una migración de datos colabora con el equipo de proyecto estimando los volúmenes de las estructuras de datos implicadas, definiendo los mecanismos de migración y carga inicial de datos y participando activamente en su realización. Una vez que el sistema está en producción se ocupa de la gestión y operativa asociada a las bases de datos y al software en el que están implementadas. Los integrantes del Equipo de Proyecto participan a lo largo de todo el proceso de desarrollo y mantenimiento del sistema de información, si bien su composición puede ir variando en función de las características del proyecto y del proceso que se esté realizando, diferenciando así los Equipos de Implantación, Operación, Mantenimiento, Arquitectura, Soporte Técnico y Seguridad, coordinados por un Responsable de Equipo, cuyas funciones y perfiles están más especializadas para la realización de un proceso o interfaz concreto. El Equipo de Formación es el encargado de preparar e impartir la formación al equipo responsable de la implantación y operación del sistema, para lo cual se encarga de elaborar un plan de formación que incluye los cursos de formación y sus contenidos, así como los recursos humanos y de infraestructura para llevarlo a cabo. Igualmente define el contenido de la formación que deberá recibir el usuario final del sistema, realizando su seguimiento. El Grupo de Aseguramiento de la Calidad, dirigido por el Responsable de Calidad, desarrolla el plan de aseguramiento de calidad específico para el proyecto, reflejando en dicho plan entre otros aspectos las actividades de calidad a realizar (normales o extraordinarias). Participa en la revisión de los productos seleccionados para determinar si son conformes o no a los procedimientos, normas o criterios especificados, comprobando que se han llevado a cabo las medidas preventivas o correctoras necesarias. Este grupo es completamente independiente del equipo de proyecto. Perfil Programador La función del programador, miembro del equipo de proyecto, es construir el código que dará lugar al producto resultante en base al diseño técnico realizado por el analista o analista programador, generando también el código asociado a los procedimientos de Oficina Técnica en un Departamento de Informática de las AAPP Página - 49 - migración y carga inicial de datos. Igualmente se encarga de la realización de las pruebas unitarias y participa en las pruebas de conjunto de la aplicación. 2.2 Oficina Técnica Una Oficina Técnica (OT) es la instancia que presta el servicio que una organización necesita para satisfacer un objetivo en un momento dado. Una OT tiene como objetivo asegurar la adecuada gestión de los proyectos desde una perspectiva estratégica para que se cumpla con los plazos establecidos, las calidades acordadas dentro de los presupuestos estimados y a satisfacción del cliente. Una definición más concreta y que propone el escritor Alejandro Barros [ABA-2007] es: “Marco institucional en el que se establecen las prácticas, herramientas y mecanismos de control unificados que le permiten a la organización gestionar sus proyectos en las distintas etapas en las que estos se encuentran” Desde la OT la dirección de proyectos ofrece a cada miembro del equipo una clara perspectiva sobre el valor del proyecto, el grado de complejidad, la participación de otros miembros, los riesgos asociados y las prioridades. Es la forma de asegurar el éxito y la satisfacción de clientes e interesados, sean estos internos o externos a la organización. Dentro de las ventajas de implementar una OT se destacan que ésta le permitirá a la organización tener un mayor control sobre la gestión y administración de los recursos y las actividades, la utilización de metodologías, técnicas y herramientas actuales, tener control documental sobre todos los aspectos relacionados con los proyectos y soporte documental sobre el conocimiento que se genere en administración de proyectos. Algunas de las características clave de una OT según lo contenido en el PMBOK [PMB2004] son: 1. Identificación y desarrollo de la metodología de dirección de proyectos, de las mejores prácticas y de las normas. 2. Una plataforma guía para directores del proyecto. 3. Repositorio y gestión centralizados para riesgos compartidos y únicos para todos los proyectos, entre otras. 2.2.1 Nacimiento de las Oficinas Técnicas El concepto de OT tiene ya más de medio siglo. Durante las décadas de los setenta y ochenta, las empresas de construcción incorporaron el nuevo concepto de una manera muy activa, pero casi siempre creando la oficina para proyectos grandes pero aislados. Algunas empresas adoptaron la OT para estandarizar y fijar procedimientos y procesos similares en sus proyectos. Posteriormente, al comienzo de los noventa, muchas empresas relacionadas con Tecnologías de Información (IT) y otras industrias, comenzaron a reestructurar progresivamente sus organizaciones de proyectos incorporando la OT, al principio como una entidad “táctica”, o sea capaz de crear normas, procesos y seleccionar herramientas aplicables por igual a todos sus proyectos. Oficina Técnica en un Departamento de Informática de las AAPP Página - 50 - A finales de la década y durante los primeros años del siglo XXI, el concepto de seleccionar los proyectos acordes a los objetivos estratégicos de la organización, creando y gestionando el portafolio de proyectos de la empresa, empezó a introducir en el entorno de Proyectos, el concepto de NGOT (NextGeneration OT). Esta nueva idea incluye una nueva visión para realizar proyectos pensando en el concepto de ‘negocios” más que en el de “procesos”, concentrándose en problemas estratégicos y de comportamiento organizacional y de recursos humanos, más que en procedimientos y procesos tácticos. 2.2.2 ¿Por qué una OT? Cuando las empresas empiezan a tener problemas realizando proyectos, entonces se impone la necesidad de reestructurar su organización. ¿Cuáles son algunos de los síntomas para requerir la instalación de una Oficina Técnica? : Se arrancan demasiados proyectos y se finalizan muy pocos. Los profesionales se ven desmotivados y faltos de liderazgo. Se hace sumamente difícil controlar proyectos, especialmente los más importantes. El rendimiento promedio de nuestros proyectos es deficiente y sigue cayendo más a medida que transcurre el tiempo. Nuevos problemas siguen apareciendo agobiando a nuestros equipos de proyectos, quienes se encuentran continuamente en el rol de apagar fuegos. No hay suficiente tiempo para resolver todos los problemas que surgen. Demasiados problemas se convierten en crisis, algunas irrecuperables. Siempre parecemos estar faltos de recursos, tiempo y presupuesto. ¿Cuál es el proyecto que deberíamos iniciar primero? Los proyectos no están alineados con los objetivos estratégicos de la empresa. Si algunos de estos problemas se manifiestan con demasiada frecuencia en nuestros proyectos, entonces se requiere hacer una reorganización que permita minimizar sus efectos y alcanzar un mayor éxito. 2.2.3 Tipos de Oficinas Técnicas La literatura apunta una diversidad de modelos y funciones que la Oficina de Administración de Proyectos puede asumir, dependiendo de la etapa de evolución de la disciplina en la empresa, del tipo de estructura organizacional, entre otros factores. Hay desde Oficina Técnica que tienen la función única de informar el desempeño de los proyectos hasta aquellos que participan de la definición de las estrategias empresariales y son responsables por el cuerpo de profesionales del área. La OT puede tener un foco apenas en procesos internos (planeamiento, gerencia de personas, ejecución, control de cambios, etc.), pero también puede responsabilizarse por interfaces externas (satisfacción del cliente, etc.). Hay también diferentes nombres, tales como Oficina de Proyectos, Oficina de Soporte a Proyectos, Centros de Excelencia, etc., pero lo que las distingue son los diferentes grados de autoridad y responsabilidad. Casey & Perck [C&P-2001] parten del supuesto de que no existe un único tipo de OT que atienda a todas las necesidades y que se deba evitar un modelo padrón que puede acabar operando como cualquier otro departamento funcional. Diferentes tipos de Oficina Técnica Oficina Técnica en un Departamento de Informática de las AAPP Página - 51 - resuelven diferentes problemas. Para escoger el modelo adecuado se debe tomar en cuenta el nivel de madurez de la gerencia de proyectos en la organización. El autor describe tres tipos de Oficinas, y los problemas que cada una de ellas puede solucionar. Figura 6. Modelos de OT Cuando el problema de la empresa es la confusión causada por diferentes tipos de informes elaborados por diferentes gerentes de proyectos, con jergas variadas, la solución sería la Estación Meteorológica. Este tipo de Oficina apenas informa la evolución de los proyectos, pero no intenta influenciarlos. Así como una estación meteorológica, ésta informa a los pilotos sobre las condiciones del tiempo sobre la dirección que los pilotos están tomando, pero no conduce él mismo el avión, tampoco influencia el vuelo. Su misión es informar. La estación meteorológica no está autorizada a decir a los gerentes de proyectos y a sus clientes cómo y qué hacer. Responde a preguntas tales como: ¿cómo está nuestro proyecto? ¿Cuánto gastamos de nuestro presupuesto hasta aquí? ¿Cuáles son nuestros riesgos? Este tipo de Oficina Técnica también puede ser responsable por mantener una base de datos con documentos históricos de proyectos y lecciones aprendidas. Por otro lado, cuando la organización tiene problemas de entrenamiento de personal (el entrenamiento puede existir, pero no se traduce en aplicación), metodologías caras y poco utilizadas; altos ejecutivos con poca comprensión o visión equivocada sobre gerencia de proyectos; lecciones aprendidas no utilizadas en nuevos proyectos; uso y cambio constantes de cualquier método y herramientas, la Torre de Control parece ser la solución más adecuada. En este caso, el gerente de la OT da la dirección a los gerentes de proyectos. Cada gerente maneja su avión y tiene responsabilidad por el vuelo, pero debe seguir las instrucciones de la torre de control, particularmente durante el despegue y el aterrizaje. Así, los pilotos prestan mucha atención a la torre de control, pues el avión puede caer si las reglas no son seguidas. La Torre de Control establece la metodología de gerencia de proyectos, incluyendo gerencia de riesgo, definición de roles y responsabilidades, comunicación, gestión de objetivos, lecciones aprendidas y herramientas. También es responsable por la consultoría interna, en el sentido de garantizar que la metodología será seguida y por la constante mejora en los procesos. Organizaciones cuyo negocio es hacer proyectos, necesitan estar permanentemente atentas a la capacitación de su personal en gerencia de proyectos. En general, la persona que contrata y trata con los gerentes de proyectos sabe muy poco sobre la función. Por otro lado, es fundamental para la empresa que ellos sean bien seleccionados, bien entrenados y que permanezcan en la empresa. La solución, en este caso, es el Pool de Recursos. La participación del gerente de una OT es bastante fuerte. Igual que en el aire, todos los pilotos deben estar en estrecha consonancia y volando en la misma dirección. Algunos pilotos pueden ser verdaderos ases, otros no tanto, pero el gerente de la Oficina en Gestión de Proyectos es evaluado por el desempeño del pool. Un Pool de Recursos puede ofrecer un Oficina Técnica en un Departamento de Informática de las AAPP Página - 52 - conjunto de gerentes de proyectos con habilidades necesarias para administrar los diferentes tipos de proyectos para los cuales fueron designados, así como una supervisión para garantizar que estas habilidades serán efectivamente aplicadas. Este no es un tipo de estructura que basta implementar y ella andará solita, al contrario, requiere algunos cuidados. El gerente del pool debe ser el responsable de designar los gerentes a los respectivos proyectos y el pool es la única fuente disponible en la empresa. Los ejecutivos no pueden contratar gerentes de proyectos que no sean del pool o, por lo menos, sin consultar al gerente. El gerente del pool es la autoridad máxima en lo que respecta a sus funcionarios. 2.2.4 Ventajas de una OT La utilización de una Oficina Técnica está justificada por los beneficios cuantitativos y cualitativos que ésta aporta. Desde el punto de vista cuantitativo, el sólo hecho de aglutinar los esfuerzos de administración y gestión del programa en un único equipo de trabajo, por sí sólo, resulta atractivo económicamente; ya que, de no ser así, éstos esfuerzos se incrementarían notablemente debido al desarrollo en paralelo de las funciones de la oficina por los correspondientes grupos dependientes de los órganos participantes, lo que su vez dificultaría la obtención de la visión global de la evolución del programa y de sus proyectos. En el plano cualitativo, las principales aportaciones de la Oficina son la generación de valor en materia de gestión del conocimiento, obtenido mediante el desarrollo de los proyectos, y la coordinación de actividades de gestión del cambio. La gestión del conocimiento resulta esencial, pues, cuando se activa un programa de innovación, no sólo se ponen en marcha iniciativas para implantar soluciones tecnológicas u organizativas, también forma parte de los objetivos la capitalización de las buenas experiencias y prácticas derivadas del desarrollo de los programas, para aplicarlas en otros proyectos y tenerlas de referencia en el futuro. Por otra parte, la coordinación de actividades para la gestión del cambio es una garantía, en muchos casos, del éxito de los proyectos; la mejor solución tecnológica, sino va acompañada tras su desarrollo de una gestión de las actividades que faciliten su adaptación al correspondiente entorno organizativo, podría concluir en un estrepitoso fracaso. Una OT puede aportar muchas ventajas a los proyectos de la empresa y en definitiva a toda la organización, tales como: Uso efectivo de recursos, que permite usar escasos y valiosos recursos en más cantidad de proyectos. Practicas de Gerencia de Proyectos estandarizadas. Uso de las mismas metodologías, procesos y herramientas, disminuyendo el tiempo de aprendizaje. Permite establecer un sistema centralizado de seguimiento y control de proyectos, capaces de producir reportes para todos los niveles de la organización que permitan una toma de decisiones rápida y efectiva. La OT permite comunicaciones centralizadas. El conocimiento en gerencia de proyectos está ubicado en una sola entidad y se distribuye adecuadamente a los proyectos que lo requieren. La apropiada recolección y procesamiento de “lecciones aprendidas” alimenta este sistema de conocimiento. Incrementa la cantidad de proyectos exitosos. Reduce costos en la estructura de proyectos, incrementando por tanto los beneficios de la organización. Oficina Técnica en un Departamento de Informática de las AAPP Página - 53 - 2.2.5 Oficina Técnica y Administración Pública La administración en general es consciente de la importancia que tienen las tecnologías de la información para el desarrollo de nuestra sociedad, por lo que está invirtiendo y poniendo en marcha grandes programas para el desarrollo tecnológico de los diferentes sectores de interés: social, empresarial, administrativo. El proceso de modernización de nuestra sociedad y su evolución hacia el nuevo modelo, la Sociedad del Conocimiento, no culmina cuando finaliza el desarrollo técnico de los proyectos, más bien empieza, ya que los proyectos sólo proporcionan la base necesaria para impulsarnos hacia el camino que debemos recorrer. La modernización se materializará cuando los componentes de nuestra sociedad perciban y asimilen los efectos positivos que aporta la aplicación tecnológica, y utilicen las soluciones suministradas por considerarlas eficaces y confiables para desarrollar habitualmente sus actividades cotidianas. Para lograr este objetivo es preciso, una vez desarrollados los proyectos tecnológicos que sirven de impulso, acercar las nuevas soluciones a los componentes de la sociedad a los que van dirigidas (ciudadanos, empresas, colectivos, organizaciones, administración pública, etc.), facilitándoles la comprensión y utilización de las mismas, y generándoles confianza en estas. El cambio no lo hace la tecnología, sino las personas, y las personas sólo cambian sus hábitos y costumbres cuando conocen otras formas, mejores y confiables, para desarrollar las actividades. Los procesos de difusión de las nuevas soluciones y de las facilidades proporcionadas por la tecnología, el desarrollo de experiencias piloto para extender y estimular la concienciación y la confianza de la sociedad en las nuevas soluciones, junto con la observación continuada de los resultados y del impacto, son factores críticos de éxito de las iniciativas, lo que contribuirá a materializar los objetivos del futuro modelo de sociedad; la Sociedad del Conocimiento. 2.2.5.1 Administración electrónica La Sociedad del Conocimiento se identifica claramente en las políticas y directrices europeas que promueven una sociedad abierta y competitiva basada en la economía digital y poniendo especial énfasis en la Administración Electrónica como impulsora para la inclusión y la calidad de vida. Sin duda, las Tecnologías de Información y Comunicación (TIC) han irrumpido con fuerza en la sociedad y están transformando rápidamente la economía y las costumbres en los distintos ámbitos de actuación de la actividad diaria (ocio, trabajo, etc.). Los hábitos de los ciudadanos se adaptan rápidamente a los nuevos servicios que el sector privado les ofrece a través de la red. . En este contexto, la Administración Pública se posiciona como referencia en el liderazgo en calidad e innovación en la prestación de servicios. A corto plazo, para cumplir la legislación, satisfacer las demandas de los ciudadanos y aumentar los niveles de productividad. A medio y largo término, como motor y transmisor a los agentes sociales y económicos para seguir en un proceso de mejora continua que permita a Europa competir en un marco económico globalizado y mantener la Sociedad del Conocimiento. En esta sección, se desarrollarán los antecedentes, líneas y entorno estratégico, así como recursos disponibles en Administración electrónica. Oficina Técnica en un Departamento de Informática de las AAPP Página - 54 - Ámbito Nacional El proceso de transformación que las Administraciones Públicas han experimentado en los últimos años se ha visto claramente reflejado en el desarrollo e implantación de la Administración electrónica. Se han implementado diversos planes de actuación y puesto en marcha toda una serie de iniciativas que persiguen la modernización de los servicios públicos para una mejor y más amplia atención al ciudadano. En junio de 2007, con la aprobación de la Ley 11/2007, se produce un importante punto de inflexión, al obligarse por ley a las Administraciones españolas a poner en línea todos sus servicios públicos y a proveerse de los medios necesarios para que los ciudadanos puedan relacionarse electrónicamente con todos los organismos públicos. Plan Avanza [PAV-2011]: el Gobierno ha aprobado la Estrategia 2011-2015 de Avanza 2 para situar a España como líder en el uso de productos y servicios TIC avanzados. La Estrategia 2011-2015 centra sus esfuerzos en diez objetivos, entre los que se encuentra generalizar la Administración electrónica, y fortalecer el sector de los contenidos digitales. El Real Decreto 1671/2009 [RD-1671] , de 6 de noviembre, tiene por objeto el desarrollo parcial de la Ley 11/2007,de 22 de junio, de Acceso Electrónico de los Ciudadanos a los Servicios Públicos en el ámbito de la Administración General del Estado y los organismo públicos vinculados o dependientes de ésta, en lo relativo a la transmisión de datos, sedes electrónicas y punto de acceso general, identificación y autenticación, registros electrónicos, comunicaciones y notificaciones y documentos electrónicos y copias. El Real Decreto 3/2010 [RD-3], de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica, preaviso en el artículo 42 de la Ley 11/2007, establece la política de seguridad en la utilización de medios electrónicos por las Administraciones Públicas y está constituido por principios básicos y requisitos mínimos que permitan una protección adecuada de la información. El Real Decreto 4/2010 [RD-4], por el que se regula el Esquema Nacional de Interoperabilidad en el ámbito de la Administración Electrónica, previsto en el artículo 42 de la Ley 11/2007 comprende el conjunto de criterios y recomendaciones que deberán ser tenidos en cuenta por las Administraciones Públicas para la toma de decisiones tecnológicas que garanticen la interoperabilidad. Ámbito Autonómico En los últimos años, todas las Comunidades Autónomas han desarrollado múltiples iniciativas de Administración Electrónica. Se han puesto en marcha servicios electrónicos y desarrollado aplicaciones que han impulsado la implantación y extensión de un nuevo concepto de Administración Pública centrada en el servicio al ciudadano. Planes estratégicos. Prácticamente todas las Comunidades Autónomas han desarrollado su propio Plan Estratégico y de actuación para impulsar el desarrollo de la Administración Electrónica en su ámbito territorial. Ámbito Europeo La Estrategia de Lisboa [EDL-2000] supuso el punto de inflexión en el desarrollo de las políticas para el impulso de la Sociedad de la Información en la UE. Sólo las Tecnologías de la Oficina Técnica en un Departamento de Informática de las AAPP Página - 55 - Información podían ser la piedra angular en la construcción de una economía competitiva, dinámica y basada en el conocimiento. Parte de ese impulso, es el desarrollo coordinado de las políticas de Administración Electrónica, que continua en el ámbito de la estrategia Europa (2020). La Estrategia de Lisboa La estrategia de Lisboa para el crecimiento y el empleo se lanzó en el año 2000 como respuesta a la globalización. Su objetivo era que la Comisión Europea y los Estados miembros cooperasen en las reformas dirigidas a generar crecimiento y más y mejores empleos mediante la inversión en capacidades de las personas, la ecologización de la economía y la innovación. El horizonte temporal de la iniciativa era el periodo 2001-2010. Los resultados de la estrategia se vieron afectados por la crisis económica mundial que empezó a gestarse en 2008. Europa 2020 [EUR-2020] Durante la Presidencia Española de la Unión Europea se procedió a hacer un rediseño de la estrategia política de la Unión Europea. Europa 2020 es la estrategia de crecimiento de la UE para la próxima década. En un mundo cambiante, busca que la UE se convierta en una economía inteligente, sostenible e incluyente. Estas tres prioridades que se refuerzan mutuamente, deben ayudar a la UE ya los Estados miembros ofrecer altos niveles de empleo, la productividad y la cohesión social. Concretamente, la Unión ha establecido cinco objetivos ambiciosos - en el empleo, la innovación, la educación, la inclusión social y el clima / energía - que deben alcanzarse para 2020. Cada Estado miembro adoptará sus propias metas nacionales en cada una de estas áreas. Las acciones concretas a nivel europeo y nacional se basan la estrategia. 2.3 Empresa El Grupo Capgemini [CAP-2011] está presente en más de 30 países y es uno de los líderes mundiales en gestión de servicios informáticos. Capgemini España (en adelante, y de forma genérica, Capgemini) tiene como misión “ayudar a nuestros clientes a usar la tecnología de la información del modo más provechoso para su negocio”. Para conseguir cumplir esta misión adapta, casi de manera permanente, su oferta de servicios en función de la demanda del mercado. La estrategia de Capgemini, denominada I³, se articula alrededor de tres conceptos propios denominados: Industrialization: Impulsar nuestras ventajas y fortalezas. Intimacy: Impulsar el acercamientos con los clientes Innovation: Impulsar el valor añadido a los clientes. La colaboración es la piedra angular reconocida de su acercamiento al negocio. Para Capgemini, la colaboración asegura el éxito, siendo pioneros en el desarrollo de metodologías basadas en este principio. Sus clientes han identificado que, lo que hace a Capgemini diferente, es su forma única de trabajar en colaboración, ayudándoles a resolver sus necesidades a través de sus servicios de consultoría, tecnología y outsourcing. El mensaje de fondo es que la colaboración hace más fuerte al cliente, al combinar lo que sabe hacer mejor con lo que Capgemini hace mejor. En Capgemini entienden que cuando un cliente busca ayuda en una firma de Consultoría o Servicios Tecnológicos, su meta final es hacer más fácil su trabajo. El cliente busca a alguien que: Oficina Técnica en un Departamento de Informática de las AAPP Página - 56 - - Le ayude a encontrar rápidamente soluciones que le permitan obtener, lo antes posible, los resultados esperados para lo que dispone de una sólida red de partners que pueden proporcionar el máximo beneficio. - Le escuche y comprenda, pero sin miedo a asesorarle de la forma más simple y constructiva. - Entienda su cultura, independientemente de que opere en un país o en muchos - Que sienta la misma pasión y compromiso con el éxito de su negocio. Para lograrlo, Capgemini ha identificado cuatro factores clave para una colaboración exitosa: Aportación de valor: significa la identificación de los beneficios del proyecto y asegurar que los recursos adecuados, con el nivel adecuado y en el momento adecuado, sean aplicados al proyecto con el fin de crear y capturar el valor de este. Reducción del riesgo: significa comprender las expectativas y el nivel de riesgo del proyecto que percibe el cliente así como gestionar estos riesgos. Optimización de los recursos: significa fomentar la transferencia del conocimiento, en ambas direcciones, durante el proyecto y asegurar que el saber hacer y el soporte necesario para que el valor del proyecto se mantenga estén establecidos al acabar. Alineamiento con la organización del cliente: significa mantener a los equipos del proyecto alineados y asegurar que se aborden las necesidades internas de la organización, de las funcionalidades y de los resultados de la implantación. 2.4 Planificación A continuación, en la figura 7 se muestra un diagrama de Gantt con la planificación general del proyecto, elaborado con la herramienta Microsoft Project 2007 [MS-PRO] Figura 7. Planificación del proyecto Se ha elaborado una planificación estándar mediante la herramienta Microsoft Project, donde aparecen los hitos, fases y actividades. Veamos lo que significan cada una de las columnas: Columna 1: Número identificativos de las diferentes actividades Columna 2: Notas informativas y aclarativas de las actividades a realizar Columna 3: Actividades a realizar. Organizadas según el índice previamente acordado. Columna 4: Tiempo estimado de duración de cada actividad. Oficina Técnica en un Departamento de Informática de las AAPP Página - 57 - Columna 5: Fecha de inicio de la actividad. Columna 6: Fecha de finalización de la actividad. Gráfico con el diagrama de Gantt. El proyecto se comenzó a principios del mes de Febrero 2011 y se entrega el 30 de Septiembre de 2011, lo que hace un total de 174 días de duración total hasta su evaluación. Oficina Técnica en un Departamento de Informática de las AAPP Página - 64 - Determinados los elementos que intervienen en el sistema a desarrollar, su estructura, relaciones, evolución temporal y funcionalidades, el objetivo de esta etapa es tener una descripción detallada del producto informático que satisfaga los requisitos técnicos y funcionales, así como proporcionar una base inicial de condiciones que debe cumplir el producto informático a construir y proporcionar una primera aproximación de cómo se pondrá en producción el producto informático. Es tarea del analista el elaborar una lista con las funcionalidades o casos de uso, (secuencia de interacciones que se desarrollan entre un sistema y sus ejecutores para corroborar que los requisitos tomados son analizables y, posteriormente, diseñables) que soportan los requisitos acordados, dando un nombre descriptivo a cada uno. Para que esta etapa se complete con éxito se debe implementar, como mínimo, un caso de uso por requisito acordado, pues, la finalidad de esta etapa es analizar estos requisitos mediante los casos de uso para comprobar que todos y cada uno de los requisitos tomados son válidos para el diseño del producto. Para finalizar esta etapa con éxito se deberá redactar un documento, que será la salida requerida, especificando la lista de las funcionalidades o casos de uso propuestos y analizados, para poder diseñar, en la siguiente etapa, las pruebas que confirman que los casos de uso especificados son válidos. A este modelo lo denominamos Modelo Funcional. En la figura 11 se presentan los documentos de salida de la fase de análisis. Diseño. DISEÑO - Diagrama de componentes, - Modelo de datos, - Modelo de implementación - Documento de integración - Arquitectura técnica, - Plan de pruebas, - Plan de puesta en marcha, - Plan de formación Figura 12. Fase. Diseño Una vez se sabe qué hacer, se debe determinar la forma de hacerlo (¿Cómo debe ser construido el sistema en cuestión?). Se definirán con detalle las entidades y relaciones de las bases de datos, se seleccionará el lenguaje que se utilizará, el sistema gestor de bases de datos, librerías, configuraciones hardware, redes y comunicaciones. La misión de esta etapa es la de disponer de las instrucciones de cómo se tiene que fabricar el producto informático descrito previamente, de cómo se va a probar, de la formación que se va a impartir y de cómo va a realizarse la puesta en marcha. En esta etapa, entran en juego los diferentes diseñadores del proyecto, que se encargarán de diseñar los modelos y diagramas necesarios para la implementación del producto. Algunos documentos necesarios para la consecución de esta etapa y que serán absolutamente necesarios en la etapa siguiente son: Oficina Técnica en un Departamento de Informática de las AAPP Página - 65 - - Diagrama UML de componentes, donde se pueda tener una visión de los sistemas y componentes software del producto informático a construir, y de sus relaciones con otros sistemas. - Modelo de implementación, donde se detalle cómo se debe desarrollar cada componente del producto informático a construir. - Documento donde se describa cómo integrar el producto informático a construir con otros sistemas. - Modelo de datos UML, donde se detalla cómo se pretende estructurar la información que el producto informático debe gestionar. - Arquitectura técnica de la infraestructura. Es en este momento donde se realiza el diseño de los casos de prueba o Test Case, esto es, un conjunto de condiciones o variables bajo las cuáles el analista determinará si los requisitos acordados son parcial o completamente satisfactorios. A la hora de diseñar estos casos de prueba, se recopilarán todos en un documento llamado Plan de pruebas, donde a cada caso de uso le corresponde, al menos, un caso de prueba. Son los propios diseñadores los que diseñan estos casos de prueba que posteriormente serán probados. Por último, en esta fase también se diseña el plan de puesta en marcha que se desea implantar, además de un posible plan de formación a los usuarios del producto final. Una vez finalizada esta etapa, para poder pasar a la siguiente se deberán tener redactados el plan de pruebas y los documentos donde se especifican los diseños de puesta en marcha y formación, además de los enumerados anteriormente. Estos documentos son las salidas de esta etapa y servirán como entradas para la etapa siguiente. En la figura 12 se presentan los documentos de salida de la fase de diseño. Implementación. Documento con detalle del producto desarrollado IMPLEMENTACIÓN Figura 13. Fase. Implementación Es en esta etapa cuando se comienza a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programación o para un determinado gestor de bases de datos. Durante esta etapa se realizan las tareas que comúnmente se conocen como “programación” que consiste, esencialmente, en llevar a código fuente, en el lenguaje de programación elegido, todo lo diseñado en la fase anterior. Esta tarea la realiza el programador, siguiendo por completo las directrices impuestas en el diseño y en consideración siempre a los requisitos funcionales y técnicos especificados en la primera etapa. En esta etapa, no sólo se crea el producto en sí, sino que además se debe realizar la integración de los recursos necesarios para que el sistema funcione. Oficina Técnica en un Departamento de Informática de las AAPP Página - 66 - En primer lugar, se debe preparar los medios y herramientas necesarios para poder realizar el desarrollo y las pruebas del producto informático que se pretende construir, así como para poder soportar el producto informático una vez terminado y puesto en producción. Una vez se tiene preparado el escenario de actuación se desarrollará el producto informático en sí con todos sus componentes. Con el producto terminado, se ejecutarán pruebas unitarias para comprobar que el producto creado es robusto y fiable. Por último se debe realizar un documento, que servirá de salida, en el que se detallará toda la información acerca del producto desarrollado necesaria para su posterior explotación y mantenimiento. En la figura 13 se presentan los documentos de salida de la fase de Implementación. Pruebas de verificación. PRUEBAS DE VERIFICACIÓN Informe de pruebas realizadas y resultados Figura 14. Fase. Pruebas de Verificación El objetivo de esta etapa es garantizar que nuestro programa hace lo indicado en el diseño, intentando encontrar el mayor número de errores de diseño y codificación. Todos los programas contienen errores: encontrarlos es cuestión de tiempo. Lo ideal es encontrar la mayoría, si no todos, en esta etapa. Serán los propios programadores los que realicen ejecuten pruebas. Las pruebas que se realizan al producto informático pueden ser de diferentes tipos: Pruebas funcionales, son pruebas que se realizan a nivel de cada módulo, aislado del resto, es decir se prueban cada una de las partes en las que está dividido el producto informático por separado. Cada prueba se realiza de modo independiente al resto de pruebas de cada módulo. La idea es escribir casos de prueba para cada función no trivial o método en el módulo de forma que cada caso sea independiente del resto. Pruebas de integración, son aquellas que se realizan una vez que se han aprobado las pruebas modulares. Únicamente se refieren a la prueba o pruebas de todos los elementos unitarios que componen un proceso, hecha en conjunto, de una sola vez. Consiste en realizar pruebas para verificar que un gran conjunto de partes de software funcionan juntos. Como salida de esta etapa, para finalizar exitosamente se puede redactar un informe especificando las pruebas realizadas y sus resultados, que servirá como punto de partida para la etapa de validación e implantación. Oficina Técnica en un Departamento de Informática de las AAPP Página - 67 - En la figura 14 se presentan los documentos de salida de la fase de Pruebas de Verificación. Pruebas de Validación. PRUEBAS DE VALIDACIÓN Informe de pruebas realizadas y resultados Figura 15. Fase. Pruebas de Validación El objetivo de esta etapa es verificar que el sistema desarrollado cumple con los requisitos expresados inicialmente por el usuario. Además se debe asegurar que el producto informático funcione correctamente después de ser ejecutado. Pruebas de aceptación, cuyo objetivo es validar que la aplicación cumple con el funcionamiento esperado; y permitir al usuario de la aplicación que determine su aceptación desde el punto de vista de su funcionalidad y rendimiento. Estas pruebas son definidas por el usuario del sistema y preparadas por el equipo de desarrollo, aunque la ejecución y la aprobación final corresponden al usuario. El alcance de la validación está basado en la complejidad del software. La selección de actividades y tareas a llevar a cabo durante esta etapa deben corresponderse con la complejidad del diseño del software. Es interesante contar con los casos de uso, generados a través de las correspondientes fases previas, que servirán de guía para la verificación de que el sistema cumple con lo descrito por estos. La documentación de la validación debe ser suficiente para demostrar que todos los planes y procedimientos de validación del software se han completado con éxito. En la figura 15 se presentan los documentos de salida de la fase de Pruebas de Validación. Implantación IMPLANTACIÓN Despliegue Figura 16. Fase. Implantación Fase de puesta en marcha del sistema desarrollado comprobando que funciona adecuadamente, ejecuta lo diseñado y responde a las especificaciones que en su momento fueron aprobadas. Oficina Técnica en un Departamento de Informática de las AAPP Página - 68 - En la figura 16 se presentan los documentos de salida de la fase de Implementación. Evolución y mantenimiento. MANTENIMIENTO Producto en servicio Figura 17. Fase. Mantenimiento Finalmente la aplicación resultante se encuentra ya en fase de producción (en funcionamiento para el cliente, cumpliendo ya los objetivos para los que ha sido creada). En esta etapa, el responsable de la aplicación debe agregar nuevas funcionalidades al producto (Evolución), además de corregir los errores que vayan surgiendo (mantenimiento). La mayoría de las veces en que se desarrolla una nueva aplicación, se piensa solamente en un ciclo de vida para su creación, olvidando la posibilidad de que esta deba sufrir modificaciones futuras (que tendrán que producirse con casi completa seguridad para la mayor parte de los casos). Como salida de esta etapa se tiene ya el producto puesto en servicio. En la figura 17 se puede ver un esquema de esta etapa. 3.2 Definición de Modelo de Gobierno La definición del Modelo de Gobierno se muestra en la figura 18 y consiste en dos fases principales: la definición de tres comités que velen por la continuidad del proyecto, y la clara definición de roles y responsabilidades que defina un equipo de trabajo de alto nivel capaz de desarrollar completamente el proyecto. Definición de Comites Comité de Seguimiento de los Proyectos Quincenal Acta de Comité de Seguimiento Comité de la Oficina Técnica Mensual Acta de Comité de la OT Comité de Gestión Operativa del Proyecto Semanal Acta de GO Definición de Roles y Responsabilidades Definición de Roles y Responsabilidades Al principio del proyecto Matriz RECI de roles y responsabilidades Figura 18. Definición de Modelo de Gobierno Oficina Técnica en un Departamento de Informática de las AAPP Página - 69 - 3.2.1 Definición de Roles y Responsabilidades En la mayoría de Proyectos destinados a AAPPs, es común que haya 3 entidades diferenciadas:  OT (Oficina Técnica) compuesta por: Director de la OT, Jefe de Proyecto y el equipo de consultores.  AAPP (Administración Pública): Dentro de la administración pública existe un equipo encargado del desarrollo y la gestión de proyecto compuesto por: Jefe del área de informática, Jefe de proyecto, Equipo informático (analistas, programadores, testers …),y otro equipo encargado de aportar el conocimiento funcional compuesto por: Responsable Funcional y los Usuarios Clave  Proveedor (Empresa particular contratada por la AAPP para llevar a cabo el proyecto) consta de: Director de proyecto, Jefe de proyecto, Equipo informático (analistas, programadores, testers…) Esta estructura se puede ver en la figura 19: Figura 19. Estructura Organizacional A continuación se describen las funciones principales de los roles claves de la Oficina Técnica: Director de la Oficina Técnica: - Es miembro del Comité de la Oficina Técnica y participa en algunos Comités de Seguimiento de los proyectos - Se encarga de definir la Oficina Técnica y apoyar al Jefe de Proyecto de la AAPP - Coordina los diferentes proyectos para garantizar la integración de los mismos - Es el máximo responsable del funcionamiento de la Oficina Técnica por parte del proveedor - Tiene a su cargo el resto de recursos de la Oficina Técnica por parte del proveedor. Jefe de la Oficina Técnica - Es miembro del Comité de la Oficina Técnica - Es miembro de los Comités de Seguimiento de los Proyectos - Monitoriza el funcionamiento diario de la Oficina Técnica y apoya al Director Ejecutivo de la Oficina Técnica - Monitoriza la coordinación de los diferentes proyectos para garantizar la integración de los mismos DESARROLLO Y GESTIÓN DE PROYECTOS CONOCIMIENTO FUNCIONAL OT AAPP (DPTO. DE INFORMÁTICA) PROVEEDOR AAPP Director de la Oficina Técnica Jefe de la Oficina Técnica Consultores Director de Proyecto Jefe de Proyecto Analistas Programadores Testers Jefe del Área de Informática Jefe de Proyecto Analistas Programadores Testers Responsable Funcional Usuarios Clave Oficina Técnica en un Departamento de Informática de las AAPP Página - 70 - - Gestiona las incidencias, riesgos, cambios y la calidad de la Oficina Técnica - Escala decisiones al Director Ejecutivo de la Oficina Técnica - Proporciona información precisa sobre el avance y el estado de los proyectos en el ámbito de la Oficina Técnica - Dispone de la visión global de la Oficina Técnica y se encarga de comunicarlas pertinentemente - Elabora los informes de los Comités de la Oficina y las actas de estas reuniones - Participa en la elaboración de los informes de Comités de Seguimiento de los proyectos. Consultor de la Oficina Técnica - Participa en la elaboración de los informes de los comités de la Oficina Técnica - Colabora en la elaboración de los informes de las Gestiones Operativas. Es centro de la información de incidencias, riesgos y cambios y colabora con el Jefe de Proyecto del proveedor en la elaboración de la parte de Avance del Proyecto. - Elabora los informes de los Comités de Seguimiento - Elabora el acta de las reuniones de los comités de Gestión Operativa y Comités de Seguimiento - Facilita la coordinación de los recursos mediante la coordinación de agendas de las reuniones - Monitoriza el seguimiento de procedimientos de la Oficina Técnica - Escala riesgos, incidencias al Jefe de Proyecto de la Oficina Técnica Proceso: Definición de roles y responsabilidades Entrada: - Salida: matriz RECI de responsabilidades Actividades: 1. Solicitar listado de participantes: El director de la OT solicita al Jefe del Área de Informática un listado de todas las personas y de todas las entidades que participan en el proyecto 2. Proporcionar listado: El jefe del Área de informática envía el listado solicitado 3. Elaborar propuesta documento descripción de roles: Una vez recibido el listado, la OT elabora una propuesta del documento de descripción de roles y las tareas que realiza cada uno. 4. Convocar reunión: la OT hace una convocatoria de reunión con el Jefe del Área de Informática de la AAPP. 5. Asistir a la reunión: El jefe de proyecto de la AAPP se reúne con la Oficina Técnica. 6. Crear Matriz RECI de responsabilidades: La OT elabora la Matriz RECI de responsabilidades. 7. Componer y registrar documento: la OT finaliza la composición del documento y lo registra donde se haya acordado. Oficina Técnica en un Departamento de Informática de las AAPP Página - 71 - Oficina TécnicaAAPP DirectorJefe del Área de Informática Solicitar listado de participantes Elaborar propuesta documento Crear Matriz RECI de resposabilidades Convocar Reunión Asistir a la reunión Componer y registrar documento Matriz RECI Proporcionar listado Doc Figura 20. Definición de Roles y Responsabilidades 3.2.2 Definición de Comités El Modelo de Gobierno de los proyectos que propone la Oficina Técnica descrita en este proyecto se basa en tres Comités con una visión diferente del proyecto que vele por la consecución de éste a diferentes niveles. Esta estructura se ilustra en la tabla 17: QUIÉN QUÉ CUÁNDO Comité de la Oficina Técnica - Jefe del Área de Informática - Jefe de Proyecto (AAPP) - Director de la OT - Jefe de Proyecto de la OT - Responsables funcionales Vela por la correcta ejecución de todos los proyectos en el ámbito de la Oficina Técnica. Cada 8 semanas Comité de Seguimiento de los proyectos - Jefe del Área de Informática - Jefes de Proyectos (AAPP) - Jefe de Proyecto de la OT Coordinación de Avance, Riesgos y cambios. Cada 4 semanas Comité de Gestión Operativa de Proyecto - Jefe de Proyecto (AAPP) - Jefe de Proyecto del Proveedor - Consultor OT Seguimiento detallado del: avance, incidencias, riesgos y cambios. Semanal Tabla 17. Definición de Comités Proceso: Comité de la Oficina Técnica Entrada: último informe de comité de la OT Salida: acta de la reunión Actividades: 1. Estudiar informe de la OT: El jefe de proyecto de la Oficina Técnica antes de acudir a la reunión debe realizar un estudio previo del último informe de comité de la OT. 2. Convocar reunión: el consultor observando el calendario de planificación sugiere una fecha para llevar a cabo la reunión. 3. Confirmar asistencia: por medio del jefe de proyecto todos y cada uno de los participantes en la reunión deben contestar el email enviado por el consultor para confirmar su asistencia 4. Revisar confirmación de asistencia: en los días previos a la fecha de la reunión el consultor revisa que todos los asistentes hayan confirmado su asistencia. Oficina Técnica en un Departamento de Informática de las AAPP Página - 72 - 5. Exponer informe: el día de la reunión: el jefe de proyecto de la OT realiza su exposición del informe. 6. Asistir a la reunión: el jefe de proyecto de la AAPP acude el día citado a la reunión. 7. Elaborar acta: una vez finalizada la reunión, desde la OT se elabora el acta de la misma para posteriormente remitirla a todos los participantes. Consultor Jefe de Proyecto Oficina TécnicaAAPP Jefe de Proyecto Cada dos meses Estudiar Informe de la OT Confirmar asistencia Revisar confirmación de asistencia ¿Todas las confirmaciones? Exponer informe El día seleccionado Elaborar acta Convocar reunión No Acta Sí Asistir a la reunión El día seleccionado Último Informe de la OT Figura 21. Comité de la Oficina Técnica Proceso: Comité de Seguimiento de los Proyectos Entrada: último informe de seguimiento Salida: acta de la reunión Actividades: 1. Estudiar informe de seguimiento: El jefe de proyecto de la Oficina Técnica antes de acudir a la reunión debe realizar un estudio previo del último informe de seguimiento 2. Convocar reunión: el consultor observando el calendario de planificación sugiere una fecha para llevar a cabo la reunión. 3. Confirmar asistencia: por medio del jefe de proyecto todos y cada uno de los participantes en la reunión deben contestar el email enviado por el consultor para confirmar su asistencia 4. Revisar confirmación de asistencia: en los días previos a la fecha de la reunión el consultor revisa que todos los asistentes hayan confirmado su asistencia. 5. Exponer informe: el día de la reunión: el jefe de proyecto de la OT realiza su exposición del informe. 6. Asistir a la reunión: el jefe de proyecto de la AAPP acude el día citado a la reunión. 7. Elaborar acta: una vez finalizada la reunión, desde la OT se elabora el acta de la misma para posteriormente remitirla a todos los participantes. Oficina Técnica en un Departamento de Informática de las AAPP Página - 73 - Jefe de ProyectoConsultor Oficina TécnicaAAPP Jefe de Proyecto Mensualmente Estudiar Informe de seguimiento Confirmar asistencia Revisar confirmación de asistencia ¿Todas las confirmaciones? Exponer informe El día seleccionado Elaborar acta Convocar reunión No Acta Sí Asistir a la reunión El día seleccionado Último Informe de seguimiento Figura 22. Comité de Seguimiento de los Proyectos Proceso: Comité de Gestión Operativa Entrada: último informe de GO Salida: acta de la reunión Actividades: 1. Estudiar informe de GO: El jefe de proyecto de la Oficina Técnica antes de acudir a la reunión debe realizar un estudio previo del último informe de GO. 2. Convocar reunión: el consultor observando el calendario de planificación sugiere una fecha para llevar a cabo la reunión. 3. Confirmar asistencia: por medio del jefe de proyecto todos y cada uno de los participantes en la reunión deben contestar el email enviado por el consultor para confirmar su asistencia 4. Revisar confirmación de asistencia: en los días previos a la fecha de la reunión el consultor revisa que todos los asistentes hayan confirmado su asistencia. 5. Exponer informe: el día de la reunión: el jefe de proyecto de la OT realiza su exposición del informe. 6. Asistir a la reunión: el jefe de proyecto de la AAPP acude el día citado a la reunión. 7. Elaborar acta: una vez finalizada la reunión, desde la OT se elabora el acta de la misma para posteriormente remitirla a todos los participantes. Oficina Técnica en un Departamento de Informática de las AAPP Página - 80 - 11. Registrar incidencia en estado “Cerrada”: finalmente cuando la solución está ok, se cierra la incidencia AAPP Equipo InformáticoJefe de Proyecto Nueva incidencia Proveedor Jefe de ProyectoEquipo Informático Oficina Técnica Consultor Comunicar incidencia Registrar incidencia “Abierta” Asignar responsabilidad Registrar incidencia “Identificada” Desarrollar solución Registrar incidencia “En Proceso” Subir solución a PreProducción Registrar incidencia “Pdte. Validar” Validar Solución ¿Solución Ok? Sí Registrar incidencia “Cerrada” No incidencias incidencias incidencias incidencias incidencias Proponer solución Subir a Producción Figura 28. Gestión de Incidencias 3.2.5 Gestión de Cambios El proceso de Gestión de cambios que monitorizará la Oficina Técnica definido en este apartado puede ser modificado en pro de simplificar y mejorar el proceso global de gestión con el consenso de todas las partes. Se denomina cambio a todo tipo de modificación o extensión que afecte a los trabajos del programa y a su planificación y costes. Puede ser una actualización, una mejora, una extensión o una corrección. El procedimiento de cambios definido cubre los siguientes aspectos:  Gestionar las peticiones de cambio y coordinar sus aprobaciones  Actualizar la planificación del proyecto según los cambios aprobados  Reportar el estado de las peticiones de cambio  Mantener registro de los cambios Proceso: Gestión de cambios Entrada: - Salida: reporte de cambios Actividades: Oficina Técnica en un Departamento de Informática de las AAPP Página - 81 - 1. Comunicar petición de cambio: una necesidad de cambio puede ser detectada por cualquiera de los roles que participan en el proyecto, quién detecte la necesidad de cambio debe comunicarlo al jefe de proyecto de la AAPP, al jefe de proyecto del proveedor y a la Oficina Técnica. 2. Registrar petición de cambio “Abierta”: La oficina técnica realiza el registro de la petición de cambio. 3. Solicitar detalle: la OT solicita al Jefe de Proyecto del proveedor el detalle de la petición de cambio 4. Procesar detalle: el jefe de proyecto del proveedor con la supervisión del Jefe de proyecto de la AAPP será quién cumplimente la información del detalle del cambio con la información necesaria para la evaluación de la petición 5. Registrar petición de cambio “en proceso”: la oficina técnica realiza el registro de la petición de cambio. 6. Valorar petición de cambio: el Proveedor da una aproximación en costes con lo que valora la petición y remite esta información a la OT para que ésta la registre. 7. Evaluar petición de cambio: En la reunión de seguimiento con potestad para aprobar o desestimar el cambio, se evaluará la necesidad del cambio. Para su evaluación se tendrán en cuenta factores económicos, plazos, recursos, imposiciones legales, etc. 8. Registrar petición de cambio “Evaluada”: La OT dará soporte a la toma de decisiones en la aprobación / desestimación del cambio, dando pautas para objetivar la decisión. Además registrará el resultado de la evaluación y las acciones asociadas en caso de que las hubiera. 9. Abordar petición: Si se aprueba la petición de Cambio, se definirán una serie de acciones encaminadas a que se aborde la petición para su implementación. AAPP Jefe de Proyecto Necesidad del cambio Proveedor Jefe de Proyecto Oficina Técnica Consultor Comunicar petición de cambio Registrar petición de cambio “Abierta” Registrar petición de cambio “Evaluada” cambios cambios Solicitar detalle Procesar detalle Supervisar detalle detalle Necesidad del cambio Comunicar petición de cambio Registrar petición de cambio “En Proceso” cambios Valorar petición valoración Registrar petición de cambio “Valorada” cambios Evaluar petición ¿Aprobada? Abordar petición Sí No Figura 29. Gestión de cambios 3.2.6 Apoyo a la comunicación y gestión del cambio Proceso: Apoyo a la comunicación y gestión del cambio Entrada: - Salida: Calendario de Formaciones Actividades: Oficina Técnica en un Departamento de Informática de las AAPP Página - 82 - 1. Elaborar propuesta de calendario de formación: cuando el sistema está finalizado, el director de la OT elabora una propuesta con el calendario de formación para usuarios, proveedores... 2. Estudiar Propuesta: desde la AAPP se estudia está propuesta y se hacen los comentarios oportunos. 3. Componer Documento: finalmente y después de haber revisado los comentarios del jefe del Área de Informática, la OT prepara un documento que contiene el calendario definitivo de formaciones. Oficina TécnicaAAPP DirectorJefe del Área de Informática Elaborar Propuesta de Calendario de Formaciones Estudiar Propuesta Componer documento Calendario de formaciones Calendario de Formaciones Figura 30. Apoyo a la comunicación y Gestión del cambio Oficina Técnica en un Departamento de Informática de las AAPP Página - 83 - Capítulo 4 4. Tecnología A la vista de toda la documentación de entrada/salida que se va a generar después de atravesar cada uno de los procesos descritos en el capítulo anterior, es lógico pensar que necesitemos algún tipo de gestor documental que actúe como biblioteca centralizada de archivos. Además, sería deseable que todos los roles que van a participar en un determinado proyecto, pudieran comunicarse simultáneamente y trabajar de manera conjunta. Una herramienta colaborativa sería lo más conveniente para el caso que nos ocupa en el presente documento. Las herramientas colaborativas, básicamente son los sistemas que permiten acceder a ciertos servicios que facilitan a los usuarios comunicarse y trabajar conjuntamente sin importar que estén reunidos en un mismo lugar físico. En general con ellos se puede compartir información en determinados formatos (audio, texto, video, etc.), y en algunos casos producir conjuntamente nuevos materiales productos de la colaboración. Muchos de ellos proveen de avanzadas funcionalidades que facilitan tareas como publicación de información, búsquedas, filtros, accesos, privilegios, etc.) Por lo general casi todas las herramientas colaborativas tienen un funcionamiento similar, trabajan bajo el concepto de cliente servidor, donde los clientes son los usuarios que hacen uso de un servicio y el servidor se encarga de ofrecer este servicio. Generalmente se utilizan programas clientes para acceder a estos servicios, tal es el caso de un browser que hace las veces de cliente para acceder a un servicio que puede ser por ejemplo un servidor web que “sirve” una página web. Para el presente proyecto se han estudiado varias de estas herramientas, a continuación se hace una breve descripción de cada una de ellas. Oficina Técnica en un Departamento de Informática de las AAPP Página - 84 - 4.1 Microsoft Office SharePoint Office SharePoint [MS-SHA] se encuentra enmarcado dentro de la familia de servidores que forma parte de Microsoft Office System, lo cual permite interconectar distintos productos de office de una forma más amigable. Con office SharePoint se puede hacer uso de una serie de herramientas disponibles que permitirán crear fácilmente sitios que: - Admitan la publicación de contenido específico. - Administren dicho contenido. - Administren los registros. - Satisfagan las necesidades de la inteligencia empresarial de la organización. - Dirijan búsquedas eficaces de personas, documentos y datos. - Permitan diseñar y participar en procesos basados en formularios Características generales Colaboración:  Usar plantillas de sitio para colaborar o celebrar reuniones. Las plantillas del sitio del grupo Colaboración están diseñadas para ayudar a los equipos de una organización a trabajar en los proyectos y colaborar en los documentos.  Compartir documentos, contactos, tareas y calendarios. Utilizando Outlook y Office SharePoint Server.  Intercambiar ideas fácilmente utilizando sitios de Wiki (Colaboración), que le permitirán interactuar en foros de grupos, así como también rescatar información de los mismos.  Recibir actualizaciones en listas y bibliotecas con RSS (Really Simple Syndication) Crear Sitios Personales, en los que se puede: Ver y administrar todos los documentos, las tareas, los vínculos, etc., administrar los calendarios de Microsoft Office Outlook. Administrar los compañeros y la información personal centralizadamente. Buscar personas, conocimientos y datos en las aplicaciones empresariales: Permite buscar datos en una base de datos corporativa y buscar datos en una aplicación empresarial (CRM, Customer Relationship Management). Administrar documentos, registros y contenido Web: Permite desarrollar un proceso para retirar o hacer que caduquen documentos cuando haya transcurrido un período de tiempo determinado. Dentro de las novedades que se observan en Office SharePoint se pueden describir las siguientes: Excel. Con la última versión de SharePoint, los usuarios tendrán la capacidad de poder visualizar la información de un archivo de Excel a través de los Servicios de Excel, y directamente en un navegador (sin restricción del tipo de navegador) y sin tener que depender de una instalación de Microsoft Office Excel en el cliente. Oficina Técnica en un Departamento de Informática de las AAPP Página - 85 - PowerPoint. Es posible compartir ciertas diapositivas en una biblioteca de presentación compartida para poder ver la información directamente en la Web y que se encuentre disponible con el efecto de presentación. Access. Es posible exportar cualquier tabla de Access y publicarla a través de Microsoft Office SharePoint. Word. Brinda la posibilidad de poder publicar cualquier tipo de contenido hacia los blogs de manera muy rápida y sencilla y contando con las posibilidades de formato y diseño que provee Microsoft Word . InfoPath. Compartir un formulario de cualquier tipo de información que un departamento podría requerir. Los empleados de una empresa pueden llenar un simple examen de capacidades relacionado al ERP, o incluso una orden de compra que podría ser compartida mediante un navegador (a través de los Servicios de Formularios Web) para que los proveedores pudieran responderla, o encuestas de satisfacción de clientes de igual forma publicadas a través de un navegador y todo esto almacenado en sitios de colaboración para mantener la información al día e integrada con otro tipo de información de proyectos o procesos. Ahora es claro que no es la única forma de hacerlo, también podemos responder cualquier tipo de formulario con el cliente de InfoPath, pero la ventaja cara de la posibilidad de hacerlo a través de cualquier navegador nos elimina la restricción de contar con licencias de InfoPath en cualquier máquina que fuese a acceder a dicho formulario compartido. Templates. Para crear blogs, wikis, centro de documentación, reporteo, tableros de control, indicadores de desempeño o KPIs, entre otras. WorkFlow. La posibilidad de crear flujos de información por default o WorkFlows Out-OfThe-Box para cualquier biblioteca de documentos o incluso para un archivo individual. Requerimientos del sistema Una instalación de SharePoint Server se puede realizar en un solo computador (instalación Independiente) o en muchos computadores que funcionan juntos (una granja). Los requisitos para la instalación dependen de las cargas que el sistema tiene que satisfacer. Los requisitos descritos son aplicables tanto en sistemas de 32 como de 64 bits (sistemas basados en procesadores Itanium no son soportados). La siguiente tabla indica los mínimos en hardware recomendados para una instalación independiente, incluyendo la instalación de Microsoft SQL Server: Componente Mínimo Recomendado Procesador 2,5 GHz Procesador doble de 3 GHz o mayor RAM 1 GB 2 GB Disco NTFS, 3 GB NTFS con al menos 3 GB libres Monitor 1024 x 768 1024 x 768 o mayor Red 56 Kbps 56 Kbps o mayor entre servidor y clientes La rutina de instalación de Office usa un instalador común para todas las aplicaciones, y el tipo de SharePoint a instalar depende de la clave de licencia que se utilice durante el procedimiento. Esto significa que el código base de todas las instalaciones es igual, y las opciones instaladas dependen de la licencia utilizada. Cuando se hace una instalación Básica, SQL Server es instalado automáticamente. SharePoint necesita Windows Server 2003 con SP1 o mayor como mínimo. Es recomendable que todos los parches críticos estén instalados. Oficina Técnica en un Departamento de Informática de las AAPP Página - 86 - La utilidad de administración de SharePoint necesita Microsoft Internet Explorer 6.0 o 7.0 con los Service Packs más recientes. Después de instalar el sistema operativo con todos los parches necesarios, el computador tiene que ser configurado como un servidor Web activando Internet Information Services (IIS) 6.0, incluyendo los archivos comunes, WWW y el Simple Mail Transfer Protocol (SMTP). Antes de instalar SharePoint se debe instalar el Microsoft .NET Framework 3.0 y asegurarse que ASP.NET 2.0 esta activado. En la figura 31 se muestra una captura de pantalla de un sistema implementado con Microsoft share point. Figura 31. Captura SharePoint 4.2 Alfresco Alfresco [ALF-2011] es un sistema de administración de contenidos libre, basado en estándares abiertos y de escala empresarial para sistemas operativos tipo Unix y Otros. Se distribuye en dos variantes diferentes: - Alfresco Community Edition: Es software libre, con licencia LGPL de código abierto y estándares abiertos. - Alfresco Enterprise Edition: Se distribuye bajo licencia de código abierto y estándares abiertos con soporte comercial y propietario a escala empresarial. Características Generales Facilidad de Uso: - Permite conectarse al gestor documental a través de unidades de red compartidas - Búsqueda similar a Google o a Yahoo. Facilidad de Administración Oficina Técnica en un Departamento de Informática de las AAPP Página - 87 - - Sin instalación en el cliente, únicamente en el servidor - Gestión de los permisos desde un único punto Open Source - Reducción de costes Extensible - Permite el acceso al repositorio a través de Servicios Web, REST, WebScripts, etc ... - Desarrollado con Spring, para garantizar la extensibilidad. - Conexión desde Portales Corporativos, ERPs, CRMs, etc .. Arquitectura Robusta - Arquitectura Escalable y tolerante a fallos Repositorio Completo - Creación de reglas a través de Wizards para transformar el contenido o actuar en función de cambios. - Foros de discusión sobre documentos. - Creación de Flujos de trabajo visualmente. - Auditoría completa. Requerimientos del sistema Para poder instalar Alfresco se requiere previamente: 1. MySQL. 2. Apache Tomcat 3. PHP. En la figura 32 se muestra una captura de pantalla de un sistema desarrollado con Alfresco. Figura 32. Captura Alfresco Oficina Técnica en un Departamento de Informática de las AAPP Página - 88 - 4.3 Drupal Drupal [DRU-2007] es una herramienta colaborativa que actúa como un sistema de gestión de contenido modular y muy configurable. Es un programa de código abierto, con licencia GNU/GPL, escrito en PHP, desarrollado y mantenido por una activa comunidad de usuarios. Destaca por la calidad de su código y de las páginas generadas, el respeto de los estándares de la web, y un énfasis especial en la usabilidad y consistencia de todo el sistema. El diseño de Drupal es especialmente idóneo para construir y gestionar comunidades en Internet. No obstante, su flexibilidad y adaptabilidad, así como la gran cantidad de módulos adicionales disponibles, hace que sea adecuado para realizar muchos tipos diferentes de sitio web. Características generales Ayuda on-line. Un robusto sistema de ayuda online y páginas de ayuda para los módulos del 'núcleo', tanto para usuarios como para administradores. Búsqueda .Todo el contenido en Drupal es totalmente indexado en tiempo real y se puede consultar en cualquier momento. Código abierto. El código fuente de Drupal está libremente disponible bajo los términos de la licencia GNU/GPL. Al contrario que otros sistemas de 'blogs' o de gestión de contenido propietarios, es posible extender o adaptar Drupal según las necesidades. Módulos. La comunidad de Drupal ha contribuido muchos módulos que proporcionan funcionalidades como 'página de categorías', autenticación mediante jabber, mensajes privados, bookmarks, etc. Personalización. Un robusto entorno de personalización está implementado en el núcleo de Drupal. Tanto el contenido como la presentación pueden ser individualizados de acuerdo las preferencias definidas por el usuario. URLs amigable. s Drupal usa el mod_rewrite de Apache para crear URLs que son manejables por los usuarios y los motores de búsqueda. Gestión de usuarios Autenticación de usuarios. Los usuarios se pueden registrar e iniciar sesión de forma local o utilizando un sistema de autenticación externo como Jabber, Blogger, LiveJournal o otro sitio Drupal. Para su uso en una intranet, Drupal se puede integrar con un servidor LDAP. Permisos basados en roles. Los administradores de Drupal no tienen que establecer permisos para cada usuario. En lugar de eso, pueden asignar permisos a un 'rol' y agrupar los usuarios por roles. Gestión de contenido Control de versiones. El sistema de control de versiones de Drupal permite seguir y auditar totalmente las sucesivas actualizaciones del contenido: qué se ha cambiado, la hora y la fecha, quién lo ha cambiado, y más. También permite mantener comentarios sobre los sucesivos cambios o deshacer los cambios recuperando una versión anterior. Oficina Técnica en un Departamento de Informática de las AAPP Página - 89 - Enlaces permanentes (Permalinks). Todo el contenido creado en Drupal tiene un enlace permanente asociado a él para que pueda ser enlazado externamente sin temor de que el enlace falle en el futuro. Objetos de Contenido (Nodos). El contenido creado en Drupal es, funcionalmente, un objeto (Nodo). Esto permite un tratamiento uniforme de la información, como una misma cola de moderación para envíos de diferentes tipos, promocionar cualquiera de estos objetos a la página principal o permitir comentarios -o nosobre cada objeto. Plantillas(Templates). El sistema de temas de Drupal separa el contenido de la presentación permitiendo controlar o cambiar fácilmente el aspecto del sitio web. Se pueden crear plantillas con HTML y/o con PHP. Sindicación del contenido. Drupal exporta el contenido en formato RDF/RSS para ser utilizado por otros sitios web. Esto permite que cualquiera con un 'Agregador de Noticias', tal como NetNewsWire o Radio UserLand visualice el contenido publicado en la web desde el escritorio. Blogging Agregador de noticias. Drupal incluye un potente Agregador de Noticas para leer y publicar enlaces a noticias de otros sitios web. Incorpora un sistema de cache en la base de datos, con temporización configurable. Soporte de Blogger API. La API de Blogger permite que un sitio Drupal sea actualizado utilizando diversas herramientas, que pueden ser 'herramientas web' o 'herramientas de escritorio' que proporcionen un entorno de edición más manejable. Plataforma Independencia de la base de datos. Aunque la mayor parte de las instalaciones de Drupal utilizan MySQL, existen otras opciones. Drupal incorpora una 'capa de abstracción de base de datos' que actualmente está implementada y mantenida para MySQL y PostgresSQL, aunque permite incorporar fácilmente soporte para otras bases de datos. Multiplataforma. Drupal ha sido diseñado desde el principio para ser multi-plataforma. Puede funcionar con Apache o Microsoft IIS como servidor web y en sistemas como Linux, BSD, Solaris, Windows y Mac OS X. Por otro lado, al estar implementado en PHP, es totalmente portable. Múltiples idiomas y Localización. Drupal está pensado para una audiencia internacional y proporciona opciones para crear un portal multilingüe. Todo el texto puede ser fácilmente traducido utilizando una interfaz web, importando traducciones existentes o integrando otras herramientas de traducción como GNU ettext. Administración y Análisis Administración vía Web. La administración y configuración del sistema se puede realizar enteramente con un navegador y no precisa de ningún software adicional. Análisis, Seguimiento y Estadísticas. Drupal puede mostrar en las páginas web de administración informes sobre referrals (enlaces entrantes), popularidad del contenido, o de cómo los usuarios navegan por el sitio. Registros e Informes. Toda la actividad y los sucesos del sistema son capturados en un 'registro de eventos', que puede ser visualizado por un administrador. Oficina Técnica en un Departamento de Informática de las AAPP Página - 96 - Figura 35. Matriz RECI (2/2) Matriz RECI en el ámbito de los proyectos de eAdministración respecto a las actividades de los proyectos: R: responsable del resultado de la actividad E: ejecutor de la actividad C: se le consulta para realizar la actividad I: se le informa para realizar la actividad Responsable Funcional Uusario Clave Jefe del Área de Informática AAPP Jefe de Proyecto Analistas Programadores Testers Director de la Oficina Técnica Jefe de Proyecto de la Oficina Técnica Consultores Director de Proyecto Jefe de Proyecto Analistas Programadores Testers MODELO DE GOBIERNO Actividades PRUEBAS VERIFICACIÓN Disponer del producto informático robusto y fiable y con todos sus componentes bien integrados Desplegar en entorno de integración Disponer del producto desarrollado, configurado e instalado en el entorno de integración Preparar Pruebas de integración Disponer de los escenarios, juegos de datos y automatizaciones necesarias para ejecutar el plan de pruebas Ejecutar pruebas de integración Detectar los defectos y carencias del producto informático Documento del Plan de integración Conforme Aceptación por parte del Responsable del Proyecto de las Pruebas de Integración realizadas PRUEBAS DE VALIDACIÓN / ACEPTACIÓN Obtener la conformidad del producto informático para poder implantarlo en producción Generar Documentación Disponer de toda la información acerca del producto desarrollado necesaria para su posterior explotación y mantenimiento. Preparar entorno de pre-producción Disponer de los medios y herramientas necesarios para probar la puesta en marcha Probar plan de puesta en marcha Disponer del plan de puesta en marcha probado Realizar pruebas de Aceptación Disponer del producto informático validado y aceptado Pruebas de Aceptación Conforme Aceptación por parte del Responsable del Proyecto de las Pruebas de Aceptación realizadas IMPLANTACIÓN - PILOTO Tener el producto informático preparado para ejecutar en el entorno de producción Preparar entorno de Producción Disponer de los medios y herramientas necesarios para ejecutar el plan de puesta en marcha Ejecutar plan de puesta en marcha Dejar el producto en condiciones de ser ejecutado Supervisar sistemas Detectar e Informar las desviaciones del Sistema Informático respecto a los criterios definidos Notificar resumen de indicadores Disponer del resumen de indicadores del periodo definido (incidencias, riesgos, %avance etc) Analizar tendencias Prever las necesidades de modificación del Sistema Informático Atender llamadas Proporcionar el soporte necesario para poder utilizar los productos informáticos, gestión de incidencias, atención al usuario Notificar resultado de incidencias Proporcionar el soporte necesario para poder utilizar los productos informáticos, gestión de incidencias, atención al usuario IMPLANTACIÓN - DESPLIEGUE Tener el producto informático preparado para ejecutar en el entorno de producción Preparar entorno de Producción Disponer de los medios y herramientas necesarios para ejecutar el plan de puesta en marcha Ejecutar plan de puesta en marcha Dejar el producto en condiciones de ser ejecutado Supervisar sistemas Detectar e Informar las desviaciones del Sistema Informático respecto a los criterios definidos Notificar resumen de indicadores Disponer del resumen de indicadores del periodo definido (incidencias, riesgos, %avance etc) Analizar tendencias Prever las necesidades de modificación del Sistema Informático Atender llamadas Proporcionar el soporte necesario para poder utilizar los productos informáticos, gestión de incidencias, atención al usuario Notificar resultado de incidencias Proporcionar el soporte necesario para poder utilizar los productos informáticos, gestión de incidencias, atención al usuario IMPLANTACIÓN - CERRAR PROYECTO Realizar correctamente la transición del proyecto de construcción del producto informático al servicio que se proporciona para su explotación y mantenimiento Supervisar funcionamiento Asegurarse que el producto informático funciona correctamente después de ser ejecutado en el proceso de explotación Cerrar proyecto formalmente Tener el producto listo para ser explotado y mantenido MANTENIMIENTO Realizar el mantenimiento del sistema Investigar y Diagnosticar Conocer los casos que pueden provocar o han provocado una caída de los servicios o una reducción de las calidades, y tener la propuesta de solución para estos casos Analizar el impacto Tener identificados los elementos afectados por los cambios a realizar y adecuar los cambios Realizar mantenimiento Tener las operaciones de mantenimiento realizadas Cerrar Dejar constancia de los trabajos realizados ACTORES AF AAPP Proveedor OT Oficina Técnica en un Departamento de Informática de las AAPP Página - 97 - 5.1.2 Reunión de Comité de la Oficina Técnica OBJETO: Comité que vela por la correcta ejecución de todos los proyectos en el ámbito de la Oficina Técnica. Revisión del estado global de los proyectos, toma de decisiones estratégicas y priorización. PROCEDIMIENTO DE LA REUNIÓN: Como se dibujó en la Figura 12, Cada dos meses, la OT enviará una propuesta de convocatoria de reunión, por medio de su buzón de correo electrónico. Una vez que todos los participantes hayan confirmado la asistencia a la reunión, ésta se llevará a cabo en la fecha determinada. Al finalizar dicha reunión la OT creará el acta con las acciones acordadas para el siguiente periodo. HERRAMIENTA DE SOPORTE: Para dar soporte a esta tarea se ha desarrollado una plantilla para generar éstas actas en .pdf dinámicos por medio de la herramienta Adobe LiveCycle [AD-LC]. Los archivos generados se irán guardando en la biblioteca documental con el formato Acta_ComiteOT_aaaammdd.pdf. Se puede ver una captura de estos documentos en la figura 36: Figura 36. Acta de Comité de la OT COMITÉ OFICINA TECNICA PPP PPP PPP Oficina Técnica en un Departamento de Informática de las AAPP Página - 98 - 5.1.3 Reunión de Comité de Seguimiento de los Proyectos OBJETO: Comité de seguimiento de proyectos que requieran de integración. Se coordina el avance de los proyectos relacionados en un mismo ámbito, se realiza un seguimiento de los Riesgos, Incidencias, Acciones y Cambios. PROCEDIMIENTO DE LA REUNIÓN: Como se dibujó en la Figura 13, mensualmente, la OT enviará una propuesta de convocatoria de reunión, por medio de su buzón de correo electrónico. Una vez que todos los participantes hayan confirmado la asistencia a la reunión, ésta se llevará a cabo en la fecha determinada. Al finalizar dicha reunión la OT creará el acta con las acciones acordadas para el siguiente periodo. HERRAMIENTA DE SOPORTE: Para dar soporte a esta tarea se ha desarrollado una plantilla para generar éstas actas en .pdf dinámicos por medio de la herramienta Adobe Live Cycle. Los archivos generados se irán guardando en la biblioteca documental con el formato: Acta_ComiteSeguimiento_aaaammdd.pdf. Se puede ver una captura de estos documentos en la figura 37: Figura 37. Acta de Comité de Seguimiento COMITÉ DE SEGUIMIENTO PPP Oficina Técnica en un Departamento de Informática de las AAPP Página - 99 - 5.1.4 Reunión de Comité de Gestión Operativa OBJETO: Conocer el estado en detalle del proyecto con el equipo de trabajo, revisando el estado/avance del proyecto, los riesgos/planes de acción, las incidencias y los cambios. PROCEDIMIENTO DE LA REUNIÓN: Como se dibujó en la Figura 14, cada semana, la OT enviará una propuesta de convocatoria de reunión, por medio de su buzón de correo electrónico. Una vez que todos los participantes hayan confirmado la asistencia a la reunión, ésta se llevará a cabo en la fecha determinada. Al finalizar dicha reunión, la OT creará el acta con las acciones acordadas para el siguiente periodo. HERRAMIENTA DE SOPORTE: Para dar soporte a esta tarea se ha desarrollado una plantilla para generar éstas actas en .pdf dinámicos por medio de la herramienta Adobe Live Cycle. Los archivos generados se irán guardando en la biblioteca documental con el formato Acta_ComiteGO_aaaammdd.pdf. Se puede ver una captura de estos documentos en la figura 37: Figura 38. Acta de Comité de GO GESTIÓN OPERATIVA DE LOS PROYECTOS P Oficina Técnica en un Departamento de Informática de las AAPP Página - 100 - 5.2 Desarrollo de los Procedimientos La Oficina Técnica propuesta, con el objetivo de homogeneizar la metodología de trabajo de los proyectos bajo su ámbito de actuación, define una serie de procedimientos concretos para abordar las líneas de trabajo que tienen una relación directa con la gestión de los proyectos: Gestión de Incidencias Gestión de cambios Seguimiento, Coordinación y Control Gestión de Riesgos Gestión de la organización y recursos de los proyectos 2 3 4 5 1 6Apoyo a la Comunicación y Gestión del Cambio Figura 39. Desarrollo de los procedimientos 5.2.1 Planificación Para llevar a cabo una planificación de todos los comités a los que la oficina técnica ha de acudir, se propone utilizar un fichero Excel en el que se mostrará cada una de las reuniones tanto de gestión operativa como de seguimiento de los proyectos y comités de la oficina técnica. Dado que cada una de estas reuniones se apoya en un informe que previamente ha de preparar la oficina técnica, esta tarea se especifica también en la tabla. Por último, es necesario especificar la tarea de convocar dichas reuniones y elaborar el acta al finalizar cada una de ellas. En la figura 40 se puede ver una captura del documento de planificación: Tareas Oficina Técnica Gestiones operativas PG Preparación Informe GO CO Convocatoria de reunión P1 Gestión Operativa Proyecto 1 EG Envio Informe GO AEnvío Acta P2 Gestión Operativa Proyecto 2 PS Preparación Informes Seguimiento ES Envio Informe de Seguimiento CS Comité de seguimiento PO Preparación Informe OT CT Comité de Oficina Técnica EO Envio Informe OT 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 S D L M X J V S D L M X J V S D L M X J V S D L M X J V S D L P1 P2 P1 P2 P1 P2 P1 P2 A A A A A A A A A CO PS CO ES CO CS CO CO CO CO CO CO PG EG PG EG PG EG PG EG PG EG PG EG PG EG PG EG PG EG 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 M X J V S D L M X J V S D L M X J V S D L M X J V S D L M X P1 P2 P1 P2 P1 P2 P1 P2 P1 A A A A A A A A A A A CO CO PS CO ES CO CS CO CO PO CO EO CO CT CO PG EG PG EG PG EG PG EG PG EG PG EG PG EG PG EG PG NOVIEMBRE'11 PROPUESTO OCTUBRE'11 PROPUESTO Figura 40. Planificación de tareas Oficina Técnica en un Departamento de Informática de las AAPP Página - 101 - Los procedimientos de la Oficina Técnica se basan en el Modelo Organizativo y Definición de Proyecto Propuesto (Fases, Estructura, Comités, Roles y Responsabilidades) y se apoyan en un conjunto de documentos de seguimiento que serán la fuente de los datos para el seguimiento a los diferentes niveles. Esta estructura de organización se muestra en la figura 41: Cuadro de Mandos Informe Seguimiento de Proyectos Informe de Gestión Operativa COMITÉ DE SEGUIMIENTO PPP GESTIÓNOPERATIVA DE LOS PROYECTOS P PPP PPP PPP COMITÉ OFICINA TECNICA Figura 41. Niveles de seguimiento Los bloques de datos de cada documento se muestran en la figura 42 y son: Cuadro de Mandos Informe de Seguimiento Informe de Gestión Operativa •Tablas Auxiliares •Tareas por periodo •Avance de Proyecto •Incidencias •Riesgos •Peticiones de Cambios •Observaciones •Identificación de Proyecto •Resumen •Estado Actual •Tendencias por periodo •Históricos •Gráficas •Tablas Auxiliares •Identificación de Proyectos •Resumen •Estado Actual •Tendencias por periodo •Históricos •Gráficas Figura 42. Bloques de datos La estructura de directorios ha de ser de acceso centralizado; Supone tener de raíz el Cuadro de mando, en directorios los proyectos y dentro de cada directorio de proyectos los informes de seguimiento. En la figura 43 se muestra esta estructura: Raíz Cuadro Mando.xls Proyectos Seguimiento Gestión Operativa aaaammdd. xls Informe seguimiento aaaammdd.xls Proyecto 1 Proyecto n Figura 43. Directorio de proyectos Oficina Técnica en un Departamento de Informática de las AAPP Página - 102 - A continuación se va a detallar el contenido de cada uno de los documentos generados en esta fase. Estos documentos han sido elaborados con Excel 2007, apoyándose en el lenguaje Visual Basic [VB-2.6] para generar las diferentes Macros que lo componen. Nota: Los datos con los que se han rellenado estos informes, han sido extraídos de uno de los proyectos que ha desarrollado la Empres en la que la autora del presente trabajo ha realizado las prácticas. 5.2.2 Creación de Informe de Gestión Operativa El informe de Gestión Operativa consta de 8 pestañas, las cuales se detallan a continuación: (Tablas auxiliares) •Estado Incidencias: Abierta Identificada En Proceso Pendiente de Validar Cerrada •Criticidad Incidencias: Alta Media Baja •Estado Riesgos: Abierto Identificado En Proceso Cerrado •Impacto Riesgos: Muy Alto Alto Medio Bajo Muy Bajo •Estado Acciones Incidencias: Identificada En Proceso Pendiente Validar Cerrada •Estado Acciones Riesgos Identificada En Proceso Cerrada •Estado Avance Proyecto Abierto En proceso Paralizado Anulado Cerrado •Roles: Jefe Proyecto Analista Funcional etc. •Estado Peticiones de Cambio Abierto En proceso Valorado Evaluado •Prioridad Peticiones de Cambio Alta Media Baja Oficina Técnica en un Departamento de Informática de las AAPP Página - 103 - (Acta) P002 Portal del Ciudadano Acta Nº OBJETO Desde Hasta Fecha En AGENDA 1 Objetivo de la reunión 2 Aprobación de la reunión anterior 3 Revisar el cumplimiento de las acciones de la reunión anterior 4 Revisar tareas del proyecto periodo actual 5 Revisar Incidencias / Acciones 6 Revisar Riesgos / Acciones 7 Revisar Avance de Proyecto 8 Toma decisiones 9 Determinar Tareas proximo periodo 10 Plan de Acción Jefe Proyecto cliente Eloy Moreno Seguimiento de Proyecto Ivan Cabotà Jefe Proyecto proveedor 16/11/2009 25/11/2009 19/11/2009 Castellon Nombre Rol Entidad Elaborado por Oficina Técnica de Proyectos eAdministración Participantes NOMBRE DEL PROYECTO ACTA DE REUNIÓN DE SEGUIMIENTO 1 Implementacion e implantación completa del Portal del Cuidadano Descripción corta Codigo Proyecto Descripción Nº Responsable Fecha Prevista Acción PLAN DE ACCIÓN Periodo evaluado Nº Acta Fecha del acta de la correspondient e Gestión Operativa Agenda Fija de Gestión Operativa Acciones surgidas de la reunión. Son acciones generales, las particulares asociadas a incidencias o riesgos están en su correspondiente apartado (Avance del proyecto) P002-Portal del Ciudadano Estado Hitos Activ. Entregables Totales Fecha Abiertos 848 864 15/01/2010 En Proceso 1 2 0 3 Paralizado 0 0 0 0 Anulado 0 0 0 0 Cerrados 0 2 0 2 Totales 952 869 Lista desde Actividades de la Definición del Proyecto H: Hito A: Actividad E: Entregable Estado: Abierto En Proceso Suspendido Cerrado Avance: % Avance respecto a duración de la actividad Como mejora para 2011: *Esfuerzo asociado por actividad: -Duración en jornadas --nº Recursos implicados * Importe de presupuesto por actividad Conteo de las actividades por estado. Es utilizado por el documento de Estado Proyecto Fecha del Acta (Gestión operativa) Identificación del Proyecto Fecha Inicio Fecha Fin ID Hito/Actividad/Entregable Prevista Real Prevista Real ESTADO % Prevista Real Desviación Duración Avance Oficina Técnica en un Departamento de Informática de las AAPP Página - 104 - (Tareas por período) Proyecto Fecha Desde: 01/01/2010 Desde: 01/01/2010 Hasta: 15/01/2010 Hasta: 15/01/2010 Tareas /Actividades periodo actual Tareas /Actividades periodo siguiente Responsable Actividad Responsable Actividad Ivan Cabotá Realizar las Pruebas de Aceptación Ivan Cabotá Actualización incidencias y mejoras en producción Revisar las incidencias I001, I0038, I008 15/01/2010 P002-Portal del Ciudadano Periodo Siguiente Periodo Actual Identificación del Proyecto Tareas en detalle previstas del periodo anterior junto con el responsable de la tarea a ejecutar Tareas en detalle previstas del periodo anterior siguiente junto con el responsable de la tarea a ejecutar Periodo Actual/Siguiente (Incidencias) Detección Nº Cuando Quien Criticicidad ESTADO I001 Carlos Izquierdo Fortea Descripción Breve Cuando se utiliza la opción imprimir del trámite de Recogida de enseres a domicilio (me imagino que el error aparecerá en todos los trámites) aparecen unos cuantos ?? ?? ?? sin razón de ser. 16/11/2009 Media Pendiente de Validar Proyecto P002-Portal del Ciudadano Fecha 19/11/2009 Identificación del Proyecto Conteo de las estado de las incidencias Es utilizado por el documento de Estado Proyecto Identificador de la Incidencia: PXXX-IYYY, donde: XXX: código del proyecto YYY: código de la incidencia Ejemplo: P002-I001 Para que la Incidencia sea Identificada ha de estar rellenados los datos de cuando, quien la detectó y que criticidad se le asigna. Nueva Incidencia Botón para crear Nueva Incidencia Alta Media Baja Totales Abiertas 0 0 0 0 Identificadas 0 0 0 0 En Proceso 9 2 0 11 Pendiente Validar 1 2 0 3 Cerradas 0 0 0 0 Totales 10 4 0 14 Criticidad Estado Incidencia Descripción breve pero clara de la incidencia. La documentación con la descripción detallada, pantallazos etc. debería de estar con acceso centralizado en el repositorio a nivel de Proyecto Estado Incidencia: •Abierta: Con la descripción, sin cuando, quien y criticidad •Identificada: Con la descripción, cuando, quien y criticidad •En Proceso: Con al menos una acción en Proceso. •Pendiente Validar: Con todas las acciones Cerradas •Cerrada: Con la incidencia Validada. Oficina Técnica en un Departamento de Informática de las AAPP Página - 105 - Resolución Acciones Estado F Previsto F Real Quien Responsable A1 En Proceso 18/11/2009 Iván Cabotá A2 En Proceso 18/11/2009 Implantación de Indenova A3 Identificada 18/11/2009 Implantación de Indenova < Analisis Causas Se investiga la incidencia y se observa que es un tema de la codificación con la que se interpreta la Pasar a PRO el cambio en la codificación que ya se encontraba en PRE. Ya se ha pasado a PRO Proyecto P002-Portal del Ciudadano Fecha 19/11/2009 Identificación del Proyecto Conteo de las estado de las acciones asociadas a las incidencias. Es utilizado por el documento de Estado Proyecto Alta Media Baja Totales Abiertas 0 0 0 0 Identificadas 0 3 0 3 En Proceso 9 7 0 16 Cerradas 2 0 0 2 Totales 11 10 021 Criticidad Estado Acción Añadir Acción Botón para crear Añadir acción Ax+1 ubicándose en acción Ax Descripción breve pero clara de la acción. Estado Acción: •Identificada: Con la descripción de la acción y quien la crea •En Proceso: Con la descripción, con fecha prevista y el responsable de ejecutar la acción •Pendiente Validar: Acción pendiente validar si procede •Cerrada: Acción validada Análisis detallado de la causa que originó la incidencia Identificador de la Incidencia. Ax Donde: X: valor numérico incremental asociado a la incidencia (Riesgos) Muy Alto Alto Medio Bajo Muy Bajo Totales Abiertos 0 0 0 0 0 0 Identificados 1 1 1 1 0 4 En Proceso 0 0 1 0 1 2 Cerrados 0 0 0 0 0 0 Totales 1 1 2 1 1 6 Estado Riesgo Impacto Detección Nº ID Descripción Breve Consecuencias Cuando Quien Impacto ESTADO P002-R001 Antonio Lujan P002-R002 Pepe 01/01/2010 El proyecto se retrasa por mas de 2 mese Los usuarios eliminan los marcadores de los documentos Posible problema con el texto de las plantillas que indica el firmante en el caso de las delegaciones si no se modifica antes de la firma Cambio en especificacaciones en el core del proyecto 05/01/2010 Muy Alto Abierto Alto Abierto 001 002 Proyecto P002-Portal del Ciudadano Fecha 19/11/2009 Identificación del Proyecto Conteo de las estado de los riesgos. Es utilizado por el documento de Estado Proyecto Estado Riesgo: •Abierto: Con la descripción, sin consecuencias, cuando, quien y el impacto •Identificado: Con la descripción, consecuencias, cuando, quien y impacto •En Proceso: Con al menos una acción identificada. •Cerrado: Con todas las acciones Cerradas Descripción breve pero clara del riesgo Identificador del riesgo: PXXXRYYY donde: XXX: código del proyecto YYY: código de la incidencia Ejemplo: P002-R001 Nº de Riesgos Oficina Técnica en un Departamento de Informática de las AAPP Página - 112 - Jefe de Proyecto del Proveedor (vía email con copia OT). El (3) Registro será realizado por la Oficina Técnica en la hoja de “Riesgos”. Estados de los Riesgos:  Abierto: El riesgo se ha comunicado y se encuentra registrado a falta de asignarle un responsable.  Identificado: Se ha asignado un responsable para la resolución del riesgo  En Proceso: Se han definido acciones para cerrar el riesgo.  Cerrado: El riesgo se ha eliminado. En la figura 45 se muestra un esquema con los estados por los que pasa un riesgo desde que se inicia hasta que se da por cerrado: Identificado En Proceso CerradoAbierto Acciones Identificada En Proceso CerradaAbierta Estados de los Riesgos Estados de Acciones Figura 45. Estados de los riesgos y acciones Estados de las Acciones:  Abierta: Se ha registrado una acción para la eliminación del riesgo a falta de asignarle un responsable.  Identificada: Se identifica al responsable de la resolución.  En Proceso: La acción se está ejecutando.  Cerrada: La acción ha sido ejecutada Oficina Técnica en un Departamento de Informática de las AAPP Página - 113 - Gestión de Incidencias 5.2.6 Procedimiento de Gestión de Incidencias Una incidencia es cualquier circunstancia cuyas consecuencias afectan al normal desarrollo del Programa, es un riesgo previsto o imprevisto que se materializa. El procedimiento que a continuación se describe hace referencia a las incidencias acontecidas en el proyecto en cada una de sus fases, con la excepción del registro de las incidencias en las fases de pruebas de aceptación y el mantenimiento. En la figura 46 se muestra el procedimiento de gestión de incidencias propuesto: Equipo de TrabajoOficina Técnica Responsable Funcional Jefe de Proyecto ProveedorJefe de Proyecto AyC (1) DETECCIÓN Jefe de Proyecto AyC Jefe de Proyecto ProveedorOficina Técnica (3) REGISTRO (2) INFORME: EMAIL Equipo de Proyecto Figura 46. Procedimiento de Incidencias La (1) Detección puede ser realizada por cualquiera de los perfiles que participan en el proyecto. Quien detecte el riesgo debe comunicarlo (2) Informe al Jefe de Proyecto de la AAPP y al Jefe de Proyecto del Proveedor (vía email con copia OT). El (3) Registro será realizado por la Oficina Técnica en la hoja de “Incidencias”. Oficina Técnica en un Departamento de Informática de las AAPP Página - 114 - Estados de las Incidencias  Abierta: La incidencia se ha comunicado y se encuentra registrada a falta de asignarle un responsable.  Identificada: Se ha asignado un responsable para la resolución de la incidencia  En Proceso: Se han definido acciones para solucionar la incidencia.  Pendiente de Validar: Pendiente de Validación  Cerrado: La incidencia se ha cerrado. En la figura 47 se muestra un esquema con los estados por los que pasa una incidencia desde que se inicia hasta que se da por cerrada: Identificada En Proceso Pendiente de Validar Abierta Acciones Identificada En Proceso Pendiente de Validar Abierta Cerrada Cerrada OK OK NOK Estados de Incidencias Estados de Acciones Figura 47. Estados de las incidencias y acciones Estados de las Acciones  Abierta: Se ha registrado una acción para el cierre de la incidencia.  Identificada: Se identifica al responsable de la resolución.  En Proceso: La acción se está ejecutando.  Pendiente de Validar: Pendiente de Validación  Cerrada: La acción ha sido ejecutada Gestión de cambios 5.2.7 Procedimiento de Gestión de Cambios Como se ha definido anteriormente, se denomina cambio a todo tipo de modificación o extensión que afecte a los trabajos del programa y a su planificación y costes. Puede ser una Oficina Técnica en un Departamento de Informática de las AAPP Página - 115 - actualización, una mejora, una extensión o una corrección. En la figura 48 se muestra el procedimiento de gestión peticiones de cambios propuesto: La (1) Necesidad de cambio puede ser detectada por cualquiera de los roles que intervienen en el proyecto. Quién detecte el riesgo debe comunicarlo (2) Informe al Jefe de Proyecto de la AAPP y al Jefe de Proyecto del Proveedor (vía email con copia OT). (3)Registro: La Oficina Técnica registra la petición de cambio y solicita el detalle al proveedor. (3.1)Registro: El Jefe de Proyecto del Proveedor con la supervisión del Jefe de Proyecto de la AAPP registrará el detalle del cambio. (3.2)Registro: Una vez realizado lo envía a la Oficina Técnica para que lo registre. Detalle Cambio Registro Cambio (1) NECESIDAD CAMBIO (3.1) Cumplimentación del detalle del la Solicitud de Cambio DA SOPORTE CONTRASTANADO Oficina Técnica (3.2) Cierre del Detalle de la Solicitud de Cambio Equipo de ProyectoOficina Técnica Jefe de Proyecto ProveedorJefe de Proyecto AAPP Equipo de Proyecto Jefe Proyecto AAPP Jefe de Proyecto Proveedor Oficina Técnica (2) INFORME: EMAIL (3) Registro Solicitud de Cambio SOLICITA EL DETALLE CUMPLIMENTA Figura 48. Procedimiento de gestión de cambios Estados de los Cambios  Abierto: El cambio se ha comunicado y se encuentra registrado.  En Proceso: El cambio está siendo analizado para determinar su alcance y beneficios.  Valorado: El cambio ha sido valorado teniendo en cuenta todo su posible alcance.  Evaluado: Se ha evaluado la necesidad del cambio y se ha tomado una decisión al respecto. En la figura 49 se muestra un esquema con los estados por los que pasa un cambio desde que se inicia hasta que se evalúa: En Proceso Valorado EvaluadoAbierto Figura 49. Estados de los cambios (4) Reporte: En la siguiente reunión operativa se evalúa el cambio, en caso de no tener potestad para aprobarla se escala. Oficina Técnica en un Departamento de Informática de las AAPP Página - 116 - (5) Evaluación: La Oficina Técnica registra el resultado de la evaluación (6) Acciones: Se definen acciones para realizar el cambio en caso de ser aprobado. Apoyo a la Comunicación y Gestión del Cambio 5.2.8 Calendario de Formaciones El calendario de formaciones se utiliza para establecer sesiones o tutorías en las que la Oficina Técnica se encarga de instruir a los diferentes participantes del proyecto, en la utilización de los recursos con los que se va a trabajar. Consiste pues en un acuerdo entre las diferentes partes para concretar fechas. Lo que se muestra en la tabla 19 es una propuesta de ésta formación. Formación Qué A quién Contenido Duración F1 2 sesiones de trabajo. Todos los roles identificados en el equipo de Proyecto. *Descripción detallada del diseño de la O. Técnica *Caso Práctico 1: Definición de un Proyecto *Caso Práctico 2: Práctica de uso de procedimientos de la OT 3h cada sesión F2 1 Sesión por Proyecto. Total 8 sesiones Jefes de Proyecto. Interesante asistencia de Responsable Funcional y Usuario Clave. Por cada proyecto: *Definición de las fases del Proyecto: Hitos, Actividades y Entregables * Definición de la estructura de proyecto: Roles y Responsabilidades 1 hora y media por proyecto F3 1 Sesión por Proyecto. Total 8 sesiones Jefes de Proyecto Preparación del primer informe de Comité de Gestión Operativa 1 hora y media por proyecto Tabla 19. Formaciones Oficina Técnica en un Departamento de Informática de las AAPP Página - 117 - Capítulo 6 6. Conclusiones 6.1. Conclusiones Como se ha descrito en apartados anteriores, es muy amplio lo que una Oficina Técnica puede o debería hacer. La participación de una Oficina Técnica dentro de un proyecto realmente va a venir determinada por sus responsables directos dentro de la figura del cliente para el que se esté trabajando. Sabiendo esto, la Oficina Técnica que se ha propuesto puede abarcar más de lo necesario o por el contrario, quedarse corta. El modelo de OT que se ha desarrollado en el proyecto está basado principalmente en el estándar Métrica 3 de gestión de proyectos ya que es el que se ha considerado más adecuado. No se ha desarrollado en su totalidad porque es muy amplio, pero sí la parte que más aplicación tiene al tema tratado. Se ha encontrado más documentación de la esperada en cuanto a conceptos teóricos de Oficinas Técnicas, de hecho se han encontrado trabajos específicos sobre este tema, como son los trabajos de Ricardo Rodríguez o Rodrigo Zuñiga expuestos en la bibliografía de este documento [CRO-2009] y [RRO-2008]. En cuanto a la propuesta de modelo, el resultado de estudiar un proyecto para el que se estaba trabajando dentro de Capgemini y la metodología aplicada en el marco teórico han establecido las líneas generales de desarrollo de la propuesta. Estas líneas podrían haberse ampliado mucho más hasta el punto de abarcar todas y cada una de las fases de la gestión de proyectos, pero en este caso se ha optado por ayudar a trabajar aquellas que se han considerado más imprescindibles para garantizar un proyecto de calidad. En cuanto a las tecnologías estudiadas, sería muy interesante que existiera una herramienta específica para gestionar Oficinas Técnicas, pero realmente no es necesario ya que el trabajo de la OT es más humano que automático. Oficina Técnica en un Departamento de Informática de las AAPP Página - 118 - Generalmente con llevar una adecuada gestión documental de los artefactos que se generan en las diferentes fases, un buen buzón de correo electrónico y tener un buen equipo de consultores debería bastar para asegurar una OT de calidad, pero qué duda cabe que el hecho de que existan herramientas colaborativas con un control de versiones, con creación de flujos de trabajo, gestión de usuarios, etc. ayuda mucho a garantizar el acceso instantáneo a toda la documentación. Debido a lo descrito anteriormente se considera que el diseño presentado es suficiente para implantar una Oficina Técnica dentro del ámbito de la e-administración. Así mismo, este diseño ha ofrecido la posibilidad a la autora de conocer herramientas y lenguajes de programación no utilizados anteriormente por ella, como es el lenguaje Visual Basic con el que se ha realizado la mayoría de las macros que componen las Excels de los documentos o programas como Adobe Live Cycle para el desarrollo de los .pdfs editables, etc. Una vez terminado este Proyecto Final de Carrera y a la vista de los resultados obtenidos al aplicar una Oficina Técnica en un proyecto para el que se ha trabajado en la empresa Capgemini, se llega a la conclusión de que es muy beneficiosa la participación de la Oficina Técnica cuando lo que se quiere es controlar varios proyectos a la vez. Numerosos estudios demuestran que cuando se aplican metodologías de control de calidad o de gestión de proyectos se alcanza con mayor frecuencia el éxito de los mismos, sin embargo la figura de la Oficina Técnica en determinadas ocasiones no está bien considerada por los proveedores o las personas ajenas a los clientes que contratan y que participan en el proyecto, en cuyo caso por mucho que la OT ayude a planificar y lleve un adecuado control del avance del proyecto, éste no podrá ser llevado a término. Personalmente, el trabajo realizado durante el tiempo de desarrollo del proyecto ha sido sin duda una experiencia enriquecedora como punto de partida al mundo de la consultoría de procesos y calidad. Aprendiendo conceptos prácticos relacionados con el ciclo de vida de los proyectos, el día a día con clientes de las AAPP, el trabajo en equipo y en definitiva el contacto real en el mundo del proyecto, sus entregables y el compromiso y entrega que requiere por parte del consultor se ha redirigido la trayectoria profesional a la que la autora pretende dedicar su vida laboral. 6.2. Trabajos futuros A continuación se detalla una lista de posibles trabajos futuros o propuestas de mejora que se podrían aplicar a la Oficina Técnica desarrollada:  Inclusión de software de gestión de incidencias: Después de la experiencia de la autora trabajando con oficinas técnicas, se llega a la conclusión de que el estado y el seguimiento explícito de las incidencias es una tarea que se realiza sino diaria muy frecuentemente durante todo el proyecto. Actualmente se lleva ésta gestión por medio de macros en Excel pero sería recomendable tener un soporte software que implementara la funcionalidad necesaria para la gestión de las mismas. Los objetivos básicos que debería ofrecer serían: - La asignación de incidencias - El seguimiento de las incidencias en curso - El detalle de la resolución de las incidencias - La notificación a los interesados del estado de las incidencias Oficina Técnica en un Departamento de Informática de las AAPP Página - 119 -  Incorporación a la biblioteca documental un informe de situación de incidencias: Como apoyo para la mejora anterior sería pues deseable que se genera un informe explícito no solo que mostrara cuantitativamente el estado de las mismas sino también de manera gráfica.  Incorporación de plantillas de presentaciones: Cada vez que la Oficina Técnica acude a una reunión es muy frecuente que se apoye en un modelo de presentación. Se propone realizar plantillas de estas presentaciones.  Gestión de usuarios por proyectos: Esta mejora consistiría en incluir una gestión de usuarios dentro del sistema que permitiera a cada jefe de proyecto acceder a un espacio específico de trabajo.  Incorporación de un chat interno: Instalación de un chat o sistema de mensajería instantánea para la comunicación con los diferentes participantes dentro del proyecto.  Incorporación de un sistema de correo electrónico que permita actualizar los calendarios personales: Cuando en un proyecto participan varias personas y hay que reunirlas a todas, es una tarea complicada ponerse de acuerdo con todas ellas para fijar los días que se celebran estas reuniones. Se añade pues la propuesta de utilizar un gestor de correo electrónico que permita llevar un calendario de tareas y que tenga control de reuniones. Con esto se podría ver rápidamente que personas han confirmado su asistencia.  Creación de una herramienta hecha a medida para la gestión de Oficinas Técnicas: La herramienta Drupal, descrita en apartados anteriores, podría ser una buena opción para este propósito, la idea sería generar un sitio web al que todos y cada uno de los roles participantes dentro del proyecto pudieran acceder para gestionar la documentación y que la OT dispusiera de un área particular en la que aparecieran automáticamente calendarios de reuniones, gráficas de situación, noticias relevantes, etc. y en función del día a día del proyecto, el administrador de esta OT pudiese actualizar el contenido de este sitio web para que se amoldara a las necesidades específicas de cada proyecto.  Incorporación de la Oficina Técnica propuesta a la empresa Capgemini: Actualmente la empresa Capgemini gestiona algunas de sus oficinas técnicas por medio de los documentos que se han presentado en este proyecto. Sería deseable que en un futuro utilizara el gestor documental proporcionado para que todos los participantes del proyecto pudieran acceder a la información de manera simultánea. Oficina Técnica en un Departamento de Informática de las AAPP Página - 120 - Oficina Técnica en un Departamento de Informática de las AAPP Página - 121 - Capítulo 7 7. Bibliografía [ABA-2007]. Barros, Alejandro. Oficina de Proyectos (PMO). [ACH-2000]. Antonio A. Chillida. Garantía y Calidad del Software. [AD-LC]. Adobe LiveCicle 2.5. Página web: http://www.adobe.com/products/livecycle/ [ALF-2011]. Alfresco Communty Edition 3.4. Página web: http://www.alfresco.com/es/ [BPMN-2004]. Business Process Modeling Notation. Página web http://www.bpmn.org/ [CAP-2008]. Capgemini Valencia. Manual de Calidad 2008. [CHY-2002]. Chamoun, Yamal. Administración Profesional de Proyectos. Una Guía Práctica para Programar el Éxito de los Proyectos. [CRA-1999]. Ramió, Carles. Teoría de la Organización y Administración.[C&P-2001]. CASEY, W. &.PECK (2001). Choosing fue right PMO setup. [CRO-2009]. Zúñiga Soriano, Claudio Rodrigo. Propuesta para la implementación de una oficina de administración de proyectos (PMO) en la municipalidad de Aguirre. Proyecto Final de Carrera, San José, Costa Rica, 2009. [DRU-2007]. Drupal 7.8. Página web http://drupal.org.es/ [EDL-2000]. La estrategia de Lisboa [EUR-2020]. Europa 2020. Una estrategia para un crecimiento inteligente, sostenible e integrador. Obtenido de: http://ec.europa.eu/commission_20102014/president/news/documents/pdf/20100303_1_es.pdf Oficina Técnica en un Departamento de Informática de las AAPP Página - 128 - El área de trabajo permite al usuario realizar una serie de modificaciones y acciones sobre los contenidos y las vistas. Esta área está dividida en 3 secciones: 1. La cabecera 2. El examinador de espacios 3. El contenido del espacio de trabajo. Figura 58. Secciones del Área de Trabajo A.4.1 Vistas El usuario puede modificar la vista que tiene en su área de trabajo. Para ello debe seleccionar el tipo de vista en el menú desplegable a la derecha en la cabecera. Se puede seleccionar entre: – Vista de detalles: En esta vista el usuario puede cambiar los criterios de ordenación que se muestran en la cabecera. – Vista de iconos – Examinar vista Oficina Técnica en un Departamento de Informática de las AAPP Página - 129 - Todos los contenidos y espacios están acompañados de un icono, que abre una ventana emergente con información del contenido o espacio (autor, fecha de creación, descripción, título, etc.) A.4.2 Acciones Tanto el menú “Más acciones” de la cabecera del área de trabajo como los iconos que tiene asociados cada contenido o espacio, permiten al usuario realizar una serie de acciones sobre estos elementos. Si el usuario selecciona una acción de las disponibles en la cabecera, éstas afectarán al espacio en el que se esté en ese momento; y si se quieren aplicar acciones a algún contenido del espacio, el usuario debe seleccionar las que el contenido tiene asociadas. Figura 59. Acciones en la cabecera A.5 Añadir Contenido El usuario puede elegir varias maneras de añadir contenido a los espacios, y deberá elegir una u otra según sus criterios y la rapidez que le proporcionen cada uno de los métodos. Antes de añadir contenidos el usuario debe conocer también la manera de crear espacios de trabajo, que luego le servirán para almacenar y organizar los contenidos que añada al sistema. A.5.1 Crear Espacios En Alfresco se usan los espacios para almacenar y organizar contenidos y otros espacios, de manera que se puedan encontrar con mayor rapidez en un futuro. Para crear un espacio el usuario debe ir al menú “Crear”, situado en el área de trabajo, y seleccionar “Crear espacio”. Oficina Técnica en un Departamento de Informática de las AAPP Página - 130 - Figura 60. Crear espacio El sistema nos pedirá una serie de datos, de los cuales sólo son obligatorios el nombre del espacio y el icono. Figura 61. Datos del Nuevo Espacio Cuando el usuario haya terminado de rellenar los datos debe pulsar sobre el botón “Crear espacio” para terminar. Una vez creado, el nuevo espacio no aparecerá todavía en la barra lateral. Para sincronizar la barra lateral con los nuevos cambios el usuario debe pulsar sobre el icono “refrescar” situado en la parte superior derecha de la barra lateral. Este nuevo espacio estará a disposición de todos los usuarios que tengan acceso al espacio donde fue creado, sin embargo, el usuario puede estar interesado en que a este nuevo espacio sólo tengan acceso un número limitado de personas, o solamente él. Para ello el usuario debe situarse dentro del nuevo espacio y seleccionar “Gestionar usuarios del espacio”, dentro del menú de “Más acciones” del área de trabajo. En la nueva página que aparece, el usuario debe desmarcar la opción “Heredar permisos de Espacio Padre” para que solo él pueda verlo, y si desea que otros usuarios lo puedan ver también puede seleccionar la opción “invitar”, la cual abrirá un menú en el que el usuario puede escoger a otros grupos/usuarios para darles permisos sobre el nuevo espacio. A.5.2 Crear Contenidos Una de las posibilidades para crear contenido en el sistema es usar un archivo creado anteriormente y agregarlo a nuestro sistema. Para hacer esto el usuario debe pulsar el botón ‘Crear Contenido’ dentro del área de trabajo. Oficina Técnica en un Departamento de Informática de las AAPP Página - 131 - El sistema abrirá un asistente para añadir contenido que guiará al usuario durante el proceso. Figura 62. Añadir Contenido El usuario debe seleccionar el contenido que desea agregar al sistema. Pulsando sobre “Examinar...” se abrirá una ventana que nos permitirá seleccionar un documento del PC. Una vez seleccionado el contenido que se desea agregar, el usuario debe pulsar en “Enviar” para que el contenido se agregue al sistema. Ahora el sistema pedirá que el usuario introduzca el nombre del contenido (si quiere cambiar el que tenía), tipo, codificación y tipo de contenido. Figura 63. Propiedades Generales del nuevo contenido Al igual que ocurre al crear contenido, si dejamos marcada la casilla “Modificar todas las propiedades cuando este asistente se cierre”, cuando el usuario termine de editar las propiedades generales y pulse “Aceptar” para terminar, el sistema mostrará una nueva interfaz para editar las propiedades del contenido idéntica a la que aparece al crear nuevo contenido. A.6 Buscar Contenido El usuario tiene 4 maneras de realizar búsquedas en el sistema: – Mediante el panel de búsqueda en la barra de tareas. – Realizando búsquedas jerárquicas. – Usando el OpenSearch de la barra lateral. – Realizando una búsqueda avanzada. A.6.1 Búsquedas en la barra de tareas La barra de tareas tiene una zona asignada para realizar búsquedas, situada en la parte derecha de la barra. Oficina Técnica en un Departamento de Informática de las AAPP Página - 132 - Esta barra contiene un menú desplegable para realizar filtrados simples en las búsquedas, y también nos permite seleccionar la búsqueda avanzada. Si el usuario realiza búsquedas similares muchas veces, existe la opción de guardar la búsqueda. Esto es útil para ahorrar tiempo a la hora de especificar las características de la búsqueda. Esta opción está disponible en el menú “Mas acciones” cuando se realiza la búsqueda. A.6.2 Búsqueda Jerárquica Este es un tipo de búsqueda manual, es decir, el usuario navega a través de los espacios para buscar manualmente los contenidos que desee. Para ello el usuario puede usar el navegador de la barra lateral y el área de trabajo. Si un usuario quiere buscar un documento con datos de clientes y conoce su ubicación dentro de los espacios de trabajo puede ir directamente al espacio donde se encuentra el documento y abrirlo. A.6.3 OpenSearch La búsqueda mediante OpenSearch está situada en la barra lateral, y para seleccionarla el usuario debe desplegar el menú del navegador y elegir “OpenSearch”. Este tipo de búsqueda permite al usuario navegar por los espacios en su área de trabajo y realizar búsquedas al mismo tiempo, sin perder la visión de su área de trabajo. Los resultados de las búsqueda se muestran justo debajo de donde se inserta la búsqueda. Oficina Técnica en un Departamento de Informática de las AAPP Página - 133 - A.6.4 Búsqueda Avanzada Para realizar este tipo de búsquedas el usuario debe seleccionar “Búsqueda avanzada” en el menú desplegable de búsquedas, en la barra de tareas. Aparecerá entonces en el área de trabajo la zona de búsqueda con todas las posibilidades, filtros, etc. de las que dispone la búsqueda avanzada. Opciones de la búsqueda avanzada: – Mostrar resultado para: El usuario puede hacer una selección de los contenidos que quiere buscar, si no desea buscar cualquier contenido. – Buscar en: Se puede especificar a partir de qué espacio o en que espacio se quiere realizar la búsqueda. Si el usuario no marca la casilla “Incluir espacios hijo” la búsqueda solo se realizará en el espacio seleccionado. – Buscar también:  “Tipo de Carpeta” permite seleccionar entre buscar en Carpetas o Espacios de Foros.  “Tipo de Contenido” contiene una lista de tipos de contenidos que puede haber en los espacios (facturas, contratos, acuerdos, etc).  En “Formato del Contenido” el usuario puede seleccionar el formato que tiene el contenido que está buscando (documento PDF, documento Microsoft Word, etc). Asociado al formato también se pueden especificar el título, descripción y autor del contenido que se desea buscar.  El usuario también puede especificar las fechas entre las que se modificó o creó el contenido. – Opciones adicionales: Las opciones adicionales varían en función del tipo de contenido que seleccionemos en el panel “Buscar también”. Estas opciones permiten hacer búsquedas especificando los metadatos según el tipo de contenido. – Mostrarme resultados en las categorías: El usuario puede filtrar su búsqueda según una serie de categorías de las que dispone el sistema. Por ejemplo, un usuario podría realizar una búsqueda de contenidos cuyo lenguaje utilizado sea el español.