SMU CSE 7315 Planning and Managing a Software Project

1. SMU CSE 7315Planning and Managing a Software Project Module 36 Details of the SEI CMM and CMMI

2. Objective of This Module • To examine the SEI CMM (capability maturity model) and CMMI (capability maturity model integrated) in further detail Note: a thorough discussion of these models would require a half day or more – there are many commercially available short courses on this subject.

3. Level 5 Maturity Level 4 Maturity Level 3 Maturity Level 2 Maturity Level 1 Maturity Structure of the CMM and the "Staged" version of the CMMI

4. Structure (continued) • “Each level comprises a set of process goals that, when satisfied, stabilize an important component of the process. • “Achieving each level of the maturity framework establishes a different component in the process, resulting in an increase in the process capability of the organization.” As one moves up the levels, one exhibits greater maturity and capability and one EXPECTS to achieve better performance

5. Effects of Higher Levels At higher levels, one expects the following characteristics: • Better visibility into what is happening • Less variability in outcomes • Less risk associated with software development, due to more accurate planning and better management

6. Level 1 Input Output Input Output Level 2 Process Step Level 2 Process Step Level 2 Process Step Level 3 Process Step Level 3 Process Step Level 3 Process Step Better Visibility

7. Lower Variability / Less Risk Level 1 Level 2 Level 3 etc.

8. What kind of Model is the CMM or CMMI? • The CMM/CMMI is a descriptivemodel and a normative model • A descriptive model acts as an example or a paradigm or an ideal • A model home • A fashion model • A normative model acts as a way to compare two or more instances of something • A model of the human body • A model of an automobile engine

9. Descriptive Model • The model describes essential (or key) attributes that would be expected to characterize an organization at a particular maturity level. • Example: an organization at level 3 has documented its process for configuration management • One can use these attributes to evaluate one’s organization or to establish goals for an organization • Example: if we do not document our process for CM, we are probably not at level 3 • If we want to be at level 3, we should probably document our process for CM

10. Uses of the Models • Appraisal teams will use the models to identify strengths and weaknesses in the organization. • The SEI has defined processes for doing self-assessments and other forms of appraisals • Evaluation teams will use the models to identify the risks of selecting among different contractors for awarding business and to monitor contracts. • The SEI has defined processes for doing capability evaluations • There are many less extensive ways the models can be used to evaluate contractors

11. Uses (continued) • Managers and technical staff will use the models to understand the activities necessary to plan and implement a software process improvement program for their organization • The models are sometimes followed too rigidly, but the goals tend to be universally applicable • Process improvement groups, such as an EPG [engineering process group], will use the models as a guide to help them define and improve the engineering processes in their organization.

12. Use as A Normative Model • The detailed practices in the models characterize the normal types of behavior that would be expected in an organization doing large-scale projects, such as those found in a government contracting context. • A given organization can compare itself with the models to determine how it “stacks up” with what is considered an example of best practices.

13. Do These Models Fit a Small Organization? • There is considerable debate about the extent to which these practices should be expected in other kinds of organizations. • Watts Humphrey (1) has shown that the principles, if not always the specific practices, are applicable to individual, single-person projects (very small scale) that are not in a government contracting mode (1) Humphrey, Watts, A Discipline of Software Engineering, Addison Wesley, 1994.

14. The Principles Seem to Be Universally Applicable • The intent is that the models are at a sufficient level of abstraction that it does not unduly constrain how the development process is implemented by an organization • Rather, the models describe what the essential attributes of a process would normally be expected to be • One must keep this in mind when applying the CMM or CMMI

15. Level 5 Maturity Level 4 Maturity Level 3 Maturity Level 2 Maturity Level 1 Maturity Structure of the CMMI (CMM) Maturity Levels Indicate Process Capability Contain (Key) Process Areas Achieve Goals Organized by Common Features Address Implementation Contain Describe Specific or Generic (Key) Practices Specific or Generic Goals in CMMI Infrastructure or Activities

16. Level 2: Repeatable Indicate Process Capability: Disciplined Process Contains SW Project Planning Achieve Goal: SW Estimates are Documented ... Organized by Activities Performed Address Implementation: Implementation Activities Contains Documented Procedure for Size Estimates Describe Infrastructure or Activities Example

17. Process Areas Process Areas • Except for Level 1, each level of the CMMI is defined in terms of a series of Process Areas or PAs • Process areas indicate the areas an organization should focus on to improve its software process. • Process areas identify the issues that must be addressed to achieve a maturity level. • Level 2 PAs are what you focus on when you are at level 1 • Level 3 PAs are what you focus on when you are at level 2 • And so forth.

18. Structure of PAs Key Process Areas Each process area identifies a cluster of related activities that, when performed collectively, achieve a set of goalsconsidered important for enhancing process capability. • Note that PAs are artificially associated with specific levels in the CMM • In actual fact, each PA evolves as an organization moves up the maturity scale

19. Continuous Model of CMMI • This is an alternative perspective that, instead of looking at maturity as a series of five levels (Staged model) looks, instead, at the maturity of each individual process area • This approach was originated in the systems engineering CMM, but is not as widely used as the Staged model

20. You are Level 3 Staged Model Scorecard Level 5 Maturity Level 4 Maturity Level 3 Maturity Level 2 Maturity Level 1 Maturity

21. Continuous Model Scorecard

22. PA Definition Process Areas Each PA is defined in terms of the following: • Goals - why you do it - what you hope to achieve • The goals signify the scope, boundaries, and intent of each key process area. • Generic goals apply to all PAs; specific goals apply to specific PAs • Practices (generic or specific) - what you (typically) do to achieve the goals • Infrastructure elements, such as policies or practices or resources • Activities, such as reviews or processes

23. Achievement of PAs Process Areas • Certain attributes indicate whether the implementationand institutionalizationof a process area are effective, repeatable, and lasting. • The attributes are: • Commitment to Perform • Ability to Perform • Activities Performed • Measurement and Analysis • Verifying Implementation

24. We WILL do this! Commitment to Perform Process Areas • Commitment to Perform describes the actions the organization must take to ensure that the process is established and will endure • Example: establishing a policy that mandates a particular activity Commitment to Perform typically involves establishing organizational policies and demonstrating senior management sponsorship.

25. Boss SEPG SW Manager Ability to Perform Process Areas • Ability to Perform describes the preconditions that must exist in the project or organization to implement the software process competently Ability to Perform typically involves resources, organizational structures, and training

26. Activities Performed Process Areas • Activities Performed describes the roles and procedures necessary to implement a key process area Activities Performed typically involve: -- Establishing plans and procedures, -- Performing the work, -- Tracking it, and -- Taking corrective actions as necessary

27. Measurement and Analysis Process Areas • Measurement and Analysis describes the need to measure the process and analyze the measurements Measurement and Analysis typically includes examples of the measurements that could be taken to determine the status and effectiveness of the activities performed.

28. Verifying Implementation Process Areas • Verifying Implementation describes the steps to ensure that the activities are performed in compliance with the process that has been established Verification typically encompasses reviews and audits by management and software quality assurance.

29. Practices Practices • The specific and generic practices describe "what" is to be done -- Example: a practice for risk management might be periodic evaluation of risks and the status of known risk areas • But they should not be interpreted as mandating "how" the goals should be achieved

30. Alternative Practices Practices • Alternative practices may accomplish the goals of the key process area • The key practices should be interpreted rationally to judge whether the goals of the key process area are effectively, although perhaps differently, achieved. Key Practice for Our Situation Key Practice per CMMI Example

31. Level 5 Maturity Level 4 Maturity Level 3 Maturity Level 2 Maturity Level 1 Maturity Reviewing the Five Levels for the Software Portion of the CMMI • The five levels correspond to Humphrey’s five levels (see text) • But the CMM and CMMI provide additional detail and many “best practices”

32. Level 5 Maturity Level 4 Maturity Level 3 Maturity Level 2 Maturity Level 1 Maturity Level 1- Initial • The software process is characterized as ad hoc, and occasionally even chaotic. • Few processes are defined, and success depends on individual effort (heroes). • Unstable environment is subject to catastrophe if key people leave • “Bus sensitive projects” • Planning is ineffective -- reaction is the order of the day • Plans are routinely ignored or abandoned “You can be very successful, but you cannot count on it.”

33. Level 5 Maturity Level 4 Maturity Level 3 Maturity Level 2 Maturity Level 1 Maturity Level 2 - Repeatable • Basic project management processes are established to track cost, schedule, and functionality. • The necessary process discipline is in place to repeat earlier successes on projects with similar applications. • Stability is present, even when heroes leave, so long as the overall environment is consistent • Everyone knows how to do it, although they do not always know why “You can expect consistent behavior.”

34. Process Areas for Level 2 • Configuration Management • Project Planning • Process & Product Quality Assurance • Requirements Management • Supplier Agreement Management (**) • Project Monitoring and Control (**) • (*) Measurement and Analysis (*) Was not in the CMM (**) Different Title in the CMM

35. Level 5 Maturity Level 4 Maturity Level 3 Maturity Level 2 Maturity Level 1 Maturity Level 3 - Defined • The process for both management and engineering activities is documented, standardized, and integrated into a standard process for the organization. • All projects use an approved, tailored version of the organization's standard process for developing and maintaining products. • People know why, not just how to do the job “You can expect stability in a changing environment.”

36. Process Areas for Level 3Part 1 – Similar to CMM • Organizational Process Focus • Organization Process Definition • Organizational Training • Integrated Project Management • Integrated Teaming • Organizational Environment for Integration • Technical Solution

37. Process Areas for Level 3Part 2 – New in CMMI (not found in CMM) • Requirements Development • Product Integration • Verification • Validation • Risk Management • Integrated Supplier Management • Decision Analysis and Resolution

38. Level 5 Maturity Level 4 Maturity Level 3 Maturity Level 2 Maturity Level 1 Maturity Level 4 – Quantitatively Managed • Detailed measures of the process and product quality are collected. • Both the process and products are quantitatively understood and controlled. • Decisions are based on fact • Process behavior is quantified • Processes are instrumented to facilitate data collection • Measurements are applied across the organization so that norms and exceptions can be identified

39. Process Areas for Level 4 • Quantitative Project Management -- Metrics are defined, collected, analyzed and acted upon to improve the project • Organizational Process performance -- Metrics are defined, collected, analyzed and acted upon to improve the process

40. Level 5 Maturity Level 4 Maturity Level 3 Maturity Level 2 Maturity Level 1 Maturity Level 5 - Optimizing • Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.

41. Process Areas for Level 5 • Causal Analysis and Resolution • You not only find defects, you correct or remove the process steps that cause them • Organizational Innovation and Deployment • You insert technology in an orderly and managed fashion • New methods and tools do not disrupt performance

42. Level 5 Maturity Level 4 Maturity Level 3 Maturity Level 2 Maturity Level 1 Maturity A Closer Look at a Few Parts of CMMI Level 2 • Configuration Management • Project Planning • Quality Assurance • Requirements Management • Supplier Agreement Management • Project Monitoring and Control • Measurement and Analysis

43. We Will Review Two of the PAs • Requirements Management and Supplier Agreement Managementhave not been discussed very much in the course up until now • So we will examine what the CMMI has to say about them • The other PAs have been discussed in the course, and are discussed further in other courses

44. Requirements Management TYPICAL SYMPTOMS • The product is “perfect,” but the customer doesn’t like it • Often because the developers “know what’s best for the customer” • Finger pointing • Multiple versions of the requirements • Multiple interpretations of the requirements • The system will not integrate • The parts do not fit together • Some functions are duplicated in software & hardware • Some functions are missing entirely

45. Requirements Management PA • Purpose: To establish a common understanding between the customer and the software project • Practices: • Reaching agreement on the requirements • Documenting the requirements • Controlling changes to the requirements • Communicating changes to the requirements • Allocating requirements - to software, hardware, etc. - in a clear, unambiguous manner

46. Requirements ManagementGoals I 1. System requirements allocated to software or other disciplines are controlled to establish a baseline • Requirements may come directly from the customer on a software-only project • Requirements may come from a system engineering function on a hardware & software project • “Controlled” means you don’t change without approval and communication

47. Requirements ManagementGoals II 2. Plans, products and activities are kept consistentwith the requirements • If you change the requirements, you must consider changing the plans, etc.

48. Sample Behaviors • System engineer or project lead: • Allocatesrequirements to all parts of the system • Don’t forget support, installation, documentation, etc. • Include platform selection, network configuration, and other tasks that are not part of software development • Controlsand communicates changes • May use a system configuration control board • Listens to understand the impact of changes

49. Sample Behaviors (continued) • Software manager: • Participatesin system configuration control process • Determines the impact of changes on software cost and schedule • Communicates the impact to affected parties (system engineers, customers, program managers, etc.)

50. Sample Behaviors (continued) • Software engineers: • Review requirements (and changes) • Communicatethe cost/impact of requirements/changes • For example, which modules need to be redesigned, recoded, retested, etc. • (This works best if the software engineer can document the estimated cost and schedule impact of each change.)