1 / 38

CMMI

CMMI. Engineering Process Areas. Engineering Process Areas. The Engineering PA’s are: Requirements Management REQM Requirements Development RD Technical Solution TS Product Integration PI Verification VER Validation VAL.

elu
Download Presentation

CMMI

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CMMI Engineering Process Areas

  2. Engineering Process Areas The Engineering PA’s are: Requirements Management REQM Requirements Development RD Technical Solution TS Product Integration PI Verification VER Validation VAL

  3. The Requirements Management and Requirements Development Partnership RD REQM

  4. Requirements Development (RD) Purpose: Produce and analyze customer, product, and product component requirements.

  5. Potential Requirements Development Problems • Unstated requirements or poorly stated requirements lead to confusion among staff and customers. • Design, implementation, and test work products inconsistently interpret the requirements. • It takes an inordinately long time to get agreement on product design. • There is an increased potential for higher costs to meet customer expectations.

  6. Requirements Development Specific Goals SG 1: Develop Customer Requirements Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements. SG 2: Develop Product Requirements Customer requirements are refined and elaborated to develop product and product component requirements. SG 3: Analyze and Validate Requirements The requirements are analyzed andvalidated, and a definition of required functionality is developed.

  7. Requirements Development Context -2 Develop Customer Requirements Develop the CustomerRequirements Elicit Needs Customer Requirements Stakeholders’ Needs

  8. Requirements Development Context -4 Develop Product Requirements TS Customer Requirements Establish Product & Product Component Requirements Selected Solutions Allocate Product Component Requirements Identify Interface Requirements Product, Product component And interface Requirements

  9. Requirements Development Context -6 Analyze and Validate Requirements Establish a Definition of Required Functionality Establish Operational Concepts & Scenarios AnalyzeRequirementsto AchieveBalance Analyze Requirements ValidateRequirements Validated Requirements Product, Product component And interface Requirements

  10. Requirements Management (REQM) Purpose: Manage the requirements of the project’s products and product components and identify inconsistencies between those requirements and the project’s plans and work products.

  11. Potential Requirements Management Problems • Requirements are accepted by staff from any source they deem to be authoritative. • The project experiences a high level of requirements changes. • There are high levels of rework throughout the project. • There is an inability to prove that the product meets the approved requirements. • Lack of requirements traceability often results in incomplete or incorrect testing of the product.

  12. Requirements Management Goals SG 1: Manage Requirements Requirements are managed and inconsistencies with project plans and work products are identified.

  13. Requirements Management Context Manage Requirements ObtainCommitmentto Requirements Manage Requirements Changes Obtain anUnderstanding of Requirements MaintainBidirectional Traceability ofRequirements Validated Requirements IdentifyInconsistenciesBetween ProjectWork and Requirements Traceability Matrix

  14. Technical Solution (TS) Purpose Design, develop, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product-related lifecycle processes either singly or in combinations as appropriate.

  15. Potential Technical Solution Problems • An ineffective solution is chosen. • Products may not meet technical performance requirements or user needs. • Increased testing and rework is required to resolve design issues. • The product may not be able to accommodate technology upgrades and future growth if the technical solution is not well conceived.

  16. Technical Solution Goals SG 1: Select Product Component Solutions Product or product component solutions are selected from alternative solutions. SG 2: Develop the Design Product or product component designs are developed. SG 3: Implement the Product Design Product components, and associated support documentation, are implemented from their designs.

  17. Technical Solution Context RD RD Select Product Component Solutions Select Product Component Solutions Develop Alternative Solutions and Selection Criteria • Alternative Solutions • Selection Criteria Selection Decisions Compliant with Requirements

  18. Technical Solution Context Develop the Design Perform Make, Buy, or Reuse Analyses Establish a Tech Data Package Designthe Product or ProductComponent RD • I/F Design Documents • I/F Specification • I/F Control Documents Tech Data Package Design InterfacesUsingCriteria • Product Architecture • Product Component Designs PI

  19. Technical Solution Context Implement the Product Design Develop Product Support Documentation Implement the Design • End-User Training Materials • User’s Manual • Operator’s Manual • Maintenance Manual • Online Help • Software Coded • Processes Documented

  20. Product Integration (PI) Purpose Assemble the product from the product components, ensure that the product, as integrated, functions properly, and deliver the product.

  21. Potential Product Integration Problems • Subsystems do not operate together. • There is increased integration test time. • The integration environment is inadequate to support the integration activities. • A product is released without all the component integration fully tested.

  22. Product Integration Goals SG 1: Prepare for Product Integration Preparation for product integration is conducted. SG 2: Ensure Interface Compatibility The product component interfaces, both internal and external, are compatible. SG 3: Assemble Product Components and Deliver the Product Verified product components are assembled and the integrated, verified, and validated product is delivered.

  23. Product Integration Context Prepare for Product Integration EstablishProductIntegration Proceduresand Criteria Establishthe ProductIntegration Environment DetermineIntegrationSequence • Integration Sequence • Integration Procedures and Criteria • Integration Environment TS

  24. Product Integration Context Ensure Interface Compatibility ReviewInterface DescriptionsforCompleteness Manage Interfaces • Integration Sequence • Integration Procedures and Criteria • Integration Environment TS

  25. Product Integration Context Assemble Product Components and Deliver Product Package and Deliverthe Product or Product Component Assemble Product Components Confirm Readiness of ProductComponents for Integration Evaluate Assembled Product Components • Integration Sequence • Integration Procedures and Criteria • Integration Environment VER VAL TS

  26. Verification Versus Validation Verification Are you building the product right? That is, are you meeting the specified requirements? Validation Are you building the right product? That is, are you meeting the operational need? Both are applicable throughout the product development lifecycle.

  27. Verification (VER) Purpose Ensure that selected work products meet their specified requirements.

  28. Potential Verification Problems • There is disagreement among technical staff as to whether the different components meet the requirements. • The product being tested does not meet design requirements. • Product reliability suffers because defects are not detected or corrected prior to customer release. • Added rework occurs because defects that could have been caught early escape into later lifecycle phases.

  29. Verification Goals SG 1: Prepare for Verification Preparation for verification is conducted. SG 2: Perform Peer Reviews Peer reviews are performed on selected work products. SG 3: Verify Selected Work Products Selected work products are verified against their specified requirements.

  30. Verification Environment • Verification Procedures and Criteria • List of Work ProductsSelected for Verification Verification Context Prepare for Verification Establish Verification Proceduresand Criteria Establish the Verification Environment Select Work Products for Verification

  31. Verification Context Perform Peer Reviews Analyze Peer Review Data Prepare For Peer Reviews • Requirement for Data Collection • Entry and Exit Criteria • Peer Review Plan • Review Results • Review Issues • Review Data • Action Items Conduct Peer Reviews

  32. Verification Context Verify Selected Work Products Perform Verification • Verification Results • Deficiencies • Verification Data • Corrective Actions Analyze Verification Results

  33. Validation (VAL) Purpose Demonstrate that a product or product component fulfills its intended use when placed in its intended environment.

  34. Potential Validation Problems • There are arguments among the technical staff as to what the user really wants. • The released product does not meet user expectations. • Customers do not pay for products that do not meet their needs. • End users refuse to use the product as delivered.

  35. Validation Goals SG 1: Prepare for Validation Preparation for validation is conducted. SG 2: Validate Product or Product Components The product or product components are validated to ensure that they are suitable for use in their intended operating environment.

  36. Validation Context Prepare for Validation Establish the Validation Environment SelectProducts for Validation Establish Validation Proceduresand Criteria • Validation Environment • Validation Procedures and Criteria • List of Products and ProductComponents Selected for Validation

  37. Validation Context Validate Product or Product Components Analyze Validation Results Perform Validation • Validation Reports • Validation Results • Cross Reference Matrix • As Run Procedures Log • Operational Demonstrations • Validation Deficiency Reports • Validation Issues • Procedure Change Request

  38. Engineering Process Areas REQM Product and component requirements Alternative Solutions Product Components RD TS PI Product Customer Requirements Product Components Product Components Verification Report Validation Report VER VAL

More Related