bluuebunny/crossref_metadata_2025_split huggingface dataset:
1.4.2 SYSTEMS ENGINEERING IN A FASTER, BETTER, CHEAPER WORLD
Authors: Parker Kimberly L. , Braddock Robert L. 
Published: November 2014

AbstractSystems 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

AbstractThe 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

ABSTRACTThis 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

AbstractThis 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

AbstractIn 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

AbstractSystems 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

AbstractDocumentation 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

AbstractThe 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

AbstractThe 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

AbstractOne 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

AbstractTechnology 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

AbstractSince 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.
4.5.2 Taming the Sofware Monster with Threads
Authors: Alford Mack 
Published: November 2014

AbstractOne of the biggest challenges facing system engineers is the way in which they interface with the development of the software which implements the desired behavior of the system. Experience has shown that the approach of passing paper specifications between systems and software developers does not yield satisfactorily results. This paper proposes the use of stimulus‐condition‐response threads for controlling software development – for specification, review, and testing.
5.5.2 Foundations Of A Human Systems Theory and Systems Engineering
Authors: Mayhew Michael E. , Alessi R. Samuel 
Published: November 2014

AbstractHuman beings and the dynamics of human interaction are central features of systems engineering. Since engineers are often technically oriented, understanding and dealing with this human dimension can become problematic. Built upon the technical foundations of General Systems Theory and cybernetics, a human systems theory may provide systems engineers a more rigorous way to understand themselves, other team members, and stakeholders. This paper gives the historical development and general description of human systems theory with examples to help communicate meaning. This theory can give systems engineers a better understanding of the human dimension of systems engineering, thereby enabling rigorous management of the system.
6.4.1 Industrialization Of Formal Methods Through Process Definition
Authors: Toth Kalman C. , Joyce Jeffrey J. 
Published: November 2014

AbstractThis paper advocates the use of process definition methods to drive the “industrialization” of new techniques – that is, the transformation of a technique, or combination of techniques, developed by a research organization into a production process that can be used by an industrial organization. We relate our own experience at Hughes Canada Systems Division (HCSD) based on an effort to industrialize an application of “Formal Methods” to support the development of large automated air traffic control systems. In addition to providing an account of some components of our approach to process definition, this paper provides a glimpse into the topic of “Formal Methods” which is already becoming established in Europe as an important systems engineering discipline and can be expected to soon become as important within North America.
6.4.4 INITIAL SYSTEM VERIFICATION AND VALIDATION CONSIDERATIONS
Authors: Morrison Arthur F. , Mar Brian W. 
Published: November 2014

AbstractEarly consideration of a system development project's system verification and validation aspects can make an important contribution to its success. Three specific areas of consideration–management method, technical approach, and information system utilization–are examined to identify considerations that need to be taken into account from the beginning of a project. A proposal is made to use an integrated approach involving concurrent engineering with customer and system team member representation, early system modeling, simulation, and analysis targeted toward addressing system verification and validation, and integrated system development information that provides a system verification and validation thread throughout all phases.
6.5.1 PARTNERSHIP FOR ORGANIZATIONAL EFFECTIVENESS
Authors: Rhodes Donna H. 
Published: November 2014

AbstractOrganizational effectiveness can be improved in a multitude of ways, some more obvious than others. “Small changes can produce big results ‐ but the areas of highest leverage are often the least obvious”, says Peter Senge, author of The Fifth Discipline. This paper describes a very successful program which inserted systems engineering paraprofessionals into an existing organization. While the addition of an individual to a team is a small change in the scheme of things, the program has turned out to be a high leverage change for our business. Benefits to the engineering organization's effectiveness go well beyond the initial expectations for the program.
6.5.3 THE DESIGN LIFE AFFECTS SYSTEM DESIGN
Authors: Bahill A. Terry , Dean Frank F. , Senglaub Mike E. 
Published: November 2014

AbstractWhen a system is being designed, one of the system requirements will specify the intended duration of life for the system, which is called the design life, the system life, the expected operational life or the service life. This specification is an important driver of the total life cycle cost. This paper suggests how specifying this design life affects the design and the cost of the system.If the customer requires a longer design life, then the system will cost more. Figure 1 shows the manufacturer's suggested list price (dollars) as a function of design life (number of pages) for 166 laser printers (Computer Select, 1994). The cost increases as the design life increases. The correlation for these data is high, 0.84.
7.4.2 RELATIONSHIPS BETWEEN COMMON GRAPHICAL REPRESENTATIONS USED IN SYSTEM ENGINEERING
Authors: Long James E. 
Published: November 2014

AbstractMost system engineers today use graphical representations of a system to communicate its functional and data requirements. The most commonly used representations are the Function Flow Block Diagram (FFBD), Data Flow Diagram (DFD), N2 Chart, IDEF0 Diagram, and Behavior Diagram (BD). This paper discusses the characteristics of each and shows how they are related.When analyzed in the context of specifying functional control and data modeling, it appears that the FFBD and DFD representations are limiting, special cases of the Behavior Diagram. The N2 Chart has the same capability as the DFD, with a more formal format. The IDEF0 is essentially an N2 Chart with some control definition (no constructs) capability. The IDEF0 has the capability to indicate the allocation of functions to system components.Thus, the Behavior Diagram features comprise a “parent/unified” set of graphical system representations. To achieve the same level of specification completeness, you would have to use an integrated set of the FFBD and one of the data models or augment the FFBD with a graphical representation of the data model, as was done at TRW (then called Function Sequence Diagrams, FSDs).
7.4.3 Human‐System Interaction Development: An Integral Part of the Systems Engineering Process
Authors: Buie Elizabeth , Vallone Antonio 
Published: November 2014

AbstractAs currently defined and practiced, the systems engineering process (SEP) overlooks the design of human‐system interaction (HSI) as a systems engineering activity. Integrating HSI engineering into the SEP would promote the cost‐effective development of highly usable, reliable systems and products. This paper shows that the integration effort must identify the roles that humans play and the perspectives from which system development can be perceived: Support system, environmental system, and total system (which includes the system's users). This paper presents a scheme for an SEP that includes HSI definition and design, and it shows an example of applying the scheme to a software system, where the HSI is human‐computer interaction. Integrating HSI engineering and SEP forms the basis of effective multidisciplinary collaboration and the development of human‐centered systems.
7.5.2 RAPID PROCESS DESIGN A SYSTEM ENGINEERING DESIGN METHOD
Authors: Aguilar Ronald J. 
Published: November 2014

AbstractA rapid method has been developed for the design of computing system capabilities and/or human work flow activities. This design method is call Rapid Process Design (RPD) and is based on the definition of processes and not requirements. This design originally was developed for use as a preliminary design tool supporting the Definition Phase for system development programs using the Rapid Development Methodology (RDM) [1]. The RPD method allows for quick design of automated computing processes for immediate computing system capability deliveries. A key element of RPD is the definition of a process and its associated conditions and constraints. The process definition can be used to support evaluation and testing of a delivered computing system capability or human work flow.
INFORMATION SYSTEM TRENDS INFLUENCING SYSTEMS ENGINEERING
Authors: Howe Donald M. 
Published: November 2014

AbstractGovernment and industry are focusing on “information” system technology to provide dramatic changes that will be the critical factors in a comprehensive range of activities from achieving‐competitive‐advantage to winning‐wars. System, software, and security engineering for information systems involve principles and practices that continue to evolve. This paper identifies, compares, and questions those principles and practices. It characterizes the information system development/integration paradigms as being in a state of flux. In addition, architectural concepts are discussed that provide a framework for information system services that support a variety of missions and functions.Three salient points of the paper are: (1) system engineers should become familiar with “technical” information system architecture alternatives, (2) advances in technology are leading to the merging of system, software, and hardware engineering disciplines at the architectural level, and (3) requirements‐definition and design‐resolution procedures are being revolutionized through incremental/continuous development paradigms.