están relacionados con la propia gestión del proyecto, los mayormente usados en relación con el proyecto global y los elementos que tienen sus raíc...

están relacionados con la propia gestión del proyecto, los mayormente usados en relación con el proyecto global y los elementos que tienen sus raíces en la economía, cultura, historia, etc. Las competencias contextuales se agrupan en términos del rol de la gestión de proyectos en las organizaciones permanentes y de las interrelaciones de gestión de proyectos con la administración de negocios. ORGANIZACIÓN DE LA CERTIFICACIÓN IPMA En la Figura 6 se refleja un gráfico con la organización que tiene IPMA establecida para la certificación en gestión de proyectos. Capítulo 4: Metodologías y directrices de la gestión de los proyectos Metodología para la Gestión de Proyectos en las Administraciones Públicas según ISO 10.006 82 Figura 6: Organización de la certificación IPMA DESCRIPCIÓN DE LOS ELEMENTOS DE CERTIFICACIÓN IPMA (ICB3) Los elementos de competencia, IPMA los organiza en 3 grupos: técnicos, de comportamiento y contextuales. En la Tabla 7se realiza un inventario de los mismos. Técnicos De comportamiento Contextuales Partes interesadas Implicación Orientación al proyecto Dirección de la gestión del proyecto Autocontrol Orientación al programa Requerimientos y objetivos del proyecto Asertividad Orientación a la carpeta de programas Riesgo y oportunidad Relajación Implementación del proyecto, programas y carpeta de proyectos Calidad Accesibilidad Legalidad y negocio Organización del proyecto Creatividad Sistemas, productos y tecnología Consejo IPMA Control ejecutivo IPMA IPMA CVMB Validadores Red de asociaciones nacionales Red de cuerpos de certificaciones nacionales con el panel de validación y certificación IPMA Fuente: IPMA Capítulo 4: Metodologías y directrices de la gestión de los proyectos Metodología para la Gestión de Proyectos en las Administraciones Públicas según ISO 10.006 83 Técnicos De comportamiento Contextuales Trabajo en equipo Liderazgo Gestión de personal Resolución de problemas Orientación al resultado Salud, seguridad, prevención y entorno Integración Eficiencia Financiación Estructuras de proyecto Consultable Alcance y entregables Negociación Fases del proyecto y tiempos Crisis y conflictos Recursos Credibilidad Costes de financiación Apreciación de valores Aprovisionamiento y contratos Ética Cambios Informes y controles Información y documentación Comunicación Arranque y cierre Tabla 7: Elementos de competencia para la certificación IPMA 4.3.4.- Técnicas Para evaluar la competencia técnica efectiva de cada uno de los niveles de certificación IPMA, ICB define 20 elementos de competencia técnica relacionados con la gestión de los proyectos en los que hayan trabajado los profesionales, siendo valorados de 0 a 10 . La demostración de los conocimientos en cada una de las técnicas se hace mediante preguntas a los candidatos. ICB no describe las técnicas concretas que se deben conocer, sino que define los elementos de conocimiento. 4.4.- UNE 157801 4.4.1.- Introducción Esta norma UNE 157801 “Criterios Generales para la elaboración de proyectos de Sistemas de Información”, que tiene su origen en la norma UNE 157001 [UNE 157001 2002] bajo el título “Criterios generales para la elaboración de proyectos”, puede servir de pauta para que los proyectos de Sistemas de Información que se realicen por o para las entidades, tanto organismos públicos como empresas privadas, que se adhieran a la misma, puedan tener un nivel de calidad mínimo aceptable. El uso cada vez más creciente de los Sistemas de Información tanto en los organismos públicos como en las empresas privadas ha hecho ver la necesidad de la elaboración de la presente norma para establecer los criterios generales para la elaboración de proyectos informatizados, siguiendo en lo posible el modelo y normas empleadas en otras ingenierías. La norma trata de equiparar los proyectos informáticos con los proyectos de otras disciplinas y para ello la norma UNE 157801 diferencia las tres grandes etapas que propiamente corresponden a otros tantos subproyectos, cada uno de ellos con su ciclo de vida completo. La Norma pretende resaltar la dificultad de planificar y definir el proyecto de construcción del software cuando no se ha especificado lo que se va a construir, y para ello, divide el proyecto en 3 subproyectos: Subproyecto para la definición, especificación y diseño de lo que se va a construir. Subproyecto para la construcción y pruebas de lo previamente diseñado. Subproyecto para la implantación y puesta en servicio de lo previamente construido. Esta norma no pretende desarrollar ni condicionar los proyectos a ninguna metodología ni a ningún ciclo de vida que pueda emplearse en la elaboración de los mismos. Tampoco establecerá los procesos que necesiten realizarse, ni el estado del arte para el uso de estas tecnologías que, en caso de considerarse necesaria su inclusión, se hará mediante la referencia a otras normas de carácter técnico que contemplen éstos aspectos. 4.4.2.- Objetivos Esta norma tiene por objeto establecer las características generales que deben ser cubiertas en los proyectos de los Sistemas de Información a realizar, para que satisfagan los fines a los que están destinados. El sentido tradicional que se le da a proyecto implica dos partes bien diferenciadas: la elaboración del documento que especifica lo que se ha proyectado realizar y la ejecución de lo proyectado según está especificado en el documento proyecto. Por tanto en esta norma se pretende recoger la documentación que detalla la solución propuesta para el problema planteado y que es necesaria para que pueda realizarse el sistema de información objeto del proyecto definido en su alcance. 4.4.3.- Estructura Normas para consulta: Describe las Normas ISO y UNE que sirven de consulta, además de otras relacionadas como PMBOK, Eurométodo [Eurométodo 1997], Métrica v.3 y SW-CMM. Realiza un conjunto de definiciones de los términos usados. Esta Norma utiliza términos y definiciones de las Normas UNE, ISO, ISO/IEC, CEN-CNELEC, IEEE, etc., relativas a los sistemas de información. En caso de discrepancias entre las definiciones de dichas Normas y las de la presente, prevalecerán las aquí dadas. Requisitos generales de la documentación del proyecto: Describe un índice de cómo se debería documentar cada proyecto, haciendo posteriormente una exposición más detallada de los contenidos de cada apartado del índice. Considera necesario redactar una memoria como nexo de unión entre todos los documentos del proyecto y que sea vinculante para el ejecutor y el receptor. 4.4.4.- Técnicas La Norma dice que, dado lo cambiante de las técnicas utilizadas en este tipo de proyectos y la dinámica existente en las actividades de las organizaciones, debe realizarse una revisión para valorar, y en su caso hacer las oportunas modificaciones para adaptarse a las nuevas circunstancias. 5. DESCRIPCIÓN DE LAS METODOLOGÍAS DE REALIZACIÓN DE PROYECTOS INFORMÁTICOS PARA LA ADMINISTRACIÓN PÚBLICA MÁS USADAS 5.1.- SSADM 5.1.1.- Introducción SSADM (Structured Systems Analysis and Design Method) [SSADM Foundation] es una metodología de aproximación en cascada para el desarrollo de sistemas de información y que puede ser considerada como la más completa de las metodologías estructuradas, por su garantía contrastada a lo largo de los años por los desarrolladores informáticos. Es la metodología estándar de desarrollo de proyectos del gobierno del Reino Unido. SSADM fue desarrollada inicialmente por Learmonth y Burchett Management Systems (LBMS) y continuada por el Central Computing and Telecommunications Agency (CCTA) mediante la adopción de un método de desarrollo de sistemas de información para el uso en los proyectos del gobierno del Reino Unido. Se lanzó la primera versión en 1981 y en 1983 se convirtió en uso obligatorio [Hussmann 1997] para el desarrollo de todos los proyectos nuevos del gobierno del Reino Unido, y en 1988 fue promocionada como un Standard abierto. En el año 2000, CCTA renombró SSADM como “Business System Development” [Model Systems 2005]. La metodología fue reorganizada en 15 módulos y se añadieron otros 6 módulos. 5.1.2.- Objetivos SSADM se basa en 3 vistas fundamentales [Hutchings 1996]: Modelo lógico de datos: Es el proceso de identificar, modelar y documentar los requerimientos de datos de un sistema de información de negocio. El modelo lógico de datos consiste en la estructura lógica de datos (LDS) y su documentación asociada. LDS representa las entidades y relaciones. Modelo de flujo de datos: Es el proceso de identificar, modelar y documentar como fluyen los