This document proposes a framework for a systems engineering body of knowledge (SEBOK). It notes that currently, systems engineering has no recognized body of knowledge, making it difficult to teach. The document analyzes several existing models of systems engineering and proposes combining two models to form the framework. It then outlines a roadmap for developing the SEBOK and how it could enable world-class postgraduate degrees in systems engineering through distance education.
This document proposes a framework for a systems engineering body of knowledge (SEBOK). It notes that currently, systems engineering has no recognized body of knowledge, making it difficult to teach. The document analyzes several existing models of systems engineering and proposes combining two models to form the framework. It then outlines a roadmap for developing the SEBOK and how it could enable world-class postgraduate degrees in systems engineering through distance education.
This document proposes a framework for a systems engineering body of knowledge (SEBOK). It notes that currently, systems engineering has no recognized body of knowledge, making it difficult to teach. The document analyzes several existing models of systems engineering and proposes combining two models to form the framework. It then outlines a roadmap for developing the SEBOK and how it could enable world-class postgraduate degrees in systems engineering through distance education.
11th International Symposium of the INCOSE, Melbourne, Australia, July 200 Page 1.
A Framework for a Systems Engineering Body
of Knowledge Joseph Kasser D.Sc., C.Eng., CM Systems Engineering and Evaluation Centre University of South Australia School of Electrical and Information Engineering F2-37 Mawson Lakes Campus South Australia 5095 Telephone: +61 (08) 830 23941, Fax: +61 (08) 830 24723 Email: [email protected] Angus Massie Defence Science and Technology Organisation PO Box 1500 Salisbury South Australia 5108 Email: [email protected] Abstract. At this time, systems engineering has no recognized body of knowledge. Without such a body of knowledge, systems engineers have difficulty agreeing on exactly what systems engineering should be and academia has difficulty in teaching it. This paper first summarizes a number of models of systems engi- neering and proposes a framework for a systems engineering body of knowledge (SEBOK) based on a combination of two of the models. The paper then proposes a road map for the development of the SEBOK, a way to offer a world class postgraduate degree and closes with some perspectives on systems engineering that become visible when system engineering is viewed within the framework. INTRODUCTION 1 The demand for systems engineers and postgradu- ate degrees in systems engineering (by course- work) is growing both in Australia and around the world. However, meeting that demand is not a simple affair 2 . There is a scarcity of qualified per- sonnel who truly understand the nature of systems engineering and can teach systems engineering subjects in academia. A major problem faced by academia is deciding what subjects to teach 3 since before one can teach systems engineering, one has to define the term. At present systems engineer-
1 This work was partially funded by the DSTO Centre of Expertise Contract 2 Although this paper has a focus on the academic teaching for Systems Engineering, it would be ap- propriate to ask whether this is the best approach. In particular one could ask whether this discipline is better developed via in-house training rather than in a university. For example, it is worth noting that there is some evidence (e.g. McCornick in R&D Management #2, 1995) that the Japanese value internal more than external training. 3 Actually this is may be a little broader since one may also need to identify the pre-requisites for starting to understand system engineering. ing Covers a broad spectrum of activities from soft systems and organizations to hard computer based systems. Is a vague term with many different interpre- tations. Table 1 contains a number of defini- tions of systems engineering. Reading these definitions, it appears that the state of the art of systems engineering appears to be comparable to the state of electrical engineering before the advent of Ohms law (Kasser 1996) or physics before the Newtonian laws. The INCOSE definition is a compromise designed to satisfy everyone and fails to do so. Has a number of process standards and Capa- bility Maturity Models which are focussed on the subset of activities involved in the devel- opment of computer based systems. Has no standard for competence (Kasser 2000). As such, Many systems engineers cannot clearly ar- ticulate the functions and benefits of systems engineering (Kasser and Shoshany 2000). 11th International Symposium of the INCOSE, Melbourne, Australia, July 200 Page 2. It has been extremely difficult to establish systems engineering body of knowledge (SE- BOK) for the diverse activities that are known by the term systems engineering. The Systems Engineering and Evaluation Centre (SEEC) at the University of South Australia Systems Engineering is an interdisciplinary approach and means to enable the realisation 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. INCOSE, (http://www.incose.org/whatis.html on 9 th November 2000) Systems Engineering integrates all the disciplines and specialty 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. Andrew Sage Systems Management for Infor- mation Technology and Software Engineering ISBN0-417-01583-3 Wiley 1995 Systems Engineering. This area comprises systems analysis, systems integration and human factors including human-computer interaction. Anderson and Dibb Strategic Guidelines for enabling research and development to support Australian Defence par 121 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 manage- ment decision making. Mil-STD-499B Systems Engineering ... the application of scientific and engineering efforts to transform an operational need into a descrip- tion 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 optimises 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 per- formance objectives. MIL-STD-499A Systems Engineering 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, pg 1-2. ... is a robust approach to the design and creation of systems to accomplish desired ends. "Fundamen- tals of Systems Engineering at NASA," INCOSE/ASEM Proceedings, October 1991, Robert G. Chamberlain and Robert Shishko, Phd., pg 23. ... 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 sat- isfy the owner's objectives in the context of long-term future operational or market environments. P. M'Pherson, "Systems engineering: A proposed definition," IEE Proce., Vol. 133, pp. 330-331, Sep. 1986. is the management function which controls the total system development effort for the purpose of achieving an optimum balance of all system 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 ef- fectiveness. DSMC Systems Engineering Management Guide, January 1990, pg 1-2. The iterative controlled process in which users needs are understood and evolved, through incremental de- velopment of requirements specifications and system design, to an operational system. IBM Federal Systems Company definition used as the basis for divisions, internal Systems Engineering practices and education. an iterative process of top-down synthesis, development, and operation of a real-world system that sat- isfies, in a near-optimal manner, the full range of requirements for the system. Howard Eisner Computer Aided Systems Engineering, , Prentice Hall, 1988, pg 17. is a discipline created to compensate for the lack of strategic technical knowledge and experience by middle and project managers in organizations functioning according to Taylor's "Principles of Scientific Management". Kasser, J.E., Systems Engineering Myth or Reality, INCOSE 6th International Sym- posium, Boston, MA, 1996 Table 1 A selection of definitions o f systems Engineering 11th International Symposium of the INCOSE, Melbourne, Australia, July 200 Page 3. (UniSA) has developed a global reputation for ex- pertise in systems engineering. By virtue of its re- search, SEEC also has expertise in software engi- neering, distance education techniques, and distrib- uted collaboration environments. Consequently SEEC is in an ideal position to offer world wide postgraduate degrees (by coursework) in systems and software engineering via distance education. SEEC can provide subjects to cohorts of students at any location at times convenient to the students. However, as stated above, there is one factor that precludes the offering; there is no widely recog- nized body of knowledge for systems engineering, although two starts have been made in assembling a SEBOK A curriculum for teaching a few subjects in the context of an undergraduate degree has been presented (Faulconbridge and Ryan 1999). The INCOSE Education and Research Techni- cal Committee (IERTC) is collecting informa- tion that describe academic curricula for use in developing a SEBOK. POTENTIAL FRAMEWORKS Without a framework in which to place the collec- tion of knowledge, the information may be incom- plete. Several models that have the potential to act as a contextual framework for a taxonomy of the SE- BOK have been published. The following models are discussed in this paper Allison and Cook. Hitchins Five-layer Model. Sages Three Overlapping facets Model. Badaways Master of Technology. Kassers People Process Product Time (PPPT) enterprise framework. Allison and Cook (Allison Cook and Allison 1998) proposed that military systems thinking and practice needs to be extended to encompass a sys- tems hierarchy which includes systems and sys- tems-of-systems (SOS), systems-of-SOS, et cetera. No longer is the focus only on the acquisition and use of individual systems, but now there is a need to consider the forest of systems and how they can be integrated in a variety of ways to satisfy different military purposes. This extension of sys- tems engineering presages the creation of new methods and tool sets to support the new activities. In moving to address total capabilities, systems engineers need to move away from acquisition of individual systems, to the acquisition of super sys- tems that are not obtained through a single acquisi- tion exercise, nor necessarily under the direction of a single authority. They proposed an approach based on architectures in which a military enterprise architecture 4 would be developed that is in reality a dual architecture The Preparedness Architecture - describes the tasks and Defence elements needed to de- velop, train, and prepare the Force, and the relationships, interactions, and information flows between these elements. The Joint Operations (or Warfighting) Ar- chitecture - describes those tasks, operational elements, and information flows that support actual operations (warfighting). Hitchins Five-layer Model - Hitchins (2000) proposed the following five-layer model for sys- tems engineering Layer 5 - Socioeconomic, the stuff of regula- tion and government control. Level 4 - Industrial Systems Engineering, or engineering of complete supply chains/circles. Level 3 - Business Systems Engineering - many businesses make an industry. At this level, systems engineering seeks to optimize performance somewhat independent of other businesses. Level 2 - Project or System Level. Many proj- ects make a Business. Western engineer- managers operate at this level, principally making complex artifacts. Level 1 - Product Level. Many products make a system. The tangible artifact level. Many en- gineers and their institutions consider this to be the only "real" systems engineering. Hitchins states that the 5 layers form a "nest- ing" model, i.e. many products make a project, many projects make a business, many businesses make an industry and many industries make a so- cio-economic system. Clearly, these statements are only approximate since-
4 The military enterprise architecture view is de- fined as a description of the tasks and activities, military elements, and information flows required to accomplish or support a military function or operation. 11th International Symposium of the INCOSE, Melbourne, Australia, July 200 Page 4. A socioeconomic system has more in it than just industries. A business has more in it than just projects, and so on. Actual organizations may divide the work in different ways resulting in either sub-layers, or different logical break points. Sages Three Overlapping Facets Model - Sage (1995) suggests that System Engineering needs to be dealt with as 3 overlapping facets namely of structure, function and purpose. These overlap and he provides a definition for each. He then divides each as follows Purpose - Systems Management and consists of enterprise, process re-engineering, process maturity, organizational environment, organ- isational culture, strategic costs and effective- ness metrics, benchmarking and strategic quality (TQM) Structure - Systems Methodology and con- sists of life cycles, concurrent engineering, structural effectiveness metrics, decision as- sessment, structural economic analysis, cogni- tive ergonomics, configuration control and quality assurance. Function - Systems Engineering Methods and Tools and consists of performance metrics, control and communications theory, require- ments engineering, functional economic analy- sis, programming languages, simulation and modeling, operations research and quality control and statistics. If the actual core discipline of programming at the lowest level was replaced by core specialist knowledge this structure could be used for a SE- BOK. However, each of the three facets would still be complex. Badaways Master of Technology - Badaway (1995) argues that the need is for engineering management training, and describes a possible Masters level course that is a hybrid MBA/ME that he calls a Master of Technology (MOT). However, it has a high level of overlap with Systems Engi- neering. The starting place is that the National Research Council defines MOT as linking engi- neering, science and management disciplines to address the issues involved in the planning, devel- opment and implementation of technological capa- bilities to shape and accomplish the strategic and operational objectives of an organisation. In par- ticular shaping is very important since most sys- tems engineering starts with the idea of filling a pre-defined requirement, but in reality the technol- ogy often produces new capability that meets what no-one had envisaged as a requirement when the project began. The overall framework he proposes is to meet the following eight primary needs. 1. How to integrate technology into the overall strategic objectives of the firm 2. How to get into and out of technologies faster and more efficiently. 3. How to assess/evaluate technology more effi- ciently. 4. How to accomplish technology transfer. 5. How to reduce new product development time 6. How to manage large, complex and interdisci- plinary or inter-organizational projects/systems 7. How to manage the organizations internal use of technology. 8. How to leverage the effectiveness of technical professionals. Kassers People Process Product Time (PPPT) Enterprise Framework - The PPPT approach (Kasser 1995) is a control and information system paradigm rather than a production paradigm. It views the enterprise from the perspective of Infor- mation Systems, the application of Knowledge Management, and modern Quality theory. It has explicit emphasis on Configuration Management and building Quality into the process. PPPT combines prevention with testing and is based on the recognition that prevention is planned anticipation (Crosby 1981). It is used within an Organizational Engineering or integrated product- process and management paradigm (Kasser 1999). The most significant factor in the PPPT approach is the recognition that cost reductions [improvements] in the product and process do not occur in a vac- uum. The product under construction is a system and the process producing the product is a system. Thus, the process, product and organization repre- sent three tightly coupled dimensions of quality and must not be considered independently. In addition, every one of the systems changes over time. Frosch (1969), when he was Assistant Secre- tary to the United States (of America) Navy wrote: Systems, even very large systems, are not devel- oped by the tools of Systems Engineering, but only by the engineers using the tools. Engineers are people. PPPT emphasizes effective people (Covey, 1989)] since people working within the context of 11th International Symposium of the INCOSE, Melbourne, Australia, July 200 Page 5. an enterprise framework (system) build a product over a period of time. From the PPPT perspective, systems engi- neering is a time-ordered sequence of activities in a multi-threaded environment managed by the Con- figuration Control Board (CCB). PPPT combines prevention with in-process testing in a synergistic manner to eliminate defects and so reduces project cost and schedule overruns. The PPPT task man- agement methodology Emphasizes teamwork and customer involve- ment. Is loosely based on a methodology used for at least eight years in a task-ordered environment by a large contractor to the National Aeronau- tical and Space Administration (NASA). Improves on the basic methodology by adding the elements of Quality. The improvement: Ensures work is performed in a cost-effective manner. Maps very well into managing tasks per- formed in geographically distributed locations by different elements of a distributed organi- zation. Intrinsically incorporates task management into program management. Builds the Quality into the task. Reduces the cost of doing work. Allows the needed staffing levels and skill-mix to undergo the gradual change required to per- form the planned work in an optimal manner as tasks progress through their life cycle. Monitors task and contract performance rela- tive to the baseline plan. Develops measures of effectiveness of the work. Incorporates control functions that effectively deal with deviations from the baseline plan in a timely manner. Deming (1986) wrote: Improvement of quality and productivity, to be successful in any company, must be a learning process, year by year, top man- agement leading the whole company. Drucker (1995) discussed learning organizations as organi- zations in continuous change. PPPT includes Continuously monitoring and improving the task: Training before doing, and applying les- sons learned on one project to the next (the feedback loop). Prevention and continuous improvement are important elements of the Malcolm Baldridge National Quality Award. Making the Technical Performance Meas- urements: Supplying the standards and con- trols for the current task to provide: Visibility of actual vs. planned perform- ance. Early detection or prediction of problems which require management attention. Managing changes: Supporting the assess- ment of the program impact of proposed change alternatives. Acting as the advocate for the customer: During the design and test phases of the task and whenever the customer is not present. Performing Risk Management: Identifying and mitigating risks to future tasks. Tracking implementation: Allowing the Pro- gram Manager to ensure that tasks are com- pleted on schedule. A FRAMEWORK FOR THE SEBOK The Hitchins five-layer model provides a useful basis for illustrating how each level "lives within", and contributes to, the one above and how enablers and constraints at one level affect the lower levels. Viewing systems engineering in Hitchins frame- work shows that the IERTC is focussed mainly on levels 1-3 and that Badaway framework focuses much more on the upper levels of Hitchins model. However, a broader 5 perspective is needed for a more complete SEBOK. Now if the Hitchins five layer model is enhanced by adding the second di- mension of the phase or time, the resulting matrix allows one to provide both the perspective (ie level) and purpose (ie phase) for each activity needed in System Engineering and hence a justifi- cation for why its needed. For example, each of the Hitchins levels contains different processes needed to look at the overall aims (ie ConOps), obtaining the requirements, creating 6 , introduction to service, using, evolving, and retiring a system. The PPPT model which describes the product in the context of the process, people and organiza- tion and the changes over time as the product is
5 Levels 3-5 are often regarded as management rather than engineering and as such in the aca- demic world are taught via MBA courses. 6 Creating includes design, build and testing. 11th International Symposium of the INCOSE, Melbourne, Australia, July 200 Page 6. constructed allows more dimensions to be added. By combining the PPPT and Hitchins models into a multi-dimensional framework, it should be possible to identify appropriate knowledge, standards, and methodologies for each level within the framework of products, processes, people and organisation. The information appropriate to each layer should be identifiable from experience and verified in the literature. Development of the draft SEBOK is planned to take the following form. For each layer in the Hitchins model, the following will be done in an iterative manner: Develop a glossary of terminology. The glos- sary is to contain references to the source of the use of a word within a given context. Develop a concept of operations of the activi- ties being undertaken by means of scenarios or use cases. Based on the activities, identify the knowledge needed and appropriate methodologies for cost effective work. Develop the vertical interfaces to adjacent layers in the model. Identify the horizontal interfaces to adjacent professions to determine the degree of overlap between systems engineering and other profes- sions. Search the literature to provide sources for the knowledge in the layer. Document the SEBOK using the software en- gineering body of knowledge as a guide in the manner that the systems engineering CMM was developed from the software CMM. Each layer of information then needs to be verified and validated. To ensure the appropriateness of the information in each layer, representatives from Industry and INCOSE should verify the informa- tion. Once the first draft of the SEBOK has been compiled it will be used to develop a curriculum for postgraduate education in systems engineering. COMMENTS Once the draft SEBOK is available, then the knowledge has to be mapped into subjects and ap- propriate instructors found. Due to the broad nature of the material, it can be expected that no single academic institution will have expertise in all subjects. Thus while they may be able to teach them, Industry would be better off if all the subjects were taught by experts. Distance education technology has made it possible for institutions to teach off-campus students either in cohorts or as individuals using local or distant instructors (Kasser 2000 unisadl). PERSPECTIVES FROM THE FRAME- WORK Even now with a rudimentary framework in place, several causes of confusion can be identified. For example Semantic confusion a word may have a different meaning in a different level. For ex- ample, the term capability has different meanings in layers 1 and 3. Traceability of requirements requirements on a system in layer 1 can be traced back to the socioeconomic situation in layer five. SUMMARY The advantages of using the layer framework for assembling the SEBOK include: Provides a Rosetta stone for communications between different systems engineers. This should avoid the need to continually redefine terminology. Provides visibility into what systems engineers actually do. Identifies differences in methodologies and tools between hard and soft systems activities. Identifies skills and hence training needed at each level. REFERENCES Allison, J.S., Cook, S.C., The new era in military systems thinking and practice, Proceedings of Systems Engineering 98, Systems Engineering Society of Australia, IEAust, Canberra, No- vember, pp 11-19, 1998. Badaway, M., EMR Fall 1995 Educating Tech- nologists in Management of Technology. Covey, S. R., The 7 Habits of Highly Effective People, Simon & Schuster, 1989. Crosby, P.B., The Art of Getting Your Own Sweet Way, Second Edition, McGraw-Hill Book Company, p 131, 1981. Deming, W.E., Out of the Crisis, MIT Center for Advanced Engineering Study, 1986. 11th International Symposium of the INCOSE, Melbourne, Australia, July 200 Page 7. Drucker, P., Managing in a time of Great Change, Truman Talley Books/Dutton, New York, 1995. Faulconbridge, I., and Ryan, M., A Framework for Systems Engineering Education, Systems Engineering Test and Evaluation (SETE) Conference, Adelaide, Australia, 1999. Frosh, R.A., "A new look at systems engineering", IEEE Spectrum, September 1969. p 25. Hitchins, D.K., World Class Systems Engineering the five layer model, Http://www.hitchins.co.uk, last accessed 20 March 2001. Kasser, J.E., Systems Engineering Myth or Real- ity, INCOSE 6th International Symposium, Boston, MA, 1996. Kasser, J. E., Applying TQM to Systems Engineer- ing, Boston, Artech House, 1995. Kasser, J. E., Using Organizational Engineering to Build Defect Free Systems, On Schedule and Within Budget, PICMET, 1999. Kasser, J.E., How Collaboration Via The World Wide Web Can Provide A Global Perspective And Truly Provide The Student With A World Class Education, Distance Education an Open Question Conference, Adelaide, Austra- lia, 11-13 September 2000. Kasser, J.E., The Certified Systems Engineer Its About Time!, The Systems Engineering Test and Evaluation Conference (SETE 2000), Brisbane, Australia, 2000. Kasser, J.E., Shoshany, S., Systems Engineers are from Mars, Software Engineers are from Ve- nus, 13 th ICCSEA, Paris, 2000. Sage, A., Systems Management for Information Technology and Software Engineering, Wiley, 1995. BIOGRAPHY Joseph Kasser D.Sc. C.Eng, CM, has been a practicing systems engineer for 30 years. He is the author of "Applying Total Quality Management to Systems Engineering" published by Artech House. Dr. Kasser is both a DSTO Associate Research Professor at the University of South Australia (UniSA) and a Distance Education Fellow in the University System of Maryland. He performs research into improving the acquisition process. Prior to taking up his position at UniSA, he was a Director of Information and Technical Studies at the Graduate School of Management and Technology at University of Maryland University College. There, he developed and was responsible for the Master of Software Engineering degree and the Software Development Management track of the Master of Science in Computer Systems Management (CSMN) degree. He is a recipient of NASAs Manned Space Flight Awareness Award for quality and technical excellence (Silver Snoopy), for performing and directing systems engineering. Dr. Kasser took part in the development of the Software Engineering BOK and also teaches systems and software engineering in the classroom and via distance education.