Đang tải... (xem toàn văn)
Lecture Software process improvement: Lesson 1 provide students with knowledge about: CMMI staged – maturity level 3; the maturity levels; attributes of a process suggested by CMMI; defined process builds; requirements development; technical solution; product integration; verification; validation; organizational process focus;... Please refer to the detailed content of the lecture!
CMMI Staged – Maturity Level 3 1 Lecture # 16 Following slide to be inserted The Maturity Levels The Maturity Levels Optimizing 5 Focus on process improvement Quantitatively Managed 4 Process measured and controlled Process characterized for the organization and is proactive Process characterized for projects and is often reactive 1 Process unpredictable, poorly controlled and reactive Defined Managed Performed Maturity Level • Maturity Level 3 differs from Level 2 in that now an organizational way of doing business has been developed. What that means is that the best practices and lessons learned from the projects have bubbled up to the organizational level to create an organizational identity Maturity Level • There are common, shared approaches for performing daily tasks on each project. For example, estimating the size of a project may be done using the Delphi Technique (basically subject matter experts discussing bestcase and worstcase estimates), a standard metric may have been institutionalized (such as using function points instead of lines of code), and a standard tool may be in use Maturity Level • This organizational way of doing business is documented in the Organization’s Set of Standard Processes (OSSP) • However, should a project need to tailor this OSSP to more adequately fit its needs, then that tailoring request is bought to a decisionmaking body (usually the Engineering Process Group [EPG]), and if appropriate, the request is granted Maturity Level • An example may be a legacy system that calculates size by lines of code instead of by function point. Rather than reengineer the millions of lines of code in the system in order to use a tool to count function points, and rather than do it manually, the project is simply allowed to continue calculating size by lines of code. The Delphi Technique is still used, but lines of code is the measurement Maturity Level • To perform at Level 3, an organization must have satisfied all of the goals for all of the process areas (PAs) in both Level 2 and Level 3 • Sometimes exceptions may be made. Caution should be exercised however Maturity Level • Entire process areas are generally not allowed to be tailored out of consideration. Practices may be tailored out if replaced by sufficient alternative practices. Remember: the more tailoring done, the less likely an organization is to achieve improvement, and the less likely the organization is to achieve a maturity level through an appraisal Attributes of a Process suggested by CMMI 10 Technical Solution (TS) • Technical Solution includes determining how to satisfy the requirements via analysis of different alternatives and methods; creating operational scenarios; selecting solutions and followon designs; generating a technical data package that may include development methodologies, bills of material, lifecycle processes, product descriptions, requirements, conditions of use, rationale for decisions made, and verification criteria; defining and documenting detailed interface information; determining whether to make, buy, or reuse; and implementing the design and generating supporting documentation 48 Product Integration PA 3 49 Product Integration (PI) • The purpose of Product Integration (PI) is to assemble the product from the product components, ensure that the product, as integrated, functions properly, and deliver the product • Specific goals for this process area are – SG1 Prepare for product integration – SG2 Ensure Interface Compatibility – SG3 Assemble Product Components and Deliver the Product 50 SG1 Prepare for Product Integration – Specific Practices • SP 1.1 Determine Integration Sequence • SP 1.2 Establish the Product Integration Environment • SP 1.3 Establish Product Integration Procedures and Criteria 51 SG2 Ensure Interface Compatibility – Specific Practices • SP 2.1 Review Interface Descriptions for Completeness • SP 2.2 Manage Interfaces 52 SG3 Assemble Product Components and Deliver the Product – Specific Practices • SP 3.1 Confirm Readiness of Product Components for Integration • SP 3.2 Assemble Product Components • SP 3.3 Evaluate Assembled Product Components • SP 3.4 Package and Deliver the Product or Product Component 53 Discussion on PI 54 Product Integration (PI) • This is where the product comes together and you get to see the results of your work • It is also where you deliver the product, and that means you get paid • This process area expects the project to demonstrate each step to the user 55 Product Integration (PI) • This process area is not release management. Releasing products is covered somewhat in Configuration Management, Supplier Agreement Management, and Technical Solution 56 Things People Forget • The nightly build does not satisfy all of the Product Integration process area practices. Just running the automated build nightly does not constitute planning an integration sequence. You must analyze the problems that occur and see if any of the integrated components conflict with remaining components or modules or requirements. Also, the emphasis is on being proactive and identifying problems early, rather than being reactive to problems that pop up during 57 the nightly run Product Integration (PI) • There are no generic practices that directly map to this process area 58 Product Integration (PI) • Product Integration includes determining how to assemble the product and what the sequence of assembly should be; creating an operational environment in which to satisfactorily deploy the product; documenting procedures and criteria for integrating the product; ensuring adequate integration of interfaces; and delivering the product 59 Product Integration (PI) • There are no generic practices that directly map to this process area 60 Summary 61 References • Interpreting the CMMI: A Process Improvement Approach, Second Edition, by Margaret K. Kulpa and Kent A. Johnson, Auerbach Publication, 2008 (electronic file), (Chapter 6) 62 ... expressed in verbs, and usually becomes the entry criteria for the next? ?process? ?step or next? ?process. ) 14 Managed? ?Process • Another distinction is made concerning processes. A managed? ?process? ?is a? ?process? ? that tackles project management efforts, is ... adherence to its? ?process? ?description • This is the type of? ?process? ?expected at Maturity Level 2 15 Defined? ?Process • A defined? ?process? ?builds upon a managed process? ?by creating an organizational process? ?that is then tailored to fit the needs ... Technical Solution (TS) • In this? ?process? ?area, when the model refers to processes, the model generally does not mean? ?process? ?improvement–type processes, but design processes. That is, the processes they are talking about in this PA focus on