Convener: Houman Younessi

1. Software Engineering Management Course # CISH-6050 Lecture 3: Software Process Maturity - Part 2 Convener: Houman Younessi 05/21/2012

2. AGENDA … • Software Maturity Model: SEI SW-CMM • Systems Engineering Maturity Models: • SE-CMM • SECAM • SECM – EIA/IS 731 • Staged vs. Continuous Architecture 2

3. AGENDA … • Integrating SW and SE Maturity Models • - CMMI • - FAA-iCMM • - STRICOM – SAE-CMM 3

4. SEI Software CMM • The SEI Software Capability Maturity Model: SW-CMM • Best known Capability Maturity Model • Created by Carnegie Mellon Software Engineering Institute (CMU SEI) • Evolved out of Air Force challenge to find key set of questions to determine maturity about a company’s software processes • CMM V1.0 released 1991; V1.3 released 1993 4

5. SEI Software CMM … • The SEI SW-CMM: • Provides guidance for gaining control of software development processes • Helps identify gaps for organization to pursue process improvement for continuous & lasting gains in process capability • Follows a staged architecture • Improve a few key KPAs at a time • Receive new capability for the effort • Continue to improve additional KPAs 5

6. SEI Software CMM … • SW-CMM Maturity Levels • Well defined evolutionary plateau to achieve a mature software process • Each level is layer in foundation for continuous process improvement • Each level has set of process goals • At each step in maturity, a type of process capability is institutionalized by the organization • SW-CMM contains 5 levels 6

7. SEI Software CMM Levels 7

8. SEI Software CMM Levels … • Initial – Ad hoc software process; few processes defined; success = individual effort • Repeatable – Basic project management established to track cost, schedule & function • Defined – Software process is documented, standardized & integrated into organization • Managed – Detailed measures of software process & quality are collected & understood • Optimizing – Continuous process improvement 8

9. SEI Software CMM Measurements • Initial – Baseline measurements needed for starting point for measuring improvement • Repeatable – Project management metrics needed to identify project characteristics • Defined – Product measurements needed to control the product • Managed – Process measurement feedback from prior projects allows for better control • Optimizing – Process measurement feedback allow for process improvement 9

10. SEI Software CMM Levels Behavioral characteristics of each SW-CMM Level 10

11. SEI Software CMM Behaviors • Level 1 (Initial) • Organization does not provide stable environment for developing & maintaining software • During crisis, planned procedures abandoned & revert to code and test • Software process capability is unpredictable because the software process is ad hoc 11

12. SEI Software CMM Behaviors … • Level 2 (Repeatable) • Policies for managing a software project & procedures to implement those policies are established • Projects have installed basic software management controls 12

13. SEI Software CMM Behaviors … • Level 3 (Defined) • Standard process for developing & maintaining software across organization is documented & integrated into a coherent whole • Projects tailor the standard software process to develop their own defined software process 13

14. SEI Software CMM Behaviors … • Level 4 (Managed) • Organization sets quantitative quality goals for both software products and processes • Projects achieve control over products and processes by narrowing variation in process performance to fall within acceptable quantitative boundaries 14

15. SEI Software CMM Behaviors … • Level 5 (Optimizing) • Entire organization focused on process improvement • Software project teams analyze defects to determine their causes 15

16. SEI SW-CMM Internal Structure 16

17. SEI SW-CMM Key Process Areas • Key Process Areas (KPAs) • Each KPA describes cluster of activity that achieves goal for enhancing capability • 18 KPAs in total across the 5 CMM levels • All Goals of KPA must be achieved for organization to satisfy that KPA • 52 Goals across the 18 KPAs • Org has institutionalized process capability when those KPAs are done on continuing basis across projects 17

18. SEI SW-CMM Key Process Areas 18

19. SEI SW-CMM Key Process Areas … • Level 1- Initial • None • Level 2 – Repeatable • Requirements Management, 2 Goals • Software project planning, 3 Goals • Software project tracking, 3 Goals • Software subcontract mgmt, 4 Goals • Software Quality Assurance, 4 Goals • Software configuration mgmt, 4 Goals 19

20. SEI SW-CMM Key Process Areas … • Level 3 - Defined • Organizational process focus, 3 Goals • Organizational process def., 2 Goals • Training program, 3 Goals • Integrated software management, 2 Goals • Software product engineering, 2 Goals • Intergroup coordination, 3 Goals • Peer reviews, 2 Goals 20

21. SEI SW-CMM Key Process Areas … • Level 4 - Managed • Quantitative process mgmt., 3 Goals • Software quality management, 3 Goals • Level 5 – Optimizing • Defect prevention, 3 Goals • Technology change mgmt., 3 Goals • Process change management, 3 Goals 21

22. SEI SW-CMM Common Features • Common Features – Attributes that indicate implementation & institutionalization of key process area is effective, repeatable, & lasting: • Commitment to perform • Ability to perform • Activities performed • Measurement & analysis • Verifying implementation 22

23. Systems Engineering Maturity Models • SE-CMM • SECAM • SECM • – EIA/IS 731 23

24. Systems Engineering CMM • SE-CMM • December, 1993 work started on SE-CMM, based on SW-CMM • 8 Organizations collaborated to develop it • SEI provided admin oversight and published standards; other 7 groups provided Systems Engineering content • SE-CMM V1.0 released in 1994; 1996 V1.1 released • Uses “continuous” view architecture, derived from SPICE 24

25. Systems Engineering CMM … • SE-CMM Architecture • Support to assess & improve SE capability • Dual-path: domain and capability • Domain – essential, basic SE elements • Capability – process management elements • 5 Capability Levels, 11 Common Features, 26 Generic Practices • 3 Process Area Categories, with 18 Base Process Areas 25

26. SE-CMM Architecture 26

27. SE-CMM Process Categories 27

28. SE-CMM Capability Levels 28

29. SE Maturity Model - SECAM 29

30. SE Maturity Model - SECAM … • Systems Engineering Capability Assessment Model (SECAM) • Developed in 1992 by INCOSE • Developed from materials used by 4 companies to assess internal SE capabilities • V1.5 released in July, 1996 • Includes both model & assessment method • Uses “continuous” view architecture 30

31. SE Maturity Model SECM-EIA/IS 731 31

32. SECM – EIA/IS 731 … • Systems Engineering Capability Model (SECM) – EIA/IS 731 • January, 1999, EIA facilitated merger of SECAM and SE-CMM to be released as Interim Standard • Work done over 2 years on merged models • Review copy of SECM distributed at 1997 INCOSE symposium • Architecture “continuous” view • Includes both a model & appraisal method 32

33. Staged Architecture 33

34. Continuous View Architecture 34

35. Continuous Staged Models using Architecture SW-CMM, SA-CMM, People CMM SE-CMM, SECAM, EIA/IS 731, SPICE, SSE-CMM Created and owned by Mostly Non-SEI groups SEI Rating Each process area Organization as a whole Single Organization Rating? No Yes Prescribed order of implementation? No Yes Consistent with SPICE effort? Yes Yes -Higher level of granularity Advantages Flexibility, tailorability Stepwise guidance, standardization How to meet Level 4 Manage a process area by data Manage key processes by data Staged vs. Continuous View 35

36. Integrating SW & SE Models: CMMI • Capability Maturity Model-Integrated (CMMI) History: • Sponsored by Office of Secretary of Defense (OSD) and National Defense Industry (NDIA) in 1997 • Capitalizes on similarities of SE and SW process improvement models; eliminates differences between models • Addresses problem of organization having to use multiple capability models 36

37. CMMI – History … • Initial Mission to combine 3 source models: • SW-CMM V2.0, draft C • EIA/IS 731 – SECM • Integrated Product Development Capability Maturity Model (IPD-CMM) V0.98 • Draft released in August, 1999 • 2,500 change requests submitted from public review of CMMI 37

38. CMMI – History … • Initially thought creating CMMI would be as easy as combining 3 into one document, but that wasn’t the case • Most controversial decision – maintain two architectural models • Continuous View for EIA/IS 731 heritage and Staged architecture for SW-CMM users 38

39. CMMI – History … • The CMMI offers 3 versions released in December, 2000: • Software/Systems Engineering (SE/SW) • Integrated product & process development (SE/SW/IPPD) • Acquisitions (SE/SW/IPPD/A) 39

40. Is CMMI Ready for General Use? • Bill Pierce article in Cross Talk – July, 2000: “Is CMMI Ready for Prime Time?” • Pilot conducted in 1999 using CMMI SE/SW V0.2b • Two “all-star” teams included in pilot • Teams reviewed data independently and drafted findings • Findings from both teams identical 40

41. CMMI Pilot Assessment Results • CMMI meant for large organizations • SE-CMM criticized for applying to large orgs with million $ projects • Small companies had to be convinced that SE-CMM could work for them • Some roots of CMMI process areas based on large bidder/source selection for gov’t • CMMI appears to insist upon large bureaucracy to manage these activities 41

42. CMMI Pilot Assessment Results … • Large number of process areas and practices • 437 practices in CMMI • SW-CMM criticized for having too many practices; CMMI has more • Org’s starting process improvement will need to focus on small number of process areas that provide measurable payback 42

43. CMMI Pilot Assessment Results … • What to do, not How to do it • SW-CMM is framework for process, not description of process (i.e. what to do, not how to do it) • CMMI takes step backwards from other CMMs to prescribe how to do it versus what to do • Example: describes approach to mitigate risk 43

44. CMMI Pilot Assessment Results … • Merged vs. Integrated Model • CMMI is really a merged model, rather than completely integrated model • Overlap between process areas • SW processes written like SW-CMM • SE process areas written like EIA/IS 731 44

45. CMMI Pilot Assessment Results … • Capability Assessments using CMMI • CMM based assessments allow for ruling KPAs as non-applicable • SCAMPI method in CMMI doesn’t allow for non-applicable, but rather rules Process Area as out of scope • Some Process Areas in CMMI are difficult for assessment team to evaluate 45

46. CMMI Pilot Assessment Results … • Pilot Assessment Summary (July, 2000) • If customer mandates org to adopt CMMI, they should do it • If org after benefit of process improvement, maybe wait for further improvements • Major DOD suppliers should pursue CMMI • Smaller companies may want to wait for CMMI improvements 46

47. CMMI Tech. Transition Workshop • SEI sponsored Technology Transition Workshop in May, 2001 • Supports management of technology transition • Captured feedback from adopters of the CMMI product suite • 73 Prioritized recommendations on what works, what doesn’t work, and what’s needed for an org to transition to CMMI 47

48. CMMI Tech. Transition Workshop … • Survey sent to participants prior to workshop: • Org size ranged from 2 to 72,000 employees; avg org size 3,369 • 43% stated already decided to adopt CMMI • Addresses common model • Required by customers • Provided competitive edge 48

49. CMMI Tech. Transition Workshop … • Migrating from other models: • SW-CMM • ISO9000 • ISO/IEC 12207 • SE-CMM • Early CMMI versions • Duration estimated at 18 to 88 person months • Not yet decided on Continuous vs. Staged 49

50. CMMI Tech. Transition Workshop … • Organizations participating in workshop must have already started CMMI transition from another CMM or adopting CMMI with no prior CMM background • Varied backgrounds, including Dept. of Defense, Commercial, and Transition Partner Domains • Workshop provide attendees with fundamentals about complexity of technology adoption 50