Architectural Project Management App by Vilares y Romo - issuu\nMÁSTER OFICIAL DIRECCIÓN INTEGRADA DE PROYECTOS Especialidad: Edificación y Desarrollo Territorial\nTrabajo fin de Máster "PGCPE" DISEÑO Y DESARROLLO DE UNA PLATAFORMA PARA LA GESTIÓN COLABORATIVA DE PROYECTOS DE EDIFICACIÓN\nTutor Fernando Vázquez Núñez Co-tutor Eduardo Sanjurjo Royo Autor Ángel Romo Sandoval Fecha 31/05/2013\nÍNDICE DOCUMENTO TÍTULO DOC.00 RESUMEN DOC.01 CONTEXTUALIZACIÓN Y JUSTIFICACIÓN\nDOC.02 DOC.03 DOC.04 DOC.05 DOC.06 DOC.07 DOC.08 DOC.09 DOC.10 DOC.11 DOC.12 DOC.13 DOC.14 DOC.15 DOC.16 DOC.17 DOC.18 DOC.19 DOC.20 DOC.21 DOC.22 DOC.23\nPROYECTO DOCUMENTOS DEL GRUPO DE PROCESOS DE INICIO ACTA DE CONSTITUCIÓN DEL PROYECTO MATRIZ DE INTERESADOS DOCUMENTOS DEL GRUPO DE PROCESOS DE PLANIFICACIÓN PLAN PARA LA DIRECCIÓN DEL PROYECTO REQUISITOS DE PRODUCTO REQUISITOS DE PROYECTO ENUNCIADO DEL ALCANCE ESTRUCTURA DE DESGLOSE DE ENTREGABLES DEFINICIÓN DE ACTIVIDADES DIAGRAMA DE RED ESTRUCTURA DE DESGLOSE DE RECURSOS HOJA DE ACTIVIDADES CRONOGRAMA LÍNEA BASE DE PRESUPUESTO PLAN DE CALIDAD MÉTRICAS DE CALIDAD PLAN DE PERSONAL PLAN PARA LA DIRECCIÓN DEL PERSONAL PLAN DE GESTIÓN DE LAS COMUNICACIONES PLAN DE GESTIÓN DE RIESGOS IDENTIFICACIÓN DE RIESGOS Y OPORTUNIDADES, ANÁLISIS CUALITATIVO Y CUANTITATIVO PLAN DE RESPUESTA A LOS RIESGOS Y OPORTUNIDADES DOCUMENTOS DEL GRUPO DE PROCESOS DE EJECUCIÓN DOCUMENTO DE DESEMPEÑO DE TRABAJO\nPÁG 4 5\n6 8 12 13 14 15 16 17 21 22 24 31 32 35 36 17 43 45 47 48 52 56\nÍNDICE DOCUMENTO DOC.24 DOC.25 DOC.26 DOC.27\nPÁG 57 58 59 60\nTÍTULO DOCUMENTO DE SOLICITUD DE CAMBIO PLANIFICACIÓN DE REUNIÓN CON STAKEHOLDERS ACTA DE REUNIÓN CON STAKEHOLDERS ADQUISICIÓN DEL EQUIPO DOCUMENTOS DEL GRUPO DE PROCESOS DE SEGUIMIENTO Y CONTROL EVALUACIÓN DEL DESEMPEÑO DEL EQUIPO MONITORIZACIÓN Y CONTROL DEL TRABAJO DEL PROYECTO ACEPTACIÓN O DENEGACIÓN DE SOLICITUD DE CAMBIO VERIFICACIÓN Y CONTROL DEL ALCANCE CONTROLAR EL CRONOGRAMA Y EL PRESUPUESTO HOJA DE RECOGIDA DE DATOS DE CONTROL DE CALIDAD INFORME DEL DESEMPEÑO MONITORIZACIÓN Y CONTROL DE RIESGOS DOCUMENTACIÓN DE LAS ADQUISICIONES DOCUMENTOS DEL GRUPO DE PROCESOS DE CIERRE FIN DE CONTRATO LECCIONES APRENDIDAS ACTA DE CIERRE DE PROYECTO ANEXO EJEMPLO DE FRAGMENTO DE DIAGRAMA DE FLUJO DE LA APLICACIÓN\nCONCLUSIONES BIBLIOGRAFÍA Y WEBGRAFÍA\nDOC.28 DOC.29 DOC.30 DOC.31 DOC.32 DOC.33 DOC.34 DOC.35 DOC.36 DOC.37 DOC.38 DOC.39\n61 62 63 64 65 66 68 70 71 72 73 74 75\nRESUMEN El presente trabajo constituye el Trabajo fin de Máster del Máster Oficial Interuniversitario de Dirección Integrada de Proyectos, curso 2012-2013 impartido en las Universidades de A Coruña y Vigo, especialidad de "Edificación y Desarrollo Territorial". Se trata del proyecto de diseño y desarrollo de una aplicación informática que ayude a organizar y gestionar la información producida y manejada por equipos de trabajo (arquitectos y/o ingenieros) durante el diseño de proyectos de edificación. La necesidad de esta aplicación surge de la progresiva implantación en el mercado de grandes estudios de arquitectura formados por múltiples profesionales de distintas ramas, estos grandes estudios, aún estando formados por grupos de hasta 300 personas poseen metodologías de trabajo poco eficientes y anticuadas. Esto es debido, entre otras razones, al gran volumen de negocio que poseían dichos estudios durante la pasada década lo cual les exhimía de ser plenamente eficaces; A la creencia de que la metodología mata la creatividad; A la falta de aplicaciones informáticas de gestión de proyectos arquitectónicos; A la escasa implantación de los fundamentos DIP en este sector o a la dificultad de planificar manualmente proyectos de edificación. Este trabajo está organizado en documentos (DOC.01, 02, 03 etc) los cuales constituyen los entregables de los distintos procesos incluídos en este proyecto organizados según el orden de los cinco grupos de procesos y, dentro de cada grupo, según el orden de las áreas de conocimiento. El objetivo de estructurar el trabajo en documentos y no en procesos es evitar el problema al cual uno se enfrenta cuando elabora un trabajo fin de máster sobre un proyecto que no se realiza: Realizar la planificación pero no la ejecución de la mayoría de los procesos. La organización en documentos permite no solamente explicar el proceso asociado a dicho documento, sino también pensar cómo debe ser el documento y además rellenarlo, a veces con datos reales, otra veces con datos hipotéticos que se darían si se llegase a ejecutar el proyecto (solicitudes de cambio, informes de desempeño de trabajo, etc). Estas tres partes se muestran en la misma página, permitiendo una lectura global. Creo que este modo de acometer el trabajo lo hace más didáctico tanto para mí como para el lector. Dado que el trabajo está formado por los documentos necesarios para desarrollar el proyecto y con los cuales se trabajaría durante la ejecución del mismo, he realizado todos estos documentos en MS Excel. En dicho archivo .XLS el conjunto del TFM es el libro y cada documento se ubica en una hoja, a su vez cada hoja posee una o varias páginas. Gracias a la vinculación entre celdas que permiten los archivos .XLS, si se modifica, por ejemplo, el nombre de una actividad en la hoja "DOC.13" automáticamente cambia en la "DOC.18". La estructura de este trabajo incluye además del proyecto, un ejemplo del diagrama de flujo que estructuraría la aplicación informática así como un apartado final de conclusiones y una bibliografía. PGCPE DOC.00, página 4 de 77\nCONTEXTUALIZACIÓN Y JUSTIFICACIÓN Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por CONTEXTUALIZACIÓN Y JUSTIFICACIÓN Diseño y desarrollo de una aplicación informática que ayude a organizar y gestionar la información producida y manejada por equipos de trabajo (arquitectos y/o ingenieros) durante el diseño colaborativo de proyectos de edificación. Esta aplicación permite asignar responsabilidades y determinar relaciones de dependencia entre entregables. Por ejemplo, en un hipotético contrato entre un proyectista y un calculista de instalaciones, ambos pueden definir si debe ser el proyectista quien determine factores iniciales como el tipo de instalación de climatización a escoger o sea el calculista quien lo determine o sea responsabilidad de ambos. Para ello tan solo sería necesario abrir el listado de requisitos del apartado diseño de instalaciones y asignar responsabilidades. Otra posibilidad que brinda la aplicación es conocer el orden en el cual se deben realizar las tareas de proyecto, pocos son los proyectistas que comprueban antes de iniciar el diseño los requerimientos de aislamiento acústico del emplazamiento debido posiblemente a que es un punto incluído en el penúltimo apartado del CTE y por lo tanto no parece primordial, sin embargo, considerarlo como un proceso inicial puede suponer evitar problemas a posteriori. La aplicación dispondría de entornos de trabajo constituídos por hojas de tareas dinámicas asociadas a un responsable, en las cuales se puede indicar qué se ha realizado, qué se está realizando y qué falta por realizar, asimismo, también se puede comprobar que entregables se necesitan para iniciar un proceso y quién o quienes son responsables de dichos entregables. Este prototipo formaría parte de una plataforma colaborativa de proyectos de edificación que se está desarrollando actualmente por parte de la organización en la cual he realizado este proyecto. Asimismo también podría incluirse en software de diseño arquitectónico como puede ser el Cype, el Revit o el Archicad, de modo que la aplicación detectaría en cada instante qué proceso está realizando el usuario con la finalidad de informarle en todo momento de los entregables (tanto entradas como salidas) relacionados con dicho proceso. Por ejemplo, si el usuario modifica una ventana, automáticamente, podrá ver qué consecuencias supondrá esto (influirá en el rendimiento energético del edificio, en el aislamiento acústico o en el coste del proyecto) y a qué otros profesionales afectará este cambio (calculista de instalaciones, redactor de cumplimiento acústico DB HR, etc). Varias de estas aplicaciones actualmente poseen sencillos módulos de asignación de responsabilidades (revit o archicad) o de dependencia entre requisitos (Cype Instalaciones) pero ninguna de ellas permite el control del conjunto del proyecto tal y como plantea este proyecto, éste es el requisito más importante de esta aplicación: La posibilidad de asesorar a cada uno de los proyectistas sobre qué tareas emprender en cada momento así como favorecer el trabajo en equipo al relacionar entradas y salidas de tareas entre sí.\nPGCPE DOC.01, página 5 de 77\nACTA DE CONSTITUCIÓN DEL PROYECTO versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por El acta de constitución puede ser readactada solo por el director de proyecto, en adelante DP o ser redactada conjuntamente por el DP y los responsables de la oficina de proyectos. ACTA DE CONSTITUCIÓN DEL PROYECTO título proyecto Diseño y desarrollo de una plataforma para la gestión colaborativa de proyectos de edificación Partes acordantes (Rol, nombre) Director Gerente xxx Director de proyecto xxx Objetivo Diseño de una aplicación informática que permite incluir en ella todos los entregables que posee un proyecto de edificación (tomando como referencia el Código Técnico de la Edificación) y vincularlos con los procesos llevados a cabo comúnmente en la elaboración de un proyecto. A su vez estos procesos pueden asignarse a uno o varios responsables. Todo ello constituye un diagrama de flujo que describe un proyecto de edificación tipo y que facilita la coordinación entre distintos agentes en la elaboración del proyecto tanto básico como de ejecución. Objetivos de negocio Esta aplicación será incorporada a otra de mayor rango ya desarrollada por esta organización. Recursos a disposición (rol, nombre) Responsable de desarrollo, xxx Ingeniero informático 1, xxx Ingeniero informático 2, xxx Ingeniero informático 3, xxx Ingeniero informático 4, xxx Ingeniero informático 5, xxx\nPGCPE DOC.02, página 6 de 77\nACTA DE CONSTITUCIÓN DEL PROYECTO Interesados Promotor (oficina de proyectos) Organización Colegio oficial arquitectos y empresa desarrolladora del “Memorias CTE” Colegio oficial ingenieros Colegio oficial aparejadores Universidade de A Coruña Empresa de aplicaciones informáticas del sector de edificación (CYPE) Grandes empresas de aplicaciones informáticas del sector de edificación (SAP, Autodesk, , ARCHICAD)) Dirección General de Arquitectura, Vivienda y Suelo (responsables de CTE) Grandes empresas del sector edificación Profesionales (proyectistas, calculista, ingenieros, etc)\nRequisitos La aplicación: Facilitará el trabajo en equipo en el diseño de proyectos de edificación. Dispondrá de un fácil manejo y será usable sin necesidad de conocer el CTE en profundidad. Permitirá asignar responsabilidades de distintas tareas fácilmente. Será editable y reeditable tanto durante la fase de planificación del proyecto así como durante su ejecución. Facilitará realizar las tareas necesarias para justificar el cumplimiento del Código Técnico de la Edificación. Permitirá la estandarizar de los procesos proyectuales Permitirá el trabajo en red Equipo El equipo necesario serán 5 profesionales del sector de la construcción con un responsable, 5 profesionales del sector de la ingeniería informática con otro responsable y un director de proyecto. Presupuesto El presupuesto estimado son 200.000€ Tiempo En torno a 1 año. Acuerdo entre partes acordantes (Rol, nombre, firma y fecha) Director Gerente xxx Director de proyecto xxx PGCPE DOC.02, página 7 de 77\nMATRIZ DE INTERESADOS versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por MATRIZ DE INTERESADOS Interesado Poder (alto Actitud Acción a realizar medio (+ 0 -) bajo) Promotor (oficina de alto proyectos)\nColegio oficial arquitectos y empresa desarrolladora del “Memorias CTE”\nRealizar reuniones periódicas informando del desempeño del proyecto. Establecer un ambiente de trabajo favorable\nLa oficina de proyectos es la impulsora de PGCPE, el objetivo es incluirlo en otra aplicación ya existente.\nLa convivencia de agentes del sector de la edificación y del informático puede ser tan beneficiosa como problemática debido a problemas de comunicación.\nGrupo de Realizar reuniones con los procesos de gestores del software “Memorias CTE” (aplicación de Planificación cierta similitud con este proyecto) antes de emprender el proyecto y durante este.\nAl tratarse de la entidad promotora del “Memorias CTE”) es recomendable adquirir experiencia a través de juicio de expertos.\nPGCPE DOC.03, página 8 de 77\nMATRIZ DE INTERESADOS Interesado Poder (alto Actitud Acción a realizar medio (+ 0 -) bajo)\nRealizar reunión de presentación de PGCP.\nComunicar la existencia de PGCP a dicho colegio puede ser enormemente favorable pues ellos pueden ser los grandes beneficiados de un software que facilitará su entrada en el mundo de la edificación a raíz de la posible entrada en vigor de la Ley de Servicios Profesionales.\nIntentar establecer un convenio de colaboración mediante los viveros de empresas u otros tipos de bolsas. Realizar reunión de presentación de PGCP.\nLa dirección integrada de proyectos es un área de conocimiento extendida en dicha profesión, las aplicaciones relacionadas con ésta tendrá una buena acogida. -\nEmpresa de alto aplicaciones informáticas del sector de edificación (CYPE)\nCype Ingenieros compró el software “Memorias CTE” incluyéndolo actualmente en su paquete “Cype”. Pueden estar interesados en la compra de PGCPE. También existe el riesgo de que, conociendo la idea, decidan implementarla por sí mismos.\nPGCPE DOC.03, página 9 de 77\nGrandes empresas de alto aplicaciones informáticas del sector de edificación (SAP, Autodesk, , ARCHICAD))\nCiertas aplicaciones de creación y gestión de planos como Revit (de tipo BIM) actualmente están introduciendo plataformas de trabajo colaborativo como la posibilidad de trabajar varios agentes sobre un mismo modelo 3d. Nuestra aplicación podría ser un valor añadido para estas estrategias.\nDirección General de bajo Arquitectura, Vivienda y Suelo (responsables de CTE)\nInformarse sobre si habrá futuros cambios en la normativa o la posibilidad de que los haya.\nAdaptarse a la normativa es un factor clave de proyecto para asegurar el interés de los futuros usuarios.\nGrandes empresas medio del sector edificación\nLas grandes empresas son potenciales usuarios, existe la posibilidad de que una empresa contrate para sí PGCPE como software interno.\nPGCPE DOC.03, página 10 de 77\nMATRIZ DE INTERESADOS Interesado Poder (alto Actitud Acciรณn a realizar medio (+ 0 -) bajo) Profesionales Bajo (proyectistas, calculista, ingenieros, etc)\nRealizar versiones de prueba gratuitas online de PGCP que aglutinen รกreas temรกticas (por ejemplo, procesos relacionados con el cรกlculo de la estructura) Dichas versiones podrรกn ser usadas por profesionales del sector a cambio de que cedan las estadรญsticas e informes de uso.\nPeriodicidad semanal a lo largo del G.P. Ejecuciรณn.\nLa realizaciรณn del diagrama de flujo que el programa incluirรก por defecto es una tarea muy compleja. Cรณmo debe ser exactamente dicho diagrama puede ser ampliamente debatido y el juicio de expertos serรก de gran ayuda para su realizaciรณn.\nPGCPE DOC.03, pรกgina 11 de 77\nPLAN PARA LA DIRECCIÓN DEL PROYECTO versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por PLAN PARA LA DIRECCIÓN DEL PROYECTO A continuación se incluyen todos los documentos que detallan todos los apartados que constituyen el Plan para la dirección del proyecto, desde el DOC.05 hasta el DOC.22, ambos incluídos.\nPGCPE DOC.04, página 12 de 77\nREQUISITOS DE PRODUCTO versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por REQUISITOS DE PRODUCTO Requisito\nInteresado o grupo de interesados Sector de edificación Sector de la edificación Usuarios\nDebido a que la especialización el trabajo en edificación de equipo es una tendencia al alza, el facilitarlo redundará en una mayor eficiencia. Fácil manejo Actualmente el uso de software de gestión de proyectos es escaso en el diseño de proyectos de edificación, la herramienta debe tener una fácil usabilidad. Establecer responsabilidades Las responsabilidades en proyectos abordados por gran cantidad de agentes de distintas fácilmente especialidades a menudo se solapan o no son definidas. Editable tanto durante la fase de Usuarios Dado que el modo de afrontar proyectos es heterogéneo y varía en gran medida entre agentes, es planificación del proyecto así como preciso que el diagrama de flujo sea totalmente editable de un modo sencillo por parte del durante su ejecución. usuario en cualquier momento. Posibilidad de manejar el software Profesionales Si la Ley de Servicios Profesionales entra en vigor, ingenieros industriales con especialidad sin necesidad de conocer a fondo que se edificación podrán ser proyectistas de todo tipo de edificaciones, su forma de trabajo con una el código técnico de la edificación incorporan al gran componente técnica y orientada a resultados les hace potenciales usuarios de dicha sector aplicación sin embargo su posible menor conocimiento del código técnico debe ser tenido en actualmente cuenta. Creación de un diagrama basado Sector de la Esta ley posiblemente esté vigente bastantes años. Los apartados que la componen y exigencias en el código técnico de la edificación que incluye actualmente definen las partes que componen la mayoría de los proyectos de edificación edificación. Estandarizar los procesos Sector de la Actualmente no existe una estandarización debido a la complejidad de dichos proyectos, las proyectuales edificación herramientas informáticas pueden contribuir a alcanzar una cierta estandarización. Permitirá el trabajo en red Sector de la Al tratarse de una aplicación de gestión colaborativa, es indispensable posibilitar el acceso a ésta edificación desde cualquier terminal. Facilitar el trabajo en equipo\nPGCPE DOC.05, página 13 de 77\nREQUISITOS DE PROYECTO versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por REQUISITOS DE PROYECTO Requisito\nInteresado o Contextualización grupo de interesados La propia Es fundamental favorecer la comunicación interna entre dos tipos de profesionales con organización formaciones tan dispares.\nProyecto colaborativo sector tecnologías de la información edificación Facilitar la rápida introducción de La propia datos en el nuevo software (es organización preciso introducir del orden de más de 6000 entradas y salidas) Uso de un lenguaje de programación similar al empleado en los programas de edición de proyectos con más difusión en el mercado Recopilación de información de los usuarios Facilitar las posibles actualizaciones y mejoras que se realicen del producto\nUso de herramientas informáticas por parte de los profesionales de edificación para la introducción de datos que permitan una rápida implementación por parte de los ingenieros informáticos.\nEl uso de un lenguaje común permitirá tanto la posible sincronización de la aplicación con otras aplicaciones e incluso su inclusión en dichas aplicaciones.\nLa propia organización La propia organización\nCon ello se permitirá establecer los objetivos y necesidades de mejora del software una vez haya sido lanzado al mercado. Al tratarse de una aplicación que favorece su personalización por parte de los usuarios, probablemente deban realizarse multitud de pequeños cambios a posteriori.\nPGCPE DOC.06, página 14 de 77\nENUNCIADO DEL ALCANCE versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por ENUNCIADO DEL ALCANCE Diseño y desarrollo de una aplicación informática que ayude a organizar y gestionar la información producida y manejada por equipos de trabajo (arquitectos y/o ingenieros) durante el diseño colaborativo de proyectos de edificación. Esta aplicación permite asignar responsabilidades y determinar relaciones de dependencia entre entregables.\nLa aplicación consta de un diagrama de flujo: Un proyecto de edificación posee múltiples procesos, un ejemplo sería "evaluación del grado de impermeabilidad de muros". Este proceso, como otros muchos, posee unos entregables que son entrada y unos entregables que son salida, en este caso "evaluación del grado de impermeabilidad de muros" posee como entradas "presencia de agua en terrenos" y "coeficiente de permeabilidad del terreno" y como salida "grado de impermeabilidad exigido en muro". A su vez, los entregables se pueden agrupar en distintos niveles, por ejemplo los dos entregables antes mencionados "presencia de agua en terrenos" y "coeficiente de permeabilidad del terreno" están incluídas en el entregable, "informe geotécnico". Por último cada entregable tiene un responsable, por ejemplo, un ingeniero de minas puede ser el responsable del "informe geotécnico". En resumen: El diagrama de proceso posee tres reglas: La posibilidad de relacionar entregables, la posibilidad de agrupar entregables en otros entregables de mayor categoría (el CTE distingue 14 categorías) y la asignación de responsables a cada entregable. Con estas tres reglas se puede construir un diagrama de flujo que aglutine todos los entregables (o también definidos requisitos) que necesita un proyecto de edificación. La aplicación dispondrá de un diagrama tipo con una asignación de responsabilidades estandarizada según las prácticas profesionales habituales pero será personalizable según intereses o características de cada equipo y/o proyecto de edificación.\nPGCPE DOC.07, página 15 de 77\nESTRUCTURA DE DESGLOSE DE ENTREGABLES versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por ESTRUCTURA DE DESGLOSE DE ENTREGABLES PROYECTO GRUPO PROCESOS DE INICIO GPI Acta de constitución Definición de interesados y estrategia de gestión de interesados GRUPO PROCESOS DE PLANIFICACIÓN GPP Plan para la dirección del proyecto GRUPO DE PROCESOS DE EJECUCIÓN GPE Diseño de la aplicación Recopilación de información Definir relaciones entre requisitos de un proyecto de edificación, procesos y roles Lógica interna del software Diseño de la funcionalidad de la aplicación Desarrollo de la aplicación Aplicación Plataforma online de versiones de prueba y venta Gestión de las expectativas de los interesados GRUPO DE PROCESOS DE SEGUIMIENTO Y CONTROL GPS Documentos de seguimiento y control GRUPO DE PROCESOS DE CIERRE GPC Transición del producto final Adquisiciones cerradas Lecciones aprendidas Acta de Cierre del proyecto PGCPE DOC.08, página 16 de 77\nDEFINICIÓN DE ACTIVIDADES versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por DEFINICIÓN DE ACTIVIDADES Proceso/actividad 1 GRUPO PROCESOS DE INICIO\nVinculada a entregable GPI\n2 Desarrollar el acta de constitución DOC.02 del proyecto 3 Identificar interesados DOC.03 4 GRUPO DE PROCESOS DE PLANIFICACIÓN 5 Recopilar requisitos 6 Definir el alcance 7 Crear la EDT 8 Definir las actividades 9 Estimar los recursos de las actividades 10 Desarrollar el cronograma del proyecto 11 Determinar el presupuesto 12 Planificar la calidad\nDesarrollar el documento que autoriza formalmente un proyecto y documentar los requisitos iniciales que satisfacen las necesidades y expectativas de los interesados. Identificar a todas las personas u organizaciones que reciben el impacto del proyecto y establecer una estrategia.\nGPP DOC.05 y 06 DOC.07 DOC.08 DOC.9\nDefinir y documentar las necesidades de los interesados a fin de cumplir con los objetivos del proyecto. Desarrollar una descripción detallada del proyecto y del producto. Subdividir los entregables en componentes más pequeños y fáciles de dirigir. Identificar las acciones especificas a ser realizadas para elaborar los entregables del proyecto.\nIdentificar y documentar las relaciones entre las actividades del proyecto.\nEstimar el tipo y las cantidades de materiales, personas, equipos o suministros requeridos para ejecutar cada actividad. Establecer una línea base de costos autorizados. Identificar los requisitos de calidad y/o normas para el proyecto y el producto y documentar la manera en que el proyecto demostrará el cumplimiento con los mismos.\nPGCPE DOC.09, página 17 de 77\nDEFINICIÓN DE ACTIVIDADES Proceso/actividad 13 Desarrollar el plan de personal\nVinculada a entregable DOC.17 y 18\n14 Planificar las comunicaciones\n15 Planificar la gestión de riesgos DOC.20 16 Identificar los riesgos y evaluarlos. DOC.21 17 Planificar la respuesta a los riesgos DOC.22 18 Desarrollar el plan para la dirección De DOC.04 a del proyecto DOC.22 19 GRUPO DE PROCESOS DE GPE EJECUCIÓN 20 Dirigir y gestionar la ejecución del DOC.23 diseño 21 Recopilar requisitos de un proyecto de edificación 22 Definir dependencias entre requisitos 23 Recopilar y procesos de un proyecto de edificación 24 Recopilar roles y responsabilidades\nPendiente de definir Pendiente de definir Pendiente de definir Pendiente de definir\nAtributos Identificar y documentar los roles dentro de un proyecto, las responsabilidades, las habilidades requeridas y las relaciones de comunicación y crear el plan de recursos humanos. Determinar las necesidades de información de los interesados en el proyecto y para definir cómo abordar las comunicaciones. Definir cómo realizar las actividades de gestión de riesgos para un proyecto. Determinar y evaluar los riesgos que pueden afectar el proyecto y se documentan sus características. Desarrollar opciones y acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del proyecto. Documentar las acciones necesarias para definir, preparar, integrar y coordinar todos los planes subsidiarios.\nEjecutar el trabajo definido en el plan para la dirección del proyecto para cumplir con los objetivos del de las actividades de diseño (definir sus características) de la aplicación informática Recopilar los entregables que exige la normativa española en los proyectos de ejecución, organizarlos temática y jerárquicamente y establecer una nomenclatura. Evaluar las relaciones de dependencia entre los entregables antes mencionados (qué entregable o entregables deben haberse realizado para poder realizar otro u otros). Recopilar y evaluar los procesos más comunes en la elaboración de un proyecto de edificación y asociar entregables recopilados a cada dichos procesos. Recopilar roles existentes en los proyectos de edificación en función de los estructuras organizativas más comunes en las empresas y los procesos recopilados en la actividad 23\n25 Elaborar la lógica interna que rige Pendiente de Extraer las reglas lógicas que relacionan los entregables y los procesos recopilados en las el software definir actividades 21 y 23 PGCPE DOC.09, página 18 de 77\nDEFINICIÓN DE ACTIVIDADES Proceso/actividad\nVinculada a entregable 26 Definir las funcionalidades de la Pendiente de aplicación definir 27 Diseñar la interfaz Pendiente de definir 28 Dirigir y gestionar la ejecución del DOC.23 desarrollo\nEstablecer las funcionalidades de la aplicación en función de los requisitos iniciales, el alcance y la lógica interna de la aplicación. Diseñar conjunto de imágenes y entornos gráficos para representar la información y acciones disponibles en la interfaz. Ejecutar el trabajo definido en el plan para la dirección del proyecto para cumplir con los objetivos de las actividades de desarrollo (implementación informática del diseño realizado).\n29 Desarrollar aplicación\nDesarrollo de la aplicación informática.\nPendiente de definir 30 Crear plataforma online Pendiente de definir 31 Realizar reuniones periódicas con DOC.25 Y 26 interesados 32 Adquirir desarrollar y dirigir el DOC.27 y 28 equipo de proyecto 33 GRUPO DE PROCESOS DE GPS SEGUIMIENTO Y CONTROL 34 Monitorear y controlar el trabajo DOC.29 del proyecto 35 Realizar el control integrado de DOC.30 cambios 36 Verificar y controlar el alcance\n37 Controlar el cronograma y el presupuesto\nCrear una plataforma de información del producto, versiones de prueba y comercialización del prototipo en su caso. Realizar reuniones con interesados(distribuidas en el tiempo en función de los entregables) con distintas finalidades. Realizar la adquisición, desarrollo y dirección del equipo de proyecto.\nRevisar, analizar y regular el avance a fin de cumplir con los objetivos de desempeño definidos en el plan para la dirección del proyecto. Revisar todas las solicitudes de cambios, aprobar los cambios y gestionar los cambios a los entregables, a los activos de los procesos de la organización, a los documentos del proyecto y al plan para la dirección del proyecto. Formalizar la aceptación de los entregables del proyecto que se han completado y monitorización del estado del alcance del proyecto y del producto. Monitorear la situación del proyecto para actualizar el avance y el presupuesto del mismo y gestionar cambios a la línea base del cronograma y línea base de costo.\nPGCPE DOC.09, página 19 de 77\nDEFINICIÓN DE ACTIVIDADES Proceso/actividad 38 Realizar el control y el aseguramiento de calidad 39 Informar el desempeño\nVinculada a entregable DOC.33\n40 Monitorear y controlar los riesgos DOC.35 41 Administrar las adquisiciones\n42 GRUPO DE PROCESOS DE CIERRE GPC 43 Realizar la transición del producto DOC.37 final\n44 Elaborar lecciones aprendidas\n45 Cerrar las adquisiciones\n46 Cerrar el proyecto\nAtributos Monitorear y registrar los resultados de la ejecución de actividades de control de calidad, a fin de evaluar el desempeño y recomendar cambios necesarios. Auditar los requisitos de calidad y los resultados obtenidos según el plan de gestión de calidad. Recopilar y distribuir la información sobre el desempeño, incluyendo los informes de estado, las mediciones del avance y las proyecciones. Implementar planes de respuesta a los riesgos, dar seguimiento a los riesgos identificados, e identificar nuevos riesgos. Gestionar las relaciones de adquisiciones, supervisar el desempeño del contrato y efectuar cambios y correcciones según sea necesario. Preparar la inclusión del producto informático en otra aplicación ya existente o la transición de éste a otro proyecto con un alcance mayor (establecer reuniones con el nuevo equipo, transmitir el conocimiento adquirido). Planificar, si es necesario, tareas que sea necesario realizar en función del carácter de la transición mencionada. Medición y valoración de: La relación entre requisitos iniciales y alcance obtenido, el grado de satisfacción de los interesados, la aportación de cada uno de los miembros del equipo, etc. Realizar el cierre económico del proyecto, definir estado de los coste finales, proceder al cierre de facturación. Realizar y firmar acta de cierre de proyecto.\nPGCPE DOC.09, página 20 de 77\nDIAGRAMA DE RED versi贸n ( 1 ) Redactado por Revisado por Aprobado por\nRol / Nombre / Firma / Fecha\nPGCPE DOC.10, p谩gina 21 de 77\nESTRUCTURA DE DESGLOSE DE RECURSOS versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por ESTRUCTURA DE DESGLOSE DE RECURSOS Código Rol Responsabilidades DP Director de Desarrollar todas las tareas relacionadas con los grupos de planificación, dirigir y gestionar los grupos de Proyecto proceso de ejecución, de seguimiento y control y de cierre. RDI Responsable Dirigir y gestionar la ejecución del diseño de la aplicación. Analizar la información generada por los diseño especialistas en estructuras, proyectos, construcción, instalaciones y código técnico y estructurarla según la lógica interna que rige el software. EE\nRecopilar requisitos, definir dependencias entre ellos y asociarlos a procesos. Para ello analizará los documentos DB SE del manual de calidad arquitectónico así como los planos relacionados que se hallan en el documento II de dicho manual y otros documentos que considere necesarios como puede ser el CTE.\nRecopilar requisitos, definir dependencias entre ellos y asociarlos a procesos. Para ello analizará los documentos DB SI Y SUA del manual de calidad arquitectónico así como los planos relacionados que se hallan en el documento II de dicho manual y otros documentos que considere necesarios como puede ser el CTE.\nRecopilar requisitos, definir dependencias entre ellos y asociarlos a procesos. Para ello analizará los documentos DB HS Y HR del manual de calidad arquitectónico así como los planos relacionados que se hallan en el documento II de dicho manual y otros documentos que considere necesarios como puede ser el CTE.\nRecopilar requisitos, definir dependencias entre ellos y asociarlos a procesos. Para ello analizará los documentos DB HE del manual de calidad arquitectónico así como los planos relacionados que se hallan en el documento II de dicho manual y otros documentos que considere necesarios como puede ser el CTE.\nPGCPE DOC.11, página 22 de 77\nESTRUCTURA DE DESGLOSE DE RECURSOS Código Rol Responsabilidades ECTE Especialista Recopilar requisitos, definir dependencias entre ellos y asociarlos a procesos. Para ello analizará los código técnico documentos III (pliego de condiciones), IV (mediciones), V (presupuesto) y VI (proyectos parciales y otros documentos técnicos complementarios). Asesorará a los demás profesionales en cada una de sus especialidades y recopilará la información generada por EE, EP, EC y EI para agruparla. RDE Responsable Dirigir y gestionar la ejecución del desarrollo de la aplicación. desarrollo I1\nIngeniero Realizar actividades relacionadas con el desarrollo. informático 1\nIngeniero Realizar actividades relacionadas con el desarrollo. informático 2\nIngeniero Realizar actividades relacionadas con el desarrollo. informático 3\nIngeniero Realizar actividades relacionadas con el desarrollo. informático 4\nIngeniero Realizar actividades relacionadas con el desarrollo. informático 5\nPGCPE DOC.11, página 23 de 77\nHOJA DE ACTIVIDADES versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por HOJA DE ACTIVIDADES Proceso/actividad\nVinculada a Responsa Comienzo bles GPI jue 18/04/13\nDP, RDI, RDE\n3 Identificar interesados DOC.03\n1 GRUPO PROCESOS DE INICIO 2 Desarrollar el acta de constitución del proyecto\n4 GRUPO DE PROCESOS DE GPP PLANIFICACIÓN 5 Recopilar requisitos DOC.05 y 06 DP, RDI, RDE 6 Definir el alcance\n7 Crear la EDT\n8 Definir las actividades\nDP, RDI, RDE DP, RDI, RDE DP, RDI, RDE\nPred Suces Atributos eces oras\nmar 23/04/13 3;4\nDefinir y documentar las necesidades de los interesados a fin de cumplir con los objetivos del proyecto. Desarrollar una descripción detallada del proyecto y del producto. Subdividir los entregables en componentes más pequeños y fáciles de dirigir. Identificar las acciones especificas a ser realizadas para elaborar los entregables del PGCPE DOC.12, página 24 de 77\nHOJA DE ACTIVIDADES Proceso/actividad\nVinculada a Responsa Comienzo bles 9 Estimar los recursos de DOC.11 DP, RDI, vie 03/05/13 las actividades RDE 10 Desarrollar el DOC.13 DP, RDI, mar 07/05/13 cronograma del RDE proyecto\n11 Determinar el presupuesto 12 Planificar la calidad\n13 Desarrollar el plan de personal\nDOC.17 y 18 DP, RDI, RDE\n15 Planificar la gestión de DOC.20 riesgos 16 Identificar los riesgos y DOC.21 evaluarlos. 17 Planificar la respuesta a DOC.22 los riesgos\nDP, RDI, RDE DP, RDI, RDE\nlun 06/05/13 jue 09/05/13\nPred Suces Atributos eces oras 8 10 Identificar y documentar las relaciones entre las actividades del proyecto. 9 11;12; Estimar el tipo y las cantidades de 13;14; materiales, personas, equipos o suministros 15;18 requeridos para ejecutar cada actividad. Establecer una línea base de costos autorizados. Identificar los requisitos de calidad y/o normas para el proyecto y el producto y documentar la manera en que el proyecto demostrará el cumplimiento con los mismos. Identificar y documentar los roles dentro de un proyecto, las responsabilidades, las habilidades requeridas y las relaciones de comunicación y crear el plan de recursos humanos. Determinar las necesidades de información de los interesados en el proyecto y para definir cómo abordar las comunicaciones. Definir cómo realizar las actividades de gestión de riesgos para un proyecto. Determinar y evaluar los riesgos que pueden afectar el proyecto y se Desarrollar opciones y acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del proyecto. PGCPE DOC.12, página 25 de 77\nVinculada a Responsa Comienzo bles 18 Desarrollar el plan para De DOC.04 a DP, RDI, mié 15/05/13 la dirección del DOC.22 RDE proyecto\n19 GRUPO DE PROCESOS DE GPE EJECUCIÓN 20 Dirigir y gestionar la ejecución del diseño\nFin jue 16/05/13\nPred Suces Atributos eces oras 17;1 20;35; Documentar las acciones necesarias para 4;13; 36;37; definir, preparar, integrar y coordinar todos 12;1 38;39; los planes subsidiarios. 1;10; 40;41; 8;7;6 42;31; ;5 32;33; 34;43; 19;44\n21 Recopilar requisitos de Pendiente un proyecto de de definir edificación\nRDI, EE, lun 20/05/13 EP, EC, EI, ECTE\n22 Definir dependencias entre requisitos\nRDI, EE, lun 17/06/13 EP, EC, EI, ECTE\n23 Recopilar y procesos de Pendiente un proyecto de de definir edificación\nRDI, EE, mié 18/09/13 EP, EC, EI, ECTE\nEjecutar el trabajo definido en el plan para la dirección del proyecto para cumplir con los objetivos del de las actividades de diseño (definir sus características) de la aplicación informática\nRecopilar los entregables que exige la normativa española en los proyectos de ejecución, organizarlos temática y jerárquicamente y establecer una nomenclatura. 23;25 Evaluar las relaciones de dependencia entre los entregables antes mencionados (qué entregable o entregables deben haberse realizado para poder realizar otro u otros). 24\nRecopilar y evaluar los procesos más comunes en la elaboración de un proyecto de edificación y asociar entregables PGCPE DOC.12, página 26 de 77\nHOJA DE ACTIVIDADES Proceso/actividad 24 Recopilar roles y responsabilidades\n25 Elaborar la lógica interna que rige el software 26 Definir las funcionalidades de la aplicación\nVinculada a Responsa Comienzo bles Pendiente RDI, EE, jue 17/10/13 de definir EP, EC, EI, ECTE\nRDI, EE, mié 18/09/13 EP, EC, EI, ECTE RDI, EE, mié 25/09/13 EP, EC, EI, ECTE\nPred Suces Atributos eces oras 23 28 Recopilar roles existentes en los proyectos de edificación en función de los estructuras organizativas más comunes en las empresas y los procesos recopilados en la actividad 23 22 26;28 Extraer las reglas lógicas que relacionan los entregables y los procesos recopilados en las actividades 21 y 23 25 27;28 Establecer las funcionalidades de la aplicación en función de los requisitos iniciales, el alcance y la lógica interna de la aplicación. 26 28 Diseñar conjunto de imágenes y entornos gráficos para representar la información y acciones disponibles en la interfaz.\n27 Diseñar la interfaz\nRDI, EE, jue 10/10/13 EP, EC, EI, ECTE\n28 Dirigir y gestionar la ejecución del desarrollo\n24;2 30FF;2 Ejecutar el trabajo definido en el plan para 5;26; 9CC la dirección del proyecto para cumplir con 27 los objetivos de las actividades de\nRDE, I1, I2, jue 24/10/13 I3, I4, I5\n30 Crear plataforma online\nRDE, I1, I2, vie 20/12/13 I3, I4, I5\ndesarrollo (implementación informática del Crear una plataforma de información del producto, versiones de prueba y comercialización del prototipo en su caso. Realizar reuniones con interesados(distribuidas en el tiempo en función de los entregables) con distintas PGCPE DOC.12, página 27 de 77\nHOJA DE ACTIVIDADES Proceso/actividad 31 Realizar reuniones periódicas con interesados\nVinculada a Responsa Comienzo bles DOC.25 Y 26 RDE, I1, I2, lun 20/05/13 I3, I4, I5\n32 Adquirir desarrollar y DOC.27 y 28 DP dirigir el equipo de proyecto 33 GRUPO DE PROCESOS DE GPS SEGUIMIENTO Y CONTROL\nFin vie 07/03/14\nPred Suces Atributos eces oras 18 46 Realizar reuniones con interesados(distribuidas en el tiempo en función de los entregables) con distintas finalidades. 18 46 Realizar la adquisición, desarrollo y dirección del equipo de proyecto.\n34 Monitorear y controlar DOC.29 el trabajo del proyecto\n35 Realizar el control integrado de cambios\n36 Verificar y controlar el DOC.31 alcance 37 Controlar el DOC.32 cronograma y el presupuesto\nRevisar, analizar y regular el avance a fin de cumplir con los objetivos de desempeño definidos en el plan para la dirección del Revisar todas las solicitudes de cambios, aprobar los cambios y gestionar los cambios a los entregables, a los activos de los procesos de la organización, a los documentos del proyecto y al plan para la dirección del proyecto. Formalizar la aceptación de los entregables del proyecto que se han completado y Monitorear la situación del proyecto para actualizar el avance y el presupuesto del mismo y gestionar cambios a la línea base del cronograma y línea base de costo. PGCPE DOC.12, página 28 de 77\nVinculada a Responsa Comienzo bles 38 Realizar el control y el DOC.33 DP lun 20/05/13 aseguramiento de calidad\n39 Informar el desempeño DOC.34\n40 Monitorear y controlar DOC.35 los riesgos\n41 Administrar las adquisiciones\n42 GRUPO DE PROCESOS DE GPC CIERRE\nPred Suces Atributos eces oras 18 46 Monitorear y registrar los resultados de la ejecución de actividades de control de calidad, a fin de evaluar el desempeño y recomendar cambios necesarios. Auditar los requisitos de calidad y los resultados 18 46 Recopilar y distribuir la información sobre el desempeño, incluyendo los informes de estado, las mediciones del avance y las proyecciones. 18 46 Implementar planes de respuesta a los riesgos, dar seguimiento a los riesgos identificados, e identificar nuevos riesgos. 18\n43 Realizar la transición del producto final\n29;3 45 0;18\nGestionar las relaciones de adquisiciones, supervisar el desempeño del contrato y efectuar cambios y correcciones según sea\nPreparar la inclusión del producto informático en otra aplicación ya existente o la transición de éste a otro proyecto con un alcance mayor (establecer reuniones con el nuevo equipo, transmitir el conocimiento adquirido). esLa necesario, Medición y Planificar, valoraciónside: relación tareas entre requisitos iniciales y alcance obtenido, el grado de satisfacción de los interesados, la aportación de cada uno de los miembros PGCPE DOC.12, página 29 de 77\nVinculada a Responsa Comienzo bles 45 Cerrar las adquisiciones DOC.39 DP lun 17/03/14\nPred Suces Atributos eces oras 45;3 47 Realizar el cierre econ贸mico del proyecto, 1;32; definir estado de los coste finales, proceder 33;3 al cierre de facturaci贸n. 5;36; 46 Realizar y firmar acta de cierre de proyecto.\nPGCPE DOC.12, p谩gina 30 de 77\nCRONOGRAMA versión ( 1 ) Redactado por Revisado por Aprobado por\nCALENDARIO DE FESTIVOS DADOS DURANTE EL CICLO DE VIDA DEL PROYECTO Festividades Comienzo Fin Duración Día del Trabajo 01/05/2013 1 día Día Das Letras Galegas 17/05/2013 1 día San Juan 24/06/2013 1 día Santiago Apóstol 25/07/2013 1 día Vacaciones estivales 12/08/2013 16/08/2013 5 días Asunción de la Virgen 15/08/2013 1 día Festividad del Rosario 07/10/2013 1 día Fiesta Nacional Española 12/10/2013 1 día Día de Todos los Santos 01/11/2013 1 día Día de la Constitución Española 06/12/2013 1 día Navidad 25/12/2013 1 día Año Nuevo 01/01/2014 1 día Epifanía del Señor 06/01/2014 1 día San José 19/03/2013 1 día JORNADA LABORAL Rol DP RDI, RDE, I1-5, EE, ECTE, EI, EP, EC\nmañana Comienzo 8:00 9:00\nFin 13:00 13:00\nTarde Comienzo 16:00 16:00\nTotal Fin 21:00 20:00\nPGCPE DOC.13, página 31 de 77\nLÍNEA BASE DE PRESUPUESTO versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por LÍNEA BASE DE PRESUPUESTO Proceso/actividad\n1 GRUPO PROCESOS DE INICIO\n2 Desarrollar el acta de constitución del proyecto 3 Identificar interesados 4 GRUPO DE PROCESOS DE PLANIFICACIÓN 5 Recopilar requisitos 6 Definir el alcance 7 Crear la EDT 8 Definir las actividades 9 Estimar los recursos de las actividades 10 Desarrollar el cronograma del proyecto 11 Determinar el presupuesto 12 Planificar la calidad 13 Desarrollar el plan de personal 14 Planificar las comunicaciones 15 Planificar la gestión de riesgos 16 Identificar los riesgos y evaluarlos. 17 Planificar la respuesta a los riesgos 18 Desarrollar el plan para la dirección del proyecto 19 GRUPO DE PROCESOS DE EJECUCIÓN 20 Dirigir y gestionar la ejecución del diseño 21 Recopilar requisitos de un proyecto de edificación\njue 18/04/13 lun 22/04/13 mar 23/04/13 mié 24/04/13 vie 26/04/13 lun 29/04/13 mar 30/04/13 vie 03/05/13 mar 07/05/13 vie 10/05/13 vie 10/05/13 vie 10/05/13 vie 10/05/13 vie 10/05/13 lun 13/05/13 mar 14/05/13 mié 15/05/13 jue 16/05/13 lun 20/05/13 lun 20/05/13\nmar 23/04/13 vie 19/04/13 mar 23/04/13 jue 16/05/13 jue 25/04/13 vie 26/04/13 lun 29/04/13 jue 02/05/13 lun 06/05/13 jue 09/05/13 mar 14/05/13 mar 14/05/13 mar 14/05/13 mar 14/05/13 vie 10/05/13 lun 13/05/13 mar 14/05/13 jue 16/05/13 vie 07/03/14 mié 05/03/14\nCoste total Coste total grupo procesos actividad 2.105 € 1.065 € 1.040 €\n7.602 € 1.040 € 520 € 520 € 1.040 € 865 € 1.560 € 312 € 312 € 257 € 312 € 104 € 104 € 104 € 552 €\n160.649 € 31.200 € 12.000 € DOC.14, página 32 de 77\nLÍNEA BASE DE PRESUPUESTO Proceso/actividad\n22 Definir dependencias entre requisitos 23 Recopilar y procesos de un proyecto de edificación 24 Recopilar roles y responsabilidades 25 Elaborar la lógica interna que rige el software 26 Definir las funcionalidades de la aplicación 27 Diseñar la interfaz 28 Dirigir y gestionar la ejecución del desarrollo 29 Desarrollar aplicación 30 Crear plataforma online 31 Realizar reuniones periódicas con interesados 32 Adquirir desarrollar y dirigir el equipo de proyecto 33 GRUPO DE PROCESOS DE SEGUIMIENTO Y CONTROL 34 Monitorear y controlar el trabajo del proyecto 35 Realizar el control integrado de cambios 36 Verificar y controlar el alcance 37 Controlar el cronograma y el presupuesto 38 Realizar el control y el aseguramiento de calidad 39 Informar el desempeño 40 Monitorear y controlar los riesgos 41 Administrar las adquisiciones 42 GRUPO DE PROCESOS DE CIERRE 43 Realizar la transición del producto final 44 Elaborar lecciones aprendidas 45 Cerrar las adquisiciones 46 Cerrar el proyecto\nlun 17/06/13 mié 18/09/13 jue 17/10/13 mié 18/09/13 mié 25/09/13 jue 10/10/13 jue 24/10/13 jue 24/10/13 vie 20/12/13 lun 20/05/13 lun 20/05/13 jue 16/05/13 lun 20/05/13 lun 20/05/13 lun 20/05/13 lun 20/05/13 lun 20/05/13 lun 20/05/13 lun 20/05/13 lun 20/05/13 vie 07/03/14 lun 10/03/14 jue 13/03/14 lun 17/03/14 mar 18/03/14\nvie 14/06/13 mar 17/09/13 mié 16/10/13 mié 23/10/13 mar 24/09/13 mié 09/10/13 mié 23/10/13 mié 05/03/14 mié 05/03/14 vie 07/03/14 vie 07/03/14 vie 07/03/14 lun 10/03/14 lun 10/03/14 lun 10/03/14 lun 10/03/14 lun 10/03/14 lun 10/03/14 lun 10/03/14 lun 10/03/14 lun 10/03/14 lun 07/04/14 mié 12/03/14 lun 17/03/14 jue 20/03/14\nCoste total Coste total grupo procesos actividad 36.000 € 6.000 € 1.500 € 1.500 € 3.000 € 3.000 € 12.600 € 43.200 € 6.360 € 715 € 3.574 €\n28.785 € 3.597 € 3.595 € 3.593 € 3.600 € 3.600 € 3.600 € 3.600 € 3.600 €\n4.385 € 450 € 625 € 560 € 2.750 €\nDOC.14, página 33 de 77\nInforme del flujo de caja Costo 70000\nCosto acumulado 250000\n20000 50000 10000 0\nDOC.14, pรกgina 34 de 77\nPLAN DE CALIDAD versión ( 1 ) Redactado por Revisado por Aprobado por\nPLAN DE CALIDAD El aseguramiento y control de calidad será responsabilidad del DP, el cual, realizará la verificación de todos los entregables del proyecto sin una frecuencia definida, sino en función del v olumen de trabajo y de la complejidad dada en cada etapa. Para ello empleará las métricas de calidad indicadas en el DOC.16, las cuales atienden a distintos aspectos (calidad del proyecto, producto,control de documentación y diseño y desarrollo de la aplicación). El objetivo es medir la calidad de los distintos procesos o entregables, evaluarlos y tomar medidas correctoras en caso necesrio, mediante las herramientas del control integrado de cambios. Posteriormente se realizará la medición y evaluación de si el cambio adoptado es beneficioso o no.\nPGCPE DOC.15, página 35 de 77\nMÉTRICAS DE CALIDAD versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por MÉTRICAS DE CALIDAD DEL PROYECTO Recursos empleados Se medirán los recursos empleados (tiempo, personal y coste) en las distintas actividades y se comparará con otras actividades en las actividades iguales o de similares características realizadas previamente en el mismo o en otros proyectos. Recursos empleados Se medirán los recursos empleados (tiempo, personal y coste) en las evaluaciones definidas en las métricas de calidad y se en la evalución comparará con otras evaluaciones realizadas previamente en otros proyectos. Recursos empleados Se medirán los recursos empleados (tiempo, personal y coste) en las actividades resultantes de cambios realizados debido a en los cambios cualquier factor. Grado de satisfacción de los miembros del proyecto\nSe evaluará durante la actividad "elaborar lecciones aprendidas".\nMÉTRICAS DE CALIDAD DEL PRODUCTO Corrección Grado con el cual el software cumple mediante su funcionalidad los requisitos definidos inicialmente. Se establecerá un porcentaje. Facilidad de Sencillez con la cual el software puede corregirse si existe un error, un cambio de entorno o una ampliación. mantenimiento Facilidad de uso Se medirá la facilidad de uso mediante pruebas de funcionalidad realizadas durante las reuniones programadas con expertos a lo largo de la evolución del proyecto. Se establecerá un porcentaje Grado de Se evaluará durante la actividad "elaborar lecciones aprendidas". satisfacción de los miembros del proyecto PGCPE DOC.16, página 36 de 77\nMÉTRICAS DE CALIDAD DEL CONTROL DE DOCUMENTACIÓN Organización de Todo documento digital se guardará en la carpeta C:/PROYECTOS/PGCP documentos digitales Organización de Todo documento impreso se guardará los archivadores denominados “PGCP1, 2, 3, n.”. Dichos archivadores poseen documentos subapartados cuya nomenclatura coincide con los distintos entregables enunciados en la EDT. impresos Control de El formato de los documentos impresos será DIN-4 apaisado con formato digital según plantilla ubicada en carpeta documentos C:/PROYECTOS/PGCP/PLANTILLAS. En el encabezado se definirá el nombre del documento (con la abreviatura especificada en la escritos impresos EDT), la versión del documento "versión(n)", se definirá el rol (según la nomenclatura definida en la estructura de desglose de recursos), el nombre, los apellidos y la firma de la persona que lo redacta, lo revisa y lo aprueba (pueden ser la misma persona). Asimismo se incluirá la fecha con el formato definido, dia/mes/año. Control de El formato de los documentos digitales será documento de Microsoft word 2010 con el diseño de página según plantilla ubicada documentos escritos en carpeta C:/PROYECTOS/PGCP/PLANTILLAS. El nombre del archivo será año/mes/día/_PGCP_NOMBRE DEL DOCUMENTO (todo digitales en mayúsculas) Control de Se graparán o se unirán con un clip a una plantilla estandarizada que haga referencia al documento en cuestión. documentos externos impresos Si el formato es compatible se convertirán a documento de Microsoft Word 2010, si no es así, se creará una carpeta con la Control de documentos nomenclatura año/mes/día/_PGCP_NOMBRE DEL DOCUMENTO (todo en mayúsculas) y dentro de ella se alojará el documento externos digitales externo y una plantilla estandarizada que haga referencia a éste. MÉTRICAS DE CALIDAD DEL DISEÑO Y DESARROLLO DE LA APLICACIÓN Recopilación de Se recopilarán todos los entregables, relaciones de dependencia entre entregables, procesos y roles de un proyecto de información edificación. Deberá incluirse una nomenclatura que acompañe y clasifique todos los elementos. Lógica interna del Se enunciarán las reglas lógicas. Deberá incluirse una nomenclatura que acompañe y clasifique todas las reglas. software Se enunciarán y explicarán las distintas funcionalidades. Se acompañarán de diseños no funcionales en imágenes de extensión Diseño de la funcionalidad de la .png. aplicación Desarrollo Se establecerán durante el proceso de desarrollo las métricas necesarias para la correcta evolución del proyecto. PGCPE DOC.16, página 37 de 77\nPLAN DE PERSONAL versión ( 1 ) Redactado por Revisado por Aprobado por\nEl personal se organiza jerárquicamente, organizado en dos grupos diferenciados, el grupo responsable del diseño, formado por especialistas en edificación y el grupo responsable del desarrollo, constituído por especialistas en informática. Ambos poseen responsables y se coordinan bajo la figura del director de proyecto. DIAGRAMA JERÁRQUICO Niveles 1º 2º 3º DP Director de Proyecto RDI Responsable diseño EE Especialista estructuras EP Especialista proyectos EC Especialista construcción EI Especialista instalaciones ECTE Especialista código técnico RDE Responsable desarrollo I1 Ingeniero informático 1 I2 Ingeniero informático 2 I3 Ingeniero informático 3 I4 Ingeniero informático 4 I5 Ingeniero informático 5\nPGCPE DOC.17, página 38 de 77\nESTRUCTURA DESGLOSE DE RECURSOS, RESPONSABILIDADES, AUTORIDAD Y COMPETENCIAS Rol Responsabilidades Autoridad Competencias Código DP\nDesarrollar todas las tareas relacionadas con los grupos de planificación, dirigir y gestionar los grupos de proceso de ejecución, de seguimiento y control y de cierre.\nProposición y aceptación de cambios en el proyecto y en el producto (en conjunto con RDI y RDE). Responsable Dirigir y gestionar la ejecución del Proposición y diseño diseño de la aplicación. Analizar la aceptación de información generada por los cambios en el especialistas en estructuras, proyecto y en el proyectos, construcción, producto (en instalaciones y código técnico y conjunto con DP estructurarla según la lógica interna y RDE). que rige el software.\nLiderazgo, habilidades interpersonales, experiencia en dirección de proyectos, conocimientos de proyectos TIC, conocimientos del quehacer profesional en el sector del desarrollo de proyectos de edificación (no necesariamente 25,00 €/h exhaustivos). Liderazgo, habilidades interpersonales, conocimientos de proyectos TIC, conocimientos del quehacer profesional en el sector del desarrollo de proyectos de edificación (no necesariamente exhaustivos).\nVisión de conjunto, capacidad de síntesis, conocimiento profundo del diseño de estructuras, dilatada experiencia en el manejo del Código Técnico de la Edificación.\nRecopilar requisitos, definir Elaborar dependencias entre ellos y diagramas de asociarlos a procesos. Para ello flujos. analizará los documentos DB SE del Proposición de manual de calidad arquitectónico así cambios como los planos relacionados que se hallan en el documento II de dicho manual y otros documentos que considere necesarios como puede ser el CTE.\n15,00 €/h PGCPE DOC.17, página 39 de 77\nESTRUCTURA DESGLOSE DE RECURSOS, RESPONSABILIDADES, AUTORIDAD Y COMPETENCIAS Rol Responsabilidades Autoridad Competencias Código EP\nElaborar diagramas de flujos. Proposición de cambios\nVisión de conjunto, capacidad de síntesis, conocimiento profundo del proceso proyectual, experiencia en el desarrollo proyectos muy heterogéneos, tanto de obra mínima, como de gran obra (por ejemplo un proyectista que haya diseñado tanto viviendas unifamiliares como hospitales). Dilatada experiencia en el manejo del Código Técnico de la Edificación. 15,00 €/h\nEspecialista Recopilar requisitos, definir construcción dependencias entre ellos y asociarlos a procesos. Para ello analizará los documentos DB HS Y HR del manual de calidad arquitectónico así como los planos relacionados que se hallan en el documento II de dicho manual y otros documentos que considere necesarios como puede ser el CTE.\nVisión de conjunto, capacidad de síntesis, conocimiento profundo de la construcción, dilatada experiencia en el manejo del Código Técnico de la Edificación.\nPGCPE DOC.17, página 40 de 77\nESTRUCTURA DESGLOSE DE RECURSOS, RESPONSABILIDADES, AUTORIDAD Y COMPETENCIAS Rol Responsabilidades Autoridad Competencias Código EI\nEspecialista Recopilar requisitos, definir Elaborar instalaciones dependencias entre ellos y diagramas de asociarlos a procesos. Para ello flujos. analizará los documentos DB HE del Proposición de manual de calidad arquitectónico así cambios como los planos relacionados que se hallan en el documento II de dicho manual y otros documentos que ECTE Especialista Recopilar requisitos, definir Elaborar código dependencias entre ellos y diagramas de técnico asociarlos a procesos. Para ello flujos. analizará los documentos III (pliego Proposición de de condiciones), IV (mediciones), V cambios (presupuesto) y VI (proyectos parciales y otros documentos técnicos complementarios). Asesorará a los demás profesionales RDE Responsable Dirigir y gestionar la ejecución del Proposición y desarrollo desarrollo de la aplicación. aceptación de cambios en el proyecto y en el producto (en conjunto con DP y RDI)\nVisión de conjunto, capacidad de síntesis, conocimiento profundo en el cáculo de instalaciones de todo tipo, dilatada experiencia en el manejo del Código Técnico de la Edificación.\nVisión de conjunto, capacidad de síntesis, dilatada experiencia en el manejo del Código Técnico de la Edificación, a ser posible, persona que forme o haya formado parte en la creación o mejora de esta normativa.\nLiderazgo, habilidades interpersonales, conocimiento profundo del sector de las TIC.\nPGCPE DOC.17, página 41 de 77\nESTRUCTURA DESGLOSE DE RECURSOS, RESPONSABILIDADES, AUTORIDAD Y COMPETENCIAS Rol Responsabilidades Autoridad Competencias Código I1\nIngeniero Realizar actividades relacionadas informático 1 con el desarrollo.\nDesarrollo de la aplicación. Proposición de cambios\nIngeniero Realizar actividades relacionadas informático 2 con el desarrollo.\nIngeniero Realizar actividades relacionadas informático 3 con el desarrollo.\nIngeniero Realizar actividades relacionadas informático 4 con el desarrollo.\nIngeniero Realizar actividades relacionadas informático 5 con el desarrollo.\nCompetencias en ingeniería de software. Conocimientos de modelado funcional y modelado de datos así como conocimiento del lenguaje de programación empleado en 15,00 €/h el proyecto. Competencias en ingeniería de software. Conocimientos de modelado funcional y modelado de datos así como conocimiento del lenguaje de programación empleado en el proyecto. 15,00 €/h Competencias en ingeniería de software. Conocimientos de modelado funcional y modelado de datos así como conocimiento del lenguaje de programación empleado en el proyecto. 15,00 €/h Competencias en ingeniería de software. Conocimientos de modelado funcional y modelado de datos así como conocimiento del lenguaje de programación empleado en el proyecto. 15,00 €/h Competencias en ingeniería de software. Conocimientos de modelado funcional y modelado de datos así como conocimiento del lenguaje de programación empleado en el proyecto. 15,00 €/h\nPGCPE DOC.17, página 42 de 77\nPLAN PARA LA DIRECCIÓN DEL PERSONAL versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por Se empleará a personal de la propia organización para la dirección, gestión y desarrollo del proyecto, sin embargo, el diseño será responsabilidad de personal externo. PERSONAL Y PROCESO DE SELECCIÓN Niveles Rol Perteneciente Externo Proceso de selección 1º 2º 3º organización DP Director de Proyecto X Recopilará información sobre posibles candidatos acudiendo a las organizaciones de los stakeholders principales (por ejemplo, desarrolladores del software Memorias, Oficinas encargadas de la redacción del CTE, Colegio Oficial de Arquitectos de Galicia (promotor del Memorias 1 y 2), Escuela Técnica Superior de Arquitectura de A Coruña, Escuela Universitaria de Arquitectura Técnica, etc). RDI Responsable diseño X El RDI es una persona de la propia organización. Colaboracon el DIP en el proceso de selección. EE Especialista estructuras X El personal externo será adquirido mediante el proceso de selección EP Especialista proyectos X definido a continuación. EC Especialista construcción X EI X Especialista instalaciones ECTE Especialista código técnico X RDE X El RDE es una persona de la propia organización. Colaboracon el DIP Responsable desarrollo en el proceso de selección. I1 X El I1 es una persona de la propia organización. Ingeniero informático 1 I2 X El I2 es una persona de la propia organización. Ingeniero informático 2 I3 X El I3 es una persona de la propia organización. Ingeniero informático 3 Ingeniero informático 4 I4 X El I4 es una persona de la propia organización. I5 Ingeniero informático 5 X El I5 es una persona de la propia organización. PGCPE DOC.18, página 43 de 77\nPROCESO DE SELECCIÓN 1 Búsqueda de posibles candidatos a través de las organizaciones de los stakeholders principales, asimismo se publicarán anuncios de ofertas de trabajo a través de los medios de difusión de dichas organizaciones. 2\nLlamada a dichos candidatos. Se realizarán reuniones presenciales y/o virtuales en pequeños grupos según las especialidades en las cuales se expondrá una presentación del proyecto. Se fomentará un debate sobre el proyecto en el cual los candidatos expondrán su opinión, ideas y qué pueden aportar al proyecto. El DP, el RDE y el RDI deberán conducir el debate para escoger a dos posibles candidatos finalistas.\nEntrevisas individuales a los candidatos finalistas. En ellas se detallarán condiciones del contrato y se decidirá el candidato final.\nEl siguiente proceso será el inicio de la actividad 32 "adquirir, desarrollar y dirigir el equipo de proyecto.\nTIPO DE CONTRATO DEL PERSONAL EXTERNO El tipo de contrato es de CR, costos reembolsables. Se decide este tipo de contrato dado que la dificultad para realizar los diagramas de flujo es desconocida, no obstante, existe la posibilidad de, si el alcance se detalla a lo largo del avance del proyecto y se puede estimar con mayor exactitud el grado de esfuerzo necesario para desarrollar el trabajo de diseño, pueda cambiarse de contrato. Para ello se realizará inicialmente un contrato CR temporal de en torno a un mes, cuya duración sea más o menos un tercio del tiempo total estimado de la duración de los procesos de diseño, para posteriormente, renovar dicho contrato o cambiarlo por otro.\nPGCPE DOC.18, página 44 de 77\nPLAN DE GESTIÓN DE LAS COMUNICACIONES versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por COMUNICACIÓN EXTERNA Participantes Mensaje\nPromotor (oficina de proyectos) y DP\nStakeholders y DP\nVariable (Depende del Stakeholder) Ver DOC.03 Matriz de Stakeholders\nBetatesters y DP Recibir feedback a través de cuestionarios asociados a cada función de la versión de prueba de la aplicación\nA partir de la web entrada en funcionamien to de la versión demo de la plataforma\nRespons Moder Participantes Documentación able ador Sala DP Gerent Gerente org. Y Actualizaciones a los documentos de los Reuniones e org. DP procesos de Sede seguimiento y control Lugar a DP No hay DP (si es Actualizaciones a los decidir entre necesario, le documentos de los DP y acompañará el procesos de RDI o el RDE) seguimiento y Stakeholder control web DP No hay Betatesters Actualizaciones a los documentos de los procesos de seguimiento y control\nPGCPE DOC.19, página 45 de 77\nCOMUNICACIÓN INTERNA Participantes Mensaje Equipo de proyecto\nInformar sobre el desempeño del proyecto. Fomentar la unidad entre diseñadores y desarrolladores Mensajes dirigidos directamente a una persona.\nDocumento "TODO" (hoja de tareas personal)\nDISTRIBUCIÓN DE LA INFORMACIÓN OFICIAL 1º 2º 3º DP RDI EE EP EC EI ECTE RDE I1 I2 I3 I4 I5\nDirector de Proyecto Responsable diseño Especialista estructuras Especialista proyectos Especialista construcción Especialista instalaciones Especialista código técnico Responsable desarrollo Ingeniero informático 1 Ingeniero informático 2 Ingeniero informático 3 Ingeniero informático 4 Ingeniero informático 5\nRespons Moder Participantes Documentación able ador DP DP todos Actualizaciones a los documentos de los procesos de seguimiento y control DP Actualizaciones a los documentos de los procesos de seguimiento y control.\nEn la distribución de la información oficial los miembros de cada nivel solo puede comunicarse con su directamente superior o inferior. De este modo, el ingeniero informático I5 para solicitar un cambio, por ejemplo, debe informar al RDE y este a su vez, al DP. Esto no se hace para fomentar la jerarquía sino porque el DP no ha de ser una persona experta en las dos áreas de especialidad existentes en el proyecto, de modo que una solicitud de cambio realizada por dicho ingeniero informático posiblemente no pueda ser evaluada directamente por el DP sin antes consultar la opinión del RDE.\nPGCPE DOC.19, página 46 de 77\nPLAN DE GESTIÓN DE RIESGOS versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por PLAN DE GESTIÓN Actividades Planificar la gestión de riesgos Identificar los riesgos y evaluarlos. Planificar la respuesta a los riesgos Monitorear y controlar los riesgos\nResponsable DP DP DP DP\nESTRUCTURA DE DESGLOSE DE RIESGOS Y OPORTUNIDADES PROYECTO DIRECCIÓN DISEÑO\nAsesora/informa Toda persona de la org. o ajena a la org. Toda persona de la org. o ajena a la org. Toda persona de la org. o ajena a la org. Toda persona de la org. o ajena a la org.\nErrores de planificación Errores de gestión de ejecución Requisitos mal enunciados o mal aplicados Diagramas de flujo excesivamente complejos Falta de usabilidad de la aplicación Problemas de desarrollo Existe o se está desarrollando una aplicación similar Falta de operatividad dentro de otras aplicaciones Oferta de colaboración con otra entidad desarrolladora de un aplicación similar Personal no cualificado Problemas comunicación\nPGCPE DOC.20, página 47 de 77\nIDENTIFICACIÓN DE RIESGOS Y OPORTUNIDADES, ANÁLISIS CUALITATIVO Y CUANTITATIVO versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por El proceso identificación de riesgos, al ser un proceso iterativo, (pueden identificarse nuevos riesgos a lo largo del proyecto) también define cómo y cuándo se realizará la revisión de la identificación de riesgos, a continuación se detallan las actividades a realizar: La primera identificación de riesgos se realiza por parte del DP individualmente y a través de las entrevistas realizadas en el proceso desarrolla el plan de recursos humanos, en dichas entrevistas (ver DOC.18) se reúne a expertos, posibles candidatos a formar parte del equipo y se les expone el proyecto para reflexionar sobre éste. Posteriormente, dentro del grupo de procesos de seguimiento y control, el DP realizará el proceso de monitorear y controlar los riesgos, en las reuniones de trabajo diarias de 10 minutos se detectarán los posibles nuevos riesgos incluyéndolos en esta matriz y evaluando sus posibles respuestas. De igual modo se procederá durante todas las reuniones con Stakeholders. MATRIZ DE PROBABILIDAD, IMPACTO, IMPORTANCIA, ANÁLISIS CUANTITATIVO Y CUALITATIVO DE RIESGOS riesgo impacto probabilid import % coste Acciones correctivas y explicación del coste asociado al riesgo. (0 - 1) ad (0 - 1) ancia asociado Diagramas de 60% 40% alta 70% 7.200 € El riesgo de que los diagramas de flujo que componen la estructura de la flujo aplicación sean más complejos de lo esperado es medio, si esto ocurre, la excesivamente única opción es dedicar más recursos humanos a su elaboración o prolongar complejos la duración del proceso. El valor del coste definido es el 20% del presupuesto de la actividad 22 "Definir dependencias entre requisitos".\nPGCPE DOC.21, página 48 de 77\nMATRIZ DE PROBABILIDAD, IMPACTO, IMPORTANCIA, ANÁLISIS CUANTITATIVO Y CUALITATIVO DE RIESGOS riesgo impacto probabilid import % coste Acciones correctivas y explicación del coste asociado al riesgo. (0 - 1) ad (0 - 1) ancia asociado Falta de 70% 5% baja 30% 3.600 € El riesgo de que la aplicación tenga una usabilidad menor de la esperada usabilidad de la debido a la complejidad de este, es baja, si esto ocurriera sería necesario, aplicación simplificar los diagramas de flujo mediante la redefinición de las dependencias entre requisitos de la actividad 22 Definir Dependencias entre requisitos. Es imposible conocer exactamente el grado de complejidad de la aplicación pues no se conoce el grado de complejidad de los diagramas de flujo. El valor del coste definido es el 10% del presupuesto de la actividad 22 "Definir dependencias entre requisitos". Problemas de desarrollo\nSe está desarrollando una aplicación igual o similar.\nFalta de operatividad dentro de otras aplicaciones\n2.160 € Es muy poco probable que haya problemas de desarrollo al tratarse de una aplicación muy sencilla y poseer la organización un motor de procesos a partir del cual llevarla a cabo. ? El riesgo de existir una aplicación similar supone un impacto enorme, sin embargo, las reuniones iniciales realizadas con organizaciones tan importantes como los propios desarrolladores del MEMORIAS o redactores del CTE permiten asegurar con bastante fiabilidad la no existencia de una aplicación similar. De existir dicha aplicación el coste debería analizarse pues dependería del volumen de negocio de la organización que está desarrollando dicha aplicación, la calidad de dicha aplicación, etc. ?\nLa falta de operatividad es un riesgo que debe contemplarse a través de reuniones con stakeholders del sector, estudio de los lenguajes de programación más usados, etc. Si fuera necesario reescribir el código en otro lenguaje. De darse este riesgo el coste debería ser analizado pues la complejidad de cada lenguaje es muy heterogénea.\nPGCPE DOC.21, página 49 de 77\nMATRIZ DE PROBABILIDAD, IMPACTO, IMPORTANCIA, ANÁLISIS CUANTITATIVO Y CUALITATIVO DE RIESGOS riesgo impacto probabilid import % coste Acciones correctivas y explicación del coste asociado al riesgo. (0 - 1) ad (0 - 1) ancia asociado Personal no 80% 10% media 50% 2.000 € La monitorización de este riesgo debe ser realizada al principio del proceso cualificado de ejecución diariamente. El personal del grupo de diseño realiza una labor que es difícil evaluar en una entrevista la capacitación para realizarla por ello se destina una partida de 2.000€ para, en el caso de un despido, realizar una búsqueda rápida de un suplente.\nMATRIZ DE PROBABILIDAD, IMPACTO, IMPORTANCIA, ANÁLISIS CUANTITATIVO Y CUALITATIVO DE RIESGOS riesgo impacto probabilid import % coste Acciones correctivas y explicación del coste asociado al riesgo. (0 - 1) ad (0 - 1) ancia asociado Problemas 30% 5% media 50% 8.032 € Al tratarse de un proyecto compuesto por un equipo heterogéneo, los comunicación problemas de comunicación pueden suponer un riesgo que dificulte el avance del proyecto. El coste asociado al riesgo es el resultado de multiplicar el presupuesto del grupo de procesos de ejecución por 5% PRESUPUESTO DE CONTINGENCIA El presupuesto de contigencia se obtiene multiplicando el presupuesto estimado destinado a cada riesgo por un valor % relacionado con la importancia del riesgo según la relación: Importancia baja=30%, media=50% y alta=70%. (ver tabla superior) PRESUPUESTO DE CONTINGENCIA\nPGCPE DOC.21, página 50 de 77\nComo riesgo positivo posible durante el desarrollo del proyecto, solo se contempla uno, la posibilidad de colaborar con otras entidades: MATRIZ DE PROBABILIDAD, IMPACTO, IMPORTANCIA, ANÁLISIS CUANTITATIVO Y CUALITATIVO DE OPORTUNIDADES Oferta de 1,00 0,50 media 50% ? La posibilidad de, durante las reuniones con stakeholders, encontrar a colaboración con organizaciones que estén realizando aplicaciones que puedan interactuar otra entidad con la propia aplicación supone la posibilidad de emprender una desarrolladora de colaboración que aumentaría el valor del proyecto en gran medida. una aplicación similar\nPGCPE DOC.21, página 51 de 77\nPLAN DE RESPUESTA A LOS RIESGOS Y OPORTUNIDADES versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por PLAN DE RESPUESTA A LOS RIESGOS Y OPORTUNIDADES riesgo import coste Frecuencia y ancia Resp contexto de la onsa monitorización ble del riesgo Diagramas de media 7.200 € DP Semanal (desarrollada flujo excesivamente durante la actividad 22) complejos\nAcciones correctivas y explicación del coste Propi asociado al riesgo. etario del DP El riesgo de que los diagramas de flujo que Se estima que los diagramas riesgo de flujo poseerán unos 6000 componen la estructura de la aplicación sean más complejos de lo esperado es medio, si esto procesos. Analizar si el avance es progresivo hacia ocurre, la única opción es dedicar más recursos esta cifra. Si el desvío es humanos a su elaboración o prolongar la duración del proceso. El valor del coste definido mayor de 10% se considera es el 20% del presupuesto de la actividad 22 disparador. "Definir dependencias entre requisitos".\nPGCPE DOC.22, página 52 de 77\nPLAN DE RESPUESTA A LOS RIESGOS Y OPORTUNIDADES riesgo import coste Frecuencia y ancia Resp contexto de la onsa monitorización ble del riesgo Falta de baja 3.600 € DP Semanal usabilidad de la (durante la aplicación actividad 29)\nEl DP junto al RDI y el RDE serán los responsables de definir si la funcionalidad es suficiente según su propio criterio. A posteriori, cuando la versión de prueba esté realizada, se someterá a una segunda evaluación por parte de betatesters\n2.160 € DP\nSemanal (durante la actividad 29)\nLa aparición de problemas será evaluada por el RDE\nEl coste DP depende de factores a analizar en el momento en que aparezca\nSemanal (en las reuniones con stakeholders)\nExiste o se está desarrollando una aplicación igual o similar.\nAcciones correctivas y explicación del coste Propi asociado al riesgo. etario del riesgo DP El riesgo de que la aplicación tenga una usabilidad menor de la esperada debido a la complejidad de este, es baja, si esto ocurriera sería necesario, simplificar los diagramas de flujo mediante la redefinición de las dependencias entre requisitos de la actividad 22 Definir Dependencias entre requisitos. Es imposible conocer exactamente el grado de complejidad de la aplicación pues no se conoce el grado de complejidad de los diagramas de flujo. El valor del coste definido es el 10% del presupuesto de la actividad 22 "Definir dependencias entre requisitos". DP Es muy poco probable que haya problemas de desarrollo al tratarse de una aplicación muy sencilla y poseer la organización un motor de procesos a partir del cual llevarla a cabo. DP El riesgo de existir una aplicación similar supone un impacto enorme, sin embargo, las reuniones iniciales realizadas con organizaciones tan importantes como los propios desarrolladores del MEMORIAS o redactores del CTE permiten asegurar con bastante fiabilidad la no existencia de una aplicación similar. De existir dicha aplicación el coste debería analizarse pues dependería del volumen de negocio de la PGCPE DOC.22, página 53 de 77\nPLAN DE RESPUESTA A LOS RIESGOS Y OPORTUNIDADES riesgo import coste Frecuencia y ancia Resp contexto de la onsa monitorización ble del riesgo Falta de baja El coste DP Semanal (en operatividad depende de las reuniones dentro de otras factores a con analizar en stakeholders) aplicaciones el momento en que aparezca Personal no cualificado\n2.000 € DP\n8.032 € DP\nDiaria durante los primeros 5 días de cada actividad y semanal posteriormente Diaria, durante las reuniones de 10 minutos de equipo de proyecto.\nAcciones correctivas y explicación del coste Propi asociado al riesgo. etario del riesgo El lenguaje empleado es DP La falta de operatividad es un riesgo que debe incompatible con al menos 3 contemplarse a través de reuniones con aplicaciones de uso stakeholders del sector, estudio de los lenguajes extendido en el mercado que de programación más usados, etc. Si fuera podrían interactuar con la necesario reescribir el código en otro lenguaje. aplicación. De darse este riesgo el coste debería ser analizado pues la complejidad de cada lenguaje es muy heterogénea. Más de dos personas de la org. realizan la actividad de la que son responsables de forma errónea o poco eficientemente.\nDurante el 20% de las DP reuniones se dan indicios de problemas de comunicación de cualquier tipo.\nLa monitorización de este riesgo debe ser realizada al principio del proceso de ejecución diariamente. El personal del grupo de diseño realiza una labor que es difícil evaluar en una entrevista la capacitación para realizarla por ello se destina una partida de 2.000€ para, en el caso Al tratarse de un proyecto compuesto por un equipo heterogéneo, los problemas de comunicación pueden suponer un riesgo que dificulte el avance del proyecto. El coste asociado al riesgo es el resultado de multiplicar el presupuesto del grupo de procesos de ejecución por 5%\nPGCPE DOC.22, página 54 de 77\nPLAN DE RESPUESTA A LOS RIESGOS Y OPORTUNIDADES riesgo import coste Frecuencia y Disparadores ancia Resp contexto de la onsa monitorización ble del riesgo Oferta de media El beneficio DP Semanal (en Oferta colaboración con depende de las reuniones otra entidad factores a con analizar en stakeholders) desarrolladora de el una aplicación similar momento en que aparezca\nAcciones correctivas y explicación del coste Propi asociado al riesgo. etario del riesgo DP La posibilidad de, durante las reuniones con stakeholders, encontrar a organizaciones que estén realizando aplicaciones que puedan interactuar con la propia aplicación supone la posibilidad de emprender una colaboración que aumentaría el valor del proyecto en gran medida.\nPGCPE DOC.22, página 55 de 77\nDOCUMENTO DE DESEMPEÑO DE TRABAJO versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por Tanto la actividad 20 "Dirigir y gestionar la ejecución del diseño" cuyo responsable es el RDI como la actividad 28 "Dirigir y gestionar la ejecución del desarrollo", cuyo responsable es el RDE, consisten en ejecutar el trabajo definido en el plan para la dirección del proyecto para cumplir con los objetivos del de las actividades de diseño y desarrollo de la aplicación informática. Las salidas estandarizadas de dicha actividad son los "Documentos de Desempeño de trabajo" y "solicitud de cambio". Dicha información se incluirá en el MS PROJECT como una actualización a la línea base. A continuación incluyo un documento tipo de desempeño rellenado con un hipotético entregable. DOCUMENTO DE DESEMPEÑO DE TRABAJO Entregable Nº actividad responsable/ asociada s Recopilación de Act. 21 "Recopilar EE, EP, EC, EI y ECTE requisitos de un procesos de un proyecto de proyecto de edificación edificación"\nestado del entregable Se han definido correctamente los requisitos, agrupados y jerarquizados según la nomenclatura dada en el Manual de Calidad del Proyecto Arquitectónico. Ha sido necesario incluir entregables que si bien no estaban recogidos en el Código Técnico son indispensables para la redacción de un proyecto, la mayoría de estos entregables hacen referencia al apartado de diseño inicial del edificio, proceso tratado escuetamente en el CTE.\nCRONOGRAMA tiempo estimado\nfin estimado tiempo invertido\nPRESUPUESTO Presupuesto estimado Presupuesto real\nPGCPE DOC.23, página 56 de 77\nDOCUMENTO DE SOLICITUD DE CAMBIO versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por Tanto la actividad 20 "Dirigir y gestionar la ejecución del diseño" cuyo responsable es el RDI como la actividad 28 "Dirigir y gestionar la ejecución del desarrollo", cuyo responsable es el RDE, consisten en ejecutar el trabajo definido en el plan para la dirección del proyecto para cumplir con los objetivos del de las actividades de diseño (definir sus características) de la aplicación informática. Las salidas estandarizadas de dicha actividad son los "Documentos de Desempeño de trabajo" y "solicitud de cambio". Dicha información se incluirá en el MS PROJECT como una actualización a la línea base. A continuación incluyo un documento tipo de solicitud de cambio rellenado con una hipotética solicitud.\nDOCUMENTO DE SOLICITUD DE CAMBIO cambio Incluír entre los requisitos de un proyecto de edificación los requisitos relacionados con elaboración de un diagrama funcional del solicitado programa del edificio. IMPACTO SOBRE EL PROYECTO coste Creo que no será relevante tiempo Creo que no será relevante alcance Aumenta calidad Aumenta IMPACTO DE LA ACEPTACIÓN O DENEGACIÓN DE CAMBIO Aunque suponga un aumento consumo de recursos tanto humanos como de coste y tiempo, se trata de un paso no recogido en el CTE pero que gran cantidad de profesionales realizan, la relación entre el esfuerzo invertido y la satisfacción que provocará en un porcentaje enorme de usuarios es asumible.\nPGCPE DOC.24, página 57 de 77\nPLANIFICACIÓN DE REUNIÓN CON STAKEHOLDERS versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por La actividad 31 "Preparar y realizar reuniones con expertos", responsabilidad del DP, incluye toda la comunicación externa del proyecto durante la fase de ejecución, a continuación se incluye el Documento de Planificación de Reunión con stakeholders. PLANIFICACIÓN DE REUNIÓN CON STAKEHOLDERS Fecha 16/05/2013 Hora de inicio y finalización 18:00-19:00 Lugar Sede de la empresa desarrolladora del MEMORIAS 2 Participantes de la org. DP (xxx) como portavoz, RDE (xxx) y RDI (xxx) como asesores (rol/nombre) Objetivo final de la propia org. Exponer el proyecto, obtener experiencia Participantes de la/s otra/s parte/s Director gerente, ? (rol/nombre) Objetivo de la/s otra/s parte/s ? Factores ambientales La empresa ha realizado un proyecto similar al que emprendemos con la salvedad de que no ha realizado un diagrama de flujo personalizable ni ha incluído en su aplicación la posibilidad de realizar proyectos mediante trabajo en equipo. Ha vendido su aplicación a Cype Ingenieros recientemente, desconocemos la razón. Objetivos operativos (temas a tratar, modo de tratarlos) Orden del día: Material (documentos) Material (herramientas) Notas\nExponer nuestra idea de proyecto y buscar similitudes con el proyecto que ellos emprendieron en su día para establecer líneas de actuación a lo mejor no incluídas en la planificación. Presentaciones, exposición del proyecto, solicitud de información, establecimiento de convenios o transmisión de información compartida Presentación PPT, presentación impresa, Plan de Gestión de Proyecto ninguna ninguna PGCPE DOC.25, página 58 de 77\nACTA DE REUNIÓN CON STAKEHOLDERS versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por La actividad 31 "Preparar y realizar reuniones con expertos", responsabilidad del DP, incluye toda la comunicación externa del proyecto durante la fase de ejecución. A continuación se incluye un acta rellenada como acta de la reunión que sirvió de ejemplo anterior. ACTA DE REUNIÓN CON STAKEHOLDERS Fecha 16/05/2013 Hora de inicio y finalización 18:00-19:00 Lugar Sede de la empresa desarrolladora del MEMORIAS 2 Participantes de la org. DP (xxx) como portavoz, RDE (xxx) y RDI (xxx) como asesores (rol/nombre) Objetivo final de la propia org. Exponer el proyecto, obtener experiencia Participantes de la/s otra/s parte/s (rol/nombre) Objetivo de la/s otra/s parte/s Resultado\nDirector gerente y un asesor La otra parte ha sido colaborativa, ha resuelto nuestras dudas seguramente con el objetivo de establecer lazos y buenas relaciones. Se han alcanzado los objetivos, hemos recopilado información acerca de posibles riesgos del proyecto así como el modo de detectarlos y mitigarlos y una lista de requisitos de proyectos de edificación que será de ayuda para acometer con mayor facilidad la tarea 21.\nPGCPE DOC.26, página 59 de 77\nADQUISICIÓN DEL EQUIPO versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por Se contrata a los especialistas (EE, EI, EP, EC y ECTE) con contrato tipo CR, de costos reembolsables con incentivos. Se decide este tipo de contrato dado que la dificultad para realizar los diagramas de flujo no puede ser definida con exactitud y los incentivos contribuyen a la motivación. CONTRATO Localización y fecha: En _________ a día __/__/____ Partes intervinientes (comprador y adquisición): Director de proyecto con nombre ____ ,domicilio ____ y datos fiscales _____ y Especialista en Código Técnico, en adelante ECTE con nombre _____ , domicilio _____ y datos fiscales _____. Declaración de capacidad jurídica: Cada uno de los reunidos, posee la capacidad jurídica y de obrar necesaria y suficiente en derecho para contratar y obligarse en la representación que ostenta, y en especial para formalizar el presente contrato. Alcance del contrato: Colaboración en el proyecto PGCPE participando en las actividades definidas en el DOC.12 “hoja de actividades” (adjunto documento). El objetivo final es la creación de un diagrama de flujo que comprenda todos los entregables, procesos y roles incluídos en un proyecto de edificación. Para ello el ECTE ha de Recopilar requisitos, definir dependencias entre ellos y asociarlos a procesos analizando los documentos III (pliego de condiciones), IV (mediciones), V (presupuesto) y VI (proyectos parciales y otros documentos técnicos complementarios) así como los diagramas de flujo parciales elaborados por los otros profesionales participantes en el proyecto. Por útilmo asesorará a los demás profesionales en cada una de sus especialidades. Plazo y lugar de realización del proyecto: El proyecto comenzará el 12/04/2013 y finalizará el 23/05/2014. Las actividades en las cuales participa el ECTE tienen previsto su inicio el 20/05/2014 y finaliza el 16/04/2014. Salario: 15,00 €/h y 20,00 €/h extra. Forma de pago: Por transferencia bancaria mensualmente. Errores en el diagrama de flujo: Será el ECTE el responsable de los errores de dependencia entre requisitos existentes en el diagrama de flujo. Errores en el diagrama de flujo: Será el ECTE el responsable de los errores de dependencia entre requisitos existentes en el diagrama de flujo. Obligaciones laborales, sociales y tributarias del subcontratista: Toda la documentación debe estar en regla y presentarse si se solicita. Cese del Proyecto: Si se produce el cese del proyecto se suspenderá la ejecución del contrato. Domicilio a efectos de notificaciones: El designado en el punto 1. Firma y aprobación de las partes:\nPGCPE DOC.27, página 60 de 77\nEVALUACIÓN DEL DESEMPEÑO DEL EQUIPO versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por El documento "Evaluación del desempeño del equipo" es salida tanto del desarrollo como de la dirección del equipo, responsabilidades del DP. El desarrollo del equipo tendrá varias fases, en la primera se fomentará la participación en reuniones informativas con stakeholders para que los miembros del equipo se familiaricen tanto con el proyecto así como con el sector al cual pertenece el proyecto. Dichas reuniones servirán también para que el equipo se conozca mejor entre sí. Posteriormente, durante las actividades del grupo de procesos de ejecución el DP realizará inspecciones periódicas para evaluar el grado de desarrollo del equipo, dichas inspecciones se realizarán durante las reuniones matutinas diarias definidas en el plan de gestión de comunicaciones y darán lugar a los documentos "Evaluaciones del desempeño del equipo". El espacio de trabajo comprenderá una misma oficina con dos mesas, una empleada por el equipo de diseño y otra por el equipo de desarrollo. La dirección del equipo consistirá en monitorear el desempeño de los miembros del equipo, proporcionar retroalimentación, resolver problemas y gestionar cambios a fin de optimizar el desempeño del proyecto. DP observa el comportamiento del equipo, gestiona los conflictos, resuelve los problemas y evalúa el desempeño de los miembros del equipo. Como consecuencia de dirigir el equipo del proyecto, se envían solicitudes de cambio, se actualiza el plan de recursos humanos, se resuelven los problemas, se suministran datos de entrada para las evaluaciones del desempeño y se añaden lecciones aprendidas a la base de datos de la organización. EVALUACIÓN DEL DESEMPEÑO DEL EQUIPO Entregable Nº actividad responsable estado del entregable asociada /s Recopilación de Act. 21 "Recopilar EE, EP, EC y Se han definido correctamente los requisitos, agrupados y jerarquizados según la nomenclatura requisitos de un y procesos de un EI dada en el Manual de Calidad del Proyecto Arquitectónico. Ha sido necesario incluir entregables proyecto de proyecto de que si bien no estaban recogidos en el Código Técnico son indispensables para la redacción de edificación edificación" un proyecto, la mayoría de estos entregables hacen referencia al apartado de diseño inicial del edificio. CRONOGRAMA tiempo estimado\n14/06/2013 22 días\nPGCPE DOC.28, página 61 de 77\nMONITORIZACIÓN Y CONTROL DEL TRABAJO DEL PROYECTO versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por La monitorización y control del trabajo del proyecto, actividad 34, es responsabilidad del DP. Consiste en monitorear, analizar y regular el avance a fin de cumplir con los objetivos de desempeño definidos en el plan para la dirección del proyecto. El DP realizará esta actividad diariamente mediante la comparativa de la evolución del proyecto real respecto de su línea base, la evaluación del desempeño tanto del programado como del resultado de los cambios efectuados y mediante la identificación de riesgos. Sus documentos entregables son las solicitudes de cambio, actualizaciones al plan para la dirección del proyecto así como actualizaciones de otros procesos. No existe documento estandarizado asociado a esta actividad.\nPGCPE DOC.29, página 62 de 77\nACEPTACIÓN O DENEGACIÓN DE SOLICITUD DE CAMBIO versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por La aceptación o denegación de solicitud de cambios es el documento resultado de la actividad "Realizar control integrado de cambios", actividad 35, que es responsabilidad del DP. Consiste en revisar todas las solicitudes de cambios, aprobar los mismos y gestionar los cambios a los entregables, a los activos de los procesos de la organización, a los documentos del proyecto y al plan para la dirección del proyecto. A continuación se incluye un documento de aceptación relleno como ejemplo con la hipotética respuesta de aceptación a la solicitud de cambio del documento 24: ACEPTACIÓN O DENEGACIÓN DE SOLICITUD DE CAMBIO cambio Incluír entre los requisitos de un proyecto de edificación los requisitos relacionados con elaboración de un diagrama funcional del solicitado programa del edificio. Se acepta X Se deniega IMPACTO SOBRE EL PROYECTO coste No se contempla aumentar el presupuesto dado que el el desempeño del trabajo avanza más rápido de lo esperado tiempo No se contempla aumentar el cronograma dado que el el desempeño del trabajo avanza más rápido de lo esperado alcance Aumenta. Es necesario modificar el texto del alcance del proyecto. calidad Aumenta. Es necesario incluirla en la descripción del producto en la plataforma online dado que será un aspecto que satisfará a gran cantidad de profesionales. IMPACTO DE LA ACEPTACIÓN O DENEGACIÓN DE CAMBIO Se considera que la posibilidad de incluir dichos requisitos aunque suponga un aumento consumo de recursos tanto humanos como de coste y tiempo, se trata de un paso no recogido en el CTE pero que gran cantidad de profesionales realizan, la relación entre el esfuerzo invertido y la satisfacción que provocará en un porcentaje enorme de usuarios es asumible.\nPGCPE DOC.30, página 63 de 77\nVERIFICACIÓN Y CONTROL DEL ALCANCE versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por La verificación y control del alcance es responsabilidad del DP y consiste la formalización de la aceptación de los entregables del proyecto que se han completado y la monitorización del estado del alcance del proyecto y del producto. Consecuentemente, el principal cometido de esta actividad es evitar que el proyecto se desvíe del alcance definido originalmente pero también, si se desvía, estudiar qué nuevas posibilidades en cuanto a alcance se dan según avanza el proyecto. Adjunto a continuación el alcance inicial del proyecto, sobre el cual el DP, trabajaría modificándolo y mejorándolo, a lo largo del proyecto: ENUNCIADO DEL ALCANCE Diseño de una aplicación informática que permite incluir todos los entregables que posee un proyecto de edificación (tomando como referencia el Código Técnico de la Edificación) y vincularlos con los procesos llevados a cabo comúnmente en la elaboración de un proyecto. A su vez estos procesos pueden asignarse a uno o varios responsables. Todo ello constituye un diagrama de flujo que describe un proyecto de edificación tipo y que facilita la coordinación entre distintos agentes en la elaboración del proyecto.\nPGCPE DOC.31, página 64 de 77\nCONTROLAR EL CRONOGRAMA Y EL PRESUPUESTO versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por El control del cronograma y del presupuesto se realizará por parte del DP mediante el MS Project, estableciendo una línea base y efectuando los cambios necesarios sobre ésta tanto cronológicos como de prespuesto. INFORME DE RESUMEN DE PROYECTO\nFECHAS Comienzo Comienzo previsto Comienzo Real Variación del comienzo DURACIÓN Programada Prevista Variación TRABAJO Programado Previsto Variación COSTOS Programados Previstos Variación ESTADO DE LAS TAREAS Tareas aún no comenzadas Tareas en curso Tareas finalizadas Total de tareas\njue 18/04/13 jue 18/04/13 jue 18/04/13 0\nFin Fin previsto Fin real Variación de fin\nlun 07/04/14 lun 07/04/14 NOD 0\n1882 horas 1892 horas 0\nRestante Real Porcentaje completado\n1574 horas 317 horas 17%\n11.648 horas 11.648 horas 0\n9.166 horas 2.481 horas 21%\n201.426 € Restantes 203.531 € Reales 2.105 € ESTADO DE LOS RECURSOS Recursos de trabajo Recursos de trabajo sobreasignados Recursos materiales Total de recursos\n158.108 € 43.317 €\n5 0 0 5 PGCPE DOC.32, página 65 de 77\nHOJA DE RECOGIDA DE DATOS DE CONTROL DE CALIDAD versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por La "Hoja de recogida de datos de control de calidad" es un documento salida de la actividad "Realizar el control y aseguramiento de la calidad". A continuación se muestra un documento rellenado con un ejemplo de medición que consiste en comprobar que en el entregable "Recopilación de requisitos de un proyecto de edificación" no hay duplicidad de requisitos, es decir que un mismo requisito no tenga asociado dos códigos y por lo tanto, la aplicación, entienda que son dos requisitos distintos. Esta exigencia viene recogida en el Plan de Calidad del proyecto (DOC.16) en el apartado métricas de calidad del diseño y desarrollo de la aplicación en el cual se indica que "Se recopilarán todos los entregables, relaciones de dependencia entre entregables, procesos y roles de un proyecto de edificación. Deberá incluirse una nomenclatura que acompañe y clasifique todos los elementos".\nHOJA DE RECOGIDA DE DATOS DE CONTROL DE CALIDAD Responsable de la medición DP Fecha de la medición 31/05/2013 Proceso o entregable analizado Entregable parcial "Recopilación de requisitos de un proyecto de edificación, apartado DB SI" Responsable de dicho proceso o EP entregable analizado Métricas empleadas Métricas de calidad del diseño y desarrollo de la aplicación Medición Se comprueba, mediante búsqueda con asistencia informática (comando buscar y seleccionar) que no hay duplicidad de requisitos y que cada uno posee un código asociado. Resultado Se han documentado 2 duplicidades, tanto en DB SI 1 como en DB SI 2 existe la entrada "cuadro de usos y superficies estimadas" con un código distinto en cada una. Esta entrada posiblemente también aparezca en los diagramas realizados por el resto de los miembros del equipo Proceso o entregable válido Proceso o entregable no válido X\nPGCPE DOC.33, página 66 de 77\nANÁLISIS DE DATOS RECOGIDOS Responsable análisis Fecha de la acción correctiva Resultado analizado\nResponsable acción correctiva Fecha de la acción correctiva Acción correctiva\nDP 31/05/2013 Se han documentado 2 duplicidades, tanto en DB SI 1 como en DB SI 2 existe la entrada "cuadro de usos y superficies estimadas" con un código distinto en cada una. Esta entrada posiblemente también aparezca en los diagramas realizados por el resto de los miembros del equipo DP 03/06/2013 Se informará al responsable del error y éste será el responsable de corregirlo. Si el error es también cometido por el resto de miembros del equipo en más del 5% de los requisitos incluídos en dichas listas se procederá a hacer un análisis de diagrama de causa efecto para buscar el origen del problema y estudiar acciones correctivas para cambiar el método aplicado en la actividad "Recopilación de requisitos de un proyecto de edificación".\nPGCPE DOC.33, página 67 de 77\nINFORME DEL DESEMPEÑO versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por El documento "informe del desempeño" se realiza durante la actividad "informar del desempeño", responsabilidad del DP. En ellos se recoge toda la información generada en otros documentos de seguimiento y control para realizar un evaluación y un compendio de éstos. Dependiendo del receptor de dichos informes, éstos serán más complejos o menos, incluirán o no cierta información y poseerá un código de lenguaje distinto. A continuación incluyo dos informes a modo de ejemplo sobre unaetapa del proyecto, el destinatario de uno de los informes es un miembro del equipo, el RDE, y del otro es un grupo de inversión. INFORME DEL DESEMPEÑO Responsable de difusión Fecha Informe\nDP 31/05/2013 La "Recopilación de requisitos de un proyecto de edificación" avanza aceptablemente, se ha realizado un 51% de la actividad, con un desvío tanto en el cronograma como en el coste de un 5%. El equipo trabaja individualmente en la recopilación de los requisitos que denominamos "internos", es decir los que aparecen solo en una parte del CTE y no influyen en otras, sin embargo este tipo de requisitos son más escasos de lo que esperábamos de modo que en un 50% del tiempo los espertos deben acordar entre sí la nomenclatura de los requisitos que afectan a más de un responsable, por ejemplo, la existencia o no de locales de riesgo especial en el documento básico seguridad de incendio también afecta a los apartados tratados en el documento básico de ahorro de energía puesto que la instalación de una caldera de gas o de biomasa supone una variación en la clasificación del riesgo del RDElocal. Correo interno\nPGCPE DOC.34, página 68 de 77\nINFORME DEL DESEMPEÑO Responsable de difusión Fecha Informe\nDP 31/05/2013 La "Recopilación de requisitos de un proyecto de edificación" avanza satisfactoriamente habiéndose recopilado más de 3000 de un total de 6000 habiendo invertido el tiempo y los recursos estimados con una desviación de solo el 5%. Esta actividad que estamos desarrollando es muy importante pues consiste en recopilar y organizar todos los puntos tratados en el código técnico, para posteriormente comenzar a trabajar con ellos buscando las relaciones existentes entre ellos. Los responsables de esta actividad son profesionales del sector de la edificación con amplia experiencia en el Código Técnico de la Edificación, uno de ellos incluso colaboró estrechamente en la redacción de este mismo. Estamos satisfechos con el rendimiento obtenido y confiamos en seguir así. Grupo de inversión X Este mensaje se transmitirá personalmente en la reunión con fecha 07/06/2013\nPGCPE DOC.34, página 69 de 77\nMONITORIZACIÓN Y CONTROL DE RIESGOS versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por La monitorización y control de riesgos es un documento responsabilidad del DP con diferentes objetivos, desde la implementación de planes de respuesta a los riesgos, el rastro de riesgos identificados, monitorización de los riesgos residuales,identificación de nuevos riesgos y evaluación de la efectividad del proceso contra los riesgos. Se trabaja, entre otros, con el Plan de gestión de riesgos y con el documento "Identificación de riesgos, análisis cualitativo y cuantativo". A continuación incluyo un documento tipo con un ejemplo: MONITORIZACIÓN Y CONTROL DE RIESGOS Responsable de monitorización DP Fecha Riesgo Importancia Informe\nResponsable de control Fecha Acción correctiva\n24/10/2013 Problemas comunicación media Al tratarse de un proyecto compuesto por un equipo heterogéneo formado por profesionales de edificación y profesionales de ingeniería informática, los problemas de comunicación están suponiendo un problema a la hora de transmitir el trabajo realizado por los primeros durante la fase de diseño a los segundos para que éstos procedan al desarrollo de la aplicación. DP 25/10/2013 Dado que los problemas de comunicación están siendo mayores de lo esperado, se procederá a invertir el presupuesto de contingencia en 7 clases formativas de duración 1 hora de 9:00 a 10:00 durante los próximos 7 días. Habrá dos clases, una impartida por el RDE al grupo de diseño y otra impoartida por el RDI al grupo de desarrollo. En las primeras se impartirá al grupo de diseño leyes lógicas necesarias para elaborar diagramas de flujo y en la segundas una visión superficial de la estructura que compone el Código Técnico de la edificación. A mayores en ambas clases se impartirá una definición de términos empleados por ambos grupos de profesionales.\nPGCPE DOC.35, página 70 de 77\nDOCUMENTACIÓN DE LAS ADQUISICIONES versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por La documentación de las adquisiciones es salida de la actividad administrar las adquisiciones, responsabilidad del DP, en dicha documentación se incluyen aspectos que completan los definidos en el contrato. Se muestra a continuación un documento hipotéticamente rellenado al final del grupo de procesos de ejecución (véase que ya se ha evaluado a la persona contratada). DOCUMENTACIÓN DE LAS ADQUISICIONES Adquisición ECTE (especialista en código técnico) Desempeño de la adquisición Recopilar requisitos de un proyecto de edificación Definir dependencias entre requisitos Recopilar procesos de un proyecto de edificación Recopilar roles y responsabilidades Elaborar la lógica interna que rige el software Definir las funcionalidades de la aplicación Elaborar lecciones aprendidas Informe de desempeño Se ha realizado el trabajo eficazmente, merece especial mención su actitud en la actividad elaborar lecciones aprendidas. En la cual aportó gran cantidad de observaciones que podrán servir de utilidad en futuros proyectos. Evaluación de la adquisición (0-10) Facturas Cambios de contrato aprobados\n10 Ver documentos adjuntos Durante el contrato, al darse variaciones en el cronograma, se realizó un cambio de contrato prolongando la vigencia del mismo. Se adjunta dicho documento.\nPGCPE DOC.36, página 71 de 77\nFIN DE CONTRATO versión ( 1 ) Redactado por Revisado por Aprobado por\nEl documento de fin de contrato es salida de la actividad cierre de adquisiciones, responsabilidad del DP, este documento debe entregarse personalmente. Nota: En el caso de rescisión de contrato, el DP deberá entregarlo personalmente al receptor al menos 30 días de la fecha efectiva de extinción. A continución se incluye un modelo de fin de contrato completado. FIN DE CONTRATO Emisor Receptor Motivo Fecha efectiva de extinción Informe\nDP ECTE Trabajo completado 25/10/2013 Su colaboración en este proyecto ha sido muy valiosa y el hecho de haber trabajado junto a usted gratificante, espero que su experiencia también haya sido positiva. Quiero que sepa siempre tendrá una puerta abierta en esta casa sea para colaborar en futuros proyectos o por cualquier otra razón. Atentamente, xxx.\nPGCPE DOC.37, página 72 de 77\nLECCIONES APRENDIDAS versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por Las lecciones aprendidas es un documento desarrollado en la actividad elaborar lecciones aprendidas, consistente en una reunión de todos los miembros del equipo en la cual se enunciará una orden del día con los puntos a tratar. Se solicitará a los miembros que rellenen un formulario sobre las áreas de conocimiento (integración, alcance, tiempo, costes, calidad, personal, comunicación, riesgos, adquisiciones). En dicho formulario se realizarán preguntas directas sobre aspectos relevantes pero también se dará la posibilidad a los participantes de incluir otras apreciaciones. Posteriormente pondrán en común estos temas con el objetivo de hallar las lecciones de mayor importancia. Una vez finalizada la reunión, el DP recopilará la información para realizar un informe con una serie de conclusiones. LECCIONES APRENDIDAS Fecha Hora de inicio y finalización Lugar Moderador Participantes (rol/nombre) Orden del día:\nMaterial (documentos) Material (herramientas) Obtención de conclusiones\n17/03/2014 09:00-13:00 Oficina DP Todos los miembros del equipo de proyecto Inicio de la reunión Entrega del formulario con los apartados integración, alcance, tiempo, costes, calidad, personal, comunicación, riesgos y adquisiciones. Tiempo para rellenar el formulario Puesta en común Fin de la reunión Presentación PPT, todos los documentos del proyecto, formularios proyector\nPGCPE DOC.38, página 73 de 77\nACTA DE CIERRE DE PROYECTO versión ( 1 ) Rol / Nombre / Firma / Fecha Redactado por Revisado por Aprobado por ACTA DE CIERRE DE PROYECTO Título proyecto Diseño y desarrollo de una plataforma para la gestión colaborativa de proyectos de edificación Partes acordantes (Rol, nombre) Director Gerente xxx Director de proyecto xxx Objetivos alcanzados Se han alcanzado todos los objetivos planteados en los requisitos iniciales: Se ha completado el diseño y desarrollo de la aplicación PGCPE y se ha realizado la transión del producto final (la aplicación se encuentra en estado operativo en la plataforma online). Toda la documentación impresa ha sido archivada en los archivadores con nombre “PGCP1, 2, 3, n.” y en la documentación digital en la carpeta C:/PROYECTOS/PGCP/. Acuerdo entre partes acordantes (Rol, nombre, firma y fecha) Director Gerente xxx Director de proyecto xxx\nPGCPE DOC.39, página 74 de 77\nEJEMPLO DE FRAGMENTO DE DIAGRAMA DE FLUJO DE LA APLICACIÓN La imagen inferior es un fragmento que he realizado del que sería el diagrama de flujo que vincularía todos los entregables de un proyecto de edificación. El ejemplo muestra las relaciones de dependencia de los entregables relacionados con el cumplimiento de CTE DB-SI 1 con sus entregables previos. Los colores indican la pertenencia de los entregables a distitas áreas de conocimiento (magenta = protección contra incendios, azul = proyecto, verde = diseño de instalaciones, azul = seguridad de utilización). El diagrama completo estaría formado por unos 6000 entregables que constituyen todos los puntos del CTE así como otros no recogidos en la normativa.\nPGCPE ANEXO.01, página 75 de 77\nCONCLUSIONES La elaboración del presente trabajo fin de máster me ha otorgado la posibilidad de enfrentarme a la totalidad de un proyecto. En el momento en el cual mis tutores me propusieron elaborar una aplicación que permitiera el trabajo en grupo en la elaboración de proyectos de edificación, ilusionado, les dije que creía conveniente centrarme en los procesos realizados durante la fase de diseño pues creo que la elaboración de proyectos de edificación actualmente está poco sistematizada y estandarizada. Mi formación y mi trabajo como arquitecto tanto en la administración pública como en la privada me ha brindado la posibilidad de conocer de cerca el escaso rigor y orden con el cual se acomete el diseño de proyectos. Los proyectistas se escudan bajo la premisa de que establecer un método empobrece la diversidad arquitectónica y mina la creatividad, no solo la artística sino también la técnica ejemplificada en la creación de programas funcionales, soluciones constructivas o plantemamientos urbanos. Sin embargo, el haber conocido la "dirección integrada de proyectos" me ha ayudado a sistematizar en cierta medida el método creativo sin necesidad de crear una metodología y gracias a ello he podido plantear este proyecto. La elaboración de este trabajo me ha permitido aunar tres áreas de conocimiento: la informática, la edificación y la dirección integrada de proyectos. El haber abarcado estas tres áreas para enfrentarme a este proyecto ha sido muy didáctico. Considero que si bien la redacción de los procesos incluídos en el proyecto es una parte importante de este trabajo, también lo es en gran medida la idea que pretendo desarrollar en dicho proyecto. La organización de los entregables y los procesos integrantes en un proyecto de edificación es muy compleja debido a que el proyecto posee forma física y la elección de una forma u otra supone la variación de los entregables en gran medida, por ello los proyectos de edificación, al igual que los informáticos, deben ser planificados iterativamente. De ahí la idea de crear un gran diagrama de flujo que pueda ser modificado por el usuario fácilmente, gracias a la informática, tanto al inicio como durante el ciclo de vida del proyecto. A fin de cuentas la exigencia de llevar a cabo el proyecto para saber cómo gestionarlo es el mayor problema con el que nos encontramos en muchos de estos trabajos fin de máster, en los cuales, al no llegar a realizar el proyecto debemos imaginar el avance del mismo para así trabajar con todos los grupos de procesos. La estructura de mi trabajo intenta solventar ese problema mediante la organización de éste en los sucesivos documentos empleados en cada uno de los procesos y en su rellenado con datos del proyecto, a veces datos reales, otras veces con datos hipotéticos elaborados a partir de situaciones que posiblemente se den en un proyecto (solicitudes de cambio, detección de riesgos, etc.). Creo que la calidad del trabajo de este modo es mayor pues no me limito a relatar el modo procedimiento a realizar en cada proceso. He intentado sacar el mayor provecho posible a mi aprendizaje de la dirección integrada de proyectos y, tal y como manifiesta la temática de mi trabajo fin de máster, lo que más deseo es aplicarlo en lo que de verdad más me apasiona, la arquitectura. PGCPE CONCL, página 76 de 77\nBIBLIOGRAFÍA Y WEBGRAFÍA Project Management Institute. (2008). Guía de los fundamentos de la Dirección de Proyectos (Guía del PMBOK). Cuarta Edición. Pennsylvania: PMI. García Fronti, V. (2009). Project Management con Visio y Project. Buenos Aires. Elaine J, Marmel. (2009). Gestión de Proyectos con Microsoft Project 2007. Madrid: Anaya. Gutiérrez de Mesa, J. A. Planificación y gestión de proyectos informáticos (2ª ED. Universidad de Alcalá de Henares. 2008. Rem Koolhaas, Stefano Boeri, Sanford Kwinter, Nadia Tazi, Hans-Ulrich Obrist. Mutations, ACTAR D. 2000 Neufert, Ernst. El arte de proyectar arquitectura. Ed G.G. 2009. Kahn, Louis. Monumentalidad (1944) Wrigting, Lectures, Interviews. Rizzoli, 1991. http://www.pmi.org (Project Management Institute) http://www.aedip.org (Asociación Española de Dirección Integrada Proyecto)\nPGCPE BIBLIO, página 77 de 77\nArchitectural Project Management App\nProject management guide of a team of architects and computer engineers who would develop a software manage architectural projects.