CMMI for Development phần 10 ppsx

CMMI for Development Version 1.2 Supplier Agreement Management (SAM) 452 some portions of the plan reside outside of the project with an independent group, such as contract management. GP 2.3 Provide Resources Provide adequate resources for performing the supplier agreement management process, developing the work products, and providing the services of the process. Elaboration: Examples of resources provided include the following tools: • Preferred supplier lists • Requirements tracking programs • Project management and scheduling programs GP 2.4 Assign Responsibility Assign responsibility and authority for performing the process, developing the work products, and providing the services of the supplier agreement management process. GP 2.5 Train People Train the people performing or supporting the supplier agreement management process as needed. Elaboration: Examples of training topics include the following: • Regulations and business practices related to negotiating and working with suppliers • Acquisition planning and preparation • COTS products acquisition • Supplier evaluation and selection • Negotiation and conflict resolution • Supplier management • Testing and transitioning of acquired products • Receiving, storing, using, and maintaining acquired products GP 2.6 Manage Configurations Place designated work products of the supplier agreement management process under appropriate levels of control. CMMI for Development Version 1.2 Supplier Agreement Management (SAM) 453 Elaboration: Examples of work products placed under control include the following: • Statements of work • Supplier agreements • Memoranda of agreement • Subcontracts • Preferred supplier lists GP 2.7 Identify and Involve Relevant Stakeholders Identify and involve the relevant stakeholders of the supplier agreement management process as planned. Elaboration: Examples of activities for stakeholder involvement include the following: • Establishing criteria for evaluation of potential suppliers • Reviewing potential suppliers • Establishing supplier agreements • Resolving issues with suppliers • Reviewing supplier performance GP 2.8 Monitor and Control the Process Monitor and control the supplier agreement management process against the plan for performing the process and take appropriate corrective action. Elaboration: Examples of measures and work products used in monitoring and controlling include the following: • Number of changes made to the requirements for the supplier • Cost and schedule variance per supplier agreement • Number of supplier work product evaluations completed (planned versus actuals) • Number of supplier process evaluations completed (planned versus actuals) • Schedule for selecting a supplier and establishing an agreement CMMI for Development Version 1.2 Supplier Agreement Management (SAM) 454 GP 2.9 Objectively Evaluate Adherence Objectively evaluate adherence of the supplier agreement management process against its process description, standards, and procedures, and address noncompliance. Elaboration: Examples of activities reviewed include the following: • Establishing and maintaining supplier agreements • Satisfying supplier agreements Examples of work products reviewed include the following: • Plan for Supplier Agreement Management • Supplier agreements GP 2.10 Review Status with Higher Level Management Review the activities, status, and results of the supplier agreement management process with higher level management and resolve issues. Staged Only GG3 and its practices do not apply for a maturity level 2 rating, but do apply for a maturity level 3 rating and above. Continuous/Maturity Levels 3 - 5 Only GG 3 Institutionalize a Defined Process The process is institutionalized as a defined process. GP 3.1 Establish a Defined Process Establish and maintain the description of a defined supplier agreement management process. GP 3.2 Collect Improvement Information Collect work products, measures, measurement results, and improvement information derived from planning and performing the supplier agreement management process to support the future use and improvement of the organization’s processes and process assets. CMMI for Development Version 1.2 Supplier Agreement Management (SAM) 455 Continuous/Maturity Levels 3 - 5 Only Elaboration: Examples of work products, measures, measurement results, and improvement information include the following: • Results of supplier reviews • Trade studies used to select suppliers • Revision history of supplier agreements • Supplier performance reports • Results of supplier work product and process evaluations Continuous Only GG 4 Institutionalize a Quantitatively Managed Process The process is institutionalized as a quantitatively managed process. GP 4.1 Establish Quantitative Objectives for the Process Establish and maintain quantitative objectives for the supplier agreement management process, which address quality and process performance, based on customer needs and business objectives. GP 4.2 Stabilize Subprocess Performance Stabilize the performance of one or more subprocesses to determine the ability of the supplier agreement management process to achieve the established quantitative quality and process-performance objectives. GG 5 Institutionalize an Optimizing Process The process is institutionalized as an optimizing process. GP 5.1 Ensure Continuous Process Improvement Ensure continuous improvement of the supplier agreement management process in fulfilling the relevant business objectives of the organization. GP 5.2 Correct Root Causes of Problems Identify and correct the root causes of defects and other problems in the supplier agreement management process. CMMI for Development Version 1.2 Technical Solution (TS) 456 TECHNICAL SOLUTION An Engineering Process Area at Maturity Level 3 Purpose The purpose of Technical Solution (TS) is to design, develop, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product-related lifecycle processes either singly or in combination as appropriate. Introductory Notes The Technical Solution process area is applicable at any level of the product architecture and to every product, product component, and product-related lifecycle process. Throughout the process areas, where we use the terms product and product component, their intended meanings also encompass services and their components. The process area focuses on the following: • Evaluating and selecting solutions (sometimes referred to as “design approaches,” “design concepts,” or “preliminary designs”) that potentially satisfy an appropriate set of allocated requirements • Developing detailed designs for the selected solutions (detailed in the context of containing all the information needed to manufacture, code, or otherwise implement the design as a product or product component) • Implementing the designs as a product or product component Typically, these activities interactively support each other. Some level of design, at times fairly detailed, may be needed to select solutions. Prototypes or pilots may be used as a means of gaining sufficient knowledge to develop a technical data package or a complete set of requirements. Technical Solution specific practices apply not only to the product and product components but also to product-related lifecycle processes. The product-related lifecycle processes are developed in concert with the product or product component. Such development may include selecting and adapting existing processes (including standard processes) for use as well as developing new processes. Processes associated with the Technical Solution process area receive the product and product component requirements from the CMMI for Development Version 1.2 Technical Solution (TS) 457 requirements management processes. The requirements management processes place the requirements, which originate in requirements development processes, under appropriate configuration management and maintain their traceability to previous requirements. For a maintenance or sustainment project, the requirements in need of maintenance actions or redesign may be driven by user needs or latent defects in the product components. New requirements may arise from changes in the operating environment. Such requirements can be uncovered during verification of the product(s) where actual performance can be compared against the specified performance and unacceptable degradation can be identified. Processes associated with the Technical Solution process area should be used to perform the maintenance or sustainment design efforts. Related Process Areas Refer to the Requirements Development process area for more information about requirements allocations, establishing an operational concept, and interface requirements definition. Refer to the Verification process area for more information about conducting peer reviews and verifying that the product and product components meet requirements. Refer to the Decision Analysis and Resolution process area for more information about formal evaluation. Refer to the Requirements Management process area for more information about managing requirements. The specific practices in the Requirements Management process area are performed interactively with those in the Technical Solution process area. Refer to the Organizational Innovation and Deployment process area for more information about improving the organization’s technology. Specific Goal and Practice Summary SG 1 Select Product Component Solutions SP 1.1 Develop Alternative Solutions and Selection Criteria SP 1.2 Select Product Component Solutions SG 2 Develop the Design SP 2.1 Design the Product or Product Component SP 2.2 Establish a Technical Data Package SP 2.3 Design Interfaces Using Criteria SP 2.4 Perform Make, Buy, or Reuse Analyses SG 3 Implement the Product Design SP 3.1 Implement the Design SP 3.2 Develop Product Support Documentation CMMI for Development Version 1.2 Technical Solution (TS) 458 Specific Practices by Goal SG 1 Select Product Component Solutions Product or product component solutions are selected from alternative solutions. Alternative solutions and their relative merits are considered in advance of selecting a solution. Key requirements, design issues, and constraints are established for use in alternative solution analysis. Architectural features that provide a foundation for product improvement and evolution are considered. Use of commercial off-the-shelf (COTS) product components are considered relative to cost, schedule, performance, and risk. COTS alternatives may be used with or without modification. Sometimes such items may require modifications to aspects such as interfaces or a customization of some of the features to better achieve product requirements. One indicator of a good design process is that the design was chosen after comparing and evaluating it against alternative solutions. Decisions on architecture, custom development versus off the shelf, and product component modularization are typical of the design choices that are addressed. Some of these decisions may require the use of a formal evaluation process. Refer to the Decision Analysis and Resolution process area for more information about the use of a formal evaluation process. Sometimes the search for solutions examines alternative instances of the same requirements with no allocations needed for lower level product components. Such is the case at the bottom of the product architecture. There are also cases where one or more of the solutions are fixed (e.g., a specific solution is directed or available product components, such as COTS, are investigated for use). In the general case, solutions are defined as a set. That is, when defining the next layer of product components, the solution for each of the product components in the set is established. The alternative solutions are not only different ways of addressing the same requirements, but they also reflect a different allocation of requirements among the product components comprising the solution set. The objective is to optimize the set as a whole and not the individual pieces. There will be significant interaction with processes associated with the Requirements Development process area to support the provisional allocations to product components until a solution set is selected and final allocations are established. Product-related lifecycle processes are among the product component solutions that are selected from alternative solutions. Examples of these product-related lifecycle processes are the manufacturing, delivery, and support processes. CMMI for Development Version 1.2 Technical Solution (TS) 459 SP 1.1 Develop Alternative Solutions and Selection Criteria Develop alternative solutions and selection criteria. Refer to the Allocate Product Component Requirements specific practice in the Requirements Development process area for more information about obtaining allocations of requirements to solution alternatives for the product components. Refer to the Decision Analysis and Resolution process area for more information about establishing criteria used in making decisions. IPPD Addition The activity of selecting alternative solutions and issues to be subject to decision analyses and trade studies is accomplished by the involvement of relevant stakeholders. These stakeholders represent both business and technical functions and the concurrent development of the product and the product-related lifecycle processes (e.g., manufacturing, support, training, verification, and disposal). In this way, important issues surface earlier in product development than with traditional serial development and can be addressed before they become costly mistakes. Alternative solutions need to be identified and analyzed to enable the selection of a balanced solution across the life of the product in terms of cost, schedule, and performance. These solutions are based on proposed product architectures that address critical product qualities and span a design space of feasible solutions. Specific practices associated with the Develop the Design specific goal provide more information on developing potential product architectures that can be incorporated into alternative solutions for the product. Alternative solutions frequently encompass alternative requirement allocations to different product components. These alternative solutions can also include the use of COTS solutions in the product architecture. Processes associated with the Requirements Development process area would then be employed to provide a more complete and robust provisional allocation of requirements to the alternative solutions. Alternative solutions span the acceptable range of cost, schedule, and performance. The product component requirements are received and used along with design issues, constraints, and criteria to develop the alternative solutions. Selection criteria would typically address costs (e.g., time, people, and money), benefits (e.g., performance, capability, and effectiveness), and risks (e.g., technical, cost, and schedule). Considerations for alternative solutions and selection criteria include the following: • Cost of development, manufacturing, procurement, maintenance, and support, etc. • Performance CMMI for Development Version 1.2 Technical Solution (TS) 460 • Complexity of the product component and product-related lifecycle processes • Robustness to product operating and use conditions, operating modes, environments, and variations in product-related lifecycle processes • Product expansion and growth • Technology limitations • Sensitivity to construction methods and materials • Risk • Evolution of requirements and technology • Disposal • Capabilities and limitations of end users and operators • Characteristics of COTS products The considerations listed here are a basic set; organizations should develop screening criteria to narrow down the list of alternatives that are consistent with their business objectives. Product lifecycle cost, while being a desirable parameter to minimize, may be outside the control of development organizations. A customer may not be willing to pay for features that cost more in the short term but ultimately decrease cost over the life of the product. In such cases, customers should at least be advised of any potential for reducing lifecycle costs. The criteria used in selections of final solutions should provide a balanced approach to costs, benefits, and risks. Typical Work Products 1. Alternative solution screening criteria 2. Evaluation reports of new technologies 3. Alternative solutions 4. Selection criteria for final selection 5. Evaluation reports of COTS products Subpractices 1. Identify screening criteria to select a set of alternative solutions for consideration. 2. Identify technologies currently in use and new product technologies for competitive advantage. Refer to the Organizational Innovation and Deployment process area for more information about improving the organization’s technology. CMMI for Development Version 1.2 Technical Solution (TS) 461 The project should identify technologies applied to current products and processes and monitor the progress of currently used technologies throughout the life of the project. The project should identify, select, evaluate, and invest in new technologies to achieve competitive advantage. Alternative solutions could include newly developed technologies, but could also include applying mature technologies in different applications or to maintain current methods. 3. Identify candidate COTS products that satisfy the requirements. Refer to the Supplier Agreement Management process area for more information about evaluating suppliers. These requirements include the following: • Functionality, performance, quality, and reliability • Terms and conditions of warranties for the products • Risk • Suppliers' responsibilities for ongoing maintenance and support of the products 4. Generate alternative solutions. 5. Obtain a complete requirements allocation for each alternative. 6. Develop the criteria for selecting the best alternative solution. Criteria should be included that address design issues for the life of the product, such as provisions for more easily inserting new technologies or the ability to better exploit commercial products. Examples include criteria related to open design or open architecture concepts for the alternatives being evaluated. SP 1.2 Select Product Component Solutions Select the product component solutions that best satisfy the criteria established. Refer to the Allocate Product Component Requirements and Identify Interface Requirements specific practices of the Requirements Development process area for information on establishing the allocated requirements for product components and interface requirements among product components. Selecting product components that best satisfy the criteria establishes the requirement allocations to product components. Lower level requirements are generated from the selected alternative and used to develop the product component design. Interface requirements among product components are described, primarily functionally. Physical interface descriptions are included in the documentation for interfaces to items and activities external to the product. The description of the solutions and the rationale for selection are documented. The documentation evolves throughout development as [...]... between the various product component development efforts Refer to the Requirements Development process area for more information about the allocation and refinement of requirements Refer to the Product Integration process area for more information about the management of interfaces and the integration of products and product components 472 Technical Solution (TS) CMMI for Development Version 1.2 Example... environment • The Perform Validation specific practice enables the performance of validation according to the methods, procedures, and criteria Related Process Areas Refer to the Requirements Development process area for more information about requirements validation Refer to the Technical Solution process area for more information about transforming requirements into product specifications and for corrective... a formal evaluation approach Refer to the Decision Analysis and Resolution process area for more information about defining criteria and alternatives and performing formal evaluations As technology evolves, so does the rationale for choosing to develop or purchase a product component While complex development efforts may favor purchasing an off-the-shelf product component, advances in productivity... for performing the technical solution process Elaboration: This plan for performing the technical solution process can be part of (or referenced by) the project plan as described in the Project Planning process area Technical Solution (TS) 477 CMMI for Development Version 1.2 GP 2.3 Provide Resources Provide adequate resources for performing the technical solution process, developing the work products,... Solution (TS) 471 CMMI for Development Version 1.2 Subpractices 1 Develop criteria for the reuse of product component designs 2 Analyze designs to determine if product components should be developed, reused, or purchased 3 Analyze implications for maintenance when considering purchased or nondevelopmental (e.g., COTS, government off the shelf, and reuse) items Examples of implications for maintenance... Analyze Validation Results Validation (VAL) CMMI for Development Version 1.2 Specific Practices by Goal SG 1 Prepare for Validation Preparation for validation is conducted Preparation activities include selecting products and product components for validation and establishing and maintaining the validation environment, procedures, and criteria The items selected for validation may include only the product... it provides the designer, and the cost effectiveness of that assistance For example, a multiyear prototyping effort may not be appropriate for a simple product component but might be the right thing to do for an unprecedented, expensive, and complex product development Rapid prototyping techniques, however, can be highly effective for many product components Methods that use tools to ensure that a design... Goals The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products 476 Technical Solution (TS) CMMI for Development Version 1.2 Continuous Only GP 1.1 Perform Specific Practices Perform the specific practices of the technical solution process to develop work products and provide services... Definition process area for more information about establishing and maintaining organizational process assets Technical Solution (TS) 469 CMMI for Development Version 1.2 2 Identify interfaces associated with other product components 3 Identify interfaces associated with external items 4 Identify interfaces between product components and the productrelated lifecycle processes For example, such interfaces... optimized for certain qualities or performance characteristics Designers may evaluate the use of legacy or COTS products for the product components As the design matures, the requirements assigned to lower level product components are tracked to ensure that those requirements are satisfied Refer to the Requirements Management process area for more information about tracking requirements for product . Requirements Management process area for more information about tracking requirements for product components. CMMI for Development Version 1.2 Technical Solution (TS) 465 For Software Engineering. technologies for competitive advantage. Refer to the Organizational Innovation and Deployment process area for more information about improving the organization’s technology. CMMI for Development. selection criteria include the following: • Cost of development, manufacturing, procurement, maintenance, and support, etc. • Performance CMMI for Development Version 1.2 Technical Solution (TS)