Water unsafe to drink for one second every six years

• Master Black Belts—Master black belts are people within the organization who have the highest level of technical and organizational experience and expertise. Master black belts train black belts and, therefore, must know everything a black belt knows. Subsequently, a maser black belt must have technical competence, a solid foundation in statistical methods and tools, and the ability to teach and communicate.

• Black Belts—Although black belts may come from various disciplines, they should be technically competent and held in high esteem by their peers. Black belts are actively involved in the Six Sigma change process.

• Green Belts—Green belts are Six Sigma team leaders or project managers. Black belts generally help green belts choose their projects, attend training with them, and then assist them with their projects once the project begins.

• Champions—Many organizations have added the role of a Six Sigma cham pion. Champions are leaders who are committed to the success of the Six Sigma project and can ensure that barriers to the Six Sigma project are removed. Therefore, a champion is usually a high-level manager who can remove obstacles that may involve funding, support, bureaucracy, or other issues that black belts are unable to solve on their own

Although the concept of Six Sigma was initially used in a manufacturing environment, many of the techniques can be applied directly to software projects (Siviy 2001). The usefulness of Six Sigma lies in the conscious and methodical way of achieving customer satisfaction through the improvement of current processes and products and their design.

The Capability Maturity Model (CMM)

In 1986, the Software Engineering Institute (SEI), a federally funded research development center at Carnegie Mellon University, set out to help organizations improve their software development processes. With the help of the Mitre Corporation and Watts Humphrey, a framework was developed to assess and evaluate the capability of software processes and their maturity, and the work of the SEI evolved into the Capability Maturity Model (CMM) (Humphrey 1988). The CMM provides a set of recommended practices for a set of key process areas specific to software development. The objective of the CMM is to provide guidance as to how an organization can best control its processes for developing and maintaining software. In addition, the CMM provides a path for helping organizations evolve their current software processes toward software engineering and management excellence (Paulk, Curtis et al. 1993).

To understand how the CMM may support an organization, several concepts must first be defined:

• Software Process—A set of activities, methods, or practices and transfor mations used by people to develop and maintain software and the deliverables associated with software projects. Included are such things as project plans, design documents, code, test cases, user manuals, and so forth.

• Software Process Capability—The expected results that can be achieved by following a particular software process. More specifically, the capability of an organization's software processes provides a way of predicting the out comes that can be expected if the same software processes are used from one software project to the next.

• Software Process Performance—The actual results that are achieved by following a particular software process. Therefore, the actual results achieved through software process performance can be compared to the expected results achieved through software process capability.

• Software Process Maturity—The extent to which a particular software process is explicitly and consistently defined, managed, measured, controlled, and effectively used throughout the organization.

One of the keys to the CMM is using the idea of software process maturity to describe the difference between immature and mature software organizations. In an immature software organization, software processes are improvised or developed ad hoc. For example, a software project team may be faced with the task of defining user requirements. When it comes time to complete this task, the various members of the team may have different ideas concerning how to accomplish it. Several of the members may approach the task differently and, subsequently achieve different results. Even if a well-defined process that specifies the steps, tools, resources, and deliverables required is in place, the team may not follow the specified process very closely or at all.

The immature software organization is characterized as being reactive; the project manager and project team spend a great deal of their time reacting to crises or find themselves in a perpetual state of fire fighting. Schedules and budgets are usually exceeded. As a result, the quality and functionality of the software system and the associated project deliverables are often compromised. Project success is determined largely by who is (or who is not) part of the project team. In addition, immature software organizations generally do not have a way of judging or predicting quality. Since these organizations operate in a perpetual crisis mode, there never seems to be enough time to address problem issues or improve the current processes.

Mature software organizations, on the other hand, provide a stark contrast to the immature software organization. More specifically, software processes and the roles of individuals are defined explicitly and communicated throughout the organization. The software processes are consistent throughout the organization and continually improved based on experimentation or experiences. The quality of each software process is monitored so that the products and processes are predictable across different projects. Budgets and schedules are based on past projects so they are more realistic and the project goals and objectives are more likely to be achieved. Mature software organizations are proactive and they are able to follow a set of disciplined processes throughout the software project.

The CMM defines five levels of process maturity, each requiring many small steps as a path of incremental and continuous process improvement. These stages are based on many of the quality concepts and philosophies of Shewhart, Deming, Juran, and Crosby (Paulk, Curtis et al. 1993). Figure 10.7 illustrates the CMM framework for software process maturity. These levels allow an organization to assess its current level of software process maturity and then help it prioritize the improvement efforts it needs to reach the next higher level (Caputo 1998).

Maturity levels provide a well-defined, evolutionary path for achieving a mature software process organization. With the exception of Level 1, each maturity level encompasses several key process areas that an organization must have in place in order to achieve a particular level of maturity. There are five levels of software process maturity.

Level 1: Initial The initial level generally provides a starting point for many software organizations. This level is characterized by an immature software organization in which the software process is ad hoc and often reactive to crises. Few, if any, processes for developing and maintaining software are defined. The Level 1 software organization does not have a stable environment for software projects, and success of a project rests

Figure 10.7 Levels of Software Process Maturity

largely with the people on the project and not the processes that they follow. As a result, success is difficult to repeat across different projects throughout the organization.

Key Process Areas

• No key process areas are in place.

Level 2: Repeatable At this level, basic policies, processes, and controls for managing a software project are in place. Project schedules and budgets are more realistic because planning and managing new projects is based upon past experiences with similar projects. Although software processes between projects may be different at this level, the process capability of Level 2 organizations is more disciplined because software processes are more documented, enforced, and improving. As a result, many previous project successes can be repeated by other project teams on other projects.

Key Process Areas

• Software Configuration Management—Supports the controlling and man aging of changes to the various project deliverables and software products throughout the project and software life cycles.

• Software Quality Assurance—Provides project stakeholders with an understanding of the processes and standards used to support the project quality plan.

• Software Subcontract Management—Supports the selection and manage ment of qualified software subcontractors.

• Software Project Tracking and Oversight—Ensures that adequate controls are in place to oversee and manage the software project so that effective decisions can be made and actions taken when the project's actual perform ance deviates from the project plan.

• Software Project Planning—Establishes realistic plans for software devel opment and managing the project.

• Requirements Management—Ensures that a common understanding of the user's requirements is established and becomes an agreement and basis for planning.

Level 3: Defined At Level 3, software engineering and management processes are documented and standardized throughout the organization and become the organization's standard process. And, a group is established to oversee the organization's software processes and an organizationwide training program to support the standard process is implemented. Thus, activities, roles, and responsibilities are well defined and understood throughout the organization. The software process capability of this level is characterized as being standard, consistent, stable, and repeatable. However, this standard software process may be tailored to suit the individual characteristics or needs of an individual project.

Key Process Areas

• Peer Reviews—Promotes the prevention and removal of software defects as early as possible and is implemented through code inspections, structured walkthroughs, and so forth.

• Intergroup Coordination—Allows for an interdisciplinary approach where the software engineering group participates actively with other project groups in order to produce a more effective and efficient software product.

• Software Product Engineering—Defines a consistent and effective set of integrated software engineering activities and processes in order to produce a software product that meets the users' requirements.

• Integrated Software Management—Supports the integration of software engineering and management activities into a set of well-defined and understood software processes that are tailored to the organization.

• Training Programs—Facilitates the development of individuals' skills and knowledge so that they may perform their roles and duties more effectively and efficiently.

• Organization Process Definition—Supports the identification and develop ment of a usable set of software processes that improve the capability of the organization across all software projects.

• Organization Process Focus—Establishes organizational responsibility for implementing software processes that improve the organization's overall software process capability.

Level 4: Managed At this level, quantitative metrics for measuring and assessing productivity and quality are established for both software products and processes. This information is collected and stored in an organizationwide repository that can be used to analyze and evaluate software processes and products. Control over projects is achieved by reducing the variability of project performance so that it falls within acceptable control boundaries. The software processes of software organizations at this level are characterized as being quantifiable and predictable because quantitative controls are in place to determine whether the process performs within operational limits. Moreover, these controls allow for predicting trends and identifying when assignable causes occur that require immediate attention.

Key Process Areas

• Software Quality Management—Establishes a set of processes to support the project's quality objectives and project quality management activities.

• Quantitative Process Management—Provides a set of quantitative or statis tical control processes to manage and control the performance of the soft ware project by identifying assignable cause variation.

Level 5: Optimizing At the highest level of software process maturity, the whole organization is focused on continuous process improvement. These improvements come about as a result of innovations using new technology and methods and incremental process improvement. Moreover, the organization has the ability to identify its areas of strengths and weaknesses. Innovations and best practices based on lessons learned are identified and disseminated throughout the organization.

Key Process Areas

• Process Change Management—Supports the continual and incremental improvement of the software processes used by the organization in order to improve quality, increase productivity, and decrease the cycle time of soft ware development.

• Technology Change Management—Supports the identification of new tech nologies (i.e., processes, methods, tools, best practices) that would be bene ficial to the organization and ensures that they are integrated effectively and efficiently throughout the organization.

• Defect Prevention—Supports a proactive approach to identifying and pre venting software defects.

As an organization's software process maturity increases, the difference between expected results and actual results narrows. In addition, performance can be expected to improve when maturity levels increase because costs and development time will decrease, while quality and productivity increase.

According to the SEI, skipping maturity levels is counter-productive. If an organization was evaluated at Level 1, for example, and wanted to skip to Level 3 or Level 4, it may be difficult because the CMM identifies levels through which an organization must evolve in order to establish a culture and experiences.

Both the CMM and ISO 9001 series of standards focus on quality and process improvement. A technical paper by Mark C. Paulk (1994) compares the similarities and differences between the CMM and ISO 9001. His analysis indicates an ISO 9001-compliant organization would satisfy most of the Level 2 and Level 3 goals. Although Level 1 organizations could be ISO 9001 compliant, it may be difficult for these organizations to remain compliant. In turn, there are many practices in the CMM that are not addressed by ISO 9001, and it is, therefore, possible for a Level 1 organization to be ISO 9001 compliant. A Level 2 organization should have little difficulty in receiving ISO 9001 certification.

After reading this section, you may be wondering which quality system is best. Should an organization focus on ISO certification? Or, should it concentrate its efforts on the CMM? Although the market may dictate a particular certification, an

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment