Software technology 3. Process improvement models. BSc Course Dr. Katalin Balla

Transcription

1 Software technology 3. Process improvement models BSc Course Dr. Katalin Balla

2 Contents Process improvement models. Popular SPI models: CMM, SPICE, CMMI The Personal Software Process (PSP) and the Team Software Process (TSP) Process improvement in the Agile environment 10/31/2017 Balla K. 2

3 Maturity models Principles: Crosby (1979), Juran (1988), Deming (1986), Humphrey (1989) It became obvious already in the 1980 s that Some organizations are more mature than others Some software processes are more mature than others Look to the organization or its certain aspects based on certain criteria The organizations are classified to be on certain maturity levels based on the characteristics of the assessed processes / characteristics 10/31/2017 Balla K. 3

4 Maturity of software processes Maturity of the software process: The degree to which a process is defined, monitored, measured, controlled and efficient. [Paulk]. Software process maturity may show whether a process is able to developed a good quality product, while honoring its cost and schedule constraints. A mature software process is: Defined, monitored, measured, controlled, efficient and able to improve. 10/31/2017 Balla K. 4

5 Maturity and capability Nowadays we talk about Organization maturity Process capability The two notions interrelate: organizations are the more mature, the more processes they have in place that are of a high capability-level CMM = Capability Maturity Model CMMI = Capability Maturity Model Integration 10/31/2017 Balla K. 5

6 Capability Maturity Models (1/2.) Have a well defined structure. They concentrate on certain elements of software production. Verification models have been developed, that ensure the auditability of the maturity models. (eg. SCAMPI, Bootstrap ) 10/31/2017 Balla K. 6

7 Capability Maturity Models (2/2.) Staged models Look to the entire organization Deal with managerial and technical processes, the technology used, the organization itself Continuous models Define capability levels for certain processes (not for the entire organization), according to different characteristics The user of the model can decide about the process for which capability will be checked Combined, integrated models Combine the two approaches, making use of the most useful elements Same processes, 2 ways of looking at them 10/31/2017 Balla K. 7

8 Staged models: CMM Capability Maturity Model for Software Was developed between leader: Watts Humphrey Version 1: 10/31/2017 Balla K. 8

9 5 4 Quantitative feedback used for improvement Quantitative assurance of efficiency, effectiveness and quality Process change management Technology change management Error prevention Software quality management Quantitative process management Improvement of productivity and reducing cycle time Improvement of productivity and reducing cycle time control 3 Most efficient methods are documented and used in every project Peer reviews Intergroup coordination Software product development Integrated software management Training plan Organisational process definition Organisational process focus Important improvement of product quality 2 Existance of efficient procedures Software configuration management Software quality assurance Software subcontract management Software project tracking and oversight Software project planning Requirements management Project planning and tracking is adequate 1 Projects usually overrun time and cost limits risk 10/31/2017 Balla K. 9

10 CMM maturity profile Process Change Management Technology Change Management Defect prevention Software Quality Management Quantitative Process Management Peer Reviews Intergroup Coordination Software Product Engineering Integrated Software Management Training Program Organisational Process Definition Organisational Process Focus Software configuration management Software quality assurance Software subcontract management Software project tracking & oversight Software project planning Requirements management Level 5, Optimising Level 4, Managed Level 3, Defined Level 2, Repeatable NA X Fully Satisfied Partially Satisfied Not Satisfied Not Applicable Not Rated 10/31/2017 Balla K. 10

11 Results of applying CMM model : 4110 projects, : companies szint: 27.1 % 19.3 % 13.3% 9.6% 2 szint: 39.1 % 43.2 % 43.5% 42.6% 3 szint: 23.4 % 23.4% 25.6% 30.1% 4 szint: 5.4 % 7.3% 8.5% 8.1% 5 szint: 4.8 % 6.8% 9.2% 9.6% 10/31/2017 Balla K. 11

12 Continuous models: SPICE Software Process Improvement and Capability determination An international collaborative effort to develop a standard It has been underway (unofficially) since 1990 and officially since June of 1993 Refers to the individual processes of an organization 10/31/2017 Balla K. 12

13 What is ISO 15504? ISO/IEC TR is the result of SPICE project International standard for Software Process Assessment. First published in 1998 as a Technical Report Type 2. ISO/IEC TR is re-published as ISO/IEC during 2003/2006, and parts added in the years of 2010 ISO/IEC (as a standards set) is currently (2017) under revision and being published as the 330xx series of standards. ISO/IEC 33001:2015 is a revision of ISO/IEC The ISO/IEC 330xx family of standards is intended to supersede the ISO/IEC 155xx family. 10/31/2017 Balla K. 13

14 The SPICE User Group ( Non profit membership organization, with free individual membership. 10/31/2017 Balla K. 14

15 SPICE capability levels 5. Optimizing (Continuously-Improving) level 4. Predictable (Quantitatively-controlled) level 3. Established (Well-defined) level 2. Managed (Planned-and-tracked) level 1. Performed ( informally) level 0. Incomplete (Not performed) level 10/31/2017 Balla K. 15

16 Process capability Processes Process capability levels 5. Optimizing 3. Established 4. Predictable Customer-supplier Engineering Project Support Organization 1. Performed 0. Incomplete 2. Managed 10/31/2017 Balla K. 16

17 Process dimension Processes - Initially: software life cycle processes taken from ISO ISO/IEC 12207:1995 Information technology -- Software life cycle processes ISO/IEC 12207:1995/Amd 1:2002 ISO/IEC TR 15271:1998 Information technology -- Guide for ISO/IEC (Software Life Cycle Processes) ISO/IEC TR 16326:1999 Software engineering -- Guide for the application of ISO/IEC to project management 10/31/2017 Balla K. 17

18 Process dimension - as in September 2017 ISO/IEC Standard for Information Technology - Software Life Cycle Processes (Stabilized: ) ISO/IEC 12207: Systems and software engineering -- Software life cycle processes ISO/IEC/IEEE : Software and systems engineering -- Software testing -- Part 1: Concepts and definitions ISO/IEC/IEEE : Software and systems engineering -- Software testing -- Part 3: Test documentation ISO/IEC/IEEE 24765:2010 Systems and software engineering -- Vocabulary ISO/IEC 25010: Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models ISO/IEC 25000:2014 Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE 10/31/2017 Balla K. 18

19 Software life cycle processes According to ISO 12207, the following processes are possible to execute during software life cycle (already discussed in Lecture 2): 10/31/2017 Balla K. 19

20 SPICE process dimension (3/6.) The individual processes are described in terms of six components: Process Identifier This identifies the process category and the sequential number within that category. The numbering scheme distinguishes between top-level processes and second-level processes. The identifier consists of two parts: a process category abbreviation Process Name A descriptive phrase that encapsulates the principal concern of the process (e.g. Supplier Selection). 10/31/2017 Balla K. 20

21 SPICE process dimension (4/6.) Process Types: 3 top-level and 2 second-level, and these are as follows: 1.Basic Processes identical in intent to the processes in ISO/IEC 12207; 2.Extended Processes that are expansions of ISO/IEC processes; 3.New Processes that are outside the scope of ISO/IEC 12207; 4.Component Processes (a group of one or more ISO/IEC s activities from the same process); 5.Extended Component Processes that are one or more of ISO/IEC s activities from the same process, with additional material. These would normally be Component Processes of Extended Processes. 10/31/2017 Balla K. 21

22 SPICE capability dimension Generic practices are used to determine process capability. If a process is on a certain level of capability, the generic practices associated to that maturity level should be there. If a process is on a certain capability level, it must satisfy certain goals and must produce certain deliverables. 10/31/2017 Balla K. 22

23 SPICE capability levels Level 0: Incomplete. There is general failure to attain the purpose of the process. There are few or no easily identifiable work products or outputs of the process. Level 1: Performed. The purpose of the process is generally achieved. The achievement may not be rigorously planned and tracked. Individuals within the organization recognize that an action should be performed, and there is general agreement that this action is performed as and when required. There are identifiable work products for the process, and these testify to the achievement of the purpose. 10/31/2017 Balla K. 23

24 SPICE capability levels Level 2: Managed. The process delivers work products according to specified procedures and is planned and tracked. Work products conform to specified standards and requirements. The primary distinction from the Performed Level is that the performance of the process now delivers work products that fulfill expressed quality requirements within defined timescales and resource needs. 10/31/2017 Balla K. 24

25 SPICE capability levels Level 3: Established. The process is performed and managed using a defined process based upon good software engineering principles. Individual implementations of the process use approved, tailored versions of standard, documented processes to achieve the process outcomes. The resources necessary to establish the process definition are also in place. The primary distinction from the Managed Level is that the process of the Established Level is using a defined process that is capable of achieving its process outcomes. 10/31/2017 Balla K. 25

26 SPICE capability levels Level 4: Predictable. The defined process is performed consistently in practice within defined control limits, to achieve its defined process goals. Detailed measures of performance are collected and analyzed. This leads to a quantitative understanding of process capability and an improved ability to predict and manage performance. Performance is quantitatively managed. The quality of work products is quantitatively known. The primary distinction from the Established Level is that the defined process is now performed consistently within defined limits to achieve its process outcomes. 10/31/2017 Balla K. 26

27 SPICE capability levels Level 5: Optimizing. Performance of the process is optimized to meet current and future business needs, and the process achieves repeatability in meeting its defined business goals. Quantitative process effectiveness and efficiency goals (targets) for performance are established, based on the business goals of the organization. Continuous process monitoring against these goals is enabled by obtaining quantitative feedback and improvement is achieved by analysis of the results. Optimizing a process involves piloting innovative ideas and technologies and changing non-effective processes to meet defined goals or objectives. The primary distinction from the Predictable Level is that the defined and standard processes now dynamically change and adapt to effectively meet current and future business goals. 10/31/2017 Balla K. 27

28 SPICE assessment There are three important elements that are needed for conducting an assessment: An Assessment Model An Assessment Method One or more Competent Assessors 10/31/2017 Balla K. 28

29 SPICE assessment An Assessment Model An Assessment Method One or more Competent Assessors ISO/IEC TR defines a set of requirements for an Assessment Model and an Assessment Method in the normative parts of the document set (parts 2 and 3 respectively). An assessment that meets these requirements is referred to as a conformant assessment. There are a number of organizations that provide public or commercial assessment methods that are claimed to meet the method requirements defined by ISO/IEC TR /31/2017 Balla K. 29

30 SPICE assessment Working method Choosing the processes Questionnaires Interviews Report Process improvement plan (Registration in database) Assessment results: capability profile for the chosen processes. SPI plan is an important result of the assessment 10/31/2017 Balla K. 30

31 SPICE assessment Ratings Process attribute rating scale A process attribute represents a measurable characteristic of any process as defined above. The rating scale is a percentage scale from zero to one hundred percent that represents the extent of achievement of the attribute. Each process attribute assessed in an organizational unit, up to and including the highest capability level defined in the assessment scope, shall be accorded a rating using the attribute scale defined above. 10/31/2017 Balla K. 31

32 SPICE assessment Process attribute rating scale calibration: The ordinal rating scale defined below shall be used to calibrate the levels of achievement of the defined capability of the process attributes. N Not achieved: 0% to 15% - There is little or no evidence of achievement of the defined attribute in the assessed process. P Partially achieved: 16% to 50% - There is evidence of a sound systematic approach to and achievement of the defined attribute in the assessed process. Some aspects of achievement may be unpredictable. L Largely achieved: 51% to 85% - There is evidence of a sound systematic approach to and significant achievement of the defined attribute in the assessed process. Performance of the process may vary in some areas or work units. F Fully achieved: 86% to 100% - There is evidence of a complete and systematic approach to and full achievement of the defined attribute in the assessed process. No significant weaknesses exist across the defined organizational unit. 10/31/2017 Balla K. 32

33 SPICE assessment Capability levels 5. Optimising Processes 4. Predictable 3. Established 2. Managed 1. Performed 0. Not performed P1 P2 P3 10/31/2017 Balla K. 33

34 SPICE - profile Process Requirement management Supplier management Process capability A Requirement analysis Planning Coding Testing 10/31/2017 Balla K. 34

35 Taking into account basic drivers - example Process Business drivers Effect Capability level Time dependence Product quality Service quality Costs Weig ht Project management ,2 2 Quality assurance ,2 1 Configuration ,8 1 management Risk management ,0 1 Subcontractor ,8 2 management Testing ,8 1 Integration ,5 1 Importance: 1-3 effect= time dependence x 30 + product qual x 30 + process qual x 20 + cost x /31/2017 Balla K. 35

36 Choosing development direction Capability level Areas for improvement Effect 10/31/2017 Balla K. 36

37 Specific SPICE models 10/31/2017 Balla K. 37

38 An integrated model: CMMI Capability Maturity Model Integration CMMI v CMMI for Development, Version 1.3, CMMI-DEV, V1.3 Improving processes for developing better products and services November 2010, TECHNICAL REPORT Now (2017 autumn): version 1.3 Version 2 on its way, will be made public in First version: Capability Maturity Model Integration, Version 1.1.Continuous representation. Staged representation. December Internet: 10/31/2017 Balla K. 38

39 CMMI 10/31/2017 Balla K. 39

40 Elements of CMMI Goal Introduction Related PA s PA Goals SG GG Practices SP GP Example work products Subpractices Subpractices Elaborations Exp: Mandatory Informative Expected Examples, Notes Additions References 10/31/2017 Balla K. 40

41 A CMMI model components Pictures are taken from the model description, available on CMMI Institute web page. 10/31/2017 Balla K. 41

42 CMMI representations 10/31/2017 Balla K. 42

43 CMMI elements Levels Maturity Level 1 Initial 2 Managed 3 Defined Staged Representation Maturity Levels 4 Quantitatively Managed 5 Optimizing Capability Continuous Level Representation Capability Levels 0 Incomplete 1 Performed 2 Managed 3 Defined 43 10/31/2017 Balla K. 43

44 Maturity levels Maturity Level 5 Optimizing 4 Quantitatively managed 3 Defined 2 Managed 1 Initial 0 none 10/31/2017 Balla K. 44

45 A CMMI framework and constellations Constellations describe specific aspects of a certain area Development DEV, Acquisition ACQ, Services SVC. Shared material Constellation-specific material 10/31/2017 Balla K. 45

46 CMMI constellations 10/31/2017 Balla K. 46

47 Processes of the CMMI model 1. Product Integration (PI) 2. Requirements Development (RD) 3. Supplier Agreement Management (SAM) 4. Technical Solution (TS) 5. Validation (VAL) 6. Verification (VER) 1. Causal Analysis and Resolution (CAR) 2. Configuration Management (CM) 3. Decision Analysis and Resolution (DAR) 4. Integrated Project Management (IPM) 5. Measurement and Analysis (M&A) 6. Organizational Performance Management (OPM) 7. Organizational Process Definition (OPD) 8. Organizational Process Focus (OPF) 9. Organizational Process Performance (OPP) 10. Organizational Training (OT) 11. Project Monitoring and Control (PMC) 12. Project Planning (PP) 13. Process and Product Quality Assurance (PPQA) 14. Quantitative Project Management (QPM) 15. Requirements Management (REQM) 16. Risk Management (RSKM)

48 CMMI model A CMMI and its constellations 10/31/2017 Balla K. 48

49 10/31/2017 Balla K. 49

50 Elements of CMMI description Example: SAM Mandatory Expected Informative 10/31/2017 Balla K. 50

51 Elements of CMMI description Example: SAM elements Mandatory Informative Expected 10/31/2017 Balla K. 51

52 Example: Supplier Agreement Management (SAM) The purpose of SAM is to manage the acquisition of products and services from suppliers. The Supplier Agreement Management process area involves the following activities: Determining the type of acquisition Selecting suppliers Establishing and maintaining agreements with suppliers Executing supplier agreements Accepting delivery of acquired products Ensuring successful transition of acquired products 10/31/2017 Balla K. 52

53 Example: Supplier Agreement Management (SAM) SG 1 Establish Supplier Agreements SP 1.1Determine Acquisition Type SP 1.2Select Suppliers SP 1.3Establish Supplier Agreements SG 2 Satisfy Supplier Agreements SP 2.1Execute the Supplier Agreement SP 2.2Accept the Acquired Product SP 2.3Ensure Transition of Products 10/31/2017 Balla K. 53

54 Generic goals and practices GG (1/3) GG 1 Achieve Specific Goals The specific goals of the process area are supported by the process by transforming identifiable input work products into identifiable output work products. GP 1.1 Perform Specific Practices Perform the specific practices of the process area to develop work products and provide services to achieve the specific goals of the process area. Such a process is at Capability Level 1 (CL1) 10/31/2017 Balla K. 54

55 GG s (2/3) GG 2 Institutionalize a Managed Process The process is institutionalized as a managed process. GP 2.1 GP 2.2 GP2.3 GP2.4 GP2.5 GP2.6 GP 2.7 GP 2.8 GP 2.9 Establish an Organizational Policy Plan the Process Provide resources Assign responsibility Train people Control work products Identify and Involve Relevant Stakeholders Monitor and Control the Process Objectively Evaluate Adherence GP 2.10 Review Status with Higher Level Management Such a process is at Capability Level 2 (CL2) 10/31/2017 Balla K. 55

56 GGs (3/3) 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 process. GP 3.2 Collect Process Related Experiences Collect process related experiences derived from planning and performing the process to support the future use and improvement of the organization s processes and process assets. Such a process is at Capability Level 3 (CL3) 10/31/2017 Balla K. 56

57 Process area categories in CMMI Process Management Project Management Supporting Engineering SE processes / Life cycle models will (most probably) be described here! 10/31/2017 Balla K. 57

58 CMMI-DEV : Maturity levels and Process Areas REQM PP PMC SAM CM MA PPQA OPD OPF OT IPM RSKM RD TS VAL PI VER DAR OPP QPM OPM CAR 10/31/2017 Balla K. 58

59 CMMI target profile and equivalent staging 10/31/2017 Balla K. 59

60 Nota Bene The process areas of CMMI-DEV are basically those appearing in Software Engineering The relationship might not be exactly 1:1 VER, VAL, PI = testing TS = Design and coding However CMMI reflects a wide, common understanding of processes related to Software Engineering CMMI versions showed a continuous evolution (eg. Agile practices explicitly mentioned ) CMMI tries to integrate knowledge from other models as well (mentions ISO 9126, ISO 9001 etc.) CMMI made use of process descriptions within the model, and shared feedback for more than 15 years Therefore we make use of ideas described in CMMI while presenting the processes of Software Engineering in the following lectures. We made this decision, being conscious about the fact that we cannot present everything connected to every process area, while other approaches are as good as the ones we present. 10/31/2017 Balla K. 60

61 Auditing CMMI: SCAMPI 10/31/2017 Balla K. 61

62 CMMI appraisals SCAMPI method Standard CMMI Appraisal Method for Process Improvement (SCAMPI) Version 1.3b: Method Definition Document for SCAMPI A,B, and C 10/31/2017 Balla K. 62

63 CMMI appraisals Requirements for different SCAMPI appraisals Requirements SCAMPI class A SCAMPI class B SCAMPI class C Needed objective evidence Documents and interviews Documents and interviews Documents OR interviews Rating Organizational coverage Minimum size of audit team Rating goals mandatory Not allowed Not allowed Needed Not needed Not needed Person leading the appraisal Lead Appraiser Trained and experienced person Trained and experienced person SEE Lecture 10 for further details about auditing! 10/31/2017 Balla K. 63 / 29

64 Difficult to understand for CMMI users (Top 5 - based on own experience) Planning and monitoring activities different from engineering ones CM for things different from code Data management often confused with CM IPM as a whole (often argued that if PP, PMC is done for all projects, IPM results so, e.g. no process description is needed) GP-s, mainly planning of PP and PMC, measurement on measurement, CM on CM, relevant stakeholders for PA-s 10/31/2017 Balla K. 64

65 Experience with using CMMI model in Hungary PA degree of conformity to CMMI requirements, according to SQI informal and formal appraisals 10/31/2017 Balla K. 65

66 Some statistics Weaknesses and notes referring to CMMI ML2 PA-s (based on 9 SCAMPI A-s, all weaknesses+notes = 100%, ) SAM 6% PPQA 4% Most of weaknesses refer to "maintain bidirectional traceability". REQM 9% PP 30% Measurementhaslittlefeedback. More PA-s measured"together". MA 20% PMC 10% Most weaknesses are inconnectionwithpp and PMC. Configuration management, and mainly configuration audits is sometimes formal for work products different from code. CM 21% 10/31/2017 Balla K. 66

67 Some statistics Weaknesses and notes referring to CMMI ML3 PA-s (Excl. SAM, 8 SCAMPI A-s, All weaknesses + notes = 100%) OPD 12% OPF 11% MA 9% PMC 5% OT 5% IPM 12% CM 12% 3 PA-s out of 17 PA-s 3 have 41% of all weaknesses and notes (PP+PMC+IPM) PP 14% REQM DAR RD VAL VER RSKM TS PPQA PI 10/31/2017 Balla K

68 Some statistics RD, REQM 14% Strengths for ML3 PA-s (9 SCAMPI A-s, total nr. of strengths=100%) "Other" more detailed PMC 14% TS: 14% IPM 14% Other 36% CM, PI, OT: 21% PP 22% Other PA-s 10/31/2017 Balla K. 68

69 Some statistics Average of ML2 PA SP-conformity for pre-appraisals (15 pre-appraisals, PA SP conformity = 100%) 87% 83% 94% 76% 78% 95% 87% PP PMC CM MA REQM SAM PPQA 10/31/2017 Balla K. 69 #

70 CMMI appraisal data /31/2017 Balla K. 70

71 10/31/2017 Balla K. 71 / 29

72 10/31/2017 Balla K. 72 / 29

73 10/31/2017 Balla K. 73 / 29

74 10/31/2017 Balla K. 74 / 29

75 TMMi Based on CMMI, a model for test process improvement was developed: TMMi 10/31/2017 Balla K. 75

76 Other SPI models Personal Software Process (PSP) Watts Humphrey, 1995 Based on CMM principles Shows engineers how to manage the quality of their projects make commitments they can meet improve estimating and planning reduce defects in their products 10/31/2017 Balla K. 76

77 PSP Because personnel costs constitute 70 percent of the cost of software development, the skills and work habits of engineers largely determine the results of the software development process. Based on practices found in the Capability Maturity Model (CMM), the PSP can be used by engineers as a guide to a disciplined and structured approach to developing software. The PSP is a prerequisite for an organization planning to introduce the TSP. The PSP can be applied to many parts of the software development (Watts Humphrey: 1. A Discipline for software engineering. Addison-Wesley, Using a Defined and Measured Personal Software Process. In: IEEE Software, May 1996, pp What is your life depended on software? EuroSPI 2000, Copenhaga, 7. November 2000.) 10/31/2017 Balla K. 77

78 PSP Personal development process Personal measurement Personal planning Personal quality Calibrating phases 1. planning 2. designing 3. coding 4. compiling 5. testing 6. post mortem +1 Assessing the programmer s work, aided by forms Training 10/31/2017 Balla K. 78

79 CMM(I) and PSP CMM(I) Refers to the organisation Is a framework in which high quality sw development can be executed Framework for SPI Assumes that the developers use efficient methods and do process improvement PSP Refers to the individual It assumes that there is a well organised framework in which the individual activities are executed The infrastructure for supporting sw development exists. 10/31/2017 Balla K. 79

80 Other SPI models Team Software Process (TSP) After 1998, Watts Humphrey, SEI Refers to the work of software development teams Is related to CMM and PSP ( 10/31/2017 Balla K. 80

81 TSP TSP along with PSP, helps the high-performance engineer to ensure quality software products create secure software products improve process management in an organization Engineering groups use the TSP to apply integrated team concepts to the development of software-intensive systems. A four-day launch process walks teams and their managers through establishing goals defining team roles assessing risks producing a team plan 10/31/2017 Balla K. 81

82 TSP After the launch, the TSP provides a defined process framework for managing, tracking and reporting the team's progress. Using TSP, an organization can build selfdirected teams that plan and track their work, establish goals, and own their processes and plans. These can be pure software teams or integrated product teams of 3 to 20 engineers. 10/31/2017 Balla K. 82

83 TSP Before TSP training, developers must take part in PSP training Teams using TSP: 3-20 members Dealing exclusively with software development 10/31/2017 Balla K. 83

84 Why does this worth it? 10/31/2017 Balla K. 84

85 Tools for PSP and TSP /31/2017 Balla K. 85

86 IDEAL The IDEAL model is an organizational improvement model that serves as a roadmap for initiating, planning, and implementing improvement actions. The IDEAL model is named for the five phases it describes: initiating, diagnosing, establishing, acting, and learning. model.pdf 10/31/2017 Balla K. 86

87 SPI models and agile All presented models in their new versions- show how they can be applied in the agile environment Eg. CMMI has descriptions about how the different practices are understood in the agile environment TMMi has an agile addendum 10/31/2017 Balla K. 87

88 Process improvement in the agile way Process improvement in an organization that work in an agile way Doing process improvement activities in an agile way Experience needed! Interesting job! m-and-continous-process-improvement-(1) 10/31/2017 Balla K. 88

89 SPI approaches 10/31/2017 Balla K. 89

90 What we talked about Process improvement models. Popular SPI models: CMM, SPICE, CMMI The Personal Software Process (PSP) and the Team Software Process (TSP) Process improvement in the Agile environment 10/31/2017 Balla K. 90