The Structure of Systems Engineering

Fortunately, the overall structure of systems engineering appears to be under constant examination. The Navy workshop [12.15] previously cited did so by exploring the state of the art as well as recommendations for the future in the following key focus group areas:

• Design capture

• Evolutionary systems

• Infrastructure and tools

• Organizational/institutional learning

• Systems architecting

• Reengineering

Results in these areas cannot be reiterated here, but it is clear that the very structure of systems engineering is being analyzed in considerable detail, with participation of many of the best systems engineers in the country.

While mentioning the best systems engineers, it is also necessary to acknowledge the varied, prolific, and significant work, over many years, of Andrew Sage [12.20, 12.21, 12.22, 12.23]. As an example, in 1994, Dr. Sage discussed the ''many faces of systems engineering'' in the INCOSE inaugural issue of its journal [12.24]. Among the topics examined were

• Systems management

• Systems methodology

• Knowledge types

• Formulation, analysis, and interpretation

• Life-cycle models

• Interactions across life cycles

• Architecture levels

Another examination of the structure of systems engineering was carried out by the Software Productivity Consortium (SPC), expanding its original charter from software considerations to the broader context of systems [12.25]. The result was a tailorable process for systems engineering that was given the name of Generic Systems Engineering Process (GSEP). The basic notion was to view all elements of systems engineering in terms of the detailed processes that were required in order to carry them out. In effect, it was equivalent to taking the thirty elements of systems engineering defined here and answering the question: What process is necessary for the proper execution of each element? In order to give the process descriptions some rigor, ICAM (Integrated Computer-aided Manufacturing) Definition (IDEF) diagrams were used as descriptors. This method is also embodied in several systems/software engineering tools so that the process flows are easily automated.

These are but a few of the many examinations of the basic structure of systems engineering that are under constant scrutiny and reevaluation. It is believed that trends in this direction are helpful and likely to continue indefinitely.

12.2.7 Systems Engineering Environments and Tools

Given the thirty elements of systems engineering and descriptions of the processes required to carry out these elements, two natural questions that follow are:

1. Is there a set of automated tools that the systems engineering team can use?

2. Can these tools be integrated in some fashion to create a ''systems engineering environment'' (SEE) with which the team can operate in a highly effective and efficient manner?

A book by this author concentrated on answering the first of these [12.26], and also made it clear that a large number of such tools have been developed for other purposes, and that many were focused on software engineering. Further developments with respect to system of systems (S2) engineering, as discussed earlier in this chapter [12.3, 12.4], depended highly on the availa bility of systems engineering supporting tools. This situation is true today with tool developers giving emphasis to applications in software engineering and even business process reengineering (BPR) [12.27], in distinction to systems engineering. The need for tools that support systems engineering has now been widely recognized, and groups such as INCOSE and others [12.28] are working on this issue as a continuing activity.

With respect to a systems engineering environment, a leading position was taken by the Air Force's Rome Laboratory in developing the System Engineering Concept Demonstration (SECD). The primary goal of this program was to ''increase the productivity and effectiveness of system and specialty engineers involved in the development, maintenance, and enhancement of military computer systems'' [12.29]. Within the scope of this effort, the Air Force specifically addressed the automation of the systems engineering role and the various activities that support systems engineering. These activities fell into the categories of engineering, communications, and management.

Ultimately, the program focused on the development of Catalyst, an automated systems engineering environment that targeted the systems engineering team as the user and addressed these three categories. The building blocks of Catalyst were tools that dealt with interface mechanisms and environment frameworks that took the form of:

• Process automation

• Generic engineering and management tools

• Concurrent engineering groupware

• Integration mechanisms

• Environment adminstration tools

Documentation of SECD was produced in six volumes addressing:

1. Systems engineering needs

2. A process model

3. Interface standards studies

4. Technology assessments

5. Trade studies

6. A security study

From this point, the SECD program transitioned from exploratory to advanced development that involved the building of critical Catalyst components.

Because systems engineering continues to be a process that calls for considerable ingenuity in working with massive amounts of information, it is likely that efforts to build automated systems engineering environments will continue for the indefinite future. One key issue is the extent to which these environments are designed to incorporate tools that are fully integrated, that is, tools that work together so as to minimize rekeying and manual transport of data. Another, of course, is the scope of these tools. In the context of this book, that question may be stated as: To what extent does such an environment cover the full thirty elements of systems engineering? These issues carry forward into constructing a software engineering environment, otherwise known as CASE (computer-aided software engineering). Further discussion of these points appear later in this chapter under the subject of software engineering trends.

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