02 February 2008

PP y REQM en CMMi ACQ V1.2 (2)

PROJECT PLANNING

El propósito de Project Planning (PP), perteneciente al Nivel de Madurez 2, consiste en establecer y mantener los planes que se definen en las actividades del proyecto. Esta área de proceso involucra lo siguiente: (1) Desarrollo del plan de proyecto, (2) Interacción con las partes interesadas, (3) Obtener la conformidad respecto del plan y (4) Mantenimiento del plan.

La planificación comienza con los requerimientos que definen el producto y el proyecto. La planificación del proyecto incluye el desarrollo y mantenimiento de los planes de todos los procesos adquiridos incluidos los procesos que requieren una interacción proveedor-cliente. También incluye establecer y mantener un plan para la transición al producto adquirido.

El plan de proyecto necesita ser revisado para poder administrar los cambios que se realizan en los requerimientos. Estos cambios pueden afectar las estimaciones de la planificación del proyecto, los presupuestos, riesgos, tareas del proyecto, recursos y confirmaciones.

PP se relaciona con las siguientes áreas de proceso: ARD, REQM, RSKM, ATM, SSAD y MA. Los objetivos específicos (SG), prácticas especificas (SP) y subprácticas de esta AP son:

SG 1 - Establish Estimates

SP 1.1 – Establish the Acquisition Strategy

1.1.1- Identify the capabilities and objectives the acquisition is intended to satisfy or provide. 1.1.2- Identify the acquisition approach. 1.1.3- Document business considerations 1.1.4- Identify major risks and which risks will be addresses jointly with the supplier 1.1.5- Identify the preferred supplier agreement type 1.1.6- Identify the product support strategy 1.1.7- Review and obtain agreement with senior management on the acquisition strategy

SP 1.2 - Estimate the Scope of the Project

1.2.1- Develop a WBS (Work Breakdown Structure) based on the product architecture. 1.2.2- Identify the work packages in sufficient detail to specify estimates of project tasks, responsibilities, and schedule 1.2.3- Identify product or product components to be externally acquired. 1.2.4- Identify work products to be reused.

SP 1.3 - Establish Estimates of Work Product and Task Attributes

1.3.1- Determine the technical approach for the project. 1.3.2- Use appropriate methods to determine the attributes of the work products and tasks to be used to estimate the resource requirements 1.3.3- Estimate the attributes of the work products and tasks.

SP 1.4 - Define Project Life Cycle

SP 1.5 - Determine Effort and Cost

1.5.1- Collect models or historical data to be used to transform the attributes of the work products and tasks into estimates of labor hours and costs. 1.5.2- Include supporting infrastructure needs when estimating effort and cost. 1.5.3- Estimate effort and cost using models and/or historical data.

Productos de trabajo típicos

Acquisition strategy (SP 1.1) Task descriptions (SP 1.2) Work package descriptions (SP 1.2) WBS (SP 1.2) Technical approach (SP 1.3) Size and complexity of tasks and work products (SP 1.3) Estimating models (SP 1.3) Attribute estimates (SP 1.3) Project lifecycle phases (SP 1.4) Estimation rationale (SP 1.5) Project effort estimates (SP 1.5) Project cost estimates (SP 1.5)

SG 2 - Develop a Project Plan

SP 2.1 - Establish the Budget and Schedule

2.1.1- Identify major milestones. 2.1.2- Identify schedule assumptions. 2.1.3- Identify constraints 2.1.4- Identify task dependencies. 2.1.5- Define the budget and schedule. 2.1.6- Establish corrective action criteria.

SP 2.2 - Identify Project Risks

2.2.1- Identify risks. 2.2.2- Document risks 2.2.3- Review and obtain agreement with relevant stakeholders on the completeness and correctness of documented risks. 2.2.4- Revise risks, as appropriate.

SP 2.3 - Plan Data Management

2.3.1-Establish requirements and procedures to ensure privacy and security of data. 2.3.2- Establish a mechanism to archive data and to access archived data. 2.3.3- Determine the project data to be identified, collected, and distributed. 2.3.4- Decide which project data and plans require version control or more stringent levels of configuration control and establish mechanisms to ensure project data are controlled.

SP 2.4 - Plan the Project’s Resources

2.4.1- Determine process requirements. 2.4.2- Determine staffing requirements. 2.4.3- Determine facilities, equipment, and component requirements.

SP 2.5 - Plan Needed Knowledge and Skills

2.5.1- Identify the knowledge and skills needed to perform the project. 2.5.2- Assess the knowledge and skills available. 2.5.3- Select mechanisms for providing needed knowledge and skills. 2.5.4- Incorporate selected mechanisms into the project plan.

SP 2.6 - Plan Stakeholder Involvement

SP 2.7 – Plan Transition to Operations and Support

2.7.1- Determine the transition scope and objectives. 2.7.2- Determine transition requirements and criteria. 2.7.3- Determine transition responsibilities and resources to include post-transition support enhancements and lifecycle considerations. 2.7.4- Determine configuration management needs of the transition. 2.7.5- Determine training needs for operations and support.

SP 2.8 - Establish the Project Plan

Productos de trabajo típicos

Project schedules (SP 2.1) Schedules dependencies (SP 2.1) Project budget (SP 2.1) Identified risks (SP 2.2) Risk impacts and probability of occurrence (SP 2.2) Risk priorities (SP 2.2)

Data management plan (SP 2.3) Master list of managed data (SP 2.3) Data content and format description (SP 2.3) List of data requirements for acquirers and suppliers (SP 2.3) Privacy requirements (SP 2.3) Security requirements (SP 2.3) Security procedures (SP 2.3) Mechanisms for data retrieval, reproduction, and distribution (SP 2.3) Schedule for the collection of project data (SP 2.3) List of project data to be collected (SP 2.3)

WBS work packages (SP 2.4) WBS task dictionary (SP 2.4) Staffing requirements based on project size and scope (SP 2.4) Critical facilities and equipment list (SP 2.4) Process and workflow definitions and diagrams (SP 2.4) Program administration requirements list (SP 2.4)

Inventory of skill needs (SP 2.5) Staffing and new hire plans (SP 2.5) Databases (SP 2.5) Training Plans (SP 2.5) Stakeholder involvement plan (SP 2.6) Transition to operations and support plans (SP 2.7) Overall project plan (SP 2.8)

SG 3 - Obtain Commitment to the Plan

SP 3.1 - Review Plans that Affect the Project

SP 3.2 - Reconcile Work and Resource Levels

SP 3.3 - Obtain Plan Commitment

3.3.1- Identify needed support and negotiate commitments with relevant stakeholders. 3.3.2- Document all organizational commitments, both full and provisional, ensuring appropriate level of signatories. 3.3.3- Review internal commitments with senior management as appropriate. 3.3.4- Review external commitments with senior management as appropriate. 3.3.5- Identify commitments regarding interfaces between project elements and other projects and organizational units so that these commitments can be monitored.

Productos de trabajo típicos

Record of the reviews of plans that affect the project (SP 3.1) Revised methods and corresponding estimating parameters (SP 3.2) Renegotiated budgets (SP 3.2) Revised schedules (SP 3.2) Revised requirements list (SP 3.2) Renegotiated stakeholder agreements (SP 3.2) Documented requests for commitments (SP 3.3) Documented commitments (SP 3.3)

REQUIREMENTS MANAGEMENT

EL propósito de Requirements Management (REQM), perteneciente al Nivel de Madurez 2, es administrar los requerimientos de los productos del proyecto y de los componentes del proyecto. Permite identificar las inconsistencias entre estos requerimientos y los productos de trabajo y planes del proyecto.

Los procesos de manejo de requerimientos administran todos los requerimientos recibidos o generados en el proyecto, incluyendo los requerimientos técnicos y no técnicos. Esta área de proceso es implementada y genera requerimientos del cliente y del contrato que serán administrados por los procesos de manejo de requerimientos.

Todos los proyectos tienen requerimientos. En el caso de un proyecto de mantenimiento, los cambios del producto o de los componentes del producto están basados en los cambios de los actuales requerimientos, en el diseño o en la implementación. Los cambios de los requerimientos pueden ser documentados en las solicitudes de cambio del cliente o pueden tomar la forma de nuevos requerimientos recibidos del proceso de desarrollo de requerimientos.

REQM se relaciona con las siguientes áreas de proceso: ARD, PP, CM, PMC y RSKM. Los objetivos específicos (SG), prácticas especificas (SP) y subprácticas de esta AP son:

SG 1 - Manage Requirements

SP 1.1 – Understand Requirements

1.1.1- Establish criteria for distinguishing appropriate requirements providers. 1.1.2- Establish objective criteria for the evaluation and acceptance of requirements. 1.1.3- Analyze requirements to ensure that established criteria are met. 1.1.4- Reach an understanding of requirements with requirements provider so that project participants can commit to them.

SP 1.2 - Obtain Commitment to Requirements

1.2.1- Assess the impact of requirements on existing commitments. 1.2.2- Negotiate and record commitments.

SP 1.3 - Manage Requirements Changes

1.3.1- Document all requirements and requirements changes that are given to or generated by the project. 1.3.2- Maintain a requirements change history including the rationale for the changes. 1.3.3- Evaluate the impact of requirement changes from the standpoint of relevant stakeholders. 1.3.4- Make requirements and change data available to the project.

SP 1.4 - Maintain Bidirectional Traceability of Requirements

1.4.1- Maintain requirements traceability to ensure that the source of lower level (derived) requirements is documented. 1.4.2- Maintain requirements traceability from a requirement to its derived requirements and allocation to functions, interfaces, objects, people, processes, and work products. 1.4.3- Generate a requirements traceability matrix.

SP 1.5 - Identify Inconsistencies between Project Work and Requirements

1.5.1- Review the project’s plans, activities, and work products for consistency with requirements and changes made to them. 1.5.2- Identify the source of the inconsistency 1.5.3- Identify changes that must be made to plans and work products resulting from changes to the requirements baseline. 1.5.4- Initiate corrective actions.

Productos de trabajo típicos

Lists of criteria for distinguishing appropriate requirements providers (SP 1.1) Criteria for evaluation and acceptance of requirements (SP 1.1) Results of analyses against criteria (SP 1.1) An agreed-to set of requirements (SP 1.1) Requirements impact assessments (SP 1.2) Documented commitments to requirements and requirements changes (SP 1.2)

Requirements change requests (SP 1.3) Requirements change impact reports (SP 1.3) Requirements status (SP 1.3) Requirements database (SP 1.3) Requirements decision database (SP 1.3) Requirements traceability matrix (SP 1.4) Requirements tracking system (SP 1.4) Documentation of inconsistencies between requirements and project plans and work products, including sources, conditions and rationale (SP 1.5) Corrective actions (SP 1.5)

Productos de trabajo del Proveedor

Supplier’s requirements impact assessments (SP 1.2) Requirements change requests (SP 1.3) Requirements change impact reports (SP 1.3) Comprehensive requirements traceability matrix managed by the supplier as required by the supplier agreement (SP 1.4)