PHD Research Proposal

PhD Research Proposal

Methodology Selection for the Engineering of Complex
Defence Systems
Mr. Les Vencel
Supervisors
Prof. Stephen Coo
Prof. Lahmi !ain
School of Physics & Electrical Engineering
Systems Engineering & Evaluation Centre
Mawson Lakes Campus
University of South Australia
Mawson Lakes, SA !"#!
$%
th
March %""!
Les &encel $ $%'Mar'%""!
(a)le of Contents
$* +,(-./UC(+.,*************************************************************************************************************' 0 '
%* .verview of /efence Systems Engineering**********************************************************************' 1 '
%*$* 2hat is Systems Engineering3**********************************************************************************' ! '
%*%* A (ypology for Systems Engineering************************************************************************' 4 '
%*0* Characteristics of Comple5ity in /efence Systems*************************************************' $" '
%*1* E5isting /efence Systems Engineering Mo6els******************************************************' $$ '
%*!* Multi'Metho6ological Approaches in Management Science***********************************' $0 '
%*7* Pro)lems in Mo6ern /efence Systems Engineering***********************************************' $1 '
0* -esearch Pro)lem************************************************************************************************************' $7 '
0*$* +S. $!%44 Life Cycle processes*****************************************************************************' $4 '
0*%* A (ypology of Pro)lems*****************************************************************************************' $# '
0*0* A (ypology of Systems*******************************************************************************************' %" '
0*1* Attri)utes for selection of systems 8engineering9 processes an6 practices**************' %" '
0*!* E5pecte6 Contri)ution********************************************************************************************' %" '
1* -esearch Metho6ology****************************************************************************************************' %% '
1*$* Literature -eview***************************************************************************************************' %% '
1*%* Metho6ology***********************************************************************************************************' %% '
1*0* Case Stu6ies************************************************************************************************************' %0 '
1*1* Pu)lications*************************************************************************************************************' %0 '
!* 2ork Plan************************************************************************************************************************ ' %1 '
7* -eferences*********************************************************************************************************************** ' %! '
Les &encel % $%'Mar'%""!
1 INTRODUCTION
The nature of problems encountered in the system engineering domain for large and
novel Defence systems has over the past thirty years grown in complexity. The
integration of technology with human activity systems to produce complex capabilities
has required a continual change in our definition and application of systems engineering.
The acquisition of defence capability has transitioned from a mindset in the late 1960s of
equipment procurement to one associated with capability development. This change in
mindset has been driven partly by the growth of information technology and its impact on
technology based systems. Defence equipment has moved from being predominantly
hardware based to being multi-function, multi-role systems where the flexibility and
adaptability of the system is primarily derived from its software functionality.
Similarly, the global environment within which nations need to develop and project a
defence capability has also changed. Decades ago, nations would examine their short and
long term threat environments and based on such assessments, plan the defence force
structure most suited to meet such adversities. For Australia, the Defence White Paper
would set the direction of Australias defence force structure. It has been one of
protecting national interests, involvement in the local region and establishment and
maintenance of international alliances.
However, the threats facing defence forces are now quite different. Global terrorism,
support to Coalition forces and UN Peace keeping missions have dramatically changed
the demands placed on a defence capability to support these new missions and roles.
Today, defence forces may be called upon to be deployed in any part of the world with
little warning, undertaking missions that were not envisioned a few years ago and
consequently using defence capability that was not designed for such purposes.
Modern Defence systems need to be able to be integrated [in a plug and play
manner] into hybrid system of systems to address short term national and international
demands and on completion of such missions be disassembled to return to their prior
roles. These hybrid system of systems integrate human activity systems with advanced
technology [sociotechnical systems] to produce complex defence capabilities. More
recently, the move by Western countries towards embracing net centric warfare concepts
such as distributed functionality and composeability imply that system components that
may have been designed to be platform centric now need to operate in a network centric
manner hence the metaphor of plug and play. This has introduced further complexity
in the development of defence systems.
This research aims to examine how does one design such complex systems to meet
demands that are not envisioned at the time of development and be able to integrate with
other capabilities not contemplated during development. Such is the challenge to modern
Les &encel 0 $%'Mar'%""!
defence system engineering.
In this research proposal, we begin with an introduction to put in context the changing
demands on system engineering over the past few decades, a short description of the
status quo of systems engineering followed by a discussion of the research problem. Then
we discuss the approach used to undertake the research, followed by a work plan and
schedule.
2 Overview of Defence Systems Engineering
Systems engineering gained recognition as a discipline following the Second World
War. The increasing cost and technical complexity of development and acquisition
programs in the 1950s and 1960s stimulated the need for a methodology to handle the
technical and managerial complexity of large projects. Some of this recognition was no
doubt due to large program failures that could have been avoided, or at least mitigated
through the use of systems engineering (MPherson, 1980; DSMC, 1983).
The development of defence programs such as the Polaris submarine and the Apollo
Space program in the 1960s saw the need to establish processes and procedures to assist
in the development of such programs. Standards began to be developed. Whilst the
problems encountered were amenable to such approaches, system engineering gained
acceptance as a valuable component in the success of large projects.
The 70s saw the introduction of software as a major component of large defence
systems. Whilst software development in itself was to become a major challenge,
software changed the nature of equipment development. Prior to the introduction of
software based systems, equipment was designed for a set purpose and the hardware
manufactured to such an end goal. With the advent of software based systems, defence
systems could now exhibit multiple functions and roles all reconfigurable through the
system software. System complexity grew. Software based defence systems encountered
significant difficulties in estimation and development control. Systems engineerings
functionalist approach began to falter as developers struggled to grasp with problems that
were unprecedented and with ill-defined operational concepts leading to scope and cost
overruns and dissatisfied end users.
More recently, Defence has had to grapple with the need to response quickly to
situations on a global perspective with equipment not designed to meet such occurrences.
Modern day defence systems need to be able to be integrated into mission specific system
of systems, have network centric and not platform centric characteristics and display
robustness and agility within such an environment. Furthermore, these systems now
comprise advanced technology that is integrated with human activity systems
[organisations] to achieve complex capabilities as may be seen in modern C4ISR
systems.
Contemporary systems engineering, while cognisant of these issues, is still practiced
largely as a process-based, equipment-centric discipline based on traditional or classical
systems engineering process models. This traditional systems engineering approach
tends to be goal oriented and based on a belief system that the application of natural
scientific principles to the problem at hand will provide a solution. In line with this
concept, the problem solving method tends to be reductionist in that the belief is that the
problem can be decomposed to smaller components until each component is amenable to
scientific analysis and solution. Then the components are re-assembled to represent the
whole
However, todays complex System of Systems (SOS) requires a multi-disciplinary
approach applied across their life cycle development and management. This implies that
a pluralist approach using multiple system methodologies, based on different social
models, is required to adequately address the scope of the problem. Mingers & Gill
(1997, p8-9) argue that real world problem situations are inevitably highly complex and
multidimensional. Different paradigms (or social models) each focus attention on
different aspects of the situation and so multimethodology is necessary to deal effectively
with the full richness of the real world.
What is needed is to apply systems engineering to the range of problems identified by
Cook (2004), in a framework that engages the many disciplines involved during the
different lifecycle phases of system of interest albeit simple equipment or the defence
force as a whole.
3 What is Systems Engineering?
It is worthwhile to examine some definitions of Systems Engineering to observe the
changing emphasis in the definitions over time to address the need to recognise multi-
disciplinary skills and that complex systems comprise more than just equipment. It is also
noteworthy that many definitions of systems engineering describe what it does and not
what it is. This is particularly prevalent in the earlier standards.
The definitions follow in chronological order:
A logical sequence of activities and decisions that transforms an operational
need into a description of system performance parameters and a preferred
system configuration. (MIL-STD-499A, Engineering Management, 1 May
1974. Now cancelled.)
An interdisciplinary, collaborative approach that derives, evolves, and verifies
a life-cycle balanced system solution which satisfies customer expectations
and meets public acceptability. (IEEE P1220, Standard for Application and
Management of the Systems Engineering Process, [Final Draft], 26 September
Les &encel ! $%'Mar'%""!
1994.)
An interdisciplinary approach encompassing the entire technical effort to
evolve and verify an integrated and life-cycle balanced set of system people,
product and process solutions that satisfy customer needs, (Shishko, R, 1995,
(NASA Systems Engineering Handbook)).
The INCOSE SE Handbook (1998) defines system engineering as follows -
An interdisciplinary approach and means to enable the realisation of
successful systems.
The EIA 632 standard describes the processes for engineering a system.
EIA 632 provides a description of the typical system engineering processes
associated with the life cycle of a system. The processes for engineering a
system are grouped into the five categories as shown below in figures 1 and 2.
It does not provide a definition of systems engineering.
The more recently released ISO/IEC 15288, Systems Engineering System Life
cycle processes, also does not provide a definition of systems engineering but rather
provides a common process framework to improve communication and co-operation
among the parties that create, utilise and manage modern systems in order that they can
Figure 1. The five main groups of processes
associated with the EIA 632 System Engineering
model.
Figure 2. The EIA 632 System
Engineering Process model Egg diagram.
work in an integrated, coherent fashion. These processes extend beyond those previous
addressed in EIA 632 and address agreement, enterprise, project and technical processes
in co-operating organisations.
Table 1 depicts the typical lifecycle stages whilst figure 3 shows the 15288 system
life cycle processes note the inclusion of enterprise processes.
Over the span of a thirty year period, the definition of systems engineering has
gradually developed to encompass the more complex systems needed to be engineered.
More recently, standards have become less prescriptive in terms of defining a systems
engineering process, but rather concentrate more on the establishment of a framework of
life cycle processes that can be integrated to support the development of a complex
system.
Les &encel : $%'Mar'%""!
Table 1. The 15288 example of typical life cycle
stages, their purpose and major decision gates.
Figure 3. The 15288 System Life Cycle Model
Processes.

Figure 4: Heritage of Systems Engineering Standards
Figure 4 depicts the so-call quagmire map of the development of various system
and software standards to attempt to grapple with the increasing complexity of systems.
The latest standard IEC/ISO 15288 [5] lists 23 processes that cover the breadth of SE
and places them into four categories as depicted in figure 3. These indicate that SE has
expanded its breadth beyond that of a predominantly technical discipline. Indeed, SE can
be considered a meta-discipline that coordinates and interacts with other related
disciplines such as project management, development engineering, integrated logistic
support, test and evaluation, configuration management and software engineering. One
of the improvements that can be seen in IEC/ISO 15288 is that SE has become inherently
interwoven with the enterprise environment of the host organization
4 A Typology for Systems Engineering
Hitchins [6] proposes a five-layer model for systems engineering to try and
encompass the scope and diversity of activities that systems engineering embraces.
Level Hitchins Five Layer Model
Level 1 Product or The outcome of SE at this level is tangible products.
Subsystems engineering.
Level 2 - Project SE. This is classic or traditional SE that leads to the creation of
complex artifacts such as aircraft, ships, and computer
networks.
Level 3 - Business SE. At this level many projects combine to form a business or
enterprise. At this level additional functions appear such as
marketing, strategic management, human resource
management, etc. There is also the concept of ongoing
activity beyond the life of a single project. Continuous
process businesses such as chemicals, pharmaceuticals, and
smelting operate at this level. A military Service can be
thought to operate at this level.
Level 4 - Industrial SE. This level is characterized by many businesses working
together to achieve large-scale outcomes such as vehicle
manufacture, telephone networks, national transport
systems, national health systems, and the defence force.
Level 5 - Socioeconomic
SE.
This is the highest level and activities are normally
sociotechnical in nature and of national or global scale.
National security, of which defence is a component, operates
at this level.
Table 2: Hitchins Five Layer Systems Model
Hitchins states that the layers form a nesting model, in that many products make a
project, many projects make a business, many businesses make an industry and many
industries make a socio-economic system. He goes on to say that these statements are
only approximate since a socioeconomic system has more in it than just industries and a
business comprises more than just projects, and so on. Nonetheless, Hitchins model is
useful because it:
Gives an appreciation of the scope of activities that fall within the term
systems engineering.
Illustrates how each activity fits within the layer above and as such
emphasizes both the open system view of the engineering of complex systems,
and the hierarchy of SE activities.
Indicates that the ISO/IEC 15288 processes can be applied to various levels of
complexity not just engineering projects at Level 2.
For the purposes of illustrating where certain activities fit within the scope of both
systems engineering and the system life cycle, we can map Hitchins model onto a two-
dimensional space defined by system level on the vertical axis, and life-cycle time on the
horizontal axis (Cook et al, 2003).
Les &encel # $%'Mar'%""!
Life'cycle temporal focus
S
y
s
t
e
m

S
c
a
l
e
Layer % System Level
Layer $ Pro6uct Level
Layer 0 ;usiness Level
Layer 1 Supply Chain Level
Layer ! Socio'Economic Level
Strategic
Planning
Capaility
Development
Capaility !c"#isition
an$ T%ro#g%&'ife S#pport
25 yrs
Into the future
10 yrs
Before EIS
Disposal Support Entry
into Service
Figure 5: A graphical depiction of Hitchins extended five-layer model showing the positioning of the
systems activities of interest.
The types of systems addressed during the 1950s tended to be level 2 Project SE for
which Hitchins states that the traditional systems engineering is adequate. However as the
complexity of the systems increased, i.e. defence systems became level 3 and level 4, it
becomes clearer as to why the more traditional process oriented approaches fail to work.
Systems activities can now be mapped onto this space to indicate where they fit with
respect to these two dimensions as shown in figure 5. For example, strategic planning
primarily concerns issues that are 10-25 years in the future and operates at the socio-
economic and supply-chain (whole-of-defence) levels. The positioning of capability
development in the figure illustrates that this activity is centered at the front of the
business-layer lifecycle and remains involved until projects enter service. Capability
acquisition starts once capability development processes have identified a capability gap
to be filled. In Australia, acquisition and logistic functions have been combined within
the Defence Material Organization and thus project office functions continue through
until equipment disposal which may occur decades after introduction of a capability into
service. The containment of the acquisition and support functions into Level 2 indicates
that project offices tend to be rather insular in their concerns.
5 Characteristics of Complexity in Defence Systems
At this point it is worthwhile to state what the characteristics of complexity found in
modern systems [and in particular, defence systems]. The following are representative of
characteristics that lead to complex problems in modern day systems.
Les &encel $" $%'Mar'%""!
1. Poorly defined system boundaries
2. Size i.e. the number of system components and their interactions that needs
to be addressed at anyone level
3. Multi-disciplinary nature i.e. the system has many technologies involved
and interacting
4. System topology the number and nature of the inter-relationships between
the system components
5. Ill-defined operational goals for the system i.e. the end user has not been
able to clearly articulate how the system is to be utilised, but may have been
able to express the need for such a capability
6. Unprecedented nature i.e. such a system has not been developed before,
hence little experiential base to draw upon to assist in the development of the
system
7. Nature of the system problem is changing i.e. the problem under
consideration is continually changing and is dynamic [referred to as a wicked
problem by Rittel]
8. Human Activity Systems systems where humans not only use the system
but represent functional components of the capability, hence the need to
define the interfaces between technology and organisational information
exchanges
9. Political differences between different organisational components of the
system
10. Conflicting operational and sociological views within the system
The causes of these characteristics may be due to incomplete information, the nature of
the problem [Rittels wicked problem scenario] or the nature of the environment within
which the system needs to operate. For Defence, it is the environment within which
defence systems need to operate that is a major influence on the complexity of the
problems that need to be managed if not solved.
6 Existing Defence Systems Engineering Moels
The existing systems engineering models within Defence have tended to be based on
the traditional or classic systems engineering approach. This approach is goal oriented
and is based on a belief system that the application of natural scientific principles to the
problem at hand will provide a solution. In line with this concept, the problem solving
method tends to be reductionist in that the belief is that the problem can be decomposed
to smaller components until each component is amenable to scientific analysis and
solution. Then the components are re-assembled to represent the whole.
Such a process-oriented methodology is well suited to problems that are well defined
and are inherently technical by nature. Consequently, this approach to systems
engineering fitted reasonably well the type of systems being developed after the Second
Les &encel $$ $%'Mar'%""!
World War.
As the system complexity grew from the 1950s to modern day, various process
models were proposed to cater for the difficulties found in handing some of the
characteristics of increasing complexity as stated above. Some of these process models
are briefly described below.
1. Classic Waterfall Model a sequential process model beginning with a
requirements analysis phase and concluding with system Acceptance testing.
Figure 6 depicts such a process methodology. A key point in this process is
that to begin the process [namely the requirements analysis phase], a well
defined set of operational specifications or Concept of Operations [CONOPS]
is required. The process is goal oriented and hence requires well defined
inputs to process.
Secondly, a large percentage of the process lifecycle ie approximately half is
associated with paper products hence the process is documentation centric
and is so linked into its review cycle.
Les &encel $% $%'Mar'%""!
Figure 6: Classic Waterfall Model for Systems Engineering
2. The V Model still represents a similar process model to the waterfall method
but provides cross links between the requirements and design phase to the
production and test phases. Three critical elements that the V diagram
promotes well.
a. Definition: Represented in terms of a Specification Hierarchy that
reflects decomposition.
b. Build: Life-cycles for component implementation and
manufacturing.
c. Verification: Represented in terms of a Test Hierarchy that
reflects integration
3. Spiral or Helical Model again a similar process model but is usually used
when the best solution to the problem is unclear at the outset. The idea is to
create a prototype of the solution, test it in an operational environment and
then by observing deficiencies in its performance, devise improvements to the
system. Each revolution of the spiral invokes the classic waterfall process
model. The cycle is repeated until an acceptable solution is reached. Figure 7
below depicts such a process model.
Les &encel $0 $%'Mar'%""!
MODEL
PROBLEM
REAPPRAISE
NEED &
RISK
REFINE
REQUIREMENT
APPROACHES &
ANALYSE
CONSTRAINTS
DESIGN
ARCHITECTURE
DESIGN
COMPONENTS
IMPLEMENT
COMPONENTS
VALIDATE
SYSTEM
PERFORMANCE
VERIFY &
INTEGRATE
COMPONENTS
USER
REQUIREMENTS
DELIVERED
PRODUCT
DESIGNED
SYSTEM
SYSTEM
REQUIREMENTS
Figure 7: Spiral model for Systems Engineering
4. Incremental Development Model within this process model, the system level
requirements and architecture are developed and then the various system
components are developed and commissioned in a staggered and incremental
manner. The key point here is that the top level system structure is developed.
Each increment still uses the waterfall model
5. Evolutionary Development This model attempts to manage the development
of large complex systems by initially developing a basic capability and then
through operational use as an understanding of the utility of the system grows,
further enhancements are developed. Again a similar process model to the
waterfall model is used for each development. A limitation is that the initial
baseline development needs to capture the system concept to allow further
enhancements to be integrable into the design. There is little value in the
approach if each enhancement requires large amounts of re-engineering of the
previous development.
All of these system engineering process oriented models have met with limited
success. Where the system type tends to fit into Hitchins Level 2 Project SE layer, the
traditional systems engineering methods and process models meet with reasonable
success. However, as the nature of the systems become more complex; i.e. moved up
Hitchins layer model, the inherent reductionist basis of the process models did not
adequately cater for the real world situation, consequently resulting in poor compliance to
end user needs and ineffective systems design.
! M"lti#Methoological Approaches in Management Science
Multi-methodological approaches are becoming commonplace in systems
intervention practice that management consultants conduct to ameliorate problems in
organisations. The theory is that management issues are too complex to understand
adequately with one model, one set of theories, and one world view. Jackson and Keys
(1984) proposed a system of systems methodology (SOSM) that presented different
methodologies as being appropriate for different types of problem contexts. Jackson
(1987) codified this approach by assigning systems approaches to management into
categories characterized by social theory and problem complexity. From this, Flood and
Jackson (1991) formulated a systemic meta-methodology entitled Total Systems
Intervention that guides practitioners through methodology choice in a systemic way
based on metaphors of the problem situation. This has been elaborated in subsequent
works (Jackson, 2000; Mingers 1999). The fundamental ideas that have emerged
concerning the need for pluralism in problem solving remain sound.
Flood and Jackson assigned systems engineering as a methodology to the simple,
unitary problem context. This implies that it is a useful methodology for problems where
the actors share an agreed set of objectives, the problem is clearly structured, and the
complexity level is low. Most systems engineers would take exception to this
categorisation because they would consider that acquirers and suppliers would have quite
different objectives (world views) and they would consider that the creation of, say, a
new aircraft carrier was reasonably complex!
In defence of the management science community, one could argue that building a
large system of this type is, in fact, a simpler and more unitary proposition than, say,
solving the problem of homeless youth or public health care. If one appreciates that TSI
is focused on social and organisational issues, then the stance of the leading authors is
reasonable. One also needs to appreciate that TSI and other management science
techniques are aimed principally at improving existing complex organisational situations
and not at creating unprecedented systems.
$ %ro&lems in Moern Defence Systems Engineering
Whilst contemporary defence systems engineering may recognise the complexity of
the problems associated with complex defence systems, there does not exist any
methodology or meta-methodology akin to Flood and Jacksons Total Systems
Intervention concept for the management sciences that assists a practitioner to investigate
the nature of the problem space and thereby develop a suitably rich picture from which an
appropriate set of methodologies based on different social belief systems may be selected
to tackle the development of the system under consideration.
Incorrect methodology selection does not imply that the system will not be developed
and commissioned; what it does imply is that the system built may not meet all the
requirements of the end user. Incorrect methodology selection simply implies that an
insufficient problem definition has occurred and consequently, an incorrect or inferior
model representation of the complex system has occurred.
This tends to be the case when methodologies appropriate for a level 2 type system
are used to develop type 4 or 5 level systems i.e. systems that are sociological or
sociotechnical and consequently exhibit complex behaviour not strictly amenable to
scientific enquiry. Consequently, the inappropriate methodology solves the representation
of the complex system that is structured and well represented ie it solves a simpler less
complex problem than that required to be addressed.
Les &encel $! $%'Mar'%""!
Symptoms of such occurrences may be observed when end users complain that the
system poorly meets their needs usually a symptom of poor systems engineering
encountered in the problem definition or structuring phase.
( Researc% Prolem
The final section in chapter 2 of this research proposal discussed the nature of
problems found in modern defence systems engineering. In particular, the problem to be
investigated is:
How does one select an appropriate set of methodologies to undertake
the systems engineering across the life cycle development of modern
defence systems?
In the previous section, we discussed the development of defence systems
engineering and the gradual change in the nature or type of system towards increased
complexity that Defence required to be engineered. This need to engineer systems with
increased complexity is driven by a number of factors, such as:
a. Changes in the environment that Defence forces need to work in.
b. Changes in the Missions that Defence may undertake
c. Changes in the response times.
For Australia, this means the following:
a. Australian forces may now be deployed anywhere in the world as part of a
Coalition force. Consequently, defence equipment needs to be
interoperable with that of a coalition force, and more so, Australian
equipment needs to be net centric, not platform centric so that force
attributes such as shared awareness, synchronization and agility may be
utilised across an instantiated coalition force. These are strong design
drivers for Defence systems when one considers that most systems will
not have been designed with this in mind or cognisant of the need to Plug
& Play in instantiated System of systems.
b. The Australian Defence forces only a short period ago, before September
11, would predominantly focus on Defending Australia, Protecting
regional interests and establishing and maintaining international alliances.
Today, with the advent of Global Terrorism, Australian forces may
undertake missions in any part of the Globe with roles such as Support to
Coalition led Forces in Defence or Offensive positions in areas of the
Globe that Australia would normally not have been involved; e.g.
Afghanistan, Iraq, etc. Support to or Lead Coalition forces within the
Pacific Rim and Support to UN Peacekeeping forces. These new roles
require Australian Defence equipments to be interoperable, net centric and
plug and play in the formation of mission specific System of systems.
c. The responses times that Australian forces may have to meet may be very
short days to weeks for some deployments. This is clearly not sufficient
Les &encel $: $%'Mar'%""!
time to design new specific defence systems to meet new and unexpected
roles and missions. Again, modern defence systems need to be adaptable,
agile; net centric and re-configurable [ie plug and play in system of
systems.].
If we analyse these new demands on Australian Defence systems, we find that these
modern defence systems have the following attributes:
1. Systems need to be interoperable with other systems that may not be defined
at the time of design
2. Need to undertake roles not envisaged at the time of design
3. Need to be net centric not platform centric
a. Need to be agile; i.e., system functions not tightly coupled together but
able to be connected to other functions from other systems
b. Need to be re-configurable i.e. system can be re-configurable to
perform other functions than that designed for.
4. System needs to be able to be integrated into a larger system of systems
We can see the following:
1. The design of defence systems to meet such future possible roles means that
there is usually an ill defined set of requirements as to what operational
conditions the system will work within
2. The problem is ill structured as not all requirements can be forecast or are
known at the time of development and this needs to be catered for.
3. The ability to integrate into any systems of systems is not just at the technical
level but also at the systems, operational and organisational level. Hence, such
developments are inherently complex as these interfaces are not known at the
time of the system development but the systems needs to be flexible enough to
undertake such activity.
4. Net centric concepts such as shared awareness, synchronization and agility
also place demands on system design that can not be clearly predicted at
design time.
Defence communities in the United States, Europe and Australia are investigating a
number of approaches to the development of defence systems with such complex
capabilities. Approaches such as:
1. Threat based response options
2. Military Capability Packages
3. Capability Based planning.
The third option is currently being viewed as a viable means for the development of
such defence capability. Typical examples of such capability as rapid instantiated C4ISR
systems to meet either Joint [Australian] or Coalition deployed forces needs and the
development of a mobile and agile defence force capability.
These systems are clearly not at Hitchins level 2 Project Engineering layer but more
at level 3 and level 4. Hence it is not surprising to find that traditional systems
engineering struggles with these types of system development.
Whilst approaches such as Capability Based Planning gain flavour in the international
community for the planning of such complex defence systems, there is still little to no
guidance available as to how to engineer such systems. There is little to no system of
methods or Meta-methodology to assist the systems engineering practitioner in the
selection of an appropriate set of methodologies the engineer such complex defence
systems.
It is the development of such guidance to be able to select an appropriate mix of
methodologies that this research will focus on. The research will examine the following
areas.
1. Systems engineering and life cycle models and processes in particular the
new standard ISO 15288 with a view to establishing a set of activities and
processes aligned with different life cycle phases of a system
2. Development of a Problem typology; primarily aimed at understanding the
attributes of problems, in particular those associated with complexity.
3. Development of a Systems typology developing a military typology of
systems based initially on Hitchins 5 layer model.
4. Development of a set of attributes within an ISO 15288 framework that will
provide the necessary guidance towards the selection of problem solving
methodologies relevant to the activities associated with a particular life cycle
phase
5. Theoretical insight into the nature of the selection process and its utility to
modern defence systems
'( )S* '5+$$ ,ife Cycle processes
If we think of ISO 15288 as providing a framework for the development of modern
complex systems, i.e. the life cycle processes involved in the development of complex
systems; then the set of processes defined within 15288 can be related to the activities
that need to be undertaken throughout the lifecycle of the system.
It is useful to state that the systems lifecycle spans from conception to disposal and is
usually drawn as five or six phases and is designed to suit the problem domain, the level
of complexity, and nature of the system of interest. The phase to be tackled of the system
life cycle will determine the skill sets to be invoked and the detail of the methods to be
employed. For example, the operations phase requires quite different people, processes
and skills from conceptual design.
Therefore, if we think of these activities as the problems we need to solve to develop
the complex system, we can begin to link ISO 15288 to a set of problem solving
Les &encel $# $%'Mar'%""!
methodologies. Our thinking can be depicted as follows:
ISO15288 Lifecycle phase Processes Activities Problems to solve Problem Solving
Methodologies
'' A Typology of %ro&lems
The systems engineering process is described in MIL-STD-499B as a comprehensive,
iterative problem solving process. In order to understand how best to select
methodologies to tackle systems engineering problems, it is helpful to understand what
constitutes a problem.
Jonassen (2003) explains that problems vary in at least four dimensions, namely
structuredness, complexity, dynamicity and domain specificity (or abstractness). The
definitions of these problem attributes have been taken from Jonassen (2003) with the
addition of the additional category, namely wicked, to structuredness.
1. Structuredness usually has two broad classifications, namely well-structured and ill-
structured. More recently, the term wicked has also been introduced in the literature
to define a special class of particularly difficult problems to solve. Some definitions
of these are:
Well Structured require the application of a limited and known concepts,
rules and principles within a restricted domain (or discipline), have a well
defined initial (or input) state, a known goal state or solution and a constrained
set of methods for solved the problems.
Ill Structured problems often have aspects that are not well understood, they
are interdisciplinary [i.e. can not be solved by applying concepts and
principles from a single domain]; they usually have poorly defined initial or
input conditions and may possess multiple solutions or solution methods or
often no solution at all.
Wicked this type of problem is similar to ill-structured problems except that
the problem parameters may change significantly within short time periods
requiring a constant re-appraisal of solution methods, domains and possible
end goals. It is due to the changing nature of the problem parameters that the
term wicked was coined.
2. Complexity is determined by the number of issues, functions or variables
involved in the problem, the degree of connectivity among these variables, the
nature of the functional relationships and the stability of these properties over
time. Hence complexity and structuredness overlap. Ill structured problems
tend to be complex.
3. Dynamicity is a measure of the stability of problems, moreso how the problem
parameters change over time (rapidly, slowly, etc). As the problem parameters change
so must the understanding of the problem to enable solutions to be developed, where
Les &encel %" $%'Mar'%""!
feasible. Wicked problems are an extreme example where the problem state changes
so quickly, that the formation of solutions needs to be continually revised.
Consequently, solution-oriented methods may not be feasible.
4. Domain context refers to the observation that problems within a domain rely on
cognitive operations that are specific to that domain. Problem solving activities
therefore are dependent on the nature of the context or domain knowledge.
It is proposed to develop a problem typology for defence systems that will provide
insight to the nature of the problem to be tackled and thereby to the relevant problem
solving methods.
'+ A Typology of Systems
Hitchins provides a five layer model of systems in terms of increasing complexity. It
is proposed to develop a similar typology for defence based systems for use in
understanding at what level a defence system sits. The combination of proper
identification of system type along with a problem typology for the nature of problems
found within the various life cycle activities of the system provide a basis for selection of
problem solving methodologies
'3 Attri&"tes for selection of systems -engineering.
processes an practices
The previous sections have described the generic processes of systems engineering,
systems engineering life cycles phases, Hitchins 5-Layer model mapped to a Defence
model, and the dimensions of problem solving. Each of these can contribute to a set of
problem attributes such as:
Structuredness can be represented on a Likart scale
Complexity a suitable range e.g. TSIs simple and complex
Context Nature of the problem
Level associated with Hitchins 5-layer model.
Phase associated with the ISO 15288 life cycle processes
Problem of interest mapped to the most logical 15288 process(es)
Dynamicity is the problem static or changing with time, how quickly?
It is postulated that the selection of an appropriate set of problem solving
methodologies is a complex cogitative process that is akin to parsing the tree structures
associated with complex decision making problems. This will be explored further in the
research. A key point here is that the processes need not be (nor usually are) sequential,
the process can be quite non-linear with the individual applying different weighting
criteria based on experiential judgement.
Les &encel %$ $%'Mar'%""!
It is this key activity that is at the heart of methodology selection.
'4 Expecte Contri&"tion
Contemporary systems engineering practice as applied to modern defence systems
still tends to apply traditional systems engineering processes and practices. As discussed
earlier, modern defence systems tend to be found at level 3 and 4 of Hitchins system
typology model and consequently implies that traditional systems engineering practice is
poorly suited for these class of systems.
Whilst the Defence community is exploring alternative methods to assist in the
planning and development of Defence capability (the most recent being Capability Based
Planning), little thought has gone towards the selection of appropriate problem solving
methodologies for the life cycle development of these systems.
Currently there does not exist any theoretically based method for the selection of
appropriate problem solving methodologies across the life cycle phases of a modern
defence system.
The outcomes of this research combines the ideas of systems engineering and
cognitive problem solving to propose a list of attributes that can be used to characterise
systems engineering problems at various phases within a systems life cycle and thereby
provide guidance as to the appropriate mix of problem solving methodologies.
The outcome will use an ISO 15288 framework within which system activities can be
related to problem solving methodologies in a robust theoretical manner. This framework
will permit the development of a rich picture of the problem types to be encountered and
thereby facilitate an understanding of the mix of methods from different social models
that may be necessary to solve or manage the problems.
This will result in a more rigorous application of systems engineering processes and
practices to complex systems and assist in better aligning user expectations with system
operation and performance.
As a minimum, such knowledge would assist novices to get started and avoid
inappropriate applications of systems engineering. In an environment, such as a research
laboratory where systems engineering is not considered a core skill, this knowledge
would be very useful for those who are tasked to produce a concept demonstrator, assist a
development project, or provide advice to capability development.
More appropriately, it would be a valuable tool for the informed systems practitioner
to facilitate and develop the framework of considerations necessary to ensure that an
Les &encel %% $%'Mar'%""!
appropriate mix of methods is chosen for any particular task.
Les &encel %0 $%'Mar'%""!
1) Researc% *et%o$ology
'6 ,iterat"re /e0ie1
A literature review will )e un6ertaken to stu6y the various system engineering processes an6
practices currently )eing applie6 in /efence systems as well the nature of comple5ity in mo6ern
systems, approaches towar6s engineering comple5 systems an6 their relevance to military
6efence systems* A further stu6y will )e un6ertaken into multimetho6ology practices as employe6
in the management sciences an6 their relevance to 6efence oriente6 systems*
<inally, a stu6y will )e un6ertaken to 6iscover within the literature, the current state of the art
with respect to theoretical approaches to systems engineering of comple5 systems an6 their
relevance to 6efence systems*
'! Methoology
A two fol6 approach will )e taken in the system of metho6s applie6 to this research pro)lem*
a. "n #M" "pproach
Checklan6 an6 =olwell 8$##49, state that there are three elements necessary to 6escri)e any piece
of research>
(he Area of Concern 8A9, which might )e a particular pro)lem in a 6iscipline 8area of
stu6y9, a real'worl6 pro)lem situation, or a system of interest*
A particular linke6 framework of i6eas 8<9 in which the knowle6ge a)out the area of
concern is e5presse6* +t inclu6es current theories, )o6ies of knowle6ge, heuristics, etc as
6ocumente6 in the literature as well as tacit knowle6ge*
(he metho6ology 8M9 in which the framework is em)o6ie6 that incorporates metho6s,
tools, an6 techni?ues in a manner appropriate to the 6iscipline that uses them to
investigate the area of concern*
<igure 4 e5tracte6 from Checklan6 an6 =olwell 8$##49, illustrates the relationship )etween these
three elements an6 how un6ertaking the metho6ology creates new knowle6ge a)out all three
elements*
<igure 4> Elements relevant to any piece of research 8Checklan6 an6 =olwell, $##4> p $09*
+n the conte5t of this research pro)lem,
$* Area of concern is how 6oes one select appropriate pro)lem solving metho6ologies
associate6 with the application of systems engineering in the various life cycle phases of a
6efence system*
%* <ramework of i6eas will comprise a num)er of items such as the +S. $!%44 framework,
=itchin@s work on systems engineering, a num)er of approaches on pro)lem typologies,
concepts from <loo6 an6 Aackson in terms of their (otal Systems intervention concept,
Mingers an6 Bill@s work on Multi'metho6ologies, heuristical knowle6ge from -echtin an6
Maier plus an assortment of concepts an6 i6eas from the )roa6er literature
0* (he metho6ology or in this case the system of metho6s to )e use6 will comprise a systems
analysis of the source material, an6 a postulate of the outcome to )e e5amine6 for theoretical
correctness an6 practical soun6ness*
b. Practical "ssessment of Method
(he secon6 component to the metho6ology is in support of the last statement in point a namely
Cpostulate of the outcome to be examined for theoretical correctness and practical soundness*D
'the focus )eing on Cpractical soun6ness*
+t is propose6 to review a num)er of 6efence systems that have )een 6evelope6 )y the author over
the course of this research program an6 assess how well the concepts propose6 with the research
work align with practical e5perience* (hese stu6ies will take the form of case stu6ies* (heir use is
to apply some gui6ance an6 insight into the practical utility an6 theoretical soun6ness of the
approach*
'$ Case St"ies
+t is propose6 to un6ertake a num)er of case stu6ies of the systems engineering metho6s applie6
to a selection of 6efence programs* (he case stu6ies will )e selecte6 across a range of system
types an6 pro)lem comple5ity*
'2 %"&lications
A num)er of reports an6 conference pu)lications will )e pro6uce6 an6 su)mitte6 to international
conferences an6 Eournals*
Les &encel %! $%'Mar'%""!
2+ ,or- Plan
This work is being undertaken part time as the researcher is employed on a full time
basis within his own systems engineering consultancy. It is anticipated that the work will
be completed in December 2006.
Timeframe Activities
1999/2000 a. Enrolment
b. Draft Research proposal
c. Review of classical system engineering techniques for
concept technology demonstrators (CTD)
d. Review of literature on CTD development
e. SETE 99 paper
2001/2002 a. Review of literature on Soft Systems Techniques
b. Checkland, Senge, Flood and Jacksons TSI
c. Klines work on multi disciplinary thinking
d. Work on Defence Capability and effects based domain
partitioning
e. Reports on Systemic behaviour of Defence Capability
domain structures
f. INCOSE 2002 paper
2003/2004 a. Extension of research into enterprise level systems
b. Hitchins and Rechtin and Maiers work
c. Report on Organisational Intervention 2003
d. DSTO reports
e. INCOSE 2004 paper
f. SETE 2004 paper
2005 a. Update to PhD research Proposal
b. Research into attributes for ISO 15288 activities
c. Problem typology to be developed
d. Modified Hitchins Typology
e. Finalise theory and process
f. Begin writing sections of PhD
g. Proposed INCOSE 2005 paper (accepted)
h. Proposed SETE 2005 paper
i. DSTO Research reports
2006 a. Case studies review and test theory and process
b. Continue to finalise draft thesis
c. Mid Year review of draft thesis
d. End of year completion of Thesis
21 References
Arnold S., and Cook S., (2002), Developing a Coalition Systes
!ngineering "rocess#, INCOSE Insight $ol %, &o ' pp ()*.
Avison, D. E. and Fitzgerald, D., (2003) Information Systems Development:
Methodologies, Techniques and Tools, McGraw Hill Book Company Europe. Third
edition.
Cook, S.C., (2003) Systems Engineering for Complex Problem Solving, Course Lecture
Notes, University of South Australia.
Cook, S*C*, 8%""19, C(he -ise of Systems Engineering within the Australian /efence
.rganisationD, in Procee6ings of the %""1 +EEE +nternational Engineering Management
Conference, Singapore, $4 to %$ .cto)er %""1, pp :! to :#*
Cook, S. C., Kasser, J. E. and Ferris, T. L. J., (2003) Elements of a Framework for the
Engineering of Complex Systems, Proc. of the 9th ANZSYS Conference, Systems in
Action, 18-20 November 2003, Melbourne, Australia, Paper No. 3000079.
DoD (2002), Capability System Life Cycle Management Manual, Department of Defence,
Australia.
DSMC, Systems Engineering Management Guide, Defence Sysrtems Management
College, Fort Belvoir, Virginia, USA, 1993
Hitchins D. K., (2003) Advanced Systems Thinking, Engineering, and Management,
Artec House, ISBN 1-58053-619-0.
Hodge, R.J. (1998)Defence Capability Development -Learning from the Future, in
Proceedings of SE98, Canberra, Australia, 4-6 November 1998, pp. 43-56.
Hodge, R. and Walpole, G., (1999), A Systems Approach to Defence Capability
Planning A Work in Progress, in Proceedings of SETE99, Adelaide, Australia, 20-22
October 1999, pp. 21-32.
INCOSE. Systems Engineering Handbook (v 1.0), International Council on Systems
Engineering, 1998.
Les &encel %: $%'Mar'%""!
ISO/IEC 15288, System engineering System life cycle processes, ISO/IEC.
Jackson, M.C. and Keys, P. (1984). Toward a systems of systems methodologies. Journal
of the Operational Research Society, 35, 473-486
Jackson M. C., (2000) Systems Approaches to Management, Kluwer Academic/Plenum
Publishers, ISBN 0-306-46506-X.
Jonassen, D.H. (2003). Learning to Solve Problems: An Instructional Design Guide,
ISBN: 0-7879-6437-9 Hardcover 256 pages December 2003, Pfeiffer.
MPherson P. K., Systems Engineering: an approach to whole system design, The
Radio and Electronic Engineer, 1980, Vol. 50, No 11/12, p545-558
M+L'S(/)+**,, (-**+), Systems Engineering, .S Departent of Defence.
Mingers, J. and Gill, A. (1997), Multimethodology, The Theory and Practice of
Combining Management Science Methodologies, Wiley, ISBN 0471974900.
Shear6 S* A* & Lake A* B*, Systems Engineering Mo6els an6 Stan6ar6s Compare6, Software
Pro6uctivity Consortium, .nline Accesse6, .cto)er $##4*
http>FFwww*software*orgFpu)FpapersF#4"1'%*html

PHD Research Proposal

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

PHD Research Proposal

Caricato da

Copyright:

Formati disponibili

PhD Research Proposal

PhD Research Proposal

Potrebbero piacerti anche