4.6 Systems engineering: the recent development of a discipline
The recent development of systems engineering can be dated from two events. First, following the lead of the US Department of Defense and its introduction of standards for contractors, systems engineering was taken up by companies such as Boeing, Lockheed Martin and, in the UK, British Aerospace, Marconi and the Lucas Group. Second, in August 1990, a group of individuals interested in systems engineering met in Seattle (Box 10 – extract from a paper presented at the International Committee for Systems Engineering Symposium in 1996). This was the beginning of first the National Council on Systems Engineering and then the International Council on Systems Engineering.
Box 10 The recent development of systems engineering
In August of 1990 a group of 35 individuals, recognized for their interest, knowledge, and expertise in systems engineering, met in Seattle to discuss the need for a professional organization to foster the definition and understanding of systems engineering. The cost of attendance was submission of the individual's concept or definition of systems engineering. The submitted definitions were categorized into four groups. The first group believed systems engineering to be a functional discipline of system engineers with the practice restricted to technical activities. The second group considered systems engineering to be a discipline of system engineers with practice including both technical and management activities. The third group expressed systems engineering as a set of technical activities practiced by any required discipline, not just system engineers. And, the fourth group believed systems engineering to be a set of technical and management activities practiced by any required discipline.
Thus, from the beginning, INCOSE has been composed of persons with differing views of what systems engineering is. It is because of these different views that INCOSE did not attempt to define the term. Doing so was considered as being counter productive to the purpose and objectives of the new Council. The intent of the founders was to include all who shared the vision that systems could be developed and produced at a lower cost, delivered on schedule, and provided with expected performance attributes if more system qualified engineers and better processes, methods and automated tools were available.
Recognition of systems engineering
In the years since inception of INCOSE, enterprises have been found in which system engineers, systems engineering organizations, and the term systems engineering itself are not recognized as needed disciplines, organizations, or practices. To such enterprises, systems engineering is analogous to high overhead, too much unnecessary documentation, and other costly Department of Defense oversight practices. This is not to say that these enterprises do not accomplish systems engineering. They do, and in many enterprises with relative success. They could, however, like most enterprises with system engineers, systems engineering organizations and established systems engineering practices, accomplish the engineering of systems more efficiently and effectively if a disciplined, comprehensive systems engineering approach or process were utilized.
Enterprises that have shunned systems engineering because of perceived negative connotations, have adopted and fostered terms such as Concurrent Engineering and Integrated Product (and Process) Development. The trend lately is for enterprises with a history of embracing systems engineering, including the Department of Defense, to adopt these new terms to avoid the confusion related to systems engineering. Much of this can be directly attributed to a lack of appreciation of exactly what systems engineering is.
Commercial systems engineering standards
This confusion and the perceived need for other terms to describe the engineering of systems is unfortunate, but understandable. The animosity (often hostility) toward systems engineering is one reason new commercial systems engineering standards (EIA/IS 632 and IEEE 1220 – 1994) have not received wide acceptance, even within INCOSE.
Whereas system engineers look at these standards as much broader than what they do, non-system engineers look at the standard titles and come up with the conclusion that the standards are not relevant to their work; that they are only applicable to system engineers. The adage ‘don't judge a book by its cover’ is applicable in this case.
The intent of these two new standards is well denned in their respective forward and scope sections. The purpose of the EIA standard is to improve the engineering of systems in oversight or contractual instances. The IEEE standard purpose ‘is to provide a standard for managing a system from initial concept through development, operations, and disposal.’ It explains what any enterprise must do to engineer a system. Its focus is on commercial, non-oversight developments.
Neither standard restricts its tasks to what a system engineer does or for which a systems engineering organization is responsible. Specifically, teams and teamwork are called out to include personnel to ensure that quality factors related to predictability, testability/verifiability, deployability, operability, supportability, trainability, and disposability are designed into system products. Additionally, both standards call for inclusion, as appropriate, of customers/users, subcontractors, and other non-engineering personnel such as marketing, legal and contracting on interdisciplinary teams.
Two processes important to engineering a system are the central focus of the IEEE systems engineering standard. These are the life cycle development process and the systems engineering process. The systems engineering process is the engine, recursively applied, that drives the evolution and maturity of the system through successive stages of development.
Systems engineering in relation to concurrent engineering and integrated process and product development
When the systems engineering envisioned in the standards is compared with the explained concepts and scope of Concurrent Engineering and Integrated Product and Process Development one finds that the purpose and scope of life cycles tasks are essentially the same, that the focus on downstream specialities in upstream design activities is the same, and that the utilization of automated tools is the same. The essential difference, which could lead one to consider the systems engineering approach described in the IEEE and EIA standards as being more comprehensive, is the inclusion of a comprehensive systems engineering process utilized recursively to mature the system solutions, attain customer satisfaction, and satisfy organizational commitments and public expectations.
So, the problems associated with acceptance of systems engineering appear to be based on lack of understanding on just what systems engineering is and what its purpose is.
The other modern development of a variant of systems engineering occurred in the UK from the late 1970s onwards. Under the direction of John Parnaby, Lucas Engineering and Systems Department was established to improve the effectiveness of the disparate group of factories that made up the group. Many were in need of urgent reorganisation and updating in terms of their manufacturing approaches and methods. In response to this need, Parnaby and his staff developed methodologies for product and manufacturing and business systems engineering. Parnaby (1995) stated:
A system is an integrated combination of components designed to follow a common purpose. A systems philosophy demands that an unco-ordinated, piecemeal activity is replaced by a co-ordinated approach in which the identity of the separate parts of the system are subsumed by the identity of the total system. Systems engineering is an art, based on control systems principles, for designing complex systems. Individual elements and subsystems are fitted together to achieve an overall system purpose objective in the most effective way, at the lowest cost, with minimum complexity.
The Lucas approach to manufacturing systems engineering (MSE) is illustrated in Figure 45. This illustrates the activities undertaken as part of the concept design of the system. The methodology lays particular stress upon the need to establish business targets and market plans as the basis for the design of the system. The methodology is designed to be implemented through the work of a multidisciplinary taskforce. The members of the taskforce can be classified into the three groups shown in Figure 46.
As the statement made in the last paragraph of the extract in Box 10 suggests, there remains some uncertainty about the nature and extent of systems engineering. This uncertainty is reflected in the numerous definitions of systems engineering that are current. A selection of these definitions is given in Box 11.
Box 11 Definitions of systems engineering
US Military Standard MIL-STD-499A Systems Engineering:
‘… the application of scientific and engineering efforts to:
transform an operational need into a description of system performance parameters and a system configuration through the use of an iterative process of definition, synthesis, analysis, design, test, and evaluation;
integrate related technical parameters and ensure compatibility of all physical, functional, and program interfaces in a manner that optimizes the total system definition and design;
integrate reliability, maintainability, safety, survivability, human engineering, and other such factors into the total engineering effort to meet cost, schedule, supportability, and technical performance objectives.’
US Military Standard MU-STD-499B Systems Engineering:
‘Systems engineering is an interdisciplinary approach to evolve and verify an integrated and optimally balanced set of product and process designs that satisfy user needs and provide information for management decision making.’
DSMC Systems Engineering Management Guide, January 1990, pp. 1–2:
‘… is the management function which controls the total system development effort for the purpose of achieving an optimum balance of all systems elements. It is a process which transforms an operational need into a description of system parameters and integrates those parameters to optimize the overall system effectiveness.’
IBM Federal Systems Company definition used as the basis for divisions, internal SE practices and education:
‘The iterative controlled process in which users’ needs are understood and evolved, through incremental development of requirements specifications and system design, to an operational system.’
Joe DeFoe and Jim McAuley; November 1991:
‘The processing of building real things to solve real problems within technological, environmental, economic, legal, ethical, cultural, and institutional constraints.’
Computer Aided Systems Engineering, Howard Eisner, Prentice Hall, 1988, page 17:
‘… an iterative process of top-down synthesis, development, and operation of a real-world system that satisfies, in a near-optimal manner, the full range of requirements for the system.’
Field Manual: System Engineering, FM 770–78 Headquarters, Department of the Army, April 1979, pp. 1–2. Summary definition in the introduction of the manual:
‘The transforming of an operational need into a description of system performance parameters and a system configuration.’
Field Manual: System Engineering, FM 770–78 Headquarters, Department of the Army, April 1979, p. C-2. More extensive definition found in the glossary:
‘The selective application of scientific and engineering efforts to:
-
transform an operational need into a description system configuration which best satisfies the operational need according the measures of effectiveness;
-
integrate related technical parameters and ensure compatibility of all physical, functional, and technical program interfaces in a manner which optimizes the total system definition and design;
-
integrate the efforts of all engineering disciplines and specialities into the total engineering effort.’
Fundamentals of Systems Engineering at NASA’, INCOSE/ASEM Proceedings, October 1991, Robert G. Chamberlain and Robert Shishko, PhD, p. 23:
‘… is a robust approach to the design and creation of systems to accomplish desired ends.’
P. M'Pherson, ‘Systems engineering: A proposed definition’, IEE Proceedings, vol. 133, pp. 330–331, Sep. 1986 (3):
‘… is a hybrid methodology that combines policy analysis, design and management. It aims to ensure that a complex man-made system, selected from the range of options on offer, is the one most likely to satisfy the owner's objectives in the context of long-term future operational or market environments.’
INCOSE:
‘Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem:
Operations
Performance
Test
Manufacturing
Cost & Schedule
Training & Support
Disposal
Systems Engineering integrates all the disciplines and speciality groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.’
Lucas:
‘At the core of manufacturing system design is a relatively multidisciplinary engineering function called “Manufacturing Systems Engineering” which tries to view the manufacturing as a whole. It has a broader view point than the traditional disciplines of “industrial engineering” and “production engineering”.’
SAQ 15
From the definitions of systems engineering in Box 11 summarise the characteristics of the approach.
Answer
My definition of the characteristics of systems engineering is:
A holistic, balanced approach. Systems engineering treats the problem, its environment, and the solution as a whole, not as a set of disconnected parts. The system and its environment have to be considered as an entity. Trade-offs between requirements, costs and timescales are an essential part of the work.
Creativity and domain knowledge. Systems engineering demands intense creativity, particularly in the system requirements and architectural design processes. The role is far more than coordination and management of other people's work. Systems are made by people, and are the products of clever minds. Indeed, success or failure often turns on the ability of a single brilliant person. The systems engineer must also understand the design domain in some detail to make logical decisions. We need to immerse ourselves in (but not dictate) the detail of systems, and be sensitive to changes that might affect us. Committee-driven approaches will not work. At different stages we need visionaries, inventors, makers, negotiators, organisers and implementers acting as part of a team. Process and tools are essential, but we must allow room for creativity, and sometimes use intuition instead of apparently hard facts.
Coping with risk and change. Risk and human fallibility are constants in system development and operations. We have to predict the operating environment of the system we are constructing. The perfect design is beyond our reach, reason has its limitations, and life is not predictable. Yet the systems must still work reliably and safely. Continuous change is hard enough to handle and requires constant awareness of the business environment. Discontinuous change is even more difficult to survive. Although systems engineering is about prediction and direction, the future is only partially discernible. We cannot anticipate every problem, but we must build systems which can cope with change.
Managing complexity. Modern systems are large, intricate and difficult to develop. They need discipline, organisation, traceability, planning, and allocation of responsibilities to ensure efficient development. Systems engineering processes and tools help contain the problems which result from this complexity, in both product and development process.
Reusing experience. An intricate system like a car is built on a century's work by a million engineers. Few core concepts need be invented, and we must be humble in learning from the past. This requires sharing of what we know, in the form of best practice for products and processes. This should be based on reality more than dry theorising.
A user-driven approach. Users are the experts at using the system. We have to build systems which satisfy them, or risk product or even business failure. Requirements management is therefore a key activity for the systems engineer, pervading the whole life cycle.
Whole-life consideration. Systems have a natural cycle, from conception and birth, and then through useful life until disposal. They may live on, transformed through evolution, or spawn successor products, reusing parts of the original blueprints. They are often coupled to other systems with which they must co-evolve to survive. Early decisions may impact much later in a product life cycle, and systems engineering must be aware of the downstream consequences.
Comprehension of multiple disciplines. Systems engineers inevitably interact with many specialist disciplines. They must understand enough about these specialist skills to know what is vital for success, and how to deploy them. Although systems engineers are generalists, they must never imagine that they can do what they want or succeed on their own. Systems engineering is a service to others, providing a realistic framework for specialist knowledge.
Improving the performance of the team. Systems engineering involves many different roles through the life cycle. Developing a complex product is always a team effort, and methodologies must always take into account the interactions within a creative team. We must improve the teamwork to conquer difficult problems that no single person could have solved alone. The customer and the supplier must share risks from an early point, or the customer needs to take the systems engineering work to a point where risk is acceptable. The last few years have seen an increase in integrated stakeholder teams and concurrent engineering, based on partnership and information sharing.
Management of information. Systems engineering is not a technical discipline like software or mechanical engineering because it defines the products to be implemented by others. Information modelling and management are essential to direct the system development.
Linkage to business goals. Engineering of complex systems can succeed only within businesses providing trained staff, finances, facilities, practices and tools. Market-leading systems businesses commit to continuous system improvement, and spread these concepts through their supply chain. Systems engineering principles also apply to the building of those organisational support systems.