Handouts Software Testing and Quality Assurance Theory and Practice Chapter 18 Maturity Models ------------------------------------------------------------------

Slides:



Advertisements
Similar presentations
More CMM Part Two : Details.
Advertisements

INFO 631 Prof. Glenn Booker Week 5 – Quality Assessment & Process Improvement 1INFO631 Week 5.
Chapter 2 The Software Process
©2006 OLC 1 Process Management: The Foundation for Achieving Organizational Excellence Process Management Implementation Worldwide.
CPIS 357 Software Quality & Testing I.Rehab Bahaaddin Ashary Faculty of Computing and Information Technology Information Systems Department Fall 2010.
Software Development Process Models. The Waterfall Development Model.
R R R CSE870: Advanced Software Engineering (Cheng): Intro to Software Engineering1 Advanced Software Engineering Dr. Cheng Overview of Software Engineering.
SE 470 Software Development Processes James Nowotarski 12 May 2003.
Computer Engineering 203 R Smith Process/Plan Model 7/ Development Process Models Development Process Models are different ways to look at the processes.
CMM Overview - 1 © Paul Sorenson CMPUT Software Engineering refs. IEEE Software, March 1988, 73-79, and IEEE Software, July 1993, (Capability.
Chapter 3 The Structure of the CMM
CMMI Overview Quality Frameworks.
Software Process CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology December 17, 2002.
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 17 Software Quality
Capability Maturity Model
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 18 Maturity Models
Chapter : Software Process
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 17 Software Quality
S T A M © 2000, KPA Ltd. Software Trouble Assessment Matrix Software Trouble Assessment Matrix *This presentation is extracted from SOFTWARE PROCESS QUALITY:
Integrated Capability Maturity Model (CMMI)
UNIT-II Chapter : Software Quality Assurance(SQA)
Chapter 2 The process Process, Methods, and Tools
CLEANROOM SOFTWARE ENGINEERING.
N By: Md Rezaul Huda Reza n
1 Chapter 2 The Process. 2 Process  What is it?  Who does it?  Why is it important?  What are the steps?  What is the work product?  How to ensure.
J. R. Burns, Texas Tech University Capability Maturity Model -- CMM n Developed by the Software Engineering Institute (SEI) in 1989 –SEI is a spinoff.
CMMi What is CMMi? Basic terms Levels Common Features Assessment process List of KPAs for each level.
OHT 23.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 The benefits of use of standards The organizations involved in standards.
Introduction to Software Engineering LECTURE 2 By Umm-e-Laila 1Compiled by: Umm-e-Laila.
S Q A.
Chapter 2 Process: A Generic View
Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITHClass of 39 CS3600: Software Engineering: Standards in Process Modeling CMM and PSP.
Capability Maturity Models Software Engineering Institute (supported by DoD) The problems of software development are mainly caused by poor process management.
Software Engineering Lecture # 17
Software process improvement Framework for SPI SPI support groups, maturity and immaturity models Assessment and gap analysis Education and training Selection.
Software Engineering Principles Principles form the basis of methods, techniques, methodologies and tools Principles form the basis of methods, techniques,
Quality Concepts within CMM and PMI G.C.Reddy
Lecture Topics covered CMMI- - Continuous model -Staged model PROCESS PATTERNS- -Generic Process pattern elements.
Georgia Institute of Technology CS 4320 Fall 2003.
SWEN 5130 Requirements Engineering 1 Dr Jim Helm SWEN 5130 Requirements Engineering Requirements Management Under the CMM.
Software Engineering - I
CMMI. 1.Initial - The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual.
Ch-1 Introduction The processes used for executing a software project have major effect on quality of s/w produced and productivity achieved in project…
Level 1 Level 1 – Initial: The software process is characterized as ad hoc and occasionally even chaotic. Few processes are defined, and success depends.
Purpose: The purpose of CMM Integration is to provide guidance for improving your organization’s processes and your ability to manage the development,
SOFTWARE PROCESS IMPROVEMENT
Software Engineering (CSI 321) Software Process: A Generic View 1.
COMPGZ07 Project Management CMMI Project Planning Lecture 5b Graham Collins, UCL.
UNIT 5.
SE513 Software Quality Assurance Lecture12: Software Reliability and Quality Management Standards.
CMMI Overview Quality Frameworks. Slide 2 of 146 Outline Introduction High level overview of CMMI Questions and comments.
Cmpe 589 Spring Fundamental Process and Process Management Concepts Process –the people, methods, and tools used to produce software products. –Improving.
PROCESS ASSESSMENT AND IMPROVEMENT. Process Assessment  A formal assessment did not seem financially feasible at the onset of the company’s process improvement.
MIS Project Management Instructor: Sihem Smida Project Man agent 3Future Managers1.
Capability Maturity Model. What is CMM? n CMM: Capability Maturity Model n Developed by the Software Engineering Institute of the Carnegie Mellon University.
CS4311 Spring 2011 Process Improvement Dr
Identify the Risk of Not Doing BA
CMMI Overview Quality Frameworks.
TechStambha PMP Certification Training
Software Testing and Quality Assurance
Level 1 Level 1 – Initial: The software process is characterized as ad hoc and occasionally even chaotic. Few processes are defined, and success depends.
CMMI Overview.
Quality management standards
Software Quality Assurance
Software Engineering: A Practitioner’s Approach, 6/e Chapter 2 Process: A Generic View copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
Software Engineering Lecture 16.
Software Engineering I
Capability Maturity Model
Chapter # 8 Quality Management Standards
Capability Maturity Model
Presentation transcript:

Handouts Software Testing and Quality Assurance Theory and Practice Chapter 18 Maturity Models ------------------------------------------------------------------ ------------------------------------------------------------------- -------------------------------------------------------------------- 1

Outline of the Chapter Basic Idea in Software Process Capability Maturity Model (CMM) Test Process Improvement (TPI) Testing Maturity Model (TMM) Summary

Basic Idea in Software Process A process comprises a set of activities that are executed to develop products. The activities find expressions in the form of methods, techniques, strategies, procedures, and practices. The activities heavily rely on information repositories, such as documents, standards, and policies. Different processes are driven by different goals and availability of resources. It is useful to follow a defined process because of the following benefits. The process can be repeated in subsequent projects. The process can be evaluated by using a variety of metrics, such as cost, quality, and time to deliver. Actions can be taken to improve the process to achieve better results.

Basic Idea in Software Process A software process comprises the following tasks. Gathering requirements Constructing a functional specification Designing the system Writing code Testing the system Maintaining the system

Basic Idea in Software Process Software testing is treated as a distinct process because it involves a variety of unique activities, techniques, strategies, and policies. Testing is performed to reveal defects and show to what extent the software possesses different quality attributes, such as reliability and performance. Testing begins almost at the same time a project is conceptualized. Testing is carried out by different people at different stages of system development. A number of different techniques can be applied at each level of testing. A number of different strategies can be applied at each level of testing. A number of metrics can be monitored to gauge the progress of testing. Testing is influenced by organizational policies. Testing can be performed as a combination of manual and automated modes of execution of test cases.

Basic Idea in Software Process To be able to improve a defined process, organizations need to evaluate its capabilities and limitations. Example: The Capability Maturity Model (CMM) allows an organization to evaluate its software development processes. The CMM model supports incremental process improvement. A separate model, known as the Testing Maturity Model (TMM), has been developed to evaluate a testing process. For an organization to be able to improve their testing process, the Test Process Improvement (TPI) model has been developed.

Capability Maturity Model (CMM) While awarding a contract, the customer needs to gain confidence that an organization is capable of delivering the desired product. The US Department of Defense wanted to evaluate their contractors. They needed a framework to evaluate the maturity of software processes. In 1986, the Software Engineering Institute (SEI) initiated the development of a framework to be called the CMM. In the CMM model, the maturity level of an organization tells us to what extent an organization can produce low cost, high quality software. Having known the current maturity level, an organization can work to reach the next higher level. There are five maturity levels in the CMM model.

Capability Maturity Model (CMM) Figure 18.1: The CMM structure [4] (©[2005] John Wiley).

Capability Maturity Model (CMM) Figure 18.2: SW-CMM maturity levels [4] (©[2005] John Wiley).

Capability Maturity Model (CMM) Common features of key practices The key practices in every key process area are organized into five categories called common features. Common features are attributes of key practices that indicate whether the implementation of a KPA is effective, repeatable, and lasting. The five categories of common features are as follows. Commitment to perform Ability to perform Activities performed Measurement and analysis Verifying implementation

Capability Maturity Model (CMM) Application of the CMM For an organization to be at a certain level of maturity, all the goals of all the KPAs at that level – and all preceding levels too – must be satisfied. Example: For an organization to be at Level 3, it must meet all the six KPAs at Level 2 and all the seven KPAs at Level 3. The SEI developed the Capability Maturity Model-Based Assessment Internal Process Improvement (CBA-IPI) to assist organizations for self-assessment. The CBA-IPI uses the CMM as a reference model to evaluate the process capability of organizations by identifying what KPAs are being satisfied and what need to be improved. The SEI developed the CMM Appraisal Framework (CAF) to provide a mechanism for formal evaluation of organizations. The CAF describes the requirements and guidelines to be used by external assessors in designing CAF-compliant evaluation methods.

Capability Maturity Model (CMM) Capability Maturity Model Integration (CMMI) After the successful application of the CMM in the software area (known as CMM-SW). CMMs in other areas were also developed. Systems Engineering CMM Integrated Product Development CMM Electronic Industry Alliance 731 CMM Software Acquisition CMM People CMM Supplier Source CMM

Test Process Improvement (TPI) A test process is a certain way of performing activities related to defect detection. A few such activities are as follows (See Section 18.3 for more.) Identifying test goals. Preparing a test plan. Identifying different kinds of tests. Hiring test personnel. Designing test cases. Setting up test benches. Procuring test tools. Assigning test cases to test engineers. Prioritizing test cases for execution. Organizing the execution of test cases into multiple test cycles.

Test Process Improvement (TPI) A simple test process for system-level testing Categorize the features of a system into k groups. Design Ni test cases for feature category i, for 1 ≤ i ≤ k. These Ni test cases are denoted by the set Ti. Run T1 U … U Tk to detect defects. Run T1 U … U Tk each defect fix until no more defects are found, or it is time to release the system. Deficiencies in the above simple process. Test tools have not been used. Test cases have not been prioritized. The entire test suite has been executed in each test cycle. Therefore, it is important to improve test processes by following a defined model. The idea of improving test processes by following a model, namely the Test Process Improvement (TPI) model, was first studied by Tim Koomen and Martin Pol.

Test Process Improvement (TPI) A test process needs to be improved for three reasons. Quality: A better test process should give more insights into the quality characteristics of a system being tested. Lead Time: A better test process saves testing time. One can prioritize test cases so that difficult-to-fix defects to gain time. Cost: A better test process is expected to be carried out with a lower cost. An intuitive approach to improving a test process is as follows: Step 1: Determine an area for improvement. Step 2: Evaluate the current status of the test process. Step 3: Identify the next desired state and the means. Step 4: Implement the necessary changes to the process. The above steps are straightforward, but their implementation is not. The TPI model supports gradual process improvement. The current status of a test process is evaluated from different viewpoints, known as key areas – and 20 key areas have been identified. The status of a test process w.r.t. a key area is represented in terms of one of four levels of maturity – A, B, C, and D.

Test Process Improvement (TPI) The 20 key areas are as follows: Test strategy Life-cycle model Moment of involvement Planning and estimating Test specification technique Static test technique Metrics Test tools Test environment Office environment Commitment and motivation Test functions and training Scope of methodology Communication Reporting Defect management Test process management Evaluation Low-level testing

Test Process Improvement (TPI) Maturity levels of test processes Based on the idea of dependencies and prioritization, a Test Maturity Matrix, as shown in Table 18.2, is constructed. The Test Maturity Matrix shows that the overall maturity of a test process can be represented on a scale of 1—13. The 13 scales of maturity of a test process are classified into three distinct segments as follows. Controlled (1—5): All component activities are planned and executed in phases according to the plan. Efficient (6—10): All the key areas, except Evaluation, are raised to at least B level with some being at C. Optimizing (11—13): All the key areas have reached their respective highest maturity levels. Optimizing a test process means performing testing tasks in the best possible manner from the standpoint of quality, time, and cost.

Test Process Improvement (TPI) Applying the TPI model Analyze the current test process, using Table 18.1 (Requirements for different maturity levels), in terms of the 20 key areas, and give each key area a rating – A, B, C, or D. Evaluate the current scale, between 1—13, of the test process by comparing the current status of the test process with the standard Test Maturity Matrix of Table 18.2 (Test maturity matrix.) Identify the goal of the organization in terms of the next scale to be achieved. Identify the key areas where improvements must be achieved. Take actions to improve the key areas identified in the preceding step.

Testing Maturity Model (TMM) TMM was pioneered by Ilene Burnstein to help organizations evaluate and improve their testing processes. The TMM framework describes an evolutionary path of test process maturity in five levels, or stages. (Figure 18.3). Each stage is characterized by the concepts of maturity goals supporting maturity goals, and activities, tasks, and responsibilities (ATRs)

Testing Maturity Model (TMM) Figure 18.3: The 5-level structure of the testing maturity model [1] (©[2003] Springer).

Testing Maturity Model (TMM) Maturity goals Each maturity level, except 1, contains certain maturity goals. For an organization to reach a certain level, the corresponding maturity goals must be met by the organization. Maturity subgoals Maturity goals are supported by maturity subgoals ATRs (Activities, Tasks and Responsibilites) Maturity subgoals are achieved by means of ATRs. ATRs address issues concerning implementation of activities and tasks. ATRs also address how an organization can adapt its practices so that it can move in-line with the TMM model. ATRs are refined into “views” from the perspectives of three groups: Managers Developers and test engineers Customers (user/client).

Testing Maturity Model (TMM) Level 1 – Initial There are no maturity goals to be met at this level. Testing begins after code is written. An organization performs testing to demonstrate that the system works. No serious effort is made to track the progress of testing. Test cases are designed and executed in an ad hoc manner. In summary, testing is not viewed as a critical, distinct phase in software development.

Testing Maturity Model (TMM) Level 2 – Phase Definition: The maturity goals are as follows: Develop testing and debugging goals. Some concrete maturity subgoals that can support this goal are as follows: Organizations form committees on testing and debugging. The committees develop and document testing and debugging goals. Initiate a test planning process. (Identify test objectives. Analyze risks. Devise strategies. Develop test specifications. Allocate resources.) Assign the task of test planning to a committee. The committee develops a test plan template. Proper tools are used to create and manage test plans. Provisions are put in place so that customer needs constitute a part of the test plan. Institutionalize basic testing techniques and methods. The following concrete subgoals support the above maturity subgoal. An expert group recommends a set of basic testing techniques and methods. The management establishes policies to execute the recommendations.

Testing Maturity Model (TMM) Level 3 – Integration: The maturity goals are as follows: Establish a software test group. Concrete subgoals to support the above are: An organization-wide test group is formed with leadership, support, and $$. The test group is involved in all stages of the software development. Trained and motivated test engineers are assigned to the group. The test group communicates with the customers. Establish a technical training program. Integrate testing into the software lifecycle. The test phase is partitined into several activities: unit, integration, system, and acceptance testing. Follow the V-model. Control and monitor the testing process. Develop policies and mechanisms to monitor and control test projects. Define a set of metrics related to the test project. Be prepared with a contingency plan.

Testing Maturity Model (TMM) Level 4 – Management and Measurement: The maturity goals are: Establish an organization-wide review program. Maturity subgoals to support the above are as follows. The management develops review policies. The test group develops goals, plans, procedures, and recording mechanisms for carrying out reviews. Members of the test group are trained to be effective. Establish a test management program. Test metrics should be identified along with their goals. A test measurement plan is developed for data collection and analysis. An action plan should be developed to achieve process improvement. Evaluate software quality. The organization defines quality attributes and quality goals for products. The management develops policies and mechanisms to collect test metrics to support the quality goals.

Testing Maturity Model (TMM) Level 5 –Optimization, Defect Prevention and Quality Control: The maturity goals are as follows: Application of process data for defect prevention Maturity subgoals to support the above are as follows. Establish a defect prevention team. Document defects that have been identified and removed. Each defect is analyzed to get to its root cause. Develop an action plan to eliminate recurrence of common defects. Statistical quality control Establish high-level measurable quality goals. (Ex. Test case execution rate, defect arrival rate, …) Ensure that the new quality goals form a part of the test plan. The test group is trained in statistical testing and analysis methods. Test process optimization

Testing Maturity Model (TMM) Level 5 –Optimization, Defect Prevention and Quality Control: The maturity goals are as follows (continued.) Test process optimization Maturity subgoals to support the above are as follows. Establish a test process improvement group to monitor the testing process and identify areas for improvement. Evaluate new technologies and tools to improve the capability of the testing process. Put a mechanism in place for continual evaluation of the effectiveness of the testing process. Test stopping criteria are based on quality goals.

Summary Capability Maturity Model (CMM) Test Process Improvement (TPI) The CMM is used to assess the maturity level of an organization to develop software products. Five levels of maturity Level 1: Initial Level 2: Repeatable Level 3: Defined Level 4: Managed Level 5: Optimized Each level is characterized by a set of key process areas. Test Process Improvement (TPI) A test process is evaluated w.r.t. 20 key areas. The maturity level of a test process is assessed on a scale of 1—13. The 13 levels of maturity are partitioned into three groups: controlled, efficient, and optimizing. Testing Maturity Model (TMM) The TMM model gives guidelines concerning how to improve a test process. The maturity of a testing process is evaluated on a scale of 1—5. Level 1: Initial Level 2: Phase Definition Level 3: Integration Level 4: Management and Measurement Level 5: Optimization, Defect Prevention, and Quality Control