A Proposed Framework for a Systems Engineering Discipline
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Conference on Systems Engineering Research 2007, Paper 057 Page 1
A Proposed Framework for a Systems Engineering
Discipline
Joseph E. Kasser
Centre of Excellence in Defence and Industrial Systems Capability
University of South Australia
Adelaide, Australia
Email: Joseph.kasser@incose.org
early stages of a discipline. The paper then
Abstract discusses the elements of a discipline and hy-
The paper discusses the rationale for, and pothesizes that a framework for systems engi-
describes a proposed framework for systems neering exists. Using the scientific method to
engineering in the context of a discipline. This build on an earlier two-dimensional frame-
framework, the Hitchins-Kasser-Massie work, the paper then presents a candidate
(HKM) framework has already facilitated three-dimensional-framework based on the
postgraduate teaching of systems engineering problem solving perspective. The paper then
and has provided reasons why systems engi- discusses some insights that the framework
neers have a plurality of views concerning the has already provided.
scope and nature of systems engineering. The
contribution of this paper is to place the HKM The need for a framework
framework in the context of Kline‟s definition We need a framework because systems
of a discipline. engineering has failed to fulfill 50 years of
promises of providing solutions to the com-
Introduction plex problems facing society. (Wymore, 1994)
George Friedman called for the develop- pointed out that it was necessary for systems
ment of a grand unified theory of systems en- engineering to become an engineering discip-
gineering (GUTSE) (Friedman, 2006) echoing line if it was to fulfill its promises and thereby
the earlier lament by (Hill and Warfield, 1972) survive. Nothing has changed in that respect
who wrote since then. (Wymore, 1994) also stated that
“development of a theory of systems “Systems engineering is the intellec-
engineering that will be broadly ac- tual, academic, and professional disci-
cepted is much to be desired.” pline, the principal concern of which is
to ensure that all requirements for
Taking up the spirit of those challenges,
bioware/hardware/software systems
this paper proposes a framework for systems
are satisfied throughout the lifecycles
engineering that can serve as a vital element in
of the systems. This statement defines
formalizing the discipline of systems engi-
systems engineering as a discipline,
neering and potentially as a platform for de-
not as a process. The currently ac-
veloping such a theory.
cepted processes of systems engineer-
The paper begins with a discussion of the
ing are only implementations of sys-
need for the framework, as a fundamental part
tems engineering.
of a discipline, observes that systems engi-
neering shows the symptoms of being in the Out of more than 50 definitions discovered
Conference on Systems Engineering Research 2007, Paper 057 Page 2
in the literature (Kasser and Massie, 2001; Moving towards a discipline
Kasser and Palmer, 2005), Wymore provided As today‟s systems engineering is in a
the only definition of systems engineering as a similar state to chemistry and electrical engi-
discipline. neering in their formative years, then a major
step forward in the development of the discip-
The elements of a discipline line would be to apply the scientific method to
Consider the elements that make up a dis- postulate a hypothesis (namely a framework
cipline. One view was provided by (Kline, for systems engineering exists); identify and
1995) page 3) who states prototype a candidate framework, test it; mod-
“a discipline possesses a specific area ify it and eventually evolve a working frame-
of study, a literature, and a working work for systems engineering. This frame-
community of paid scholars and/or work would pull together systems engineering
paid practitioners”. in an analogous manner to the application of
the periodic table of elements in chemistry.
Systems engineering has a working com- The hypothesis behind this research is that
munity of paid scholars and paid practitioners. if the activities performed by systems engi-
However, the area of study seems to be differ- neers can be plotted in a framework it may be
ent in each academic institution but with vari- able to bring about a revision of the a priori
ous degrees of commonality. This situation understanding of systems engineering. This
can be explained by the recognition that means a change in the understanding of its
(1) systems engineering has only been in current paradigm (Churchman, 1979) page
existence since the middle of the 20 th 105) or Weltanschauung (Checkland and
century (Johnson, 1997; Jackson and Scholes, 1990), and its emergence as a true
Keys, 1984; Hall, 1962), and engineering discipline. (Kasser, 2006) dis-
(2) as an emerging discipline, systems cussed the evolution of a proposed framework
engineering is displaying the same for systems engineering. This paper places
characteristics as did other now estab- that framework in the context of Kline‟s defi-
lished disciplines in their formative nition of a discipline.
years.
Thus, systems engineering may be consi- Elements relevant to research in
dered as being in a similar situation to the
a discipline
state of chemistry before the development of
the periodic table of the elements, or similar to According to (Checkland and Holwell,
the state of electrical engineering before the 1998) research into a discipline needs the fol-
development of Ohm‟s Law. This is why vari- lowing three items:
ous academic institutions focus on different An Area of Concern (A), which might be
areas of study but with some degree of com- a particular problem in a discipline (area
monality in the systems development life of study), a real-world problem situation,
cycle. Nevertheless, to be recognized as a dis- or a system of interest.
cipline, the degree of overlap of the various A particular linked Framework of Ideas
areas of study in the different institutions (F) in which the knowledge about the area
needs to be much, much greater. of concern is expressed. It includes current
theories, bodies of knowledge, heuristics,
etc as documented in the literature as well
as tacit knowledge.
Conference on Systems Engineering Research 2007, Paper 057 Page 3
Figure 1 Elements relevant to any piece of research (Checkland and Hol-
well, 1998) page 23)
The Methodology (M) in which the the systems engineer is the man who is
framework is embodied that incorporates generally responsible for the over-all
methods, tools, and techniques in a man- planning, design, testing, and produc-
ner appropriate to the discipline that uses tion of today’s automatic and semi-
them to investigate the area of concern. automatic systems” (Chapanis, 1960)
page 357).
Figure 1 extracted from (Checkland and
Holwell, 1998) page 23) illustrates the rela- The principal functions of systems en-
tionship between these elements. Given that gineering are “to develop statements
there is a working community of paid scholars of system problems comprehensively,
and/or practitioners (Kline, 1995) page 3), without disastrous oversimplification,
these same three elements can also be used to precisely without confusing ambigui-
characterise a discipline because they expand ties, without confusing ends and
(Kline, 1995)‟s specification and encompass means, without eliminating the ideal in
the key aspects of a discipline (Cook, Kasser favour of the merely practical, without
and Ferris, 2003). Consider each of these ele- confounding the abstract and the con-
ments in turn, as they apply to systems engi- crete, without reference to any particu-
neering. lar solutions or methods, to resolve
An Area of Concern (A). Pragmatically, top-level system problems into simpler
the Area of Concern (A) should be both what problems that are solvable by technol-
systems engineers do and where they do it. ogy: hardware, software, and bioware,
There have been many diverse opinions on to integrate the solutions to the simpler
these topics over the years, typical examples problems into systems to solve the top-
are (Allison and Cook, 1998; Hitchins, 2000; level problem” (Wymore, 1993) page
Sage, 1995; Badaway, 1995; Kasser, 1995; 2).
Chapanis, 1960; Shenhar and Bonen, 1997;
Wymore, 1993) hence the difficulty in defin- Systems engineering is a wide-range
ing systems engineering. Three sample opi- activity, and it should not be handled
nions are: in the same form for all kinds of sys-
tems (Shenhar and Bonen, 1997).
“Despite the difficulties of finding a
universally accepted definition of sys-
tems engineering, it is fair to say that In addition, the latest systems engineering
Conference on Systems Engineering Research 2007, Paper 057 Page 4
standard ISO 1528 provides a list of the orga- cal breadth and technical depth. Roe adds
nizational processes or activities in which sys- that the difference in application is that the
tems engineers are involved as shown in Fig- system engineer has more technical
ure 2 extracted from the standard (Arnold, breadth, while the project manager has
2002) page 61). Note the use of the word more management expertise.
“management” in eight of the process boxes. (Bottomly, Brook, Morris and Stevens,
1998) studied the roles of the systems en-
gineer and the project manager and identi-
fied 185 activities and their competencies
(experience and knowledge). Their find-
ings included:
o No competency was assessed as
being purely the province of sys-
tems engineering.
o There is no sharp division between
the two disciplines (systems engi-
neer and the project manager) even
at the level of individuals.
Further research into the reason for the
Figure 2 ISO 52888 Systems Engi- overlapping of the disciplines turned up in-
neering Processes formation as to how the overlap originated.
The following statement:
There have also been many discussions in “Driven by cold war pressures to de-
the literature about the overlapping of, and velop new military systems rapidly,
differences in, the roles of systems engineer- operations research, systems engineer-
ing, systems architecting, and project man- ing, and project management resulted
agement, e.g. (Brekka, Picardal and Vlay, from a growing recognition by scien-
1994; Roe, 1995; Sheard, 1996; Kasser, 1996; tists, engineers and managers that
Mooz and Forsberg, 1997; Kasser, 2002; technological systems had grown too
Eisner, 2002; Kasser and Palmer, 2005; Kass- complex for traditional methods of
er, 2005; Faulconbridge and Ryan, 2003; Mai- management and development” (John-
er and Rechtin, 2000) and (Alleman, 2005) son, 1997)
who recasts project management as systems
management using systems engineering. In and the argument in the rest of the paper
addition, there have also been many discus- seem to provide a definitive answer. (Kasser,
sions in the literature about the depth of spe- 2005) showed how the roles evolved into
cialty knowledge required for each of the roles overlapping functions due to the differences in
in the development of systems, typical exam- the activities assigned to the roles in different
ples are (Kasser and Schermerhorn, 1994; organisations. The (A) of systems engineering
Roe, 1995; Bottomly, Brook, Morris and Ste- thus needs to span the activities performed by
vens, 1998; Maier and Rechtin, 2000; Kasser, the roles of the systems engineer, operations
2000; Kasser, 2002). For example: researcher and project manager.
according to (Roe, 1995) the knowledge The framework of ideas (F). (Checkland
and skills of systems engineers are the and Holwell, 1998) pages 23-25) discuss the
same as those of project management in importance of a “declared-in-advance” epis-
the areas of management expertise, techni- temological framework (F) when undertaking
Conference on Systems Engineering Research 2007, Paper 057 Page 5
interpretive research. Thus establishing an (F) and Fabrycky, 1981; Buede, 2000) and
is fundamental to the definition of a research other treatments of the systems engineer-
topic or a discipline. As systems engineering ing process.
focuses on problems (Wymore, 1994), the (F)
for systems engineering can be considered as The Hitchins-Kasser-Massie
being documented in the literature on systems Framework
thinking, problem solving and the activities The vertical and horizontal dimensions of
that take place in the (A). the framework are based on the work of
The methodology (M). Since the activity (Kasser and Massie, 2001) who, in conceptua-
known as systems engineering overlaps other lising a framework for a systems engineering
organisational activities, systems engineering body of knowledge based on the roles of sys-
may be considered as a meta-methodology tems engineers, created the following two-
incorporating the methodologies, tools and dimensional framework.
techniques used in the (A) by both systems
The vertical dimension of the frame-
engineers and practitioners of the other orga- work is based on the work of (Hitchins, 2000)
nisational activities. This puts a considerable who proposed the following five-layer model
number of tools into the toolbox of the sys- for systems engineering:
tems engineer. These tools include:
Layer 5 - Socioeconomic, the stuff of
Total Systems Intervention (Flood and regulation and government control.
Jackson, 1991);
Layer 4 - Industrial Systems Engineering
Soft Systems Methodology (Checkland
or engineering of complete supply
and Holwell, 1998); chains/circles. Many industries make a
the process-oriented, blended, object- socio-economic system. A global wealth
oriented, rapid development, people ori- creation philosophy. Japan seems to oper-
ented, and organisational-oriented meth- ate most effectively at this level.
odologies discussed in (Avison and Fitz- Layer 3 - Business Systems Engineering -
gerald, 2003); many businesses make an industry. At this
a whole suite of problem solving tools for level, systems engineering seeks to opti-
requirements elicitation and elucidation mize performance somewhat independent
discussed in (Hari, Kasser and Weiss, of other businesses
2007); these include interviews (Alexan- Layer 2- Project or System Level. Many
der and Stevens, 2002), Joint Applications projects make a Business. Western engi-
Development (JAD) (Wood and Silver, neer-managers operate at this level, prin-
1995), Analytical Hierarchical Process
cipally making complex artefacts.
(AHP) (Saaty, 1990), Nominal Group
Layer 1- Product Level. Many products
Technique (NGT) (Memory Jogger, 1985)
make a system. The tangible artefact level.
scenario building, user/customer inter-
Many [systems] engineers and their insti-
views, questionnaires, customer visits, ob-
tutions consider this to be the only "real"
servation, customer value analysis, use
systems engineering.
cases, contextual inquiry, focus groups,
viewpoint modelling (Darke and Shanks, Hitchins states that the five layers form a
1997), and Quality Function Deployment "nesting" model, i.e. many products make a
(QFD) (Hauser and Clausing, 1988; Claus- project, many projects make a business, many
ing and Cohen, 1994); businesses make an industry and many indus-
the more commonly used hard systems tries make a socio-economic system. Hitchins
methodologies discussed in (Blanchard also states that these statements are only ap-
Conference on Systems Engineering Research 2007, Paper 057 Page 6
proximate since- working in Area „2F.‟ Note, while the axes of
A socioeconomic system has more in it the framework are shown in a linear manner,
than just industries. this is just for the convenience of drawing.
A business has more in it than just pro- The operations and maintenance phase of the
jects, and so on. system life cycle generally lasts much longer
Actual organizations may divide the work than the initial acquisition phases, hence col-
in different ways resulting in either sub- umn G is drawn wider than the other columns.
layers, or different logical break points.
The horizontal dimension of the frame-
work covers the phases of the systems engi-
neering life cycle. (Kasser and Massie, 2001)
did not define explicit phases. The phases
have been stated in various ways in various
standards, conference papers and books, but
for this framework, they are now defined in
generic terms as:
A. Identifying the need.
B. Requirements analysis.
C. Design of the system.
D. Construction of the system. Figure 3 The HKM Framework for
E. Testing of the system components. Systems Engineering
F. Integration and testing of the system.
G. Operations, maintenance and upgrading Adding the third dimension
the system. (Kasser and Massie, 2001)‟s vertical and
H. Disposal of the system. horizontal dimensions provide a map for the
location of the activities performed by systems
The horizontal dimension is also nested engineers. This paper now goes beyond
but in time. For example, the initial acquisi- (Kasser and Massie, 2001) and discusses the
tion of a system might flow linearly through development of the candidate for the third di-
the system development life cycle from Area mension. The third dimension of the HKM
2B through Areas 2C, 2D, 2E, 2F to delivery Framework is the difficult one since there are
and operations and maintenance in Area 2G. many ways to classify the types of problems
However, the activities that take place during posed in each area of the network. One imme-
the operations and maintenance phase (Area diately obvious approach is by the domain
2G) are the same as those that take place in (aerospace, military, commercial etc.) how-
requirements analysis (of change requests) ever, it was felt that
(2B), design (2C), construction (2D) testing 1. this situation was analogous to the devel-
(2E) and integration (2F) of the configurations opment of theories of motivation in Psy-
of the various system upgrades. chology, and
The vertical and horizontal axes produce a 2. if the analogy holds true then applying les-
two-dimensional map containing 40 areas as sons learned from Psychology to systems
shown in Figure 3. Thus, a systems engineer engineering, should provide a workable
performing requirements analysis for a new framework.
system is working in Area „2B‟. Another sys-
tems engineer performing integration and test- At one point of time in the development of
ing on the same or a different new system is theories of motivation, Henry A. Murray iden-
Conference on Systems Engineering Research 2007, Paper 057 Page 7
tified separate kinds of behaviour and devel- views the coin. For example, a set of require-
oped an exhaustive list of psychogenic or so- ments may be considered as:
cial needs (Murray, 1938). However, the list is a solution – the specification of a system
so long that there is almost a separate need for that will meet a need.
each kind of behaviour that people demon- A problem – a description of something
strate (Hall and Lindzey, 1957). While this list that needs to be designed.
has been very influential in the field of Psy-
chology, it has not been applied directly to the Consequently, the first attempt to formu-
study of motivation in organizations. This is late a framework for systems engineering in
probably because the length of the list makes this research (Kasser, 2006) based the third
it impractical to use. On the other hand, Mas- dimension of the framework on problem solv-
low's hierarchical classification of needs ing (risk mitigation). One context of catego-
(Maslow, 1954; Maslow, 1968; Maslow, ries for risk mitigation was found in the litera-
1970) has been by far the most widely used ture in (Shenhar and Bonen, 1997) who pre-
classification system in the study of motiva- sented a taxonomy in which systems were
tion in organizations. Maslow differs from classified according to three levels of system
Murray in two important ways; his list is scope and four levels of technological uncer-
Arranged in a hierarchy -commonly tainty (risk). Their three levels of system
drawn as a pyramid, and contains a set of scope correspond roughly to the three lower
hypotheses about the satisfaction of these layers of the Hitchins five layer model (Hit-
needs. chins, 2000) and their four levels of technolo-
Short -- Only five categories. gical uncertainty (risk) are:
Type a — Low-Technology Projects
Clayton P. Alderfer subsequently proposed which rely on existing and well-
modifying Maslow's theory by reducing the established technologies to which all in-
number of categories to three (Alderfer, dustry players have equal access. The sys-
1972). Murray's and early theories defined tem requirements of Low-Tech Projects
needs or instincts, Maslow's shows interde- are usually set by the customer prior to
pendencies and relationships between those signing the contract and before the formal
needs and Alderfer proposed further reduc- initiation of the project execution phase.
tions in the number of categories. Applying
Type b — Medium-Technology Projects
this situation to systems engineering, it was
which rest mainly on existing technolo-
felt that using system domains as the third di-
gies; however, such systems incorporate a
mension would be analogous to using Mur-
new technology or a new feature of limited
ray‟s list of needs and a Maslow/Alderfer
scale. Their requirements are mainly set in
more generic-type classification was needed.
advance; however, some changes may be
Consider Maslow as having identified com-
introduced during the product develop-
mon categories and then grouped Murray‟s
ment phase. This process often involves a
needs into those categories as well as adding
joint effort of the contractor and customer.
the interdependencies and relationships be-
It may also require the involvement of po-
tween those needs. In any domain of systems
tential customers in the process.
engineering systems engineers deal with prob-
lems (Wymore, 1994). Type c — High-Technology Projects
Problem stating and problem solving may which are defined as projects in which
be considered as two sides of the same coin most of the technologies employed are
depending on the perspective from which one new, but existent — having been devel-
Conference on Systems Engineering Research 2007, Paper 057 Page 8
oped prior to the project’s initiation. Sys- work. The following are some of the insights
tem requirements are derived interactively already afforded by the framework.
with a strong involvement by customers or 1. Reasons why systems engineers do not
potential users, and many changes are in- agree on the roles of systems engineers
troduced during the development phase. and the different definitions of systems
engineering.
Type d — Super-High-Technology Pro-
2. A roadmap for a more complete set of sys-
jects which are based primarily on new,
tem requirements.
not entirely existent, technologies. Some
3. The place of operations research in the
of these technologies are emerging; others
framework.
are even unknown at the time of the pro-
4. The similarity between new product de-
ject’s initiation. System requirements are
velopment and systems engineering.
hard to determine; they undergo enormous
5. An explanation of the iterative nature of
changes and involve extensive interaction
systems engineering.
with the customer.
Thus, Shenhar and Bonen‟s work forms 1. Reasons why systems engineers do
the basis for the risk dimension of the HKM not agree on the roles of systems engineers
Framework at least in the lower layers of tra- and the different definitions of systems en-
ditional systems engineering. gineering. The HKM Framework illustrates
As the development of a system pro- one reason why systems engineers have not
gresses through the system development life- been able to agree on roles and activities is
cycle the work takes place in different areas of that systems engineers work in different layers
the HKM Framework. The nature of the prob- and in different phases of each layer (Areas of
lems faced by systems engineers in each area the framework). (Cook, 2003) demonstrates
of the framework will be different because the this in the classroom by positioning a number
problems will depend on the level of techno- of areas in which systems engineers work as
logical uncertainty of the specific system summarized below.
(Shenhar and Bonen, 1997). Shenhar and ―Traditional systems engineering cov-
Bonen also support (Martin, 1994)‟s claim ers Layer 2 as shown in Figure 9.
that adopting the wrong system and manage- Contemporary test and evaluation is
ment style may cause major difficulties during shown in Figure 9. The ―V‖ model can
the process of system creation. Namely, what be seen in the figure.
works in Area „2Ba‟ may not work in Area Military platforms lie mostly in Layer
„2Bd‟.Thus, a systems engineer working in 2 with some activities in Layers 1 and
Area „2B‟ should be using methodologies ap- 3 as shown in Figure 9
propriate to Area „2Ba‟ if it is a low technical Information systems overlap several
risk system or Area „2Bd‟ if it is a Super- layers as shown in Figure 9. They
High-Technology Project. comprise traditional systems integrated
out of [commercial] products interact-
Insights from the HKM Frame- ing with the business and supply chain
work layers.
The effort spent to provide the first at- Capability Development lies as shown
tempt at a map of the (A) of the discipline of in Figure 9. This roughly corresponds
systems engineering by applying lessons to the investment management and re-
learned from Psychology to systems engineer- source management processes shown
ing, seems to be providing a useable frame- in Figure 2 (Arnold, 2002). The posi-Conference on Systems Engineering Research 2007, Paper 057 Page 9
Figure 4 Traditional Systems Engi- Figure 5 Contemporary Test and Eval-
neering uation
Figure 6 Military Platforms Figure 7 Information Systems
Figure 8 Capability Development Figure 9 Overlay of areas
tioning of Capability Development in If the positions of activities in the frame-
the figure indicates that this activity is work are overlapped, the result is as shown in
focused in the front of the business- Figure 9. It shows that systems engineers
layer lifecycle. Capability Develop- working in the different parts of the frame-
ment also interacts with the supply work do different tasks. Figure 9 does not
chain level because there is a need to
ensure enduring support to future De- Evaluation Centre, University of South Australia,
fence capabilities. Lastly, it interfaces Adelaide, 2003., such a representation is, of course,
to Layer 2 through the acquisition pro- overly simplistic because aspects of the capability
development processes also occur further down the life-
jects it generates1.‖ cycle, thus a more accurate representation would be an
overlay whose colour saturation represents the degree
1 of effort applied at each point in the two-dimensional
According to Cook, S. C., Principles of Systems
space.
Engineering - Course Notes, Systems Engineering andConference on Systems Engineering Research 2007, Paper 057 Page 10
show, but anecdotal evidence indicates that noted by Roy as “Operations research is more
systems engineers working in the different likely to be concerned with systems in being
areas of the framework use the same words than with operations in prospect” (Roy, 1960)
but with different meanings. For example, the Page 22). Thus, operations research seems to
word “Capability” has different meanings in focus on the areas in column G of the frame-
Areas „3A‟ and „2C‟. Consequently, it is no work.
wonder they cannot agree on what systems 4. The similarity between new product
engineering is and on what systems engineers development and systems engineering.
do. (Priest and Sánchez, 2001) provide a descrip-
2. A roadmap for a more complete set of tion of the product development process as
system requirements. The traditional re- follows:
quirements definition process focuses on the 1. Requirements definition.
functional and performance of the system in 2. Conceptual design.
its operations and maintenance phase. Treat 3. Detailed design.
the HKM framework as a road map, where the 4. Test and evaluation.
road begins in columns A or B, and ends in 5. Manufacturing.
columns G or H. This gives an explicit as- 6. Logistics, supply chain, and environment.
sumption that the system will pass though oth- The description of each step in the product
er areas during its development lifecycle. Dur-
development process maps into the HKM
ing the requirements definition phase (Area
framework Layer 2 systems engineering life
2B) determine if any of these areas lay re- cycle yet the words systems engineering do
quirements on the system (e.g. supply chain
not appear in the book. For example, the U-
requirements such as installation, storage, and
diagram on (Priest and Sánchez, 2001) page
transport), and if so include them in the sys- 64) shown in Figure 10 is equivalent to sys-
tem requirements.
tems engineering’s V-diagram. This is hardly
3. The place of operations research in surprising as the product development process
the framework. Operations research was de- takes place in Layer 1 while traditional sys-
fined as “how to make sure that the whole sys-
tems engineering takes place in Layer 2 of the
tem works with maximum effectiveness and framework as shown in Figure 9.
least cost” (Johnson, 1954) page xix) a goal
that many modern systems engineers would 5. An explanation of the iterative nature
apply to systems engineering. The overlap be- of systems engineering. Students have had
tween operations research and systems engi- trouble grasping the concept that systems en-
neering was noted as early as 1954 when gineering is iterative. The Egg diagram (AN-
Johnson wrote “Operations research is con- SI/EIA-632, 1999) shows iterative activities
cerned with the heart of this control problem – but does not clearly show how the emphasis
how to make sure that the whole systems changes over the life cycle. The FRAT cycle
works with maximum effectiveness and least (Mar, 1994) on the other hand provides a
cost” (Johnson, 1954) page xi). According to clearer perspective in the context of the HKM
(Goode and Machol, 1959) page 130) “the op- Framework. For example, the answer to the
erations analyst is primarily interested in question of “when do we do functional analy-
making procedural changes whilst the systems sis?” is “several times”. We use it in the „F‟
engineer is primarily interested in making step of the FRAT cycle in each Area of the
equipment changes.” A lasting difference was frameworkConference on Systems Engineering Research 2007, Paper 057 Page 11
Figure 10 U-Shape development: flow down of design requirements and flow
up of testing (Priest and Sánchez, 2001)
By virtue of the HKM Framework, sys-
Summary tems engineering can fulfil (Wymore,
This paper takes up the spirit of the chal- 1994)‟s requirement to become a disci-
lenges for the development of a theory of sys- pline since systems engineering now meets
tems engineering (Hill and Warfield, 1972; Kline‟s definition of a discipline, namely it
Friedman, 2006) and describes a candidate has “a specific area of study, a literature,
three-dimensional framework for systems en- and a working community of paid scholars
gineering viewed from problem-solving and and/or paid practitioners” (Kline, 1995)
decision-making perspective that provides page 3).
Kline‟s elements of a discipline namely an
(A), (F), and (M). The paper has shown that References
the framework has already provided insight as Alderfer, C. P., Existence, Relatedness and
to reasons why systems engineers have a plu- Growth: Human Needs in Organiza-
rality of views concerning the scope and na- tional Settings, The Free Press, 1972.
ture of systems engineering. Research into this Alexander, I. F. and Stevens, S., Writing Bet-
framework continues. ter Requirements, Addison-Wesley,
2002.
Conclusions Alleman, G. B., Large Project Management
The conclusions from the research dis- as a Systems Engineering Discipline,
cussed in this paper are: 2005,
While the HKM Framework does not pro- http://www.niwotridge.com/PMasSE/i
vide a theory of systems engineering, it ndex.html, last accessed 20 December
does provide a platform for further re- 2006
search into the nature of systems engineer- Allison, J. S. and Cook, S. C., "The New Era
ing. in Military Systems Thinking and
The HKM Framework embodies the (A), Practice", First Regional Symposium
(F) and (M) of systems engineering and of the Systems Engineering Society of
hence can be considered as a candidate for Australia INCOSE Region 6 (SETE
the first formal representation of the disci- 98), Canberra, Australia, 1998.
pline. ANSI/EIA-632, Processes for Engineering a
System, American National StandardsConference on Systems Engineering Research 2007, Paper 057 Page 12
Institute and Electronics Industries As- Conference, Coventry, England, 1994.
sociation, 1999. Cook, S. C., Principles of Systems Engineer-
Arnold, S. (Editor), ISO 15288 Systems engi- ing - Course Notes, Systems Engineer-
neering — System life cycle processes, ing and Evaluation Centre, University
International Standards Organisation, of South Australia, Adelaide, 2003.
2002. Cook, S. C., Kasser, J. E. and Ferris, T. L. J.,
Avison, D. and Fitzgerald, G., Information "Elements of a Framework for the En-
Systems Development: Methodologies, gineering of Complex Systems", the
Techniques and Tools, McGraw-Hill 9th ANZSYS Conference, Melbourne,
Education (UK), Maidenhead, 2003. 2003.
Badaway, M., "Educating Technologists in Darke, P. and Shanks, G. G., "User Viewpoint
Management of Technology", EMR Modelling: understanding and
Vol (1995), Number Fall. representing user viewpoints during
Blanchard, B. and Fabrycky, W., Systems En- requirements definition", Information
gineering and Analysis, Prentice Hall, Systems Journal Vol 7 (1997), Number
1981. 3, Pp: 213-219.
Bottomly, P. C., Brook, P., Morris, P. W. and Eisner, H., Project and systems engineering
Stevens, R., "A Study of the Relation- management, Wiley, 2002.
ship of Systems Engineering to Project Faulconbridge, R. I. and Ryan, M. J., Manag-
Management", Fourth Annual Sympo- ing Complex Technical Projects: A
sium of the INCOSE-UK, 1998. Systems Engineering Approach, Ar-
Brekka, L. T., Picardal, C. and Vlay, G. J., tech House, Boston, 2003.
"Integrated Application of Risk Man- Flood, R. L. and Jackson, M. C., Creative
agement and Cost of Quality", The 4th Problem Solving, Wiley, 1991.
Annual International Symposium of Friedman, G., "On the Unification of Systems
the NCOSE, 1994. Engineering", INSIGHT Vol 8 (2006),
Buede, D. M., The Engineering Design of Sys- Number 2, Pp: 16-17.
tems, John Wiley & Sons, Inc., 2000. Goode, H. H. and Machol, R. E., Systems En-
Chapanis, A., "Human Engineering," Opera- gineering, McGraw-Hill, 1959.
tions Research and Systems Engineer- Hall, A. D., A Methodology for Systems Engi-
ing, C. D. Flagle, W. H. Huggins and neering, D. Van Nostrand Company
R. H. Roy (Editors), Johns Hopkins Inc., Princeton, NJ, 1962.
Press, Baltimore, 1960. Hall, C. S. and Lindzey, G., Theories of Per-
Checkland, P. and Holwell, S., Information, sonality, John Wiley & Sons, 1957.
Systems and Information Systems: Hari, A., Kasser, J. E. and Weiss, M. P., "How
making sense of the field, vol. Chiche- lessons learnt from creating require-
ster, John Wiley & Sons, 1998. ments for complex systems using QFD
Checkland, P. and Scholes, J., Soft Sytems Me- led to the evolution of a process for
thodology in Action, John Wiley & creating quality requirements for com-
Sons, 1990. plex systems", Systems Engineering:
Churchman, C. W., The Systems Approach The Journal of the International Coun-
and its Enemies, Basic Books, Inc., cil on Systems Engineering Vol 10
New York, 1979. (2007), Number 1, Pp: 45-63.
Clausing, D. and Cohen, L., "Recent Devel- Hauser, J. R. and Clausing, D., "The House of
opments in QFD in the United States", Quality", Harvard Business Review
Institution of Mechanical Engineering Vol May-June (1988), Number, Pp:Conference on Systems Engineering Research 2007, Paper 057 Page 13
63-65. Rochester, New York, 2005.
Hill, J. D. and Warfield, J. N., "Unified Pro- Kasser, J. E., "Reducing the cost of doing
gram Planning", IEEE Transactions on work by an order of magnitude (by ap-
Systems, Man, and Cybernetics Vol plying systems thinking to systems en-
SMC-2 (1972), Number 5, Pp: 610- gineering)", 21st Centre of Excellence
621. Workshop: Challenges for life-based
Hitchins, D. K., World Class Systems Engi- systems development, Tokyo, Japan,
neering - the five layer Model, 2000, 2006.
http://www.hitchins.net/5layer.html, Kasser, J. E. and Massie, A., "A Framework
last accessed 3 November 2006 for a Systems Engineering Body of
Jackson, M. C. and Keys, P., "Towards a Sys- Knowledge", 11th International Sym-
tem of Systems Methodologies", Jour- posium of the INCOSE, INCOSE,
nal of the Operations Research Society Melbourne, Australia, 2001.
Vol 35 (1984), Number 6, Pp: 473- Kasser, J. E. and Palmer, K., "Reducing and
486. Managing Complexity by Changing
Johnson, E. A., "The Executive, the Organisa- the Boundaries of the System", the
tion and Operations Research," Opera- Conference on Systems Engineering
tions Research for Management, Vo- Research, Hoboken NJ, 2005.
lume 1., J. F. McCloskey and F. N. Kasser, J. E. and Schermerhorn, R., "Gaining
Trefethen (Editors), The Johns the Competitive Edge through Effec-
Hopkins Press, Baltimore, 1954. tive Systems Engineering", The 4th
Johnson, S. B., "Three Approaches to Big Annual International Symposium of
Technology: Operations Research, the NCOSE, San Jose, CA, 1994.
Systems Engineering, and Project Kline, S. J., Conceptual Foundations for Mul-
Management", Technology and Cul- tidisciplinary Thinking, Stanford Uni-
ture Vol (1997), Number, Pp: 891-919. versity Press, Stanford, 1995.
Kasser, J. E., Applying Total Quality Man- Maier, M. K. and Rechtin, E., The Art of Sys-
agement to Systems Engineering, Ar- tems Architecting, CRC Press, 2000.
tech House, Boston, 1995. Mar, B. W., "Systems Engineering Basics",
Kasser, J. E., "Systems Engineering: Myth or Systems Engineering: The Journal of
Reality", The 6th International Sympo- INCOSE Vol 1 (1994), Number 1, Pp:
sium of the INCOSE, Boston, MA., 7-15.
1996. Martin, J. N., "The PMTE Paradigm: Explor-
Kasser, J. E., "The Certified Systems Engineer ing the Relationship Between Systems
- It's About Time!" The Systems Engi- Engineering Processes and Tools", 4th
neering, Test and Evaluation (SETE) Annual International Symposium of
Conference, Brisbane, Australia, 2000. the National Council on Systems En-
Kasser, J. E., "Systems Engineering: An Alter- gineering, INCOSE, San Jose, CA,
native Management Paradigm." The 1994.
Systems Engineering and Evaluation Maslow, A. H., A Theory of Human Motiva-
Conference (SETE 2002), Sydney tion, Harper & Row, 1954.
Australia, 2002. Maslow, A. H., Toward a Psychology of Be-
Kasser, J. E., "Introducing the Role of Process ing, Van Nostrand, 1968.
Architecting", The 15th International Maslow, A. H., Motivation and Personality,
Symposium of the International Coun- Harper & Row, 1970.
cil on Systems Engineering (INCOSE), Memory Jogger, "Memory Jogger,"Conference on Systems Engineering Research 2007, Paper 057 Page 14
GOAL/QPC, Mathuen, MA, 1985. Biography
Mooz, H. and Forsberg, K., "Visualizing Sys-
tems Engineering and Project Man- Dr. Joseph Kasser has been a practising sys-
agement as an Integrated Success", tems engineer for more than 35 years. He is an
The 7th Annual International Sympo- INCOSE Fellow and the author of "Applying
sium of the INCOSE, 1997. Total Quality Management to Systems Engi-
Murray, H. A., Explorations in Personality, neering" and many INCOSE symposia papers.
Oxford University Press,, 1938. He holds a Doctor of Science in Engineering
Priest, J. W. and Sánchez, J. M., Product De- Management from The George Washington
velopment and Design for Manufactur- University, and is a Certified Manager. He is
ing, Marcel Dekker, 2001. Deputy Director and an Associate Research
Roe, C. L., "The Role of the Project Manager Professor at the Systems Engineering and
in Systems Engineering", The 5th An- Evaluation Centre at the University of South
nual International Symposium of the Australia. He teaches online and in the class-
NCOSE, 1995. room as well as performing research into the
Roy, R. H., "The Development and Future of nature of systems engineering and the proper-
Operations Research and Systems En- ties of object-oriented requirements. He is a
gineering," Operations Research and recipient of NASA‟s Manned Space Flight
Systems Engineering, C. D. Flagle, W. Awareness Award (Silver Snoopy) for quality
H. Huggins and R. H. Roy (Editors), and technical excellence for performing and
Johns Hopkins Press, Baltimore, 1960. directing systems engineering and many other
Saaty, T., Decision Making for Leaders, RWS awards and commendations.
Publications, Pittsburgh, PA, 1990.
Sage, A., Systems Management for Informa-
tion Technology and Software Engi-
neering, Wiley, 1995.
Sheard, S. A., "Twelve Systems Engineering
Roles", The 6th Annual International
Symposium of the NCOSE, 1996.
Shenhar, A. J. and Bonen, Z., "The New Tax-
onomy of Systems: Toward an Adap-
tive Systems Engineering Framework",
IEEE Transactions on Systems, Man,
and Cybernetics - Part A: Systems and
Humans Vol 27 (1997), Number 2, Pp:
137 - 145.
Wood, J. and Silver, D., Joint Application De-
velopment, John Wiley and Sons Inc.,
1995.
Wymore, A. W., Model-Based Systems Engi-
neering, CRC Press, Boca Raton,
1993.
Wymore, A. W., "Model-Based Systems Engi-
neering", Systems Engineering: The
Journal of INCOSE Vol 1 (1994),
Number 1, Pp: 83-92.You can also read
