|
The following section lists technical paper abstracts in the order in which they appear in the program.
The number shown before each abstract title indicates the presentation order in the session and track.
Papers can be referenced in the CD ROM Proceedings
SESSION 1
Session 1 Track 1: Design of Complex Systems - Managing Complexity
| 1.1.1 |
Applying Systems Engineering to Warship Top Side Design
M. Manzini, M. Montigiani, Orizzonte Sistemi Navali SpA
This paper presents a high level warship topside design process. All the aspects involved such as Human Factors, Electromagnetic Engineering,
the Platform, the Combat System and so on, are taken into account. To manage, plan and coordinate all the activities,
a Systems Engineering approach is applied. Starting from requirements definition and their analysis, through an iterative optimization loop,
the whole Systems Engineering process is described. To assist supervision, graphic tools such as risk matrices are introduced.
These matrices allow a global vision of the whole process in a very simple way.
So we provide an effective path towards an efficient topside configuration that minimizes the risks which would otherwise occur
in a non-interdisciplinary approach. Finally a way to "measure" the process is given. |
| 1.1.2 |
Naval Combat System Design: System Engineering Approach and Complexity Management
F. Ciambra, M. Nardini, AMS
Naval Combat System Design is the process which starting from system specification allows to define system architecture and
its functional and physical interfaces in order to obtain an integrated system in its natural operative scenario.
The large number of components and interdependent systems of a naval Combat System makes it complex.
The application of the System Engineering approach, throughout the project’s life cycle, consents to manage the system complexity.
|
| 1.1.3 |
A Quantitative Methodology for the Optimal Selection of Design Margins in Complex Systems
S. Snape, P. Sen, University of Newcastle upon Tyne; S. Whittle, BAE SYSTEMS
Design margins are the additional performance capability designed into a system to compensate for uncertainties.
It is common place for uncertainties to be allowed for by introducing design margins based on experience.
However, there is currently great interest within industry in applying robust and probabilistic methods,
as the arbitrary selection of design margins is inappropriate in today’s design to cost environment.
With this in mind, this paper presents a novel quantitative methodology developed to estimate and select design
margins in an optimal and robust manner. Particular attention is given to design margins in a performance context,
i.e. design margins intended to improve the probability of a system/process performing to requirements.
Furthermore the link between Design Margins and Critical Design Features (A sub-set of top level product attributes
/ requirements that are agreed as being critical to project success) is explained and an approach to determine and manage both is introduced.
|
Session 1 Track 2: Systems Safety & Reliability Engineering
| 1.2.1 |
Introducing New Technical and Methodological Requirements in Avionics Systems Safety Engineering
P. Capircio, Thales Avionics
Avionics safety is under facing new technical and methodological challenges. After a description of the actual safety process
required by airworthiness regulation, the main new technical concerns to deal with are presented,
one of the most important being software errors. THALES AVIONICS is under implementing a new safety engineering process
providing a way to cope with these new technical requirements and fully compliant with new methodological ones such as
ISO 9001 V2000 and CMM-I. As a conclusion, a brief identification of the other challenges being expected in the near
future is given and the capability of the THALES AVIONICS process to deal with is stated.
|
| 1.2.2 |
A Specification Format for Reducing the Cost of Change in Safety-Critical Systems
J. Howard, Safeware Engineering Corporation
Safety-critical systems are costly to change. In all systems, changes must be examined for their impact on existing designs.
Conflicts must be resolved and trade-offs evaluated to ensure that the system still accomplishes its goals.
In safety-critical systems, the additional concerns of system safety must be satisfied: the change must not introduce new hazardous behaviors,
be they incorrect actions or correct actions taken at an incorrect time. An improved format for system specifications,
called intent specifications, and a component requirements modeling language, called SpecTRM-RL
(SpecTRM Requirements Language) can reduce the cost of evaluating the safety of changes to complex safety-critical systems.
Intent specifications, the SpecTRM-RL requirements modeling language, and supporting tool automation have been applied in the aerospace,
automotive, and medical device industries.
|
| 1.2.3 |
A Systems Engineering Approach to Occupant Protection System Design and Optimization Through Modeling and Simulation
H. Zhang, D. Ma, Delphi Corporation
Occupant Protection Systems (OPS) have become a very important part of today’s automotive systems.
The extensive government regulations and consumer information programs make the design and optimization of the advanced OPS a complex and
challenging task. A Systems Engineering (SE) approach is implemented throughout the OPS design and optimization process.
The SE process includes customer requirements analysis, system concept design, system design, analysis and optimization
and system verification and validation. To fully evaluate the performance of the OPS and ensure its compliance of government regulations,
the system needs to be tested in a large number of crash scenarios. Using physical tests alone to develop the OPS is cost prohibitive.
Therefore, computer modeling and simulation are utilized as one of the primary tools in the process.
A frontal impact OPS design and optimization example is presented in the paper to demonstrate the process.
|
Session 1 Track 3: SE in Research & Design
| 1.3.1 |
Conflict Oriented Design - A Concept for the Integration of Innovative Design and Quality Assurance
Methods to Support the Preliminary Design and Technology Validation Processes
T. Lochow, EADS Germany GmbH
Due to the increasing competition on the transport aircraft market the aircraft manufacturers have to make effective strategic
decisions during the product development phase in order to avoid false investments and resultant costs. A central position takes
the preliminary design phase. This study of the EADS Corporate Research Center contributes to an increase of effectiveness of the
design and technology validation process by integrating core elements of innovative design and quality management methods like TRIZ and FMEA.
That way a conflict oriented design concept is formed, which allows the user to analyse interdependencies of conflicts
that arise during the design process. Additionally a typology of emerging conflicts and contradictions in the preliminary
design process is developed, supported by research results in the field of conflict management and concurrent engineering.
For the demonstration of the concept, a prototype of a parametric aircraft configuration tool is used.
It supplies functionalities that help focusing on detecting conflicts and contradictions within the concept design or technology validation process.
|
| 1.3.2 |
Customer Focused Engineering in Airbus A380 Programme
P. De Chazelles, M. Comes, A. Kerrien, AIRBUS
At the very beginning of a new program, the environment is not stable because nobody is able to know the answers to the future needs
from the previous solutions. In this phase, it is necessary to brain storm with potential customers in order to identify new ideas
that are emerging and to learn very fast from the feedback, because the target is moving. The elicitation of the basic ideas allows
the preparation of a consistent framework of top level requirements and design solutions.
It is a factor of critical success for the continuation of the project. Since the beginning of the development of A380,
Airbus has organized many workshops (Customer Focus Group / CFG) with Airline companies who are potential customers of the A380,
Airports and other stakeholders. These events give the opportunity to elicit customers needs and to provide visibility on design.
This is supported by a process that covers:
- customer requests capture and validation during workshop or during bilateral meeting;
- processing of the request
- feedback and acknowledgment by the customer.
In addition, the repository used to manage the requests and answers is a source for Top Level Requirements that drives the development of the A380.
The role of the CFG is fundamental to support communication between airlines customers and Airbus specialists from all disciplines.
It allows establishing a common and clear vision of the purposes to be achieved by the new product.
This paper presents the engineering process deployed by Airbus to guarantee the consideration of the customer point of view and
ensure its satisfaction on the final product.
|
| 1.3.3 |
Deployment of System Engineering to Structural Design Teams within Airbus
M. Bourne, AIRBUS UK
System Engineering though well established in the development of Aircraft Systems and Software within Airbus has not been widely
used in structural design. On the A380 project it was decided to deploy System Engineering methodology across both disciplines
to add rigor to the design, benefit from exchange of data and try to ensure Maturity at EIS.
This paper describes how System engineering principles were simplified as far as possible to allow deployment to teams
unaccustomed to their use and how the cascade of requirements has led to a large proportion of non-functional requirements at the lowest levels.
|
Session 1 Track 4: Process Development/Improvement
| 1.4.1 |
Teaching Old Dogs New Tricks
R.A. Bardo, Lockheed Martin Missiles and Fire Control
P.J. Brown, Systems Engineering Associates, Inc.
Downsizing, and consolidation of previously independent companies, has produced a clash of cultures in many companies.
The problem is exacerbated by "home-grown" product development cultures that have been around for decades and have often
failed to adequately integrate new disciplines such as software engineering and systems engineering.
Over the years, the pace and complexity of technological development has increased. Mergers have brought together more
companies with differing processes. New standards like the Software-Capability Maturity Model® (SW-CMM®) and Capability Maturity Model Integration®
(CMMI®) have been introduced. All these changes have moved to the forefront the need for developing and instituting new,
integrated, and more repeatable engineering processes. Methods of introducing, and gaining acceptance of, these new processes are
becoming very important to the continued competitiveness of many companies.
At issue is how best to get a diverse workforce to work together to achieve extraordinary goals.
Lockheed Martin Missiles and Fire Control (LMMFC), faced with integrating two former competitors, embarked in 1999 on a course to
develop a common product development culture. A primary forcing function was the use of Carnegie Mellon University's Capability Maturity
Model-Integration (CMMI®) standard. The resulting new processes are enabling employees to achieve higher goals
-- by increasing productivity, maximizing use of information, using proven simplified processes, increasing re-use, and decreasing re-work.
Results to date indicate a "One Company, One Team" mentality is rapidly becoming the norm at LMMFC.
|
| 1.4.2 |
Enterprise Architecture and Enterprise Process Improvement
L. Ibrahim, Federal Aviation Administration
C. Wells, I-metrics LLC
R. Bate, Software Engineering Institute
The Federal Enterprise Architecture (FEA), once institutionalized throughout government, can become a major driver for process improvement.
This will depend on the use of best practice in creating, applying, and evolving it and the successful launching and execution of projects
to realize those improvements. An enterprise process improvement model that provides best practice guidance for creating, applying, evolving,
and institutionalizing the FEA, can align with the FEA in striving for enterprise improvement. Industry is monitoring Government progress,
and some companies are working on their enterprise architectures.
Enterprise architecture and enterprise process improvement are similar concepts, with similar methods, seeking similar objectives.
This paper examines the commonalities between enterprise architecture and process improvement and illustrates how an enterprise process improvement model,
when used in combination with enterprise architecture, can enable improvement across government and industry.
|
| 1.4.3 |
Learning Organizational Lessons
S. Sheard, Software Productivity Consortium
Learning and applying lessons is one requirement for continuing to improve business processes. Too often, companies neither collect lessons
nor apply them well, or else they collect lessons well but have difficulty incorporating the lessons into future work.
This paper describes the phases of learning lessons, necessary cultural factors and infrastructures, and how lessons-learned
programs evolve over time. The phases of a process for learning lessons are identification and collection, analysis and description,
and communication and implementation. Additionally, this paper shows many dimensions of lessons-learned efforts,
provides pointers to many examples available online, and helps the reader establish a strategy for improving the ability of the
organization to learn lessons.
|
Session 1 Track 5: Managing Multidisciplinary/-Cultural Complexity
| 1.5.1 |
Bridging System Engineering and Human Factors Engineering: A Step Forward
J.R. Ruault
Human factors are the cornerstone for insuring QHSESA quality for all/some/many systems. Normative documents such as ISO 15288 or EIA 632
provide keys to human factors processes and activities. There are few links between system engineering (SE) processes and
human factors engineering (HFE) processes.
This article bridges the gap between SE, using EIA 632, and HFE, using ISO TS 13407 and ISO TR 16982. The purpose is to provide
project managers and system engineers with a guide helping them to plan and implement human centred design. The first part deals with SE,
the second with HFE, and the third provides the bridge between the two. For each EIA 632 requirement, the article indicates the
relevant ISO 13407 principles and activities to apply.
ISO 13407 is not as specific and clear as EIA 632. It would be relevant to enhance HF standards in order to encompass such processes
as risk management, effectiveness analysis, or trade-off analysis.
|
| 1.5.2 |
Factors Influencing SE Practices by 2010
J. Ring, Innovation Management
This paper describes current and probable stochastic shocks that may shape the practice of systems engineering in the near future.
This is not about predicting the future but about considering possibilities, ramifications and probabilities.
The purpose of this paper is to encourage the reader to add, change, or delete entries that are more pertinent to their respective
situations and viewpoints, then to think deeply about the interrelationships of these change factors thus the key alternative
scenarios for the reader’s future. One general conclusion seems clear – the SE practitioner of 2003 will be largely obsolete
in five to seven to ten years unless he/she vigorously engages in multidisciplinary learning both across engineering disciplines
and especially outside of engineering.
|
| 1.5.3 |
Is SE Evolving Fast Enough? Results of INCOSE 2002 Panel Poll
J. Ring, Innovation Management
Attendees were polled at the end of the INCOSE 2002 panel session, "Is SE Evolving Fast Enough?"
This paper reports the questions and attendee responses as well as the author’s interpretations of the responses.
Two important conclusions are; 1) SE is not evolving fast enough and 2) key opportunities for evolving the practice of SE are not being pursued.
This poll should be considered only a quick look at the issue. The purpose of this paper is to motivate INCOSE to conduct
a more comprehensive survey of SE practitioners regarding the issue.
|
Session 1 Track 6: Integrating SE & Project/Program Management
| 1.6.1 |
Software Project Management: Adding Stakeholder Metrics to Agile Projects
T. Gilb, Result Planning Limited
Agile methods need to include stakeholder metrics in order to ensure that projects focus better on the critical requirements,
and that projects are better able to measure their achievements, and to adapt to feedback. This paper presents a short,
simple defined process for evolutionary project management (Evo), and discusses its key features.
|
| 1.6.2 |
An Approach to Tailoring Major Technical Reviews Based on Project Characteristics and Stakeholder Interests
A.B. Richstein, Space Technology Office
J.T. Nolte, Northrup Grumman Information Technology – TASC
B. Pfarr, NASA
Both NASA and DOD have well defined, proven technical review processes that include numerous technical reviews that occur throughout
the systems engineering process life cycle. Many are well known by project managers and stakeholders such as developers and end users,
an example of which is the critical design review (CDR). This major milestone for a large, complex new project may last two or more days,
include an extensive agenda of topics, and entail hundreds of hours of developer time to prepare presentation materials and associated documents.
Additionally, the weeks of schedule spent on review preparation is at least partly at the expense of other work.
This paper suggests an approach for tailoring technical reviews, based on the project characteristics and the project manager’s
identification of the key stakeholders and understanding of their most important issues and considerations.
With this insight the project manager can communicate to, manage expectations of, and establish formal agreement with the
stakeholders as to which reviews, and at what depth, are most appropriate to achieve project success. The authors,
coming from diverse organizations and backgrounds, have drawn on their personal experiences and summarized the best practices
of their own organizations to create a common framework to provide guidance on the adaptation of design reviews to other system engineers.
|
| 1.6.3 |
Formalizing the Language in Your Universes of Discourses
R. Gonzales,S. Joyce, D.S. Cuyler Sandia National Laboratories
Semantic understanding of the domain for which a system or solution is being developed is crucial. Defining the ontology as part of domain modelling
at the onset of a project permits effective effort as you communicate with stakeholders and move into formal definition of requirements.
However, there is another Universe of Discourse in play when working as an integrated product team (IPT) on a project. Many times the terms used
by the project team are assumed to be understood, but with the complexity of today’s systems, the tools used to create project artefacts,
and the teams needed to realize solutions, this is not always the case. This paper will present a case study illustrating the method applied to model,
using UML, the ontology for a Universe of Discourse that represents the problem domain and the ontology of the project team developing the solution.
|
SESSION 2
Session 2 Track 1: Design of Complex Systems - Managing Complexity
| 2.1.1 |
Isoperformance: Analysis and Design of Complex Systems with Known or Desired Outcomes
O.L. de Weck, Massachusetts Institute of Technology
M.B. Jones, Pennsylvania State University
Tradeoffs between performance, cost and risk frequently arise during analysis and design of complex systems. Many such systems have both
human and technological components and can be described by mathematical input-output models. Oftentimes such systems have known or desired
outcomes or behaviors. This paper proposes "isoperformance" as an alternative approach for analyzing and designing systems
by working backwards from a set of desired performance targets to a set of acceptable solutions. This is in contrast to the
traditional "forward" process, which starts first in the design space and attempts to predict performance in objective space.
Isoperformance can quantify and visualize the tradeoffs between determinants (independent design variables) of a known or desired outcome.
For deterministic systems, performance invariant contours can be computed using sensitivity analysis and contour following.
In the case of stochastic systems, the isoperformance curves can be obtained by regression analysis, given a statistically representative data set.
Examples from opto-mechanical systems design and human factors are presented to illustrate specific applications of the method.
|
| 2.1.2 |
Predicting the Reliability of a Complex System Using an Artificial Neural Network
A.L. Breitler, Trinity College / Florida Institute of Technology
C.D. Sloan, EagleRidge Technologies, Inc.
The capability to predict the reliability of complex systems that must be deployed without overly prolonged or expensive testing is of
increasing importance to the military test and evaluation community. The presentation of subsystem reliability data to an artificial
neural network is a critical factor in the capability of such networks to produce accurate system predictions. By producing a matrix
of values corresponding to subsystem reliabilities, using a zero (0) for a nonexistent parallel resource and a one (1) for a nonexistent
series subsystem, it was possible to train an artificial neural network to accurately predict the overall system reliability.
|
| 2.1.3 |
A Systems Engineering Framework for Design, Construction and Operation of the Next Generation Nuclear Plant
E.J. Gorski, F.H. Southworth, C.V. Park, Bechtel BWXT Idaho, LLC
Not since the International Space Station has a project of such wide participation been proposed for the United States.
Ten countries, the European Union, universities, Department of Energy (DOE) laboratories, and industry will participate in the
research and development, design, construction and/or operation of the fourth generation of nuclear power plants with a demonstration
reactor to be built at a DOE site and operational by the middle of the next decade. This reactor will be like no other.
The Next Generation Nuclear Plant (NGNP) will be passively safe, economical, highly efficient, modular, proliferation resistant, and sustainable.
In addition to electrical generation, the NGNP will demonstrate efficient and cost effective generation of hydrogen to support
the President’s Hydrogen Initiative.
To effectively manage this multi-organizational and technologically complex project, systems engineering techniques and processes will
be used extensively to ensure delivery of the final product. The technological and organizational challenges are complex.
Research and development activities are required, material standards require development, hydrogen production, storage and infrastructure
requirements are not well developed, and the Nuclear Regulatory Commission may further define risk-informed/performance-based approach to licensing.
Detailed design and development will be challenged by the vast cultural and institutional differences across the participants.
Systems engineering processes must bring the technological and organizational complexity together to ensure successful product delivery.
This paper will define the framework for application of systems engineering to this $1.5B - $1.9B project.
|
Session 2 Track 2: Systems Safety & Reliability Engineering
| 2.2.1 |
Model-Based Safety Analysis of a Flap Control System
T. Peikenkamp, E. Böde, I. Brückner, H. Spenke, Kuratorium OFFIS e.V.
M. Bretschneider, AIRBUS Deutschland GmbH
H-J. Holberg, OSC Embedded Systems AG
Fault tree analysis is a widely adopted technique to systematically analyze causes for a given failure of a complex system.
Traditionally, a fault tree is constructed top-down based on knowledge about the structure of the system and the interaction of subsystems.
With the increasing system complexity and the accompanying introduction of model-based development techniques in the industrial process,
a substantial amount of this knowledge is laid down in the system models. The main focus of the presented techniques and
tools is to automatically exploit this knowledge by extracting a fault tree suitable for FaulTree+ directly from a given
design modeled in Statemate. The resulting fault tree is complete wrt. the specified failure, i.e. the analysis considers
every possible causal failure combination which is guaranteed by applying model checking techniques.
Using an aircraft Flap control system this paper shows how to smoothly integrate the technique into an existing model-based process.
|
| 2.2.2 |
Complexity and Change in the Subsea Oil Production Industry
L.A. Piciaccia, H.J. Lindland, T. Faanes, FMC Kongsberg Subsea
Sweeping changes have been experienced throughout the whole of the subsea oil production industry. Space technology has gone subsea,
and with it comes the need to properly address the relevant issues. The traditional oil industry, used to measure its tools in
multiple of tons and its performance in barrels, has been faced by the challenge of distributed system interfaces and their metrics.
This paper describes of how the challenge is being tackled at FMC Kongsberg Subsea (FKS), the Subsea Production System manufacturer
with the largest number of system installed in the world.
|
| 2.2.3 |
Towards the Integration of Saftey Assessment and Systems Engineering Methods for Rail Transport Systems Development
E. Duurland, G.-J. Ransijn, M. Verhoeven, R. van Duyne, ADSE Consultancy & Engineering Services
This paper describes an improved, scenario-based method for identifying hazards of complex safety-critical systems and its application
to the safety management of a high-speed rail transportation system.
Traditional approaches for systematic identification of hazards include empirical methods like the use of checklists and structured
walkthroughs as well as creative methods like brainstorming and HAZOPS studies. While empirical methods rely heavily upon knowledge
of the past and tend to be less effective for novel systems, creative methods tend to lack systematic rigor.
Both categories fail at addressing the hazards associated with functional failure of complex integrated systems.
The scenario-based method introduced in this paper combines the systematic, analytical derivation of hazards from behavior models
that specify the operational scenarios for the system of interest with creative team-based sessions that are structured around the
same behavior models of the operational scenarios.
A major benefit of this approach is that through the behavior models of the operational scenarios the safety assessment process
is directly linked to systems engineering work products. This provides a sound basis for integrated design iteration cycles and
reuse of information and thus for improving the quality, lead times and cost of the overall development process.
|
Session 2 Track 3: SE in Research & Design
| 2.3.1 |
A Decision Support Framework for Feasibility Analysis of International Space Station (ISS) Research Capability Enhancing Options
J.N. Ortiz, NASA / JSC
H. Smith, Raytheon Technical Services Co.,
K. Scott, Booz-Allen Hamilton
The assembly and operation of the ISS has generated significant challenges that have ultimately impacted resources available to
the program’s primary mission: research. To address this, program personnel routinely perform trade-off studies on alternative
options to enhance research. The approach, content, level of analysis and resulting outputs of these studies vary due to many factors,
however, complicating the Program Manager’s job of selecting the best option. To address this, the program requested
a framework be developed to evaluate multiple research-enhancing options in a thorough, disciplined and repeatable manner,
and to identify the best option on the basis of cost, benefit, and risk. The resulting framework consists of a systematic
methodology and a decision-support toolset. The framework provides quantifiable and repeatable means for ranking research-enhancing
options for the complex and multiple-constraint domain of the space research laboratory. This paper describes the development,
verification and validation of this framework and provides observations on its operational use.
|
| 2.3.2 |
Tailoring Systems Engineering for UAV Platform Development
I. Wijnhoven, J. Doornbos, E. Jesse, ADSE Consultancy and Engineering Services
This paper describes how Systems Engineering methods have been applied in the conceptual design study for an Unmanned Aerial Vehicle (UAV),
and the lessons that were learned in this experience. In comparison with traditional aerospace and defense industry,
the UAV market is different because of the seemingly endless possibilities of UAV technology, the lack of existing standards
and the entrance of new players, which are not traditionally active in aerospace or defense. This makes the application of
Systems Engineering for UAV platform developments differ from traditional practice.
In the UAV conceptual design study, which is the focus of this paper, all partners had a strong background in aerospace and
defense development. The case is discussed as an example, aimed at illustrating the principles of tailoring Systems Engineering
for UAV platform development.
|
| 2.3.3 |
A Transparent Way for Process Guidance in Satellite Design
S. Finkel, Technische Universitat Munchen
M. Burazanis, EADS Astrium GmbH
This paper describes the development of a satellite design process and its implementation within a process guidance tool
(Process Steering Tool – ProST) for the work within a design center environment (Satellite Design Office – SDO).
Process and tool have been developed at the Institute of Astronautics (LRT) of the Technische Universität München in cooperation with
EADS Astrium Ottobrunn within the BaiCES project (Bavarian Center of Excellence for Satellite Constellation Systems) partially funded by
the Bayerische Forschungsstiftung BFS. The work presented in this paper was based on two major aspects, the design center concept and
the satellite design process. The paper emphasizes a new way of process guidance, using a web based tool support, against the background of these aspects.
The authors present the overall process development and guidance approach, in particular the design and implementation of the
satellite design center process within the process steering tool and the process guidance provided by the tool.
The paper also highlights the evolution from the idea of developing a HTML based process guidance demonstrator to a dynamic PHP/mySQL based tool.
It also shows that this approach is well suited for the guidance of a design center team through a development process.
The usability and flexibility of this process was shown during a satellite design workshop at the Institute of Astronautics.
At the end of the paper the next steps of the process and tool development will be presented.
|
Session 2 Track 4: Process Development/Improvement
| 2.4.1 |
10 Pitfalls of Process Development with Avoidance Solutions
E. Arnold, United Defense, LP
Literature has provided good guidance on what to include when writing new process descriptions, but very little has stated clearly what actions
must be taken by companies during the course of developing usable, integrated processes. Countless hours have and are being spent on
development of company processes, which end up sitting on shelves in their unopened, shrink-wrapped notebooks, or archived to sparsely
accessed and often ignored internal web sites. Management assumes the processes must not be the right ones,
or personnel would joyfully use them. The result is yet another extensive effort to "get it right" by re-writing the processes
with a different slant. Why is it that processes are not well received or utilized by some companies,
yet others embrace process with open arms? This paper explores the author’s experienced pitfalls of integrated,
system process development at an organizational level, whether that translates to a program, division, or enterprise level,
and offers avoidance solutions to help remedy the maladies. This paper is intended to provide solutions to circumvent the common maladies
associated with process development and process improvement. |
| 2.4.2 |
NASA Systems Engineering Capability Pre-Assessment Plan
J. F. Andary, P. Chun, E. Ernst, D. Gauntner, S. Kapurch, R. Kerns, NASA
J. Lake, Systems Management international
Over the past several years, several events have led NASA to re-examine how it engineers systems. As a result, NASA initiated a
Systems Engineering Excellence Initiative in 2001, and established a Systems Engineering Working Group (SEWG) to form and
implement a common framework for engineering systems within NASA.
The common framework is based on the development and sustainment of a state-of-the-art level of competence in systems engineering,
measurable in three specific areas; Concepts and Processes; Knowledge and Skill of Workforce; and Tools and Methodologies.
The framework must also include a method of providing continuous assessment and improvement.
Cursory review led a SEWG sub-group (The Assessment Subgroup) to conclude that utilization of a recognized maturity model,
such as the Software Engineering Institute’s (SEI) Capability Maturity Model Integrated (CMMI®), would provide the means
for ensuring continuous assessment and improvement of the framework.
Prior to launching a CMMI® assessment of systems engineering at all ten NASA Centers (estimated to cost in excess of $500,000),
the Assessment Subgroup proposed to conduct a pre-CMMI® assessment (hereafter referred to as a pre-assessment) to evaluate the
current level of competence of systems engineering throughout the Agency, and determine whether or not CMMI® should be implemented. |
| 2.4.3 |
Evolving Systems Engineering Processes: Moving from "What Systems Engineers Do" to "Engineering Systems"
S. Sheard, Software Productivity Consortium, T. Holzer, National Imagery and Mapping Agency
Companies have documented systems engineering processes for years, in order to describe what the people they call "systems engineers"
do to help product development. In an era of integrated processes, however, it becomes apparent that systems engineering is by its nature
an integrating process. Therefore, true engineering of systems works better with an integrated set of engineering processes,
within which are systems engineering roles. This paper describes why systems engineering processes are evolving in this manner,
as well as how to evolve processes that describe what systems engineers do into an integrated set of processes for engineering systems.
|
Session 2 Track 5: Managing Multidisciplinary/-Cultural Complexity
| 2.5.1 |
Collaborative Processes Enabler
M. Callot, L. Saint-Marc, EADS CCR, M. Moly, AIRBUS
B. Trebucq, PCO Technologies
In Concurrent Engineering, multi-disciplinary teams of experts perform design activities. They contribute to the design activities collaboratively,
which induce them to make decisions and share the information with each other with no systematic traceability.
The purpose of this paper is to anticipate decisions by proposing rules and methods to enhance collaborative work concerning data engineering
exchanges between all involved skills whatever their site or their firm. The main objective of this work is to enforce Discipline Collaboration
in Engineering by :
- Supporting Collaborative Processes complexity,
- Enhance collaboration work through Engineering objects availability and quality control,
- Decrease rework with obsolete information or over information.
To address the complexity, the method relies on invariant objects independently of the organization and discipline processes.
A "collaborative platform" demonstrator based on the method will support the designers in their daily work.
|
| 2.5.2 |
Systems Engineering in an Outsourcing Environment
F.R. Parth, J. Gumz, Project Auditors, LLC
Outsourcing is the process of hiring someone else to do work that a business cannot, or does not wish to, do itself.
While businesses have always done this, the entire field of outsourcing has taken on new dimensions and in the past few years
has become vastly different from what it once was. Now companies are outsourcing significant portions of their core application
development work overseas as well as areas such as order processing, help desks and others, justified by a lower cost per unit.
As a result of overseas outsourcing, significant problems have arisen that either did not exist before or were easy to remedy
when the work was done internally. Many of these problems can be traced to poor or missing requirements,
a poor understanding of business processes, or to technology and security problems in the deliverables.
This article discusses the role of systems engineering in avoiding or reducing the most significant problems.
Rather than just gathering functional and performance requirements, systems engineers must now develop
an entire requirements encyclopedia in order to provide enough information, do much more detailed business process analysis,
and help develop testing and quality assurance approaches that can detect security back doors that may have been put into software products.
|
| 2.5.3 |
Unifying Systems Engineering Through the System Record
G.R. Baden, University of Maryland University College
Managing the information and processes that are intrinsic to systems engineering efforts requires the identification and
control of a range of enterprise data. This paper will present an approach to systems engineering management that is based
on the concept of the "system record." By capturing and managing the system record, an organization gains visibility
into the five major content areas that feed the systems engineering effort and integrates these content areas in a managed
process from concept through retirement. Intrinsic within the system record approach is the ability to operate on system engineering
content from the highest system level to the detailed component level within the context of both process and content interrelationships.
Examples of how the system record concept can be utilized in system engineering projects are included.
|
Session 2 Track 6:
| 2.6.1 |
The Schedule as Independent Variable (SAIV) Process for Acquisition of Software-Intensive Systems
B. Boehm, W. Brown, LG. Huang, University of Southern California
D. Port, University of Hawaii at Manoa
Many system acquisitions do not achieve on-time delivery because of delays in software development. This paper presents a highly successful
approach for on-time delivery of software-intensive systems: the Schedule As Independent Variable (SAIV) process. The SAIV process involves
prioritization of desired features; scoping a Core Capability of top-priority features easily achievable within the available schedule;
architecting for ease of dropping or adding borderline-priority features; monitoring progress with respect to plans;
and adding or dropping borderline-priority features to meet the schedule target. The paper summarizes experiences and discusses critical
success factors in applying the SAIV acquisition process across a range from small in-house e-services projects to very
large Government systems of systems.
|
| 2.6.2 |
Systems Engineering Sizing in the Age of Acquisition Reform
R. Valerdi, USC Center for Software Engineering
M. Ernstoff, P. Mohlman, The Aerospace Corporation
D. Reifer, Reifer Consultants, Inc., E. Stump, Galorath
As organizations develop more complex systems, increased emphasis is being placed on Systems Engineering (SE) to ensure that cost and
schedule are within budget. Correspondingly, the failure to adequately plan and fund the systems engineering effort appears to have
contributed to a number of cost overruns and schedule slips, especially in the development of complex ground and space systems.
Government and commercial organizations have recently placed increased emphasis on accurately planning the SE function and on understanding the
factors that influence the resources needed to implement and perform SE.
In an attempt to better quantify the SE activity, the DoD acquisition community has been exploring Systems Engineering Revitalization
and migrating back to a reinstatement of prescribed military standards. Several models and tools have become available to aid in
forecasting systems engineering resource needs, but few guidelines exist to help engineers and program managers determine which approach
is best suited for estimating any particular effort.
To provide such guidelines, this paper provides an overview of eight existing cost models - three of which focus on software and five on hardware.
These models include SE components and employ unique approaches to sizing the SE effort. An overview of the genesis and assumptions of each model
shed some light on their individual applicability. To complete the paper, future research topics are discussed along with recommendations on
tasks to enhance the accuracy of SE sizing.
|
| 2.6.3 |
Understanding Cost Analysis Process in United States Government Systems Acquisition
R.P. Covert, S.E. Jones, T.P. Anderson, The Aerospace Corporation
Cost estimates are one of the most widely known attributes of a program, but from an outsider's perspective, the process of cost estimation
and analysis often appears to be a "black art.&%quot; The purpose of this paper is to describe the development and use of cost estimates
and cost analysis, particularly with respect to United States (U. S.) government systems acquisition, and describe the systems engineers’
role in this process.
First, we discuss why a systems approach to cost analysis is critical to mission success and needs to begin at the time of program formulation.
Second, we describe the cost analysis process. Third, we examine the most common methods used in cost estimation; the estimates' accuracies
often depend on which methods are chosen and when these methods are used. Fourth, we describe the evolutionary process of cost estimation
throughout the program lifecycle. Since the amount of information available to estimate the cost of a program changes over the lifecycle
as the program evolves, so too should the methods used to estimate the program's cost. Finally, we describe the use of cost estimates in
cost-risk and cost-benefit analysis.
|
SESSION 3
Session 3 Track 1: Design of Complex Systems - Managing Complexity
| 3.1.1 |
Embedded Systems Engineering: Managing Systems Complexity, Change, and Crises
J.L. BeVier, John L. BeVier & Associates, LLC, C.A. Calimer, The Boeing Co.
The concept of the "Embedded Systems Engineer" is proposed by the authors. The purposeful inclusion, and redefinition of,
the Systems Engineer from that of a specialist supporting engineering activity to that of the persistent critical function underlying
the management and direction of the Dynamic System. Today, Dynamic Systems, as described by John Sterman in Business Dynamics,
have become commonplace. However the Systems Engineering Profession has not adequately responded by creating a correspondingly
dynamic engineering management structure.
Crises driven Engineering Change Proposals in lieu of knowledge-driven systems engineering has become the standard response.
Systems Engineers are challenged to adopt a new and even more important role responsible for management and oversight,
maintenance and operations, and especially architecture and behavior in a Learning System context. Because Dynamic Systems are
primarily Learning Systems, the Systems Engineering function is placed "on-line" to manage rapidly changing systems requirements.
These modern Learning Systems are based on the seminal work of Jay Forrester. The Embedded System Engineer’s unique capabilities are
critical to competent management and decision-making within Dynamic Systems.
|
| 3.1.2 |
The Seven Samurai of Systems Engineering: Dealing with the Complexity of 7 Interrelated Systems
J.N. Martin, The Aerospace Corporation
There are seven different systems that must be acknowledged and understood by those who purport to do systems engineering.
The main system to be engineered is the Intervention System that will be designed to solve a real or perceived problem.
The Intervention System will be placed in a Context System and must be developed and deployed using a Realization System.
The Intervention, when installed in the Context, becomes the Deployed System which is often different in substantial ways
from the original intent of the Intervention. This Deployed System will interact with Collaborating Systems to accomplish
its own functions. A Sustainment System provides services and materials to keep the Deployed System operational.
Finally, there are one or more Competing Systems that may also solve the original problem and will compete for resources
with your Deployed System. All seven systems must be properly reckoned with when engineering a system.
|
| 3.1.3 |
Complex System Classification
C.L. Magee, O.L. de Weck, Massachusetts Institute of Technology
The use of terms such as "Engineering Systems", "System of systems" and others have been coming into greater use
over the past decade to denote systems of importance but with implied higher complexity than for the term systems alone.
This paper searches for a useful taxonomy or classification scheme for complex Systems. There are two aspects to this problem:
1) distinguishing between Engineering Systems (the term we use) and other Systems, and 2) differentiating among Engineering Systems.
Engineering Systems are found to be differentiated from other complex systems by being human-designed and having both significant
human complexity as well as significant technical complexity. As far as differentiating among various engineering systems,
it is suggested that functional type is the most useful attribute for classification differentiation. Information, energy,
value and mass acted upon by various processes are the foundation concepts underlying the technical types.
|
Session 3 Track 2: Systems Safety & Reliability Engineering
| 3.2.1 |
Failure Modes and Two Types of Robustness
D. Clausing, D. Frey, Massachusetts Institute of Technology
Reliability is one of the most important characteristics of a system. To be reliable a system must be robust and mistake free.
Robustness is achieved by avoiding failure modes, even in the presence of noises that strongly tend to excite the failure modes.
Basic systems engineering primarily considers two-sided failure modes, such as excessive deviation from the correct voltage reading
for a voltmeter, which can be either positive or negative; thus the name two sided. In this paper we focus attention on one-sided
failure modes, which occur only on one side of the distribution for the exciting noise(s). A single one-sided failure mode is easy to avoid.
However, in complex systems it is common for two or more one-sided failure modes to be affected by one critical design parameter
in such a way that it is challenging to avoid both failure modes. A path to a reliable system is to open an operating window
between the two one-sided failure modes.
|
| 3.2.2 |
Optimal and Adaptable Reliability Test Planning Using Conditional Methods
M.A. Powell, University of Idaho at Idaho Falls
Developing optimal cost verification strategies for performance requirements using the analysis or test methods can be difficult,
if not impossible. Developing such a strategy that is also adaptable to unexpected test results is even more difficult.
The author investigates a reliability requirement verification example from the automobile industry for cost optimization and
adaptability to unexpected failures using classical methods. Verification strategies for this example are then developed using
conditional methods. These conditional verification strategies demonstrate significant cost efficiencies, and provide easy
adaptability to unexpected failures. These strategies further provide understandable decision criteria for test success or failure.
Using conditional methods for verification of performance requirements provides opportunities for cost savings,
adaptability to unexpected test results data, and clear decisions for product acceptance.
|
| 3.2.3 |
An Approach to Design for Saftey in Complex Systems
N. Dulac, N. Leveson, Massachusetts Institute of Technology
Most traditional hazard analysis techniques rely on discrete failure events that do not adequately handle software intensive systems
or system accidents resulting from dysfunctional interactions between system components. This paper demonstrates a methodology
where a hazard analysis based on the STAMP accident model is performed together with the system development process to design
for safety in a complex system. Unlike traditional hazard analyses, this approach considers system accidents, organizational factors,
and the dynamics of complex systems. The analysis is refined as the system design progresses and produces safety-related
information to help systems engineers in making design decisions for complex safety-critical systems. The preliminary design of
a Space Shuttle Thermal Tile Processing System is used to demonstrate the approach.
|
Session 3 Track 3: SE in Research & Design
| 3.3.1 |
Consumer Product Development: A Systems Engineering Approach to the Derivation of Design Requirements from Stakeholder Needs
V. Agouridas, A. McKay, A. de Pennington, University of Leeds
This paper reports results of research into the engineering design of consumer electro-mechanical products. The research dealt with the
derivation of design requirements from stakeholder needs. An approach based on principles of systems engineering was developed,
applied and evaluated through a number of case studies that were carried out in three industrial domains. The evaluation showed
that the approach can significantly improve the quality of product designs. The revision of the expressed stakeholder requirements
and the expression of stakeholder requirements as stakeholder needs and stakeholder attributes were found to be key factors towards
the improvement of product designs. It is recognised that there are many difficulties associated with the identification of
stakeholder needs for both existing and new products. However, given a need, benefits can be gained from providing information
to support traceability between design parameters, design requirements, stakeholder attributes and stakeholder needs;
such traceability is a key enabler to downstream integration management.
|
| 3.3.2 |
Design Concept Evaluation Using System Throughput Model
G.F. Sequeira, M. Nutt, United States Dept. of Enegry (Environmental)
The U.S. Department of Energy (DOE) Office of Civilian Radioactive Waste Management (OCRWM) is currently developing the technical bases
to support the submittal of a license application for construction of a geologic repository at Yucca Mountain, Nevada to the
U.S. Nuclear Regulatory Commission. The Office of Repository Development (ORD) is responsible for developing the design of the repository
surface facilities for the handling of spent nuclear fuel and high level nuclear waste. Preliminary design activities are underway
to sufficiently develop the repository surface facilities design for inclusion in the license application. The design continues to
evolve to meet mission needs and to satisfy both regulatory and program requirements.
A system engineering approach is being used in the design process since the repository facilities are dynamically linked by a series
of sub-systems and complex operations. In addition, the repository facility is a major system element of the overall waste management
process being developed by the OCRWM. Such an approach includes iterative probabilistic dynamic simulation as an integral part of the
design evolution process. A dynamic simulation tool helps to determine if:
- the mission and design requirements are complete, robust, and well integrated;
- the design solutions under development meets the design requirements and mission goals;
- opportunities exist where the system can be improved and/or optimized;
- proposed changes to mission and design requirements have a positive or negative impact on overall system performance
and if the design changes may be necessary to satisfy these changes.
This paper will discuss the type of simulation employed to model the waste handling operations. It will then discuss the process being
used to develop the Yucca Mountain surface facilities model. The latest simulation model and the results of the simulation and
how the data was used in the design evolution process will also be discussed. Since the use of dynamic simulation is iterative and
integral to the design effort, future activities will also be summarized. The paper will close discussing lessons learned from
applying dynamic simulation to designing complex systems, and will discuss what pitfalls to avoid and recommendations for developing
flexibility in system model development.
|
| 3.3.3 |
Designing Sustainable Processes Using Environmental and Economic Assessment
D. Krajnc, P. Glavic, University of Maribor
The paper presents a systematic approach to the problem of sustainable process synthesis of large-scale chemical processes with
respect to the resource usage and other environmental considerations. The process design is composed of three main steps,
i.e. simulation step, conceptual design step (extended Pinch design method, determination of promising modifications,
their assessment regarding sustainability, selection of the most promising modification) and rigorous design step
(structural and parameter optimization). The ecological considerations are combined with the economic assessment of process design
using indicators of process sustainability. Environmental impact of process design is quantified by a set of sustainable process
indicators (specific energy and water consumption, global warming potential, acidification potential, etc.).
With suitable weightings, a composite index of process sustainability is defined and served as an objective function for the assessment
of process modifications. A simplified ammonia production is presented to demonstrate the potential of the approach
assisting in arriving at environmentally friendly and economically favorable process design.
|
Session 3 Track 4: Process Development/Improvement
| 3.4.1 |
Center for Systems Engineering
K.B. Bausman, M.K. Wilson, USAF AFIT
The "Systems Engineering" Discipline seems to have has lost its focus within the Air Force. Comments by high level USAF leaders
have pointed out that the front end of the Systems Engineering Process has broken down. This has resulted in systems that have high
requirements volatility and acquisition failures. In a combined effort, the Air Force Institute of Technology, the Air Force Material Command
and the Air Force Space Command have joined forces to establish a Center for Systems Engineering.
It has become evident over the last ten years, with Acquisition Reform, the government gave away the "Keeper" role that assured
a consistent application of Systems Engineering and no one from industry has stepped up to accept full responsibility.
Systems Engineering (SE) is an interdisciplinary engineering management process that evolves and verifies an integrated,
life cycle balanced set of system solutions that satisfy customer needs. It is a comprehensive, iterative, multi-functional,
technical management process that includes translating operational requirements into configured systems. It is responsible for integrating
the technical inputs of the entire design team, managing interfaces, characterizing and managing technical risk, transitioning technology
from the technology base into program specific efforts, and verifying that designs meet operational needs. It is a life cycle activity
that demands a concurrent approach to both product and process development. Systems Engineering/Management touches every aspect of our acquisition,
operational, sustainment and retirement processes.
A national forum on SE identified the need to ensure that a quality systems engineering capability exists. The Center for Systems Engineering (CSE)
has been established to do just this job. This CSE serves as the nucleus for the development and accumulation of academic,
government and industry SE best practices, processes, metrics and training. It is collaborating with other members of the SE community to develop,
publish, continuously refine and advocate systems engineering processes and implementation. The CSE provides consulting and analysis services on SE
to all Air Force commands and programs and publish findings as necessary. The CSE manages the identification and collaboration of education and
training for all Air Force personnel associated with the systems engineering process. Ultimately we hope to rebuild the systems engineering
expertise across all Department of Defense areas.
This paper identifies some of the current systems engineering issues/initiatives and challenges with which the CSE is engaged.
The approach in this paper provides a logical method of correcting current systems engineering shortfalls and posturing the Air Force,
and potentially the Department of Defense, for future success in the management of our weapon/space systems toward meeting the war-fighters needs.
|
| 3.4.2 |
Deployment of Systems Engineering at PSA Peugeot Citroën
P. Lamothe, G. Fanmuy, PSA Peugeot Citroën
Automobile product has become today a complex system. Not only does it seek for an optimal trade-off between many domains such as style,
human factors, mechanical, electronic, body structure, software, economy and production products but automobile has also taken advantage
of control and information management functions that represent a third of the car price.
Automobile is now both the result of the application of existing solutions (re-use of processes) and the integration of innovating solutions.
Moreover while automobile product is becoming more complex, customers move from a demand market to an offer market. Automobile industry
offer now creates client needs. This competitive challenge involves obviously the necessity to reduce costs and deadlines while
functional and performance requirements are increasing.
Resolution of this set of antagonistic requirements can be obtained only by using the most appropriate methodologies.
Engineering methodologies now converge towards a large concept called: Systems Engineering.
This paper introduces fundamental considerations associated with the deployment of systems engineering in PSA Peugeot Citroën:
(1) tailoring a referential of processes for engineering an automobile product based on EIA 632 standard (2) building a training cycle
(3) setting up systems engineering tools focused on the engineering requirements processes with DOORS
(4) assisting the engineering teams to use methods and tools.
We hope this experience about the still ongoing deployment of system engineering in PSA Peugeot Citroën will inspire firms that
wish to set up the systems engineering methodology.
|
| 3.4.3 |
Genomics: Requirement Going from Art to Industry
D.S. Kosack, Institute for Genomic Research
Genomics is a new science that is contributing significantly to our understanding of genes, life processes, and disease.
Genomics endeavors to look at the entire organism – the complete DNA - to study its entire gene set, observing mutations and diversity.
Producing the entire DNA sequence and identifying the genes within is no easy task. As budgets are cut and cost becomes more important,
the role of organized software and systems engineering becomes more pronounced.
This paper describes the systems used at the Institute for Genomic Research (TIGR) to produce the sequence of an organism.
The paper begins with an overview of the overall Genomics process. It follows with a discussion of the human genome project and
how lessons learned from the project regarding scale and capability have affected the Genomics view of systems design.
The paper continues with discussion about the need for traceable, consistent requirements and organized system design in Genomics.
Finally, the paper discusses how the Institute for Genomic Research recognizes and addresses the need for proper systems development
through requirements gathering and analysis, system decomposition, and rework.
|
Session 3 Track 5: Managing Multidisciplinary/-Cultural Complexity
| 3.5.1 |
How Can Systems Engineering Improve Socioeconomic Conditions in Developing Countries?
The Jamaican Situation
H. Gaynor, University of Mayland University College
The increased demand being placed on the dwindling resources of developing countries by rising populations, and the need to compete with more
advanced nations in the global economy, have forced the implementation of projects that are stifling socioeconomic growth.
The need to apply systems engineering concepts and methodologies in the field of socioeconomic engineering is discussed. A proposal for
a collaborative effort of systems engineering experts working with targeted professional bodies to initiate a paradigm shift toward increased
self-reliance is outlined.
|
| 3.5.2 |
Integrated Modular Avionics: A Challenge in Tools & Processes
P. Bonnet, Thales Avionics
For years, the avionics systems have been implemented via Line Replaceable Units (LRU) where each LRU is dedicated to one avionics function,
leading to huge avionics costs as more and more functions were embedded. In the late 80’s, came the idea of Integrated Modular Avionics (IMA)
where generic "platforms" would be shared by several "applications".
"First-generation" IMA programs demonstrated the industry capability to provide integrated "avionics suites" with
standardised computing resources, leading to significant improvements in terms of direct and indirect aircraft costs.
With the "Second-generation" of IMA program, the IMA platforms are now being procured separately from the hosted avionics applications,
introducing many challenges in terms of industrial organisation, design processes and tools.
Thales with Diehl Avionik Systeme, its 49% German subsidiary, has been awarded IMA platforms on the A380 and had to overcome with Airbus
these challenges to make this "2nd-generation" IMA a success.
The paper will review how Thales and Diehl are conducting these changes, and how System Engineering processes are impacted.
The paper will also give some hints and what is still to be made or could be envisioned as a "3rd-generation" IMA.
|
| 3.5.3 |
Trans-National Distributed Systems Engineering in A400M
S-O. Schulze, AIRBUS GmbH
This paper briefly gives an overview about the Systems Engineering application in a multi-national and multi-lingual project.
At least 6 nations, Airbus and other companies, are developing in one partnership this new military transport aircraft.
Based on the contractual, cost, quality and time constraints the engineers have to design the best possible solution for this aircraft.
The aim is to give an overview about the practical experience developing a system in an IPT (integrated project team),
a multi cultural environment, different historical experience and knowledge of each partner and to show the added value to work
with a defined and agreed view of developing a complex system.
|
Session 3 Track 6: Integrating SE & Project/Program Management
| 3.6.1 |
Experience in Teaching the Seamless Integration of Systems Engineering and Project Management
H. Mooz, K. Forsberg, Center for Systems Management
Project management and systems engineering are two inseparable disciplines. Yet they are very frequently taught separately
and they are usually implemented separately within organizations. PMI and INCOSE usually operate independently,
further accentuating the separateness. This leads to a lack of teamwork and collaboration and often causes competition and
tension among those that should be working and cooperating seamlessly. To overcome this undesired result in a
US Government Agency’s technology-intensive project environment, a training program has been in place for fifteen years
that serves as the basis for high-level project manager certification and presents the disciplines of project management
and systems engineering as a single inseparable process. The training has resulted in improved project performance and
reduced cost and schedule overruns. Over the years the content has continually been upgraded to remain at the state of the art
and to improve the effectiveness of the information transfer. This paper describes the motivation, concept, formulation,
execution, and management of this highly effective program.
|
| 3.6.2 |
Successful Integration of Systems Engineering and Program Management Processes
C.S. Witte, Harris Corporation
Since the inception of Systems Engineering as a discipline, Systems Engineers (SEs) have been providing technical leadership toward
the successful completion of projects. As the science of project management has evolved, SEs and Project Managers (PMs) have grown
more interdependent. In fact, there are many similarities in the skills required for Systems Engineers and Project Managers.
This paper will provide a summary of the shared skills between both SE and PM professionals. A description of the interaction between
SE and PM disciplines in various organizational structures will also be presented. A comparison will be made between PMI’s view of
product realization and the standard "Vee Diagram" process understood by most Systems Engineering professionals.
And lastly, this paper will conclude with a description of the project management process followed at the Harris Corporation.
Survey results will be presented illustrating the distribution of traditional project management functions between Project Managers,
Systems Engineers, and Project Engineers.
|
| 3.6.3 |
Towards a Shared Process for Product Design and Project Managment
C. Baron, LESIA, INSA, D. Esteve, LAAS, CNRS
This paper explores the interest to join system design and project management methods and tools. Our motivation is to prevent the
obvious incompatibilities between technical objectives and socio-economical requirements in the enterprise. What we recommend is
to work on a generic unique model based on the classical top down design steps, to which costs models and non-functional
requirements are associated. Project management thus appears as an activity of diagnosis and optimisation, allowing to choose
certain realisations between the different possible scenarios and to optimise the management by an allocation of tolerances,
which is calculated for each supplier on the base of a global objective. This analysis concludes on the interest of two complementary tools :
the evolutionary algorithms to arbitrate the scenarios, and the Monte-Carlo methods for the allocation of tolerances.
|
SESSION 4
Session 4 Track 1: UML Applications to SE
| 4.1.1 |
Benefits in Using Object-Oriented Methodology For Architecture Modeling
G. Osvalds, The Boeing Company
Currently enterprise and systems architecture models being developed by Systems Engineers to describe the stakeholders’ problem often
use the Structured/Functional Methodology while software designers usually use the Object-Oriented Methodology. Thus,
architectures represented with Functional Representation may not be fully implemented, as designed, by the software developers
who use Object-Oriented Representation. The systems engineer should consider the benefits in utilizing an Object-Oriented Methodology
in developing the architecture design. A benefit, in the use of the same representation, is the ability to create a concordant set of
engineering products that are traceable from the design to the system implementation. Another benefit is that the Object-Oriented
Methodology is that it closely matches the stakeholders’ view of the world which consists of objects that perform actions and
utilize information. Therefore the use of the Object-Oriented Methodology in the design and documentation of enterprise and
system architectures provides reusable design artifacts for the software developers.
|
| 4.1.2 |
Extending UML to Support a Systems Modeling Language
S. Friedenthal, Lockheed Martin Corporation
C. Kobryn, PivotPoint Technology Corp.
The International Council on Systems Engineering (INCOSE) and the Object Management Group (OMG) are collaborating on an initiative to
extend the Unified Modeling Language™ (UML™) to provide a general-purpose systems modeling language.
The language will support the specification, analysis, design, verification and validation of complex systems that include software-intensive,
information-intensive, and physical systems. To achieve this goal, the OMG issued a UML for Systems Engineering Request for Proposal
(UML for SE RFP) in March 2003. The modeling language that satisfies the requirements of this RFP will be a key enabler for transitioning
the practice of systems engineering from a document-centric to a model-centric approach.
This paper describes the technical approach and language features of the Systems Modeling Language (SysML),
which is being proposed in response to the UML for SE RFP.
|
Session 4 Track 2: Systems Engineering Patterns
| 4.2.1 |
A Pattern for Enacting Systems Engineering Reviews in Systems Development
S.M. Fohn, P Popick, International Business Machines Corporation
Over the last several decades, various software development models have been articulated and discussed in literature.
These models (stagewise, waterfall, spiral, iterative and incremental, etc.) have evolved in an effort to accommodate
project environments’ distinguishing characteristics: business volatility, organization and technical complexity,
validation and delivery strategies. A project must consider these characteristics in choosing an appropriate development method,
hence underlying development model. A project’s adoption of a given development method however,
often leaves the systems engineer with questions on how to integrate systems engineering planning and control,
specifically technical reviews, into the development and integration effort. A pattern is proposed that abstracts the problem of
applying systems engineering’s reviews across various development models to achieve the benefits of the systems engineering
technical reviews in conjunction with the benefits of a development model other than the waterfall model.
The pattern is demonstrated with the stagewise and the RUP iterative development model and the resulting benefits are described.
|
| 4.2.2 |
The Difference - On the Use of Pattern-Based Requirements
R. Kaffenberger, Marconi Communications GmbH
It is common knowledge that a complete and correct set of requirements is the key prerequisite for a successful development project.
But the size of the projects, their complexity, budget constraints, and short time to market prevent good requirements engineering.
An additional obstacle is human nature: People are not able to express their needs in a way that this information is sufficient as
foundation of a complete set of requirements. With the conventional requirements engineering methods, the problem of missing,
ambiguous, or misleading requirements can not be solved. This paper suggests the intensive use of patterns as the more successful
way to specify system requirements. In an object oriented environment patterns are found and applied much easier than in
an environment where the functional view prevails. Thus a shift to object oriented requirements engineering and systems engineering is required.
|
Session 4 Track 3: Managing Security
| 4.3.1 |
Security Engineering: Systems Engineering of Security Through the Adaptation and Application of Risk Management
D.P. Gilliam, M.S. Feather, California Institute of Technology, Jet Propulsion Lab
Information Technology (IT) Security Risk Management is a critical task in the organization, which must protect its resources and
data against the loss of confidentiality, integrity, and availability. As systems become more complex and diverse,
and more vulnerabilities are discovered while attacks from intrusions and malicious content increase,
it is becoming increasingly difficult to manage IT security. This paper describes an approach to address IT security risk
through risk management and mitigation in both the institution and in the project life cycle.
The application of risk management to security engineering is described. Support for this through application of a security risk algorithm
and a risk management tool for risk analysis is also discussed.
|
| 4.3.2 |
Systems Engineering Approach to Information Assurance
K. Taylor, C.D. Sloan University of Maryland University College
Today's security solutions for protecting telecommunications and information infrastructures are primarily defensive.
They are not commensurate with the increasingly sophisticated nature of the global cyberthreat, and likely ineffective in countering new,
dormant threats that could be a strategic surprise to organizational security. Defensive measures such as firewall and
antivirus software can only protect computer networks and systems against known signatures of malicious code.
To engineer pre-emptive capabilities and processes that discourage and repel attacks would require integration of key aspects of
security domain engineering into systems engineering practices. An integrated approach would promote the implementation of
security controls and processes as built-in features of future human/computer systems and networks,
rather than as separate solutions, thus enabling a more holistic and robust information assurance.
|
Session 4 Track 4: Systems Architecture Methodology and Frameworks
| 4.4.1 |
Concept of Operations Development Considerations for a Highly Networked System
T.E. Herald, Jr., Lockheed Martin - Maritime Systems & Sensors
D. Verma, Stevens Institute of Technology
Within the United States Department of Defense, the interest and focus on Network-Centric Systems (NCS) is increasing.
The US Navy defines network-centric operations as "military operations that exploit state-of-the-art information and networking technology
to integrate widely dispersed human decision makers, situational and targeting sensors, and forces and weapons into a highly adaptive,
comprehensive system to achieve unprecedented mission effectiveness." (Committee, 2000)
Therefore, the benefits of building a NCS appear to be obvious and desirable for providing greater information in order to
render higher quality decisions and provide greater overall system capability. However what is not so obvious is the priority order
of the incremental system benefits realized by the NCS. There is a need to identify the magnitude and order of the systems
(or system capabilities) that are to be integrated to provide the greatest impact on the NCS mission needs.
The importance of developing a clear Concept of Operations (ConOps) document has been acknowledged for many years
(since R. J. Lano’s seminal publication in 1980). The process traditionally involves a single Systems Engineer (or System Architect) responsible
for taking the needs statements from the involved stakeholders, and consolidating this tops-down information into a coherent ConOps document.
When the size of systems and the number of stakeholders were both small this "single person focal point%" was reasonable;
however, with NCSs this approach is no longer sufficient. The challenge is how to best formulate a NCS-level ConOps when the number of stakeholders
with uncompromising needs has increased drastically.
Since a new NCS is often made up of existing systems plus the development of new state-of-the-art and emerging-technology systems,
there is potential to provide an early system analysis from the bottoms-up and integrate with the stakeholder tops-down needs.
This source of information is the existing constituent system Concept of Operations (ConOps) documents. However, how can these be effectively used?
This paper focuses on a reasonable implementation in direct support of the NCS Systems Engineer with the tops-down and bottoms-up mapping for
effectively feeding the NCS-level ConOps document development process.
|
| 4.4.2 |
Net-Centric Dynamic System Model Architecture
Y. LaCerte, General Dynamics - Advanced Information Systems
Net-Centric weapon systems interoperate on the Global Information Grid to achieve information superiority. In a sensor-to-shooter scenario,
the chain of events that connect the initiation of a control event to its result is not within a closed space.
The chain may incorporate information gathering devices and weapons a thousand miles apart, or any of a myriad of devices in a more
local confederated environment. Net-Centric systems need to consider determinism not only on the control side, but the communications side as well.
This paper investigates a Net-Centric Dynamic System Model architecture in the context of interoperability.
|
Session 4 Track 5: Managing Organizational Complexity
| 4.5.1 |
The Capability Integration Framework: A New Way of Doing Enterprise Architecturebr>
J.H. Conklin, J.N. Martin, C.T. Robinson, J.W. Evans, J.J. Diehl, L.J. Doggrell, The Aerospace Corporation
The Capability Integration Framework was created to help Air Force Space Command leadership understand the relationships that existed within
their organization. By following a modeling process developed by The Aerospace Corporation, the architecture team was able to deliver
the first version of the tool after three months of work. This paper will briefly discuss the modeling process and will use the
Capability Integration Framework as an example for applying this process. Some features unique to this model will also be demonstrated.
|
| 4.5.2 |
Preparing the World for Complexity: A Systematic Approach
R.D. Klingler, C.M. Plowman, R. Soto, R.J. Turk, Idaho National Engineering & Environmental Laboratory
The increasing level of complexity in most aspects of today’s world requires that government, industry, and society, in general,
produce integrated systems and products more fully capable of addressing that complexity. Unfortunately, the high degree of fragmentation in our
current educational system does not adequately provide graduates with the knowledge and skills necessary to produce integrated systems.
This demand for integration has created professional opportunities in the way of new careers, such as systems engineering,
but has not yet driven the broader application of systems principles by other professionals. Even today’s interdisciplinary teams must possess
the ability to visualize the entire system they are working on prior to applying their individual skills toward developing and
producing integrated solutions.
This paper highlights proposed interventions at all educational levels (i.e., elementary, secondary, and college educational settings,
as well as in the workplace) to introduce systems thinking as a more desirable way of performing any professional activity.
In particular, the college freshman level has been selected to conduct an initial intervention to test this hypothesis.
Systems approaches and principles will be presented and discussed in a formal classroom setting between issuance and evaluation of
pre- and post-presentation questionnaire. It is expected that this intervention will result in increased knowledge of system principles and concepts,
and an increased understanding of how these principles can be applied by this target audience.
|
Session 4 Track 6: Applications of Other Disciplines/Processes to SE
| 4.6.1 |
Combining Heuristic Search, Visualization and Data Mining for Exploration of System Design Spaces
M.S. Feather, Jet Propulsion Laboratory, J. Kiper, S. Kalafat, Miami University
Finding a near-optimal solution to a complex design problem is challenging. On the one hand the problem space is too large and convoluted for
human comprehension, while on the other hand it is infeasible to elicit the entirety of design knowledge required for fully automatic problem solving.
We report on a practical application of information technology techniques to aid system engineers effectively explore large design spaces.
We make use of heuristic search, visualization and data mining, the combination of which we have implemented within a risk management tool in use at JPL
and NASA.
This approach is demonstrated on the planning for development of an advanced technology for spacecraft applications. In this context of risk-informed design,
numerous risk abatement options give rise to a huge space of potential design solutions. We show how our approach enhances the system engineers’
ability to explore this design space.
|
| 4.6.2 |
A Knowledge Management Approach to Change Management in Systems-of-Systems
D. Cropley, University of South Australia
When a complex entity comprises, for example, a set of individually complex, geographically distributed, evolving systems,
the question of how to manage change to such a system-of-systems takes great significance. Not only must change be managed
at the level of each component system, it must also be managed across the entire interrelated and interacting set.
The solution presented in this paper is based on research that treats a class of warships in the Royal Australian Navy (RAN),
along with the associated operational, production and support systems, as a system-of-systems (SoS) and examines the management of change
in this complex entity. The paper describes a Knowledge Management (KM) strategy that can be used to plan, manage,
coordinate and implement change across the entire lifecycle of the target system-of-systems and which may be generalisable to other systems-of-systems.
|
SESSION 5
Session 5 Track 1: Managing Requirements
| 5.1.1 |
From Stakeholder Values to Product Requirements: An Application of Quality Function Deployment Methods
S.I. Weiss, Stanford University
The identification of all stakeholders, as well as their values, has become a basis, often insufficiently achieved, for understanding,
prioritizing and realizing requirements for a product. Traditionally, these are gathered from a variety of sources and a widely used
method for organizing, evaluating and tracking customer needs translation to design information is Quality Function Deployment (QFD).
QFD is commonly understood as a matrix tool for collecting, organizing and prioritizing data for evaluation of requirements and
their translation to technical characteristics of a system or product. Since true requirements are derivatives of the values of
the many stakeholders associated with complex systems or products, a sequence of identifying stakeholders with their values and prioritization,
leading to the development of requirements, provides a logical path to product design characteristics. QFD provides a means that facilitates this.
The method described here has further value for data collection, reference and traceability since it is highly adaptable to
changes in stakeholders and values.
|
| 5.1.2 |
Requirement Architecture Framework (RAF)
J.Y. Lee, Y.W. Park, Ajou University
This paper describes a requirement architecture framework(RAF) which could be used during front end of requirement definition process.
The requirement definition process is a conceptual process. Up to now, several systems engineering standards are developed.
These standards describe what the systems engineering does, that is the "what to" not the "how to".
Some works are developed the "how to&%quot; of requirement definition process. This study is about the integration of process,
method and tool for front-end activity of requirement definition process. An architecture has the attribute of guiding system design
and evolution over time. An architecture framework is a structure of conclusive methodology, that is guiding system design and
evolution over time. The RAF, in this paper, is a requirement definition tool which was made for using appropriately to
implement the requirement definition process and method. The RAF is structured by 4 dimensions, which was 6W2H2V method,
requirement category, life cycle stakeholder and requirement definition process dimension. This paper also propose requirement quality metric,
that is, defect per hundred requirement (DPHR) and requirement baseline control guidelines using DPHR.
And this paper shows also the effectiveness of RAF using DPHR by an experiment.
|
| 5.1.3 |
Requirements Completeness
R.S. Carson, Boeing Integrated Defense Systems
E. Aslaken, R. Gonzales, G. Caple, P. Davies, R. Kohl, AEK Sahraoui
The INCOSE Requirements Working Group has attempted to define a process and methodology for producing a complete set of requirements.
We first carefully define the problem statement and terms. Various approaches to completeness are reviewed, and a formal process is
proposed to quantify completeness.
|
Session 5 Track 2: Managing SE Teaching/Education Programs
| 5.2.1 |
Can Systems Engineering be Taught at Undergraduate Level?
S. Goodlass, BAE SYSTEMS
Everyone knows that Systems Engineering is complicated and difficult. It takes a long time to become sufficiently experienced to
be a good practitioner and people need to make mistakes in order to learn from them. How successfully then,
can such a difficult topic be taught at undergraduate level? In the early 1990’s, BAE SYSTEMS engaged Loughborough University to
develop and deliver an undergraduate systems engineering programme and has recruited engineers from it since the first cohort graduated in 1997.
This paper describes how the programme was designed and developed and compares systems engineers graduating from this programme
with other engineers in BAE SYSTEMS.
|
| 5.2.2 |
An Innovative Partnership in Systems Engineering for Schools
S. Brown, BAE SYSTEMS
Must the teaching of Systems Engineering be restricted to a postgraduate level? Evidence from Loughborough University’s undergraduate course
has taught us that this is not the case. So why stop there? Can you teach systems engineering in schools – to children from 5 to 18 years?
Focussing mainly on the secondary level (11-18 years), this paper look at some of the issues, some of the UK-wide activities
and at BAE Systems’s own programme of working with schools to bring the basics of systems engineering to the workforce of the future.
|
| 5.2.3 |
Product and Process - Student Learning in an Undergraduate Systems Engineering Course
T. Ferris, University of South Australia
The University of South Australia program, Bachelor of Engineering (IT Option) contains a sequence of four courses in the field of Systems Engineering,
comprising 12.5% of the program. This paper describes the content and teaching processes used in the last course in this sequence,
scheduled for the undergraduate students in the final semester of their program. The paper discusses the evidence provided by
students of the learning that they have achieved through the course in the assignment assessment, weighted 40% of the course.
It is found that the learning about the practice of Systems Engineering developed by students is not correlated with the achievement
in the technical aspects of the project. The kinds of learning achieved are discussed in the paper.
|
Session 5 Track 3: SE in Research & Design
| 5.3.1 |
Adaptive Design Using System Representations
R. Dare, US Air Force, E. Rebentisch, E. Murman, MIT
Air Force weapon system development is a complex enterprise in which the stakeholders have differing and time-varying needs and constraints.
An uncertain environment of shifting budgets, evolving threats and rapid technology advances contributes to complexity.
This paper explores how complexity can be addressed through collaborative efforts to enhance program adaptability.
Case studies provide data on patterns of interaction during system design between the Air Force acquisition agency, operational users,
and the development contractor. The studies focus on a form of boundary object referred to as a "system representation" that facilitates
knowledge sharing across organizational boundaries, enhancing adaptability and enabling ongoing verification and validation of the emerging design.
As programs used system representations to provide higher levels of knowledge sharing, they were found to be more adaptable.
System representations were more effective at promoting adaptability when they portrayed the design with higher fidelity, providing system-level detail
and covering stakeholder emphasis areas.
|
| 5.3.2 |
Creativity in Systems Engineering
D.E. Warner, Lockheed Martin Mission Systems
A survey of the systems engineering literature reveals an interesting relationship between the artistic terms of 'art', 'originality', 'creativity',
and 'innovation'. An order and nesting of these terms is proposed, and their relationship to the systems engineering discipline is examined.
The specific focus is on how creativity is defined in the context of systems engineering, its importance to the discipline,
and how it is being used today in system architecting, the transition from research to development, design synthesis, alternatives in decision making,
emergence, and project management.
|
| 5.3.3 |
The Need for Observable States Affects the Make-Reuse-Buy Decision
T. Bahill, University of Arizona, R. Botta, B. Wuersch, BAE SYSTEMS
Today, systems are supposed to be designed so that they are better, faster and cheaper. The mantra for doing this seems to be the reuse of
available components. This paper presents a process to help select and reuse existing components in new system designs.
An important part of this process is identifying observable states.
|
Session 5 Track 4: Systems Architecture Methodology and Frameworks
| 5.4.1 |
The Use of Integrated Architectures to Support Agent Based Simulation: An Initial Investigation
A.W. Zinn, G. DeStefano, D. Jacques Air Force Institute of Technology
Architecture descriptions following the Department of Defense Architectural Framework (DoDAF) will be used to aid in the acquisition of
all major defense information systems. One of the primary purposes of these architectures is to help conduct military-worth analysis.
Recent work in operations analysis of information driven combat is showing that agent based simulation technology is needed to understand
the military value of Command, Control, Communications, Computers, Intelligence, and Reconnaissance (C4ISR) systems.
This paper investigates the utility of architecture descriptions based on the DoDAF to provide the needed data for agent based simulation.
This is accomplished by means of a case study where data from a DoD architecture is used in the combat model
System Effectiveness Analysis Simulation (SEAS). The research concludes that the DoDAF, if implemented properly, does provide the needed information.
A process for taking information from a DoDAF architecture and importing it into agent based simulation is proposed.
|
| 5.4.2 |
Architecting a Command and Control (C2) System
D.H. Cropley, University of South Australia
The C4ISR Architecture Framework (C4ISRAF) mandates architecture products that are needed to describe typical defense information environments
and hence entities such as a hypothetical future Command and Control (C2) Architecture. However, as is commonly understood,
the C4ISRAF does not describe a methodology for creating the architecture products. This paper seeks to redress this deficiency by
identifying a suitable methodology to create and evolve a C2 Architecture that maps to the C4ISRAF and its products.
The strong influence of human activity in the problem domain necessitates both a functionalist and an interpretive approach to system design.
This has been used to define an approach based on a multi-methodology. The paper describes the steps taken to identify appropriate candidates
for the multi-methodology and concludes that there are two leading candidate hybrid multi-methodologies: one that could be described as a soft mantle
with a hard systems core and one that follows a more traditional hard systems paradigm.
|
| 5.4.3 |
Architecting and Innovating
R.B. Campbell, Center for Innovation in Product Development
Innovating is essential to sustained industrial growth and profitability. But experience amply demonstrates how difficult innovation is,
especially for large companies. The synthesis of valued offerings by aligning customer needs with technology possibilities lies at
the heart of innovation. System architects working at the strategic level are ideally positioned, as a consequence of their experience and training,
to play a key and even a leadership role in enabling, energizing, and leading this synthesis. The scope of the architecting effort must include
the process architecture of the entire value chain as well as the more conventional product architecture to address all potential wellsprings of innovation.
This paper outlines an architecture-centric approach to innovation, based on the concept of the system platform architecture.
|
Session 5 Track 5: Managing Organizational Complexity
| 5.5.1 |
The Analysis and Evaluation of Customer Satisfaction and Service Management
A.J.C. Trappey, F-C. Hsu, National Tsing Hua University
C.V. Trappey, National Chiao Tung University
J. Kuo, C. L-J. Chao, T.T.H. Lu, Industrial Technology Research Institute
Adaptation of information technology in business applications enables enterprises to understand customer behaviors and use customer-related
knowledge to increase competitiveness, adjust product market position, and build customer loyalty. The Internet and computer telephony integrated
(CTI) applications, in particular, enhance the communication channels among members of extended enterprises (e.g., customers and suppliers).
Thus, Customer Relationship Management (CRM) has become a key focus of modern enterprise operations with the help of modern Internet and CTI techniques.
A company can achieve the customer-centric business model and the one-to-one marketing strategy by using contact center applications and
data mining methodologies. With the increasing number of communication channels, telephone-based contact centers are no longer sufficient
to build and maintain good customer relations. Multi-channel contact centers that integrate phone, fax, e-mail, web, and PDAs enable managers to
respond to customer queries, complaints and service requests. An improved CRM program not only provides greater access but also provides
the means to analyze customer interaction data. Corporatios gain benefits such as enhanced customer loyalty and brand enhancement by
transforming data collected through multiple communication channels into meaningful knowledge. This research uses a multi-channel contact center (CC)
as a basis to model customer interaction processes, define key performance indicators (KPIs) of CC, and develop CC evaluation methods to
measure customer satisfaction and service quality of a contact center based on the set KPIs.
|
| 5.5.2 |
Application of SSM and Architecture Frameworks as a Method of Enquiry in Organisational Behaviour
L. Vencel, Vcorp Consulting Pty Ltd, E. Sweetman, Defence Science Technology Organisation
Systems engineering is traditionally used as a method of design. In this study, it has been used as a method of enquiry into organisational behaviour
in a sociotechnical system. A mix of methodologies from both the functionalist and interpretative social paradigms has been adopted.
The methodology mix comprises Checkland’s Soft Systems Methodology (SSM) and Structured Analysis and Design Techniques. This hybrid methodology
allowed the use of rich pictures and architectural models to analyse organisational behaviour from two representative views:
the human activity system and the operational architecture.
The paper relates the goals of developing an understanding of the current organisational operational behaviour and then discusses the use of
methodological pluralism, its rationale and the use of a revised Total Systems Intervention (TSI) model by Jackson based on contemporary
critical systems thinking as a checklist for pluralism. The hybrid methodology using both soft and hard methods employed rich pictures and
Defence Architecture Framework (DAF) compliant architecture models (AS-IS views) to enquire into organisational behaviour.
The DAF models represented both the perceived and actual state of operations. Comparison of the DAF models correlated with the SSM derived
rich pictures and issues log were used to develop an understanding of the organisational behaviour as well as produce an updated
operational architecture. Recommendations for change were made to senior management. We finish the paper with a 12-point lessons learnt
discussion of our experiences in doing this study. We conclude that the use of a pluralist systems engineering approach as
a method of enquiry into sociotechnical organisational behaviour can provide a richer understanding of operational behaviour
as it complements the human activity systems view with the operational architecture views. The pluralist approach is methodologically sound
and Jackson’s modified TSI provides an evaluation checklist.
|
| 5.5.3 |
Systems Engineering Mangement
A. Smith, M. Emes, D. Cowper, University College London
Organizations may have sophisticated and detailed systems engineering process models yet struggle to implement them effectively in the face of
conflicting internal priorities, legacy practices and slowly changing cultures.
Taking experiences from a number of sources this paper identifies a range of current systems engineering issues and suggests that it is
the interface of systems engineering with other business activities that is a cause of many implementation problems.
By taking a systems view of the business (a systems-make-systems approach), one can use systems engineering principles to address these problems.
A broader remit for Systems Engineering Management is recommended.
|
Session 5 Track 6: Integrating SE & Project/Program Management
| 5.6.1 |
The Application of Complexity Theory in the Development of Large-scale ICT Systems
L.J. du Preez, ABSA Bank, A.J. Smith, University of Pretoria
The elements of complexity theory (chaos theory) found application in many diverse disciplines, including the social and management sciences.
It became a means to address some of the vexing problems that could not be solved through direct causal analysis.
Complexity theory contradicts many of the existing views of conventional management and requires a cognitive change from a rational
Newtonian paradigm to a non-linear, dynamic and complex systems paradigm. This paper unites the principles of complexity theory with
Information and Communications Technology (ICT) project management by considering any large-scale ICT development project as a non-linear,
dynamic and complex system within the context of a larger complex environment. The interactions between the different complex dimensions of
the project state space are discussed. ICT project- and risk management are described within the context of the elements of complexity theory
such as sensitive variables, attractors and fractals.
|
| 5.6.2 |
User Requirements for a Technical Risk Assessment Technique
M.G.H. Bijl, TNT Express, AMS DHO, R.J. Hamann, Delft University of Technology
This paper addresses the results of a study identifying the user requirements for a technical risk assessment technique, specifically for use by
small to medium sized enterprises active in space engineering. By means of a questionnaire Systems Engineers and Project Managers of four companies
where interviewed in order to collect data on the companies’ business, the experience of the personnel with risk management, constraints on the
technique’s implementation and the content of the technique.
Major result of the study is that the view on risk and the factors composing it varies widely and that a technique or tool will likely not
be applied if it does not agree with the view of the assessor. As a consequence a technique must enable the modelling of the assessor’s perception
of the structure of the risk (that is: the factors determining the probability of occurrence of a risk and their mutual interaction).
A basic set of risk models (Risk Spaces) is proposed and the constraints on technique and tool are summarized.
The paper presents the main elements of the User Requirements for a technical risk assessment technique for the specific target group:
they address both a technique and tool to construct the risk model (Model Tool Kit) and the risk assessment technique and tool itself.
|
| 5.6.3 |
Zoned Analysis: A Middle-Out Method to Join the Top-Down and Bottom-Up Approaches During Mission Analysis
L. Zirker, D. Hamelin, Idaho National Engineering and Environmental Laboratory
Zoned analysis (ZA) is a decomposition methodology, which ultimately evolves into a graphical "big picture" of a project.
This methodology maps the "journey" a systems engineer uses during the mission analysis phase to facilitate collaboration of team members,
enhance management understanding of the project, show team members their responsibilities, link requirements to deliverables,
and aid in the gap analysis between what is wanted and what is tasked. A ZA appears as a bull’s-eye or target with partitioned
pie-shaped sections emanating from the center circle to outer circles, or zones. The title of the project or program is placed in the center zone.
Subsequent partitioned zones facilitate the decomposition hierarchy of the project, with the outer-most zones or elements evolving as
terminal elements or deliverables. This paper show how a ZA was used to flesh out the details in between top-down and bottom-up
approaches during the mission analysis phase.
|
SESSION 6
Session 6 Track 1: Managing Requirements
| 6.1.1 |
Compliance Mapping of Industry Standards to the Rockwell Collins' Technical Consistent Process Using a Requirements Database
A.J. Thompson, R.A. Bennett, J. Povacz, Rockwell Collins Inc.
The growth in quantity, variety, and merging of industry standards, process capability models, regulatory requirements, and customer request has
inundated many Original Equipment Manufactures’ (OEMs) process groups. Customer requests for objective evidence corroborating capability and
maturity of documented internal design and development processes are necessary to demonstrate compliance to these source requirements.
This paper discusses Rockwell Collins’ approach to manage these changes using a requirements database to assist projects in tailoring
Enterprise standard design and development processes and processes assets to meet the customer requirements.
|
| 6.1.2 |
Interactive Metamodel-Compliance Checking of Requirements in a Semiformal Representation
H. Kaindl, Vienna Univ of Technology, S. Kramer, Technische Univ München
M. Hailing, V. Harput, Siemens AG Austria
Checking requirements is highly desirable but hard to achieve in practice, where only word processors are used in most projects.
While in this case reviews are more or less the only means, formal representations allow for a variety of automated checks.
Unfortunately, formal representations of requirements are rarely available in real-world projects.
Semiformal representations are easier to obtain and still offer some possibilities for automated checks. Based on an object-oriented
hypertext representation, we present an implemented approach for compliance checks against a metamodel, which resembles some kind of
completeness checking. In addition to allowing checks to be invoked by a human user of the tool, the checks are periodically and
automatically invoked by taking into account the already existing information on the requirements. In summary, we propose an interactive
approach with shared initiative between the tool and its user for compliance checking of requirements against a metamodel in a semiformal representation.
|
| 6.1.3 |
A Requirements Assessment Architecture that Combines Natural Language Parsing and Artificial Intelligence
W. Scott, S. Cook, University of South Australia
While the need for good requirements is well understood, and there many sources that describe what constitutes a set of good requirements,
poor requirements continue to plague projects. In recent years tools have become available to assist in requirements management and
their rapid adoption throughout industry attests to their efficacy in data handling and display. Contemporary requirements engineering tools,
however, provide few assessment capabilities and no semantic processing. This paper addresses that deficiency while building on the capability
of existing tools. The paper opens by describing the philosophy we used to tackle the problem: emulate human reasoning;
use several tiers of analysis; parse the requirement against a purpose-designed a context-free grammar;
and employ case-based reasoning to assess both individual requirements and the total requirements set.
The paper concludes with descriptions of the architecture of a tool termed REWARD, its operational concept, and its implementation.
|
Session 6 Track 2: Researching SE Methodologies & Approaches in SE Research
| 6.2.1 |
Systems Engineering Principles Revisited
M-D. Han, Korea Third Military Academy
Making a short list of principles and repeatedly using them to various systems engineering problems from time to time may help us to handle the
complexity and changes of the systems engineering environment. KCOSE has been established in KOREA in February 2002. Just as INCOSE tried to
set up some principles on SE right after they established the council, KCOSE is now trying to set up its own SE principles so that its members
can share a common perspective about what is SE, what is the value of SE, what is the core of the SE processes, etc. Here I report the first draft
of KCOSE SE Principles with how we approached to this.
|
| 6.2.2 |
A Program of Research into Systems Engineering
J. Kasser, S.C. Cook, University of South Australia
This paper provides an overview of a number of research areas that include investigating the nature of systems engineering and its underlying concepts,
defining the properties of object-oriented requirements, producing prototype object-oriented tools for systems engineering,
and applying of systems engineering to various domains.
|
| 6.2.3 |
Understanding the Value of Systems Engineering
E. Honour, Honourcode, Inc.br>
The practices of systems engineering are believed to have high value in the development of complex systems. Heuristic wisdom is that an increase
in the quantity and quality of systems engineering (SE) can reduce project schedule while increasing product quality. This paper explores recent
theoretical and statistical information concerning this heuristic value of SE. It explores the underlying theoretical relationships among
project cost and schedule, technical value, technical size, technical complexity, and technical quality, summarizing prior work by the author.
It then identifies and summarizes six prior statistical studies with conclusions that relate to the value of SE. Finally, the paper provides
final results of a statistical study by the INCOSE Systems Engineering Center of Excellence (SECOE) that presents evident correlations
supporting the heuristics. The results indicate that optimal SE effort is approximately 15-20% of the total project effort.
|
Session 6 Track 3: SE in Research %amp; Design
| 6.3.1 |
Decision Oriented Systems Engineering (DOSE) - A Structured, Systematic Approach to Function Allocation
M.E. Buckley, V. Stammnitz, Syntek Technologies, Inc.
Perhaps the most important reason Systems Engineering exists as a discipline lies in the observation that complex systems cannot be treated
merely as an assemblage of so many building blocks. Systems Engineering employs techniques and practices that attempt to consider the whole
throughout the design process. Systems Engineering offers quite an assortment of processes, and tools devices to capture, describe, derive,
and otherwise characterize various aspects of systems under design or analysis. There are many evolving Systems Engineering processes and practices,
including processes in which the object-oriented paradigm dominates. Unfortunately, the set of available processes, models,
and tools remains weakest where they are needed the most: where decision tradeoffs are most negotiable, where "requirements" are not yet
firmly established, where the use of legacy systems can have the greatest impact, and where the (projected) life cycle impacts of such
decisions are greatest.
This paper describes a new system development practice named Decision Oriented Systems Engineering (DOSE). If consistently and diligently applied
in tandem with other more conventional practices, DOSE provides a solid Systems Engineering "hook" to the application of Human Systems
Integration principles and offers considerable promise in simplifying the design of even the most complex systems involving teams working with
mixes of new, evolving, and legacy systems.
|
| 6.3.2 |
Goal/Strategy Maps: Methods, Techniques and Tools to Specify Requirements in Different Evoluntionary Concepts
C. Salinesi, A. Etien, I. Zoukar, CRI, Université Paris
This paper reports the status of a research program that deals with the issues specifically raised by Requirements Engineering (RE) in
the context of Information System (IS) evolution projects. This research program was triggered by the ‘Chaos’ report by the Standish Group,
which explains that the lack of adequate RE methods techniques and tools is a major cause of failure of IS projects, and on the other hand,
by Bohem’s report, which says that most of IS projects are set in an evolutionary context rather than for developing new IS.
Our goal was three-fold: (i) to identify the methodological frameworks for doing RE in IS evolution projects, (ii) to build
adequate modeling techniq | |
The INCOSE 2004 INTERNATIONAL SYMPOSIUM TECHNICAL PAPERS ABSTRACTS :