Administracion de proyectos
•Descargar como PPTX, PDF•
2 recomendaciones•1,155 vistas
Administracion de proyectos
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (16)
Similar a Administracion de proyectos
Similar a Administracion de proyectos (20)
Más de Tensor
Más de Tensor (20)
Último
Último (20)
Administracion de proyectos
- 1. CMMI y PMI en la Gestión de Requerimientos
- 2. Administración de Proyectos La administración de proyectos es una disciplina encaminada a satisfacer los requerimientos definidos en un alcance dentro del tiempo y costo acordados. A través de A Guide to the Project Management Body of Knowledge (PMBOK Guide), PMI define un estándar internacional para la Administración de Proyectos.
- 3. PMBOK • Estándar definido por el Project Management Institute (PMI) • Es una guía que describe fundamentos y prácticas de Administración de Proyectos. • Su estructura se basa en • Áreas de Conocimiento • Procesos • Entradas • Herramientas y Técnicas • Salidas
- 4. PMBOK – Componentes ADMINISTRACIÓN DE PROYECTOS Área de Conocimiento Área de Conocimiento Área de Conocimiento Entradas Herramientas y Técnicas Salidas
- 5. PMBOK – Clasificación de Procesos • Identifica 44 procesos clasificados por Área de Conocimiento Grupo • Gestión de la Integración • Gestión del Alcance • Gestión del Tiempo • Gestión de los Costos • Gestión de la Calidad • Gestión de los Recursos Humanos • Gestión de las Comunicaciones • Gestión de los Riesgos • Gestión de las Adquisiciones • Iniciación • Planificación • Ejecución • Seguimiento y Control • Cierre
- 6. Administración de Proyectos de TI Los proyectos de Tecnología de Información son diferentes ¿Por qué? “Los productos de software tienen cuatro propiedades inherentes: • Invisibilidad • Complejidad • Flexibilidad • Conformidad” Fred Brooks. No silver bullet: essence and accidents of software engineering
- 7. Administración de Proyectos de TI Actualmente existen varios enfoques estándares para la administración de proyectos de TI, entre ellos: • RUP (Rational Unified Process) • XP (eXtreme Programing) • CMMI (Capability Maturity Model Integration)
- 8. CMMI • Estándar definido por el Software Engineer Institute (SEI), puede ser • Escalonado • Continuo • Es un modelo que describe características de procesos efectivos. • Su estructura se basa en • Áreas de Proceso • Objetivos • Prácticas • Artefactos
- 9. CMMI - Componentes del modelo escalonado Nivel de Madurez Área de Proceso 1 Área de Proceso 2 Área de Proceso n Prácticas Genéricas Prácticas Específicas Objetivos Genéricos Objetivos Específicos
- 10. CMMI Escalonado - Niveles
- 11. CMMI – Niveles y disciplinas • Identifica 22 Áreas de Proceso clasificadas por Nivel y disciplina • Administración de Requerimientos (REQM) IngenieríaGestión de Procesos • Administración Integrada de Proyectos (IPPD) • Monitoreo y Control del Proyecto (PMC) • Planeación de Proyecto (PP) • Administración de Proveedores (SAM) Gestión de Proyectos • Administración de la Configuración (CM) • Medición y Análisis (MA) • Process and Product Quality Assurance (PPQA) Apoyo Nivel 2. Administrado
- 12. • Análisis de Decisión y Resolución (DAR) • Integración del Producto (PI) • Solución Técnica (TS) • Validación (VAL) • Verificación (VER) • Desarrollo de Requerimientos (RD) • Administración de Riesgo (RSKM) • Definición Oganizacional del Proceso (+IPPD) • Enfoque Organizacional del Proceso (OPF) • Entrenamiento Organizacional (OT) IngenieríaGestión de Procesos Gestión de Proyectos Apoyo Nivel 3. Definido CMMI – Niveles y disciplinas
- 13. Gestión de Procesos Gestión de Proyectos Ingeniería Apoyo • Desempeño Organizacional del Proceso (OPP) • Administración Cuantitativa de Proyecto (QPM) Gestión de Procesos Gestión de Proyectos Ingeniería Apoyo • Innovación y Mejora Organizacional (OID) • Resolución y Análisis Causal (CAR) Nivel 4. Administrado cuantitativamente Nivel 5. Optimizado CMMI – Niveles y disciplinas
- 14. PMBOK vs. CMMI Diferencias • Enfoque • Tipos de proyecto • Organizaciones • Intención • Estructura • Áreas de Conocimiento vs. Áreas de Proceso • Cobertura y/o definición de algunos procesos
- 15. PMBOK vs. CMMI Similitudes • Orientación • Procesos cubiertos • Planeación de Proyectos • Monitoreo y control de proyectos • Aseguramiento de Calidad • Administración de Riesgos • Administración de Requerimientos
- 17. Problemática en proyectos de TI Síntomas comunes en un proyecto: • Entregables sujetos a interpretación • Criterios de aceptación vagos • Cambios constantes de requerimientos • Re-trabajo en entregables. • Caos en el equipo de trabajo Al final… • Confusión y frustración del cliente. • Incrementos no planeados de TIEMPO y CO$TO
- 18. Definición de Gestión de Requerimientos En TI: • ¿Qué es un requerimiento? • Funcional • No funcional • No técnico • ¿Qué es la Gestión de Requerimientos? • ¿Por qué se administran?
- 19. Gestión de Requerimientos – PMBOK Áreas de Conocimiento de PMBOK: 4. Gestión de Integración del Proyecto • Desarrollar el Enunciado del Alcance del Proyecto (Preliminar) • Control Integrado de Cambios 5. Gestión del Alcance del Proyecto • Planificación del Alcance • Definición del Alcance • Control del Alcance
- 20. Gestión de Requerimientos – CMMI Áreas de Proceso de CMMI: RD – Desarrollo de Requerimientos • SG1: Desarrollar Requerimientos del Cliente • SG2: Desarrollar Requerimientos del Producto • SG3: Analizar y Validar Requerimientos REQM – Administración de Requerimientos • SG1: Administrar requerimientos e identificar sus inconsistencias con los productos de trabajo y los planes del proyecto.
- 21. Gestión de Requerimientos CMMI y PMBOK Se cuenta con: • Proyecto aprobado • Gente experta (Stakeholders o Juicio experto) • Metodología definida para la ejecución de procesos • Gestión de cambios • Administración del alcance
- 22. Gestión de Requerimientos CMMI y PMBOK PMBOK CMMI 4 – Gestión de la Integración del Proyecto 4.2 – Desarrollar Definición Preliminar de Alcance del Proyecto 4.2.2 – Herramientas y Técnicas 4.2.2.1 – Metodología de Administración de Proyectos REQM – Administración de Requerimientos SG 1. Administrar Requerimientos SP 1.1. Obtener un entendimiento de los requerimientos 5 – Gestión del Alcance del Proyecto 5.1 – Planificación del Alcance del Proyecto RD – Desarrollo de Requerimientos SG 1 – Desarrollar requerimientos del cliente SP 1.1 – Obtener necesidades SP 1.2 – Desarrollara requerimientos del cliente SG2 – Desarrollar requerimientos del producto SP 2.1 – Establecer requerimientos del producto y componentes del producto SP 2.2. – Asignar requerimientos de componentes del producto SP 2.3 – Identificar requerimientos de interfaces
- 23. Gestión de Requerimientos CMMI y PMBOK PMBOK CMMI 5 – Gestión del Alcance del Proyecto 5.2 – Definición del Alcance 5.2.2 – Técnicas y Herramientas 5.2.2.1 – Análisis del Producto RD – Desarrollo de Requerimientos SG 1 – Desarrollar requerimientos del cliente SP 1.1 – Obtener necesidades SP 1.2 – Desarrollar requerimientos del cliente SG 2 – Desarrollar requerimientos del producto SP 2.1 – Establecer requerimientos del producto y componentes del producto SP 2.2. – Asignar requerimientos de componentes del producto SP 2.3 – Identificar requerimientos de interfaces SG 3 – Analizar y validar requerimientos SP 3.3 – Analizar requerimientos SP 3.4 – Analizar requerimientos para lograr equilibrio
- 24. Gestión de Requerimientos CMMI y PMBOK PMBOK CMMI 5 – Gestión del Alcance del Proyecto 5.5 – Control del Alcance 5.5.2 – Herramientas y Técnicas 5.5.2.1 – Sistema de Control de Cambios 5.5.2.3 – Re-planificación REQM – Administración de Requerimientos SG 1 – Administrar requerimientos SP 1.3 – Administrar cambios en los requerimientos Adicionalmente, CMMI contempla la Rastreabilidad bidireccional de Requerimientos. • Describir y seguir la vida de un requerimiento • Definir, capturar y seguir la dependencia con otros elementos y/o requerimientos
- 25. Conclusiones En conclusión, en la Gestión de Requerimientos: • Ambos estándares contemplan la gestión de requerimientos • CMMI ofrece una perspectiva de ingeniería de los requerimientos • Obtención • Desarrollo • Rastreabilidad • Administración de Interfaces
- 26. Referencias Libros • A Guide to the Project Management Body of Knowledge, Third Edition (PMBOK Guide). Project Management Institute • CMMI for Development, Version 1.2. Carnegie Mellon Software Engineering Institute • Software Project Management, Second Edition. Hughes, Bob. En la red • CMMI Transition Aids. • https://bscw.sei.cmu.edu/pub/bscw.cgi/0/79783. • Managing Requirements • http://www.jiludwig.com/
Notas del editor
- Palabras más, palabras menos, la administración de proyectos se ha concebido para planear, ejecutar y controlar proyectos cuidando las 3 variables principales: alcance, costo y tiempo. Más adelante se describirá en qué consiste el PMBOK.
- Frederick Phillips Brooks, Jr. (nacido el 19 de abril de 1931) es un ingeniero de software y científico de la computación, más conocido por dirigir el desarrollo del sistema operativo OS/360, y después escribir honestamente sobre el proceso en su famoso libro The Mythical Man-Month (El mítico hombre-mes). "Es una experiencia humillante el cometer un error de coste multimillonario, pero es también muy memorable." Brooks recibió el Premio Turing en 1999 "por sus contribuciones a arquitectura de computadores, sistemas operativos e ingeniería del software”. Famoso por su libro El mítico hombre-mes en el cual es un libro de administración de proyectos cuyo tema central es “agregando fuerza de hombre a un proyecto retrasado lo hace demorar aún más”. Línea de tiempo: OS/360(1965-1972) -> MVS(1974-1995) -> OS/390(1995-2001) -> XSeries(2001 a la fecha). Invisibilidad. Mientras que en la construcción de un puente es evidente tanto los avances como los errores en su diseño y construcción, el software es intangible, no visualizable (en primera instancia) y su progreso no es evidente. Complejidad. El software por sí mismo es complejo desde su concepción: comunicación entre cliente y desarrolladores, diseño de la solución, codificación y pruebas. Además se debe adquirir y plasmar la lógica de negocios con su propia complejidad. Flexibilidad. El software y hardware es una tecnología cambiante; de hecho es la única tecnología que tiene avances sustanciales en muy poco tiempo. Conformidad. El software debe ajustarse para cumplir distintos criterios o distintas interfaces.
- El modelo para software (CMM-SW) establece 5 niveles de madurez para clasificar a las organizaciones, en función de qué áreas de procesos consiguen sus objetivos y se gestionan con principios de ingeniería. Es lo que se denomina un modelo escalonado, o centrado en la madurez de la organización. La visión escalonada definirá a la organización dándole en su conjunto un nivel de madurez del 1 al 5. El modelo para ingeniería de sistemas (SE-CMM) establece 6 niveles posibles de capacidad para una de las 18 áreas de proceso implicadas en la ingeniería de sistemas. No agrupa los procesos en 5 tramos para definir el nivel de madurez de la organización, sino que directamente analiza la capacidad de cada proceso por separado. Es lo que se denomina un modelo continuo. La visión continua de una organización mostrará la representación de nivel de capacidad de cada una de las áreas de proceso del modelo.
- Objetivo genérico: Los objetivos genéricos asociados a un nivel de capacidad establecen lo que una organización debe alcanzar en ese nivel de capacidad. El logro de cada uno de esos objetivos en un área de proceso significa mejorar el control en la ejecución del área de proceso Objetivo específico: Los objetivos específicos se aplican a una única área de proceso y localizan las particularidades que describen que se debe implementar para satisfacer el propósito del área de proceso. Práctica genérica: Una práctica genérica se aplica a cualquier área de proceso porque puede mejorar el funcionamiento y el control de cualquier proceso. Práctica específica: Una práctica específica es una actividad que se considera importante en la realización del objetivo especifico al cual está asociado. Las prácticas específicas describen las actividades esperadas para lograr la meta específica de un área de proceso
- Nivel 1: Inicial Los resultados de calidad obtenidos son consecuencia de las personas y de las herramientas que emplean. No de los procesos, porque o no los hay o no se emplean. Nivel 2: Repetible .Se considera un nivel 2 de madurez cuando se llevan a cabo prácticas básicas de gestión de proyectos, de gestión de requisitos, control de versiones y de los trabajos realizados por subcontratistas. Los equipos de los proyectos pueden aprovechar las prácticas realizadas para aplicarlas en nuevos proyectos. Nivel 3: Definido Los procesos comunes para desarrollo y mantenimiento del software están documentados de manera suficiente en una biblioteca accesible a los equipos de desarrollo. Las personas han recibido la formación necesaria para comprender los procesos. Nivel 4: Gestionado La organización mide la calidad del producto y del proceso de forma cuantitativa en base a métricas establecidas. La capacidad de los procesos empleados es previsible, y el sistema de medición permite detectar si las variaciones de capacidad exceden los rangos aceptables para adoptar medidas correctivas. Nivel 5: Optimizado La mejora continua de los procesos afecta a toda la organización, que cuenta con medios para identificar las debilidades y reforzar la prevención de defectos. Se analizan de forma sistemática datos relativos a la eficacia de los procesos de software para analizar el coste y el beneficio de las adaptaciones y las mejoras. Se analizan los defectos de los proyectos para determinar las causas, y su mapeado sobre los procesos.
- Enfoque: CMMI se enfoca a proyectos de ingeniería mientras que PMBOK se enfoca a cualquier tipo de proyecto. CMMI está orientado a organizaciones medianas grandes; PMBOK no reconoce tamaño de organizaciones. CMMI está pensado para entrenar a Administradores de Proyectos (PMP); CMMI apoya la mejora organizacional de procesos. Estructura: CMMI se basa en Procesos: Difieren en la definición de los procesos Verificación y Validación.
- Ambos estándares están orientados a procesos. La administración de requerimientos Ambos estándares buscan la definición de actividades, recursos y tiempos. Asimismo plantean la definición de la estrategia con la que se llevará a cabo el proyecto. Monitoreo y Control. Ambos estándares buscan dar seguimiento al avance de la ejecución del proyecto. Aseguramiento de Calidad. Ambos estándares buscan generar mecanismos para garantizar la calidad esperada del producto o servicio. Administración de Riesgos. Ambos estándares buscan identificar los riesgos así como su contención y/o contingencia. Administración de Requerimientos. Ambos estándares buscan definir el trabajo requerido en un proyecto.
- Ambos estándares están orientados a procesos. La administración de requerimientos Ambos estándares buscan la definición de actividades, recursos y tiempos. Asimismo plantean la definición de la estrategia con la que se llevará a cabo el proyecto. Monitoreo y Control. Ambos estándares buscan dar seguimiento al avance de la ejecución del proyecto. Aseguramiento de Calidad. Ambos estándares buscan generar mecanismos para garantizar la calidad esperada del producto o servicio. Administración de Riesgos. Ambos estándares buscan identificar los riesgos así como su contención y/o contingencia. Administración de Requerimientos. Ambos estándares buscan definir el trabajo requerido en un proyecto.
- Los requerimientos con documentación parcial o nula llevan caos entre los miembros del equipo de trabajo dado que no hay entendimiento común, ni puntos de referencia. Los desarrolladores (o ejecutores) generan entregables adheridos a su interpretación de lo que el usuario requiere. Al no haber requerimientos, los criterios de aceptación son vagos. Si no hay claridad en los criterios de aceptación ni un acuerdo mutuo sobre los requerimientos, los requerimientos pueden cambiar a voluntad del cliente. Estos cambios típicamente implican re-trabajar en los entregables generados en cualquier fase. se pierde la comunicación con el cliente generando confusión y frustración con cliente.
- La administración de requerimientos es un conjunto de prácticas encaminadas a establecer y mantener un entendimiento común entre el cliente y el desarrollador sobre los requerimientos funcionales y no funcionales. Requerimientos funcionales Requerimientos técnicos Requerimientos no técnicos.
- Desde el punto de vista del PMBOK, el mapeo con CMMI tiene su mayor porcentaje en estás áreas de conocimiento. El resto se hace referencia a CMMI por los entregables (outputs) que se generan en estas dos áreas principales.
- RD: Producir y analizar requerimientos del Cliente, del Producto y de componentes del producto. REQM: Administrar los requerimientos del proyecto de productos y sus componentes e identificar inconsistencias entre aquellos requerimientos y los artefactos y planes del proyecto.
- La definición preliminar del proyecto nos dice qué se tiene que lograr. Busca documentar las características y fronteras del proyecto, sus productos y/o servicios, criterios de aceptación y control. RD SG1. Las necesidades, expectativas, limitaciones e interfaces de stakeholders se han colectado y traducido a Requerimientos de cliente.
- La definición preliminar del proyecto nos dice qué se tiene que lograr. Busca documentar las características y fronteras del proyecto, sus productos y/o servicios, criterios de aceptación y control. RD SG1. Las necesidades, expectativas, limitaciones e interfaces de stakeholders se han colectado y traducido a Requerimientos de cliente.
- La definición preliminar del proyecto nos dice qué se tiene que lograr. Busca documentar las características y fronteras del proyecto, sus productos y/o servicios, criterios de aceptación y control. RD SG1. Las necesidades, expectativas, limitaciones e interfaces de stakeholders se han colectado y traducido a Requerimientos de cliente.