Capability Maturity Model CMM for Systems Engineering

Chapter 11 briefly described the capability maturity model (CMM) for software. A current trend is to develop a CMM for systems engineering. It is likely that this effort will be successful and have a significant impact on the systems engineering community.

The Software Engineering Institute (SEI), primary developers of the software CMM, has taken a key position in formulating a CMM for systems engineering (SE-CMM). An important ingredient in its structure is the identification of process areas (PAs), which it considers to be key elements of systems engineering [12.5, 12.6]. PAs have been broken down into three main categories, namely, (1) project, (2) organizational, and (3) engineering. Approximately seventeen preliminary PAs have been established under these three categories. The structure also breaks each PA into base practices (BPs).

The approach to the SE-CMM appears to have strong similarities to that of the CMM for software. It is a maturity model for systems engineering and a related method for assessment. As the software CMM had five levels of maturity (see Chapter 11), this SE-CMM has six levels:

Level 0: Initial Level 1: Performed Level 2: Managed Level 3: Defined Level 4: Measured Level 5: Optimizing

These levels are intended to differentiate the process capability of the organization.

INCOSE has also been investigating a CMM for systems engineering. In this conception, some fifteen key focus areas have been defined under three categories [12.7]:

• Engineering Process —System requirements —System design

—System integration and verification —Integrated engineering analysis

• System Management —Planning

—Tracking and oversight —Subcontract management —Intergroup coordination —Configuration management

—Quality assurance —Risk management

• Organizational

—Process management —Training

—Technology management —Environment and tool support

These key focus areas, at this time, are not precisely the same as the process areas (PAs) of the SE-CMM, but they have the same basic thrust. There are also other differences, and similarities, between the INCOSE approach and the SEI approach to a systems engineering CMM.

With the above SEI and INCOSE approaches as background, three organizations moved forward in order to synthesize these approaches. These organizations were the Electronics Industry Association (EIA), INCOSE, and the Enterprise Process Improvement Collaboration (EPIC). The net result was SECM, the Systems Engineering Capability Model, as embodied in EIA/IS-731 [12.8] (see also Chapter 2). This standard has two parts—the SECM model and the SECM appraisal method. It also has a total of nineteen focus areas, distributed under technical, management, and environment categories.

Another notable piece of work was the formulation of the iCMM (the Integrated Capability Maturity Model) by the Federal Aviation Administration (FAA) [12.9]. This model was focused upon the acquisition of software intensive systems and contains the process areas (PAs) listed below:

• Life Cycle or Engineering Processes

PA 01—Needs PA 02—Requirements PA 03—Architecture PA 04—Alternatives PA 05—Outsourcing

PA 06—Software development and maintenance

PA 07—Integration

PA 08—System test and evaluation

PA 09—Transition

PA 10—Product evaluation

• Management or Project Processes

PA 11—Project management PA 12—Contract management PA 13—Risk management PA 14—Coordination

• Supporting Processes

PA lS—Quality assurance and management PA l6—Configuration management PA It—Peer review PA lS—Measurement PA l9—Prevention

• Organizational Processes

PA 2O—Organization process definition PA 2l—Organization process improvement PA 22—Training PA 2S—Innovation

Finally, with respect to this overall topic, the SEI set forth the CMMI, also an integrated version of the Capability Maturity Model [12.10]. This form of the CMM concept was intended to provide ''guidance for improving your organization's processes and ability to manage the development, acquisition, and maintenance of products and services.''

The significance of the preceding, however, is not that there are different approaches to formulating a systems engineering or integrated CMM. Rather, this body of work represents a trend toward better understanding of the elements of systems engineering and the improvement of the internal processes of systems engineering and its management. This can only have a beneficial effect on both the theory and practice of systems engineering.

12.2.4 Systems Architecting

All of Chapter 9 is devoted to a key element of systems engineering, namely, the architecting of the system. As important as this element is, one can expect that efforts will continue to attempt to define and develop how architecting is to be accomplished. Because it is fundamentally a design or synthesis process, it differs from analysis in that one is attempting to ''invent'' a new configuration that may not have existed before. Fascination with the creative process of architecting a new system is not misplaced.

As stated in Chapter 9, E. Rechtin has played a key role in studying the sometimes mysterious process of system architecting. Beyond his seminal books in this area [12.11, 12.12], Dr. Rechtin has continued to explore the subject of systems architecting. For example, in examining the foundations of systems architecting [12.13], he indicates that systems architecting ''is focused and scoped by six core concepts or ideas: the systems approach, purpose orientation, ultraquality, modeling, experience-based heuristics, and certification.'' At about the same time, he also commented on the role and responsibility of the systems architect [12.14]. Questions (and answers) that he poses in this regard are as follows:

• How do I know that the system has been satisfactorily completed?

Rechtin continues to emphasize heuristics as a major factor in systems ar-chitecting, citing heuristics with respect to architecting qualitative change, maintaining system integrity, and systems acceptance. These heuristics and their value apparently came as a ''great surprise.'' Many systems engineers recognize this in terms of ''rules of thumb'' that they use in order to architect new systems. Such rules are experience-based and are a testament to the extensive domain knowledge of the best systems engineers.

The issue of systems architecting was also examined in some detail at a workshop sponsored by the Navy Department [12.15], with the central question being how to improve architecting for increasingly complex systems and environments. In response, some of the architecting tenets were defined:

• Adherence to fundamental architecting principles

• Recognition of a systems architect

• Client involvement

• Keeping the process creative

• Controlled teamwork

It was also suggested that the systems acquisition process should contain a ''systems architecture milestone'' that would contain the following:

• A definition of the systems architecture

• System acceptance requirements

• A rationale that convinces the stakeholders that the system will: —satisfy their overall needs

—satisfy functional, performance, and quality requirements —have an acceptable level of risk

—do the foregoing at least as well as any alternative architecture

Other notions discussed at the workshop were

• The use of an architecture design language (ADL)

• The unique needs of complicated systems

• Methods that enable the architecting of complex systems

• Tools for systems architecting

• Workgroup collaborations

• Taxonomies of system styles

• Training and career paths for systems architects

Another important thrust with respect to systems architecting is represented by the C4ISR (Command, Control, Communications, Computer, Intelligence, Surveillance, and Reconnaissance) Architecture Framework [12.16], as discussed previously in Chapter 9. It will be recalled that this framework was structured around three basic views, namely:

• The operational view

• The technical view

This Architecture Framework was confirmed, in part, by the C4ISR Architectures Working Group (AWG) within the Department of Defense (DoD) [12.17]. In its deliberations, the AWG was broken down into four panels to consider:

• The framework

• Interoperability matters

• Data modeling and analysis tools

• Roles and responsibilities

Based upon their report [12.17], the following recommendation areas were considered:

• Establish common architecture terms and definitions

• Implement a common approach for architectures

• Strengthen architecture policy and guidance

• Define and use levels of interoperability

• Build architecture relationships with other DoD processes

• Manage DoD architectures

The reader is urged to examine both the Architecture Framework [12.16] as well as the AWG Final Report [12.17] in order to obtain a full understanding of the significance of these efforts.

Based upon these and other stated interests in this subject, it may be expected that continuing research into and application of various processes of systems architecting will yield results that can be brought into the mainstream of systems engineering practice.

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