CMMI y PMI en la Gestión de Requerimientos
•Descargar como PPT, PDF•
1 recomendación•4,354 vistas
Este documento compara los enfoques de CMMI y PMBOK para la gestión de requerimientos en proyectos de TI. Explica que ambos estándares cubren procesos como la obtención, desarrollo y administración de requerimientos, aunque CMMI ofrece una perspectiva más centrada en la ingeniería. También destaca similitudes y diferencias en cómo cada uno aborda la planificación, control y rastreabilidad de requerimientos a lo largo del ciclo de vida del proyecto.
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a CMMI y PMI en la Gestión de Requerimientos
Similar a CMMI y PMI en la Gestión de Requerimientos (20)
Último
Último (20)
CMMI y PMI en la Gestión de Requerimientos
- 1. CMMI y PMI en la Gestión de Requerimientos
- 2. Agenda • Administración de Proyectos • PMBOK • Administración de Proyectos de TI • CMMI • PMBOK vs. CMMI • Gestión de Requerimientos • Problemática en Proyectos de TI • Definición de Gestión de Requerimientos • Gestión de Requerimientos - PMBOK • Gestión de Requerimientos - CMMI • Gestión de Requerimientos - CMMI y PMBOK • Conclusiones • Preguntas y Respuestas
- 3. Administración de ProyectosAdministración de Proyectos La administración de proyectos es una disciplinaLa administración de proyectos es una disciplina encaminada a satisfacer los requerimientos definidosencaminada a satisfacer los requerimientos definidos en un alcance dentro del tiempo y costo acordados.en un alcance dentro del tiempo y costo acordados. A través deA través de A Guide to the Project Management BodyA Guide to the Project Management Body of Knowledge (PMBOK Guide)of Knowledge (PMBOK Guide),, PMI define unPMI define un estándar internacional para la Administración deestándar internacional para la Administración de Proyectos.Proyectos.
- 4. PMBOKPMBOK • Estándar definido por el Project ManagementEstándar definido por el Project Management Institute (PMI)Institute (PMI) • Es una guía que describe fundamentos y prácticasEs una guía que describe fundamentos y prácticas de Administración de Proyectos.de Administración de Proyectos. • Su estructura se basa enSu estructura se basa en • Áreas de ConocimientoÁreas de Conocimiento • ProcesosProcesos • EntradasEntradas • Herramientas y TécnicasHerramientas y Técnicas • SalidasSalidas
- 5. PMBOK – ComponentesPMBOK – Componentes ADMINISTRACIÓN DE PROYECTOS Área de Conocimiento Área de Conocimiento Área de Conocimiento Entradas Herramientas y Técnicas Salidas
- 6. PMBOK – Clasificación dePMBOK – Clasificación de ProcesosProcesos • Identifica 44 procesos clasificados porIdentifica 44 procesos clasificados por Área de ConocimientoÁrea de Conocimiento GrupoGrupo • Gestión de la IntegraciónGestión de la Integración • Gestión del AlcanceGestión del Alcance • Gestión del TiempoGestión del Tiempo • Gestión de los CostosGestión de los Costos • Gestión de la CalidadGestión de la Calidad • Gestión de los Recursos HumanosGestión de los Recursos Humanos • Gestión de las ComunicacionesGestión de las Comunicaciones • Gestión de los RiesgosGestión de los Riesgos • Gestión de las AdquisicionesGestión de las Adquisiciones • IniciaciónIniciación • PlanificaciónPlanificación • EjecuciónEjecución • Seguimiento y ControlSeguimiento y Control • CierreCierre
- 7. Administración de ProyectosAdministración de Proyectos de TIde 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
- 8. Administración de ProyectosAdministración de Proyectos de TIde TI Actualmente existen varios enfoques estándares para laActualmente existen varios enfoques estándares para la administración de proyectos de TI, entre ellos:administración de proyectos de TI, entre ellos: • RUP (RUP (RRationalational UUnifiednified PProcess)rocess) • XP (eXP (eXXtremetreme PPrograming)rograming) • CMMI (Capability Maturity Model Integration)CMMI (Capability Maturity Model Integration)
- 9. CMMICMMI • Estándar definido por el Software Engineer InstituteEstándar definido por el Software Engineer Institute (SEI), puede ser(SEI), puede ser • EscalonadoEscalonado • ContinuoContinuo • Es un modelo que describe características deEs un modelo que describe características de procesos efectivos.procesos efectivos. • Su estructura se basa enSu estructura se basa en • Áreas de ProcesoÁreas de Proceso • ObjetivosObjetivos • PrácticasPrácticas • ArtefactosArtefactos
- 10. CMMI - Componentes delCMMI - Componentes del modelo escalonadomodelo 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
- 11. CMMI Escalonado - NivelesCMMI Escalonado - Niveles
- 12. CMMI – Niveles y disciplinasCMMI – Niveles y disciplinas • Identifica 22 Áreas de Proceso clasificadas por NivelIdentifica 22 Áreas de Proceso clasificadas por Nivel y disciplinay disciplina • Administración deAdministración de RequerimientosRequerimientos (REQM)(REQM) IngenieríaIngenieríaGestión deGestión de ProcesosProcesos • AdministraciónAdministración Integrada deIntegrada de Proyectos (IPPD)Proyectos (IPPD) • Monitoreo y ControlMonitoreo y Control del Proyecto (PMC)del Proyecto (PMC) • Planeación dePlaneación de Proyecto (PP)Proyecto (PP) • Administración deAdministración de Proveedores (SAM)Proveedores (SAM) Gestión de ProyectosGestión de Proyectos • Administración deAdministración de la Configuraciónla Configuración (CM)(CM) • Medición y AnálisisMedición y Análisis (MA)(MA) • Process andProcess and Product QualityProduct Quality Assurance (PPQA)Assurance (PPQA) ApoyoApoyo Nivel 2. AdministradoNivel 2. Administrado
- 13. • Análisis deAnálisis de Decisión yDecisión y Resolución (DAR)Resolución (DAR) • Integración delIntegración del Producto (PI)Producto (PI) • Solución Técnica (TS)Solución Técnica (TS) • Validación (VAL)Validación (VAL) • Verificación (VER)Verificación (VER) • Desarrollo deDesarrollo de Requerimientos (RD)Requerimientos (RD) • Administración deAdministración de Riesgo (RSKM)Riesgo (RSKM) • DefiniciónDefinición Oganizacional delOganizacional del Proceso (+IPPD)Proceso (+IPPD) • EnfoqueEnfoque OrganizacionalOrganizacional del Proceso (OPF)del Proceso (OPF) • EntrenamientoEntrenamiento OrganizacionalOrganizacional (OT)(OT) IngenieríaIngenieríaGestión de ProcesosGestión de Procesos Gestión deGestión de ProyectosProyectos ApoyoApoyo Nivel 3. DefinidoNivel 3. Definido CMMI – Niveles y disciplinasCMMI – Niveles y disciplinas
- 14. Gestión deGestión de ProcesosProcesos Gestión deGestión de ProyectosProyectos IngenieríaIngeniería ApoyoApoyo • DesempeñoDesempeño OrganizacionalOrganizacional del Proceso (OPP)del Proceso (OPP) • AdministraciónAdministración Cuantitativa deCuantitativa de Proyecto (QPM)Proyecto (QPM) Gestión deGestión de ProcesosProcesos Gestión deGestión de ProyectosProyectos IngenieríaIngeniería ApoyoApoyo • Innovación yInnovación y MejoraMejora OrganizacionalOrganizacional (OID)(OID) • Resolución yResolución y Análisis CausalAnálisis Causal (CAR)(CAR) Nivel 4. Administrado cuantitativamenteNivel 4. Administrado cuantitativamente Nivel 5. OptimizadoNivel 5. Optimizado CMMI – Niveles y disciplinasCMMI – Niveles y disciplinas
- 15. PMBOK vs. CMMIPMBOK 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
- 16. PMBOK vs. CMMIPMBOK vs. CMMI SimilitudesSimilitudes • OrientaciónOrientación • Procesos cubiertosProcesos cubiertos • Planeación de ProyectosPlaneación de Proyectos • Monitoreo y control de proyectosMonitoreo y control de proyectos • Aseguramiento de CalidadAseguramiento de Calidad • Administración de RiesgosAdministración de Riesgos • Administración de RequerimientosAdministración de Requerimientos
- 17. Gestión de RequerimientosGestión de Requerimientos
- 18. Problemática en proyectos deProblemática en proyectos de TITI Síntomas comunes en un proyecto:Síntomas comunes en un proyecto: • Entregables sujetos a interpretaciónEntregables sujetos a interpretación • Criterios de aceptación vagosCriterios de aceptación vagos • Cambios constantes de requerimientosCambios constantes de requerimientos • Re-trabajo en entregables.Re-trabajo en entregables. • Caos en el equipo de trabajoCaos en el equipo de trabajo Al final…Al final… • Confusión y frustración del cliente.Confusión y frustración del cliente. • Incrementos no planeados deIncrementos no planeados de TIEMPOTIEMPO yy CO$TOCO$TO
- 19. Definición de Gestión deDefinición de Gestión de RequerimientosRequerimientos En TI: • ¿Qué es un requerimiento? • Funcional • No funcional • No técnico • ¿Qué es la Gestión de Requerimientos? • ¿Por qué se administran?
- 20. Gestión de Requerimientos –Gestión de Requerimientos – PMBOKPMBOK Á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
- 21. Gestión de Requerimientos –Gestión de Requerimientos – CMMICMMI Á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.
- 22. Gestión de RequerimientosGestión de Requerimientos CMMI y PMBOKCMMI 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
- 23. Gestión de RequerimientosGestión de Requerimientos CMMI y PMBOKCMMI 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
- 24. Gestión de RequerimientosGestión de Requerimientos CMMI y PMBOKCMMI 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
- 25. Gestión de RequerimientosGestión de Requerimientos CMMI y PMBOKCMMI 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 RastreabilidadAdicionalmente, CMMI contempla la Rastreabilidad bidireccional de Requerimientos.bidireccional de Requerimientos. • Describir y seguir la vida de un requerimientoDescribir y seguir la vida de un requerimiento • Definir, capturar y seguir la dependencia conDefinir, capturar y seguir la dependencia con otros elementos y/o requerimientosotros elementos y/o requerimientos
- 26. ConclusionesConclusiones 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
- 27. ReferenciasReferencias 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/
- 28. Preguntas y RespuestasPreguntas y Respuestas
- 29. ¡Gracias!¡Gracias! Contacto: Víctor Caravantes OrtegaContacto: Víctor Caravantes Ortega Gerente de TecnologíaGerente de Tecnología Vision ConsultingVision Consulting vcaravantes@visionconsulting.com.mxvcaravantes@visionconsulting.com.mx
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.