bluuebunny/crossref_metadata_2025 huggingface dataset:
Oxidation Catalysis by Rationally Designed Artificial Metalloenzymes
Authors: Marchi‐Delapierre Caroline , Rondot Laurianne , Cavazza Christine , Ménage Stéphane
Published: November 2014

The principle of enzyme mimics has been raised to its pinnacle by the design of hybrids made from inorganic complexes embedded into biomolecules. The present review focuses on the design of artificial metalloenzymes for oxidation reactions by oxygen transfer reactions, with a special focus on proteins anchoring inorganic complexes or metal ions via supramolecular interactions. Such reactions are of great interest for the organic synthesis of building blocks. In the first part, following an overview of the different design of artificial enzymes, the review presents contributions to the rational design of efficient hybrid biocatalysts via supramolecular host/guest approaches, based on the nature of the inorganic complex and the nature of the protein, with special attention to the substrate binding. In the second part, the original purpose of artificial metalloenzymes has been twisted to enable the observation of transient intermediates, to decipher metal‐based oxidation mechanisms. The host protein crystals have been used as crystalline molecular‐scale vessels, within which inorganic catalytic reactions have been followed, thanks to X‐ray crystallography. These hybrids should be an alternative to enzymes for sustainable chemistry.
Risk Management in a Complex Development Environment: An Example
Authors: Nolte Jerry , Damsky Mike
Published: November 2014

Risk management is a hot topic that most Systems Engineers consider important, however, many differ in the strategy of implementation. Most Systems Engineers use different ad hoc methods, based on their own experience, along with structured methodologies to implement risk management This paper describes a general structure for risk management in a development environment. The paper also describes the implementation of this general risk management plan for a specific development project extended over two years. The paper presents the lessons learned on doing risk management for this project along with a strategy for implementing risk management on future problems.
TRACEABILITY FOR COMPLEX SYSTEMS ENGINEERING
Authors: White Stephanie
Published: November 2014

Improved requirements traceability would result in significant cost savings since more requirements problems are due to failures in requirements management than failures in technical functions. Without adequate requirements traceability, errors are found late in system development and are expensive to repair.

Our research identifies problems with industry's capability to trace product and process information, and offers some solutions1. We have defined a unique method, Concurrent Stimulus‐Response Threads (CSRT), that traces complex system behavior. Based on CSRT and Entity‐Relationship modeling, we make recommendations that will improve traceability in two requirements methods, Requirements Driven Design (RDD), and Real‐Time Structured Analysis (RT‐SA).
REQUIREMENTS MANAGEMENT: DOORS TO THE BATTLEFIELD OF THE FUTURE
Authors: Rundlet Nancy , Miller William D.
Published: November 2014

The integration of systems to create a stable, robustsystem of systemsposes challenges to systems engineering management when the individual systems already exist, are numerous and rapidly evolving. The Dynamic Object Oriented Requirements System (DOORSTM) introduces advanced object‐oriented techniques to manage the complexity of large numbers of inter‐linked requirements. DOORS provides an easy‐to‐use, online environment. Different on‐line views of the project status are available in both text and hierarchical graphical formats by filtering and sorting on the attributes of the objects. This object‐oriented approach to requirements management is extended to provide agroupwaresystems engineering management environment in support of the U.S. Army's program todigitizethe battlefield of the future. The Army's intent is to improve their comparative advantage in combat effectiveness over that of potential adversaries. The magnitude and complexity of the effort to manage the project compared to classical requirements management methodologies and tools are discussed.
RE‐VIEWS A REQUIREMENTS STRUCTURE AND VIEWS
Authors: Edwards Michael , White Stephanie
Published: November 2014

Numerous stakeholders collaborate to develop the system requirements for a complex system. They conceive needs, evaluate risk, cost and benefits, identify tradeoffs, and negotiate priorities over a considerable period of time. Government and industry need a structured approach to requirements elicitation that completely captures stakeholder requirements and supports necessary analysis, tradeoffs, and negotiation. Automated support for this collaborative process is a long term goal of our research 1. Our initial goal is to develop a firm foundation for capturing requirements and supporting different views. This paper discusses the need for a structure that supports requirements capture and the advantages of such a structure, identifies problems in developing a structure, and provides a high level description of information that should be captured.
REQUIREMENTS MANAGEMENT IMPLEMENTATION ROADBLOCKS
Authors: Simon Beth E.
Published: November 2014

In trying to implement requirements management on a project, several roadblocks may be encountered. By knowing the difficulties others have encountered, you will be able to anticipate the roadblocks and plan how to deal with them. This paper is part of a series being developed by the NCOSE Requirements Management Implementation Subcommittee of the Requirements Management Committee. Follow on papers will focus on solutions to the problems outlined.
Structured Requirements and a Systems Engineering Environment
Authors: Stevens Richard
Published: November 2014

A requirements management system forms the natural framework for a systems engineering environment (SEE). Requirements control the whole system, and cover the whole lifecycle. Requirements are the means of communication between systems engineers and all the specialist disciplines. A SEE based on requirements allows control at any required level of detail. This approach allows an incremental approach to developing a complete project toolset. This paper defines a SEE, in relationship to a commercial requirements management tool, DOORS.

Systems engineering covers systems‐level tasks, such as the creation of requirements, technical management, and verification management. Tools used for specialist tasks remain outside the SEE although it will need to communicate with those.
GENERATING OPERATIONS BASED REQUIREMENTS
Authors: DeFoe Joseph C. , McAuley James E.
Published: November 2014

This paper presents a process for generating capability requirements based upon intended/needed operations and mission objectives. The process addresses the uncertainties associated with:

Understanding the customer/user problem

Selecting analysis and documentation methods best suited to the problem.

The uncertainty associated with the customer/user problem is addressed by having the process stringently separate the analysis phase from the requirements (“shall”) statements documentation phase.

The uncertainty associated with analysis and documentation methods is addressed by having the process include an early phase in which one typical capability is analyzed in depth and then abstracted into requirements statements. The objective is to select and tailor methods prior to addressing the full range of capabilities that need to be specified.

This paper also identifies the value that the current system modeling methods bring to the process.
BREATHING SE LIFE INTO EXISTING DOD PROGRAMS
Authors: Kepchar Kenneth J.
Published: November 2014

The mid‐stream integration of a formal Requirements Management (RM) process into an existing Department of Defense (DOD) program with a traditional approach to design&development poses special challenges. A number of compromises are necessary to avoid disrupting the design processes that are in place and functioning on the program, while changing the traditional view of the design community on identifying and verifying proper implementation of requirements. Experience on a follow‐on development program, the F/A‐18E/F, illustrates some of the benefits and difficulties involved.
Strategies For Sustaining Competitive Advantage Through Product Development: A System Engineering Framework
Authors: Sherry Lance
Published: November 2014

Competitive advantage in an industry can be achieved by strategically entering a marketplace at the right time with a product that has the appropriate cost and operational capability to match the needs and maturity of the marketplace. In products (such as software‐based products) where the cost and time‐to‐market are primarily a function of the “intellectual” engineering process, the product development function is the source of competitive advantage.

This paper introduces a system engineering framework that describes the relationship between product operational capability, development cost, and development cycle‐time (time‐to‐market). Analysis of this relationship yields four strategies for achieving and sustaining competitive advantage through product development.
RAPID PROTOTYPING IN REQUIREMENTS SPECIFICATION PHASE OF SOFTWARE SYSTEMS
Authors: Ghajar‐Dowlatshahi Jahangir , Vernekar Ashok
Published: November 2014

End‐user involvement in the requirement specification phase is essential for the success of a software product. Software developers and architects must be able to easily and accurately translate the requirements to software codes; visualize interdependencies among different functions, objects and rules; and understand system limitations.

Using the rapid prototyping technique in the requirement analysis and specification phase is one way of achieving the goals of high quality software, lower development cost, on‐time delivery and user satisfaction.

This paper discusses the use of the rapid prototyping technique in the requirements phase of a software development cycle. It describes the advantages of using prototyping in all applications, especially in the design and development of systems which have complex user interfaces. The paper explores the user‐centered approach in relation to the rapid prototyping technique.

The rapid prototyping technique has been successfully used in several AT&T software projects. This paper also includes the authors' experiences in applying the technique to software projects.
REQUIREMENTS MANAGEMENT COST/BENEFIT SELECTION CRITERIA
Authors: Honour Eric C.
Published: November 2014

This paper explores thç practical costs and benefits of managing individual requirements statements by different methods or tools. A relatively simple evaluation is offered using fill‐in‐the‐blank entries in a form. The evaluation considers improvement costs, process costs, and requirements change management costs. The evaluation considers benefits due to more complete requirements management, better change management, and reduction in excess technical features. The evaluation result is a practical algebraic benefit/cost ratio, which is a criterion to determine the relative worth of alternative methods. Using the author's heuristics, the paper applies the evaluation criteria to several typical decisions faced by companies today. Results confirm that program‐wide use of modern databasing tools makes financial sense for large programs, while small programs can effectively use well‐managed requirements lists.
A Brave New World: Melding Systems and Software Engineering
Authors: Downward Bernadette Gagnon
Published: November 2014

The introduction of Mil‐Std‐SDD (to be named Mil‐Std‐498), “Software Development and Documentation”, in conjunction with Mil‐Std‐499B, “Systems Engineering”, will redefine the development, reuse, and evaluation of software throughout a project's life cycle. This definition is being driven in an attempt to quantify the software development process. The focus of this paper is to explore how these changes will affect the systems engineering process. The process of systems engineering as defined by Mil‐Std‐499B is compared to Mil‐Std‐SDD. An interpretation is presented of the boundaries of systems and software engineering activities proposed within the framework of these new standards.
Creating an Effective Business Environment for Developing Computer‐Assisted Systems Engineering Environments
Authors: Epperson Roy E.
Published: November 2014

This paper discusses some of the factors that affect the ability to create a computer‐assisted system engineering environment (CASEE). The system engineering community needs to consider and take action on them as it adopts automated tools and tool integration. The assumption is made that the reader has or desires to add computer assisted tools to their system engineering organization.

These observations are based on the author's experience working with customers in several industries to define project support environment requirements for system and software engineering.
THE THEORY OF TESTING APPLIED TO THE DEVELOPMENT OF A SYSTEM ENGINEERING METRIC
Authors: Ashburner Edmund J.
Published: November 2014

Any discipline which wishes to optimize its performance must, at some point, develop a testing mechanism to compare the results of various attempts at improvement to determine which were successful and which were not. The knowledge of testing and measurement methods developed in other disciplines such as Education and Psychology can be applied to the System Engineering field to help us develop such an evaluation mechanism. The results of an initial investigation suggest that three factors should be used as primary goals of any such “Metric”; they are Reliability, Validity, and Usability. In addition, the limits and potential application of such a Metric can be derived. Without the structure of this (or some similar) approach, the quest for a useful and accurate measurement technique for the System Engineering process will prove to be as elusive as that for the “Holy Grail”.
A LEADERSHIP ROLE FOR NCOSE
Authors: Aslaksen Erik W.
Published: November 2014

This paper is concerned with the current state of Systems Engineering as a distinct discipline within engineering. It is argued that a main impediment to the acceptance and usefulness of Systems Engineering is the lack of precise and agreed operational definitions of the main concepts, such as system and state. This would be an area where NCOSE could take a leadership role, and a set of possible definitions is proposed.
THE MORPHOLOGICAL APPROACH: ITS ROLE IN SYSTEMS ENGINEERING AND ITS APPLICATION TO SOLAR ENERGY CONVERSION
Authors: Jackson Scott , Drubka Robert E.
Published: November 2014

This paper discusses the morphological approach, a methodology first proposed by (Zwicky 1969) and shows how this approach would enhance the systems engineering process. The morphological approach determines the requirements and design solutions of any system by considering the totality of all solutions. Examples of solar energy conversion studies conducted at McDonnell Douglas Aerospace (MDA) are shown to illustrate the approach.

The morphological approach is a key ingredient in first‐order systems engineering (FOSE), the combination of which allows the analyst to examine all possible options at minimum cost before the design phase is initiated. Hence, it is recommended that the morphological approach, along with FOSE, be incorporated as integral parts of the SE process.
System Engineering Manual Update
Authors: McGee Allen , Khouri Jennifer
Published: November 2014

Lockheed Missiles & Space Company (LMSC) has used the system engineering process throughout the history of the company. However, the process was not formally released as a system engineering manual (SEM) until 1985. Space Systems Division (SSD) of LMSC is currently updating the SEM to reflect proposed changes to the associated military standard (MIL‐STD‐499), projected changes in our business base (a shift toward commercial ventures), and updates in technologies and methodologies used in system engineering (including new computer‐based analysis tools and Continuous Quality Improvement {CQI} methods). Many changes to the manual are due to a sweeping reorganization of the material such that the new manual has sections that are organized around system engineering functions. The functions used come from a list derived by the National Council of System Engineers (NCOSE) Process Working Group Committee. The SEM defines how SSD system engineers do business, is the basis for proposals, and serves as the core of our system engineering training program.
Design Reviews: Highly Lucrative Targets for Process Improvement
Authors: Wyman James P
Published: November 2014

This paper is a case study taken from the F/A‐18E/F Initial & Preliminary Design Reviews conducted during Sept 92 and Jun 93 respectively. These highly successful events serve as models from which the design review process can be documented, analyzed and improvement initiatives identified. The end objective is an improved process, road map and game plan that will lead to future successful Design Reviews. Key to the development of this road map, and the implementation of a game plan that would guarantee Design Review success is the clear understanding of:

Who is the real customer for the Design Review.

What are the customer expectations relative to the Design Review product.

What are the customer's quality requirements.

What processes will be employed to develop and deliver the product that will satisfy those requirements.

Post Design Review Presenter survey results and Design Review Process Improvement Team (DRPIT) findings and recommendations serve as the basis for process and product quality improvement initiatives with “real world” applicability to a wide range of acquisition programs. These initiatives will be implemented in preparation for future Design Reviews.
A SYSTEMS ENGINEERING ANALYSIS FOR RE‐ENGINEERING AN ORGANIZATION
Authors: Granata Raymond L. , Oran William A. , Beyer David S. , Mayer D. Stephen , Mackey William F. , Yost Robert F. , Van Nostrand George C. , Karlin Jay J. , Bagg Thomas C.
Published: November 2014

A multicontractor/government systems engineering team analyzed a government organization in order to develop recommendations to re‐engineer its activities and improve its processes in terms of both efficiency and quality. The organization was NASA/Goddard's Mission Operations and Data Systems Directorate (MO&DSD), which 24 hours/day, 7 days/week supplies services including data capture, data processing, operations, and communications between orbiting spacecraft and ground based investigating teams. The service operations and the underlying organizational processes were analyzed using a systems engineering approach assisted by tools consisting of a Total Quality (process) Model (TQM) instituted by AlliedSignal Corp. and the Viable Systems Model (VSM) which has its genesis in management cybernetics. Aspects of both the TQM and VSM are discussed and compared along with their application in analyzing the processes of MO&DSD. Both analyses resulted in numerous recommendations to improve MO&DSD's activities including administrative, personnel, and operational procedures. The similarities and differences in the recommendations are compared along with a discussion of the use of these two analytical techniques.
Systems Engineering and Object Technology
Authors: Oliver David W.
Published: November 2014

This paper extends Systems Engineering methods to include object technology, which has been developing in modern software engineering, (Rumbaugh et. al. 1991). It applies the principles of Model Based Systems Engineering, MBSE, (Oliver 1993a), (Oliver 1993b) to the systems engineering process itself. This results in a layered process description which is tailorable and supports aerospace or commercial methodologies.

Multiple phases of engineering ‐ concept phase, requirements analysis phase, and systems architecture and design phase ‐ are supported with a single core set of engineering steps. The additions of semantics and notations from object technology provides a capability to describe the choices of components and the mapping of behavior to components that lead to alternative architectures. Strong emphasis is placed on the systems engineering traditions of trade‐off analysis and sequential build and test which have been weak in software engineering methodologies.

The joining of systems engineering with object technology provides a seamless engineering path for projects which will implement software in an object‐oriented fashion. Integration with existing methodologies is straight forward because existing methodologies can be defined by selecting among the core MBSE steps.
ROLE OF REDUCTIONISM AND EXPANSIONISM IN SYSTEM DESIGN AND EVALUATION
Authors: Clymer John R.
Published: November 2014

Reductionism is based on the assumption that any complex system can be decomposed into a set of indivisible components that operate independently of each other. Interactions among components are based on cause and effect relationships described by a mechanistic model Expansionism is based on the assumption that a component is understood as it relates to a larger whole. It is possible, that in a mechanistic sense, a component may seem to operate properly when evaluated based on cause and effect; however, from an expansionist point of view the component may not adequately contribute to the goals and objectives of the system as a whole. In order to detect such problems early and minimize development time and cost, the expansionist view is applied during conceptual design To facilitate expansionism during conceptual design, an explicit operational model is applied that can assist understanding global context sensitive interactions that can cause problems later. To evaluate the architecture, the operational model is expanded, during system design, to include structural details.
SCRABBLE® ‐ A COLLABORATION TRAINING TOOL
Authors: Lentz Virginia A. , Stanford Jean C.
Published: November 2014

SCRABBLE®, (traditionally played as a competitive game) can be used to demonstrate the benefits of collaboration and enterprise‐wide visibility in support of alternative product development strategies. Observing individual and team play using a SCRABBLE exercise has strong corollaries to how we manage the system and product development businesses.

The authors have modified the SCRABBLE rules of play to create our exercise used with hundreds of students. In the process, we validated a number of management and systems engineering rules of thumb. The exercise rules and observations in the areas of organization, team norms, productivity and status tracking are discussed. We describe how we build on these lessons in our systems engineering courses.
AUTOMATING SYSTEMS ENGINEERING
Authors: Kuhn Dorothy A.
Published: November 2014

The need for effective automation in systems engineering has been a subtext of nearly every book on this fascinating subject since the early 1960s, yet systems engineering is still the least automated of the engineering disciplines. We are now at the happy historical position of having met the three necessary conditions for developing such a tool. We can describe the systems engineering process, the level of system complexity continues to rise, and the level of computing power is now sufficient and sufficiently wide spread.

This paper, a distillation of the author's masters thesis, will describe these three areas and will describe the general nature of such an automation tool.
The Next Big Step for Systems Engineering Tools: Integrating Automated Requirements Tools With Modeling and Simulation Tools
Authors: Schoening William W. , Daum Arthur W.
Published: November 2014

Computer tools like J‐MASS (Joint Modeling and Simulation System) have become an everyday reality for simulating the real‐time operation and testing of new hardware and software products. Systems Engineers, designers, and testers now need to link the product requirements housed in requirements management tools to the corresponding representations in the simulation software and data. This paper describes the systems engineering context for this new modeling and simulation environment, summarizes key features of J‐MASS, a Government‐developed and owned simulation tool, and discusses some of the interfaces between J‐MASS and any requirements management tools that might be linked to J‐MASS.
On the Dimensions of Interfaces Between Database Applications
Authors: Stafford Randy , Axe Herb
Published: November 2014

This paper presents a model to facilitate the description of interfaces between software applications that maintain databases of information. An interface is a capability for one application's database, or portions thereof, to be automatically and electronically transmitted en masse into another application's database. Criteria are first given for assessing the sensibility of a proposed interface between two database applications (in the context of system development projects), considering issues such as motivation, technical feasibility, and cost‐beneficiality. Next, a three‐dimensional model is proposed whose axes serve as a conceptual framework for describing interfaces between database applications, covering cases from the simplest, one‐time data conversion utilities, to the most sophisticated, integration‐type approaches. The design of software servicing such interfaces is discussed. Considerations are given for the effective use of such interfaces on system development projects, and a few example interfaces are reviewed.
System Modeling Through Parametric Spreadsheet Analyses
Authors: Ghassemi K. , Conway W. , Hines J.
Published: November 2014

Operational and cost effectiveness analyses are essential elements in the decision making process for both government and civil programs. Programs, now more than ever, require integrated system level models to perform early assessments of system tradeoffs between operational capability, performance, cost and schedule. At Rockwell Space Systems Division, an approach has been developed to achieve easy integration of various quantitative products of integrated product teams into a “system model”. This approach, at the present, is based on use of spreadsheets. We have taken advantage of the availability of PCs and Macs and familiarity of most engineers with spreadsheet operations. A demonstration of this approach is presented in the context of a satellite development program.
Digraph Analysis As a Valuable Part of the Systems Engineering Process in Design Optimization
Authors: Shih Eddie , Almeleh Nancy , Hines Jim
Published: November 2014

Digraph analysis, an approach to Boolean modeling and analysis of large systems, is a valuable technique when performed as part of systems engineering effort‐Digraph analysis provides modeling of physical and informational flow to evaluate and document decisions regarding design capabilities. It supports effectiveness analyses, design analyses, and trades in examining system interactions, fault tolerance, reliability, redundancies, and risks. A demonstration of how digraph analysis was used when performing systems engineering in an integrated product team environment on the Mars Environmental Survey (MESUR) program is given.
SIMULATION IN SLATE: Construction and Application
Authors: Chang C.Y. , Strasburg Don
Published: November 2014

This paper reports on the “Execution of Specifications” or “Simulation” at the system‐level as it was internally implemented as a prototype at Texas Instruments under the developmental name ‐System‐Level Automation Tool for Engineers (SLATE). The paper reviews original requirements, implementation specifics, actual application on a specific program, and lessons learned from the development and application of the tool.
The Role of Architecture and Evolutionary Development in Accommodating Change
Authors: Isaac David , McConaughy Gail
Published: November 2014

Traditional systems engineering processes emphasize controlling changes, and are effective at ensuring the transformation of system requirements into a system implementation that successfully fulfills those requirements. For large information systems, however, the rate of change in missions and technology is now such that a system that successfully meets the original written requirements may be obsolete on delivery. The days of static turnkey systems are gone: systems must continually evolve to adapt to changes in their environment. To support evolutionary systems, certain changes are required in the systems engineering process. Specifically, a shift in emphasis from limiting change to accommodating change is called for. Accordingly, a shift in emphasis from system requirements to the system architecture is needed. This paper discusses the need for evolvability, the role of architecture in enhancing evolvability, and the changes to the systems engineering process needed to support evolutionary systems.
OPERATIONAL CONCEPT and SYSTEM ARCHITECTURE for IVSAWS
Authors: Mayhew Gregory L.
Published: November 2014

The In‐Vehicle Safety Advisory and Warning System is a Federal Highway Administration program to develop a nationwide vehicular information system that provides drivers with advance, supplemental notification of dangerous road conditions using electronic warning zones with precise areas of coverage. Goal is to ameliorate the severity of scenarios which are particularly hazardous and have remained hazardous despite traditional crash reduction techniques such as mechanical signing. This system provides additional safety by enhancing the real time interaction between the general driving public and professional agencies. In order to solicit a broad based evaluation of the preliminary IVSAWS concept, user desired functionality was investigated. Two system design methodologies, Quality Function Deployment and Structured Requirements Specifications, produced significant refinements in the IVSAWS concept.
THE SYSTEMS ARCHITECT: SPECIALTY, ROLE AND RESPONSIBILITY
Authors: Rechtin Eberhardt
Published: November 2014

Architects, from the early Egyptians to modern systems architects, are specialists in the creation and building of complex structures, qualitatively different from those that have gone before. The architect, working with and acting as the agent of the client, creates and manages the design to maintain system integrity and to help achieve client satisfaction with the built system. This paper updates the ideas and conclusions of the teaching and study of systems architecting at the University of Southern California over the last six years.
EVOLUTIONARY DEVELOPMENT OF SOFTWARE‐INTENSIVE PRODUCT LINES
Authors: Hofkin Robert
Published: November 2014

The systems engineering process for software‐intensive products is the foundation for the developing organization's business. The enterprise's success is closely related to the capability and efficiency with which this process is performed and the quality and appropriateness of the products it produces. In the current competitive marketplace, developers of software‐intensive systems must find ways both to serve a broader range of customers and to operate more efficiently than in the past.

Systems developers need to consider their organization's present development capabilities and its legacy of products as part of their corporate assets. This paper proposes a shift from the “single‐project‐at‐a‐time” view that is typical of contract‐oriented developers to a multiproject or “product‐line‐oriented” view. This change highlights the strategic importance of systems development and emphasizes the need for corporate capabilities that support product definition and development.
ANATOMY OF A TAILORED SYSTEM
Authors: Stern George
Published: November 2014

This paper is a practical application of systems engineering theory. It is the result of a request be a customer to develop a routine by which the systems engineering process could be tailored. The routine should be able to respond to the exigencies of the current government environment.

The Current environment is strongly influenced by small budgets and an emphasis on maximizing the use of existing resources. The methodology herein described will be effective in this environment.

The key feature of this tailored methodology is that it uses the positive aspects of the Waterfall and Incremental methods to ensure positive control and insight by the customer fused with logical requirements organization to fulfill the customer's needs.
THE STATEMENT OF WORK: IT IS NOT NEEDED
Authors: Lake Jerome (Jerry) G.
Published: November 2014

Caution! Reading this exposition may alter your mind set on the need for a statement of work to direct development of a system, large or small, by a performing activity.

The recommendation is made to eliminate statements of work, as we now know them, for acquisition efforts involving system definition (Demonstration and Validation phase within the Department of Defense acquisition cycle) and subsystem development (Engineering and Manufacturing Development phase). This paper points out that the statement of work is a redundant document based on the documents that are currently available in a procurement solicitation, or will be available with publication of Mil‐Std‐499B and IEEE P1220 standards on systems engineering.

This paper is addressed to those interested in acquisition reform within the Department of Defense. It is also addressed to program managers in commercial enterprises having to communicate work tasks to a subcontractor.
A SYSTEMS ENGINEERING APPROACH TO HIGHWAY DESIGN
Authors: Mackey William F. , Mackey William F.
Published: November 2014

This paper explores some of the similarities between the approaches that civil engineers take to design highways and that systems engineers take to solve complex system development problems. The process of developing a highway design can be directly correlated to the system development life cycle used in systems engineering. The progression of highway design is demonstrated to be an evolution of technologies, inventions, organizational creations, and legislative acts supporting the development of a national interstate transportation system. Until now, highway design has been the domain of civil engineers concerned with highway structures, materials loading, traffic patterns, and supporting facilities. However, the growing need for intelligent vehicle‐highway systems (IVHSs) requires that traditional civil engineering disciplines be integrated with computers, communications, and eventually fully automated vehicles. This paper's thesis suggests that the complex highway transportation of the late 20th century and the 21st century can benefit from the collaboration of systems engineers and civil engineers.
SYSTEMS ENGINEERING SUPPORT METHODOLOGY
Authors: Kingsland Richard
Published: November 2014

A computer based Systems Engineering Support Methodology has been developed which interprets specified requirements to determine the specific concerns generated by each requirement at each level of the program structure and systematically identify all activities that are necessary to evaluate the identified concerns. The process continues by identifying and accumulating the necessary information, such as design detail and data bases; and the analytical tools, computer codes and experimental results, required to perform each evaluation. Documentation is added as the evaluation program is implemented. The aggregate of defined activities and resources required for these evaluations provide management with data regarding the full scope of the program and resources required for implementation. Correlated schedule data support the development of an efficient profile for program conduct.
Improving the System Software Requirements Development Process
Authors: Brown Phillip J. , Iwach Alexander E. , Williams Donald R.
Published: November 2014

One of the most significant challenges currently facing the system engineering profession is devising procedures for improving the system software requirements development process. While many practitioners promote a variety of automated tools and mechanistic templates as the means to improved productivity, experience suggests the highest leverage lies in harnessing thecognitiveprocesses required to produce a stable set of well defined system software requirements. System complexity and schedule constraints necessitate the use of teams of specialists working together to produce the desired software requirements database. System engineering's primary responsibilities are to foster team acceptance of a shared vision through the identification of intermediate and final products supporting the software requirements development process. This paper describes a framework for accomplishing the above, illustrates key points with actual examples, and identifies three approaches for improving management understanding of the requirements and software development processes.
Performance Sigma and the Systems Engineering Process
Authors: Kinard John Brent
Published: November 2014

The paper presents a method for the integration of Six Sigma producibility, statistical analysis, and risk management techniques into the requirements specification sub‐process of the systems engineering process. Application of the proposed method will identify performance and producibility risks early in the program life cycle. The method requires concurrent engineering and produces metrics intended to compel corrective action. Tools and training to support the method are also discussed.
A Conceptual Framework for Defining an Enactable Systems Engineering Process
Authors: Adhikari Sam B.
Published: November 2014

This article presents a conceptual framework for defining an enactable System Engineering process. The framework is based on the three primary entity types in a systems engineering process: Activities, Agents and Artifacts (AAA). AAA entity classes possess relationship within and between them. When process behavior is added to entities and relationships, dynamic systems engineering processes are created. Process definition of enactable system engineering processes can be defined via textual descriptions, IDEF/SADT or ETVX type notations, AAA or APPL/A type of process programming languages. This eventually results in the virtual machine that enacts the process code.
THE SYSTEMS ENGINEERING PROCESS AS A NEURAL NETWORK AND ITS IMPACT ON INTEGRATED PRODUCT DEVELOPMENT
Authors: Armstrong James R.
Published: November 2014

Various models have been proposed for the systems engineering process. Each one serves a particular purpose, yet none are accepted as definitive. The goal of a definitive yet simple model of the types proposed to date may be intrinsically unachievable. A neural network of interactive parts is proposed as a more accurate description of the process. This view explains the difficulty in developing a perfect and simple process model. Perhaps more importantly, it impacts the implementation of the process, particularly in an Integrated Product Development environment.
A Life Cycle for Commercial and Aerospace Systems Discovery
Authors: Oliver David W.
Published: November 2014

This paper defines a life cycle that is tailorable to either commercial or aerospace system developments. The tailorability is accomplished by separately describing the product life cycle, the acquisition cycles, and the technical steps used in performing the systems engineering. In addition this life cycle is based on the discovery of issues.

The life cycle described here differs from both the Waterfall Model, (Royce 1987), and the Spiral Model, (Boehm 1986), in significant ways that make it applicable to the work that occurs on time and cost sensitive projects.

The waterfall model defines a set of phases through which the project passes, but does not describe the manner in which actual projects loop back to prior phases when issues are discovered which require revisiting prior work. The spiral model defines progress through a series of prototypes, but does not root the prototypes in particular engineering goals.

In the discovery life cycle a set of normal forward phases is defined. The process for handling issues is described as a separate Change Management process which may be initiated at any step of engineering and may lead to any other step of engineering for resolution. In the discovery life cycle prototyping is associated with particular activities:

Rapid prototyping to define and demonstrate product function to operators and users to verify and refine requirements

Early prototyping to remediate risk by demonstrating feasibility.

Sequential release of products in a product line.

Sequential build designed to facilitate early stimulus/response thread validation through the system as it is integrated.
IMPROVING SYSTEM ENGINEERING EFFECTIVENESS >>> THE POSSIBILITIES >>>
Authors: Ring Jack
Published: November 2014

Addresses the extent to which system engineering effectiveness might be improved. These data come from subjective judgments by seminar attendees but reflect a reasonable level of “expert opinion.”

Results to date from this on‐going survey indicate that significant improvement is possible relative to prevailing system engineering roles and practices.

A majority felt that the results of their total development effort could be improved as much as 2:1 depending on the content and process of their systems engineering activity.

A majority felt that the achievement level of their current organizations might be increased by over 1.5:1 simply by improving the behavior in and of the process.

These factors are multiplicative. An advanced, systems‐level business might perform as much as 3:1 over many contemporary businesses.
THE SYSTEMS ENGINEERING PROCESS UNDER THE RAPID DEVELOPMENT METHOD
Authors: Reilly Norman B. , Spuck William H.
Published: November 2014

Management and systems engineering processes for system development have undergone a number of significant modifications over the past forty years in a constant effort to improve the probability of success. The lessons have been hard won. The traditional staircase process works best, and perhaps only, when requirements are well understood and needed technologies are in place. Following several successes and many failures, early prototyping and spiral models were devised to reduce risk in system developments where requirements and design issues were more fuzzy [BOEHM, 1988]. The latest management innovation, the rapid development method (RDM), has been successfully used to implement systems whose final requirements and designs are largely unknown at the outset [SPUCK, 1991]. It is important that the appropriate development process be selected for a given system development, and that the impact on the systems engineering process be well understood.
Requirements For Systems Engineering Metrics
Authors: Vinopal Timothy J. , Mar Brian W.
Published: November 2014

A systems engineering approach to the development of metrics for systems engineering is presented. Metrics are needed to indicate the “health” of an ongoing systems engineering process and the likely “quality” of the product of that process. A literature review of existing quality metrics identified four eras (1) inspection, (2) statistical quality control, (3) quality assurance, and (4) strategic quality management. The specific application of quality concepts to “white collar quality”, “engineering management quality”, and “system engineering quality” provided increasingly detailed and specialized product and process metrics. A survey of 28 agency/companies practicing systems engineering was made to determine whether the current solutions satisfied the functions and requirements of metrics identified in the literature. A set of 30 process and product metrics were analyzed in function, requirement and solution format. Collection, analysis, reporting and management operational functions were found to be as important as the choice of specific metrics.
DEVELOPING A TECHNICAL PERFORMANCE MEASUREMENT TOOL
Authors: Brown Dean D.
Published: November 2014

This paper discusses the development of a Technical Performance Measurement (TPM) tool by Westinghouse Electric Corporation. The tool is being developed to define and standardize the TPM process, streamline the data entry and reporting process, collect TPM data for analysis, and encourage the use of TPM within Westinghouse. The tool provides several capabilities, including a friendly user interface, network capability, configuration control, report generation, variance reporting, and metrics collection. The tool is implemented using Paradox for Windows, a commercial relational database product. By developing the tool and establishing a TPM library, we are hoping to reduce our process cycle time while also improving the quality of our TPM data.
USING CONTROL CHARTS TO MEASURE SYSTEMS ENGINEERING EFFECTIVENESS
Authors: Bellagamba Laurence
Published: November 2014

A methodology for selecting metrics to measure the long term performance of a systems engineering organization is outlined. When appropriate, control charts are used to enable the organization to perform plan, do, study, act cycles to determine if changes to operations improved the mean and variation in performance. Illustrative examples are presented using data from an aerospace firm's systems engineering department.
LIFE CYCLE SYSTEMS ENGINEERING: A GLOBAL ENVIRONMENTAL IMPERATIVE
Authors: Fiksel Joseph , Brill James H. (Jim)
Published: November 2014

The scope of systems engineering has rapidly expanded to encompass the full life cycle of system development, deployment and support. A number of important issues arise during the latter stages of this cycle related to the impact of a deployed system upon the biosphere. Such issues include health, safety, and environmental protection as well as recycling and resource conservation. This paper describes how the practice of Design for Environment can be incorporated into systems engineering, assuring that downstream environmental quality factors are incorporated into design trade‐off decisions.
AGUAS: Design of an Agricultural Water Quality System
Authors: Wymore Wayne , Onstad Charles , Lane Leonard
Published: November 2014

This paper discusses the design of AGUAS, an agricultural water quality system, for the United States Department of Agriculture (USDA). The top level function of AGUAS is to ameliorate the impact of agriculture on water quality in a designated region of the USA.

In the requirements development phase the problem of the design of AGUAS was stated in terms of I/O, technology, performance, cost, tradeoff and system test requirements. USDA policy restricts AGUAS from employing coercive technologies to carry out its top level function. Therefore, the system design requirements characterize AGUAS as an information system that outputs activities to collect data about water quality in the designated region and responses to inputted demands for information from users to persuade them to adopt less polluting farm management systems.

In the concept development phase, a system design concept was chosen. Subsequently, gaps in the technology required for the implementation of AGUAS have been identified through the processes of system functional analysis and physical synthesis.

Currently, the project is in a research and development phase.