Introduction
More now than ever, companies today want to deliver products better, faster, and cheaper. At the same time, in the high-technology environment of the twenty-first century, nearly all organizations have found themselves building more and more complex products. Today, a single company usually does not develop all the components that compose a product. More commonly, some components are built in-house and some are acquired; then all the components are integrated into the final product. Organizations must be able to manage and control this complex product development and maintenance.
Many organizations have also found themselves in the software business. Organizations that were not typically software companies—such as financial institutions, car manufacturers, airplane manufacturers, and insurance companies— find that much of their business relies on software. Software is often what differentiates them from their competitors. The problems these organizations address today involve both software and systems engineering. More and more, these disciplines are becoming a critical part of their business.In essence, these organizations are product developers that need a way to manage an integrated approach to their software and systems engineering as part of reaching their business objectives.
Capability Maturity Model Integration (CMMI) provides an opportunity to avoid or eliminate these stovepipes and barriers through integrated models that transcend disciplines. CMMI consists of best practices that address product development and maintenance. It addresses practices that cover the product’s life cycle from conception through delivery and maintenance. There is an emphasis on both systems engineering and software engineering and the integration necessary to build and maintain the total product.
Evolution of CMMI Model
The Software Engineering Institute (SEI) of Carnegie Mellon University, Pittsburgh has found several dimensions that an organization can focus on to improve its business. Manufacturing has long recognized the importance of process effectiveness and efficiency. Today, many organizations in manufacturing and service industries recognize the importance of quality processes. Process helps an organization’s workforce meet business objectives by helping them work smarter, not harder, and with improved consistency. Effective processes also provide a vehicle for introducing and using new technology in a way that best meets the business objectives of the organization.
The SEI has taken the process-management premise, “the quality of a system or product is highly influenced by the quality of the process used to develop and maintain it,” and defined capability maturity models that embody this premise. The belief in this premise is worldwide in quality movements, as evidenced by the International Organization for Standardization/ International Electrotechnical Commission (ISO/IEC) body of standards.
Capability maturity models (CMMs) focus on improving processes in an organization. They contain the essential elements of effective processes for one or more disciplines and describe an evolutionary improvement path from ad hoc, immature processes to disciplined, mature processes with improved quality and effectiveness.
In the 1930s, Walter Shewhart began work in process improvement with his principles of statistical quality control [Shewhart 31]. These principles were refined by W. Edwards Deming [Deming 86] and Joseph Juran [Juran 88]. Watts Humphrey, Ron Radice, and others extended these principles even further and began applying them to software in their work at IBM and the SEI.
Mark Paulk and others at the Software Engineering Institute created the first capability maturity model designed for software organizations and published it in a book, The Capability Maturity Model: Guidelines for Improving the Software Process [SEI 95]. The SEI’s book took the principles introduced almost a century ago and applied them to this never-ending cycle of process improvement. The value of this process improvement approach has been confirmed over time. Organizations have experienced increased productivity and quality, improved cycle time, and more accurate and predictable schedules and budgets [Herbsleb 97].
Since 1991, CMMs have been developed for a myriad of disciplines. Some of the most notable include models for systems engineering, software engineering, software acquisition, workforce management and development, and integrated product and process development.
Although these models have proved useful to many organizations, the use of multiple models has been problematic. Many organizations would like to focus their improvement efforts across the disciplines in their organizations. However, the differences among these discipline-specific models, including their architecture, content, and approach, have limited these organizations’ ability to focus their improvements successfully. Further, applying multiple models that are not integrated within and across an organization is costly in terms of training, appraisals, and improvement activities
The CMM Integration project was formed to sort out the problem of using multiple CMMs. The CMMI Product Team’s mission was to combine three source models:
1. The Capability Maturity Model for Software (SW-CMM) v2.0 draft C
2. The Systems Engineering Capability Models (SECM)
3. The Integrated Product Development Capability Maturity Model (IPD-CMM) v 0.98
The combination of these models into a single improvement framework was intended for use by organizations in their pursuit of enterprise-wide process improvement. These three source models were selected because of their widespread adoption in the software and systems engineering communities and because of their different approaches to improving processes in an organization.
Using information from these popular and well-regarded models as source material, the CMMI Product Team created a cohesive set of integrated models that can be adopted by those currently using the source models, as well as by those new to the CMM concept. Hence, CMMI is a result of the evolution of the SW-CMM, the SECM, and the IPD-CMM.
The CMMI Framework was also designed to support the future integration of other disciplines. Furthermore, CMMI was developed to be consistent and compatible with the ISO/IEC 15504 Technical Report for Software Process Assessment [ISO 98].
CMMI has gone through an extensive review process. CMMI version 0.2 was publicly reviewed and used in pilot activities. Following release of that version, improvement was guided by change requests from public reviewers, piloting organizations, and focus groups.
The CMMI Product Team evaluated more than 3,000 change requests to create CMMI version 1.0. Shortly thereafter, version 1.02 was released, which incorporated several minor improvements. As with any release, opportunities for improvement remained.
Version 1.1 incorporated improvements guided by feedback from early use, more than 1,500 change requests submitted as part of the public review, and hundreds of comments as part of the change control process.
The latest upgrade to the CMMI Product Suite, Version 1.2 is already operational from early 2007. The sunset period of Version 1.1 is August 31st 2007.
Version 1.1
Introduction
The intent of CMMI V1.1 is to provide a CMM that covers product and service development and maintenance but also provides an extensible framework so that new bodies of knowledge can be added. Four bodies of knowledge are used when planning process improvement using CMMI V1.1:
• Systems engineering
• Software engineering
• Integrated product and process development
• Supplier sourcing
Systems Engineering
Systems engineering covers the development of total systems, which may or may not include software. Systems engineers focus on transforming customers’ needs, expectations, and constraints into products and supporting these products throughout their life.
Software Engineering
Software engineering covers the development of software systems. Software engineers focus on applying systematic, disciplined, and quantifiable approaches to the development, operation, and maintenance of software.
Integrated Product and Process Development
Integrated product and process development (IPPD) is a systematic approach that achieves a timely collaboration of relevant stakeholders throughout the life of the product to satisfy customers’ needs, expectations, and requirements. The processes to support an IPPD approach are integrated with the other processes in the organization.
If a project or organization chooses IPPD, it performs the IPPD best practices concurrently with other best practices used to produce products (e.g., those related to systems engineering). That is, if an organization or project wishes to use IPPD, it must select one or more disciplines in addition to IPPD.
Supplier Sourcing
As work efforts become more complex, project managers may use suppliers to perform functions or add modifications to products that are specifically needed by the project. When those activities are critical, the project benefits from enhanced source analysis and from monitoring supplier activities before product delivery. Under these circumstances, the supplier sourcing discipline covers the acquisition of products from suppliers
Similar to IPPD best practices, supplier sourcing best practices must be selected in conjunction with best practices used to produce products.
Model Structure
Process Area
A process area is a cluster of related best practices in an area that, when implemented collectively, satisfies a set of goals considered important for making significant improvement in that area.
Process Areas for Systems / Software Engineering
If you are improving your systems engineering processes, you should select from the following process areas. The discipline amplifications for systems engineering receive special emphasis.
The process areas are as follows:
• Causal Analysis and Resolution
• Configuration Management
• Decision Analysis and Resolution
• Integrated Project Management
• Measurement and Analysis
• Organizational Innovation and Deployment
• Organizational Process Definition
• Organizational Process Focus
• Organizational Process Performance
• Organizational Training
• Product Integration
• Project Monitoring and Control
• Project Planning
• Process and Product Quality Assurance
• Quantitative Project Management
• Requirements Development
• Requirements Management
• Risk Management
• Supplier Agreement Management
• Technical Solution
• Validation
• Verification
Process Areas for Integrated Product and Process Development
If you are improving your integrated product and process development processes, you will choose from the process areas that are the same as those listed for systems engineering with two additional process areas and additional best practices in the Integrated Project Management process area. The discipline amplifications for IPPD receive special emphasis.
The additional process areas are as follows:
• Integrated Teaming
• Organizational Environment for Integration
Process Areas for Supplier Sourcing
If you are improving your source selection processes, you will choose from the process areas that are the same as those listed for systems engineering with one additional process area. The discipline amplifications for supplier sourcing receive special emphasis
The additional process area is as follows:
• Integrated Supplier Management
No comments:
Post a Comment