|
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 techniques that match the need of these frameworks, and (iii) to propose adequate methods and tools to deal
with IS evolution requirements. This paper reports on each of these aspects.
|
| 6.3.3 |
A PS Covering Functional Architecture Support in SEDRES Developed Drafts of AP-233
E. Herzog, Syntell AB
This paper takes a data exchange perspective on the multitude of methods proposed for capture of system functional architecture.
The particular focus of the paper is the different approaches proposed for representing the control flow view of a model.
We show that an extended Petri-net notation can be used to capture control flow for methods like FFBD, behaviour diagram and also UML activity diagrams.
An example is used to illustrate how the SEDRES developed drafts of AP-233 can represent FFBD control flow. The paper also contains a general discussion
on AP-233 and the underlying non-functional requirements for a data exchange standard.
|
Session 6 Track 4: Systems Architecture Methodology and Frameworks
| 6.4.1 |
Creating Flexible Architectures for Systems Engineering
M. Hause, F. Thom, Artisan Software Tools
Systems Engineers have been modeling systems since the inception of the discipline. Reasons for modeling systems include among others:
definition of the work to be done (requirements), allocation of responsibilities, documentation of the completed system, and communication
with the various disciplines who will create, operate, and maintain the system. UML (the Unified Modeling Language) has recently been used
by Systems Engineers to model systems. Many papers and articles have been written on various aspects of systems modeling with UML,
most especially Use Cases, but little attention has been paid to system partitioning. Papers that address system partitioning do so with
a "one size fits all" philosophy, by mandating a proscriptive structure that does not address the true needs of a particular
system’s development. Unfortunately, a badly partitioned system can be a serious handicap to the development of a system.
The drivers for system partitioning include: process, product, team makeup, areas of interest, standards, physical boundaries of the system,
legacy and COTS components, coupling and cohesion. A proper approach can also help in the establishment of a component based development approach,
leading to reuse of requirements, design, test, and implementation artifacts. This paper will discuss these issues and illustrate their use
by 4 case studies drawn on experience in consultation. Finally, it will give advice on lessons learned.
|
| 6.4.2 |
Concept of Application of Systems Engineering for the Component-Based Planning of Manufacturing Plants in
Non-Hierarchical Regional Production Networks
P. Näser, Chemnitz University of Technology
Manufacturing plants in non-hierarchical regional production networks are complex systems whose structures are characterized by high dynamics.
The Systems Engineering approach is suitable to analyze manufacturing plants in their complexity and to systematically support planning execution.
|
| 6.4.3 |
Ontology-Enabled Validation of System Structure
V. Mayank, N. Kositsyna, M. Austin, Institute for Systems Research
This paper describes a vision for team-based synthesis of engineering systems, enhanced by technologies for ontology-based computing,
cast in a Semantic Web framework. As a first step, in this paper we describe an ontology-enabled procedure for validation of system architectures.
We apply the procedure to the validation of connectivity relationships in a home theatre system.
|
Session 6 Track 5: Managing Organizational Complexity
| 6.5.1 |
Attributes of a Managerial and Organizational Infrastructure to Enable Safe Systems
S. Jackson, S.D. Hann, The Boeing Company
Human-intensive systems have become the subject of systems engineering studies in recent years. This concept can be used to define the organizational
and managerial infrastructure that develops, maintains and operates complex systems subject to catastrophic failure. For a program to be effective,
it must exist within this infrastructure that contains specific attributes that will enable it to meet its objectives.
If it does not, even the most well planned program will experience shortfalls, and there are multiple examples of that occurring.
This paper presents the attributes’ observable features and shows how these attributes can be confidently applied to any organizational
and managerial infrastructure. While these attributes are not a guarantee that a program will be effective, they provide the means to assure
that any program will have an opportunity to perform at its best without being compromised by an inappropriate infrastructure.
Case studies are cited and correlated to specific attributes, which, if applied, would have mitigated the probability of a major catastrophe.
|
| 6.5.2 |
Concepts Pertinent to the Future of INCOSE
J. Ring, Innovation Management
INCOSE has the opportunity to emerge as the lead catalyst for evolving both SE practitioners and practices. The purpose of this paper is to point out
key concepts for future versions of INCOSE that will enable such opportunity. This paper presents the envisioning phase of a system design by
describing some of the options for INCOSE effectiveness thus its content, structure and behavior. Envisioning what INCOSE could be is a valuable step
in sorting out what INCOSE should be. If properly considered, these options will serve to preclude blind spots or misassumptions when
subsequent analysis is performed and decisions are taken. Uncertainties abound thus a broad span of alternatives is addressed.
|
| 6.5.3 |
The Zachman Framework Populated with Baseball Models
T. Bahill, University of Arizona, R. Botta, BAE SYSTEMS
There are guidelines for making good models. Amongst these are frameworks, which help organizations develop integrated models of their businesses.
Frameworks help people understand organizations and systems. The Zachman framework for enterprise architecture is a matrix (or schema),
where the six rows represent different perspectives of the organization and the six columns illustrate the items, or models, viewed from each perspective.
In this paper, a Zachman framework is populated with models for Baseball. These models should be easy to understand without a steep learning curve.
Most of the cells are filled with quantitative simulatable models that have been published in peer reviewed journal papers.
The other cells are filled with simple thought models. Jacques Barzun said, "Whoever wants to know the heart and mind of America had better
learn baseball, the rules and realities of the game." From the perspective of the Zachman framework, the way to learn Baseball is to define
the models within the framework, as presented in this paper.
|
Session 6 Track 6: Applications of Other Disciplines/Processes to SE
| 6.6.1 |
Adapting Systems Engineering for Software-Intensive Systems
S. Sheard, Software Productivity Consortium
The nature of systems engineering has changed in the last quarter century because of the increasing presence of software in systems.
This paper describes the adaptations that systems engi¬neers should make to their skills and approaches in order to engineer software-intensive
systems better, and the places where systems engineers need to reinforce what continues to be useful about traditional systems engineering.
Systems engineers should continue to contribute "systems engineering specialist" skills, help the project manager coordinate
multidisciplinary activities that ensure a well-engineered system, and continuously learn about software. Finally, the systems engineer
might need to advocate for good systems engineering.
|
| 6.6.2 |
Integrating Open Source
A. Wind, University of Maryland University College
Open source projects is one category of self-contained software components, that should be considered for integration into software intensive system.
Benefits and risks, as well as other issues in selection, adaption, maintenance and support of such component are discussed.
|
| 6.6.3 |
Lessons Learned from Implementing Configuration Management Within Electrics/Electronics Development of an Automotive OEM
A. Schulz, 3D Systems Engineering GmbH, E. Knippel, BMW Group
In the past decade the automotive domain has encountered significant changes within its competitive environment. Automotive OEMs are forced to offer
an increased number of variant models, to satisfy individual customer needs as well as constantly introduce innovative features within their products.
Electrical/electronic systems play a major role enabling OEMs to address these needs. Development processes for electrical/electronic systems are
moving into the focus of automotive companies. However current development approaches for these type of systems within automotive industry are
only partially able to cope with the mentioned challenges and yield the necessary, high-quality systems. Thus automotive OEMs started to
restructure their development approaches for electrical/electronic systems and introduce Systems Engineering.
This paper is illustrating lessons learned from implementing configuration management within electrical/electronic development as part of
an major initiative at a German OEM to introduce Systems Engineering. The initiative is still on its way, therefore the lessons learned
are only part of the truth. The paper will start by highlighting the current situation of the automotive industry and point out the
future role of electrical/electronic systems for achieving competitive advantage. Based on this background the need for Systems Engineering,
especially within electrical/electronic development will be discussed. Configuration management as a part of Systems Engineering processes
will be described in general and in its application in an automotive environment. The specifics of configuration management within
Electrical/electronic development of an automotive OEM will be highlighted and discussed. Afterwards the paper discusses lessons learned
during conception and implementation of the configuration management building blocks into the OEMs organization. Key success factors for
introducing configuration management as part of a Systems Engineering initiative into an existing process and organizational landscape are then
derived from the lessons learned.
|
SESSION 7
Session 7 Track 1: Managing Requirements
| 7.1.1 |
Assessing the Impact of Requirements Volatility on the SE Process Using Bayesian Analysis
M. Russell, Anteon Corporation
There are many factors that affect the level of requirements volatility a system experiences over its lifecycle. Improper requirements generation,
undocumented user expectations, conflicting design decisions, and anticipated / unanticipated world states are representative of these volatility factors.
Combined, these volatility factors adversely affect successful system development. This paper proposes that a Bayesian Network can be used to
support reasonable judgments concerning the most likely sources and types of requirements volatility a developing system will experience prior
to starting development; and by doing so it is possible to predict the level of requirements volatility the system will experience over its lifecycle.
This assessment offers valuable insight to the system’s developers, particularly by providing a starting point for risk mitigation planning and execution.
|
| 7.1.2 |
System Requirement Development Process From Operational Concept and the Application Case-Study of ATACMS
Y.C. Choi, Y.W. Park, J.Y. Lee, C.K. Cho, J.D. Jang, Ajou University
J.R. Lee, Agency for Defense Development
This paper describes system technical requirement development process from operational concept using computer-aided Systems Engineering tool
(CASysE Tool-CORE). The technical requirements of the army tactical missile system (ATACMS) are developed by the process as a case-study.
The scope of the work is context analysis and requirement definition process. The proposed process is as follows. At first,
an integrated architecture could be developed from the operational concept. From the integrated architecture,
a capability needs which include KPPs, is generated. And the capability needs expanded according to the Mil-Std-961D format.
Lastly, a system technical requirement could be generated automatically from the CASysE Tool-CORE.
|
| 7.1.3 |
Using a Requirements Management Tool in Technical Requirements Negotiations
R.S. Dale, MBDA
This paper records the experiences of tracking the technical requirements for a missile system during the contract negotiation phase.
Initially WORD documents were used to record the requirements but, because of their complexity and the frequency of change,
these were abandoned in favour of using a Requirements Management tool. The paper tells the story as it was and then comments on this using
the wonders of hindsight.
Whilst the process worked well on this particular contract, it is recognised that contract negotiations can take a wide variety of forms
from formal multi-billion dollar contracts to strawman discussions for in-house projects. I believe, however, that the underlying problems
and approach to combatting them are sufficiently general to be applied universally. This paper highlights 10 tips as encouragement to
anyone contemplating facing such negotiations.
|
Session 7 Track 2: Researching SE Methodologies & Approaches in SE Research
| 7.2.1 |
Issues for Systems Engineering Research
A.E.K. Sahraoui, LAAS-CNRS and Toulouse University
D.M. Buede, Innovative Decisions, Inc., A.P. Sage, George Mason University
As a professional activity, and as an intellectual activity, systems engineering (SE) has strong links to such associated disciplines as decision analysis,
operation research, project management, quality management, and systems design. When focussing on systems engineering research,
we should distinguish between subjects that are of SE essence and others that more closely correspond to those that are more relevant
for related disciplines. In this paper, we propose selected research topics that are believed central to progress and growth in the application of SE.
|
| 7.2.2 |
On Methodology and System Framework for Knowledge Management in Allied System Engineering
Y-M. Chen, Y-J. Chen, National Cheng Kung University
J-Y. Kuo, Industrial Technology Research Institute; C.-B Wang, Nan-Hua University
C.T. Ho, National Kaohsiung University of Applied Sciences
This paper presents a systematic approach to development of a methodology and a system framework for knowledge management to support allied
system engineering. The approach of this research has laid-down four phases: allied system engineering characterization, knowledge identification,
analysis and modeling, KM strategy and methodology development, and system development. The methodology consists of a rationale behind the methodology,
a life cycle model for knowledge management, and a distributed knowledge management framework. Based on the proposed methodology,
a knowledge management system framework is developed using component technology. Besides providing functions for knowledge management and sharing,
the system possesses properties to meet the hierarchical, distributed, flexible and dynamic-configurable characteristics of allied system engineering.
|
| 7.2.3 |
Too Hard, Too Soft, Just Right...Goldilocks and Three Research Paradigms in SE
D.H. Cropley, M.B. Harris, University of South Australia
This paper examines the spectrum of methodologies that can be utilized in research in general. The two primary categories, quantitative and qualitative,
traditionally find use in particular discipline areas. This paper will examine the characteristics of common quantitative and qualitative methodologies
and discuss how these can be applied to research in systems engineering. The result is a wide choice of methodologies covering both the functionalist
(hard) and interpretive (soft) paradigms. The broad focus of systems engineering, covering both hard (technical) and soft (socio-technical) approaches,
will be shown to benefit from a broad appreciation of the full range of research methods. The paper discusses the predisposition to quantitative
methods that dominates engineering thinking and argues for the inclusion of qualitative research methods in the toolkit of systems engineering researchers.
|
Session 7 Track 3: SE in Research & Design
| 7.3.1 |
Enabling the Researcher: Applying Systems Engineering to Research
F. Bulca, MDS Sciex
Methodologies utilized in research and product development have little in common. While the former thrives on freethinking and innovative creation,
the latter is more dependent on a structured process. A culture shift is required from a purely knowledge-driven academic environment to a
commercial research environment that is more sensitive to budget and schedule constraints. In spite of these differences, systems engineering practices
may be applied to research, helping the teams to produce favourable results.
This paper presents a case study related to the research phase of a commercial product development project in the biotechnology sector.
The challenges in the research phase of the commercial project were handled through standard systems engineering practices, with new interpretations
of established methodologies. Application of systems engineering practices significantly improved the rate of progress, produced a high level
of stakeholder satisfaction and improved confidence in the results, thus indicating that systems engineering methodologies have a valid place
in the research realm.
|
| 7.3.2 |
Optimization of Research and Development Investment Strategies
K. Gormley, The MITRE Corporation, J.C. Fishenden, The Aerospace Corporation
W. Scherer, University of Virginia
An enterprise must make up-front investments in applied research and development (R&D) to mature technologies to a point where they can be
successfully deployed. These decisions are based on expected return from the investment and the cost, schedule and technical risks facing each
R&D project. Periodically, the decisions are revisited to see if changes in project performance and cost/schedule/risk estimates warrant
a change in project funding. Common approaches to this problem involve either Monte Carlo simulation of outcomes for a decision policy,
or optimization of decision variables based on some objective. This paper outlines an approach to R&D project selection where both simulation
and optimization are used to determine an investment strategy, given project interdependencies and uncertainties in utility, cost, schedule
and technical performance. The problem is formulated as a discrete sequential stochastic decision problem and uses heuristics to narrow the
solution space and find a reasonable (though non-optimal) solution.
|
| 7.3.3 |
The Applications of Systems Engineering on the Development of RFID in e-Logistic Service
T.-J. Wang, Y. J. Tsen, L. Chang, Industrial Technology Research Institute
Current paper will apply system engineering to Radio Frequency Identification (RFID) system that is developed for the purpose to improve
Taiwanese logistic industry competitiveness. Based on the development strategy for systems engineering in the e-environment,
the production line and warehouse management e-logistic RFID system program integrate both domain knowledge and systems engineering.
The methodologies, tools, procedures, templates and management system of systems engineering have been applied in this program.
Using systems engineering technology, such as requirement analysis, risk management and others will help to solve the complex and
changing environment of present logistic service industry in Taiwan.
|
Session 7 Track 4: Systems Architecture Methodology and Frameworks
| 7.4.1 |
An Architecture Description Language for Developing Automotive ECU-Software
M. Weber, M-O. Reiser, T. Wierczoch, DaimlerChrysler AG, U. Freund, ETAS
O. Gurrieri, LORIA, J. Kuster, University of Paderborn
H. Lonn, Volvo Technology Corporation, J. Migge, PSA Peugeot Citroën
The significance of embedded software systems in the automotive domain has increased dramatically during the last ten years. In contrast,
today’s development methods and tools applied in the automotive industry are limited in many ways. They are each restricted to certain
stages of development and therefore several approaches need to be used simultaneously, they are not interoperable and most of them are not
tailored to the specific needs of the automotive domain. In this paper we present an Architecture Description Language called EAST ADL
that seeks to capture all information needed during development, from early analysis to implementation and evolution and meets
specific automotive requirements such as support for automatic code generation in the context of common automotive hardware.
|
| 7.4.2 |
Europe's First System of Systems
P.J. Brown, Systems Engineering Associates, Inc.
Systems thinking is as old as civilization. The question is can today’s systems engineers benefit from examining the accomplishments of
early system builders? This thought is examined in the context of roman engineering achievements.
The birth of the Roman republic around 500 B.C. led to the building of an unprecedented array of remarkable systems. The needs of the republic,
followed by those of the empire, produced important advances in building construction, water supply, mining and the building of bridges,
roads, harbors, ships. Many complex systems such as the aqueducts supplying Rome’s water were created.
This paper postulates that the Romans developed Europe’s first system of systems. The backbone of the system, a network of roads radiating out from Rome,
began as a strategic initiative to maintain government control throughout the empire. Over time, this super system evolved into the means for
Romanizing the many different cultures dragged into Rome’s dominion. The resulting cultural harmonization left a lasting imprint on the world.
|
| 7.4.3 |
Inside-Out Systems Architecting: An Approach to Architecting the NASA Orbital Space Plane
K.E. Post, The Boeing Company - NASA Systems, C. Dagli, University of Missouri – Rolla
NASA has published the Level One requirements for the Orbital Space Plane development. Those requirements leave open opportunities for
creative development of a spacecraft that not only will provide the world with efficient travel to and from low-earth orbit,
but also for crew rescue capability from the International Space Station. The success of the Orbital Space Plane development phase will
depend strongly on the ability of competing contractors to establish criteria for gathering the needs of the stakeholders and develop models
which are technically achievable, have acceptable risks, have acceptable costs, while adequately meeting the NASA needs.
This paper proposes a hypothesis for architecting the NASA Orbital Space Plane. Beginning with the level one system requirements,
this approach defines a "system of systems%" approach that moves from the "inside-out" in an iterative fashion.
This process allows the system architect to understand the out-lying systems and when/where the architecting process should stop.
Systems are inherently boundless and knowing also where are the client’s core needs versus what are the "desirements".
Fundamentally, both the System Life Cycle functions (process architecting) and the System Functions (product architecting) need to be
addressed in this way and in an integrated fashion. Each system level would address both the System Life-Cycle Function as well as the System Functions.
|
Session 7 Track 5: Research/Test Issues
| 7.5.1 |
Recommendations for Automated Test Requirements Management
J. Houser, Hamilton Sundstrand
In the aerospace community, requirements data has a way of living beyond the end of product validation when it might be expected that it has fulfilled
its purpose. Not only are these requirements then used to develop test strategies and acceptance limits for the production line,
but certain aerospace standards and product support agreements demand a transmittal of test requirements to the airlines and their representatives.
The management of requirements data as it progresses from the interface control document, to test equipment engineering and ultimately to the
airframer's customer is explored. Specifically, a set of recommendations for a tool to support production test requirement management is proposed.
|
| 7.5.2 |
Testing a Requirements Pattern Language Through Reverse Engineering
P. Merrick, P. Barrow, University of East Anglia
This paper looks at a case study to reverse engineer an IT system that supports the Health and Safety Executive in making planning recommendations
with respect to hazardous installations. It compares a Use Case model created from a requirements specification with a Use Case model derived
from an inspection of the built system. The objective is to discover how accurately the final system could be predicted using a series of
requirements patterns. Through the application of requirements patterns, it was possible to predict the functionality delivered to a high degree,
which suggests this is a useful contribution to the prediction of functionality and thereby to system sizing. This work is part of a
bigger project for the Health and Safety Executive investigating improvements to system sizing/effort estimation and its impact on the
management of complexity.
|
| 7.5.3 |
| Testing Industrial Embedded Systems - An Overview
M. Prins, Research Fellow
Industrial systems are becoming highly dependent on software modules. This results in a continuous increase of both development & test effort
and maintenance & upgrading effort of innovative products. While on one hand competitiveness requires an as early as possible rollout
of new developed products the increasing complexity tends to lengthen the testing trajectory and seriously threatens the quality of the
delivered products. To limit this trend of increasing cost, time, and team size, research is required that targets on improving development
and test methodologies, processes, and supporting tools.
Based on experiences in the semiconductor industry - in particular the lithography segment of this industry - this paper explores factors
that should be taken into account when selecting a test strategy. In the paper, we discuss the major factors contributing to the complexity
of complex system integration. In particular we will consider the problem of testing subsystem and system behavior during several stages of integration.
We discuss several contributing factors to the test problem: the need to deliver in time, technology, and testing knowledge.
Session 7 Track 6: Applications of Other Disciplines/Processes to SE
| 7.6.1 |
Applying the Object Oriented Systems Engineering Method to A Simple Hardware System
J.C. Hsu, J. McDonough, The Boeing Company
The application of Object-Oriented Systems Engineering Method (OOSEM) to hardware systems has been controversial since it was initiated.
This paper will explore its applicability and its effectiveness relative to traditional systems engineering approach.
A simple Mouse Trap hardware system was used for the case study. The System Requirements can be derived from the System Diagram.
The Activity Diagram can be used to visualize the workflow scenario. The Sequence Diagram can provide earlier interface identification between subsystems.
The Collaboration Diagram shows the functional and physical data between subsystems. The Logical Architecture and allocation can
generate logical components and develop the Class Diagram for subsystems. The design of this simple hardware system can be accomplished using the OOSEM.
A definitive conclusion cannot be made as to which approach, between the traditional systems engineering and OOSEM, is better in
assisting a simple hardware system design.
|
| 7.6.2 |
Object-Oriented and Structured Analyses Are Homeomorphic
J. Carl, J. Hofmeister, Harris Corporation
Object-oriented analysis and design methods are becoming predominant in the systems engineering workplace. One result is that object-oriented analysis
(OOA) may come to replace older structured analysis (SA) methods traditionally used by systems engineers. Another result is that assertions are
sometimes found in the literature claiming or implying that object-oriented analysis methods are uniformly better than structured analysis methods.
But if OOA and SA are homeomorphic, a systems engineer could choose to work with the analysis methods and representations that are most convenient
to solve specific problems of interest.
A substantially complete invertible mapping is presented in the paper to serve as evidence that OOA is homeomorphic to SA. A characterization of
the classes of problems better suited to one domain than the other is included in the paper.
|
| 7.6.3 |
Role of Emerging Technologies in Facilitating Integration of ATM Operations:
A Look at One Example: XML & Its Related Technologies
R. Katkin, N.J. Taber, K. Connolly, The MITRE Corporation
The authors present the business case for using the Extensible Markup Language (XML) and its related technologies (Document Type Definitions,
Extensible Stylesheet Language, XML Schemas, and XQuery to name just a few) in Federal Aviation Administration (FAA) initiatives that involve
fielding air traffic management (ATM) operational systems which will (or may) need to share information with other ATM operational systems.
The growing use of these technologies in a wide variety of aviation related applications, several of which are noted in this paper,
as well as the growth in the range, robustness, and availability of the technologies themselves lead the authors to recommend that
FAA give explicit consideration to using XML to facilitate fielding interoperable ATM applications.
|
SESSION 8
Session 8 Track 1: Managing Requirements
| 8.1.1 |
The Use of Planguage to Improve Requirement Specifications
T. Gilb, Result Planning Ltd
I believe that most current requirement specifications lack clarity, and are very poor in their supporting information.
We need to make requirement specifications ‘work harder’ by adding more ‘background’ to the requirements By ‘background’ I mean information
related to the requirement that is not the core requirement itself. The background information I am referring to includes: prioritization
(expressed by such means as ‘Justification’), risk management (expressed using such means as ‘Assumptions’),
change management (for example, the integration requirements), and quality control (for example, the testability requirements).
To improve requirement specification, I have developed a requirement specification language, as a subset of my planning language, ‘Planguage’.
This language has developed by practical need, in international industry over three decades, and is supplemented here with some recent ideas.
This paper will give an overview of the conceptual basis and some sample detail.
|
| 8.1.2 |
Requirements Risk Assessment - Integrating QFD and Risk Assessment
C.R. Kenley, Kenley Consulting
A modified Quality Function Deployment (QFD) analysis [Hauser and Clausing, 1988] was applied to evaluate development risk for user requirements
across multiple system architectures. Applying QFD to the risk assessments required tailoring the approach to capture and quantify subjective
risk judgments and to reconcile them with raw risk assessment data from specific designs. Initial evaluation of development risk from each
architecture showed that overall risk reduction activities were acceptable as planned. Risk assessments were also conducted on updated designs
using the QFD assessment to confirm validity of the final risk reduction plans.
This method extends previous work by Clausing and Cohen [1999], which described the use of QFD to capture requirements relationships,
and U.S. Air Force guidance [AFMC, 1977], which describes methods for risk evaluation. It allows capture of the strength of relationship
between user requirements and development risk early in a program by use of conceptual system architectures. This permits early evaluation of the
trade offs between user requirements and risk mitigation efforts prior to committing a program to a functional baseline is established for
user requirements and the design solution.
|
| 8.1.3 |
Ten Questions to Ask Before Opening the Requirements Document
P. Davies, Thales Airborne Systems UK
In projects where Systems Engineering is applied, the basis for contract is usually a set of Requirements, captured in one or more requirements documents.
The Supplier must understand the requirement set, and evaluate his potential to supply the required functionality and performance at acceptable cost,
timescale and risk. There is a risk that he may commit himself to a solution and a cost, thinking that the requirement set is understood,
when in fact there are hidden omissions, contradictions and risks which expose the Supplier to potential project failures.
This paper presents a simple checklist of ten questions, based on practical experience, that the Supplier’s Requirements Analyst or
Chief Engineer should ask himself, and ideally to ask his customer, before such a commitment. These questions do not depend on
the detailed content of the requirements – instead they are properties of the set itself.
|
Session 8 Track 2: Verification, Validation & Test (VV&T)
| 8.2.1 |
Automated Test Generation and Execution for Automotive Embedded Software
B. Legeard, F. Bouquet, F. Lebeau, University of Franche-Comté & LEIRIOS Tech.
This article describes a model-based testing approach that combines automated test-case and test-driver generation from Statecharts specifications.
It focuses on how the test engineer can control the test generation process, and how he/she specify the relationship between model variables and
the interfaces of the system under test. The Test-driver mappings make it possible to support complete model-based test automation: from
requirement elicitation with Statecharts to test execution and verdict assignment using specific test execution environment.
This approach has been used in the context of automotive embedded software validation. Three tools are used to completely support this
model-based test process: the I-Logix Statecharts STATEMATE modeler, the LEIRIOS Test Generator and the National Instruments test
execution environment TestStand. In this article, we illustrate this automated test process on a small car cruise control example.
|
| 8.2.2 |
Verification and Validation as it Applies to Simulation Based Acquisition
R.D. Gibson, SAIC
Weapon systems developed for the United States military are provided by government contractors with the hope that their system is selected for
large-scale production and use. In the past the contractor would build and provide to the military fully functional systems that were
then tested to see how well they worked and whether they fulfilled the requirements. As weapon systems have grown more complicated,
the ability of the contractor to build multiple systems to support testing has decreased dramatically due to the expense of those systems.
In light of this fact, the Department of Defense, in cooperation with industry, has initiated a new procurement program that utilizes
modeling and simulation (M&S) to augment weapon system testing. This program is titled Simulation Based Acquisition (SBA).
An important factor involved with SBA is the verification and validation of the modeling and simulation models used to supplement system testing.
In this paper I will describe the development of SBA, and how it augments system testing. Next, I will address the role modeling and simulation
plays in SBA and how it supports system testing. I will then discuss how verification and validation is used for the M&S models as well
as the results of system testing.
|
| 8.2.3 |
Verification, Validation & Testing Strategy and Planning Procedure
V. Levardy, M. Hoppe, Technische Universitat Munchen
E. Honour, Honourcode, Inc.
This paper introduces a new systems engineering approach for verification and validation (V&V) planning: the Verification,
Validation & Testing (VVT) Strategy and Planning Procedure. This iterative planning technique offers an effective method
for the deeper integration of V&V planning with other systems engineering disciplines and supports the maximal fulfilment
of the project goals and objectives. Since V&V is an important means to reduce project risk, the new VVT strategy & planning procedure
assists the risk management efforts by feeding the results of risk analysis directly into VVT planning and the systems engineering measurement process.
VVT planning defines the optimal risk reduction strategy in form of the VVT process and a measurement system to track project risks throughout the lifecycle.
The three stages of the SysTest VVT Process are introduced in the first part of the paper and then the major steps of the VVT
strategy & planning procedure are described in detail. Finally, the last section provides insight to the SysTest pilot projects
presenting the first results of the VVT Methodology implementation.
|
Session 8 Track 3: SE Life Cycle Processes - Applicability and Usefulness
| 8.3.1 |
Clearing the Confusion About Spiral/Evolutionary Development
H. Mooz, K. Forsberg, Center for Systems Mangement
US Government DoD Directives 5000.1 and 5000.2 declare a preference for evolutionary acquisition and spiral development both of which affect
the life cycle and associated life cycle processes. Since this declaration there has been considerable confusion over what these terms mean
and how they should be applied to system acquisition. Unfortunately, the DoD’s own terminology definitions do not help to clarify these approaches
and tend to counter traditional understandings. Both the Software Engineering Institute and Under Secretary of Defense
E. C. (Pete) Aldredge have been quoted that there is confusion and lack of understanding of both the terms and application.
This paper highlights the points of confusion and then takes the reader back to ground zero and builds a logic based understanding of
available technical strategies. Included are technical methods/models, development strategies, and delivery strategies.
|
| 8.3.2 |
A Perspective on System Engineering Under the New US Department of Defense Acquisition Policy
C. Spenny, D. Jacques, Air Force Institute of Technology
The Department of Defense (DoD) acquisition policy, as stipulated in federal documents reissued in 2003, include substantive changes to the manner
by which systems are to be defined and developed. Requirements have been replaced by integrated architectural views as the preferred means
for documenting the capabilities of a system, and detailed procedures have been defined for converting user needs into required capabilities.
The intent is to facilitate integration and interoperability and to assure technology development needs are identified and addressed at
the appropriate time during the system development process. This paper provides the viewpoint of its authors on how system engineering might
be applied at various times during the DoD requirements and acquisition process in support of these reforms. Challenges associated with implementation
of the new policy guidance are highlighted, and tools that might facilitate development for each phase are listed.
|
| 8.3.3 |
Unique Identification Yields Total Asset Visibility from Lust to Dust
R. Leibrandt, United Stated Department of Defense
This paper is based on application of an approach to globally unique item identification that fully integrated into the design, development,
manufacture, use and disposal of a system will revolutionize the business processes of the United States Department of Defense (DoD).
As this approach becomes embedded in the Department’s business practices and “flowed down” to Prime Contractors and Suppliers it will
revolutionize item marking and use much like the Universal Product Code (UPC) did for consumer goods. Ultimately Unique Identification (UID)
and a commercial equivalent, the Electronic Product Code (EPC), will transform serialization and item management globally.
In this paper I will explain what drove the development of the need and the approach that has resulted. Practical examples of implementation
will be provided and a "business case" will be supported. In the end, I expect to convince the reader that this mandatory DoD policy
should be embraced not only in the DoD, but supported throughout the United States Government and international communities.
|
Session 8 Track 4: Systems Effectiveness & Value Engineering
| 8.4.1 |
Supportability Analysis Process Flow Simulation Driven Analysis
A. Sleder, E.A. Navarro, H.D. Carstens, United Defense LP - Armament Systems Division
United Defense, L.P., Armament Systems Division has developed a process that improves the accuracy of reliability, maintainability,
and supportability analyses during the design cycle. These analyses rely heavily on initial assumptions in calculating key parameters
and serve as the basis for determining spares, manpower, maintenance policy, etc and ultimately the estimate for system Total Life Cycle Cost (TLCC).
Because of this, it is imperative that the initial assumptions be realistic and credible. We found that by modeling and simulating the design
against the customer’s specific mission profile, we can obtain realistic credible results, permitting the program to make cost effective
supportability decisions early in the system design cycle.
This paper presents the process and related tasks used in developing the supportability analysis in order to obtain realistic supportability results.
Also, this paper discusses the benefits of the approach and draws a comparison between the traditional methodology and this new process.
|
| 8.4.2 |
Error Cost Escalation Through the Project Life Cycle
B. Haskins, B. Dick, The Boeing Company, J. Stecklein, NASA Johnson Space Center
R. Lovell, Northrop Grumman Corporation, G. Moroney, Wyle Laboratories
J. Dabney, University of Houston
As systems become more complex, the costs to identify and correct requirements errors can consume large portions of project budgets. In general,
there are two categories of cost associated with errors – cost of identification and cost of correction. This paper addresses an important element
of the second category – the behavior of the cost of error correction as a project progresses. It is based on a study that used three approaches
to determine the relative costs: the bottom-up cost method, the total cost breakdown method, and the top-down hypothetical project method.
The approaches and results described in this paper presume development of a hardware/software system having project characteristics similar
to those used in the development of a large, complex spacecraft, a military aircraft, or a small communications satellite.
The results of the study show clearly that cost-to-fix escalates exponentially as the project progresses. If the cost of fixing a requirements error
discovered during the requirements phase is defined to be 1 unit, the cost to fix that error if found during the design phase increases to 3 – 8 units;
at the manufacturing/build phase, the cost to fix the error is 7 – 16 units; at the integration and test phase,
the cost to fix the error becomes 21 – 78 units; and at the operations phase, the cost to fix the requirements error ranged from 29 units to more
than 1500 units.
|
| 8.4.3 |
Total Ship Design Approach
M. Mangiarotti, P. Neri, N. Dazzi, L.M. Palazzo, S. Traverso, M. Cirillo, Orizzonte Sistemi Navali S.p.A.
The purpose of Total Ship Design (TSD) is to perform both Cost and Mission Effectiveness analysis and Cost and Risks analysis.
This paper presents a part of this process: the Value Analysis. In particular the discussion will be focused on the Value Analysis methodology
set-up and its main entities, Cost Analysis and Effectiveness Analysis.
|
Session 8 Track 5: Managing Quality/Risk
| 8.5.1 |
Design Reviews: A Customer's Confessions
J.R. Armstrong, Software Productivity Consortium
Even when guidance was available on design reviews in MIL-STD-1521, much was left to the reader. Since the cancellation of the standard,
specifics on design reviews have been limited. This paper provides several lessons learned and best practices that can be applied at
any point in the program. As the title indicates, most of the lessons were learned from the viewpoint of the customer.
They are augmented by experiences as the one being reviewed.
|
| 8.5.2 |
Evaluation of Interrater Agreement in Internal Audit Based on ISO 9001: 2000
Y.H. Hwang, C.G. Yi, Electronics and Telecommunications Research Institute
An internal audit in quality management system based on ISO 9001:2000 is an important process that continually improves the effectiveness and
efficiency of a quality management system. The reliability of assessments of an internal audit based on ISO 9001:2000 is an issue that
continues to demand the attention of researchers in this field. One element of reliability is the extent to which different teams assessing
the same project produce similar ratings when presented with the same evidence. Cohen’s Kappa coefficient has been the most popular measure
of reliability for measuring the degree of interrater agreement beyond chance. However, the application of the Kappa coefficient may be
biased downwards due to two Kappa “paradoxes.” To compensate for the deficiency of the Kappa coefficient, we additionally use a simpler
index of observed agreement between two teams of auditors. Using Cohen’s Kappa coefficient and the observed agreement,
this paper presents some results from two assessments between two teams conducted during internal audits in Electronics and Telecommunications
Research Institute in Korea. In each of these assessments, two independent teams performed the same ratings.
The results indicate that in general there is at least moderate agreement between the two teams and the extent of agreement between the
two teams is substantial.
|
| 8.5.3 |
Rule Based Design Reviews
T. Gilb, Result Planning Limited
Design reviews would benefit from the support of formal rules. By the use of relevant rules, it should be possible to ensure prior to a
review that all the relevant information for a review is present in the design specifications, and that all the minimum review criteria are met.
This will ensure management time is not wasted and aid better decision-making. This paper recommends that the Specification Quality Control (SQC)
method be used to do this additional quality control. In addition, this paper outlines the impact of Evolutionary Project Management (Evo)
on the design review process.
|
Session 8 Track 6: Trade-Off Analysis & Acquisition Logistics
| 8.6.1 |
ntegrating Failure Modes and Effects with the System Requirements Analysis
R.S. Carson, Boeing Integrated Defense Systems
Assessing failure modes and effects as part of the system requirements analysis activity provides specific benefits. Using the concept of functional failure,
the requirements analyst, whose primary focus is system functionality, can address the failure of any identified function to be performed as part of
the functional analysis. The requisite behavior is documented as a new route to an existing function, or may be a new function altogether.
Such integration reduces rework later in the program, since all conditions (nominal and fault) can be identified while requirements are being formulated,
well ahead of integration testing. We find also that focusing on conditions associated with requirements stimulates better requirements analysis
and documentation, leading to better implementation by designers. In addition, identifying all functional failure modes and their effects during
the requirements analysis activity allows the requirements analyst to verify requirements completeness. This provides a management metric for measuring
completeness of the requirements analysis process.
|
| 8.6.2 |
Maintainability Considerations for Software Intensive Systems
R. Ramchand, D. Verma, Stevens Institute of Technology
N. Tatikonda, R.E. Nance, Virginia Tech
This paper reflects one aspect of an overall research initiative to better understand and articulate the "cause and effect" relationship
between design causes and operational effects. Here the specific focus is on "before the fact" system maintainability.
Maintenance considerations for software intensive systems must be addressed early in design and must focus on the entire system life cycle.
Use of commercial-off-the-shelf (COTS) components in system architectures reinforces this need. COTS usage can be readily observed in modern
commercial and defense systems. Such architectures are often characterized by an evolving physical baseline (technology refreshment)
driven by obsolescence considerations. This paper proposes aspects of a framework to evaluate system architectures, with a particular
focus on system maintainability and with the objective of positively influencing the long-term cost of operational maintenance.
|
| 8.6.3 |
Maintenance Practices and Metrics Across Defense and Commercial Systems
R. Ramchand, D. Verma, Stevens Institute of Technology
N. Tatikonda, R.E. Nance, Virginia Tech
Systems and software engineering are converging disciplines with increasing evolution of modern complex systems towards increased information and
knowledge content. Further, with the capital investment associated with such systems and their long operational life spans, a longer-term notion
of quality during design and implementation is necessary. The realities of cost, safety, and staffing considerations are forcing increasing
emphasis on reuse and reengineering strategies. This imperative becomes even more urgent with the thrust towards the inclusion of commercial-off-the-shelf
components in system architectures. One key operational imperative for complex systems is the cost of maintenance.
This paper presents an industry survey conducted to understand maintenance practices prevalent in commercial and defense industries.
Results from an industry survey focused on system maintenance measures and metrics are also presented. This survey focused on information and
knowledge intensive systems and was supported by INCOSE-The International Council on Systems Engineering and SOLE-The International Society of Logistics.
|
SESSION 9
Session 9 Track 1: Managing Requirements
| 9.1.1 |
Applying Systems Engineering to University Satellite Projects
M. Meijers, Netherlands Foundation for Research in Astronomy
R.J. Hamann, B. Zandbergen, Delft University of Technology
A growing number of spacecraft development programs are emerging at universities across the world. These programs share a lot of characteristics
because they are all encouraged by the perception that a small spacecraft can both be capable and low-cost. The success of these missions,
both on a performance and programmatic level, is often due to use of adapted design and verification methods from mainstream large satellites.
These methods are well described in successive papers. Less attention is however paid to the adaptation of the requirements definition process
and design configuration management process into a small satellite project. This paper shows the need for the adaptation of full Systems Engineering
(SE) functionality into such a project and that it is possible to adapt the SE process, while keeping full functionality,
into a small spacecraft project that is conducted in an educational environment. The paper describes the successful introduction of the
requirement engineering process and configuration/design management in the Delfi-1 university satellite program, as part of
the primary author’s master thesis.
|
| 9.1.2 |
Future Trends in Automotive Requirements Engineering
F. Houdek, M. Weber, DaimlerChrysler AG
In the last few years, requirements engineering for software-based systems has attracted a great deal of attention in the automotive industry.
Requirements specification documents have been recognized as a crucial element in the software and system quality chain.
Consequently, several industrial initiatives have been launched to improve requirements specification quality, the creation process, and tool support.
For instance, many automotive OEMs have introduced requirements engineering expert groups and piloting of requirements management tools.
Despite the fact that the situation is still substantially heterogeneous, we observe a common level that the more mature projects have adapted
as the current state of practice. However, due to methodological and tool restrictions, this level still falls very short of the full potential
of tool-supported systematic requirements management in the automotive domain.
In this paper, we summarize the current state of the practice in requirements engineering for software-based automotive systems
(such as electronic control units) and identify future research directions and tool enhancement requirements. Additionally,
we try to identify some popular myths, i.e. ideas that are often mentioned in the context of automotive requirements engineering
but which seem to be unrealistic and/or undesirable from our point of view.
|
| 9.1.3 |
System Engineering Approach to Shipborne Weapon System Design
E. Sclano, C. Calvo, C. Guiliano, Orizzonte Sistemi Navali
One of the problems that System Engineers have to deal with whilst carrying out system design is to allocate requirements to the subsystems.
An approach based on a stochastic model to perform requirements allocation to the subsystems of a Shipborne Weapon System (SWS) is outlined in this paper.
The model allows computing the overall system performance, in terms of Probability of Escaping Hits (PEH).
Computation of PEH is related to the predetermined set of multi-threats scenarios (including the threat characteristics),
the defended area and the ship vulnerability, but at the same time it is subject to functional, physical and performance assumptions of the subsystems
as derived from trade-off studies. On one hand, the model allows to check whether the overall system performance of a SWS configuration,
not completely defined by the customer, is achieved and eventually, after the needed iterations, the parameters characterising each subsystem
become requirements. On the other hand, if the subsystems characteristics are known, the model allows checking the overall system performance.
|
Session 9 Track 2: Verification, Validation & Test (VV&T)
| 9.2.1 |
Application Experiences of the VVT Process Modeling Procedure for Verification and Validation Planning
M. Hoppe, V. Levardy, Technische Universitat Munchen
C. Leardi, Tetra Pak Carton Ambient, I. Mendikoa, Labein Technological Center
N. de Abajo, J.A. Gonzalez, S. Peregrina, V. Lobato, ACERALIA, Centro de Desarrollo Tecnologico
A thorough balancing of the costs of conducting verification and validation with the costs of failure promises new possibilities in reducing
overall project costs and time-to-market. One goal of the presented SYSTEST project is to develop an approach to support the strategic
verification and validation (V&V) planning. This approach, reflected in the VVT Process Model, supports the trade-off between different V&V
strategies by calculating the effect of the strategy on cost-, schedule-, and quality-risk.
This paper briefly presents the VVT Process Model and describes in detail some first application experiences.
|
| 9.2.2 |
UML-PVS Requirement Specification and Verification
I. Traore, M.Y. Liu, University of Victoria, A.E.K. Sahraoui, LAAS-CNRS, H.M. Al Jamal
In this paper, we present a specification-based testing approach in which, first, the specification is validated by verifying important system
properties using model checking, consequently increasing our confidence in it. Then, suitable test cases are generated for a system implementation
using the previous specification as test oracle. The specification is produced using the UML, which is based on a graphical notation that is
easy to learn and use. The formal model used during the model checking activities is based on a formal semantic that we have defined for
a subset of the UML. We apply, in this paper, the approach to the case study of a safety-critical software; namely, a temperature regulator
software component that is used in various highly dependable systems.
|
| 9.2.3 |
Gathering Historical Lifecycle Quality Costs to Support Optimizing the VVT Process
A. Engel, I. Bogomolni, S. Shachar, A. Grinman, Israel Aircraft Industries (IAI)
The purpose of this paper is to describe the process and results of gathering historical lifecycle quality costs for avionic systems.
This is done via a pilot project conducted at LAHAV, the military aircraft division of the Israel Aircraft Industries (IAI).
This project is performed in conjunction with the SysTest project, a European Comission R&D project chartered with developing a systems Verification,
Validation and Testing (VVT) methodology and a process model for estimating product lifecycle cost, risk, quality, time, etc.
|
Session 9 Track 3: SE Life Cycle Processes - Applicability and Usefulness
| 9.3.1 |
A Knowledge Management System Life Cycle Description Using ISO/IEC 15288 Standard
T.E. Herald, Jr., W. Berkemeyer, Lockheed Martin - Maritime Systems & Sensors
H.W. Lawson, Stevens Institute of Technology
Development of a Knowledge Management (KM) system is often considered to be a technical challenge of incorporating the proper system building
blocks that provide the mechanism for information transfer from a knowledge source to a potential user. These building blocks include tangible
elements such as databases, servers, networks, search engines, web portals and even extend to expert networks and artificial intelligence algorithms.
This paper provides a life cycle description of a KM system that includes both tangible and intangible elements. These intangible elements
include interfacing the human-in-the-loop, human motivation to contribute to (and to search) the KM system, and establishing a community of
practice that includes policies, procedures and guides that encourage a learning organization. Peter Senge (Senge 1994) defines a learning
organization as requiring an environment for individual and organizational growth to facilitate continual improvement and maintain a leadership position.
The KM system is a tool that, when properly implemented in a business, can indeed facilitate the environment of a learning organization.
This paper uses the recently released ISO/IEC 15288 standard (ISO/IEC 2002) and provides a detailed system description model for the life cycle
Technical Processes implemented for a KM system. ISO/IEC 15288 also provides descriptions of Enterprise, Agreement and Program Management processes
which are summarized for the KM system as a part of Appendix A.
|
| 9.3.2 |
Integrating System Engineering into PDM by AP233
R. Eckert, W. Mansel, EADS Deutschland GmbH
In the manufacturing industry Product Data Management (PDM) systems are backbone systems. The data must be complete, correct, easy to find,
easy to visualise and extractable for reports. A drawback is that today’s PDM systems are focussed on automotive applications.
There is however an increasing need e.g. from aerospace industry for an extended PDM schema to cover systems engineering product aspects.
STEP ISO 10303 - AP233 provides an appropriate approach for integrating systems engineering needs into PDM systems, specifically future
modularised STEP ISO 10303 application protocols will allow to construct the required PDM schema extensions at reduced customisation effort.
A framework for a systems engineering PDM system is proposed and data exchange aspects discussed. A demonstrator for the proposed solution
was build using AP233 interfaces for systems engineering CASE tools coupled to an appropriate PDM system.
|
| 9.3.3 |
The Value of UML Use-Case Modeling in Product Life-Cycle Context
H. Broeze, M. Sampson, UGS PLM Solutions; R. Lagarde, P. Davis, Lucka Education & Training
The importance of Requirements Engineering in a Systems/Product Life Cycle context does not get the attention it deserves.
Requirements definition practices mainly concentrate on defining functionality and selecting conditions for systems so that the system is sold successfully.
Use-case modeling, which is part of the Unified Modeling Language, is getting a lot attention these days. It defines scenarios of system
usage to reach a specified goal. Unified Modeling Language is widely used in software development projects but the Use-case modeling is
only applied to requirements discovery.
This paper describes the increased value of Use-cases when using them in a wider scope, in the context of a Systems/Product Life Cycle.
The paper starts with an introduction on Requirements management and Use-case modeling, followed by some facts on the value of combining
Use-case modeling and Requirements managemen. Finally statements are made on the value of Requirements management and Use-case modeling in
Product Life-Cycle context.
|
Session 9 Track 4: Systems Integration
| 9.4.1 |
A Systems Engineering Process Model for 'By Default' Systems Integrators
D. Cowper, A. Smith, M. Emes, University College London
Many individuals find themselves systems integrators ‘by default’. This situation comes with many challenges when integrating custom systems
from off-the-shelf components. A particular challenge is for ‘by default’ systems integrators to employ sound systems engineering practices
when they cannot be expected to have a good understanding of systems engineering principles, such as those described in ISO 15288.
This paper aims to explore the issues and risks facing a ‘by default’ systems integrator, and proposes a simplified lifecycle model
and documentation set based on ISO 15288 to assist with these challenges.
|
| 9.4.2 |
The Biggest Peoplesoft Implementation Ever - Implications for Systems Engineering
F.R. Parth, J. Gumz, Project Auditors, LLC
This paper describes the largest Commercial Off The Shelf (COTS) human resources implementation ever attempted. The Department of Defense has chosen
to combine its payroll and personnel functions for all four branches of the military: Army, Navy, Air Force and Marines. The software they have chosen
is Peoplesoft. Changes will occur for a variety of technical and political reasons, including Peoplesoft release updates, hardware updates,
supporting software updates, requirements changes, funding changes and changes in Congressional leadership.
How will the project deal with these changes? System engineering expertise is needed to manage the change that will occur inevitably
on a COTS implementation as massive as this one is.
|
| 9.4.3 |
Thales System Engineering Community of Practice: A Knowledge Mangement Approach
C. Decamps, M. Galinier, Thales
About 3000 people worldwide belong to the Thales system engineering community. This community of common practices is first of all based on
human networks and coordination, but it also requires a systematic approach (tools, methods and processes) to facilitate knowledge and work sharing.
This paper describes the objectives, way to proceed and main results of such a knowledge management approach.
|
Session 9 Track 5: Managing Quality/Risk
| 9.5.1 |
Evolving Risks and Use of Commercial Off the Shelf (COTS) Components
R. Domikis, The Boeing Company
As we continue to defend our nations, the increased use of Commercial Off The Shelf (COTS) technology in military, infrastructure and
other systems necessitates different approaches to address evolving risks and opportunities. COTS technologies have become far more
capable over the last 10 years and that trend shows no sign of slowing. In fact, the commercial world is often on the cutting edge
as companies vie to win market share. Nations and customers have recognized this trend and, with a desire to capitalize on it
(cost and time), are now often specifying “maximum use of COTS” in many systems. This increasing specification and use of COTS
technology will increase the challenges in protecting our nations, as well as afford us new opportunities for exploitation and defense.
All views expressed in this paper are those of the author and do not represent the policy or position of his employer or school.
|
| 9.5.2 |
An Integrated Set of Technical Measures to Support Earned Value Management and Technical Review
H.G. Sillitto, Thales UK
Successful experience with the use of key technical performance indicators, in a number of projects in various businesses within the group,
has allowed us to define a coherent set of key technical indicators. These indicators taken together provide a comprehensive "health check"
showing the status and current achievement of a project, and support risk assessment and earned value management by providing an objective view of
the current level and trend of solution maturity, requirements compliance, and residual uncertainty.
The set includes requirements and verification status, estimate of performance against key technical requirements, estimate of solution maturity,
cost drivers, and issue close-out. The paper will present the rationale and philosophy of the approach, and show examples of the measures in action.
|
| 9.5.3 |
Teaching Continuous Risk Management Using A Requirements Management Tool
J.C. Helm, University of Houston Clear Lake
This paper presents a technique to teach the continuous risk management (CRM) paradigm using a requirement management tool.
The paper explains the CRM process and shows how to implement the risk information using a requirement management tool.
Teaching students the continuous risk management implementation is important to show them how the tool will: assist the project management
and team members to establish and use consistent documentation; instantiate and store each identified risk; associate for each risk
a mitigation or task plan; and visually presents each risk with the capability to be tracked, watched or mitigated throughout
the project’s iterative life cycle. The IBM Rational Suite Enterprise RequisitePro tool used to show the students how to capture
and store the organizational and management system risk knowledge into a database. The students gain hands on risk management knowledge
that can be used for product, process and project improvement. They learn how to write risk statements, collect risk metrics,
and capture the risk lessons learned for future projects.
|
Session 9 Track 6: Trade-Off Analysis & Acquisition Logistics
| 9.6.1 |
On Trade Studies
D. Buede, Innovative Decisions, Inc.
This paper addresses trade studies – decision making activities that must involve the selection of possible alternatives and then the evaluation
of these alternatives on a set of objectives while being confronted with uncertainty about the ability of the alternatives to achieve high levels
on the objectives. This discussion addresses six different types of trade studies: four for the system being developed and two for the qualification
system that must address verification, validation and acceptance of the system design. The topics of this paper are the elements of all trade studies,
the way in which the objectives and uncertainties change as we move from one type of trade study to another, and the benefits and pitfalls of trade studies.
While this paper focuses on the trade studies for the system being developed, the same discussion could be created for the system that is
developing the system being developed.
|
| 9.6.2 |
Standard Approach to Trade Studies
A. Felix, Naval Warfare Center - Weapons Division
This paper describes the steps for performing and documenting a Trade Study (Trade-Off Study), developing products for the Decision Making Authority,
and guidelines in tailoring the study to meet the needs of the program. The purpose herein is to transform a subjective decision making process into
a more objective decision making process. Within this process, standard terms and definitions are used, roles and responsibilities of the participants
and decision makers are documented, and a suggested flow is illustrated. The significant developments introduced in this paper are identified in the paper
where they appear.
1. Defining a Framework and Structure for seven often used Trade Study types
2. Removing Cost and Risk from the tradable Criteria list
3. Defining a Baseline/Optimum solution(s) to anchor Criteria Utility Curves.
4. Presenting Uncertainty (Lack of Confidence) considerations in criteria evaluation
5. Presenting the Cost-Benefit Chart for use in final (Gate 3) evaluation
6. Presenting the Risk-Benefit Chart for use in final (Gate 3) evaluation
This Trade Study process meets Level 3 Decision Analysis and Resolution requirements of the Capability Maturity Model Integration (CMMI®).
|
| 9.6.3 |
Systems Engineering in a COTS World
R.L. Sorensen, Vitech Corporation
Using traditional systems engineering practices to accommodate commercial off-the-shelf (COTS) components requires focusing on those steps
within the design process that allow identification of the constraints imposed by COTS items early in the design process.
Two traditional systems engineering processes are reviewed for their insights into the major tasks, the goals, and the dependencies.
With this understanding, the focus moves to discussion of a proposed approach for applying systems engineering practices using a process that
retains a requirements-driven methodology while simultaneously adapting to the boundaries imposed by COTS items, thereby converging on a solution.
|
Key Reserve Papers
| 10.1 |
Achieving CMMI L3
R. Richard, Thales Training and Simulation
Thales Training and Simulation (TT&S) SA achieved CMMI level 3 in June 2003. This covers Software, Project Management and Systems Engineering.
Following an action plan on Software (CMM level 3 achieved in 1996) TT&S defined a strategy leading to reach CMMI level 3 for all disciplines
(including Bid and Project management). This paper aims at sharing :
lessons learnt to reach CMMI level 3
benefits perceived by TT&S
brakes encountered during implementation of the action plan
Three keys strongly contributed to this success. The first one is the experience that TT&S gained during the Software CMM action plan.
The second one is the involvement of management. The third one is measurement of progress through internal assessments
Note: CMM and CMMI are registered copyrights of CMU/SEI
|
| 10.2 |
Architectural Framework For Complex Test Requirements Management
M.F. Ludwig, The Boeing Company; C.H. Dagli, University of Missouri-Rolla
There are several systems engineering models available to provide guidance in transforming stakeholder requirements into comprehensive solutions.
Though systems engineering processes are essential leading up to this point, the final adjustments will be determined during test and evaluation.
This point is conveyed in the heuristic, "Regardless of what has gone before, the acceptance criteria determine what is actually built."
Establishing the acceptance criteria and compliance verification processes for a complex system is also a complex task.
This task must start early and be accomplished in parallel with system architecture and design. In this way, quality can be designed
into the product and relevant tests can be devised that match the needs and expectations of the stakeholder. This paper proposes a heuristics
and model-based architecture for establishing and managing complex test program requirements. In addition,
statistics for a successful application of this architecture will be shared.
|
| 10.3 |
Architecture: A View Based on Multiple Impacts
T. Gilb, Result Planning Limited
In order to properly support the systems engineering process, the systems engineering profession needs to consciously adopt a more productive
view of systems architecture. Many existing definitions of systems architecture are too narrow: they focus too much on ‘structure.’
The focus needs to be shifted to the impact on requirements.
|
| 10.4 |
A Conceptual Glossary for Systems Engineering
T. Gilb, Result Planning Limited
This paper discusses some of the insights gained and the problems experienced to date in developing a conceptual glossary for the planning language,
‘Planguage.’ It also outlines a model to build on for similar work in organizing knowledge about concepts.
The author’s opinion is that further development of such glossaries is needed as concepts form a fundamental basis for educational
and organizational purposes.
|
| 10.5 |
Experience of Teaching Systems Architecting
G. Muller, Embedded Systems Institute
The experiences of four years teaching systems architecting are described. The duration of the course systems architecting is 5 days.
The target audience consists of (potential) architects and stakeholders that cooperate intensely with the architect, such as project leaders,
product managers, and group leaders. The course has been given 23 times in the period November 1999 to January 2004.
The maximum number of participants is 16.
This paper discusses the course content and the course objectives, course materials, the course format, some course statistics,
the expectations of the students up front and the evaluation at the end, the follow-up and the longer term results, the derived course for managers,
the lack of visibility of system architects, and the broader education context that is required for a systems architecting curriculum.
|
| 10.6 |
How Many Systems Are There? Using the N2 Method for Systems Partitioning
J. Ben-Asher, T. Bustnay, Technionz
An algorithm for partitioning a complex system into its independent constituents is developed. The N2 method is used for the problem formulation
whereby the objective is to obtain a system presentation in a simple flow. The development of the algorithm is based on graph theory techniques.
The algorithm is formulated using graph theory and N2 charts. Several examples are presented to demonstrate the relative ease of the algorithm employment.
|
| 10.7 |
Human Understandability for Optimizing Architectures
D.K. Smith, UGS PLM Solutions / SLATE Deployment Services
Humans define, create, and use systems. Therefore, to minimize opportunities for problems in a system’s lifecycle, the work products that affect
the system definition and program lifecycle activities must be highly understandable and not subject to multiple interpretations.
The antidote to complexity is (human) understandability. Understandability is driven by the amount and clarity of information presented
and accessible to stakeholders at a particular level in the system architecture. High-level information needs to be more general while
lower-level information must provide sufficient detail to prevent ambiguity and omissions. The issue is how to package information at each
system level to maximize stakeholder understandability at that level.
This paper describes ways to increase human understandability and thereby increase system robustness of both the architecture elements and
interfaces between them during the SE process. The result is a system definition that is more likely to satisfy the SE goals of
delivering an error free product.
|
| 10.8 |
Integrating Systems Engineering and Marketing
D.J. Paul, W. Webster, Cameron Consulting International
C.R. Kenley, Kenley Consulting, LLC
Customer Oriented Requirements Understanding (CORU) continues to be the key to successful Systems Engineering and Marketing of large Aerospace
and Government systems. Buyers hold all of the Requirements and all of the money. This is defined as the "Customer Needs or Requirements PULL"
environment.
Systems Engineers ask if the principles of CORU operate in a Commercial "Seller Product or Technology PUSH" environment,
and whether causal models can be constructed which address and differentiate (or segment) markets accurately.
If so, the principles which are effective in large system acquisition environments (with limited numbers of stakeholders) can be translated
to the relatively large stakeholder environment of product development for TELCOs, consumer electronics and high-technology systems,
and other high-volume commercial products. The key process techniques of Requirements Elicitation and Requirements Causality Modeling are
described along with a robust economic and Systems Engineering model for a network-like architecture of how these processes link the Customers
(Buyers) with Needs or Requirements together with the Sellers or developers of Capabilities or Products. Research results are delineated
which make the case that these linkages through Requirements Elicitation and Requirements Causality Modeling process techniques are basic
principles of CORU which are valid in both the Requirements PULL or DoD environments as well as in the Product PUSH or commercial environments.
Examples are given in which Value Hierarchies are aligned across Customer-Seller boundaries to achieve product success in both the Commercial
and the DoD environments.
|
| 10.9 |
The Multi-Dimension Metric for the Assessment of Organizational Complexity – Case Study of Shendong Coal Co. Ltd.
H. Song, Shandong Institute of Business and Technology; J. Wang, Shenfu Dongsheng Coal Company Ltd
C. Reiman, Universitas 21 Global Pte Ltd
This article applies the theories and methods of physics, mathematics, dynamics, information science, statistics and management science
to develop concepts, definitions, basic theorems and research scopes in the area of management complexity; based on the theories of management entropy,
it will establish a new metric for assessing management complexity and vectorial space, as well as mathematical modules.
Some methods to enhance managerial effectiveness and efficiency have been proposed as a result of progress in this field.
The researches so far have tried to enrich the complexity theories in management circles. As a case study of Shendong Coal Co.Ltd,
the multi-dimension metric assessment of the organizational complexity has been drawn up and verified.
|
| 10.10 |
Simplifying the Organizational Paradigm to Improve Management of Complex Aviation Systems
L.R. Smith, T. Hughes, R. Branson, Aviation Engineering Directorate
This paper presents a case study of organizational change involving systems engineering management of complex aviation systems.
The authors' premise is that management is more effective using simple tools and methods, even when dealing with very complex systems
such as military helicopters operating in a network-centric environment. Complexity of modern warfare systems requires systems engineers
to think in complex and convoluted ways. At the same time, these projects can be effectively managed using basic management skills and tools.
The complexity of military aviation systems is illustrated and management challenges are discussed in a context of business fundamentals.
Useful tools and techniques show merit in simplifying the planning, communication and decision-making processes of systems engineering.
|
| 10.11 |
SpecRight: Writing Correctly Requirements, Produce Product Specifications and Requirement Justification File
J. Chevallier, R.M. Marshall, Prosumer Solutions Ltd.
SpecRight is a tooled approach to the capture of technical requirements, product specifications and requirements justification documents.
This is done by combining educational elements, formal definitions, and automated work guides. By answering the questions in each work guide
users can create complete systems engineering documents.
The objectives of the approach are to be an aid and a guide to capture and structure technical requirements and to produce and manage product
specifications and requirements justification. As systems engineering needs correctly-documented requirements, SpecRight is a useful means of
performing the first step of the engineering process.
Following a demand from the European Space Agency (ESTEC) a prototype of SpecRight has been created to demonstrate that the logic could be
performed and supported by software. We are now working to complete SpecRight such that it is in line with ISO 21351 Functional and
Technical Specifications.
|
| 10.12 |
System Level EMC - From Theory to Practice
R. Zamir, V. Bar-Natan, EL-OP LTD.
This article discusses the vast importance of incorporating Electro-Magnetic Compatibility (EMC) engineering as an inseparable part of
system engineering in a complex, technologically-advanced, tight-scheduled military Project, starting from the Project proposal
stage (in response to a Request for Proposal – RFP), down to cositing impacts tests in the platform. The Project’s product is defined as
an operational prototype. On one hand, this prototype will prove the system’s functional properties as were specified by the Customer,
while on the other hand serving as a first article that is required to withstand all of the environmental conditions as a serially-produced system,
including full EMC requirements. The unique system which is being addressed here has multiple, diverse capabilities and is comprised of
elements and units belonging to various families, e.g., electronic boxes, electro-optical units, inertial sensors, functional display,
computer, etc. The units are based on home-developed and Commercial Off-the-Shelf (COTS) units (military as well as civilian/industrial).
Furthermore, we will present the methodology that was employed to minimize problems/failures during system EMC tests,
in both the laboratory and after installation in the platform.
|
| 10.13 |
A Systems Engineering Based RAM Approach for Rail Infrastructure:
Intelligent Application in a 25kV Traction Power Supply System
R. Lafeber, R. Van Baaren, M. Sasso, ADSE Consultancy and Engineering Services
One of the leading projects in the Netherlands concerning the integration of reliability, availability and maintainability (RAM) in the development
of new rail infrastructure is BB21/ 25kV TPS. This project is aimed at the design and development of a new generation 25kV Traction Power Supply System.
This paper describes how the existing European Standard of the application of RAMS in railway applications has been
tailored to the specifics of this project. The application hereof effectively made the 25kV Traction Power Supply System project
the first large rail infrastructure project in the Netherlands that integrated RAM into design and development.
Generic conclusions on the application of the pragmatic framework in other industries, such as shipbuilding, are also presented. |
| 10.14 |
The Systems Engineering Sandwich: Combining Requirements, Models, and Design
J. Dick, J. Chard, Telelogic UK Ltd.
As Systems Engineering problems and solutions become more complex, it is harder for engineers to describe them and harder for reviewers
and other stake-holders to understand the descriptions. What is needed is a more powerful way of describing both problems and solutions,
which combines the textual approach with the diverse world of modeling, including the use of visual representation.
The result would be more accurate and complete system descriptions that are easier to understand and communicate for all stakeholders involved.
In the Systems Engineering “sandwich”, requirements management is the “bread and butter” of the development cycle, and system modeling provides
the "filling". The role of the filling provided by modeling is to hold the requirements layers together,
and provide richer rationale for relationships between those layers.
In our opinion, the key to integrating requirements management with system model is the recording of design rational in an organized way.
Such rationale explains why requirements have been decomposed in particular ways, and how one layer of requirements is intended to satisfy the layer above.
The focus for such information is the "design document".
The following benefits are identified as accruing from an effective process integration of requirements management and system modeling:
- System modeling adds formality to the design process that lies between each layer of requirements.
- System modeling supports the construction of a consistent vocabulary for the textual expression of requirements.
- The design rationale gathered around the system model becomes the rationale for tracing between layers of requirements.
- The structure of the system model can be used to give structure to the requirements document.
- System models can be embedded in system design documents. These can provide textual context for the system model,
giving rationale for design choices, explanations of diagrams, etc.
- Impact analysis can be carried out uniformly through requirements and models.
- Non-functional and performance requirements not captured in the model can be managed as textual statements.
|
|
The INCOSE 2004 INTERNATIONAL SYMPOSIUM TECHNICAL PAPERS ABSTRACTS :