bluuebunny/crossref_metadata_2025 huggingface dataset:
Squalene emulsion potentiates the adjuvant activity of the TLR4 agonist, GLA, via inflammatory caspases, IL‐18, and IFN‐γ
Authors: Desbien Anthony L. , Reed Steven J. , Bailor Hilton R. , Cauwelaert Natasha Dubois , Laurance John D. , Orr Mark T. , Fox Christopher B. , Carter Darrick , Reed Steven G. , Duthie Malcolm S.
Published: November 2014

The synthetic TLR4 agonist glucopyranosyl lipid adjuvant (GLA) is a potent Th1‐response‐inducing adjuvant when formulated in a squalene oil‐in‐water emulsion (SE). While the innate signals triggered by TLR4 engagement are well studied, the contribution of SE remains unclear. To better understand the effect of SE on the adjuvant properties of GLA‐SE, we compared the innate and adaptive immune responses elicited by immunization with different formulations: GLA without oil, SE alone or the combination, GLA‐SE, in mice. Within the innate response to adjuvants, only GLA‐SE displayed features of inflammasome activation, evidenced by early IL‐18 secretion and IFN‐γ production in memory CD8+ T cells and neutrophils. Such early IFN‐γ production was ablated in caspase‐1/11−/− mice and in IL‐18R1−/− mice. Furthermore, caspase‐1/11 and IL‐18 were also required for full Th1 CD4+ T‐cell induction via GLA‐SE. Thus, we demonstrate that IL‐18 and caspase‐1/11 are components of the response to immunization with the TLR4 agonist/squalene oil‐in‐water based adjuvant, GLA‐SE, providing implications for other adjuvants that combine oils with TLR agonists.
STRENGTHENING THE SYSTEMS ENGINEERING PROCESS
Authors: Alford Mack
Published: November 2014

This paper suggests that many system development problems are due to the inadequacies of the mandated notations being used to support systems analysis and design An executable “behavior diagram” notation is proposed for describing system functionality which eliminates the deficiencies of the existing system analysis notations, yet can be displayed in those notations to strengthen the Systems Engineering process. The way in which this notation supports a separation of concerns for attacking large problems is also described. Finally, the role of automation is discussed to achieve increased system development productivity and reliability.
PWMP, A TAILORED SYSTEMS ENGINEERING APPROACH FOR REQUIREMENTS MANAGEMENT
Authors: DeLozier R.C.
Published: November 2014

Because of the urgent schedule imposed on environmental issues, the Pond Waste Management Project (PWMP) implemented a tailored systems engineering (SE) approach for managing, integrating, and documenting its activities and for ensuring that both state and federal requirements for treating and storing low‐level radioactive mixed‐waste sludge would be met. This tailored approach focused on seven essential activities: system requirements, project plan, SE plan, configuration management plan, risk assessment, best management practices plan, and operational readiness review.
IMPROVING THE PRACTICE IN COMPUTER‐BASED SYSTEMS ENGINEERING
Authors:   State of Practice Working Group,   IEEE Computer Society Task Force in CBSE, White Stephanie , Alford Mack , McCay Brian , Oliver David , Tully Colin , Holtzman Julian , Kuehl C. Stephen , Owens David , Willey Allan
Published: November 2014

Problems in the development of large computer‐based systems indicate that a new discipline is needed at the systems engineering level. Designing systems with distributed processing and databases requires analysis of critical end‐to‐end processing flows to determine feasibility and proper allocation. An expanded skills base would be required to enable either software or systems engineers to perform the necessary tradeoff studies concerning software, hardware, and communication components.

This paper informs managers, engineers, educators, and researchers about the need for computer‐based systems engineering and the strategic opportunities this discipline provides for systems engineering improvement.
SAVING THE URBAN ENVIRONMENT WITH SYSTEM ENGINEERING
Authors: Martin Frederick
Published: November 2014

This paper describes how we can use the methodology of System Engineering (SE) to quantify the environmental impacts of local, urban projects. The concepts for using multi‐attribute analysis are presented and applied to two examples of local government planning ‐ highway routing and forest logging. This article illustrates how multi‐attribute analysis can quantify the relative benefits of alternative approaches to these problems. For highway routing, the least expensive approach is also the most environmentally sound approach.
SYSTEM ENGINEERING PROCESS IMPROVEMENT TEAM, ONE SMALL STEP FOR … SYSTEM ENGINEERING
Authors: Callaway R. , Petri D. , Fleming R.
Published: November 2014

NASA recognizes that it must fundamentally change the way it does business, especially during the early phases of a project life cycle, to be successful. A structured system engineering culture is one of the essential ingredients without which NASA may not be effective past the end of the century. Compatibility and improvement of System Engineering processes is the charter of the System Engineering Process Improvement Team (SEPIT) which will be discussed in this paper.
Strengthening the Systems/Software Engineering Interface for Real Time Systems
Authors: Alford Mack
Published: November 2014

As both Systems Engineering and Software Engineering mature, care must be taken to ensure that the interface between the two disciplines supports the efficient, effective and error‐free exchange of information. This paper identifies several current issues and proposes a solution to the “Babel of Notations.”
EDUCATING SYSTEMS ENGINEERS AT CASE WESTERN RESERVE UNIVERSITY
Authors: Hobbs Benjamin F. , Chankong Vira
Published: November 2014

This paper describes the authors' perceptions of the functions, requirements, architecture, and performance of the program in systems engineering at Case Western Reserve University. This program is the first systems engineering department in the U.S. The program emphasizes the development of control theory and systems analysis methods, and their application to engineering problems. Because of changes in 1) the field of systems analysis, 2) our student body, and 3) the needs of research sponsors, we believe that it would be desirable to incorporate concepts of functional and requirement analysis in our curriculum.
1.5.2 EXPERIENCE WITH AUTOMATED REQUIREMENTS MANAGEMENT
Authors: Jones David A.
Published: November 2014

Theory is one thing; practicality is another. Selling a requirements tool is one thing; using it is another. Here actual experiences in requirement management using three automated toolsets–the Simple Tested Available Requirement Tracer (START), Teamwork and the Cowen Utilities, and R‐Trace and Utilities‐are described in some detail. These toolsets range from table‐document referencing systems to a full centralized database requirement text system. All were used through one or more revisions to top level requirements and all were successful to a degree.

Topics include training; requirement identification/marking, allocation, and flowdown verification; responsibility segmentation; and spec and analysis document generation and control.

Brief comments are also given on experience with eight other toolsets.
3.1.2 SYSTEMS ENGINEERING TRAINING AT ROCKWELL SPACE SYSTEMS DIVISION
Authors: Benedict J. , Connolly A. , Hines J. , Smolskis R. , Stone A.
Published: November 2014

The Systems Engineering (SE) department at Space Systems Division of Rockwell is responsible for providing qualified Systems Engineers to all of the division's programs. Our training program addresses both immediate and long term skill needs. Immediate skill needs are developed with just‐in‐time in‐house training and on‐the‐job training. Our long term SE training program is integrated with SE career planning so individuals can identify specific types of training they need to achieve their long term career objectives. In addition, we monitor the effectiveness of the SE training to continuously improve it. Our training program consists of four basic elements: (1) an internal SE How‐To course to teach basic principles, (2) SE tools training, (3) on‐the‐job‐training (experience), and (4) formal degree SE programs from local universities.
5.4.2 Mousetrap: A Concurrent Engineering Simulation That Keeps Going…and going…and going
Authors: Zittel Randy C.
Published: November 2014

The Department of Defense Systems Management College uses the Stored Energy Ground Vehicle Simulation (“Mousetrap”) to train future program managers in the application and power of concurrent engineering and the systems engineering process. The simulation has evolved over the past seven years into what we believe to be a world class concurrent engineering simulation, which additionally provides the military officers and DoD civilians a critically important industry perspective.

Each student integrated product team performs the role of a defense contractor competing against other student “companies” in their quest for the single follow‐on production contract to be awarded after completion of the acquisition development cycle and a government supervised competitive “run‐off”. They respond to a government request for proposal, negotiate a contract and spend time over 14 weeks developing a life cycle balanced system, expending and accounting for labor and actual government funds for materials. They must conduct three acquisition phase based technical design reviews presented to an integrated government program office, and subsequently build and field a competitive prototype.
6.3.2 TESTING KNOWLEDGE OF SYSTEMS ENGINEERING PROCESS FUNDAMENTALS
Authors: Bellagamba Laurence
Published: November 2014

A method is presented for people to determine if they know the fundamentals of the systems engineering process as applied to aerospace systems. After considering optional methods, a series of proctored tests with post test identification of incorrect answers was selected as the optimal approach. A systems engineering approach was taken to develop the test. The test was verified to meet performance, functional and design requirements using focus groups consisting of an aerospace firm's management and staff. Sample questions are provided.
1.1.3 ENVIRONMENTAL IMPACT DESIGN TOOL FOR SYSTEMS ENGINEERS
Authors: Frisbee Eric
Published: November 2014

With new environmental laws and regulations come new requirements and responsibilities. It is the systems engineer's responsibility to establish and monitor these requirements. But the eruption of ever changing environmental laws has escalated the systems engineer's requirement duties to an almost unmanageable level. To help meet the multitudes of environmental specifications, the systems engineer has a need for environmental compliance tools.
1.1.4 SYSTEMS ENGINEERING OF RENEWALS AND EXTENSIONS IN MASS TRANSIT RAILWAYS
Authors: Williams John , Allan Jeff
Published: November 2014

Rapid Transit Railways have become complex and expensive safety critical systems involving a considerable range of technologies and a wide choice of implementations. Many of the older systems have now reached a stage at which renewals and frequently, further extensions have become essential in order to cope with the increasingly difficult commercial and legislative environment of the present and future. These tasks are far from trivial and as a consequence, an approach based on systems engineering has been evolved to deal with them. This paper covers aspects of a code of practice which has been developed in the context of the major renewal and extension projects.
2.1.3 DEVELOPMENT OF OPERATING CONCEPTS
Authors: Thompson T.E. (Ted)
Published: November 2014

Systems engineering techniques, especially requirements collection and management, are well described in the literature but appropriate methods of determining and documenting operator requirements are not as widely discussed. The Canadian Airspace System (CAS) is a large, complex systems engineering task. This paper discusses the methods used by Transport Canada to elicit, review, discuss and document the operating concepts for the future evolution of the CAS.
7.1.1 Social Systems Engineering and Architecture
Authors: Maier Mark W.
Published: November 2014

Although the methods of systems engineering were developed to build complex technological systems, many practitioners feel they can be equally well applied to social and political processes and problems. This desire to rationalize social systems, and to do so through the application of the principles of science and engineering, is not new. It clearly dates back at least 200 years to the French Revolution. Unfortunately, the history of these attempts is mixed. This paper surveys the engineering approach to human systems and examines general criticisms of such an approach. We propose a classification of problem types and suggest variants of the system approach that may be better suited to particular classes of social system problem. Many of these issues, and the resulting classifications, can be seen in the long history of civil architecture and its attempts to deal with the interaction of engineering and society.
7.1.2 A SYSTEMS ENGINEERING APPROACH TO LIFE EXTENSION PLANNING FOR THE STRATEGIC PETROLEUM RESERVE
Authors: Pikul Robert (Bob) , Schultz Daniel A. , Culbert Jon A.
Published: November 2014

This paper addresses life extension planning for the Department of Energy's (DOE) Strategic Petroleum Reserve (SPR), the mission of which is to store crude oil and to maintain a 95 percent system availability to allow drawdown of the oil in the event of a national emergency. A key element of the planning approach is identification of those system components whose improvement from their current state of availability would have the greatest impact on increasing overall system availability. The approach includes: a) conducting a reliability centered life extension (RCLEX) planning analysis utilizing a failure modes and effects analysis (FMEA), availability modeling, and component aging in order to determine priorities for critical system components; b) identifying and assessing alternative methods for improving critical system components and analyzing their effectiveness using life‐cycle cost methods; and c) preparing an integrated Comprehensive Life Extension Plan (CLEP), showing projects, schedules, and budgets.
3.2.2 Aspects of System Engineering Environments
Authors: Tronstad Yngvar D.
Published: November 2014

The macro problem facing organizations that acquire and produce modern systems are complexity in both the process and the product dimensions. It is the scale of this multidimensional problem which requires a system approach which combines both the engineering and the management aspects as well as the process. However for all but the most trivial cases this need to be supported by an automated System Engineering Environment (SEE) where the life cycle processes, the product and the organizational elements with people using methods and tools to perform their tasks are linked together in a collaborative manner.
4.2.2 System Engineering and KBS Development
Authors: Sandral Jean‐Luc
Published: November 2014

This paper discusses connection principles for methods and tools, between traditional Requirement Engineering and Problem Domain Analysis, in order to be able to manage every kind of requirement: functional, non functional, knowledge and rule based. This paper is based on studies carried out at NCS‐FRANCE, part of the Naval Combat Systems Group (NCS) of Thomson‐CSF.

Thomson‐CSF has set up a common policy for System Engineering at the corporate level, which includes a method called MIST (“MŽthode d'IngŽnierie Systme Thomson‐CSF”), based on Draft MIL‐STD‐499B standard, and a tool which is RDD‐100TM. The additional work performed at Thomson‐CSF/NCS focuses on the analysis of operational requirements in the area of C3I systems. A Problem Domain Analysis approach appears to provide a promising solution. The method used by Thomson‐CSF/NCS in this area is KADS (Knowledge Analysis and Design Support), which is a conceptual modeling language stemming from European research projects. The tool which implements this method is OpenKADSTM.
7.2.3 VIRTUAL PROTOTYPING: RESULTS ILLUSTRATE UTILITY IN DEVELOPING WEAPON SYSTEM REQUIREMENTS
Authors: Brown Phillip J. , Lavender Jack K.
Published: November 2014

The Department of Defense, in response to excruciating budget pressures, recurring system integration problems, and the continuing remarkable growth in computer capability and high resolution graphics, has seized on the promise of advanced distributed simulation technologies (including virtual prototyping) as a means for improving efficiency in developing integrated defense system products. From the perspective of a weapon systems contractor, benefits of virtual prototyping include: (a) tighter coupling of operational requirements with developer implementation concepts, (b) introduction of a rapidly reconfigurable tool for refining system requirements early in the systems development cycle, and (c) a means for improving the visibility of the system requirements analysis process. Examples of requirements changes identified as a result of virtual prototyping activity are from Loral Vought Systems experience with virtual prototyping on the Line‐of‐Sight AntiTank (LOSAT) weapon system program. Also included is a vision of where these tools, in the context of a weapon system, can be used to abet the system requirements development process.
1.3.1 An Integrated Problem Reporting and Resolution System
Authors: Tilton Catherine J.
Published: November 2014

With few exceptions, all system development projects have a need to identify, track, and resolve issues, action items, problems and changes. Within an organization, many different mechanisms may be used to perform this function across projects. Indeed, on a single project, a number of different systems may be in place to track the various types of ‘problems‘. This paper describes an integrated approach for establishing a project problem reporting and resolution system which handles all categories of items, from identification through closure. This approach, which includes a process description and automation support, was successfully implemented and used on a $30M project over a two year period with the described results.
1.3.2 LIFE CYCLE RISK MANAGEMENT
Authors: Brekka Lawrence T. , Vlay George J.
Published: November 2014

Risk management using available engineering, schedule, and cost data provides a means of integrating the process into the mainstream responsibilities of systems engineering, program control, and program management. The type and detail of data used in different phases of the program life cycle differ, and different tools are needed to assess the potential impacts of the risks. Careful selection of the data available at each phase of the life cycle insures that the integrated, real‐data approach is easily implemented and effective.
3.3.4 The Benefits of the Systems Engineering Process in Concurrent Engineering
Authors: Matty George E.
Published: November 2014

With the appearance of concurrent engineering (CE), Systems Engineers play a more vital role in the development process. No longer are Systems Engineers dealing with individuals from functional areas who do not have a vested interest in the program. Although the Systems Engineer interfaced with the functional organizational staff in the past, now he is interfacing with functional organizational team members who all have the same goal. Because of the cooperation and team work, more realistic program costs and schedules can be obtained because most of the individuals involved in the concurrent engineering team are stakeholders in the development of the project. The Systems Engineer as a team member is required to determine program plans, assess risks and program costs with input from all the concurrent engineering team membership.

A CE team considers the product, customer, and all the processes associated with it simultaneously; in essences a ‘systematic’ approach. The difference now is that everybody affected in an organization understands the same thing at the same time. The CE team members voice issues from a variety of different perspectives based upon their background and experience. Marketing may be concerned with how the customer may perceive a particular design concept, design engineers are concerned with designing the product to meet performance capabilities, and manufacturing engineers are concerned with the producibility of the system. CE provides the forum for all these issues to be addressed. Systems engineers no longer have the sole responsibility of addressing the product issues. Now, the responsibility of the Systems Engineer is more of a facilitator. With the proper tools and guidelines in Military Standard 499B, a Systems Engineer can help the team to better determine program requirements from the customer to, ultimately, the product.
4.3.1 INDUSTRY PERCEPTIONS OF REQUIREMENTS SPECIFICATIONS FOR COMPLEX MILITARY SYSTEMS
Authors: Gabb Andrew P. , Henderson Derek E.
Published: November 2014

This paper presents the results of a survey of Australian companies involved in the development and supply of complex computer based systems for the Royal Australian Navy. The objective of the survey was to gain feedback from industry of the quality of Navy's requirements specifications leading to recommendations for improvements in specification practices. The paper summarises the industry perceptions and comments on the results.
4.3.2 SAFER ‐ A Case Study The Lessons Learned on a Flight Test Project
Authors: Hess Clifford W. , Hooks Ivy
Published: November 2014

The SAFER ‐ Simplified Aid for EVA Rescue – Flight Test Project captured the hearts and minds of the country in September when astronauts flew untethered for the first time in a decade. The SAFER, a small backpack worn by an EVA astronaut was designed and built as an in‐house project by the NASA‐Johnson Space Center.

Following the very successful flight of SAFER a study was made to document the lessons learned from the participants. This paper focuses on the system engineering aspects of the project across its life‐cycle.
4.3.3 How Do I Keep Track of This Study
Authors: Bedocs Jozsef
Published: November 2014

The commercialization of Systems Engineering is causing us to rethink some of the more labor intensive activities such as requirements management. Commercial engineers are already involved in cost, testing, program planning, procurement, configuration management and other activities. Relatively few organizations exist only to perform selective functions (such as CAD/CAM, computer support, facilities, etc.) Requirements management is likely to become the responsibility of the every day design engineer and therefore cannot be a massive effort.

For requirements management to be used by commercial engineers, the effort must be perceived to have added value and be an overall time saver. Most engineers are extremely busy supporting currently mandated processes. More work is a hindrance, a more efficient way of doing the work already required is most helpful.

We have been fairly successful in making a sound case for doing requirements management. However, the way requirements management is traditionally done is just an incredible amount of work. To become commercially palatable, requirements management must become more efficient in use of time and resources to be effectively used by design engineers.
5.1.3 Management and Re‐Use of the Artifacts from the System Engineering Process
Authors: Tronstad Yngvar D.
Published: November 2014

This paper describes the results of a forward and reverse engineering effort, with the focus on how to plan, mange and control all the different artifacts (models, documents, issues and decision) in anticipation of their re‐use during the development of subsequent versions over the life cycle. A Model Configuration Management Facility (MCMF: a prototype extension to RDD(TM)) was used to keep versions of these artifacts separated and organized into consistent and complete system configurations. Change control procedures were used to ensure the integrity of these system configurations.
5.3.1 APPLICATION OF ANSI STANDARD TO SPACE STATION RESOURCES
Authors: Taylor Irene , Bassler Julie
Published: November 2014

The Space Station environment has created unique scenarios for allocation and management of critical technical resources. Integration of resource requirements of a Prime contractor with Product Groups and associated subcontractors, in concert with international agreements with European Space Agency, National Space Development Agency of Japan, Canadian Space Agency, and the Russian Space Agency (RSA) is complicated by the fact that several components of the Space Station design are carry‐overs from a previous version of the program. Costs associated with alterations of those design components prohibit normal resource allocation processes which would assign and control resource utilization from the embryo stage of a program. In order to methodically allocate the technical resources, while assuring adequate margin for nominal programmatic growth in demand against those resources, Space Station has developed resource reserve philosophies based upon the application of American National Standards Institute (ANSI) approved methodology. The methodology was sponsored by the American Institute of Aeronautics and Astronautics (AIAA) and was published in a paper titled “Guide for Estimating and Budgeting Weight and Power Contingencies for Spacecraft Systems.” The application procedures were adjusted for application to the diverse types of resources being controlled for the Space Station.
5.3.2 SPECIFICATION DEVELOPMENT WITHIN THE IPT: A CASE STUDY OF THE F‐22
Authors: Meyer Albert
Published: November 2014

The goal of this paper is to demonstrate how the concurrent engineering method embodied in the Integrated Product Team (IPT) philosophy has impacted the specification development process on the F‐22 program. The article will examine the concurrent engineering process as it applies strictly to specification development.[1] In particular, the success of the specification development process will be attributed to three main factors: (1) maintaining flexibility in the Preliminary Allocated Baseline (PAB) until Functional Configuration Audit (FCA), (2) Increasing communication and trust between the contractor and the customer by making the customer an integral member of the IPT, and (3) taking advantage of the automated technology to redesign the specification development process. While the F‐22 program is a multi‐corporate endeavor, these principles can be applied to any development effort.]
5.3.3 Requirements Mythology: Shattering Myths About Requirements and the Management Thereof
Authors: Martin James N.
Published: November 2014

Requirements cannot be managed well if the true nature of these requirements is not understood. There are some misperceptions about requirements that lead to improper application of requirements practices and principles.

For example, some believe that “all requirements must be verifiable” before they can be declared to be “good” requirements. If this were true, then we would have to ignore the “non‐good” requirements we often get from our customer and potential system users who are not usually literate enough in “requirements engineering” to give us verifiable requirements per se. In fact, the customer usually can tell you if a requirement is met “when they see it.” A more accurate statement is that all specified requirements must be verifiable. This is not an insignificant distinction.

This example illustrates the danger of believing in certain “requirements myths”. Like all mythology, each particular myth has a degree of truth in it. It is this element of truth that encourages the persistence of these myths. It would be better to apply these truths to a better understanding of requirements management principles and application of its practices.

This paper describes a dozen common myths about requirements. Each myth is examined to determine the true and the false elements and to identify the traps to avoid when performing requirements engineering tasks.
6.1.1 System Engineering as Model Making
Authors: Tronstad Yngvar D.
Published: November 2014

This paper discuss the aspects of system engineering as model making, where models embody the decisions made over the different stages of the system's life cycle. To be useful the models need to have essential properties in common with the problem they represent. The two essential properties of systems are their behavior and structure.
6.1.4 Methods and tools for the interactions between systems and software
Authors: Stevens Richard , McCaskill George A.
Published: November 2014

Software forms an important part of almost every modern systems project. However, the development of software‐intensive systems (SIS) is plagued with well‐publicized problems. Often these problems are managerial rather than technical. Part of the problem is the interaction between systems and their software sub‐projects. This process is understood only weakly, partly because the systems and software development processes are themselves are poorly understood, often inconsistent and weakly followed in practice. This paper analyses the interactions between systems and software engineers during the course of a SIS project. These define the functions for interacting between requirements management and CASE tools. An interface between a requirements management tool (DOORS) and a CASE tool (Teamwork) has be produced according to these principles.
CONCURRENT ENGINEERING WITH INTEGRITY: THE ENVIRONMENTAL SOLUTION FOR THE 90'S
Authors: Zittel Randy C.
Published: November 2014

America has become more environmentally conscious while cheering the military for its service and professionalism. Base closures and overseas withdrawal are now bringing to light the environmental consequences of our ability to parry so many military threats. To some, it appears that a new environmental process for the 21st century is needed, but in fact the existing process provides a highly effective framework when used properly with integrity.

The DoD Instruction 5000 series requirements provide an excellent state of the art system for handling the environmental problems of yesterday, and preventing such problems tomorrow. Although the DODI 5000 series is 4 years old, the mandatory procedures have evolved, as in the use of the systems engineering (SE) management practices which now incorporates the use of integrated product and process development teams and concurrent engineering. And with the continuous evolution of the SE process, DOD's reliance on systems engineering has also evolved in the right direction.
OPERATIONS: THE MISSING THIRD OF SYSTEMS ENGINEERING
Authors: Denzler David W. R. , Vallone Antonio
Published: November 2014

Since its inception, NASA's Goddard Space Flight Center (GSFC) has developed extensive ground systems to support unmanned scientific spacecraft. These systems are composed of large numbers of subsystems operated by a multitude of individuals. This complexity has demonstrated the need for documentation to aid the developers in addition to the traditional systems requirement documents (SRDs). GSFC has increased focus on operations by requiring that most new system development activities use both an SRD and a mission operations concept document (MOCD).

This use of operations documentation accompanying requirements has provided the clarification of the reasons for and context of the requirements.

The methodology of operations engineering used to develop operational models is closely related to the processes used in business process engineering. A discussion of the characteristics of business process reengineering shows this strong relationship between the newly developed reengineering methodology and the operations engineering subdiscipline of systems engineering.
2.2.1 SYSTEMS ENGINEERING AND THE BOTTOM LINE
Authors: Jackson Scott
Published: November 2014

Systems Engineering (SE) cannot be viewed in isolation, but rather as a subset of, first, the Integrated Product Development process, and secondly, as part of a commercial or non‐governmental corporation's business enterprise. This paper discusses four ways in which the SE process directly affects the financial operations of a company and how SE can be employed to improve the financial performance. First, the design‐to‐cost process can be brought to bear to maintain predictable and affordable products. Second, the normal business cycle in commercial industries, presents cost and schedule constraints which can be treated by considering them as a natural part of the SE process. Next, the improved product quality through the SE process results in many direct and indirect financial benefits through reduced development cost, reduced unit cost, reduced operating cost, and improved sales. Finally, the SE process provides consistent methodology for obtaining superior products from suppliers, and hence enhances the business prospects for the product. Examples in this paper focus on the commercial aircraft industry, although the principles found in it may be applied to many industries.
LESSONS LEARNED AS A SE‐CMM AUTHOR
Authors: Kuhn Dorothy A.
Published: November 2014

Developing a maturity model, as I had occasion to do with the Industrial Collaboration's Systems Engineering Capability Maturity Model (SE‐CMM), was a lengthy journey over partially charted waters. Some lessons our authoring and management team learned are described, a brief history of the effort is given, along with a short description of SE‐CMM and its future plans.
1.4.2 SYSTEMS ENGINEERING IN A FASTER, BETTER, CHEAPER WORLD
Authors: Parker Kimberly L. , Braddock Robert L.
Published: November 2014

Systems Engineering in a Faster, Better, Cheaper World has been an evolution over the last two years at the NASA Johnson Space Center (JSC) Mission Control Center (MCC). NASA funding uncertainties and the availability of Commercial hardware and software technology have necessitated change in the overall MCC Architecture, the Space Station support at JSC, and the Systems Engineering processes to allow end‐to‐end success. In addition, NASA JSC Management, combined with these drivers, have been facilitators in allowing the right environment for drastic change in how we engineer, implement, deploy, and operate the MCC. This has culminated in new ways of doing business for the MCC, providing dramatic results achieved through these changes. These new ways of doing business can be applied to other government and commercial areas. For each topic, changes will be described at the overall Control Center system level, and at the systems engineering process and organization level.
1.4.3 EVOLUTION OF THE INTEGRATED MASTER PLAN ON THE F‐22 PROGRAM
Authors: Stanton Lillian
Published: November 2014

The Integrated Master Plan (IMP) developed by Lockheed for the F‐22 Program has become a model throughout the Industry. Part of an integrated management system which details the total work effort through significant accomplishments and success criteria, this contractual document is expanded by the non‐contractual Integrated Master Schedule which details the tasking and timing of the work effort as described in the IMP.

This innovative document, developed through the System Engineering Process in and Integrated Product Development environment, evolved as a detailed expansion of the Program Statement of Work (SOW) and establishes by key program review Events(e.g., PDR, CDR, etc.), the Significant Accomplishments and Accomplishment Criteria necessary to develop the F‐22 weapon system to meet its specification requirements. It traces the interaction among the various Product Sections of the IMP to achieve standardization, integration, and total system verification.

This paper traces the evolution of the F‐22 Integrated Master Plan from inception to date, detailing the though processes, rationale, and planning involved in its success. The paper further details the coordinated process wherein this contractual document is revised to reflect changes in program direction, requirements, or funding. The paper illustrates, as the result of the system engineering approach to the design of the F‐22 IMP, how, almost five years later, the basic IMP structure remains intact and has become a model for subsequent industry program IMPs.
1.4.4 Risk/Decision Analysis for Trade Studies
Authors: Buede Dennis M.
Published: November 2014

This paper relates the top‐down, iterative design process of systems engineering to key elements of decision analysis to show how decision analysis concepts can be used to enhance decision making by systems engineers. We begin by reviewing the systems engineering process: requirements, operational concept, system boundaries, and functional, physical and operational architectures. We then discuss requirements as objectives and constraints. Next we introduce the decision analysis concepts of fundamental objectives and the fundamental objectives hierarchy. These ideas are related to the traditional concepts of measures of effectiveness (MOEs) and measures of performance (MOPs). We then describe influence diagrams and show how the choice of operational architectures and the associated requirements allocation can be addressed with influence diagrams. We discuss how the fundamental objectives and objectives hierarchy change as the iterative design process proceeds to greater and greater detail. The analogy is drawn between physical interfaces between components of the design and the requirements allocation decision interface between layers of design detail.
2.4.1 TOWARD A COMPREHENSIVE SYSTEM ARCHITECTURE REPRESENTATION MODEL
Authors: Ramchandani Chander , Maier Mark , McKendree Thomas
Published: November 2014

This paper addresses an approach to developing a comprehensive representation model for system architectures. The paper uses the Hatley‐Pirbhai architecture model as the point of departure for developing a system architecture representation model, and discusses extensions to the Hatley‐Pirbhai model to make it more comprehensive and to enhance its usability. The paper also discusses activities being undertaken by the NCOSE System Architecture Working Group (SAWG) in the area of system architecture representation.
2.4.2 SYSTEMS ARCHITECTING DURING THE CLIENT INTERACTION CYCLE
Authors: Smith Timothy B.
Published: November 2014

In the traditional view of the System Development Life‐Cycle (SDLC), Systems Engineering activities tend to occur toward the front end. Systems Engineering activities are initiated during proposal development, build during requirements analysis and definition, plateau as the system level design is defined, and are, more or less, considered to be completed when the resulting system design is documented, coordinated with, and accepted by the client.

The domain of Systems Engineering is being redefined based on the “lust to dust” paradigm. It is my contention that Systems Engineering should be extended even further to include all periods of technical interaction with the client. This includes that time when the only thing that exist is an opportunity or a problem that might be able to be resolved by a the application of Systems Engineering. I further contend that Systems Engineering must be viewed as a “total system” for interacting with its environment while conceiving, designing, developing, producing, delivering, maintaining, and disposing of systems based on operational imperatives and technical, schedule and cost constraints. Systems Architecting activities are, therefore, a proper subset of Systems Engineering activities and this paper will address Systems Architecting during what I have termed the “Client Interaction Cycle” (Figure 1‐03) within the context of the “total system” of Systems Engineering.
2.5.3 Systems Engineering & Sofware Engineering, Contrasts and Synergism
Authors: Oliver David W.
Published: November 2014

Systems engineers and software engineers work together in the development of modern complex systems. The two engineering cultures, the concepts, and the best practices have developed independently over four decades. Notations and naming conventions for the same things are often different. Yet the efficient exchange of engineering information and wisdom between the two professions is important to the successful development of large complex systems.

The present record of success for complex computer intensive systems is that for every six systems put in operation two are canceled; on the average projects are 50% over schedule; and three quarters are failures that do not function as intended or are not used at all, (Gibbs 1994). Incomplete specifications, ambiguous specifications, and misunderstood specifications are a major contributor to these problems. Development of rigorous specifications that match user needs is critical.

The need for synergism between systems engineering which develops specifications to meet user need and software engineering is particularly important because software portions of systems are increasingly complex and are often being coded in countries far from the country where the system is defined and utilized.
2.5.4 IMPROVING THE SYSTEMS ENGINEERING DOCUMENTATION PRODUCTION PROCESS
Authors: Kasser Joe
Published: November 2014

Documentation is a major component of any system. It serves the purpose of communicating who is to do (or did) what, why, when, where, and how. Document quality is a function of style, format and content. Content is application specific. The documentation process is common to the entire Systems Development Life Cycle (SDLC). Good documents can be produced at low cost with resulting benefits to both you as the writer and the organization. Good engineering documents are critical to the cost effectiveness of systems engineering. Writing good documents also important to you as a person. When you sign off on a document you are stating that the document meets your personal quality standards. Your signature on that document shows your level of competency to everyone who subsequently reads that document. Reducing the cost of preparing effective documents is an approach that can be applied in any organization and will reduce the cost of the SDLC. This paper discusses improving engineering documentation.
3.4.1 Design to Cost Methodology Implemented within A Product Team Environment
Authors: Conway W. , Ghassemi K. , Hines J. , Shishko R.
Published: November 2014

The design to cost concept establishes cost as a design parameter to be considered for a system throughout its life cycle. Cost is considered a design parameter equal in importance to technical requirements and schedule. Rockwell and the Jet Propulsion Laboratory have jointly learned that the most effective way to implement design to cost in our programs is within a product team environment. Also, we have established that the success of the program is heavily dependent on the exchange of information. It is important that the necessary steps be taken early to create an open data exchange. A methodology has been determined to increase communication between team members on performance versus cost tradeoffs using spreadsheets on personal computers.
3.4.3 Practical Issues for Including Manufacturing During Space System Concept Development
Authors: Ruth Susan C.
Published: November 2014

The historical trend in systems engineering has been to increasingly consider aspects of the latter portions of the life cycle during concept design. In theory, this has been implemented by including participants from these disciplines, e.g. manufacturing, operations, etc. on the concept development team In the space industry, this approach has been observed by this author to be expensive and does not necessarily fulfill the intended function.

In this paper, an assessment will be made of the factors that hamper the effective inclusion of one of these disciplines, specifically manufacturing, in the early concept phase of a military space program. Practical approaches for significantly improving the impact manufacturing considerations can have in up‐front concept definition will be described.
3.4.4 THE HUMAN FACTORS ENGINEERING SPECIALTY WITHIN THE SYSTEMS ENGINEERING PROCESS
Authors: Rogers Christopher , Densler Kristina , Englert Mary , King Taylor , Tulloch Michael
Published: November 2014

One mission of the Human Factors Engineering (HFE) specialty is to ensure that all user requirements have been identified and that developed information systems and products can be operated and maintained effectively, efficiently, and safely, and can achieve the system mission. As part of efforts to reach greater maturity in Systems Engineering, the Human Factors Engineering process has been integrated into the Systems Engineering process. This is accomplished by recognizing where the services of Human Factors Engineering personnel are necessary and how they should be effectively applied during systems development, accommodating cost concerns.

This paper identifies the characteristics of programs that alert Systems Engineering to seek Human Factors Engineering involvement. It describes the Human Factors Engineering process and products, emphasizing those activities that HFE supports within the traditional Systems Engineering process (i.e., Concept of Operations). It describes Human Factors Engineering activities from contract award through Critical Design Review (CDR).
3.5.1 A SYSTEMS ENGINEERING APPROACH TO TECHNOLOGY MANAGEMENT
Authors: Mackey William F. , Yost Robert
Published: November 2014

Technology management is concerned with minimizing the risks associated with new technologies and ensuring the successful integration of those technologies into systems and operations. The role of an Advanced Technology Manager is to identify the technologies that will enhance project operations, identify applications throughout the project that can benefit from appropriate new technologies, and ensure that these technologies are developed and/or transferred for insertion into operations.

This paper describes the creation of a technology management process and the development of technology assessments, analysis, and evaluation methodologies developed for the NASA Goddard Space Flight Center's (GSFC's) New Technology and Data Standards Manager and the CSC Systems, Engineering, and Analysis Support (SEAS) project. The paper also includes a detailed description of the six stages of technology commitment. Note that the technology management process discussed in this paper is undergoing evaluation and will mature as it is implemented in the coming months.
3.5.4 THE TRANSITION OF FUNCTIONAL ORGANIZATIONS TO INTEGRATED PRODUCT TEAMS ON THE SPACE STATION PROGRAM
Authors: Peters James F.
Published: November 2014

Since May 1993, the Space Station Program has undergone major restructuring, primarily due to budgeting constraints, as a result of the new presidential administration. Thus far, significant changes have been made to the program which have already resulted in considerable improvements in the management, scheduling and budgeting of the program. This paper will focus on the major management changes of selecting a single Prime contractor and the effectiveness of the NASA and the Prime contractor at transitioning from a Functional Organization to Integrated Product Teams (IPTs). The Space Station program is an example of how the transformation of a functional organization to IPTs can be implemented successfully, despite failure rates of up to 65‐85%. The characteristics of Tom Peters' Simple Form/Lean Structure and Autonomy and Entrprenuership, which are two of the eight attributes of Excellent Organizations, as well as Peter Senge's 5th Discipline of Systems Thinking will be extended to include the implementation of the theories on a functional organization transitioning to IPTs. In addition, the overall transition will be evaluated based on customer satisfaction, productivity, schedule, communication, employee moral and costs. Finally, conclusions will be made and recommendations to improve the transition process will be discussed.