Capitulo 1 - Practical Insight into CMMI

Engineering Systems Think
A junção entre engenharia de sistemas e engenharia de softwares CMM® e a melhoria das idéias dos processos resultou no desenvolvimento do CMMI®. Esse capítulo provê uma breve histórico e revisão sobre essas engenharias.

CMM for Software
Establishment of the SEI
In the mid-1980s it became apparent to the United States Department of Defense (DoD) that the myriad of systems that were being developed for defense applications were becoming software intensive, were not meeting the established requirements, and were rapidly becoming cost-prohibitive. The Software Engineering Institute (SEI), as a part of Carnegie Mellon University, was established in 1984 as a federally
funded research and development center (FFRDC) with the mission to provide leadership in advancing the state of the practice of software engineering to improve the quality of systems that are dependent on software.

CMM v1.0 to CMMv1.1
Early questionnaires and model beginnings focused predominantly on software engineering processes. Capability Maturity Model (CMM®) for Software v1.0, released in August 1991, strongly referenced the link to the overall system and the requirements from which the software developers were supposed to work. These requirements were referred to as “systems engineering requirements allocated to software.” As CMM® for Software started to grow in popularity in the early 1990s, the parts of the industry that were more information technology–oriented protested the reference to systems engineering, and CMM® v1.1, released in 1993, no longer maintained that reference.

Software Product Engineering
The software life-cycle functions that coincided with the descriptions found in ISO 9001:1994 were placed all together in a Key Process Area (KPA) called Software Product Engineering. Many debates took place in the hallowed halls of the SEI during the development of CMM® v1.0 regarding the need for a more detailed description of those life-cycle functions versus the containment of the size of CMM® and the number of key process areas that were being developed for CMM® Maturity Level 3. In the end, it was decided to keep only one KPA that described the “engineering” activities or functions and to reduce the content of that KPA to keep it compatible with the rest of the KPAs in CMM®. For many, including the CMM authors, the engineering part of
CMM® was reduced or de-emphasized for the sake of spreading its usage. The need for a systems engineering CMM While the use of CMM® for Software grew rapidly worldwide, it became very clear, very quickly, that the strict focus on software engineering did not satisfy the business or systems needs of the companies that were developing
the software intensive systems. Assessments conducted by Jeff Perdue of the Institute of Software Process Improvement (ISPI) showed that the need for systems engineering process improvement and a systems CMM® was immediate. Following the final presentation of one of these software process assessments led by Mr. Perdue, one senior manager stood up and commented that if he had changed each reference from software engineering to systems engineering, the results would have been just as accurate. Comments like the one above led to the development of a systems engineering
CMM® by the Software Engineering Institute, even though its original charter and government-provided guidance was restricted to software. Eventually, various CMM® models were developed for a myriad of disciplines other than software and systems engineering. These included models for software acquisition, workforce management and development, and integrated product and process development. Although these models proved useful to many organizations, the use of multiple models also became problematic. Organizations desiring to focus their improvement efforts across the disciplines within their organizations ran into difficulties.

2 Engineering Systems Think
including their architectures, contents, and approaches, limited these organizations’ abilities to focus their process improvements efforts successfully. In addition, the application of multiple models that were not consistently integrated within and across an organization resulted in higher costs in terms of training, appraisals, and improvement activities.

The need for an integrated model
CMM® Integration project was formed to sort out the problem of using multiple CMM®s. CMMI® Product Team’s mission was to combine three source models—
(1) Capability Maturity Model for Software (SW-CMM®) v2.0 draft C,
(2) Electronic Industries Alliance Interim Standard (EIA/IS) 731, and
(3) Integrated Product Development Capability Maturity Model (IPD-CMM®) v0.98
—into a single improvement framework for use by organizations pursuing enterprise-wide process improvement.

Systems engineering
Systems engineering covers the development of total systems, which may or may not include software. Systems engineers focus on transforming customer needs, expectations, and constraints into product solutions and supporting these product solutions throughout the entire lifecycle of the product. Software engineering
Software engineering covers the development of software systems. Software engineers focus on the application of systematic, disciplined, and quantifiable approaches to the development, operation, and maintenance of software.

Integrated Product and Process Development(IPPD)
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 better satisfy customer needs, expectations, and requirements. The processes to support an IPPD approach are integrated with the other processes in the organization. The IPPD process areas, specific goals, and specific practices alone cannot achieve IPPD. If a project or organization chooses IPPD, it performs the IPPD-specific practices concurrently with other specific practices used to produce products (e.g., the engineering process areas), that is, if an organization or project wishes to use IPPD, it chooses a model with one or more other disciplines in addition to selecting IPPD.

The need for the integrated model became more apparent as CMMI® evolved into the set of models it represents today. In her work on software engineering at Carnegie Mellon University, Dr. Mary Shaw indicated that The need for an integrated model 3
software engineering is still not considered to be an engineering discipline throughout the world, especially when it is compared to electrical engineering, mechanical engineering, and civil engineering. Leading companies that have software as a part of their products still face cost overruns, schedule slippage, poor performance, and unsatisfied customers. A number of companies have set a precedent with their belief and approach to systems, software, and business goals. They have integrated all three using a unified quality management approach in their process
improvement initiatives. Among those are Motorola, whose Microsystems business unit started developing “product life cycles” in 1985 that included systems, software, hardware, marketing, and manufacturing. In 1990, AT&T realized an increase in productivity and product quality by creating integrated teams that forced marketing, systems, software, and hardware representatives to work together and to be accountable as a team for the delivery of the product. Integrating systems engineering and software engineering activities enabled Ford Aerospace from 1989 to 1992 to regain its competitive position in the command and control marketplace and reach CMM® Maturity Level 3 at the same time.

Systems engineering and systems management
We must first discuss the topics of what systems engineering and systems management are and what some of the commonly accepted functions of a systems engineer are in order to properly talk about engineering systems think. The precise definition of systems engineering is not commonly agreed upon throughout the industry or with the major companies that employ systems engineers. This has led to a great deal of confusion and long hours of wasted debates. Some of the common and not-so-common names for systems engineering include:
◗ Systems engineers;
◗ Systems architects;
◗ Systems integrators;
◗ Systems management engineers;
◗ Systems quality assurance engineers;
◗ Systems theorists;
◗ Systems reengineers;
◗ Operations research (closely related profession);
◗ Management science (closely related profession).
We will try to clarify the confusion. First, let us take a look at the engineering
of systems. Systems engineering is concerned with the engineering

Systems management is concerned with strategic-level management of systems engineering. Systems engineering efforts therefore should involve:
◗ Systems management;
◗ Systems process;
◗ Systems engineering method and tools or technologies.

These three levels of systems engineering are illustrated in Figure 1.1. Systems engineering can be viewed as a management technology. If we break management technology down into its components, we will be able to derive a clearer understanding of systems engineering.

Technology
Technology is the organization, application, and delivery of scientific knowledge,
as well as other forms of knowledge for the betterment of a client group. Technology can be viewed fundamentally as a human activity.

Management
Management involves the interaction of the organization with the environment. The purpose of management is to enable organizations to better cope with their environments in order to achieve purposeful goals and objectives. Management of technology The management of technology (Figure 1.2) involves the interaction of:
◗ Technology;
◗ Organizations that are collections of people concerned with the evolution
and use of technologies;
◗ Environment.


Figure 1.1 Three levels of systems engineering. (From: [1]. © 1999 John Wiley &
Sons, Inc. Reprinted with permission.)


Figure 1.2 Management technology. (From: [1]. © 1999 John Wiley & Sons, Inc.
Reprinted with permission.)

Systems engineering definition
Thus, if we combine all of the definition pieces we have just presented, we can define systems engineering to be the management technology that controls a total system life-cycle process, which evolves and results in the definition, development, and deployment of a system that is high quality, cost-effective, and on schedule in order to meet the user’s needs.

Engineering systems thinking
Over the past 7–10 years, I have worked with a large number of companies that did not have a strong engineering discipline among its software systems developers or its management. While this did not seem to pose a problem when an organization was going through the initial phases of its process improvement initiative, it quickly manifested itself into a deep-seated problem when an organization attempted to develop its action plan. Working groups (WG) or process action teams (PAT) found it difficult to take the necessary steps to move from assessment recommendations to implementation tasks that were:
◗ Described in enough detail to be placed into a project-level plan (complete
with milestones and deliverables);
◗ Prioritized according to organizational business need and project criticality;
◗ Scheduled for implementation according to defined increments;
◗ Able to be implemented within the financial and resource constraints of the organization.

Guidance for Action Planning
The author developed a method for successfully helping an organization make the transition from process assessment to action planning and implementation—Guidance for Action PlanningSM (GAP). The concepts behind GAP come from the application of the engineering principle of decomposition of high-level system descriptions into more manageable subsystems and modules. In other words, this is the application of basic engineering principles to process improvement tasks. However, if an organization does not have both a management team and a workforce that embraces basic systems engineering thinking, it can prove to be painfully hard, if not impossible, to develop actionable process improvement plans. The GAP provides a starter kit for the development of the action plan or plans for individual focus areas. It provides the vital intermediate details to get the organization going in the right direction, thus enabling it to implement and to complete its action planning within a reasonable time frame. It provides direction for the organization’s senior management team and the
process improvement champions to ensure that coordinated action will result from the assessment effort, and that this effort will support the organization’s business objectives. The GAP provides senior management with a big picture of the requirements
for process improvement by showing what needs to be done, who needs to be involved, and what it might take to accomplish true and lasting improvement. This analysis provides a process improvement road map to support management decision making by clarifying how process improvement priorities can map to the corporate vision and business environment. The GAP also provides important information for the Software/Systems Engineering Process Group (SEPG) and others involved in the development of the action plan as it defines the initial steps in the development of the focus area sections of the action plan. These steps are direct transitions from
the assessment results (see Figure 1.3). The GAP assists the SEPG’s facilitation
of the development and implementation of the action plans that will support the process improvement needs of the organization the most. The Guidance for Action PlanningSM provides the bridge between the assessment results and the activities necessary to develop actionable plans for improvement.
Systems thinking Systems thinking is a discipline for seeing the whole. It is a framework for understanding interrelationships and repeated events rather than seeing
things in isolation. Systems thinking is about seeing patterns of change rather than static snapshots. Systems thinking embodies the idea that the interrelationship among the parts relative to a common purpose of a system is what is important. Systems thinking is necessary for successful product development and process improvement.

Figure 1.3 Guidance for Action PlanningSM road map.

The Fifth Discipline
Peter Senge led a team of authors to write a book, The Fifth Discipline: The Art and Practice of the Learning Organization, to describe a path for the “learning organization.” According to Mr. Senge, systems thinking is the fifth discipline“ and is the catalyst and cornerstone of the learning organization that enables success through the other four disciplines” [2]:
1. Personal mastery through proficiency and commitment to lifelong learning;
2. Shared mental models or the organization markets and competitors;
3. Shared vision for the future of the organization;
4. Team learning.
Mr. Senge describes certain truths or laws about the fifth discipline. A few of them are included here to support the concepts of engineering systems thinking.
◗ Short-term improvements often lead to long-term difficulties.
When organizations only focus on the “low-hanging fruit,” they frequently do not establish the basics functions necessary to continue long-term future growth.
◗ The easy solution may be no solution at all.
◗ Quick solutions, especially at the level of the symptoms, often lead to more problems than existed initially.
◗ Cause and effect are not necessarily closely related, either in time or in space. Sometimes solutions implemented here and now will have impacts far away at a much later time.
◗ The entire system, comprised of the organization and its environment, must be
considered together.

Laws of engineering systems thinking
Engineering systems thinking is not merely a slogan; it is composed of basic “laws” that can and should be applied to everyday business life. Here is a summary of some of the more important engineering systems thinking laws according to my educational background and professional experience. Process areas that have been defined in CMM® Integration (CMMI®) appear in brackets and parentheses as indicators of the effort undertaken in the development of CMMI® in order to incorporate engineering systems thinking.
1. In all of the project’s phases/stages, and along the system’s life, the systems engineer has to take into account [Requirements Development (RD)]:
◗ The customer’s organization vision, goals, and tasks;
◗ The customer’s requirements and preferences;
◗ The problem to be solved by the system and the customer’s needs.
2. The whole has to be seen, as well as the interaction between the system’s
elements. Iterative or recursive thinking must replace the traditional linear thinking [RD–Technical Solution (TS)].
3. Project members should always look for the synergy and the relative advantages from the integration of subsystems [TS–Product Integration (PI)].
4. The solution is not always an engineering one. Remember to take into account:
◗ Business and economic costs;
◗ Reuse or utilization of products and infrastructure already developed;
◗ Organizational, managerial, political, and personal considerations.
5. The systems engineer should consider as many different perspectives as possible.
6. Systems engineers and project mangers should always take into account (RD–TS):
◗ Electrical considerations;
◗ Mechanical considerations;
◗ Environmental considerations;
◗ Quality assurance considerations;
◗ Quality factors such as reliability, maintainability, expandability, and testability.
7. Future logistic requirements should be evaluated in all development phases including (RD–TS):
◗ Spare parts;
◗ Maintenance infrastructure;
◗ Support;
◗ Service;
◗ Maintenance levels;
◗ Technical documentation.
8. When a need arises to carry out a modification to the system, always take into account (RD–TS–Requirements Management):
◗ The engineering and nonengineering implications;
◗ The effects on the form, fit, and function;
◗ The system’s response to the changes;
◗ The needs, difficulties, and attitudes of those who must live with the modification.
9. Each problem may have more than one possible working solution (TS):
◗ All possible alternatives should be examined and compared to each other by quantitative and qualitative measurements.
◗ Engineering trade-offs and cost-effectiveness should be considered at every stage.
10. Systems engineers should be encouraged to look for the changes that might introduce significant improvements with minimum effort.
11. Processes that result in slow or gradual results should be taken seriously [Organizational Innovation and Deployment (OID)].
12. A known solution is not always suitable for the current problem. Each available solution should be considered along with the risks, dependencies, and constraints inherent in the evolving system [Generic Practice (GP) 2.2].
13. Development risks must be taken into account throughout the entire product development cycle [Project Planning–Risk Management (RSKM)].
14. It is impossible to run a project without [PP–Project Management and Control (PMC)–Configuration Management (CM)–Generic Practices]:
◗ Control;
◗ Configuration Management;
◗ Milestones;
◗ Management;
◗ Scheduling methods.
15. The end user must be considered as a major part of the system (RD–PP).
16. Engineering systems thinking requires the integration of expertise from different disciplines and requires the examination of different perspectives, calling for teamwork to cover those perspectives [Integrated Project Management, Integrated Product and Process Development, Integrated Teaming (IPM–IPPD–IT)].
17. Selecting partners and subcontractors is critical. Do not enter into a partnership unless the partner is willing to share your risks as well as your successes and profits [Supplier Agreement Management (SAM)].
18. Limit the responsibility assigned to an external factor, since this increases the dependency on it [SAM–Commercial Off the Shelf Software (COTS)].
19. Take the shelf life into consideration when selecting components for production.
20. Engineering systems thinking includes probability and statistics both when defining the systems specifications and when determining the project targets such as cost and performance [Decision Analysis and Resolution (DAR)].

Summary
One of the most prominent problems observed in software and software/ systems organizations today is the lack of engineering discipline, cited by mangers at all management levels. CMM® for Software was developed to encourage organizations to develop processes to guide its software development. CMM® Integration recognizes that engineering systems thinking is an important asset for building systems and has put the “engineering” back into process improvement.

References
[1] Sage, A. P., and W. B. Rouse, Handbook of Systems Engineering and Management,
New York: John Wiley & Sons, 1999.
[2] Senge, P. M., et al., The Fifth Discipline: The Art and Practice of the Learning
Organization, New York: Doubleday, 1990.