bluuebunny/crossref_metadata_2025 huggingface dataset:
6.7.2 Defining an Architecture with a COTS‐Aware Software Engineering Process
Authors: Chung Lawrence , Cooper Kendra , Kaffenberger Ruediger
Published: November 2014

The goals of developing systems better, faster, and cheaper continue to drive software engineering practitioners and researchers to investigate software engineering methodologies that are novel, yet practical. As the size and complexity of systems continues to grow, there has been a growing interest in the investigation of social paradigms (e.g., agent‐ and goal‐oriented approaches) and the use of COTS components. These are being viewed more and more as promising, and also perhaps inevitable, solutions to this problem. The effective application of social paradigms and use of COTS components, however, requires a systematic approach that provides a set of concepts for modeling the subject matter, a set of guidelines for using such concepts, and tool support to assist the developer.

In this paper, we present part of a COTS‐Aware Requirements Engineering and Architecting (CAREA) approach that explicitly supports the use of COTS components. Our CAREA approach, an extension of our previous work in system and software requirements engineering, is agent‐ and goal‐oriented, knowledge based, and has a defined process. In particular, we present part of the process that supports the formal definition of a software architecture. Our CAREA approach is validated using a Digital Library System example; a prototype of the CAREA Assistant tool is used to present some of our preliminary results.
2.8.4 Applying SE and CASE Tool to the Jamming System
Authors: Park Moon‐Bok , Woo Byung‐Il , Lee Dale
Published: November 2014

This paper presents the design concept for the phased array T/R (transmit/receive) jamming system collecting the electromagnetic wave, finding the direction and position from the sources, and transmitting high power to the Radar. This system will be added to a stand‐off jamming system in near future. We introduce systems engineering technique to the jamming system in order to scrutinize the behaviour of the system. And using CASE tool, RDD.Com, we provide a good way to design the system in terms of requirement analysis, system architecture and the system verification. Finally we show that SE approach can be a good solution to reduce design risks for a smaller system and technically complex system.
4.8.2 Incorporating Uncertainty into Conceptual Design of Space System Architectures
Authors: Hastings Daniel E. , Weigel Annalisa L. , Walton Myles A.
Published: November 2014

The environment in which space systems are developed and operated can be classified as nothing less than dynamic. This paper introduces an approach to quantify and compare space system architectures around the central theme of uncertainty, with emphasis on policy uncertainty, as well as, technical and market uncertainty. Two cases of implementation are presented and two generalized principles are proposed that flow from the analysis: 1) space systems must be designed with uncertainty as one of the central organizing principles, 2) since space systems have management and social dimensions and thus involve human interactions, there is an irreducible uncertainty associated with these dimensions that will affect the design of the system.
4.8.4 Four Applications of Bayesian Networks for Systems Engineers
Authors: Jean‐Philippe M.
Published: November 2014

Amongst many other considerations, Systems Engineering is based on the capability to predict and control the behaviour of a system.

The Bayesian networks method is a technique that uses the theorem of Reverend Thomas BAYES, as established about 250 years ago and as developed by the great mathematician LAPLACE.

Dealing with the BAYES theorem is usually reserved to mathematicians, since its application quickly requests a high level of mathematical awareness. Most systems engineers have had some courses on BAYES theorem during their studies, but they cannot envision any use of this rusty knowledge in their daily work.

The goal of this paper is to describe four practical uses of Bayesian networks, which can be understood by the “regular” Systems Engineer:

Selecting a design and making trade‐offs

Controlling the system behaviour

Assisting the troubleshooting during integration

Facilitating system maintenance
5.8.1 CADM Compliance for Implementations in an Object‐Oriented Environment
Authors: Smith Darold K.
Published: November 2014

The C4ISR Core Architecture Data Model is defined using a relational database syntax. There are many reasons to consider implementing a C4ISR application in an object‐oriented database (OODB) environment, such as intuitive object representation, performance, and efficient support for a highly collaborative work environment.

Clearly, the database schema in the object‐oriented (OO) implementation must comply with the CADM definitions, i.e., be CADM compliant, before implementing applications. This raises the question: “What constitutes CADM compliant?” This paper identifies initial CADM compliance requirements and related issues for OO implementation.
5.8.3 Modelling Integrated Systems Architectures
Authors: Schmidt Richard F. , Macdonald Patrick
Published: November 2014

The Navy's Chief Engineering Office (RDA/CHENG) is attempting to establish an advanced methodology for performing “Capability‐based” system acquisition. This requires the modelling of a “Mission‐oriented” Battle‐force where the contributions of each system, and future system concepts, can be assessed in terms of mission effectiveness. The Naval Collaborative Engineering Environment (NCEE) has been established to support this large‐scale engineering effort and the Authors are working towards a modelling framework which properly captures a Mission Capability Portfolio of systems. In addition, the modelling approach is based on the DOD C4ISR Architecture Framework1, and provides a basis for translating the Operational, System, and Technical Views into System Engineering Models. Furthermore, a significant challenge facing this modelling effort is the capture of the emerging concepts driving Network‐centric warfare. CORE, a commercial Systems Engineering tool, is being utilized to support this modelling effort.
Integrating Legacy Systems with Data Reverse Engineering and Patterns
Authors: Heiligenthal Pamela
Published: November 2014

Legacy integration remains a major issue in the systems engineering world. Although many temporary solutions have proved successful for existing systems, the need to support dynamic and real‐time business process opportunities will require that we take a closer look at a more long‐term system solution (Sprott et al. 2002). This paper presents a high‐level introduction that will focus on using Data Reverse Engineering (DRE) and the use of patterns as a methodology to solve legacy system integration. Reverse engineering is a viable long‐term solution that will evolve legacy systems in a disciplined manner in order for it to meet new requirements (SEI 1995).
1.1.2 Naval Combat System Design: System Engineering approach and complexity management
Authors: Ciambra Francesco , Nardini Manuela
Published: November 2014

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.3.2 Customer focused Engineering in Airbus A380 programme
Authors: de Chazelles Pierre , Comes Michel , Kerrien Anne
Published: November 2014

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.6.3 Formalizing the Language in Your Universes of Discourse
Authors: Gonzales Regina M. , Joyce Scott , Cuyler David S.
Published: November 2014

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.
2.1.3 A Systems Engineering Framework for Design, Construction and Operation of the Next Generation Nuclear Plant
Authors: Gorski Edward J. , Park Charles V. , Southworth Finis H.
Published: November 2014

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.
2.3.1 A Decision Support Framework for Feasibility Analysis of International Space Station (ISS) Research Capability Enhancing Options
Authors: Ortiz James N. , Scott Kelly , Smith Harold
Published: November 2014

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.4.1 10 Pitfalls of System Process Development with Avoidance Solutions
Authors: Arnold Eileen
Published: November 2014

Process literature has provided excellent 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.5.1 Collaborative processes enabler
Authors: MOLY Marlène , TREBUCQ Bruno , CALLOT Martine , SAINT‐MARC Laurent
Published: November 2014

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.6.3 Understanding Cost Analysis Process in United States Government Systems Acquisition
Authors: Covert Raymond P. , Jones Susan E. , Anderson Timothy P.
Published: November 2014

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.” 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.
3.1.1 Embedded Systems Engineering: Managing Systems Complexity, Change, and Crises
Authors: BeVier John L. , Calimer Colleen A.
Published: November 2014

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
Authors: Martin James N
Published: November 2014

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.2.3 An Approach to Design for Safety in Complex Systems
Authors: Dulac Nicolas , Leveson Nancy
Published: November 2014

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.
3.5.1 How can Systems Engineering Improve Socioeconomic Conditions in Developing Countries? The Jamaica Situation
Authors: Gaynor Horace
Published: November 2014

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.
4.2.1 A Pattern for Enacting Systems Engineering Reviews in Systems Development
Authors: Fohn Steffen M. , Popick Paul
Published: November 2014

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.
5.1.2 Requirement Architecture Framework(RAF)
Authors: Lee Joong Yoon , Park Young Won
Published: November 2014

This paper describes a requirement architecture framework(RAF) intended for use during the front end of requirement definition processes. The requirement definition process is a highly conceptual process that is difficult to carry out. While there are several systems engineering standards, these standards describe only “what to do” not “how to do“. This study focuses on how to perform the requirements definition process including the integration of process, methods and tools for the front‐end activity of requirements definition process. Requirement architecture framework represents a model for use to define systems requirements in a systemic approach. The RAF model is structured in four segments, including 6W2H2V requirement representation method, requirement categorization, life cycle stakeholder and requirement definition process. The study also proposes a requirement quality metric, that measures defects per hundred requirements (DPHR), and requirement baseline control guidelines using DPHR as a metric. The study demonstrates the effectiveness of RAF applying DPHR by presenting the results of an experiment.
5.3.1 Adaptive Design Using System Representations
Authors: Dare Robert , Rebentisch Eric , Murman Earll
Published: November 2014

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.4.3 Architecting and Innovating
Authors: Campbell Ronald B.
Published: November 2014

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.
5.6.3 Zoned Analysis: A Middle‐Out Method to Join the Top‐Down and Bottom‐Up Approaches During Mission Analysis1
Authors: Zirker Larry , Hamelin Douglas
Published: November 2014

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.
6.1.1 Compliance Mapping of Industry Standards to the Rockwell Collins' Technical Consistent Process Using a Requirements Database
Authors: Thompson Anthony J. , Povacz John F. , Bennett Richard A.
Published: November 2014

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.3 A Requirements Assessment Architecture that Combines Natural Language Parsing And Artificial Intelligence
Authors: Scott William , Cook Stephen
Published: November 2014

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.
6.2.1 Systems Engineering Principles Revisited
Authors: Han Myeong‐Deok
Published: November 2014

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.3.3 A PS covering Functional Architecture support in SEDRES developed drafts of AP‐233
Authors: Herzog Erik
Published: November 2014

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.
6.5.2 Concepts Pertinent to the Future of INCOSE
Authors: Ring Jack
Published: November 2014

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.6.2 Integrating Open Source
Authors: Wind Allan
Published: November 2014

Open source projects are 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, adoption, maintenance and support of such component are discussed.
7.1.3 Using a Requirements Management Tool in Technical Requirements Negotiations
Authors: Dale R.S.
Published: November 2014

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.
7.2.1 Issues for Systems Engineering Research
Authors: Sahraoui Abd‐El‐Kader , Buede Dennis M. , Sage Andrew P.
Published: November 2014

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.
8.3.3 Unique Identification Yields Total Asset Visibility from Lust to Dust – P236
Authors: Leibrandt Rob
Published: November 2014

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.
9.3.3 The value of UML Use‐case modeling in Product Life‐Cycle context
Authors: Broeze Henk , Samplson Mark , Lagarde Remco , Davis Pete
Published: November 2014

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.
9.5.3 Teaching Continuous Risk Management Using A Requirements Management Tool
Authors: Helm James C.
Published: November 2014

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.
10.2 Architectural Framework For Complex Test Requirements Management
Authors: Ludwig Michael F. , Dagli Cihan
Published: November 2014

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.10 Simplifying the Organizational Paradigm to Improve Management of Complex Aviation Systems
Authors: Smith Lawrence R. , Hughes Timothy J. , Branson Ronald R.
Published: November 2014

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.
1.1.1 Industry and Academia: Why Practitioners and Researchers are Disconnected
Authors: Muller Gerrit
Published: November 2014

The industrial world and the academic world have grown far apart. The distance between the worlds primarily originates from different goals and different means of support. This is a problem in the areas of systems engineering and multi‐disciplinary design. These areas are relatively young, providing lots of opportunity for research. Education in this area is scarce. Publications are tangible examples of the gap between the two worlds.

In this paper we discuss the needs of both communities with respect to publications, education, and research. The mutual understanding of each other's needs may help to bridge the gap between academics and industry.
1.1.3 The Core Competencies Of Systems Engineering
Authors: Cowper Douglas , Allen‐Shalless Richard , Barnwell Keith , Brown Samantha , Fatatry Ayman El , Hooper John , Hudson Sandra , Oliver Les , Smith Alan , Stoves Jocelyn
Published: November 2014

This paper describes the work of an INCOSE UK Advisory Board working group set up to define the set of Core Competencies for Systems Engineering. The development of complex products (systems) demands a broad range of competencies from its system engineering resource. An agreed set of core competences would allow individuals and enterprises to establish an effective, transferable portfolio of skills, which can be deployed in systems projects. Such a set of core competences will also provide a framework for education/training and assessment. The working group recognized that in addition to core competencies, Supporting Techniques, Basic Skills and Behaviours and Domain Knowledge are important. This paper offers a set of core competencies for Systems Engineering and guidance on how to use them.
1.2.1 Engineering Information Assurance for Critical Infrastructures: The DITSCAP Automation Study
Authors: Lee Seok Won , Ahn Gail‐Joon , Gandhi Robin A.
Published: November 2014

Recent advances in information technology have transformed the way in which mission‐critical services get delivered and are evaluated today. These services are heavily and increasingly relying on an interdependent crossed network of critical information infrastructures, spanning from private to government sectors. In order to enable such infrastructures to efficiently mitigate risks, optimize their security posture and evaluate their information assurance (IA) practices, we identify the need for a structured and comprehensive methodology for IA‐aware critical infrastructure protection. In this paper, we focus on the automation study of the Department of Defense Information Technology Security Certification and Accreditation Process (DITSCAP) that is a standard for certifying and accrediting the information networks that comprise of the Defense Information Infrastructure (DII). We attempt to generalize a course of actions in DITSCAP that motivate our design principles and modeling techniques, supported by their theoretical backgrounds and demonstrable prototype interfaces to establish their appropriateness.
2.1.3 Engineering Enterprises Using Complex‐System Engineering
Authors: Kuras M. L. , White B. E.
Published: November 2014

This paper summarizes a complex‐system engineering (cSE) regimen for the deliberate and accelerated management of the natural processes that shape the development of complex‐systems and proposes an approach for applying this regimen to enterprises. It also introduces a fundamental process of cSE, multiscale analysis—a departure from the traditional, uniscale, reductionist analysis that underpins traditional system engineering (TSE).
2.4.1 A Case Study Example of the Role Matrix Technique
Authors: Callan Katie , Siemieniuch Carys , Sinclair Murray
Published: November 2014

The paper outlines the Role Matrix Technique (RMT) ‐ a paper‐based method for resourcing processes with identified human roles. It was developed in use over a number of projects, where the aim was to explore alternative allocations of roles to processes in order to find the most appropriate configuration of roles, responsibilities, interactions, activities etc. All stakeholders in a given process can generate a common understanding of roles and responsibilities, along with the interactions between roles. The overall picture is generated graphically, by means of a bottom‐up approach. Once, trained in the basics of the method, it should be applied by stakeholders familiar with the process under scrutiny, and who also have an awareness of the critical interactions between the human roles involved. The paper provides an overall rationale for the method and then goes on to discuss the three main stages involved: modelling the process of interest; identification and allocation of the roles required to process activities; and the representation of these roles within the Role Matrix – this is where the key innovation lies. The paper finishes with an evaluation of the RMT.
2.4.3 Extreme Leadership for Systems Engineers
Authors: Fossnes Terje
Published: November 2014

There have been numerous attempts to identify and analyze the multiple factors that contributed to the “tragedy” on Mt. Everest in May 1996. As the leader of a challenging project some years ago, I recognized many of the same human behavioral patterns between my project and Mt. Everest events. This paper presents my observations as well as a mapping of how Project Management / Leadership (PM), Systems Engineering (SE) and Supportability/Integrated Logistics Support (ILS) are integrated for each of the 2 systems respectively, and how these complex systems and human behaviour mutually influence each other. In my experience, Systems Engineers leading a project share many of the challenges of a leader taking a group of mountaineers to the top of Mt. Everest – and visa versa. In my capacity as Technical Program Chair of INCOSE 2004 in Toulouse France, I was privileged to organize and conduct the special session called “Management under Extreme Conditions“. This paper is a continuation of the dialogue begun in that session.
3.3.2 The ABCs of AFs: Understanding Architecture Frameworks
Authors: Siegers Rolf
Published: November 2014

Numerous architecture frameworks have emerged over the past decade, but the contents and purposes of these frameworks are quite diverse. A framework typically addresses topics such as methodology, product description, reference models, categorization, or classification, but no single framework fully covers all aspects of the architecting process. Many users mistakenly believe that these frameworks represent distinct alternatives to the architect and that they must identify a single one to facilitate or guide their architecting efforts. The reality is that architecture frameworks (or parts of frameworks) must be unified in order to provide a comprehensive architecting solution. The purpose of this paper and presentation is to provide an overview of several architecture frameworks in use today, along with recommendations on the unification of key elements of specific frameworks.
4.1.1 Bridging Systems Engineering Views with a Structuring Matrix
Authors: Battersby David , Holden Carren
Published: November 2014

This paper describes how a single information representation based upon Design Structure Matrix (DSM) may be used to provide a unified information visualisation applicable across a range of key systems engineering domains. This supports both the planning and technical architecting of a system and as such may be valuable as a link between these areas and the more abstract lifecycle model. The ability to restructure the matrix through clustering and partitioning also supports systems engineering by providing an improved understanding of the whole system. This understanding is facilitated by the use of clearly defined attributes assigned to the links within the matrix.

The use of any systems wide tool is dependent upon its facility to manage information coherently. In this paper methods enabling this management are proposed, and the implications for improving traceability across the wide range of different relationships that exist within a systems engineering project are explored.

An example is provided based upon an automobile architecture, this example demonstrates the depiction of linked information using linking different attributes within a matrix representation. It is demonstrated how DSM can facilitate further hierarchical breakdown of the system, and the benefits of clustering and partitioning of the problem are explored. A range of areas within the systems engineering process where these methods are likely to be valuable including formal optimisation, planning and requirements management are highlighted throughout the paper. This flexibility reinforces the potential role of DSM as a fundamental shared visualisation method.