bluuebunny/crossref_metadata_2025 huggingface dataset:
3.4.5 Were the Ancient Egyptians System Engineers?
Authors: Jacobs Vladimir
Published: November 2014

Systems engineering is a 20th century discipline. To judge whether an organization is on a world class systems engineering level, we evaluate whether the organization's development processes and resulting product satisfy the 8 systems engineering axioms. Could we evaluate ancient organizations? The pyramids on the Giza Plateau are the only remaining wonders of the ancient world. The sheer scale and precision of Kufu's great pyramid obviously required a quality process. But were the ancient Egyptians systems engineers? This paper will outline how the pyramids were built, and whether that process satisfied the systems engineering Axioms.
4.4.3 It's the people that matter – applying a Systems Engineering approach to process improvement
Authors: Carver Elizabeth , Kemp Duncan
Published: November 2014

This paper describes approaches taken within the UK Warship Support Agency (WSA) and BAE SYSTEMS to implement improved Systems Engineering processes throughout complex supply chains. The supply chains needed to develop and support complex products, such as large aircraft or warships, require large teams to collaborate across organisational and cultural boundaries.

To be successful the extended enterprise needs business processes which are honed to drive down life cycle costs and which manage the key emergent capabilities such as safety, availability, flexibility, and reliability. Such business processes are heavily dependant upon the people in the system and those people represent a complex web of interdependant factors. Improving these processes, which are almost exclusively goal and knowledge based, therefore requires significant understanding of how to integrate diverse teams and cultures.

This paper describes the techniques used within the WSA's Enterprise Integration and Shared Data Environment Team and BAE SYSTEMS Advanced Technology Centre in understanding and improving complex goal and knowledge based processes. It describes how the teams analyse improvement requirements, and how they implement change in such a difficult, but critical, area.
5.4.4 Optimizing Distributed Software Architectures for Ground Based Weapon Systems
Authors: LaCerte Yves
Published: November 2014

Modern ground based weapon systems depend heavily upon electronics and software for correct and safe operations. Many of these ground based weapon systems exhibit behaviors from very different domains: automobiles (e.g. engines and transmissions), aircraft avionics systems (e.g. sophisticated sensors and advanced situational awareness), and hard real‐time industrial controls (e.g. weapon loading equipment).

This paper describes the fundamental approach to Crusader's software architecture and through specific examples, demonstrates that the Crusader software architecture is highly adaptable, provides a firm technical foundation for evolutionary growth, and is capable of supporting a family of ground based weapon systems.
6.4.1 A Case Study of the Near‐Catastrophic Mir‐Progress 234 Collision with Emphasis on the Human Factors/Systems‐Level Issues Surrounding this Mishap
Authors: Holland Dwight
Published: November 2014

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

This paper examines the architecture, development & implementation of a document information management system developed for a systems engineering core group. The intent of the paper is to provide an overview of the approach employed as well as provide insight into the requirements, drivers and the solution. This review also illustrates how the development team made use of systems engineering methods, processes, practices and heuristics. The Engineering Documentation System (EDS) is currently in use by the Systems Engineering department of the Military Aircraft and Missiles division of the Boeing Company.
6.4.4 Applied Systems Analysis and Fuzzy Optimization to Water Quality Management Problems
Authors: Doukas Louis , Sappakitkamjorn Jeerapa , Kildea Daniel
Published: November 2014

In this paper, we present a mathematical model to solve water quality management problems concerned with waste load allocation by integrating systems analysis and fuzzy optimization, to overcome two major difficulties; complexity and uncertainty. The main emphasis of this paper is to present a guideline in order to develop a fuzzy optimization model dealing with multiple conflicting goals between the Pollution Control Department and dischargers. Fundamentally, the goal of the Pollution Control Department is to maximize water quality whereas the goal of dischargers is to minimize the cost of wastewater treatment. The fuzzy optimization model considered in this research is one developed from multi‐objective fuzzy mathematical programming which provides a mathematical procedure for finding an optimal solution in decision‐making problems with conflicting goals despite lack of certainty. The model can be used as a decision‐making tool for managing water quality of any specific water body. It will not only suggest an optimal solution that leads to a compromise between the goals of the Pollution Control Department and the dischargers, but also aid in determining how much waste can be discharged into the water body without violating water quality standards.
6.4.5 Knowledge‐based decision‐support system design for water quality assessment in distribution networks
Authors: Zhou Huimin , Doukas Louis , Roddick Felicity
Published: November 2014

The work on Knowledge‐Based Decision Support System Design for Water Quality Assessment in Distribution Networks is presented. This paper outlines and summarises the essential activities such as, system definition, functions allocation, requirements specification, the prototype systems design, decision‐making processes, and the knowledge database development. The integration of these activities led to the successful application of systems engineering methodology. In addition, the effects of operating parameters such as, chlorine residuals, coliforms, pH value, iron, manganese, turbidity, and colour were assessed to provide a better understanding of the link among the chemical, physical, microbiological and aesthetic issues concerning drinking water supply security and safety.
1.5.3 Epistemological Issues in Representation of Things and Requirements Specification
Authors: Ferris Timothy L.J.
Published: November 2014

This paper discusses the problem of specification of the requirements for a project from the point of view of requirements as a representation of the hypothetical or target product. The relationship between the description and nature of things presented by epistemology is considered. Project requirements introduce the further problem of knowing the essence of things through the representation provided by a description, and that before construction the proposed product is hypothetical. This is presented and discussed.
2.5.1 Assessing the Reliability of Socio‐technical Systems
Authors: Gregoriades Andreas , Sutcliffe Alistair , Shin Jae‐Eun
Published: November 2014

This paper presents a Bayesian belief network (BBN) approach for socio technical system reliability assessment. A human error model (BBN) quantifies error influences arising from user knowledge, ability and task environment, combined with factors describing the complexity of user action and user interface quality. System reliability evaluation is achieved by the System Reliability Analyser tool, which enables the iterative manipulation of the human error model according to high‐level scenarios.
2.5.4 Modeling Objectives on Cost: Insight for Practitioners and Academicians
Authors: Snyder Frank J. , Parnell Gregory S. , Klimack William K.
Published: November 2014

Following a previous paper entitled Modeling Objectives on Cost in a Decision Maker's Value Structure, the authors present the results of survey research conducted to determine whether or not the objective of minimizing cost should be included as part of the fundamental objectives hierarchy when modeling a decision maker's value structure. Conclusions are drawn for both practitioners and academicians. For practitioners, the discussion addresses which technique those who know and use decision analysis prefer and why. Suggestions for using the two competing techniques both separately and together are offered. For academicians, as a by‐product of the surveys, survey results illuminate how much and what kind of decision analysis training and education is received by systems engineers, operations researchers, engineering managers, decision analysts, and others. Standard contingency table hypothesis testing is used to validate certain points.
3.5.2 Requirements Engineering with Goal‐Driven Use Cases
Authors: Kaffenberger Ruediger
Published: November 2014

In the wake of UML, use cases have become a popular means to capture requirements. But those who do requirements engineering and design at the system level are sceptic about their value, because use case descriptions in their popular form are perceived as inadequate at this level. The points of critique are that there is no precise definition of how a use case is to be described and no well defined method for the system level, tools exist only for Object Oriented Methodology.

The concept of use cases but comes in many flavours. Especially the goal‐driven use case concept aims at the system level. It retains the benefits of use cases and at the same time is suited to a wide range of applications. It has been designed to meet the following objectives:

It can represent the requirements of all kinds of stakeholders.

It can be refined or elaborated in well‐defined steps.

Existing information can be reused in a controlled way.

The use cases can be managed along with other forms of requirements by a single tool.

The use case concept presented here not only supports object oriented methods but also equally well the standard methods of design and development at the system level.
3.5.4 A COTS‐Aware Requirements Engineering Process: a Goal‐ and Agent‐oriented Approach
Authors: Chung Lawrence , Cooper Kendra
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. In requirements engineering, the focus has been on modeling the software engineering process and products for systems that are being built from scratch. As the size and complexity of systems continues to grow the use of commercial off the shelf (COTS) components is being viewed as a solution. Effective use of COTS components, however, requires a systematic approach that provides both a set of concepts for modeling the subject matter and a set of guidelines for using such concepts. In particular, the process needs to recognize and address the people oriented problems including the identification and resolution of conflicting goals, bridging the gaps between stated requirements and ‘approximately fitting’ components while still satisfying the customer. In this paper, we present a goal and agent oriented requirements engineering process model that explicitly addresses the use of COTS components. More specifically, we present (part of) our model for a COTS‐Aware Requirements Engineering (CARE) process and illustrate it using a Digital Library System.
6.5.4 CloudSat System Engineering: Techniques That Point to a Future Success
Authors: Basilio Ralph R. , Boain Ronald J. , Lam Try
Published: November 2014

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

The International Space Station (ISS) integrated verification process was developed to provide a disciplined systems engineering approach for the verification of the ISS specification requirements and to provide a traceable archive of verification data needed to sustain ISS operations. This paper describes and illustrates a tailored version of how Quality Function Deployment (QFD) and decision analysis techniques were used to restructure the ISS integrated verification process. This tailored approach has been accomplished to facilitate the use of QFD and decision analysis by systems engineers and can be used for other systems engineering processes for small or large‐scale integration programs.
1.6.2 Formalizing a Structured Natural Language Requirements Specification Notation
Authors: Cooper Kendra , Ito Mabo
Published: November 2014

Requirements specification notations are developed by organizations in order to meet their specific needs. For example, the Threads‐Capabilities notation, an in house notation at Raytheon Systems Canada, Ltd., has been developed and used for specifying their complex, large scale, air traffic control systems. It is a semi‐formal, structured, natural language notation. In this work, we investigate how to make this semi‐formal notation more rigorous (i.e., formal) by developing and applying a new formalization process to it. By doing this, we can obtain the advantages of formal methods (precise, unambiguous, automatic generation of test specifications, automated typechecking, etc.) while retaining the style and readability of the original notation. We call the formalized notation the Stimulus Response Requirements Specification (SRRS) notation. Our results have been successful for the specific notation. The formalized notation has been demonstrated to reduce the time and improve the quality of the requirements specifications. There is additional training time, however, needed to learn to use the notation and tools.
1.6.4 IT3‐Integrated Technology Training Template
Authors: Kwinn Mike , Balough Second Lieutenant Eric , Beach Jason , Nogic Dominik , Rains Matt , Williams Stuart
Published: November 2014

Due to an influx of new equipment into the military, the US Army and Project Manager (PM) Soldier have identified the need for a template which can be used to identify what type of training is best utilized for specific functions of the equipment used by soldiers, in order to begin training development earlier in the Army Acquisition Cycle. Using a complete functional decomposition of required tasks in the Army, we used the Multi Attribute Utility Theory (MAUT) to match training requirement tasks with the most appropriate training type taking into account objectives such as cost, time and training. The result is a comprehensive list of training requirements and their associated types of training as well as a Version 1.0 template that was used to make these connections. The use of this functional training template will allow PM's to start planning for training of the new equipment that they are producing much earlier in the development process. This reduction in training development lag time will decrease fielding time and increase the speed at which units are able to integrate new equipment and types of training.
2.6.1 Model Driven Design with Matlab
Authors: Reitz Elliott
Published: November 2014

The technical challenge of recognizing pertinent information on images of mail‐pieces (such as indicia) has encouraged the integration of multiple technologies into a complex modelling environment. The modelling environment was developed to build and select the appropriate algorithms and subsystem component designs. A C/C++ library has been developed for components of the system model that are selected for product application. Prototyping has been extensively used in all of the environments. Example products developed with this approach that have been delivered to customers include: a classifier algorithm for character recognition (USPS RIP2), a Pre‐sort‐Label detection device (USPS APPS CFT), and a Non‐Address‐Attribute‐System for recognition of indicia (UK Royal Mail Address Interpretation). The results have exceeded expectations for schedule, performance, and development costs.
2.6.3 From function‐driven Systems Engineering to object oriented Software Engineering
Authors: Hoffmann Hans‐Peter
Published: November 2014

This paper describes a model‐based system and software development process that combines both function‐driven systems engineering and object oriented software engineering. The key part of this “Integrated Process” is the “Bridge” between the two paradigms. Tools chosen to demonstrate the Integrated Process are the I‐Logix tools Statemate® Magnum, for the function‐driven systems engineering, and Rhapsody® in C++ for UML‐based software engineering. Rules can be established on how an architectural design model built with Statemate will be translated to a UML model for further software design and implementation with Rhapsody. The outlined mapping is not limited to Rhapsody. Rather, the Statemate‐to‐UML Bridge is equally applicable to any UML‐based software design automation tool.

Initially conceived for the design and development of highly complex embedded systems in aerospace/defense applications, the process is also applicable to other industrial applications.
3.6.3 Where Does Software Engineering Begin During Systems Engineering?
Authors: Lee Carol Sue
Published: November 2014

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

Human‐system interactions have been largely overlooked in the traditional systems engineering process. Awareness of human factors (HF) has increased in the past few years, but the involvement of HF specialists is still often too little and too late. In systems involving long‐duration human space flight, it is essential that the human component be properly considered in the initial architectural definition phase, as well as throughout the system design process. HF analysis must include not only the strengths and limitations of humans in general, but the variability between individuals and within an individual over time, and the dynamics of group interactions
5.6.3 Lessons Learned Applying Tools and Methodologies to Develop C4ISR Architecture Framework Compliant Architecture Products
Authors: Rice David , Meilich Abraham
Published: November 2014

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

In 1997 the Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) Architecture Framework Version 2.0 was released as a guide for the U.S. Department of Defense (DoD) in the development of system architectures. This Framework was developed under the auspices of the C4ISR Working Group consisting of representatives from the Joint Staff, the military services, the Office of the Secretary of Defense, and other Defense agencies. The main motivation for the C4ISR Framework has been to ensure that architectures are interrelatable as well as comparable and integratable across Joint and multinational organizational boundaries. DoD, supported by recent government legislation, will pursue the development of more interoperable, integrated systems to meet the challenges posed now and in the future. Developed to focus on information technology, the C4ISR Framework is finding broad application in the DoD community. The C4ISR Framework serves as a consistent guideline on how architectures should be described by calling out a number of views serving operational, system, and technical interests. The need for consistency and guidance is clear. What is not clear however, is how this guidance will influence engineering activities being conducted on DoD programs. Application of the C4ISR Framework is very much in the pioneering stage. Experience is needed to set examples and teach lessons as with anything new. This paper offers some experience by developing an operational architecture view in an application to Air Defense.
2.1.1 Using a Knowledge Management Tool to Improve U.S. EPA's Enterprise Architecture
Authors: McMahon Ethan , Sullivan John
Published: November 2014

Enterprise architecture (EA) is a process for ensuring that an organization's information resources are aligned with its goals and business. EA can be used for several purposes, such as improving business processes that are performed across an organization and integrating information management resources. For EA to achieve its potential, it is important to use an EA tool for housing and analyzing the organization's information. The U.S. Environmental Protection Agency (EPA) is using such a knowledge management tool, called the Architecture Repository and Tool (ART), that is based on Metis software from Computas. ART can be used to identify which organizations perform the same business processes and to highlight opportunities for storing commonly used data. This paper illustrates how ART is a knowledge management tool that can reveal an organization's gaps, weaknesses, and opportunities for improvement.
2.1.2 Application of the Systems Engineering Approach to the Tritium Extraction Facility Design
Authors: Simpkins Philip
Published: November 2014

The Commercial Light Water Reactor ‐ Tritium Extraction Facility is being designed and built as a tritium processing facility at the Savannah River Site (SRS) in South Carolina. When built it will be the only facility processing tritium in the United States. The design of this facility required some equipment to be designed as ‘one of a kind‘. The Systems Engineering (SE) approach was applied to define the functions and requirements necessary to design and operate the facility. The SE approach for the Tritium Extraction Facility (TEF) was a major effort encompassing Requirements Analysis, Risk Management, Interface Control, and supporting plans and documentation for the facility and 23 major systems. This paper will describe the SE approach in general and give examples of selected Functions and Requirements (F&Rs) supporting the TEF design. Also presented will be advantages of using the SE approach on the design of the TEF and observations made during the design process.
4.2.4 Organizational Implications of “Real‐Time Concurrent Engineering“: Near Term Challenges and Long Term Solutions
Authors: Stagney David B.
Published: November 2014

In late 2001, a product development team was assembled at a major aerospace corporation to create an innovative product design process based on the concepts of Integrated Concurrent Engineering (ICE).

R&D funding for the “Real‐Time Concurrent Engineering” (or “RTCE“) project ended in late July of 2002 even though the tools and processes that had been developed were providing a great deal of value to the company. In response, the team leadership struggled to craft a new vision for their project and to understand some of the unexpected barriers they had encountered within their own company.

This paper discusses the organizational challenges that the pioneering RTCE team faced. The issues are categorized into four major groups: Organizational Structure, Organizational Culture, Leadership and Finance. Strategies for near term re‐vitalization and long term value‐creation are proposed in the context of a new project implementation model.
5.2.3 Breaking the 5‐Sigma Barrier with Systems Engineering
Authors: Gianacakes George
Published: November 2014

Many organizations have successfully implemented Six Sigma (6σ) quality programs, but have begun to hit what they call the 5‐sigma barrier — they have discovered that you can only get so much quality improvement from the back end of the development process. To overcome this 5‐sigma barrier, organizations are increasingly adopting the Design for Six Sigma (DFSS) methodology that in many ways reflects the “systematics” of product development. This paper examines the Six Sigma and DFSS approach and how DFSS in essence is a “Statistical Systems Engineering” approach that can achieve six‐sigma levels and beyond in product development.
6.2.1 The Ten Most Powerful Principles for Quality in Systems Engineering and Software
Authors: Gilb Tom
Published: November 2014

We know we need better engineering control. But which solutions work? What are the most fundamental underlying principles we can observe in successful projects? This paper presents 10 powerful principles, that are neither widely taught, nor appreciated. They are based on ideas of measurement, quantification and feedback. Our maturity level with respect to ‘numbers’ is poor. Within projects, many of our most critical measures are often not quantified, when they should be. Hopefully, as we move to higher maturity levels we will begin to appreciate the power of numeric expression for qualities such as security, portability, adaptability, maintainability, robustness, usability, and reliability. Decide to make them numeric on your project. Draft some more‐numeric requirements today, surprise your team tomorrow!
3.3.1 Systems Engineering With Solution Spaces
Authors: Hause Matthew , Thom Francis
Published: November 2014

When creating UML models of systems, a common strategy is to model all the elements as classes. This technique is inadequate, because eventually the element has to represent something in a given solution space. Instead, the system should be modeled using a library of Systems Engineering concepts that can be applied to the problem. In this paper, we propose using Systems Engineering profiles, patterns, concepts and standards, corresponding to solution spaces to model the system and support both the product and the process. These can be used throughout the system lifecycle, from modelling the concepts and physical environment in the requirements stage, to creating physical systems from the model during the implementation stage. This library, or ontology, could be built up over time to create a Systems Engineering Body of Knowledge (SEBOK), allowing reuse of requirements, concepts, and problem‐solving techniques.
4.3.1 Formalizing Informal Stakeholder Requirements Inputs
Authors: Kitapci Hasan , Boehm Barry W. , Grünbacher Paul , Halling Michael , Biffl Stefan
Published: November 2014

Often, the stakeholders who can contribute the most value and realism to system requirements are the ones with the least time available to participate in the process. We have found the EasyWinWin requirement negotiation method and tools to be an effective way to involve such busy stakeholders. It avoids time‐consuming group wordsmithing, but results in relatively informal win‐win agreements (e.g., “24/7” or “anytime, anywhere” vs. more precise availability and accessibility requirements). For the past three years, we have been using EasyWinWin to capture informal requirements from stakeholders in an annual series of 15‐20 University of Southern California (USC) electronic services projects. In the context of these projects, we have been exploring alternative methods for formalizing these informal requirements inputs, including natural language processing, keyword analysis, template‐based refinement, formal methods expertise, and inspections. The paper summarizes our analysis of the relative strengths and difficulties of using these methods and our approach during the USC e‐services applications projects.
5.3.1 Training Systems Engineers for System Acquisition
Authors: Fisher Jack , Humel Paul F. , Fisher Gerard H.
Published: November 2014

An experiential systems engineering training program developed for a customer of the California Institute of Technology Industrial Relations Center (IRC) was described in a previous paper (Fisher 2001). This program was modified under the sponsorship of the IRC and the Aerospace Corporation's training organization, the Aerospace Institute, to provide systems engineering training for Air Force personnel from the Space and Missile Systems Command.

The course now includes eight full‐day class meetings over a period of 14 weeks with an instructor‐defined class‐long exercise requiring the design of a satellite system. Two courses were conducted in parallel, offset by one week. Each class of 24 students was divided into two teams. The exercise requires each team to develop a system with a number of pre‐defined steps that are described by the instructor tutorials. The exercise originates with an instructor‐prepared system requirements document and culminates with a student‐prepared Preliminary Design Review, life cycle cost estimate and risk management plan. The tutorial material prepares the students for each step in the system development process. Each 8‐hour class meeting involves a tutorial by the faculty as well as student team reports describing their progress with the exercise.

Modifications to the earlier program include the addition of a class meeting utilizing the facilities of the Aerospace Concept Design Center (CDC). The CDC provides the capability to derive space system characteristics with computer‐based mathematical models. This allows the students to conduct tradeoff analyses to select a system design concept from the possible alternatives.
6.3.2 Deployment of SE including Manufacturing Systems development: Practical Aspects
Authors: Lardeur Etienne , Auzet Christian
Published: November 2014

Nowadays, the improvement of engineering efficiency is presently one of the most important issues in the field of industry. Engineering coordination through information control is often taken as means to solve this issue. PSA Peugeot Citroën has decided to explore this approach, and has consequently decided to deploy Systems Engineering. SE provides an adequate and structured approach for the development of the new vehicles. Because of its industrial background, the SE Framework of an automotive company must take into account the development of the vehicles and the related manufacturing systems. This study is the answer ‐ on practical aspects ‐ to the following problematic: how may optimal co‐ordination of the engineering of a complex and mass product and its associated manufacturing systems can be concretely be achieved? This paper presents the practical aspects of a Ph.D. study, while another submitted and accepted paper presents the theoretical aspects of the same study.
3.4.1 Traceability: A Systems Integration Perspective
Authors: Mason Paul , Arkley Paul , Riddle Steve , Saeed Amer
Published: November 2014

It has been argued previously that system integration requires a controlled environment, which in turn demands a number of integration and management undertakings (Sage & Lynch, 1998). This paper considers one such undertaking, information integration and management, and in particular, means of managing and tracking information across disjoint CASE tools.

A taxonomy is proposed that defines a conceptual framework for traceability in a systems integration context. The framework is realised by exporting information from the internal models of tools to an integrated environment consisting of: i) a Workspace comprising a set of structures or meta‐models expressed in a common modelling language representing selected notations for which tool support exists; ii) well‐formedness constraints over these structures capturing properties of the notations; and iii) associations between the structures. To maintain consistency, the structures are verified against a further structure that defines common building blocks underlying the various notations.
6.4.3 Risk Informed Design for System Life Cycle
Authors: Hill Ralph S. , Nutt Mark W.
Published: November 2014

Many facilty life cycle activities including design, construction, fabrication, inspection and maintenance are evolving from a deterministic to a risk‐informed basis. The risk informed approach uses probabilistic methods to evaluate the contribution of individual system components to total system performance. Total system performance considers both safety and cost considerations including system failure, reliability, and availability. By necessity, a risk‐informed approach considers both the component's life cycle and the life cycle of the system.

In the nuclear industry, risk‐based approaches, namely probabilistic risk assessment (PRA) or probabilistic safety assessment (PSA), have become a standard tool used to evaluate the safety of nuclear power plants. Recent studies pertaining to advanced reactor development have indicated that these new power plants must provide improved safety over existing nuclear facilities and be cost‐competitive with other energy sources. Risk‐based approaches, beyond traditional PRA, offer the opportunity to optimize design while considering the total life cycle of the plant in order to realize these goals.

The use of risk‐based design approaches in the nuclear industry is only beginning, with recent promulgation of risk‐informed regulations and proposals for risk‐based codes. This paper briefly summarizes the current state of affairs regarding the use of risk‐based approaches in design. Key points to fully realize the benefit of applying a risk‐based approach to nuclear power plant design are then presented and illustrated in a case study. These points are equally applicable to non‐nuclear facilities where optimization for cost competitiveness and/or safety is desired.
6.5.1 Information System Security Protection Levels—Enabler for a Secure Millennium National Air‐Space System
Authors: Keblawi Feisal , Fujisaki Norm , McGowan Shirley Brewer , Sullivan Dick
Published: November 2014

Critical infrastructures, such as the National Airspace System (NAS), offer a challenging set of information security and systems engineering problems. In 1997, the President's Commission on Critical Infrastructure Protection made protecting critical infrastructures in cyberspace a part of the national agendai. Post 9/11, the flying public expects the Federal Aviation Administration (FAA) to apply the right level of focus to ensure safe air travel. Besides understanding the changing threat environment and managing wide‐ranging vulnerabilities, progress depends on improving systems engineering approaches that unify cyber security in mammoth infrastructures such as the NAS. An important ingredient to the FAA's success lies not only in the technology, but also in the agility of corporate infrastructures that protect the NAS. Corporate security applies to the people and the processes that work behind the scenes to integrate appropriate technology and processes to obtain adequate and timely levels of security. As well, corporate security seeks sufficient funding to support the overarching goals for FAA “Information System Security (ISS) Protection Levels,” described here. The ISS Levels offer a strategy for achieving agile and survivable cyber protection for complex systems of systems.
7.5.2 Agile Systems Engineering for Rapid Project Solution Development
Authors: Wilson Mark A. , Mooz Harold (Hal)
Published: November 2014

Systems engineers are frequently reminded of the need for “agility” in many ways. We are encouraged to use “agile methods” to develop systems of systems that are “agile performers,” and have inherent “agility,” meaning they can easily and rapidly adapt to continually changing requirements. It seems that “agility” has become management du jour.

The concepts of agile development have been prominent in current technical literature. Some writers contend that the underlying fundamentals of agile methods are significantly different from those of traditional development methods. We believe there are agile best practices that have value across a spectrum of development situations. This paper will propose a working definition of agile development as it relates to project management and systems engineering and describe seven key practices of the “Agile Systems Engineering” process. We will leave an examination of agile performers and agile designs to a future paper.
7.5.3 Management of Enterprise Administrative Systems Implementation at United States Capitol Police
Authors: Valivullah Michael , Getter James R. , Kaisler Stephen H. , Armour Frank
Published: November 2014

This paper describes our management of the systems modernization effort at the United States Capitol Police (USCP). The Enterprise Architecture of the United States Capitol Police comprises six broad categories of business applications. Of these six, two represent clusters of IT applications: the administrative information systems (AIS) and the operational law enforcement information systems (LEIS). The Enterprise System Architecture is comprised mainly of these two systems. A number of guiding principles are used to manage these systems modernization activities. One of those guiding principles is to use commercial off the shelf (COTS) products as much as possible to reduce development time and implementation costs. In some cases, we were able to successfully implement COTS products with little or no modifications. However, in others, the COTS products needed extensive modifications due to new, unique or evolving business needs. This paper will discuss the management strategy used to select, consolidate, modify, test and implement systems within the framework of USCP's enterprise architecture. This paper also discusses lessons learned from our system upgrade, conversion, consolidation, migration, integration and modernization experiences.
3.6.4 Discrete System Optimization Using Cost as an Independent Variable (CAIV) Techniques With Distributed Analysis Models
Authors: Malone Brett , Woyak Scott
Published: November 2014

A design environment has been constructed to assist designers and analysts in performing concept studies and optimization based on distributed analysis to support cost as an independent variable (CAIV) studies. This environment uses application server‐based techniques to host distributed simulations and analysis tools. These components are then linked through a common client interface to build an integrated model. A set of unique design exploration tools provides the analyst with a decision support environment for performance, cost, and operational assessments. A design example based on this architecture is shown. This example illustrates discrete configuration selection of platform and sensor types based on a non‐gradient based optimization algorithm to defeat various threats given system cost constraints.
6.6.3 Meeting the Needs of Hydrographic Surveying: A Case Study of the Requirements Development Process
Authors: Collier Wayne M. , Shih H.H.
Published: November 2014

A long‐standing challenge in oceanography and hydrographic surveying is accurate real‐time measurement of offshore water levels. The advent of recent techniques and technologies has afforded an opportunity to address this challenge. This paper will discuss the requirement development process as it related to specifying requirements for GPS‐tracked buoy for hydrographic survey applications at the National Oceanic and Atmospheric Administration (NOAA). How stakeholders from a variety of technical disciplines collaborated to develop requirements to meet and solve an important operational need via a Small Business Innovation Research (SBIR) grant will be explored.
6.6.4 The Architecture of Problem Resolution During Assembly of the International Space Station
Authors: Johnson Harry F. , Dagli Cirhan H.
Published: November 2014

This paper describes the architecture for solving U.S. on‐orbit hardware/software problems on the International Space Station. Problems are partitioned, prioritized and coordinated and worked via a combination of monitoring, testing, commanding the vehicle, analysis, meetings, e‐mails, formal written requests, and presentations. Progress is measured against prioritized criteria. Throughout, system architectural heuristics are employed. The key heuristics utilized in solving some of the complex problems are examined for their effectiveness.
7.6.1 Integrated Rollout Project Plan Modelling Tool
Authors: Simmins John J. , Quaglio Kenneth , Appel Peter , Boteler Laura
Published: November 2014

The purpose of the Integrated Rollout Project Plan Modeling Tool is to provide a consistent approach to develop rollout plans for a variety of projects and to provide a program management tool to manage key program office analysis and reporting requirements during rollout. The tool captures those attributes that differentiate the rollout at one location from the next and dynamically builds each individual plan to reflect those different attributes. The tool was can collect inputs and dependencies across various functional groups including: Accounting, HR, Manufacturing, Quality, Shipping, Marketing, etc.
3.7.1 Process Implementation
Authors: Sheard Sarah A.
Published: November 2014

Process improvement requires two major steps. First, new processes must be defined (or existing processes modified). Second, the organization must begin to use those new or changed process descriptions. The literature has provided good guidance on writing new process descriptions, but very little has stated clearly what actions must be taken to implement and then institutionalize the use of the processes. This paper provides a list of implementation and institutionalization actions that organizations should consider to ensure that the new processes are used. These actions fall into the categories of training, ensuring management support, obtaining a measurement baseline, auditing the use of the processes, collecting and maintaining a library of process assets, tailoring the processes, improving the processes, and appraising the organization.