Technical Paper Abstracts Tab

Document Sample
Technical Paper Abstracts Tab Powered By Docstoc
					                               Technical Paper Abstracts
The following section lists technical paper abstracts in the order in which they appear in the
program as well as the reserve papers which may be substituted for withdrawn papers
scheduled for presentation.
The number shown before each abstract title indicates the paper reference number (track,
session, paper sequence). The papers are published in the Symposium proceedings with the
corresponding paper number.
                                                Paper Abstracts

SESSION 1

1.1.3    Educating Systems Engineers: Encouraging Divergent Thinking
W. McCumber, C. Sloan, EagleRidge Technologies, Inc.
Parallels between divergent thought processes, studied in creativity research by developmental psychologists, and
the intellectual control imperatives of systems engineering are examined. A metaphorical template of the systems
engineer's thought processes as defined by and taught from the standpoint of convergence is presented, and a core
set of training modules to aid in evolving systems engineers from domain engineer stock is recommended. A. D.
Hall's 1969 model of the systems engineer's thought structure is resurrected and is found to still apply to the
convergent mode of systems engineering training. It is suggested that teaching systems engineers to develop
divergent thought processes is analogous to teaching ―creativity‖ in other fields. An examination technique,
employed with success in a related field (e.g., Microsoft certification), that uses the traditional "convergent" multiple
choice question, but forces divergent thinking to arrive at the ―correct‖ answer, is discussed.

1.1.4    The „Learn from Experience‟ (LfE) Journey in Systems Engineering
B. Meakin, B. Wilkinson, BAE SYSTEMS
This paper describes how ‗Learning from Experience‘ (LfE) encompasses and pervades the popular domain of
interest ‗Knowledge Management‘ (KM) throughout the life cycle of a project. This paper is NOT about KM. It is
about the development, retention and re-use of tacit knowledge or wisdom. If KM captures the explicit knowledge
that can be captured and extracted from databases, then LfE adds to this the tacit knowledge [or wisdom] of those
who have ‗been there and done it.‘ By combining explicit and tacit knowledge we have the better of two worlds co-
existing together in a self-learning and self-sustaining process.
As Systems Engineering can be expressed as a Socio-Technical activity it is appropriate that Systems Engineers
utilise LfE to inform the Enterprise, project and the personal knowledge base as early as possible in the project life
to ensure the chosen system solutions are those with the best opportunity for success.
LfE is generic and is just as appropriate for a non-engineering enterprises, for example a Banking Institution.

1.1.5    Systems Engineering in COTS-Based Systems
L.H. Fan, Adsystech Inc.
As more and more software systems are developed by extensively making use of COTS products in recent years,
applying systems engineering disciplines to a COTS-based system is essential for building a successful system. A
COTS based system is different from the traditional software system in that it uses COTS components as the basis of
the system functionality. This means the new activities will become part of the software development process and
the risks will bring to the system development process.
This paper identifies these differences and difficulties from the system engineering's point of view, and focuses on
the major system engineering activities in all stages of a COTS-Based System life cycle. These activities are not
only considered the technical aspects of the COTS based system, but also none technical aspects, such as
marketplace research, management and business strategy and process. In order to provide a cost-effective software
development solution in COTS based system, this paper introduces the Adaptive Enterprise Solutions (AES)
platform system.

2.1.1    Systems Engineering Realization and Introduction of a Market Model
B. Genz, A. Vollerthun, Technishe Universitat Munchen
This paper describes the development process of a market model and the model itself. This market model enables
the user to simulate the market success of future products on future markets with regard to many influences like
competitors and information about the consumer. It is implemented as a software tool. The challenge of this project
was to find a structure of the market, which is quantifiable and connectable in a proper way. To achieve this, a
special method of developing the model was used. This method is described within the first chapter of this paper.
The results of this method are quantified and connectable models. The way how these models were designed and
the way they work together with their meaning in the context of the market is shown by some examples, which are
related to common problems in business. To demonstrate the strength of the model, some results of the produced
software tool are presented in the ―Output‖ chapter.
This market model is able to improve the process of product development and the whole means which are connected
to the product. But the efficient use of the model requires an integration in the product development and marketing
process.

2.1.2 Use of Constraint Programming Techniques for Systems Pre-Design Involving Several
Technical Fields (Application on an Example of an Aircraft Weapon Delivery and Navigation
System)
P. Kou, C. Regniez, P. Pagniez, Dassault Aviation
Systems pre-sizing involving several technical fields is generally based on a method where up-going validation
phases follow down-going analysis phases. Meanwhile, the usual tools, when they exist, are often optimised to work
in a single way.
The Constraint Satisfaction Solving Method (CSSM) introduces a technique, which fulfil the needs of preliminary
design, putting aside the notions of "input" and "output". Moreover, Constraint modelling is a way to ensure the
consistency between the different technical fields.
A simplified example illustrates the problem on the Weapon Delivery and Navigation System of a military aircraft,
underlining the many capabilities of the method.
As a conclusion a feedback on its introduction at Dassault Aviation's Systems Directorate is presented and
specifications for a Constraints Models Managing tool are introduced.

2.1.3    Functional Analysis for Existing Products: A Detailed Procedure
V.A. Lentz, B. Lerner, Otis Elevator Company
Functional Analysis (FA) for regenerative systems is often executed as reverse engineering or design recovery. The
initial product developer completed the Functional Analysis, and minimal updates were required or took place as the
product evolved. The working definition of a function has often become ambiguous. When the goal is to reify what
the product/system does, Functional Analysis is one method to be used in conjunction with the identification of the
scenarios to support a system decomposition to discover underlying functions. The scenarios identify how the
system/product is used by external systems (a human or other man-made system) and FA helps to expose the system
behaviors that are required to support that use, and the functions that are required to support that behavior. The
value of functional analysis is the yield of the main and derived functions of the system/product, which are the
solution independent functions. The separation of the domain functions from the subsequently developed
implementation functions (those required to provide a design dependent capability) facilitates the insertion of
technology and management of change.
The transition of the modular product structure Adifon [ADI2001] from the Phase 1 team to the on-going
implementation required the clarification and documentation of a procedure for Functional Analysis. The generic
part of that procedure is described here with templates and detailed ‗user‘ instructions.

2.1.4    Use Case Development Integrated in a Systems Engineering Environment
D.K. Smith, EDS PLM Solutions/SLATE Deployment Services
The ability to capture stakeholder interests early in a system‘s evolution is critical to successful deployment of the
system over its lifecycle. The concept of capturing user functionality as use cases is beginning to be used in systems
engineering. Most use case content development consists of the manual process of documenting use case
information as text in a CASE tool or in a word processor.
This paper describes one approach to integrating use case development in the systems engineering environment.
Each element of the user-defined use case template is an object in the SLATE [(Systems Level Automation Tool for
Enterprises) – a collaborative, front-end, object-oriented SE development environment] Database. The benefits
include: capturing relations among user needs, use cases, requirements, architecture, implementation, product
lifecycle, affected parties, and external CASE tools.
The collaborative environment assures that all users work with current data. Custom reports and metrics allow
tracking use case progress, issues, etc.

2.1.5    Does Object-Oriented System Engineering Eliminate the Need for Requirements?
J. Kasser, UniSA
This paper examines system engineering (SE) and object-oriented (OO) methodologies and then shows both that SE
is inherently OO and that OO languages such as the Unified Modeling Language (UML) may be used to document
the user‘s needs in a manner that can be used by developers. The paper also suggests a next generation tool concept
that can be used to hold both user and developer representation of the user‘s needs as an alternative to, and an
improvement on, text mode ―requirements,‖ hence increasing the reliability of the shared meaning of the user‘s
needs amongst all stakeholders.

3.1.1    The Case for Systems Management
H. Mooz, K. Forsberg, Center for Systems Management
At the INCOSE 2001 International Conference we were awarded the INCOSE Pioneer Award for ―tirelessly
working to integrate project management and systems engineering.‖ In the environment of project management and
system engineering, especially in aerospace, this concept is often referred to as Systems Management and there are a
few Masters Degrees in Systems Management available from U.S. Universities. However, Systems Management is
often viewed as the integration of computer systems, which is not our intent.
This paper addresses the definition, need, heritage, evolvement, application, realization, benefits, and visualization
of Systems Management. The concept is rooted in the seamless integration of business and technical management
such that all technical decisions are business and customer driven to ensure the right system is being built, right.

3.1.2    Organizing for Successful System Development
P.A. Rosen, University of Maryland University College
While many options are available to organize a development organization for success, applying basic elements of
system engineering management in defining, building, controlling and maintaining the organization chartered to
develop the system will provide a solid foundation for the system engineering effort. This foundation will provide
focus on the system under development and the processes to be applied to the development, rather than on
organizational roles and responsibilities. While the proper organization will not guarantee success, inadequate
organization of the effort will make the difficult process of system engineering a monumental challenge.

3.1.3    How to Nurture Systems Engineering in House: A Case Study
S. Katz, A. Zonnenshain, H. Mizrahi, Rafael
J.G. Lake, Systems Management International
RAFAEL is a company at the leading edge of weapon system development. RAFAEL develops, manufactures and
supports products for every branch of the Israel Defense Forces (IDF) and for defense forces of foreign governments
worldwide.
In 1998, RAFAEL identified the need to improve systems engineering competencies of the engineering workforce.
With the absence of systems engineering programs within Israeli universities or through Israeli industries, RAFAEL
developed its own in-house training program.
This paper describes the manner in which systems engineering program needs were determined and the initial
program design created. The method and results of course evaluations are discussed with a summary of lessons
learned and continuous improvements planned.

3.1.4    Emergence : A Partial History of Systems Thinking
G. McConnell, BAE SYSTEMS
Systems Engineers require a good knowledge of both engineering and systems concepts. Inevitably, there will be
few who are equally strong in both areas of knowledge. This paper offers a brief overview of the history of systems
thinking, concentrating primarily on those areas which relate specifically to the understanding of emergent
properties of systems. Whilst inevitably only a whistle stop tour of the subject the paper offers insight into both the
depth and the breadth of systems knowledge available. It is intended as a starting point for those interested in
finding out more.

3.1.5    PARTITIONING NATIONAL DEFENCE INTO PORTFOLIOS
S. Cook, Systems Engineering and Evaluation Centre
T. Moon, Defence Science and Technology Organisation
L.J. Vencel, VCORP Consulting Pty Ltd.
Partitioning national Defence into portfolios, where key capabilities and activities are appropriately aggregated
together, has been suggested as an effective way to manage national Defence. This paper examines in detail the
application of a heuristic approach to achieve this, assessing the efficacy of various ways of partitioning national
Defence using the established heuristics of systems architecting. The insights gained may then be applied to
configure or refine the structure and to establish linking of the portfolios.

4.1.1 Applying Integrated Product and Process Development (IPPD) on the U. S. Army Multi-
Role Armament and Ammunition System (MRAAS)
R.D. Moulder, James Gregory Associates, Inc.
M.V. Cilli, TACOM-ARDEC
The following quote was made by then Secretary of Defense, Dr. William Perry, on 10 May 1995.
―...I am directing a fundamental change in the way the Department acquires goods and services. The concepts of
IPPD and IPTs shall be applied throughout the acquisition process to the maximum extent practicable.‖
The purpose of this directive was to help reduce the ―cost of the acquisition process by the elimination of activities
that, although being performed by many dedicated and hardworking personnel, are not necessary or cost effective in
today‘s environment.‖ Subsequently, the DoD Guide to Integrated Product and Process Development was released.
This guide defines IPPD as, ―A management process that integrates all activities from product concept through
production/field support, using a multifunctional team, to simultaneously optimize the product and its manufacturing
and sustainment processes to meet cost and performance objectives.‖
Since 1995, the various components of the United States Department of Defense have been implementing IPPD by
allowing program managers the flexibility to choose the best IPPD practices and tools available for their programs.
Much of the focus has been on acquisition programs, but the use of IPPD is now being pushed back into the Science
and Technology (S&T) area as well. In fact, the Air Force Research Laboratory policy now is to use IPPD on all
Advanced Technology Demonstration (ATD) Programs. The U.S. Army has also applied IPPD on several S&T
programs such as the Future Scout Cavalry System (FSCS).
This paper presents the results of applying IPPD on the U. S. Army Multi-Role Armament and Ammunition System
(MRAAS) Munition Suite Program. We first introduce the MRAAS Munition Suite Program and the rationale for
the IPPD Process USFD—including the definition of the systems engineering process and tools. We then discuss
the specific application of this process on the MRAAS Munition Suite Program. An overall objective was to apply
the systems engineering process early in the life cycle of the system beginning with concept definition through
manufacturing development into full-scale production. In this discussion, we describe the unique approach that was
used in the Request for Proposal (RFP) and subsequent contract award. We conclude with results to date of the
application of the IPPD Process and offer observations for application to other Defense programs.

4.1.2    Geographic Information Systems (GIS) Applications And Trends
S. Raza, University of Maryland University College
This paper presents an overview of GIS technology, its impact on various industries, current GIS technology trends,
GIS standards, and systems engineering roles and challenges in the field of GIS. It introduces an overview of GIS
technology i.e. what is GIS, how does GIS work, and what distinguishes GIS from other information systems. GIS
is very much a multi-disciplinary technology and can accommodate several application areas by integrating data
from a variety of sources in a detailed and efficient manner. The paper discusses the impact of GIS application upon
various disciplines e.g. business, engineering, political boundaries management, transportation, environmental
management, natural resources, health care, and education. The development and application of geographic
information systems is vibrant and exciting. The paper further reviews the existing and latest trends in GIS
technology including new data sources, hardware and software developments. GIS is a rapidly growing field and
requires an inherent need to have a set of common standards and rules to successfully complete GIS projects within
time and budget. The paper also provides an overview of existing and future GIS standards and discusses the roles
of various organizations involved in the development of GIS standards. Many areas in GIS are systems related and
systems engineering can play a major role in helping GIS industry to be more productive and efficient to meet its
customer needs. GIS technology, however, is relatively new and almost no formal systems engineering processes
and practices are being applied. The paper addresses the major challenges faced by Systems Engineering in the
development and management of GIS based systems.

4.1.3    Selection Process for System Design Using Field Programmable Gate Arrays
C. Mirchandani, Lockheed-Martin Space Operations
Implementing image extraction algorithms for MODIS has shown the advantage of using Field Programmable
Devices to implement CPU intensive functionality very clearly. The technology is not without its disadvantages.
The task of translating the processing algorithm into VHDL code for synthesizing the design is complex. Very fast
devices led to the belief that the disadvantages are well worth the minor disadvantages of labor-intensive translation
phase. However, this is not so. Analysis of the prototype effort in the implementation of FPGAs to perform image
extraction showed a ten-fold improvement in the actual process and extract function. However, the total labor effort
to develop and provide the process, system and hardware to perform the processing took almost as long and cost just
as much.
Albeit, the replication and reuse of the system was two magnitudes lower in cost. The idea pursued in this paper
investigates the use of FPGAs in the post-processing of telemetry data (or other) data by selectively optimizing the
design solution. The criteria for system selection are based on complexity, design time and data availability. The
paper will describe the process by which the criteria are selected, rank ordered and evaluated for comparison. A
simple design exercise will be illustrated as a demonstration.

4.1.4 Applications of Conditional Inferential Methods for Operational Cost Savings for US Coast
Guard C130 Aircraft Maintenance
M.A. Powell, University of Idaho at Idaho Falls
E.B. Sheppard, Jr., U.S. Coast Guard
Maintenance costs play a significant role in the overall operational cost of the US Coast Guard (USCG) fleet of
C130 aircraft. Selection of the preventative maintenance interval for the C130 1500 Series Flight Deck Cooling
Turbine provides an opportunity for considerable maintenance cost savings. If this turbine fails in service, it may be
damaged beyond repair and cost $30,000 to replace. If overhauled before failure, the cost is typically $500. The
USCG currently allows this turbine to fail in service, and is considering a preventative maintenance schedule of
periodic overhauls. Failure data for this turbine is relatively scarce however. This paucity of data magnifies the
perceived impact of uncertainties in the data, which all but paralyzes USCG decision makers charged with selecting
an overhaul interval. The authors process failure and replacement cost data for this turbine using conditional
inferential methods. Statistical distributions of Expected Costs Savings per Flight Hour are parameterized as a
function of overhaul interval. These distributions and related estimates allow USCG decision makers to confidently
select an overhaul interval that minimizes maintenance costs and is commensurate with existing maintenance
schedules.

4.1.5    Development of a Systems Verification, Validation & Testing-Methodology
A. Vollerthun, Institute of Astronautics, Technical University of Munich
A. Engel, Israel Aircraft Industries (IAI)
C. Haskins, Norwegian Systems Engineering Council
While many are aware of the Rule-of-Ten, describing the effects of late changes in the product development
process; system verification, validation and testing are activities that are often regarded as tasks to be done at the
very end of the development. This perception causes a number of problems (in terms of time-to-market, expenses,
etc.) for many enterprises. Being aware of this situation a consortium of eight European companies, research
institutes and organizations has formed to develop a methodology for system Verification, Validation and Testing
(VVT). The project was launched in March 2002 and will continue for three years. It will be carried out with
funding from the European Community under the 5 th Framework Program (Project G1RD-CT-2002-00683). This
paper gives an overview of the objectives, structure and the contents of the project. The paper is a first in a series
that will report on the progress of VVT methodology development.

5.1.4    Towards Continuous Integrated Process Improvement
I.I. Langenberg, Thales Naval Nederland B.V./Business Unit Combat Systems
J.F.B. Gieskes, University of Twenty, School of Management
This paper describes the path towards continuous and integrated process improvement within Thales Naval
Nederland B.V, and more particular within it‘s Business Unit Combat Systems. The paper‘s Leitmotiv is formed by
the individual concepts: Continuous, Integrated, Process, and Improvement.
A major internal reorganisation of the company late ‘99 together with external trends in the process improvement
domain (e.g. CMMI), created a momentum for the regrouping and re-orientation of process improvement activities
within the company.
The company‘s experience with and lessons learned from several process improvement projects, and the unit‘s
reorganisation activities and results are reflected upon by the Leitmotiv and used to identify challenges for the future
with regard to process improvement. These challenges are captured in specific goals by senior management,
enabling the Business Unit to focus its future efforts on the path towards continuous and integrated process
improvement.

5.1.5    A Systems Engineering Methodology for Combat Systems Development
R. Merritt, SEEC
Combat system development is difficult to do well; many issues surround the development of such systems. The
history of the creation of large, complex, socio-technical systems has been marred by a litany of project failures.
Poor project outcomes result in business failure and significantly reduce the capability that can be achieved for the
modest defense budgets of countries like Australia, Austria, Belgium, Canada, the Netherlands, Spain and Sweden.
This situation is being exacerbated by the increasing dependence of modern military systems on software and the
increasing complexity of such systems. This paper highlights major issues faced by the defense industries of
‗intermediate‘ nations such as those listed. It proposes a solution in the form of a systems engineering methodology
appropriate to combat system development.

6.1.4 Implementing SE and ODM in Railway Projects: Innovating a Conservative Line of
Business
M.H. van der Ploeg, Railinfrabeheer
SE (Systems Engineering) is a well-known and frequently used methodology in the Aerospace and Defense
industry. The problems associated with the Civil Engineering industry are comparable to that of Aerospace and
Defense industry when it comes to the characteristics of processes, products, and efficiency. However, the Civil
Engineering industry does not resemble other industries on how to deal with the problems. One of the reasons is
that it is a very conservative line of business. Ever since Railinfrabeheer, which is one of the major companies in
the Netherlands, started implementing SE and Object Data Management (ODM) methods. This article describes the
characteristics and problems in the Civil Engineering industry, and also expounds on the models, methods, and tools
Railinfrabeheer uses. These methods, derived from SE and ODM, are used in the successful development of railway
systems. Finally it points out the necessary conditions for succesful implementation and mentions several benefits
experienced by the use of these methods and models.

6.1.5    Dynamic Interface Management in a Transport Infrastructure Project
L. Wildenburg, ADSE B.b.v. Consultancy & Engineering Service
P. van Kleunen, Project Organisation HSL-Zuid
This paper describes how Systems Engineering methods have been applied for the specification and interface
management of the Dutch high-speed line project (HSL-Zuid), and the lessons which have been learned from this
experience. This project is complex both in size and in the number of internal and external interfaces. The
management of these interfaces is a challenge for which Systems Engineering provides a good approach, but the
application is different from the applications in other industries. The focus of this paper is on the interface
management of Design & Construct type contracts with high level functional specifications.
SESSION 2

1.2.1 Computer Based Training: A Structured Solution Accommodating Diverse Learning
Situations
E.P. Arnold, United Defense International
Computer Based Training (CBT) courses have solved several of the inherent problems associated with the
previously preferred Instructor Led Training (ILT) delivery in industry. The problems associated with Instructor
Led classes as a one-size fits all solution to education and training are identified. A CBT solution, a self-paced
learning solution, is explored as an additional choice to accommodate diverse learning situations and knowledge
levels. This Case Study continues with an overview of curriculum development, processes used to develop the CBT
courses and learner acceptance.

1.2.2    Better Systems Engineering with Dialogue
G. Backlund, J. Sjunnesson, I. Johansson, Combitech Systems AB
Managing knowledge involves having the ability to establish intersubjectivity between a group of individuals. This
paper describes two case studies where an advanced and highly structured dialogue is used as the key instrument for
generating new ideas, and for establishing a common understanding of a new subject. Together with Prof. Bo
Göranzon at the Department of Skill and Technology at Sweden‘s Royal Institute of Technology (KTH), Combitech
Systems AB spent four years developing Dialogue Seminar method. After a period of thorough testing at Combitech
Systems, the method has been in use at a number of other development organisations. The method is based on a
view of knowledge developed by philosophers such as Aristotle, Descartes, Diderot and Wittgenstein, where tacit
knowledge—or experience-based knowledge—is central. The purpose of the concept is to give a wider
understanding of knowledge, and the basic procedure involves training people to change perspective in order to
stimulate new thinking. The three different cases clearly demonstrate that the Dialogue Seminar method can be
successful in different situations, for example, gathering experience from a completed project, establishing a
common language in a newly formed team or helping to specify a new product.

1.2.3    A Structured Approach to Developing a Systems Capability
S. Goodlass, A. Phillipson, BAE SYSTEMS
In November 1999, British Aerospace and Marconi Electronic Systems merged to become BAE SYSTEMS, one of
the 3 largest Systems, Aerospace and Defence companies in the world. In order to maintain and improve the
company‘s capability, Engineering Developing You (EDY), has been created. EDY forms part of an integrated
framework for personal and professional development – but with over 20,000 engineers just in the UK, and almost
the same number again in overseas divisions and joint ventures - the task itself is far more complex than may at first
appear.
For an (ex-)Systems Engineer now working in the Virtual University, given the task of designing and developing
this framework, using a structured Systems Engineering approach seemed to be a sensible approach. So how easy
was it to apply a ‗soft system‘ approach and how successful has it been??

1.2.4    Let‟s Just Think About That For A Minute
G. Gilmour, General Dynamics Canada
This paper contends that there is a strong relationship between disciplined thought by the individual and the system
engineering process. The paper explores this relationship by discussing ideas on how people think and illustrating by
analogy the closeness of this activity to that of system engineering. The significance of this is that if individuals
perform disciplined reflective thinking in a systematic manner then as a collective whole they are more naturally
inclined to follow the general principles of good system engineering practice.
1.2.5    Capstone Design in Education: Systems Engineering and the West Point Way
M. J. Kwinn, Jr., E. Pohl, M. McGinnis, B. Carlton. United States Military Academy
The United States Military Academy, the nation‘s first engineering institution, is celebrating its 200th birthday. The
Department of Systems Engineering, established in 1989, offers a successful, accredited undergraduate degree in
Systems Engineering. Although young by Academy standards, the program has become one of the most popular
engineering disciplines at the Academy.
Each year, approximately 40 cadets major in Systems Engineering and another 30 cadets choose it as a Field of
Study (FOS). Cadets are introduced to the different tools and techniques of systems engineering in their course
work. The program culminates with a year long group design experience that allows the cadets to put the various
tools and techniques into practice on a real world problem. This paper will focus on how the year-long design study
is integrated into our curriculum and has become what we believe is an outstanding experience for our cadets which
enables them to enter the Army as confident leaders and engineers.

2.2.4 Operational Concepts and the Case for Use Cases: Unifying UML with Systems
Engineering
R. Jorgensen, Rockwell Collins, Inc.
Operational Concepts have been used in varying degrees for many years by government acquisition agencies and
contractors to help understand the operational nature of systems. Seldom, however, have the concepts been used at
subcontractor levels or been encouraged by subsystem developers. Nor has there been much formality in the use
and structure of the operational concept document (OCD). The typical content of the OCD remains highly textual
with verbose description and little discipline in the thought process. The Unified Modelling Language (UML) has,
however, introduced the notion of the Use Case, which, when examined as to purpose and focus, may provide an
excellent basis for formalising the OCD content and providing a tool to help capture more effective operational
scenarios at all levels of system composition. This paper explores the use of the UML Use Case as an essential part
of the system Operational Concept.

2.2.5    Analysis of the Rational Unified Process
J.N. Martin, The Aerospace Corporation
J. Bedocs, General Dynamics
Recently, Rational wrote a white paper that introduces a derivative of the Rational Unified Process (RUP) that
addresses the problem of system specification, analysis, design, and development. This paper describes an analysis
of suitability of the extended RUP for use in the engineering of systems. A comparative analysis is performed
between RUP and two systems engineering standards—ANSI/EIA 632 and the C4ISR Architecture Framework.

3.2.4    A Project Managers User‟s Guide to Risk-Based Decision Support Products
B.B Roberts, D. Frost, Futron Corporation
Who will find this paper useful? This paper is designed for the mature project management professional who intends
to make risk-based decision making a fundamental, integrating principle of the project‘s operating processes. This is
in contrast to the more common approach of having a separate, stand-alone process for risk management in which its
contribution of information into other decision-making activities is arbitrary. The paper presents advanced integrated
quantitative techniques and tools that have been proven to have high utility to decision-makers.
This paper presents the following tools and techniques and their utility:
1.       Cumulative Distribution Functions (CDF‘s) for project completion date
2.       CDF‘s for cost estimate at completion
3.       Double Pareto boxes
4.       Stochastic Critical Path Analysis

3.2.5    A Risk Management Approach For Effective COTS Acquisition And Life Cycle Support
G. Shaffer, Federal Aviation Administration
The use of commercial-off-the-shelf (COTS) products as part of an acquisition strategy has continued to present
unique challenges to both acquisition and user organizations including the Federal Aviation Administration (FAA).
Using a system engineering programmatic risk management approach, the FAA has developed a risk mitigation
methodology adapted to the acquisition and life cycle support of COTS-based systems. Based on industry and
government ―lessons-learned,‖ this methodology addresses COTS-based risk factors and practical acquisition-
phased risk mitigation strategies for both new and existing systems. It also provides a structured COTS
obsolescence analysis process to establish the long range-planning horizon needed to effectively support rapidly
evolving COTS products. Having developed a COTS Risk Mitigation Guide and associated courseware, the FAA is
equipping its personnel with the tools to support more informed program management decision-making as part of
the FAA‘s ongoing National Airspace System (NAS) modernization efforts.

4.2.1   A Case Study in the Replacement of Legacy Systems with an ERP System
R. Raynor, New Mexico State University
This paper presents two case studies that involve the process of replacing multiple legacy systems with a
comprehensive Enterprise Resource Planning (ERP) system. The paper will focus on the processes that each
company took in evaluating the systems and the data housed in these systems. The lessons learned and an
assessment of each company is presented at the conclusion of this paper.

4.2.2   Organizational Safety: A Systems Engineering Perspective
S. Jackson, The Boeing Company
Numerous studies have shown that organizational factors are contributors to major accidents, in particular,
catastrophes, such as Chernobyl and Challenger. Organizational safety, as distinguished from industrial and system
safety, can be viewed in a systems engineering context. Case histories of these and other disasters are reviewed with
a focus on the organizational aspects. First, the systems engineering concept of the development and support
systems, that is, the engineering and support organizations, as categories of enabling systems dictates that these
systems be considered concurrently with the operational system in establishing the total system requirements.
Secondly, the systems engineering processes of requirements development and synthesis enable the creation of an
organizational system which meets the total system requirements for safety. Finally, systems of verification are
addressed, both externally mandated systems as well as internally conducted audits.

4.2.3   Systems Engineering Approach for Modeling an Organizational Structure
G. Rushton, Visteon Corporation
A. Zakarian, T. Grigoryan, The University of Michigan – Dearborn
An organization is just another type of system. Why not use systems engineering techniques for modeling and
development of the organizational structure. Within every organization there are required tasks/functions that
interact with each other. Therefore, one may use system engineering techniques to define what the organization is
required to do and then develop an organizational structure using some basic design principals, e.g., integration
analysis technique to minimize coupling and maximize cohesion between various organizational tasks and functions.
In this paper, we illustrate how systems engineering design principles can be used for modeling and analysis of an
organization structure.

4.2.4 Human-agent Collaboration: Ontology and Framework for Designing Adaptive Human-
Agent Collaboration Architectures
A.M. Madni, W. Lin, C. Madni, Intelligent Systems Technology, Inc.
Agent-based systems are continuing to gain in popularity as agent design tools and agent communication languages
continue to mature. Today, agents have begun to play a variety of roles with respect to humans in agent-based
systems. As a result of these developments, the systems engineering, human factors, and cognitive sciences
communities have begun to focus on the shared role of human and software agents in problem-solving and decision
making with a view to optimally leveraging the human component. This paper presents accomplishments to date on
an ONR-sponsored research initiative concerned with the development of a cognitively-inspired, multi-perspective
conceptual framework for designing adaptive human-agent collaboration architectures. Such architectures are
capable of supporting dynamic function reassignment – the key to capitalizing on the human role in agent-based
systems.
4.2.5 Requirements Management by the Numbers: Applying Common Criteria Beyond the
INFOSEC Arena
K.J. Kepchar, J. Yeager-Key, Federal Aviation Administration
The security function has taken on a dramatically increased importance around the world with the events in New
York and Washington in September 2001. As we search for ways to address the altered realities of today‘s society,
the tendency is to create ―different‖ or ―unique‖ approaches to current problems. In the information security (or
INFOSEC) realm, Common Criteria (CC) (ISO 15408) documents an international approach to formulating
information security requirements. The CC structured methodology is discussed to show its potential application to
other Systems Engineering applications. This provides a means to develop consistent and coherent requirement sets.
The CC has also established a set of domain specific terms. This paper analyzes the CC terminology to show that
CC utilizes the same guiding principles and program milestones as other Systems Engineering disciplines. In the
process, we provide a mapping of the CC terminology to that commonly used in non-security Systems Engineering
domains.

5.2.4    FRAT – A Basic Framework for Systems Engineering
B.G. Morais, Synergistic Applications, Inc.
B.W. Mar, University of Washington
Systems engineering can be difficult to implement if the words and framework are not clearly understood by all
parties involved. INCOSE has adopted a definition of systems engineering; yet a debate continues over what
systems engineering is and how to do it. The authors have developed over a period of many years the FRAT
framework for describing the process used to implement systems engineering for any task, the name for which is
derived by the first letters of the series of words function, requirement, answer, and test. FRAT is based on the
hypothesis that four views of a system are needed to completely define any system. These views are what it does
(functions), how well the functions are performed (requirements), a physical or actual description of the system
(answers), and verification and validation of the system when completed (tests). The FRAT framework has been
validated by reviewing all the papers published at INCOSE proceedings. It is important to recognize that the system
of interest (a product) is produced by another system (a production system). Both of these systems can be described
by the four FRAT views when developing a shared vision of the development process as well as the product that is
developed.

5.2.5    Toward a Mathematical Theory of Systems Engineering Management
E. Honour, Honourcode Inc.
The practices of systems engineering have high value in the development of complex systems. Heuristic wisdom
contains several important relationships in systems engineering management, among quantities such as technical
―size‖ and complexity, systems engineering effort, quality, schedule, cost, and risk. This theoretical paper explores
quantitative relationships of these variables, portraying expected values. The paper further explores the benefits and
drawbacks of each relationship, the cohesive structure of the relationships, potential usefulness, and the type and
rigor of research necessary to prove each.

6.2.1    The Concepts of Systems Engineering as Practiced by the Wright Brothers
D. Buede, Stevens Institute of Technology
To the best of our knowledge the term ―systems engineering‖ was first used at AT&T‘s Bell Laboratories some time
in between 1920 and 1940. [Buede, 2000] The systems engineering profession made rapid progress for 20-30 years
after World War II, as did all of engineering. Nonetheless it is possible to see the concepts of systems engineering
being practiced prior to 1920.
The purpose of this paper is to explore one of those cases: the development and ultimate production of the airplane
by the Wright brothers.
6.2.2 Application of Computer Aided Systems Engineering Processes for Korea Next-Generation
High Speed Railway Train
I.S. Yoo, Y.W. Park, Ajou University
A high-speed rail system represents a typical example of large-scale multi-disciplinary systems, consisting of
subsystems such as train, electrical hardware, electronics, control, information, communication, civil technology etc.
The system design and acquisition data of the large-scale system must be the subject under strict configuration
control and management. Not only the requirements dictate the contracts with the suppliers but also become the
basis for the development process, project execution, system integration, and testing. The requirements database
provide the system design specification of all development activities. Using the RDD-100, a systems engineering
tool, the Korea next-generation high-speed rail program can establish requirements traceability and development
process management in performing the enabling train technology development projects. This paper presents results
from a computer-aided systems engineering application to the Korea next-generation high-speed railway project.
Especially, the focus of the study was on requirement management, PBS management, verification management and
project management.

6.2.3 Application of Computer-Aided Systems Engineering to Develop Automated Train Control
(ATC) System
J.Y. Lee, Y.W. Park, J.K. Ahn, Ajou University
W.D. Lee, J.K. Mok, Korea Railroad Research Institute
The project to develop an automatic train control (ATC) subsystem for the Automated Guided Transit (AGT) system
has high technical risk because the wireless train control technology is unprecedented in Korea. To succeed in
developing the ATC subsystem, SE team took a reverse engineering approach focused on building an engineering
model of the ATC subsystem. The scope of this paper is to develop a functional architecture of the ATC subsystem
using the CASysE tool of Vitech Corp., CORE. This paper shows how the generic SE process was tailored to
perform a reverse engineering approach in developing the wireless signal/control subsystem.

6.2.4    Design Centers – Transferring Experience from Astronautics to Aeronautics
S. Finkel, Institute of Astronautics, Technische Universität München
H. Metzger, M. Wahnfried, Fairchild-Dornier
M. Wilke, 3D Systems Engineering GmbH
The paper describes the introduction of the Customer Demand Center (CDC) at Fairchild Dornier Oberpfaffenhofen,
Germany. The CDC is a Concept Design Center-approach dedicated to the preparation and procession of customer
related aircraft modifications. After describing the development of the Concept Design Center-approach, the
principal idea and set-up of a Concept Design Center is presented. The paper highlights some of the differences
between the traditional application of Concept Design Centers and the specific purpose at Fairchild Dornier. Based
on those differences, the adaptation of the three building blocks within a CDC is presented. Finally lessons learned
are discussed.

6.2.5    Supporting Concept Development Using Quantitative Requirements Traceability
K. Sutinen, J. Malmqvist, Chalmers University of Technology
L. Almefelt, Volvo Cars Corp/Chalmers University of Technology
This paper presents a product modeling system that supports the system engineering process including qualitative
and quantitative requirements traceability, and demonstrates its application in a case study of a passenger car
cockpit. The system features a user interface that enables rapid trade studies. The paper further discusses how to
introduce simulation models in the product development process and what kind of simulation models can be used
during different development stages.


SESSION 3
2.3.1    The Impact of CMMI Maturity on Innovation
D.D. Walden, General Dynamics
This paper analyzes the impact that increased process maturity has on innovation. The Process Areas (PAs) and
Generic Practices (GPs) of the Capability Maturity Model Integration for Systems Engineering/Software
Engineering/Integrated Product and Product Development/Supplier Sourcing (CMMI-SE/SW/IPPD/SS) were each
individually assessed for their impact against six key characteristics associated with innovation.
The analyses suggest that, on balance, increasing an organization‘s process maturity in the areas covered by the
CMMI has a positive effect on the ability to innovate. Most PAs are either neutral to or have a positive influence on
innovation. A few PAs have a negative influence on innovation. The results of this analysis are consistent with a
similar analysis that used the EIA/IS-731 Systems Engineering Capability Model (SECM).

2.3.2    Lessons Learned for Systems Engineering Capability Assessments
R.B. Wray, Lockhead Martin Naval Electronics & Surveillance Systems
Lockheed Martin Naval Electronics & Surveillance Systems-Akron (NE&SS) has completed a continuous
assessment against the Systems Engineering Capability Model (SECM), EIA/IS-731. This assessment was
conducted in three stages: Quick Look, Incremental and Final. The Quick Look took several days to conduct. The
two year Incremental assessment established the processes to assure compliance with them in the organization. The
one week Final assessment validated the Level 3+ capability of the organization. Lessons learned at each
assessment stage are applicable to all engineering assessments when evaluated against any type of assessment
model. This paper summarizes our assessment process and discusses our lessons learned.
Setting out to conduct an assessment and improvement process can be confusing, especially for an organization at
lower levels of capability maturity. This paper is focused on planning future assessments by organizations with
limited prior assessment experience.

2.3.3    Measurement For Small Projects
D.F. Baxter, Distributive Software
After several years of leading successful systems projects, you are now tasked to assemble a small team to address a
design problem with a component of the major weapon system developed by your company and to report your
findings and recommendations in two months. This is a classic assignment for a small project ... limited duration,
small group, and specific task. While you might think this is an opportunity to fall under the radar of the corporate
reporting and measurement program, you‘re missing out if you don‘t take advantage of the unique opportunity to
experience and explore the possibilities available to you through working on a small project and the opportunities
for understanding measurement in ways that just aren‘t possible on larger programs. This paper explores the world
of measurement in small projects.

2.3.4    Experience with Extending CMMI for Safety Related Applications
M. Bofinger, N. Robinson, P. Lindsay, Software Verification Research Centre
A. Pitman, M. Spiers, M. Ashford, Defense Material Organization
+SAFE, a safety extension to the Capability Maturity Model - Integrated (CMMI) has been developed and trialed in
Australia, for use in assessing suppliers of safety-related systems. This paper describes the latest version of the
safety extension and also reports on the results of seven trials.

2.3.5    Systems Engineering Beyond Capability Models
W.W. Schoening, The Boeing Company
S.A. Sheard, Software Productivity Consortium
Capability models have been used for more than a decade to improve the ability of organizations to produce
software and systems. The models themselves have matured and currently capture much industry wisdom.
However, it is important to note that capability models do not and cannot include everything that an organization
needs to know to do systems engineering well. This paper attempts to show where systems engineering is broader
or deeper than is captured in capability models. Organizations that address these areas when implementing
capability model-based process improvement will make their systems engineering capability robust.
3.3.1    Tools for Requirements Discovery, Creation, and Elicitation
H.J. Heydt, Idaho National Engineering & Environmental Laboratory
Systems engineers can benefit by increasing their familiarity with multiple approaches and tools for helping human
beings express their desires and wants. This paper addresses this issue by presenting an overview of requirements
elicitation tools. Numerous tools are discussed with their applicability to hardware, software, or soft systems, or any
combination. It provides an overview of ―what‖ the tools can do but not ―how‖ to use the tool, the difficulty of
learning (rough order of magnitude learning time), the type of product the tools are of greatest value (benefit/cost)
for usage, and some advantages and disadvantages for each tool.

3.3.2    The Communications Requirements Evaluation & Assessment Prototype (CREAP)
J. Kasser, S. Cook, University of South Australia.
Today‘s requirements engineering processes do not have very effective checks to ensure that system requirements
are feasible. This paper describes extending the use of Requirements Engineering tools to assist the writers of
requirements to only accept requirements that are feasible using the FBRET approach (Cook et al. 2001). The
approach is illustrated by the description of the Communications Requirements Evaluation & Assessment Prototype
(CREAP). The CREAP is a prototype software package that is able to integrate military communications domain
expertise and requirements engineering practice in order to ensure the feasibility of equipment selected to meet the
requirements imposed on communications systems for a rapid force deployment in a design to inventory scenario.

3.3.3    Separating Product and Process Requirements
C.D. Abadi, T. Bahill, University of Arizona
When engineers design a system, they must design both the product and the process that will develop it.
Accordingly, systems engineers must separately write requirements for the product and the process. Stating these
requirements in separate documents should make it easier to get the requirements right and manage the requirements
when either the product or the process requirements change.

3.3.4    Requirements Variability Management
R. Jorgensen, Rockwell Collins, Inc.
When a project is "reused" from an initial project to subsequent reapplications of the original project, the question of
management of the intellectual property between projects becomes a significant maintenance issue. When
intellectual property is copied from one project space and pasted into the next project space, the intellectual property
(IP) between the two projects is no longer directly shared (it's rather salvaged), and the IP between the two projects
will tend to diverge. Enhancements or variations that are introduced into that IP will not be managed as a product
family, but rather be managed as project specific IP. Any global updates needed across all projects then become
difficult and costly to understand and apply. One change must be re-created in each project sharing the same product
definition. True sharing or reuse of IP between the projects becomes difficult.
To truly share IP between two or more projects, the IP material must come from the same source (not different
copies). Sharing IP between projects encourages a product family approach to engineering. The fear, though, of
shared IP is a perception that the project will no longer be able to preserve their project's unique definition or unique
needs. They are "different from the original project," thus they must maintain their own IP. And sharing other
project data with their unique customer bias is out of the question.

3.3.5    Specification Types, Principles, and Organization
D.A. Jones, Raytheon Company
Less than ten years ago there were around twenty types of standard military spec formats, but then came acquisition
reform, emphasis on performance specs, the superseding of MIL-STD-490 (Specification Practices), and database
vendor claims that specs are a waste of time. Last year at the INCOSE symposium a panel of experts decisively
stated that both databases and specs ware needed. If specs are still worthwhile, how should they be used and how
should they be organised? This paper reviews the types of former and present mil specs, and the reasons for the
changes. It shows how different types of specs apply to different parts of the development process. The paper then
goes further and examines the characteristics of good specs for any purpose and offers practical suggestions for
organising them, including a useable outline. (This paper does not deal with determining the requirements for
particular systems.)

4.3.1    Innovation and Technology Management
J.J. Simpson, The Boeing Company
A systematic approach to innovation and technology management is outlined in terms of a generic systems
engineering process. Two types of innovation, incremental and disruptive, are described and discussed. All aspects
of the product development and application environment must be correctly managed if an organization wishes to
consistently produce innovative technologies and products. System engineering concepts provide a structured
framework for the successful practice of innovation and technology development, deployment and management.

4.3.2    Can NASA‟s Integrated Product Teams become “Hot Groups”
R. Lovell, Northrop Grumman
Over the past few years, new Systems Engineering approaches to team management have been developed and
employed at NASA. The latest team approach is utilizing Integrated Product Teams (IPTs). An IPT is a team of
stakeholders created for a particular project to be the focal point of a specialized area or task. The team is
responsible for all activities within that specialized area that might include engineering design, project schedule or
budget.
This paper examines NASA‘s current IPT management and how it evolved and whether it can obtain the status of
"Hot Group". A Hot Group is a group of hand picked employees that is obsessively single-minded about a task. A
Hot Group is much more innovative and creative and performs at a higher intensity than an IPT.
What does it take for a NASA IPT to evolve into a Hot Group? Through examination of the obstacles confronting
IPTs (and high performance teams in general) and researching the expert's recommendations to overcome these
obstacles, a forward action plan can be adopted for creating these high performance innovative Hot Groups at
NASA.

4.3.3    Systems Engineering on the Dark Side of the Moon
D.H. Rhodes, CSG Systems
Systems engineering is an essential discipline for both defense and commercial businesses. To date, it has not been
possible for INCOSE to establish as strong a leadership presence in the commercial world as it has in the defense
world. This is clearly related to the fact that heritage membership of INCOSE came largely from a defense
orientation. It is also related to the author‘s premise that just as our observer point on earth limits our ability to see
the dark side of the moon, our point of observation in our professional domain limits the capacity to truly see the
‗other side‘. The author, having a seventeen year career in the defense industry, recently transitioned to a position in
commercial software product development. The observations and insights gained are the subject of this paper, and
advocate further comparative research and study of systems engineering as a means to enrich the overall theory and
practice.

4.3.4    NASA Technology Assessment Using Real-Options Valuation
R. Shishko, G. Fox, D.H. Ebbeler, Caltech/NASA Jet Propulsion Laboratory
We examine the use of real-options valuation in the context of prioritizing advanced technologies for NASA
funding. Further, we offer a set of computational procedures that quantifies the option value of each technology.
Other researchers have applied a real-options framework to private sector investments. In the case of NASA
investments in advanced technologies, the underlying products, which must be used to justify the investments, are
nearly pure public goods—in particular, space-related scientific results and discoveries to be shared world-wide. As
in the private sector, uncertainty plays a significant role in the motivation to use real options in NASA. Uncertainty
in NASA technology investments can be classified as development risk and programmatic risk (whether missions
using the technology will actually fly). The latter might be called the technology‘s ―market risk.‖
We carried out the approach on a number of planetary exploration technologies.               We illustrate the detailed
calculations using one of them  lightweight propellant tank technology.
4.3.5 A Question of Context – Why Manufacturing Cultures Don‟t Understand Systems
Engineering
R.C. Iliff, Independent Consultant
Effective management of Systems Engineering requires expertise not only within the discipline, but expertise in
explaining the discipline as well. This is particularly critical in the commercial sector, whose management is
overwhelmingly rooted in manufacturing process and culture. Manufacturing is an important and essential skill set,
but it is fundamentally different than the creative process of Systems Engineering. Bridging the communication gap
is essential to establishing even an opportunity to perform effective Systems Engineering. This paper equips the
reader with a clear understanding of the challenge, and the insight needed to become an informed and effective
Systems Engineering advocate.

5.3.4    Introducing Innovative Technology in a Contract-Driven Environment
K.N. Myers, J. Beckley, Lockheed Martin Corporation
This paper discusses our experiences in developing and introducing a web-centric Collaborative Engineering
Environment (CEE) into an organization whose lifeblood is performing on government contracts. We review events
in the team‘s 3-1/2 year history that led to an increasing awareness that the product development paradigm needed to
introduce innovation into the engineering organization is very different from that needed to perform successfully on
a contract. While many lessons from the world of contracting have been valuable, some of the disciplined processes
learned over the course of many years, such as up front specification and traditional forms of progress tracking, can
hinder innovation. Finally, we summarize the process adaptations we have made to address the conflicts.

5.3.5    Addressing the People Problem - ISO/IEC 15288 and the Human-System Life Cycle
S. Arnold, QinetiQ
J. Earthy, Lloyds Register
B. Sherwood-Jones, Process Contracting Ltd
This paper takes a system viewpoint on an organization‘s ―most valuable asset‖- its people. It provides an overview
of how key International Standards consider people - their roles, characteristics and behaviour - as they create,
interact with and form a part of complex systems. ISO/IEC 15288 provides direction at a strategic technical level on
the design of humans into a system product, on human influence on the required system services and on the effective
execution of system process by humans throughout the life cycle. Nevertheless, a human-centred approach requires
particular techniques that are beyond the scope of this system-level standard. A human-centred standard, designed
to complement ISO/IEC 15288, is therefore to be published in 2002 by ISO. The perspectives this standard takes,
and the rationale behind them, are described.

6.3.5 An Implementation of a Process Centered Collaborative Engineering Environment within
the Satellite Industry
R. Hartmann, U. Knirsch, Astrium GmbH
The paper presents an approach for a Collaborative Engineering Environment (CEE), facilitating the work of
distributed design teams. It includes an internet portal providing among others access to tools and to a project
database. A core element is the so-called process guidance, which is not only the basis for the derivation of the CEE
user requirements - including standard tools - but also the primary reference for tailoring of processes to specific
projects. The process guidance, which is currently being implemented at Astrium, is centered on databases with web
interfaces. Thanks to the non-proprietary software, it is easy to implement, to use and to update. Additionally, the
paper discusses lessons learned in the development process.


SESSION 4
1.4.1 Application of Systems Engineering Principles In The Creation of a New Master of Science
In Systems Engineering Degree Program
R. M. Harwell, SYSTEM Perspectives
A university accepts the challenge to create a new Master of Science curriculum needed by industry. Industry
declares a major shortfall in knowledgeable systems engineers and an inability to knowingly identify the capabilities
of those practitioners that are available. Add to that mixture, a professional base that is still debating how to define
itself and the boundaries that govern its practice. These are just some of the elements faced by Southern Polytechnic
State University and Lockheed Martin Aeronautics Company (both based in Marietta, Georgia) in developing a joint
Certificate Program and a Master of Science in Systems Engineering Degree Program. And these concerns do not
take into account other issues that every new curriculum faces.

1.4.2    Space System Concept Center, A CDC in an Educational Environment
M. M. Schiffner, Institute of Astronautics, Technical University at Munich
The Institute of Astronautics (LRT) at the Technische Universität München gathered during the last years
experience in the area of implementing Concurrent Design Center (CDC) in industry. It was both involved in the
implementation of the Satellite Design Office at Astrium in Friedrichshafen and in Ottobrunn and developed a
software tool to support the development process in the SDO. It was also involved in the implementation of a
design center at Fairchild Dornier Corporation (Finkel et. all, 2002).
To teach the students the idea of concurrent engineering besides system modeling and systems engineering, the
institute decided to provide a workshop for students during which they will learn these ideas. To achieve this goal, a
small CDC, called Space System Concept Center (S2C2), was established at the institute.
This paper describes the workshop and the experience gathered during the last workshops. It outlines the process
and team size required to perform a workshop in an educational environment.

1.4.3    Designing a New Airport Using a System Engineering Approach in a Classroom Exercise
M.W. Ludema, Delft University of Technology
In the year 1999 the main transportation issue in the Netherlands was the Question: ―If, why and how to facilitate
the need for a new national airport?‖ Amsterdam Airport Schiphol is growing towards its maximum capacity, due to
space and environmental restrictions. The Dutch government looked for alternatives to facilitate the demand for
further growth in air transportation, besides expanding the current airport. An alternative would be an airport on an
artificial island a few kilometers out of the coast of the Netherlands. As part of a course addressing the subjects
System Engineering and Integrated Logistic Support it became the problem field used as a case study. A problem
solving method was developed based on some basic inter-related concepts such as the necessary requirements for
capacity, availability and maintainability that should be addressed during the system engineering phases related to
the design and development of complex systems. Students stepwise designed a conceptual plan for an airport in sea
on an artificial island based on the problem solving method. In respect to the duration of the course the results were
more than satisfying.

1.4.4 Combined Research and Curriculum Development in Information-Centric Systems
Engineering
M. Austin, J. Baras, N. Kositsyna, Institute for Systems Research, University of Maryland
This paper describes a multidisciplinary program of research and curriculum development in Information-Centric
Systems Engineering currently underway at the Institute for Systems Research, University of Maryland, College
Park. This work is supported by a significant grant from the National Science Foundation and industrial funds from
US industry. After motivating the need for an information-centric approach to systems engineering education, this
paper describes the research methodology, pathway from research to curriculum development and teaching, and
architecture for web-based project deliverables.
1.4.5   A Systems Approach to Open-Inquiry Evaluation of Engineering Programmes
M. Harris, Systems Engineering and Evaluation Centre, University of South Australia,
The problem of how to evaluate engineering programmes is considered. Engineering organisations are under
pressure to improve the performance of their programmes, as failures in technological projects receive increasing
criticism, while the demand remains for increasingly complex projects to be undertaken. Many engineering
organisations have realised that the success of such programmes depends more on the management and related
programme issues and less on the engineering details. Evaluation of engineering programmes is demanded, yet
evaluation techniques from ‗soft‘ (non-engineering) domains with little understanding of engineering values and
culture may be quickly dismissed as ‗not sufficiently quantitative‘ and ‗without a systems (engineering) basis‘.
Programme evaluation in the human services field is well established, and the types of programme evaluations are
outlined. However, engineering programmes present a complex problem space for the evaluator, and require an
evaluation method capable of accounting for the values and culture of engineering stakeholders.
This paper outlines the systems approach for solving this problem of engineering programme evaluation, on the
assumption that the engineering programmes are sufficiently complex that specialist evaluators from ‗soft‘ domains
conduct the evaluation. An evaluation model is proposed, based upon the open inquiry evaluation method used in
human services programme evaluation, superimposed on the proven process used in the engineering discipline of
Test and Evaluation (T&E) to validate ‗hard‘ products of engineering programmes. With this model, it is suggested
that an evaluation technique is easily understood and appreciated by the critical reference group in technology-
intensive domains.

2.4.1   Integrating Beyond Capability Maturity Models
L. Ibrahim, Federal Aviation Administration
The Federal Aviation Administration (FAA) has been successfully pursuing integrated process improvement since
1997 using FAA‘s integrated Capability Maturity Model  (FAA-iCMM). FAA-iCMM v1.0 integrated three
CMMs: the software, systems engineering, and software acquisition models. Version 2.0 additionally integrates
several important improvement approaches including ISO 9001:2000, EIA/IS 731, Malcolm Baldrige National
Quality Award, CMMI, ISO/IEC TR 15504, ISO/IEC CD 15288, and ISO/IEC 12207. By integrating beyond
CMMs, the FAA-iCMM now contains guidance for improving business and technical processes ranging from
enterprise management to operation and disposal.
This paper describes FAA-iCMM v2.0, points out specific contributions from new sources, and illustrates some
insights gained from taking a broader perspective - when integrating beyond CMMs. The paper will be of interest to
any organization that has been using multiple standards and finds that approach too expensive, confusing, or
ineffective. It will also be of interest to organizations that do business with the FAA.

2.4.2   New Approach to Generic Attributes
C. Wells, I-metrics LLC
L. Ibrahim, Federal Aviation Administration
L. LaBruyere, TRW
Generic Attributes (GAs) are measures of process performance introduced by the systems engineering capability
model, EIA/IS 731. The systems model defines two GAs – Effectiveness and Value. While the concept of GAs is
generally accepted as valid, they have been used very little, due to difficulties in interpretation and appraisal.
Revised definitions and a new approach for appraising and using GAs have been developed for the Federal Aviation
Administration Integrated Capability Maturity Model v2.0 (FAA-iCMM). The improved approach to Generic
Attributes provides the needed clarity and measurement objectivity. Definitions of the iCMM GAs and their
relationship to process model concepts are described, along with a practical approach to appraising GAs.

2.4.3   Verification “Auditability” Can Be “Free”
J.H. Jones, Optants Documented Decision Support Company (ODDSCO)
When simple audit support standards are applied to developing project requirements verification documentation in
the current new product development environment, several benefits accrue. Data then made available from the
verification documentation supports technical test reviews and an effective project status metric, as well as
rigorously proving that verification is complete for specified requirements. Essential to verify requirements for
systems affecting human safety, audit support standards enabled rigor could be useful during planning and testing to
assure quality under ISO 9001 parameters claimed as met by many companies. When methods described in this
paper virtually automate the resulting auditability, it essentially becomes ―free.‖

2.4.4 Prediction of Information System Availability in Mission Critical and Business Critical
Applications
M. Hecht, SoHaR Incorporated
One of the most important attributes of on-line computer systems that are performing mission or business critical
applications is availability. System Engineers are often called upon to predict the reliability of such systems as part
of proposal preparation, architecture definition, design reviews, and operation. However, traditional modeling
techniques are incapable of handling integrated hardware and software systems with multiple states and redundancy.
This paper describes how Markov Modeling and Reliability Block Diagrams can be used together to model a large
on-line information system and develop the answers to strategic questions on the configuration and operation of high
availability computing systems. The analyses are performed using MEADEP, a reliability analysis tool capable of
hierarchical modeling and integrating Markov and block diagram techniques. In the example 3-tier architecture
e-commerce site described in this paper, it is shown that (a) the most frequently failing subsystem is not necessarily
the availability bottleneck, and (b) that restoration time is often a more important parameter than availability when
attempting to maximize system throughput.

2.4.5    Multistage System Integration
J.Z. Ben-Asher, M. Tahan, Technion
In large-scale system developments, systems engineers usually divide the integration process into stages in order to
facilitate the integration. Often this ―divide-and-conquer‖ method, or what we call ―multistage integration,‖ is the
only way of rendering the integration of a complex system feasible. This paper proposes to consider the
employment of the multistage integration methodology for large as well as for small systems. The main point is
that, regardless of size, and even when a single stage integration is feasible, it may be beneficial, both time-wise and
cost-wise, to pursue the multistage integration methodology. Two models are developed in order to analyze single
stage and multistage integrations: a purely statistical model, and a robust design based model. Both models are
shown to be viable and efficient as demonstrated by a simple representative example.

3.4.5 Were the Ancient Egyptians System Engineers? How the Building of Khufu‟s Great
Pyramid Satisfies Systems Engineering Axioms
B. Jacobs, University of Maryland
Systems engineering is a 20th century discipline. To judge whether an organization is on a world class systems
engineering level, we evaluate whether the organization's development processes and resulting product satisfy the 8
systems engineering axioms. Could we evaluate ancient organizations? The pyramids on the Giza Plateau are the
only remaining wonders of the ancient world. The sheer scale and precision of Kufu‘s great pyramid obviously
required a quality process. But were the ancient Egyptians systems engineers? This paper will outline how the
pyramids were built, and whether that process satisfied the systems engineering Axioms.

4.4.1    Systems Engineering Techniques in Support of Business Improvement
D. Kemp, J. Cole, UK MOD Warship Support Agency
This paper discussesd the use of Systems Engineering concepts and techniques in business improvement projects
being undertaken within the United Kingdom‘s Warship Support Agency, part of the and Defence Logistics
Organization.
System‘s Engineering techniques have been used to understand complex cultural, process and organisational issues
that have been limiting the performance of Warship Support, and help design and justify elements of the WSA‘s
successful Enterprise Integration and Shared Data Environment Project
The paper discusses the use of failure mode analysis to identify strategic drivers for change and system dynamics
modelling to link business improvement requirements to business benefits in business cases
4.4.2    From Systems Engineering to Service Engineering
M. Wieser, Technische Universitat Munchen
For many companies the optimisation potential in quality, process, and cost has become smaller and smaller in the
last years. Systems engineering has played an important role in that process. Now, an almost untouched and in
many companies often ignored domain has become the target of interest: services!
A systematic development of services is supposed to be a key factor in the future in order to diversify the own
company from the competitors. As customers more and more call for integrated solutions goods will not be sold in
future on their own anymore. They will have to be integrated in services. Those one, who will be able to offer new
services in a shorter period of time, that meet exactly the customers‘ needs, will have a main advantage in a global
market. To do so, methods and tools are required.
This paper describes the current situation of services, their role in the world economy and why it is so important not
to ignore the services any longer. It is shown how services can be characterised and it is discussed if current systems
engineering models can be transferred to the ―immaterial‖ world of services.

4.4.3 It‟s the People that Matter – Applying a Systems Engineering Approach to Process
Improvement
D. Kemp, UK MOD Warship Support Agency
E. Carver, BAE SYSTEMS
This paper describes approaches taken within the UK Warship Support Agency (WSA) and BAE SYSTEMS to
implement improved Systems Engineering processes throughout complex supply chains. The supply chains needed
to develop and support complex products, such as large aircraft or warships, require large teams to collaborate
across organisational and cultural boundaries.
To be successful the extended enterprise needs business processes which are honed to drive down life cycle costs
and which manage the key emergent capabilities such as safety, availability, flexibility, and reliability. Such
business processes are heavily dependant upon the people in the system and those people represent a complex web
of interdependent factors. Improving these processes, which are almost exclusively goal and knowledge based,
therefore requires significant understanding of how to integrate diverse teams and cultures.
This paper describes the techniques used within the WSA's Enterprise Integration and Shared Data Environment
Team and BAE SYSTEMS Advanced Technology Centre in understanding and improving complex goal and
knowledge based processes. It describes how the teams analyse improvement requirements, and how they
implement change in such a difficult, but critical, area.

4.4.4    E-Business Enterprise Infrastructure Capability Assessment
J. Ring, Innovation Management
A modern E-Business infrastructure must enable enterprise collaboration, both external and internal, throughout
unpredictably dynamic situations. Anyone selecting an e-business solution should assess the capability of its
infrastructure using applicable Measures of Effectiveness (MOE‘s). This paper expresses the MOE‘s in the context
of a conceptual model of an E-Business infrastructure. In addition, a checklist and a graphical notation for scoring
the capability levels of candidate solutions is provided. The purpose of a capability assessment is to help protect
enterprises from making commitments to solutions that lack key capabilities. The ten MOE‘s described in this paper
will provide a useful perspective to any systems engineering practitioner involved in creating an E-Business
solution.

4.4.5    Systems Engineering Starting in the Middle of a Program
J.R. Armstrong, Software Productivity Consortium
A process for application of systems engineering in the middle of a program has been described (Bahill and Briggs)
that is based on analysis of the work breakdown structure to determine the scope of the program. The process
provides general guidance and recommends specific reduced activities. This paper proposes a different start in the
process to more thoroughly review the situation and determine where key information is missing. It also provides
specifics and examples from several such applications of systems engineering and instances where it would have
been beneficial.
5.4.1 ProACT™: Process-Aware Zero Latency System for Distributed, Collaborative
Enterprises
A.M. Madni, C.C. Madni, Intelligent Systems Technology, Inc.
J, Salasin, Defense Advanced Research Projects Agency
Enterprise integration technologies such as XML, publish-subscribe, and message brokers have made it possible for
distributed enterprises to exchange information in a consistent, standardized way. However, these technologies do
not address how to effectively integrate humans within distributed, collaborative enterprises nor do they specifically
address how to minimize latencies in collaborative enterprises.
This paper presents ProACT, a process-aware collaborative system for integrating distributed collaborative
enterprises at the functional/task level. ProACT exploits knowledge and awareness of planning/process execution
status to eliminate/reduce information latencies in the distributed enterprise. ProACT employs a variety of process-
enabled, zero latency strategies such as optimal information caching, information prefetching, message prioritization
in a bandwidth-limited network, optimum database partitioning, and information replication to achieve the near-
instantaneous awareness goals of the enterprise.

5.4.2    Understanding Enterprise Behaviour: A Feasibility Study
B. Clegg, De Montfort University
M. Turner, Elipsis Ltd.
This paper describes work conducted as a joint collaboration between the Virtual Design Team (VDT) research
group at Stanford University (USA), the Systems Engineering Group (SEG) at De Montfort University (UK) and
Elipsis Ltd. We describe a new docking methodology in which we combine the use of two radically different types
of organizational simulation tool. The VDT simulation tool operates on a standalone computer, and employs
computational agents during simulated execution of a pre-defined process model (Kunz, 1998). The other software
tool, DREAMS, operates over a standard TCP/IP network, and employs human agents (real people) during a
simulated execution of a pre-defined process model (Clegg, 2000).
This docking study was conducted to develop a supporting tool-set for the concept of Enterprise Systemics, an
approach designed to address the increasing commercial volatility of enterprises. It has been funded by the PISCES
network project, which has drawn together a cross-disciplinary resource for comprehending the dynamics of the
extended enterprise.

5.4.3    ANSI/IEEE 1471 and Systems Engineering
M.W. Maier, The Aerospace Corporation
D. Emery, The MITRE Corporation
R. Hilliard, ConsentCache
ANSI/IEEE Standard 1471-2000 is the Recommended Practice for Architectural Description of Software Intensive
Systems, developed by the IEEE‘s Architecture Working Group (AWG) under the sponsorship of the Software
Engineering Standards Committee of IEEE. ANSI/IEEE 1471 is the first formal standard addressing the content and
organization of an architecture description document. As suggested by its title, ANSI/IEEE 1471 was conceived as a
software standard, but applies essentially equally to broader systems. This article reviews the concepts of
ANSI/IEEE 1471, the rationale for their selection, and their application to systems engineering.

5.4.4    Optimizing Distributed Software Architectures for Ground Based Weapon Systems
Y. LaCerte, Architecture Technology Corporation
Modern ground based weapon systems depend heavily upon electronics and software for correct and safe operations.
Many of these ground based weapon systems exhibit behaviors from very different domains: automobiles (e.g.
engines and transmissions), aircraft avionics systems (e.g. sophisticated sensors and advanced situational
awareness), and hard real-time industrial controls (e.g. weapon loading equipment).
This paper describes the fundamental approach to Crusader‘s software architecture and through specific examples,
demonstrates that the Crusader software architecture is highly adaptable, provides a firm technical foundation for
evolutionary growth, and is capable of supporting a family of ground based weapon systems.
5.4.5    Web-Based Process Documentation – Getting Over the “Paper Mentality” Hurdle
L.D. Pohlmann, Strategics Consulting
We are in an era of extensive emphasis on process, process maturity, and process improvement. Up until only a few
years also, most process documentation was paper based. Large volumes of detailed process descriptions occupied
our bookshelves – and normally remained unused for long periods of time. Many companies are now using their
intranets to host, manage, and distribute process documentation. Web-based approaches can make process
documentation both more accessible and more easily maintained. However, too often these process descriptions still
exhibit a ―paper mentality‖ in that they leave much of the real power of the internet largely untapped.
This paper discusses a number of process documentation concepts that are beyond this paper mentality hurdle. The
basic premise is that more advanced web-based approaches allow integration of and easy navigation among sets of
highly useful systems engineering process-related information – which in turn facilitates more effective and efficient
systems engineering.

6.4.1 A Case Study of the Near-Catastrophic Mir-Progress 234 Collision with Emphasis on the
Human Factors/Systems-Level Issues Surrounding this Mishap
D. Holland, Hollins University
This paper examines the June 1997 collision between the Progress 234 Supply Ship, and the Russian Mir Space
Station. The unmanned Progress 234 cargo supply ship was being flown manually on a practice approach to MIR,
when it collided with the Spektr module of the MIR station. The result was a punctured pressure hull, which
resulted in a decompression that nearly forced the crew to leave the station in an emergency mode. An analysis of
this collision reveals that a host of systems and human factors issues combined to promote the chances for such a
collision occurring. These systems-level attributes that increased the probability of a collision happening included:
ground-control pressure to perform a difficult task, a hectic pace of operations, and previous ―close calls‖ with a
variety of on-board systems failures that left the crew in a stressed state. Systems failures in the docking apparatus
itself contributed to making the attempted docking more difficult than would normally have been the case. The
general deterioration of economic conditions in Russia and the Ukraine also appears to have played a subtle
predisposing role for this type of practice approach to be attempted to begin with due to the mission
payment/incentive structure that required the crew to complete certain tasks, and the difficulties involved with
obtaining automatic docking devices from the Ukrainians for a reasonable price. Human factors issues that are
noted as contributing to this mishap include chronic fatigue from the loss of sleep for an extended period just prior
to the mishap, very poor display-control interfacing under the conditions that the docking was attempted, and
embedded psychological/financial pressures resulting from the previous docking failure with Progress 233. From a
human factors perspective, the MIR Commander‘s situation awareness was dramatically degraded during the
manual Progress 234 docking attempt due to inadequate visual display and control information, particularly with
regard to the position, range, and velocity information of the Progress 234 supply ship.

6.4.2    Anti-Terror Meta-Systems Engineering
K.D. Palmer
The major terrorist incident of 2001 in the USA is used as an example of the relationship between the system schema
and the meta-system schema to show why understanding Meta-systems Engineering beyond conventional Systems
Engineering is, now more than ever, a necessity.

6.4.3    Architecting An Engineering Documentation System
Steven A. Recker, The Boeing Company
This paper examines the architecture, development & implementation of a document information management
system developed for a systems engineering core group. The intent of the paper is to provide an overview of the
approach employed as well as provide insight into the requirements, drivers and the solution. This review also
illustrates how the development team made use of systems engineering methods, processes, practices and heuristics.
The Engineering Documentation System (EDS) is currently in use by the Systems Engineering department of the
Military Aircraft and Missiles division of the Boeing Company.
6.4.4    Applied Systems Analysis and Fuzzy Optimization to Water Quality Management Problems
L. Doukas, D. Kildea, J. Sappakitkamjorn, RMIT University
In this paper, we present a mathematical model to solve water quality management problems concerned with waste
load allocation by integrating systems analysis and fuzzy optimization, to overcome two major difficulties;
complexity and uncertainty. The main emphasis of this paper is to present a guideline in order to develop a fuzzy
optimization model dealing with multiple conflicting goals between the Pollution Control Department and
dischargers. Fundamentally, the goal of the Pollution Control Department is to maximize water quality whereas the
goal of dischargers is to minimize the cost of wastewater treatment. The fuzzy optimization model considered in
this research is one developed from multi-objective fuzzy mathematical programming which provides a
mathematical procedure for finding an optimal solution in decision-making problems with conflicting goals despite
lack of certainty. The model can be used as a decision-making tool for managing water quality of any specific water
body. It will not only suggest an optimal solution that leads to a compromise between the goals of the Pollution
Control Department and the dischargers, but also aid in determining how much waste can be discharged into the
water body without violating water quality standards.

6.4.5 Knowledge-Based Decision-Support System Design for Water Quality Assessment in
Distribution Networks
L. Doukas, H. Zhou, F. Roddick, RMIT University
The work on Knowledge-Based Decision Support System Design for Water Quality Assessment in Distribution
Networks is presented. This paper outlines and summarizes the essential activities such as, system definition,
functions allocation, requirements specification, the prototype systems design, decision-making processes, and the
knowledge database development. The integration of these activities led to the successful application of systems
engineering methodology. In addition, the effects of operating parameters such as, chlorine residuals, coliforms, pH
value, iron, manganese, turbidity, and colour were assessed to provide a better understanding of the link among the
chemical, physical, microbiological and aesthetic issues concerning drinking water supply security and safety.


SESSION 5

1.5.3    Epistemological Issues in Representation of Things and Requirements Specification
T.L.J. Ferris, University of South Australia
This paper discusses the problem of specification of the requirements for a project from the point of view of
requirements as a representation of the hypothetical or target product. The relationship between the description and
nature of things presented by epistemology is considered. Project requirements introduce the further problem of
knowing the essence of things through the representation provided by a description, and that before construction the
proposed product is hypothetical. This is presented and discussed.

1.5.4 Capability Maturity Model Integration (CMMI) Process Using Unified Modelling Language
(UML) for Flight Safety Process Modernization at a Major Range Test Facility Base
D. Donahe, R.M. Gonzales, C. Eubanks, E.Gonzales, Altech Services, Inc.
The Capability Maturity Model Integration (CMMI) initiative is a blend of systems engineering and software
procedures that promote process improvement in multi-discipline activities such as a support system modernization
at a Test Range. Using processes that promote consensus, the CMMI provides a cohesive framework for
development that accommodates multiple disciplines toward a modernization development effort. This paper
describes the on-going processes involved in applying systems modeling techniques within a CMMI process
environment to Flight Safety modernization at a Major Test Range. The system analysis and modeling is being done
using various Requirements Engineering methods and is being expressed in the Unified Modeling Language (UML).
This modeling effort is still at the conceptual or requirements elicitation phase. Some initial models will be
presented in this paper along with the process framework that is being applied.
1.5.5    Grand Systems Verification
J.O. Grady, JOG System Engineering, Inc.
The product system development process follows a three step sequence familiar to all system engineers: (1) define
the problem you are trying to solve, (2) design and manufacture a solution to that problem, and (3) that the solution
satisfies the requirements that drove it. Therefore, verification is a process for proving that the design of an entity
satisfies the requirements for that entity that were crafted prior to the design of the entity. The common mode of
verification is to compare an entity with some accepted standard of excellence. The entity can be a product or a
process system or some element or combination thereof. This paper explores the fusion of several concepts, some
new and some old, to build an enterprise environment within which all verification work can be accomplished
within the same three step context noted above. This includes product verification but also enterprise common
process verification and program process verification. The paper also challenges common responsibility
assignments for this work.

2.5.1    Assessing the Reliability of Socio-Technical Systems
A. Gregoriades, A. Sutcliffe, J.E. Shin, University of Manchester Institute of Science and Technology
This paper presents a Bayesian belief network (BBN) approach for socio technical system reliability assessment. A
human error model (BBN) quantifies error influences arising from user knowledge, ability and task environment,
combined with factors describing the complexity of user action and user interface quality. System reliability
evaluation is achieved by the System Reliability Analyser tool, which enables the iterative manipulation of the
human error model according to high-level scenarios.

2.5.2    Modeling and Simulation of Military System Architectures Using CORE
D. Cropley, University of South Australia
B. Kirby, Defence Science & Technology Organisation
This paper describes the analysis of a hypothetical command and control architecture for a proposed future land
force conducting maneuver operations under various conditions. The Systems Engineering tool CORE  has been
used to capture the user needs, and to develop a hierarchy of functions necessary to implement the proposed
command and control system. CORE also facilitates behavioral modeling of the functional architecture. This paper
shows how the tool can be used to analyze the performance of candidate physical architectures based on a common
functional architecture. The models that are formed serve as valuable aids for the user to evaluate novel operational
concepts, and for the system architects to determine productive areas for research into improving technological
support for command and control.

2.5.3    Overcoming the Obstacles to Systematic Design Reuse
R. Cole, Raytheon Systems Company
Although some level of design reuse is present in any engineering project, systematic design-for-reuse is less
commonplace. Despite the known benefits of reuse, the implementation of systematic reuse faces strong resistance
from management and designers. This paper considers inhibitors to implementing design reuse methodologies and
the steps required to successfully transition from a no-reuse culture to one of systematic reuse. Also considered are
some of the pitfalls that can doom a poorly planned reuse initiative.

2.5.4    Modeling Objectives on Cost: Insight for Practitioners and Academicians
F.J.Snyder, G.S. Parnell, W.K. Klimack, Department of Systems Engineering, USMA
Following a previous paper entitled Modeling Objectives on Cost in a Decision Maker‘s Value Structure, the authors
present the results of survey research conducted to determine whether or not the objective of minimizing cost should
be included as part of the fundamental objectives hierarchy when modeling a decision maker‘s value structure.
Conclusions are drawn for both practitioners and academicians. For practitioners, the discussion addresses which
technique those who know and use decision analysis prefer and why. Suggestions for using the two competing
techniques both separately and together are offered. For academicians, as a by-product of the surveys, survey results
illuminate how much and what kind of decision analysis training and education is received by systems engineers,
operations researchers, engineering managers, decision analysts, and others. Standard contingency table hypothesis
testing is used to validate certain points.
2.5.5    A System Theoretic Framework for V&V
W. Wymore, The University of Arizona
This paper begins with a discussion of the meaning of the words validation and verification in the systems
engineering context; what should be validated, what should be verified and when. The system theoretic framework
proposed for V&V is then described featuring the mathematical structure of the system test requirement. Finally,
the specific V&V tasks are discussed within the system theoretic framework.

3.5.1    A Prototype Tool for Improving the Wording of Requirements
J. Kasser, University of South Australia
The majority of work on a project is in response to a set of need statements or requirements, consequently errors in
requirements are a major cause of project cost and schedule overruns. This paper presents a simple concept based
on the FBRET approach (Cook et al. 2001) that can minimize the production of poorly articulated requirements, and
describes a prototype software tool that implements the concept.

3.5.2    Requirements Engineering with Goal-Driven Use Cases
R. Kaffenberger, Marconi Communications GmbH Germany
In the wake of UML, use cases have become a popular means to capture requirements. But those who do
requirements engineering and design at the system level are sceptic about their value, because use case descriptions
in their popular form are perceived as inadequate at this level. The points of critique are that there is no precise
definition of how a use case is to be described and no well defined method for the system level, tools exist only for
Object Oriented Methodology.
The concept of use cases but comes in many flavours. Especially the goal-driven use case concept aims at the
system level. It retains the benefits of use cases and at the same time is suited to a wide range of applications. It has
been designed to meet the following objectives:
   It can represent the requirements of all kinds of stakeholders.
   It can be refined or elaborated in well-defined steps.
   Existing information can be reused in a controlled way.
   The use cases can be managed along with other forms of requirements by a single tool.
The use case concept presented here not only supports object oriented methods but also equally well the standard
methods of design and development at the system level.

3.5.3    Product Line Requirements Management
M. Sutherland, Galactic Solutions Group, LLC
Product development organizations use design reuse strategies to build common subsystems for the complex
systems they develop and the many customers these systems are delivered to. Sub-systems are designed with an
Architecture that will allow for strategic reuse. A base design for a sub-system is designed, with some reasonable
modifications for specific Applications, to meet the requirements of the systems the subsystem will be incorporated
into.
This paper provides details on a strategy for Requirement Management across Product Lines that has successfully
been deployed within a large Product Development and Manufacturing organization.

3.5.4 A COTS-Aware Requirements Engineering Process: A Goal- and Agent-Oriented
Approach
K. Cooper, L. Chung, The University of Texas at Dallas
The goals of developing systems better, faster, and cheaper continue to drive software engineering practitioners and
researchers to investigate software engineering methodologies. In requirements engineering, the focus has been on
modeling the software engineering process and products for systems that are being built from scratch. As the size
and complexity of systems continues to grow the use of commercial off the shelf (COTS) components is being
viewed as a solution. Effective use of COTS components, however, requires a systematic approach that provides
both a set of concepts for modeling the subject matter and a set of guidelines for using such concepts. In particular,
the process needs to recognize and address the people oriented problems including the identification and resolution
of conflicting goals, bridging the gaps between stated requirements and 'approximately fitting' components while
still satisfying the customer. In this paper, we present a goal and agent oriented requirements engineering process
model that explicitly addresses the use of COTS components. More specifically, we present (part of) our model for a
COTS-Aware Requirements Engineering (CARE) process and illustrate it using a Digital Library System.

3.5.5    Integrated Cost / Schedule Risk Analysis
D.T. Hulett, Hulett & Associateds, LLC
B. Campbell, III, Northrop Grumman Corporation
Project costs often exceed their estimates because those estimates do not take into consideration the actual duration
of project activities. Cost risk will also be underestimated if it does not take into consideration schedule risk. This
paper presents a method of incorporating the uncertainty in activities‘ durations into the assessment of cost risk. In
this method, a Monte Carlo simulation of the schedule provides uncertainty in time. Incorporating the schedule risk
results into the cost risk model provides the linkage between schedule and cost risk. Then equivalence must be
established between the schedule and network concepts. Uncertainty in costs is then represented by uncertainty in
―independent costs‖ (costs that do not depend on time) and ―variable costs‖ (costs that depend on uncertain time and
cost per unit time or ―burn rate‖ and rate of labor compensation.) Simulation of the cost model combines the results
from the schedule risk analysis with the uncertainty in the cost assumptions. The results include the probability
distribution of total project costs and sensitivity of that distribution to the different inputs. Issues are discussed and
simplified examples are provided.

5.5.1    Architectural Abstractions
R.W. Jorgensen, I.W. Philpott, Rockwell Collins, Inc.
Architectural constructs provide the basis for effective system design. A well conceived architecture also provides a
foundation for a product definition that can be effectively adapted and reused across many different project
instantiations. But what makes up a complete system architecture? Is one block diagram illustrating the
arrangement of physical components "the architecture"? Or are there other dimensions of a system architecture that
are needed to complete the picture? This paper explores some concepts of the "complete system architecture."
Multi-dimensional views of architecting are examined to provide insight into what makes up a system architecture.

5.5.2    A Generic Methodology for Partitioning Product Architectures
B. Gaso, University of St. Gallen
C. Whitcomb, Massachusetts Institute of Technology
E. Igenbergs, A. Schultz, Technical University of Munich
Industrial companies can gain major competitive advantages if they possess the ability to bring products to market
faster while at the same time fulfilling customer desire for greater variety. An effective way for achieving this
advantage is to develop modular product architectures. This paper presents a repeatable methodology for designing
modular products that explicitly considers multiple product attributes (as metrics) and customer preferences.
Furthermore, it introduces external and internal metrics for architectures and combines them together with the
functional analysis approach in an exceedingly powerful tool called Element Modeling Language (EML).
Subsequently, it is shown how EML-structures are translated into a system of binary and non-binary matrices, called
the Matrix Modularization System (MMS), which can be handled mathematically. Two type-of clustering
algorithms, based on heuristic methods and function flows as clustering parameters, are introduced.

5.5.3    Enabling Systems Architecture Tradeoffs Using a Systems Integration Framework
B. Kalathil, D. Moore, C. Huggins, Lockheed Martin Management & Data Systems
Systems integration of large information enterprises involves integrating multiple heterogeneous database systems,
client-server platforms, web application technologies, and data warehousing solutions. Lockheed Martin
Management and Data Systems (M&DS) is involved in systems integration for state, local, and federal government
customers. We are currently developing a Systems Integration Framework (SIF) to assist in the architecture tradeoff
and selection for large information enterprises. A SIF is an environment, which will assist in the rapid prototyping
and testing of architectures, and specific instantiations of the architectures using commercial tools and platforms.
Over the last four years we have developed and tested architectures for client-server applications, web applications,
mobile computing applications, data warehouses, and data mining applications. Performance metrics have been
collected for web application servers and client-server applications. This paper will describe how we utilized the
SIF as a rapid prototyping and tradeoff environment to support systems engineering for state government customers
in domains such as law enforcement, criminal justice, and airline operations.

5.5.4 Design of the Concept of a New System, using ICDM - Integrated, Customer Driven,
Conceptual Design Method
M.P.Weiss, TECHNION
A. Hari, A. Zonnenshain, RAFAEL
ICDM, a practical and effective Integrated, Customer Driven, Conceptual Design Method has been introduced
recently, for the design of New Products. The method has been evaluated, tested and successfully implemented by
the Israeli high-tech industry. ICDM is claimed and shown here to be practical and highly effective also for the
design of New Complex Systems and complex high-tech products.

5.5.5    Systems Engineering with ICDM – A Case Study
J. Herscovitz, A. Hari, RAFAEL
This paper presents and demonstrates the design of a new system using the ICDM method. ICDM is an Integrated,
Customer Driven, Conceptual Design Method that encompasses the entire process of conceptual design, starting
from customer needs up to the selection of the best solution to that need. In an engineering design process, the most
critical phase is the initial conceptualization of the needed system or product, where about 75% of its life cycle cost
is committed (Blanchard 1978). Therefore, using efficient methodologies and practices during this phase is essential
to the whole effort success (Pahl 1984). ICDM, demonstrated in this paper, is a flexible 10 step method, tailorable
to multifaceted project needs and organization‘s requirements. The case study describes the stages of a system
definition and conceptual design of a Personal Identification of Friend or Foe system - PIFF. The problem behind
this need is defined as the difficulty of friend or foe identification in terror fighting or infantry arena. As a result, the
case study showed the ability of ICDM to enable quick and efficient team decisions upon the customer needs and
produced an optimal conceptual design that scored the best in terms of Customer Satisfaction Rating (CSR).
ICDM integrates proven techniques with original additions and can be adapted to the need of any industry.

6.5.4    CloudSat System Engineering: Techniques That Point to a Future Success
R.J. Boain, R.R. Basilio, T. Lam, Jet Propulsion Laboratory
Numerous books, articles, and technical papers have been written on system engineering's role in successful project
management. Components of the project development life cycle such as the definition and analysis of requirements,
the design process, configuration control, and risk management are frequently identified as key ingredients to the
successful outcome of any endeavor. This is true for deployment of a product or system and also for rollout of an
important service. Most of the literature focuses on what the major system engineering steps are without necessarily
addressing how to complete each step or how to successfully transition between them. Over the past three years the
CloudSat Project, a NASA Earth System Science Pathfinder mission to provide from space the first global survey of
cloud profiles and cloud physical properties, has implemented a successful project system engineering approach.
Techniques learned through heuristic reasoning of past project events and professional experience were applied
along with select methods recently touted to increase effectiveness without compromising efficiency. The use of an
online database as the single repository for officially identified requirements and completing a streamlined system-
level fault tree analysis and accompanying probabilistic risk assessment are some specific examples. The collective
set has allowed the CloudSat Project to be successful through formulation, approval, and at least early
implementation phase.

6.5.5 Restructuring the International Space Station Integrated Verification Process Using
Quality Function Deployment and Decision Analysis
B.R. Haskins, The Boeing Company
The International Space Station (ISS) integrated verification process was developed to provide a disciplined systems
engineering approach for the verification of the ISS specification requirements and to provide a traceable archive of
verification data needed to sustain ISS operations. This paper describes and illustrates a tailored version of how
Quality Function Deployment (QFD) and decision analysis techniques were used to restructure the ISS integrated
verification process. This tailored approach has been accomplished to facilitate the use of QFD and decision
analysis by systems engineers and can be used for other systems engineering processes for small or large-scale
integration programs.


SESSION 6

1.6.1    A Strategy for Designing Optimal Complex Systems Solutions
T. Shell, DarkLake Synectic
In this paper, a strategy for the design of optimal systems solutions is developed and assessed. The main areas of
investigation focus on the use of a formal approach, based on mathematical systems theory. A specific methodology
for the ‗decomposition‘ of system trade-offs, for use in identification of optimal system solutions, is explored in
detail. The practical difficulties of accurately identifying the best (optimal) system solution - particularly for
complex systems that are subject to imposed implementation constraints and are part of some extended hierarchical
construct - are also addressed. The paper concludes with recommendations with regard to a proposed strategy for
complex systems optimisation.

1.6.2    Formalizing a Structured Natural Language Requirements Specification Notation
K. Cooper, The University of Texas at Dallas
M. Ito, The University of British Columbia
Requirements specification notations are developed by organizations in order to meet their specific needs. For
example, the Threads-Capabilities notation, an in house notation at Raytheon Systems Canada, Ltd., has been
developed and used for specifying their complex, large scale, air traffic control systems. It is a semi-formal,
structured, natural language notation. In this work, we investigate how to make this semi-formal notation more
rigorous (i.e., formal) by developing and applying a new formalization process to it. By doing this, we can obtain
the advantages of formal methods (precise, unambiguous, automatic generation of test specifications, automated
typechecking, etc.) while retaining the style and readability of the original notation. We call the formalized notation
the Stimulus Response Requirements Specification (SRRS) notation. Our results have been successful for the
specific notation. The formalized notation has been demonstrated to reduce the time and improve the quality of the
requirements specifications. There is additional training time, however, needed to learn to use the notation and
tools.

1.6.3 A Systems Decision Modeling Approach to Electrical Generation Capacity Planning under
Imperfect Information
N. Leeprechanon, S. Moorthy, R. Brooks, M. Ellis, J. Sappakitkamjorn, RMIT University
This paper presents modeling techniques for planning electrical generation capacity where demand is uncertain. We
present traditional solutions to the capacity generation problem using a deterministic programming model based on
both simple and complex demand scenarios. We then present a systems approach, employing a unique two-stage
stochastic programming model that employs random parameters, which operate on deterministic model data, over
the range of all possible scenarios. This systems model enables the expected cost of uncertain demand information
to be calculated (ECII), and candidate stochastic solutions (VSS) to the capacity generation problem to be evaluated.

1.6.4    IT3 Information Technology Training Template
J.H. Beach, E.A. Balough, D. Nogic, M. Rains, S. Williams,
M. Kwinn, United States Military Academy
Due to an influx of new equipment into the military, the US Army and Project Manager (PM) Soldier have
identified the need for a template which can be used to identify what type of training is best utilized for specific
functions of the equipment used by soldiers. Specifically, this template needs to address new information and
technology as it relates to training platforms used both currently and in the future within the US Army. The USMA
Systems Capstone Team conducted research for the use of technology integration in the functions of training
through a functional decomposition of Army equipment training using the equipment acquisition life cycle as an
archetype. The USMA team will perform an analysis of where technology integration is better suited for training in
comparison to traditional Legacy Force methods, taking into account practicality, cost, and effectiveness using the
Systems Engineering Design Process. The use of a functional training template will allow Project Managers to start
planning for training of the new equipment that they are producing much earlier in the development process. This
reduction in training development lag time will decrease fielding time and increase the speed at which units are able
to integrate new equipment and types of training.

1.6.5    The Case for Flexibility in System Design
J.H. Saleh, K.S. Marais, D.E. Hastings, D.J. Newman, Massachusetts Institute of Technology
In this paper, we make the case for flexibility in system design. Flexibility is here defined as the ability of a system
to respond to changes in its initial objectives and requirements, occurring after the system has been fielded, in a
timely and cost-effective manner. We argue that flexibility reduces a design‘s exposure to uncertainty, and provides
a solution for mitigating market risk as well as risk associated with technology obsolescence. In order to illustrate
the dynamics of system requirements, we first review the requirement generation activity. In addition, we
demonstrate the criticality of technology obsolescence in the particular case of its impact on DoD related systems.

2.6.1    Model Driven Design with Matlab
E. Reitz, Lockheed Martin Corporation
The technical challenge of recognizing pertinent information on images of mail-pieces (such as indicia) has
encouraged the integration of multiple technologies into a complex modelling environment. The modelling
environment was developed to build and select the appropriate algorithms and subsystem component designs. A
C/C++ library has been developed for components of the system model that are selected for product application.
Prototyping has been extensively used in all of the environments. Example products developed with this approach
that have been delivered to customers include: a classifier algorithm for character recognition (USPS RIP2), a Pre-
sort-Label detection device (USPS APPS CFT), and a Non-Address-Attribute-System for recognition of indicia (UK
Royal Mail Address Interpretation). The results have exceeded expectations for schedule, performance, and
development costs.

2.6.2    Integrated SE and PDM Tool Support for Medium Sized Companies
R. Vonno, N. Boersema, ADSE Consultancy and Engineering
G. Smeets, MiQ
This paper describes how a fast and pragmatic design process for complex customer specific product development
can be supported with a single tool. A commercial Product Data Management (PDM) tool has been extended with
new functionality to provide support for the Systems Engineering (SE) needs of a medium sized company focused
on modular design, maximum reuse and early involvement of suppliers.

2.6.3    From function-driven Systems Engineering to object oriented Software Engineering
H.P. Hoffmann, I-Logix Inc.
This paper describes a model-based system and software development process that combines both function-driven
systems engineering and object oriented software engineering. The key part of this "Integrated Process" is the
"Bridge" between the two paradigms. Tools chosen to demonstrate the Integrated Process are the I-Logix tools
Statemate Magnum, for the function-driven systems engineering, and Rhapsody in C++ for UML-based software
engineering. Rules can be established on how an architectural design model built with Statemate will be translated
to a UML model for further software design and implementation with Rhapsody. The outlined mapping is not
limited to Rhapsody. Rather, the Statemate-to-UML Bridge is equally applicable to any UML-based software
design automation tool.
Initially conceived for the design and development of highly complex embedded systems in aerospace/defense
applications, the process is also applicable to other industrial applications.
2.6.4    An Initial Application of AP-233
W. Scott, S.C. Cook, D. Harris, University of South Australia
J. Smith, J. Johnson, BAE SYSTEMS
The System Engineering Design Methodologies (SEDM) project is concerned with potential avenues to exploit the
AP-233 system engineering data exchange standard. The project is a joint venture between the System Engineering
and Evaluation Centre of the University of South Australia and BAE SYSTEMS Australia. The work described in
this paper covers the design and implementation of an import interface from the AP-233 data model to DOORS.
The project showed that AP-233 is an effective medium for tool independent transfer of systems engineering
information.

2.6.5    Designing a Supply Chain Analysis Framework
M.W. Ludema, Delft University of Technology
After a customer has stated his need and a proper solution as been found, either by starting a design/engineering
process or deliver a product from a stock position, several supply chain processes have to be aligned to eventually
fulfill this customers need. Coordination between all supply chain organizations on strategic, tactical and operation
levels will lead to more effective supply chains. This supply chain coordination processes is complex and
practitioners need a systems thinking approach and broad understanding of topics that are related to the field of
supply chain management. To fulfill this task supply chain managers have to speak the same language and
understand the importance of possible problems. As part of the development of a professional course in supply
chain management a supply chain analysis tool has been developed and tested during four courses in a realistic case
situation. This supply chain analysis tool gives support in finding possible problems that should be tackled to
optimize the supply chain. This tool is based on the two phases of a structured problem solving process that
resembles the first phases of Systems Engineering approaches.

3.6.1    The Concept Exploration Phase and Successful Coaching of Systems Engineering
K. McGuire, Northrop Grumman Corporation
Applying systems engineering techniques to the Concept Exploration (CE) phases of projects is often met with
either indignation or incredulity. This much less structured, problem-ridden phase seems to many to defy the use of
process. This phase has traditionally been problematic and difficult to execute. IF the word "process" is too strong,
the idea of "systems thinking" that helps make some order out of chaos can be effectively used for coaching teams to
better performance.
This paper discusses some typical problems encountered in one organization and some successful use of systems
engineering approaches to improve the teams' performances in the Concept Exploration phase.

3.6.2    Managing Priorities: Deadline Pressure Control
T. Gilb, Result Planning Limited
This paper discusses the means of determining the priority order for implementing system changes. It is concerned
with the priority ranking of requirements.
Most papers and books describing trade-off analysis and multi-dimensional priority evaluation methods refer to the
use of allocating subjective, fixed numeric weightings to multiple system requirements (Daniels 2001, Keeney 1992,
Saaty 1990, Gilb1976). I would like to argue that it is time we threw off the shackles of subjective weightings and
gave practising system engineers something more useful and realistic as a tool for determining implementation
priority.
Priority determination should be:
• an information-based process, which makes full use of the available factual information and, is able to reuse this
information.
• a dynamic process, which uses feedback from the on-going implementation and, is open to instigating and catering
for changes in requirements and design ideas.
• a resource-focussed process, which considers Return on Investment (ROI) and takes into account resource
availability.
I would like in this paper to demonstrate how Planguage, a specification language and set of methods, which I have
developed over many years, has the capability to address all these above aspects.

3.6.3    Where Does Software Engineering Begin During Systems Engineering?
C.S. Lee, University of Maryland University College
Within systems engineering and systems development, it is typical to bring in the software engineers after the
system has been designed. Because their involvement usually begins with the Software Requirements Specifications
(SRS), software engineers must spend time in gaining an understanding of the overall system design and the product
they must build according to the SRS. In addition, software engineers may discover that the system design has not
accounted for some of the necessary components or subsystems, which would require that the system design be
changed. This paper enforces the need to bring in the software engineers as full members of the team as early as
possible. This does not mean that the software engineers would begin coding. Rather, the software engineers would
bring to the table their knowledge of modularization, configuration, binding, and execution. If applied correctly, this
involvement could make a significant difference in the costs of the product as well as the product‘s quality. By
including the software engineers early in the systems engineering process, there would be no question of where to
begin; they would have already started. In other words, when systems engineering begins, so should software
engineering.

3.6.4    Market Your Systems Engineering With Business Skills
T.J. Farwell, The Boeing Company
Several indirect methods for quantifying the economic value of Systems Engineering practices are described. All
are easily recognized as conventional valuations. Systems Engineers are more effective when marketing their core
skills in a business context. This paper supports those SEs who participate in the marketing of Systems Engineering
as Engineering.

3.6.5    Architecting Systems for Human Space Flight
G.F. Wocken, Boeing Space & Communications
C.H. Dagli, University of Missouri-Rolla
Human-system interactions have been largely overlooked in the traditional systems engineering process. Awareness
of human factors (HF) has increased in the past few years, but the involvement of HF specialists is still often too
little and too late. In systems involving long-duration human space flight, it is essential that the human component
be properly considered in the initial architectural definition phase, as well as throughout the system design process.
HF analysis must include not only the strengths and limitations of humans in general, but the variability between
individuals and within an individual over time, and the dynamics of group interactions

4.6.5 Towards an Improved Understanding of Humans as the Components that Implement
Systems Engineering
J. Axelsson, Volvo Car Corporation
Successful systems are developed from a good understanding of two things: the features and functions desired by the
customers, and the features and behaviour of the available components. A firm developing a complex technical
system is also a complex technical system in itself, so the same two things need to be understood about the
organisation. Much research on systems engineering focus on defining the features and functions of the
organisation, but less attention has been given to the prime component used for implementing it: the human being.
In this paper, an initial attempt is made at describing some of the issues involved, from a mainly philosophical
perspective.

5.6.1    Characterizing the Relationships Between Product Developers and Their Customers
W.W. Schoening, The Boeing Company
The systems engineering approach of a product developer is strongly influenced by the business relationships with
customers. The model presented in this paper characterizes those relationships and provides a framework for
understanding why some developments are successful while others have little chance of success. The model is then
used to examine more complex scenarios and transitions between scenarios to help understand some of the business
management challenges encountered in a heterogeneous mix of business scenarios. A notation for describing these
relationships is introduced to facilitate describing the individual scenarios.

5.6.2    Decision Making in Modular Product Platform Development
C. Ofer, Technical University of Munich
K.N. Otto, Product Genesis Inc.
C. Whitcomb, Massachusetts Institute of Technology
In order to achieve larger market share and address individual customer needs, firms are challenged to manage the
seemingly contradictory existence of internally low variety and a maximum external variety. One very powerful
approach is to use modular product architectures (PA). This permits one to establish product families based on
platforms.
Using platforms is a common strategy in diverse industries. For development of platform architectures, there are
almost infinite possible configurations. There is a need for a framework for evaluation and selection of possible
concepts. By evaluating design concepts one is faced with decision-making. To do this, one must make choices over
a distinct evaluation method and effective metrics. In this choice, the quality of information is the limiting and
determining factor, it is the differentiating characteristic among methods. To show this, diverse methods will be
presented and their characteristics and benefits will be discussed.

5.6.3 Lessons Learned Applying Tools and Methodologies to Develop C4ISR Architecture
Framework Compliant Architecture Products
A. Meilich, Lockheed Martin Mission Systems
D. Rice, Popkin Software
With the advent of the Clinger-Cohen Act of 1996 mandate to develop an enterprise information technology
architecture, there has been a more intensive focus by all federal government agencies, and more specifically the
DoD, on defining their instantiation of an Enterprise Architecture Framework. The Federal Enterprise Architecture
Framework (FEAF) was the first attempt to document the ground rules for various government agencies to develop
their own architectures to be compliant with the intent of Clinger-Cohen. The DoD has adopted the FEAF and
tailored it into the C4ISR Architecture Framework (AF). The C4ISR AF Products are robust in terms of capturing
the architecture, but are problematic when they need to be rigorously modeled on the path to producing a system that
is compliant with that architecture. The recommended documentation of the artifacts from this architecture is not
consistent across all the products from a system or software "methodology representation" standpoint. Since the
introduction of the C4ISR AF, agencies and contractors have grappled with capturing these products (which
represent different views of the architecture) in a common repository for verification of completeness, consistency
across views, and accuracy of information represented in these views. This is a non-trivial challenge for the U.S.
Army Digitization effort that integrates existing Army C4ISR systems and designs for interoperability. Lockheed
Martin Mission Systems is providing systems engineering and integration expertise in modernizing the U.S. Army
Battle Command Systems (11 ―stovepipe‖ systems) under the ongoing Systems of Systems Engineering and
Integration contract. The capture of this complex architecture is being facilitated through the use of a repository-
based tool - System Architect 2001 (SA 2001) by Popkin Software. This paper highlights the challenges, lessons
learned, and solutions which have come out of this effort to capture and model the C4ISR AF artifacts in a manner
that is useful to systems engineers and system architects. The proper utilization of these artifacts will enable the
users and customers of this systems to have a system design that meets their needs and can be successfully
integrated as the Army matures to a field-able, totally integrated battle command and control system of systems.

5.6.4    Application of the C4ISR Architecture Framework: What Does It Really Mean?
S.A. Hyer, J.F. Engler, Johns Hopkins University Applied Physics Laboratory
In 1997 the Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance
(C4ISR) Architecture Framework Version 2.0 was released as a guide for the U.S. Department of Defense (DoD) in
the development of system architectures. This Framework was developed under the auspices of the C4ISR Working
Group consisting of representatives from the Joint Staff, the military services, the Office of the Secretary of
Defense, and other Defense agencies. The main motivation for the C4ISR Framework has been to ensure that
architectures are interrelatable as well as comparable and integratable across Joint and multi-national organizational
boundaries. DoD, supported by recent government legislation, will pursue the development of more interoperable,
integrated systems to meet the challenges posed now and in the future. Developed to focus on information
technology, the C4ISR Framework is finding broad application in the DoD community. The C4ISR Framework
serves as a consistent guideline on how architectures should be described by calling out a number of views serving
operational, system, and technical interests. The need for consistency and guidance is clear. What is not clear
however, is how this guidance will influence engineering activities being conducted on DoD programs. Application
of the C4ISR Framework is very much in the pioneering stage. Experience is needed to set examples and teach
lessons as with anything new. This paper offers some experience by developing an operational architecture view in
an application to Air Defense.

5.6.5    Advancing Systems Engineering for Systems-Of-Systems Challenges
P. Chen, J. Clothier, DSTO
Engineering activities in future organisation development including various information-based systems vary but all
result in evolutions of an organisation and its capabilities and systems. These evolutions occur in a context of
Systems-of-Systems (SoS). This paper presents an understanding of SoS challenges to Systems Engineering (SE)
and proposes a new approach to SE process management in order to cope with high complexity of SoS evolutions
and improve architecture practice

6.6.1    A Systems Engineering Approach to Filling India‟s Telecommunications Gap
S.G. Barkley, University of Maryland University College
The need of developing nations to increase information flow provides a commercial opportunity to extend modern
telecommunications technologies and service offerings into new markets. This high-level case study identifies the
need for new systems in India to assist in filling telecommunications service gaps, with a strong emphasis on
systems for rural populations. The United States is used as a basis of comparison. Existing systems and
deficiencies, stakeholders, and evaluation criteria for potential alternatives are discussed. Several alternatives for
local service delivery and national backbone networks are presented, drawn from current and planned offerings in
India and worldwide. Application of the criteria to the candidate solutions indicates that no single one is preferable,
but a combination of several would provide a suitable solution.

6.6.2    System Integration in the Power Utility Industry: Lessons Learned
A. Rothweiler, University of Maryland University College
The shift from regional monopolies to retail marketers has caused significant structural changes within the Power
Utility Industry, such as the disintegration of the transmission sectors, the transformation from engineering
management to business leadership, the reorganization of distribution operations, and the ongoing acquisitions,
mergers and buy-outs. For the past 6 years, utility companies have been seeking new economic solutions that will
allow them to survive within the competitive market. One area that has gained popularity is substation automation
(SA). SA entails the integration and data management of intelligent electronic devices (IEDs) within the substation.
This paper attempts to use systems engineering (SE) principles for the design and development of substation data
concentration (SDC) systems. A collaborated effort between the designer, the utility experts, the programmers and
the technical manager transform the SDC operational need into system performance parameters; integrate functional
and program interfaces in a manner that optimizes the total system; and ensures reliability, maintainability and
survivability to meet cost and scheduling objectives.

6.6.3    Safety Systems Intervention Plan for Yellowstone National Park
C. Plowman, R.S. Alessi, Idaho National Engineering & Environmental Laboratory
Managers of Yellowstone National Park are interested in improving both the safety performance and the systems
design and project management capability of the Park‘s personnel. The objective of our research was to address this
need by constructing a safety enhanced Capability Maturity Model that will simultaneously assess systems design
and safety. This approach advances the integration safety into business decisions and identification of ‗leading‘
indicators of safety performance. We modified the EIA 731 Capability Maturity Model to include a focus on safety
management systems. This model was used to assess the safety culture at Yellowstone National Park (YNP) in the
spring of 2001. Using the standard assessment approach, results from the safety-augmented survey were used to
target specific areas of investigation. Results from the interviews and focus groups led to a collection of information
and potential improvement opportunities that were subsequently used to develop a five-year safety system
intervention plan for the Park. This paper deals with the intervention plan development that occurred after the
standard CMM assessment activities were completed.

6.6.4 Introducing Systems Engineering in the Fast Track: Wireless Data Communications Goes
One Step Beyond
J. Ransyn, M. Verhoeven, R. Vonno, ADSE Consultancy and Engineering B.V.
This paper contains the way Systems Engineering principles have been implemented in a very specific environment,
a software engineering firm that creates applications for wireless data communication. This environment is
challenging for a number of reasons, but mostly because there doesn‘t seem to be time for structuring the
development process and introducing formal methods. On the other hand, not introducing a formal systems
engineering method would be a dead end street sooner or later, given the fact that the company is making the
transition from being project and consultancy oriented, towards becoming a producing firm with repeatable
processes and predictable quality.
The challenge was answered by introducing a dedicated task force, called the RADS team (Requirements Analysis
Design Support). This team introduced the Systems Engineering way of working in a rather unorthodox way, that
suited the way the company worked without interrupting or delaying its core processes. It proved to be highly
effective, and can be used as an example for other organizations.

6.6.5    Performing Trade Studies in the CERCLA Environment
K. Jamison, M. Borland, P. Rice, Applied Engineering & Environmental Lab
During almost any project, situations will arise that require project management and/or engineering personnel to
make choices regarding project direction or product development. Often these choices are simply a part of the
normal engineering development cycle (e.g., refinement or optimization of the product design). Frequently, on
Comprehensive Environmental Response, Compensation, and Liability Act (CERCLA) and other similar projects,
trade studies are initiated to address concerns or issues raised by stakeholders (e.g., EPA, local and state
governments, local tribes, public). Where CERCLA projects, by definition, deal with releases or threatened releases
of hazardous substances that may endanger public health or the environment, these trade studies must balance
safety, risk and health issues, as well as cost and engineering viability. How these trade studies are carried out and
documented/presented to the stakeholders involved can often be the difference between continued project progress
and a ―stalemate‖ leaving the project in limbo.
This document describes a basic trade study process, which has proved successful in addressing stakeholder
concerns while at the same time balancing the desires of the various parties involved.
Plenary
Systems Engineering and Theme Park Development
K.D. Salter, Walt Disney Imagineering
The development of theme parks requires systems thinking and can benefit from systems engineering methods. This
paper identifies some myths and truths about traditional systems engineering methods and their applicability to
theme park development. This paper is an editorial, based on the experiences of the author in applying systems
engineering for a developer of large theme parks. The paper discusses methods that are effective and those that are
not. The paper then describes problems with traditional systems engineering and suggests some improvements
using concepts from complexity science. Lastly, a systems engineering process model is presented, which is
currently in use.

RESERVE/POSTER PAPERS

9.1.1   Analysis of Human factors in Specific Aspects of System Design
P.K Balakrishnan
An important aspect of system design is the human factor. Human factor must be taken into consideration at every
stage of system design. This paper discusses human aspects in specific areas of system development life cycle. The
importance, relevance and significance of human aspects of each stage are discussed herein. The covered areas are
system requirements, communication, environment, interface design and layout, ergonomics, training content and
procedures and decommissioning.

9.1.2   Structuring a Systems Engineering Program at UALR
Y. Chan, K. Iqbal, H. Al-Rizzo, X. Liu, University of Arkansas at Little Rock (UALR)
By all measures, we have founded a successful Systems Engineering program in response to industrial and state
requirements. Being a new program, however, the faculty and administration have both learned from the experience
over the three years since the program was instituted. Given the dearth of systems engineering programs, a major
challenge is to recruit formally trained systems engineering graduates. Another is to reach a consensus on the goals
and content of our program. This paper reports this learning process.
The University of Arkansas at Little Rock (UALR) is a regional university serving primarily the people of Arkansas.
One half of the population in the state of Arkansas lives within 100 miles of Little Rock. The Little Rock
metropolitan has a population of over 500,000. UALR is a member of the University of Arkansas system, which
consists of eight campuses. UALR has approximately 11,500 undergraduate students and 1,500 graduate students.
UALR offers bachelor‘s degrees in Engineering, Science, Education, Arts, and Humanities. It offers master‘s
degrees in several areas, and doctoral degrees in Applied Science and Education. UALR is one of the fastest
growing urban universities in the country. As a Carnegie doctoral intensive institution, it is one of several
metropolitan universities in the country serving the industrial, commercial, and educational needs of the client
population, including minority students (currently UALR‘s African American population is about 25% of the
student body). The mission of the University is to provide the necessary support and access to a quality education
for all citizens of Arkansas regardless of background.

9.1.3   NASA EOS Aura Project Continuous Risk Management (CRM) Process
R. Evans, QSS Group, Inc.
              igure 1. CRM Process




The CRM Process Training Program was developed for the National Aeronautics and Space Administration
(NASA) in conjunction with Carnegie Mellon University in the fall of 1998. It has been taught throughout the
NASA organization at all of the NASA Centers. The basic functional steps followed by all NASA‘s projects for
CRM as depicted in the paradigm are the Identification of risk issues and concerns; an Analysis and an evaluation of
impact/severity, probability, and time frame; Planning, deciding what, if anything, should be done about the risk;
Tracking to monitor risk metrics and verify/validate mitigation actions; and Controlling to decide to replan
mitigation or close risk.
Communications and documentation are utilized throughout all of these functional steps of the process including the
project team, management, and customer and is, therefore, at the center of the paradigm.

9.1.4   Two Views of Systems Engineering: Project-Centric and System Conception
T.L.J. Ferris, University of South Australia, Mawson Lakes
This paper discusses two different approaches to understanding the nature and purpose of Systems Engineering. The
two approaches to thinking about Systems Engineering involve, on one side, a project level view in which Systems
Engineering is seen as a set of processes by which major, complex projects may be addressed and completed on time
and on budget and on performance. The contrasting view centres about the conceptual issues of determination of
how we can be confident that our projects are appropriate and useful. This paper exposes the two views of Systems
Engineering and discusses the relationship between them. The two views are different, and have different emphases,
and so are instructive in different ways, but are different views of the same thing. The two views are not opposed
and do not, fundamentally, conflict.

9.1.5 Risk Management : A Practical Toolkit for Identifying, Analyzing and Coping with Project
Risks
T. Gilb, Result Planning Limited
Risk management must be fully integrated into all the development and maintenance processes for systems. It
involves more than applying risk assessment methods to identify and evaluate system risks. To explain this broad
approach to risk management, this paper discusses the way in which ‗Planguage‘ (a planning language) and, the
‗Competitive Engineering (CE)‘ methods contribute to handling risks.

9.1.6   Ten Powerful Principles for Quality in Systems Engineering and Software
T. Gilb, Result Planning Limited
Software projects know they have a problem. Solutions abound. But which solutions work? What are the most
fundamental underlying principles we can observe in successful projects? This paper presents ten powerful
principles, many of which are not widely taught or appreciated. They are based on ideas of quantification,
measurement and feedback. Our maturity level with respect to 'numbers' is known to be poor. Hopefully, as we
move to higher maturity levels, we will also begin to appreciate numeric expression of idea and the power of
measurement.
9.1.6    Towards the Engineering of Requirements
T. Gilb, Result Planning Limited
Software engineers must articulate requirements in a clear testable manner. This paper outlines a framework for
specifying requirements and discusses some key concepts for requirement specification.

9.1.7 Collaboration: Government Process Improvement and Methodologies in a Collaborative
Environment
F. Grubbs, T. Holzer, National Imagery and Mapping Agency (NIMA)
This paper addresses how one government organization is making strides in its quest for CMM Level 2 through the
collaborative strategies of its managers, workforce, contractors, and private industry and other government
organizations. The last two years' efforts have yielded an environment that has helped ease the painful climb up the
CMM ladder and produced some notable results. The accounts given are both descriptive and prescriptive.
Methodologies for proper coordination, strategies for accomplishing buy-in and accountability, and measures to
achieve integration of processes are just some of the discussion points of this paper.

9.1.8    Decision Metrics Matrix Process
J.C. Helm, University of Houston-Clear Lake
This paper presents a decision metric matrix process to evaluate the stakeholders needs related to their goal for
improvement of a process, product or resources. The decision metric matrix gives the system engineer a method to
name the components of the decision matrix and provides a process to extract, quantify and evaluate the metrics of
the stakeholders' goals. Column one and subsequent rows of the decision matrix contain the decision parameters
and the interior rows and columns contain the associated action statements and values. The stakeholder uses the
action statements and action values as indicators to make a weighted decision concerning the goal. The decision
metrics matrix uses concepts from the Goal-Driven Measurement paradigm (Basili).

9.1.9 The Communications Requirements Evaluation & Assessment Prototype (CREAP) Project:
A Case Study of a System Engineering Educational Project
J. Kasser, S.C. Cook, A. Pilgrim, Y. Gamaliel, D.B.T. That, Systems Engineering and Evaluation Centre, University
of South Australia
This paper contains a case study describing the development of a software tool to prove a concept for use in design
to inventory scenarios. The tool was developed by Master‘s students at the University of South Australia. The case
study, designed as a reference for similar activities in other academic institutions, contains a list of lessons learned
on the project. All the lessons learned have to do with the non-technical aspects of the project. Even though the
project was small, many of the attributes of large projects were seen.

9.2.0    Synergizing Workplace Research and Postgraduate Degrees
J. Kasser, Systems Engineering and Evaluation Centre, University of South Australia
Many mature age students are taking courses in postgraduate degree programs to acquire a degree needed for
promotion. In these circumstances, the students may already have as much, if not more, knowledge about the subject
as the instructor. A number of these degree candidates are also working in an environment whereby their work is of
a research nature. Workplace research, however, is only one aspect of ongoing research. Important research is also
being performed by working groups (WG) in professional organizations such as the INCOSE. In many instances
such research can be incorporated into postgraduate degrees at the Masters and Doctoral levels. This paper discusses
types of research that are appropriate, the benefits of applying workplace research for the employee and other
stakeholders, and concludes with a step by step process for synergizing workplace research into a postgraduate
degree

9.2.1    Additional Systems Engineering Roles
K.R. Kyler, W.H. McCumber, University of Maryland
C.D. Sloan, EagleRidge Technologies
To date, the systems engineering roles described focus on those within an engineering firm and ignore the need for a
systems engineer who advises, and acts in behalf of, the client separate from the organization building the system.
The software systems engineering community has failed the customers by not providing a process for bridging the
gulf between the contractor and the customer in an objective manner. The additional systems engineering roles
described, that of the Contracting Officer‘s Technical Representative and the Client‘s System Engineer, bridge that
gulf and improve the integrity of the process. The focus of this paper is on Department of Defense contracts but the
principle is true for major software systems efforts.

9.2.2    A Sublayer Generation of System Architecture Using the Model Based Systems Engineering
Tool
J.Y. Lee, Y.W. Park, Ajou University
This paper describes a set of practical methods and templates developed to practice the Model Based Systems
Engineering (MBSE), a computer-aided systems engineering, in an efficient manner. It also shows the steps to build
more credible data model. The scope of the work includes the systems engineering engine process which represents
the requirements analysis, functional analysis/allocation, and synthesis. This work focuses on the functional
architecture generation. The SE engine process is tailored to accommodate the specific needs encountered from
practical applications of the MBSE. The outcome of the work includes the templates for requirement and scenario
description methods essential to construct MBSE database. To ensure the model credibility, the study presents the
use of belief criteria.

9.2.3    Open Source Software Assessment for the Naval Oceanographic Office
J.A. Lever, Naval Oceanograpic Office
C. Maresca, R. Munro, Olliance Counsulting Group
This paper describes an ongoing analysis of the utility of Open Source software at the Naval Oceanographic Office
(NAVOCEANO). NAVOCEANO possesses leading-edge technical and science skills for the application of
Information Technology (IT) in processing oceanographic data over multiple scientific domains. NAVOCEANO
produces numerous information products supporting U.S. Navy operations, the Department of Defense, and the
other military branches, as well as various national and international customers. These capabilities are critical to
developing and maintaining the highest quality oceanographic products for the Navy fleet. In addition,
NAVOCEANO maintains an extensive library of state-of-the-art scientific applications software.
The Open Source Software Institute (OSSI) is a non-profit organization that promotes development and
implementation of Open Source software solutions within government and academic institutions.
In 2001 NAVOCEANO requested OSSI assess the use of Open Source software within NAVOCEANO, and OSSI
contracted with Olliance Consulting Group to assist with this effort. The objectives, scope, approach, and some
preliminary results of this evolving Open Source assessment are presented.

9.2.4    A Tale of Two Systems – A Comparative Study of Systems Engineering
P.M. Lister, Siemens Transportation Systems Ltd
This paper is a comparative study of two system development projects as a contribution to the demand for evidence
of the benefits of Systems Engineering.
The treatment is qualitative, but the similarities of the two systems concerned allow useful conclusions to be drawn.
The projects were carried out by the same enterprise, used common subcontractors, were developed on similar
technical infrastructure and were developed for the same end user. Both projects claimed to be applying Systems
Engineering, however the very different outcomes conform to the old adage that says, ‗it ain‘t what you do, it‘s the
way that you do it – that‘s what gets results‘,
Both projects experienced the usual trials and tribulations that accompany engineering developments, however one
system was accepted and delivered whilst the other ran significantly over-budget and over time. This system was
never delivered. The seeds of the problems that afflicted the unsuccessful project could be observed very early in
the programme, and had they been addressed the outcome could have been different. The paper helps to support the
hypothesis that intelligent use of SE can ensure project success.
Projects may claim to use SE without actually delivering a good result. The paper addresses this problem by
indicating some common sense observations that can identify weak or ineffectual SE practices.
Not surprisingly the identity of the projects is not revealed, and in some cases details have been deliberately altered
to ensure anonymity.

9.2.5 Aging Transport Systems Rulemaking Advisory Committee (ATSRAC): Aviation Standard
Wiring Practices Manual – Task 7
R. Lloyd, Boeing Australia
ATSRAC was created to resolve certain aircraft wiring issues by problem solving. This entails the development of
standards and therefore ATSRAC encompasses the theme of INCOSE 2002 – Problem Solving Through Structured
Thinking with concentration on the Speciality Track of Development and Use of Standards.
Task Group 7 of ATSRAC (of which the author is a committee member) adopted the Systems Engineering approach
to solve the problem of introducing the requirement (through an industry standard) of a Standard Wiring Practices
Manual.
Soon after TWA 800 accident it was noted by the FAA that ‗aging‘ could not be limited to structural systems and it
was now necessary to include non-structural systems in the FAA program covering Aging Aircraft.
Standard Wiring Practices Manuals were developed, implemented and utilised by Aircraft Manufacturers in the
development of their product line.
Originally driven by (and in the most part, echoing) Military Standards, the layout and content varies considerably
between manufacturers.
Task Group 7 was established under the auspices of ATSRAC to develop a Standard for aircraft wiring practices.
ATSRAC Task Group 7 is an example of ‗Development and Use of Standards‘.
 This paper provides a solution to inconsistencies with aircraft wiring not only between manufactures but also
different aircraft models from the same manufacturer. This will be accomplished by developing standards, which are
intended to be mandated throughout the aviation industry.

9.2.6 Integrated Product Development Planning within Distributed Organizations using
ProcessEdge™
A.M. Madni, C.C. Madni, Intelligent Systems Technology, Inc.
Jeff Plaut, D. Zarnow, Raytheon Electronic Systems
After a series of acquisitions, major aerospace companies are still consolidating their infrastructures and processes.
One of the more challenging issues is consolidating the systems engineering infrastructure. This is because each
acquired company has its own systems engineering processes and best practices despite the fact that all claim to
have embraced integrated product process development (IPPD) and systems engineering standards. Compounding
the problem is the fact that each organization has a legacy of tools, applications, and databases that produce
sufficiently different outputs that it becomes near impossible to reconcile them. This paper presents a ―view from the
trenches‖ as a major aerospace company took on this challenge. The circumstances, approach, and findings from
this work should resonate with practitioners in the field while providing them with insights for future undertakings.

9.2.7    Value of Systems Engineering – SECOE Research Project Progress Report
B. Mar, University of Washington
E. Honour, Honourcode, Inc.
This paper is a progress report on the results of a SECOE research project to collect and analyze data that describes
project cost, schedule, and quality with systems engineering cost and quality. The original hypotheses to be tested
were that (a) at low levels, increasing systems engineering effort results in better project quality, and (b) there is an
optimum above which further increases are detrimental. The collection of data is much more difficult than
anticipated. The preliminary results are presented in an attempt to encourage more individuals to submit data.
Analysis of the preliminary data (25 project submissions) supports the hypotheses. The data suggests that
dimensionless ratios of actual to planned cost and actual to planned schedule correlate with an independent variable
defined as an index of systems engineering effort (product of systems engineering cost and systems engineering
quality divided by total project cost).
9.2.8    The Role of Systems Integration in Knowledge Management and the Knowledge Economy
J.N. Martin, The Aerospace Corporation
This paper discusses the role of systems integration in knowledge management and the knowledge economy. It
describes the social, human, organizational, and technological factors involved with the systems engineering and
integration of the systems that must support knowledge management.

9.2.9    On the Transition of a Legacy System to a New System (Upgraded or Otherwise)
J.N. Martin, The Aerospace Corporation
There are a number of approaches for dealing with the transition from a legacy system to its replacement (whether a
new start or an upgrade). These include systems engineering with precedented systems, unprecedented systems,
reused systems, reengineered systems, and systems engineering with COTS products. This paper will discuss the
special needs associated with integration due to each of these approaches and their combinations. It will also discuss
the considerations that would be involved in determining whether it would be more appropriate to use one of these
approaches to the exclusion of the others and the specific role of systems integration in this. Furthermore, an
approach is suggested for the planning effort that will, when completed, lead to the engineering of a system
involving some mix of these components.

9.3.0 Path Dependence and Network Effects and How they Affect the Engineering and
Integration of Systems
J.N. Martin, The Aerospace Corporation
Path dependence is discussed in terms of how it relates to the engineering of systems. A related phenomenon is
network externalities. These two concepts will be described with respect to standards, requirements, architecture,
intellectual property, time to market, and the spiral development approach. There will also be a discussion of how
path dependence and network externalities influence systems integration at the level of product, process, and policy.

9.3.1 Vajra Logic and Mathematical Meta-models for Meta-systems Engineering: Notes on the
Foundations of Emergent Meta-systems Theory and Practice
K.D. Palmer
This paper explains at a high level of abstraction the meaning of the term Vajra Logic as it relates to Diamond Logic
and Matrix Logic. It also explains the concept of Meta-models as an extension related to the concept of
Mathematical Model Theory. These ideas were mentioned in the paper "Anti-terror Meta-systems Engineering" and
this paper seeks to fill in more background as to what is meant by these terms. These ideas are related to Set and
Mass mathematical and logical categories and Syllogistic and Pervasion logics. Finally, there is discussion
concerning the use of the Gurevich Abstract State Machine Method for the purpose of modeling Turing machines
and Universal Turing machines as a way to represent Systems and Meta-systems for Engineering Design. The
foundations of Systems Design Languages are briefly discussed. This is a conceptual working paper of research still
in progress and does not represent final results.

9.3.2    Make Me Autonomous when I Fly: A Systems Engineering Quest and Pilots‟ Paradise
S.L. Pietras, Boeing Aerospace
C.H. Dagli, UMR Systems Engineering Program Director
How systems engineering practices may bring human cognition into the focus of advanced technology aviation
system designs. This includes generating cognitive qualitative and quantitative requirements, as both functional and
performance design requirements, early in the system conceptual design phase based on Technical Performance
Measures (TPMs). Cognitive TPMs must be formulated and assigned high priorities to ensure they are not lost or
compromised during conceptual phase trade-offs. Otherwise, economic factors will drive automation that may
consequently leave the pilot out of the loop. To prepare for the early design phases, systems engineers (SEs) must
come to understand the pilot environment and pilot behavior in that environment. The customer‘s need, and SE
purpose, is to optimize pilot situational awareness. Cockpit system designs must satisfy customer and user
expectations. This is accomplished by ensuring pilot psychomotor and cognitive skills are kept intact and by
monitoring for appropriate pilot workload during all phases of flight.
Automated pilot assistants or intelligent agents may change how pilots fly but they do not change the pilot‘s
underlying cognitive and physical make-up. Therefore, such agents must be able to track and anticipate a pilot‘s
behavior, assess the flight/mission situation, and provide advice in real time. The SE goal is to acquire good
communications and teamwork, thus reducing pilot errors and ensuring a healthy crew. Language is a key problem-
solving tool for humans, lending itself readily for pilot adaptation to advanced cockpit technology incorporating
voice recognition. All pilot tools are an extension of the pilot‘s consciousness; the pilot actually thinks with them.
Therefore, automated advice must be designed such that the pilot feels the assistant is present in real time.

9.3.3    Development of the Evolved Seasparrow Missile Under IPD Methodology
C.L. Roe, Johns Hopkins University Applied Physics Laboratory
The Evolved Seasparrow Missile (ESSM) development has proceeded through engineering and manufacturing
development and is now undergoing operational testing prior to being approved for service use. This effort,
supported by a consortium of the United States and allied nations, will provide a significant improvement to the
existing Sparrow Missile. It will give the fleets of these nations an anti-missile capability against existing and
projected threats that possess low-altitude, high velocity, and radical maneuver capabilities that stress present
systems. This paper traces the ESSM‘s development under DOD-mandated Integrated Product Development (IPD)
from early definition efforts through engineering and manufacturing development and into the present operational
test and evaluation trials that will prove its capabilities to support consortium fleet missions.

9.3.4    Internet Marketing In Central and Eastern Europe: Will It Catch Up With the West?
V. Sohmen, Umeå School of Business and Economics
This paper looks at the Internet as a marketing and e-business tool, and its prospects in Central and Eastern
European countries. Some of the impediments to Internet marketing in Central and Eastern Europe are considered. It
is recommended that to narrow the gap with Western Europe, the use of e-projects would provide flexibility and
fast-tracking capabilities to firms in the transitional economies. These countries can also craft strategies consonant
with their own historical and cultural legacies. Insights are offered into Internet marketing prospects for Central and
Eastern European countries as emerging and promising economies.

9.3.5    Effective Engineering Decisions Through Structured Collaboration
M.A. Wilson, Center for Systems Management
This paper describes a methodology for engineering decision-making through structured collaboration. This
collaborative decision engineering methodology has been effective in both government and commercial arenas on a
wide range of programs. By thinking about the decision as a three step process of: (1) framing the decision to be
made, (2) generating alternatives, and (3) deciding the course of action, decision makers can harness group
dynamics to help achieve the goal of implementing engineering decisions that work and last.