Software Process Improvement Models

Over view of current Software Process Improvement Models

To help software process improvement, there are several models, such as CMM and ISO. These models evaluate the software product, project, quality, and drawback. All purpose is to control and optimize the software process. 12:16, 28 November 2010 (UTC)12:16, 28 November 2010 (UTC)~~

The systematic of software process improvement

It includes ISO 9001, CMM, Trillium, and Bootstrasp. ISO 9001 is international organisation for standardization, general standard for service industry. After ISO 900-3, there are 20 items which specify for the software process organisation.

The Concept of CMM

What is CMM?

CMM means Capability Maturity Model. It is a series standard to assess the software capability and maturity. It also provides the methodologies for software assessment.

History/background

1985, the Software Engineering Institute(SEI) of Carnegie Mellon University, they work on a Process Maturity Framework for judging a company’s capability to produce software. And the process maturity framework evolves into the Capability Maturity Model. In August 1991, they released CMM version 1. Next year in 1992, CMM version 1.1 released.

CMM Structure

CMM has 5 maturity levels to assess software process. They are Initial level, Repeatable level, Defined level, Managed level and Optimizing level.

Initial Level

At the beginning of initial level, software processes are chaotic and the company could not assure the success when repeating the same kind of project.

Repeatable Level

At the repeatable level, the basic project management processes are established, which include software configuration management, software quality assurance, software subcontract management, software project tracking and supervision, software project planning and requirement management.

Defined Level

At the defined level, it focuses on engineering process. The management and engineering of software processes are integrated, which include peer review, inter-group coordination, software product engineering, integrated software management, training program, organisation process definition, and organisation process focus.

Managed Level

At the managed level, it concentrates on product and process quality, detail measures are used to control the process, which include the quality management and process measurement and analysis.

Optimizing Level

At the optimizing level, that is a continuous process improvement. It make the continual process improvement is enabled. It includes process change management, technology innovation and defect prevention.

The Concept of ISO

What is ISO

ISO stands for International Organisation for Standardisation. The ISO name is not an acronym but comes from the Greek word ἴσος (isos) meaning “equal”. This is because different countries would have different acronyms because of the name of the body.

They are a non-governmental body that are in charge of developing and maintaining standards in many different areas such as computing, quality, documentation, construction, agriculture, etc.

The ISO has 157 countries involved, each with one national standard institute. The coordination body for the ISO, the “Central Secretariat” is in Geneva, Switzerland. The ISO work with both private and public sectors so that when international standards need to be produced, a better overall standard can be developed to suit the community more effectively.

ISO history/ ISO Standard

The ISO was started in 1947 and has become the world’s largest standardisation body. They have published more than 16,500 international standards since then. Initially the documents written by the body were recommendations.

The body came into existence by the merging of the International Federation of the National Standardizing Associations (ISA) and the United Nations Standards Coordinating Committee (UNSCC). As time went on, more and more countries started to join which gave the standard a greater international binding.

In the 60’s there was an increase in trade and the need for international standards was increased. This was pushed by multi-national companies who needed the standards so that their products would fit to a defined standard thereby reducing the need to produce items with different interfaces, etc. In 1971 the decision was taken to release International Standards rather than just recommendations.

In the 80’s the ISO moved into the standardisation of organisational practice and trade. These documents dealt with quality and safety issues which lead to better quality products and services, and also reduced accidents in the process of manufacturing certain dangerous items.

In the 90’s the issues of Environmental Management were looked at. The ISO can up with standards for dealing with factors that could effect the environment. An example of this would be the Framework Convention on Climate Change which led to the creation of the Kyoto Protocol.

During the past 15 years the growth in ISO membership has dramatically increased; there was nearly a 50% increase from 1994 to 2003.

The ISO have a strategic plan, the “Standards for a sustainable world” developed for 2005 to 2010 which describes their global vision and objectives.

ISO 9000

ISO 9000 consists of a number of standards related to quality management systems and related supporting standards. It was created by the ISO. The ISO 9000 family is there to represent “an international consensus on good quality management practices”. Issues that are covered in the standards include:

• Procedures for key business processes
• Processes monitoring
• Keeping records
• Defect control and preventive techniques
• Review of specific processes and measuring effectiveness
• Continual improvement

ISO 9000:2005 describes fundamentals of quality management systems, which form the subject of the ISO 9000 family, and defines related terms. It is applicable to the following:

a) organisations seeking advantage through the implementation of a quality management system;

b) organisations seeking confidence from their suppliers that their product requirements will be satisfied;

c) users of the products;

d) those concerned with a mutual understanding of the terminology used in quality management (e.g. suppliers, customers, regulators);

e) those internal or external to the organisation who assess the quality management system or audit it for conformity with the requirements of ISO 9001 (e.g. auditors, regulators, certification/registration bodies);

f) those internal or external to the organisation who give advice or training on the quality management system appropriate to that organisation;

g) developers of related standards.

Source: 9000:2005 Quality management systems -- Fundamentals and vocabulary

Comparison with CMMI & ISO/IEC 15504,SPICE

Similarities

Similar systematic evaluation

Both of them provide a structured approach with different level to get software process improvement. They represent a continuous conception in software process improvement. Software organisation follows the first level at the beginning to achieve goals in each stage, to get the highest level at last. The purpose is to get the capability improvement continuously.

Similar coverage area

Compared the structure of CMMI & ISO/IEC 15504, it is not difficult to find most of coverage of their key processes are the same. That means we can find corresponding CMMI process in 15504 process, and also can find corresponding 15504 process in CMMI process.

Another aspect, the coverage of CMM is only focusing on internal software development process; the coverage of 15504 extends to external area, such as custom service process.

Differences

Different goal

CMMI and ISO/IEC 15504 have the different goals. CMMI’s goal is to improve the whole process capability in one’s organisation, but it depends on an assumption, process is the base of product’s quality. CMMI tells the company HOW TO improve the process and its capability. To achieve this goal, we can find tasks following CMMI models.

ISO/IEC 15504 focuses on each process; the goal is to improve the capability in each process. From the framework on 15504, we can find every process is an individual, associate with each other not tight. 15504 is a measure to assess the capability of the process, not the detail instruction.

Different method for evaluation

CMMI evaluates the capability of software process in according with data collection and analysis. The data collection and analysis of 15504 is based on each process, evaluate their properties.

Different structure

CMMI is a concept model on levels. For each level, they are associated with each other. And there is different concentration on each level. To reach one level, the organisation should achieve accomplish goals in all key process areas. This key process area is the base for next level.

Conclusion

CMMI seems like an instruction, more suitable for software process improvement.

ISO/IEC 15504 works on evaluating, comparing the capability of software process.

Different CMMs

Capability Maturity Model Integration(CMMI)

Capability Maturity Model Integration (CMMI) evolved from Capability Maturity Model (CMM). CMM was proposed and research began by the Software Engineering Institute (SEI) in 1986. CMMI defines processes that should be implemented in an organisation, but it does not describe the way the processes should be implemented. CMM assists to improve product quality, organisation’s processes, productivity and project development life-cycle. CMMI is successfully applied in safety critical environments like healthcare. Also it is widely deployed in government and military projects. CMMI is widely used in large enterprises, also possible for small teams to incorporate with a little modification of the processes. Latest CMMI release version 1.2 identifies twenty-two process areas which are divided into four categories:

Process Management

• OID - Organisational Innovation and Deployment • OPD - Organisational Process Definition +IPPD • OPF - Organisational Process Focus • OPP - Organisational Process Performance • OT - Organisational Training

Project Management

• PP - Project Planning • PMC - Project Monitoring and Control • SAM - Supplier Agreement Management • IPM - Integrated Project Management +IPPD • RSKM - Risk Management • QPM - Quantitative Project Management

Engineering

• REQM - Requirements Management • RD - Requirements Development • TS - Technical Solution • PI - Product Integration • VER - Verification • VAL - Validation

Support

• CM - Configuration Management • PPQA - Process and Product Quality Assurance • MA - Measurement and Analysis • DAR - Decision Analysis and Resolution • CAR - Causal Analysis and Resolution

Process areas also may be grouped according to maturity levels. Organisation can be appraised by Software Engineering Institute (SEI) and rated by one of the Maturity Levels: 1. Initial 2. Managed 3. Defined 4. Quantitatively Managed 5. Optimizing Results may be published if an organisation is willing to do so. Published results contain the name of the organisation, team leader/sponsor, and appraisal end date and maturity level representation.

Capability Maturity Model for software(SW-CMM)

Software Engineering Institute (SEI) has been supporting Capability Maturity Model for Software (SW-CMM) since 1987, but now SW-CMM has been replaced by CMMI. There is no more training provided by the SEI for SW-CMM and is no longer supported, but many organisations are still productively using SW-CMM model and assessment methods. In case of SW-CMM, organisation is assessed on the scale 1-5 similar to CMM maturity levels. SW-CMM model allows organisation to verify capability for software development and maintenance; it focuses on project management. SW-CMM was intended to make available assessment of the processes enhancement with currently existing processes in the organisation to recognize setbacks for organisational processes and software quality improvements.

People Capability Maturity Model(P-CMM)

In response to the claim that the CMM's focus is unevenly upon process rather than people the SEI has developed the P-CMM. The P-CMM adapts the concepts of the CMM and focuses them on developing the organisation's human resources. It is a framework for managing the people involved in the software development process.

Objectives

• To improve the capability of software organisations by increasing workforce capability
• To ensure that software development capability is not reliant on a small number of individuals but on the entire organisation
• To align the motivation of the staff with that of the organisation
• To retain people with critical skills and capabilities within the organisation.

Maturity Levels

As with other CMMs the P-CMM is a five stage model. At each stage a new set of practices is added to those which have been laid down in the preceding levels.

Initial Level

Characterised by ad hoc and inconsistent approach to workforce practices. Often beset with difficulty in retaining talented staff. Organisations at this level can usually be characterised as exhibiting:

• Inconsistency in performing practices.
• Displacement of responsibility
• Ritualistic Practices
• Emotionally detached workforce.

Managed Level

The Managed level focuses on activities at the unit level, such as staffing, providing resources and developing skills. The first step of the second maturity level is to make sure that managers take personal responsibility for the performance and development of those performing the unit's work.

Qualified people are selected or recruited and are transitioned into assignments in each unit. Managers pay attention to any potential problems that might hinder the performance of their units.

The Managed level has six processes.

• Staffing

The establishment of a formal process whereby committed work is matched to unit resources
and qualified people are recruited, selected, and placed within appropriate assignments.

• Communication and Coordination

The establishment of timely organisation-wide communication. Ensuring that the workforce
have the skills necessary for information sharing and coordinating

• Work Environment

Establishment and maintenance of physical working conditions.
Provision of resources needed for efficient performance of tasks.

• Performance Management

The establishment of objectives related to committed work against which unit
individual performance can be measured.

• Training and Development

Ensuring that the workforce is adequately skilled and that opportunities
for development are provided when needed.

• Compensation

The remuneration and reward of individuals for their contribution to
the organisation.

Defined Level

The focus at the Defined Level is on providing an organisational framework for the workforce. At this level, the workforce will be equipped with the knowledge and skills to carry out the core practices of the organisation.

There are seven process areas for this maturity level.

• Competency Analysis

Identification of the key knowledge, skills and process abilities needed to perform
the business activities of an organisation.

• Workforce Planning

The coordination, at both organisation and unit level, of workforce activities
with current and future business needs.

• Competency Development

The continual development of the workforce to enhance their capability
to carry out their responsibilities.

• Career Development

Ensuring that the workforce are afforded the opportunities to achieve
their career objectives

• Competency-Based Practices

Ensuring that practices support the development of the workforce competence.

• Workgroup Development

The organisation of work around competency based process abilities.

• Participatory Culture

Exploiting the full capabilities of the workforce in decision making

The Predictable Level

The focus at this level is to exploit the knowledge and experience of the workforce developed at level 3. There are six processes:

• Competency Integration

To improve the efficiency of work which is interdependent.

• Empowered Workgroups

 Ensuring that workgroups have the ability and authority to conduct business activities effectively.

• Competency-Based Assets

The purpose of Competency-Based Assets is to capture the knowledge,
experience, and artefacts developed in performing competency-based
processes for use in enhancing capability and performance.

• Quantitative Performance

Predicts and manages the capability of competency-based processes for
achieving measurable performance objectives.

• Organisational Capability Management

Quantify the capability of the workforce and the critical processes they perform.

• Mentoring

Improving the capability of individuals or workgroups through the
transference of lessons of greater experience.

Optimising Level

At this level the entire organisation is focused on continual improvement. There are three processes.

• Continuous Capability Improvement

The provision of a foundation for individuals and workgroups to continuously improve
their capability for performing competency-based processes.

• Organisational Performance Alignment

to enhance the alignment of performance results across individuals, workgroups,
and units with organisational performance and business objectives.

• Continuous Workforce Innovation

to identify and evaluate improved or innovative workforce practices and
technologies, and implement the most promising ones throughout the organisation.

Systems Engineering Capability Maturity Model(SE-CMM)

The Systems Engineering Capability Maturity Model (SE-CMM) concerns the description of the essential elements in an organisation's systems engineering process that is required to ensure good systems engineering. SE-CMM provides a reference for comparing actual systems engineering practices against these essential elements. SE-CMM allows an organisation to select a specific process area and improve relative to it. By use of capability levels it is possible to characterize improvements that are relative to an individual process area. According to the SE-CMM model the quality of a product is mainly based on the process and technology used in the development of the product (Figure 1). Also the capability of the people involved in the work is significant to contribute to a high quality product.

Figure 1. SE-CMM Quality Dependencies

Flexible approach to Software Process Improvement(SPI) The SE-CMM model architecture, shown in Figure 1, separates systems engineering process areas (domain portion) from general characteristics (capability portion) related to increasing process capability. This architecture, which separates domain-specific characteristics from capability-related characteristics, was chosen to allow flexible use of process capability criteria in other domain areas such as software engineering. SE-CMM allows an organisation to focus on a single process-related trouble spot or several areas that are closely aligned to business objectives.

Figure 2. SE-CMM Architecture

Case studies from the software engineering community and elsewhere suggest that addressing issues of process management, measurement, and institutionalization improve the organisation's ability to meet its cost, quality, and schedule goals.

Process Capability Portion of the SE-CMM

Generic practices Generic practices are a series of activities that apply to all processes. They address the management, measurement, and institutionalization aspects of a process. In general, they are used during an appraisal to determine the capability of any process.

Common features Common features are groupings of generic practices appropriate within capability levels. For example, common features included in the Planned and Tracked level (Level 2) are Planning Performance, Disciplined Performance, Tracking Performance, and Verifying Performance.

Capability Levels

Figure 3. SE-CMM Capability Levels

• The Initial level

(Level 0) displays no common features. It is characteristic of an organisation just entering the systems engineering field, or one that has not focused on the systematic application of systems engineering principles in their product development. They accomplish some of the tasks, but are not necessarily sure how. There is general failure to perform the base practices in the process area. Where there are work products that result from performing the process, they are not easily identifiable or accessible.

• The Performed level

At this level, all base practices are performed somewhere in the project's or organisation's implemented process. However, consistent planning and tracking of that performance is missing. Good performance, therefore, depends on individual knowledge and effort. Work products are generally adequate, but quality and efficiency of production depend on how well individuals within the organisation perceive that tasks should be performed. Based on experience, there is general assurance that an action will be performed adequately when required. However, the capability to perform an activity is not generally repeatable or transferable.

• The Planned & Tracked level

At the Planned and Tracked level, planning and tracking have been introduced. There is general recognition that the organisation's performance is dependent on how efficiently the systems engineering base practices are implemented within the project's or organisation's process. The primary distinction between the Performed Informally and the Planned and Tracked levels is that at the Planned and Tracked level, the execution of the base practices in the project's implemented process is planned and managed. Therefore, it is repeatable within the implementing project, though not necessarily transferable across the organisation.

• The Well Defined level

At this level, base practices are performed throughout the organisation via the use of approved, tailored versions of standard, documented processes. This information is used in planning and managing the day-to-day execution of multiple projects within the organisation and is used for short- and long-term process improvement. The main difference between the Planned and Tacked and Well Defined levels is the use of organisation-wide, accepted standard processes that implement the characteristics exhibited by the base practices. The capability to perform an activity is, therefore, directly transferable to new projects within the organisation.

• The Quantitatively Controlled level

At the Quantitatively Controlled level, measurable process goals are established for each defined process and associated work products, and detailed measures of performance are collected and analysed. These data enable quantitative understanding of the process and an improved ability to predict performance. Performance, then, is objectively managed and defects are selectively identified and corrected.

• The Continuously Improving level

This is the highest achievement level from the viewpoint of process capability. The organisation has established quantitative, as well as qualitative, goals for process effectiveness and efficiency, based on long-range business strategies and goals. Continuous process improvement toward achievement of these goals using timely, quantitative performance feedback has been established. Further enhancements are achieved by pilot testing of innovative ideas and planned insertion of new technology.

Domain Portion of the SE-CMM The SE-CMM characterizes the systems engineering domain by using process areas. Each process area is further detailed by several base practices and explanatory notes. There are 18 process areas, which are grouped into 3 process categories:

• Engineering
• Project
• Organisation

Table 1. Components of the Domain Aspect of the SE-CMM

Architectural Component	Description
Engineering	Includes base practices from the process areas that are executed by system engineers
Project & Organisation	These are support processes where the authors include support process areas because effective systems engineering is unlikely unless these support tasks are performed, i.e. ensures that all the engineering staff is working to the same requirement and design baselines prior to project continuation.

The point of the SE-CMM is not to indicate "who" does the kinds of things described in a particular process area, but to indicate that the work needs to be performed by someone regardless of their role.

Integrated Product Development(IPD-CMM)

Similar to Software Engineering Capability Maturity Model (SE-CMM), PD-CMM provides a description of best practice organisational and project management processes, but focuses on ensuring the timely collaboration of all appropriate disciplines in the development and maintenance of products or services.

Because of IPD-CMM’s focus on organisations practicing with project teams, several interviews where conducted by the Cusick organisation in the industry to investigate good and bad implementations of integrated product development. The goal of this research was to acquire an understanding of the benefits gained and problems confronted with in relation to IPD-CMM implementations. The result of these findings were collected in a database and published by Cusick.

The Cusick study showed that the components of IPD-CMM (Table 1) that comprise the model are relevant to the success factors of implementing the integrated product development model.

Table 1. IPD-CMM Components

Architectural Component	Description
Focus on people and personal commitment	Organisations committed to training and personal development, development tools that promote individual accountability and move away from forced control over employees, gain a high personal commitment to product success.
An organisational structure consistent with company goals	Unfortunately some organisations continue to use tools that don’t work in an IPD organisational structure. i.e. using own rewards and recognition system to continue to reward behaviour that is no longer desirable.
An emphasis on planning	Planning takes on increased importance due to individual involvement and interest
A focus on measurement and processes	Project performance measures are tracked to establish metrics for future projects and to fix current inefficiencies.
Careful monitoring of the decision making processes	Sometimes teams get stuck due to lack of decision making. Successful organisation closely monitors how decisions are made and use this data to monitor the health of the team.
Leadership dedicated to IPD	Leaders need to set and communicate clear, measurable goals and put effort to remove barriers that teams identify to achieving goals.

Personal Software Process(PSP)

This is already discussed; see the Personal Software Process section of the Plan-driven Software Development category of Software Process Management

Team Software Process (TSP)

For a discussion of what TSP is and how it is implemented see the Team Software Process section of the Plan-driven Software Development category of Software Process Management

The relationship between CMMI and TSP is initially confusing. Both CMM (and subsequently CMM) and TSP stem from the original work of the SEI in studying software processes. Sometimes TSP and PSP are presented as extensions of CMMI; other times PSP/TSP are presented as tools that support the implementation of CMMI. The truth is somewhere in between.

History

TSP was initially a CMMI Level 5 activity, meaning that it was intended for organisations that had reached CMM Level 5. Over time this aspect has been de-emphasised however. Currently, TSP is recommended for CMMI level 2 and above, and is increasingly been seen as a driver for process improvement and a tool for achieving CMMI levels.

The Relationship between CMMI and TSP

Significant work was done by the SEI to highlight two specific things:

• TSP an be used for process improvement for any organisation, but especially those at CMM Level 2
• TSP maps well to and supports the goals of CMM

Humphreys et al. write that "it has become clear that to establish such processes, many engineering organisations need more precise how-to guidance than that provided by CMMI" and that the combination of TSP and CMMI are the way to do this.

The synergies between CMMI and TSP are explored in depth in Mapping TSP to CMMI All aspects of the software process are explored and the report finds that most CMMI practices are partially or fully supported by TSP. The authors suggest that TSP can in fact be a catalyst for process improvement. This idea is also discussed in a more digestible fashion in TSP Can Be the Building Blocks for CMMI A real world example of the benefits of using TSP for process improvement are explored in The AV-8B Team Learns Synergy of EVM and TSP Accelerates Software Process Improvement

Caveats

When introducing TSP as a means of driving process improvement and achieving CMMI levels, it is still necessary to adhere to best practice in how the organisation is introduced to and trained in PSP/TSP

When introducing TSP to an organisation, it is still necessary to complete PSP and TSP training and gain complete management buy in. Motivations for introducing TSP must be understood and buy-in from all parties must still be achieved.

Criticisms

The repositioning of TSP suggests that to some extent there were difficulties with how it was presented initially.

The relationship between TSP and CMM/CMMI had to be explored and quantified in depth by the SEI themselves. The gaps in the mapping of TSP to CMMI are troublesome.

While TSP is a significant tool for teams in the software process, the fact that is use and application weren't better understood suggests a lack of real world study of how the process could be applied.

The future of CMM and ISO

Software standards have multiple issues to deal with going forward. Some are specific to the individual standards, others are shared concerns.

Common Concerns for the Future

It does not follow that a company that has, for example, reached CMMI Level 4, has actually got good products. Standards, in a sense, guarantee only that the standard has been followed.

All standards have a reputation for being process and document heavy, and for getting "in the way" of the development process. IS0 9000/9001 in particular is seen as a paper exercise and a good example of the "certification doesn't guarantee good product" issue mentioned previously.

For any of the standards, figuring out how they can be mapped to Agile methods is a significant challenge. Some work has been done on this already, but it is yet to achieve widespread adoption. In fact, it may never be widely adopted as it is not necessary.

Standards need to remain relevant. Too often, discussion of CMMI and ISO standards are confined to the areas of military, government or safety critical software efforts. The fact that these standards reflect what should be best practice for software engineering is frequently overlooked because the negative aspects of standards overshadow the positive. Reaching out beyond the often captive audience for standards that currently exist and addressing the ways that they can be realized using Agile methods is important for the future of standards.

CMMI

There is a clear commitment from the SEI to continue to develop and enhance CMMI. CMMI and associated standards are constantly under revision and there are continuing efforts to measure and improve the effectiveness of CMMI as well as exploring ways of introducing and achieving CMMI certification.

However, there is a question over the relevance of CMMI. Much of the work of the SEI in developing CMMI is rooted in the experience of Humphrey and others in the software industry of the pre-internet age. The process is difficult to

Also, the rise of other apparently more effective, less expensive software processes and methodologies from the Agile world have to some degree left CMMI behind. In spite of the insistence of the SEI that CMMI is perfectly suitable for Agile projects, and ways of applying CMMI to Agile are explored, there is little appetite amongst Agile practitioners for the comparatively process heavy world of CMMI. Poppendieck and others are positively dismissive of CMMI. Others are indifferent.

And certainly CMMI will always have an audience in the military and safety critical industries where standards are a requirement for doing business, and rightly so. However it's broader appeal is limited.

ISO 15504

The biggest challenge facing ISO 15504 is to gain acceptance in a market dominated by CMMI.