bluuebunny/crossref_metadata_2025_split huggingface dataset:
1.2.3 A Systems Engineering Approach to Occupant Protection System Design and Optimization through Modeling and Simulation
Authors: Zhang glu , Ma Deren 
Published: November 2014

AbstractOccupant Protection Systems (OPS) have become a very important part of today's automotive systems. The extensive government regulations and consumer information programs make the design and optimization of the advanced OPS a complex and challenging task. A Systems Engineering (SE) approach is implemented throughout the OPS design and optimization process. The SE process includes customer requirements analysis, system concept design, system design, analysis and optimization and system verification and validation. To fully evaluate the performance of the OPS and ensure its compliance of government regulations, the system needs to be tested in a large number of crash scenarios. Using physical tests alone to develop the OPS is cost prohibitive. Therefore, computer modeling and simulation are utilized as one of the primary tools in the process. A frontal impact OPS design and optimization example is presented in the paper to demonstrate the process.
1.4.3 Learning Organizational Lessons
Authors: Sheard Sarah 
Published: November 2014

AbstractLearning and applying lessons is one requirement for continuing to improve business processes. Too often, companies neither collect lessons nor apply them well, or else they collect lessons well but have difficulty incorporating the lessons into future work. This paper describes the phases of learning lessons, necessary cultural factors and infrastructures, and how lessons‐learned programs evolve over time. The phases of a process for learning lessons are identification and collection, analysis and description, and communication and implementation. Additionally, this paper shows many dimensions of lessons‐learned efforts, provides pointers to many examples available online, and helps the reader establish a strategy for improving the ability of the organization to learn lessons.
2.4.3 Evolving Systems Engineering Processes: Moving from “What Systems Engineers Do” to “Engineering Systems“
Authors: Sheard Sarah , Holzer Thomas H. 
Published: November 2014

AbstractCompanies have documented systems engineering processes for years, in order to describe what the people they call “systems engineers” do to help product development. In an era of integrated processes, however, it becomes apparent that systems engineering is by its nature an integrating process. Therefore, true engineering of systems works better with an integrated set of engineering processes, within which are systems engineering roles. This paper describes why systems engineering processes are evolving in this manner, as well as how to evolve processes that describe what systems engineers do into an integrated set of processes for engineering systems.
2.5.2 Systems Engineering in an Outsourcing Environment
Authors: Parth Frank R. , Gumz Joy 
Published: November 2014

AbstractOutsourcing is the process of hiring someone else to do work that a business cannot, or does not wish to, do itself. While businesses have always done this, the entire field of outsourcing has taken on new dimensions and in the past few years has become vastly different from what it once was. Now companies are outsourcing significant portions of their core application development work overseas as well as areas such as order processing, help desks and others, justified by a lower cost per unit. As a result of overseas outsourcing, significant problems have arisen that either did not exist before or were easy to remedy when the work was done internally. Many of these problems can be traced to poor or missing requirements, a poor understanding of business processes, or to technology and security problems in the deliverables. This article discusses the role of systems engineering in avoiding or reducing the most significant problems. Rather than just gathering functional and performance requirements, systems engineers must now develop an entire requirements encyclopedia in order to provide enough information, do much more detailed business process analysis, and help develop testing and quality assurance approaches that can detect security back doors that may have been put into software products.
2.6.2 Systems Engineering Sizing in the Age of Acquisition Reform
Authors: Valerdi Ricardo , Ernstoff Michael , Mohlman Paul H. , Reifer Don , Stump Evin 
Published: November 2014

AbstractAs organizations develop more complex systems, increased emphasis is being placed on Systems Engineering (SE) to ensure that cost and schedule are within budget. Correspondingly, the failure to adequately plan and fund the systems engineering effort appears to have contributed to a number of cost overruns and schedule slips, especially in the development of complex ground and space systems. Government and commercial organizations have recently placed increased emphasis on accurately planning the SE function and on understanding the factors that influence the resources needed to implement and perform SE.In an attempt to better quantify the SE activity, the DoD acquisition community has been exploring Systems Engineering Revitalization and migrating back to a reinstatement of prescribed military standards. Several models and tools have become available to aid in forecasting systems engineering resource needs, but few guidelines exist to help engineers and program managers determine which approach is best suited for estimating any particular effort.To provide such guidelines, this paper provides an overview of eight existing cost models ‐ three of which focus on software and five on hardware. These models include SE components and employ unique approaches to sizing the SE effort. An overview of the genesis and assumptions of each model shed some light on their individual applicability. To complete the paper, future research topics are discussed along with recommendations on tasks to enhance the accuracy of SE sizing.
3.2.2 Optimal and Adaptable Reliability Test Planning Using Conditional Methods
Authors: Powell Mark A. 
Published: November 2014

AbstractDeveloping optimal cost verification strategies for performance requirements using the analysis or test methods can be difficult, if not impossible. Developing such a strategy that is also adaptable to unexpected test results is even more difficult. The author investigates a reliability requirement verification example from the automobile industry for cost optimization and adaptability to unexpected failures using classical methods. Verification strategies for this example are then developed using conditional methods. These conditional verification strategies demonstrate significant cost efficiencies, and provide easy adaptability to unexpected failures. These strategies further provide understandable decision criteria for test success or failure. Using conditional methods for verification of performance requirements provides opportunities for cost savings, adaptability to unexpected test results data, and clear decisions for product acceptance.
3.3.1 Consumer product development: A systems engineering approach to the derivation of design requirements from stakeholder needs
Authors: Agouridas Vassilis , McKay Alison , de Pennington Alan 
Published: November 2014

AbstractThis paper reports results of research into the engineering design of consumer electromechanical products. The research dealt with the derivation of design requirements from stakeholder needs. An approach based on principles of systems engineering was developed, applied and evaluated through a number of case studies that were carried out in three industrial domains. The evaluation showed that the approach can significantly improve the quality of product designs. The revision of the expressed stakeholder requirements and the expression of stakeholder requirements as stakeholder needs and stakeholder attributes were found to be key factors towards the improvement of product designs. It is recognised that there are many difficulties associated with the identification of stakeholder needs for both existing and new products. However, given a need, benefits can be gained from providing information to support traceability between design parameters, design requirements, stakeholder attributes and stakeholder needs; such traceability is a key enabler to downstream integration management.
3.4.3 Genomics: Requirements Going From Art to Industry
Authors: Kosack Daniel 
Published: November 2014

AbstractGenomics is a new science that is contributing significantly to our understanding of genes, life processes, and disease. Genomics endeavors to look at the entire organism – the complete DNA ‐ to study its entire gene set, observing mutations and diversity. Producing the entire DNA sequence and identifying the genes within is no easy task. As budgets are cut and cost becomes more important, the role of organized software and systems engineering becomes more pronounced.This paper describes the systems used at the Institute for Genomic Research (TIGR) to produce the sequence of an organism. The paper begins with an overview of the overall Genomics process. It follows with a discussion of the human genome project and how lessons learned from the project regarding scale and capability have affected the Genomics view of systems design. The paper continues with discussion about the need for traceable, consistent requirements and organized system design in Genomics. Finally, the paper discusses how the Institute for Genomic Research recognizes and addresses the need for proper systems development through requirements gathering and analysis, system decomposition, and rework.
3.6.2 Successful Integration of Systems Engineering and Program Management Processes
Authors: Witte Craig S. 
Published: November 2014

AbstractSince the inception of Systems Engineering as a discipline, Systems Engineers (SEs) have been providing technical leadership toward the successful completion of projects. As the science of project management has evolved, SEs and Project Managers (PMs) have grown more interdependent. In fact, there are many similarities in the skills required for Systems Engineers and Project Managers.This paper will provide a summary of the shared skills between both SE and PM professionals. A description of the interaction between SE and PM disciplines in various organizational structures will also be presented. A comparison will be made between PMI's view of product realization and the standard “Vee Diagram” process understood by most Systems Engineering professionals. And lastly, this paper will conclude with a description of the project management process followed at the Harris Corporation. Survey results will be presented illustrating the distribution of traditional project management functions between Project Managers, Systems Engineers, and Project Engineers.
4.1.1 Benefits in Using Object‐Oriented Methodology For Architecture Modeling
Authors: Osvalds Gundars 
Published: November 2014

AbstractCurrently enterprise and systems architecture models being developed by Systems Engineers to describe the stakeholders' problem often use the Structured/Functional Methodology while software designers usually use the Object‐Oriented Methodology. Thus, architectures represented with Functional Representation may not be fully implemented, as designed, by the software developers who use Object‐Oriented Representation. The systems engineer should consider the benefits in utilizing an Object‐Oriented Methodology in developing the architecture design. A benefit, in the use of the same representation, is the ability to create a concordant set of engineering products that are traceable from the design to the system implementation. Another benefit is that the Object‐Oriented Methodology is that it closely matches the stakeholders' view of the world which consists of objects that perform actions and utilize information. Therefore the use of the Object‐Oriented Methodology in the design and documentation of enterprise and system architectures provides reusable design artifacts for the software developers.
4.3.1 Security Engineering: Systems Engineering of Security through the Adaptation and Application of Risk Management
Authors: Gilliam David P. , Feather Martin S. 
Published: November 2014

AbstractInformation Technology (IT) Security Risk Management is a critical task in the organization, which must protect its resources and data against the loss of confidentiality, integrity, and availability. As systems become more complex and diverse, and more vulnerabilities are discovered while attacks from intrusions and malicious content increase, it is becoming increasingly difficult to manage IT security. This paper describes an approach to address IT security risk through risk management and mitigation in both the institution and in the project life cycle. The application of risk management to security engineering is described. Support for this through application of a security risk algorithm and a risk management tool for risk analysis is also discussed.
4.6.1 Combining Heuristic Search, Visualization and Data Mining for Exploration of System Design Spaces
Authors: Feather Martin S. , Kiper James D. , Kalafat Selcuk 
Published: November 2014

AbstractFinding a near‐optimal solution to a complex design problem is challenging. On the one hand the problem space is too large and convoluted for human comprehension, while on the other hand it is infeasible to elicit the entirety of design knowledge required for fully automatic problem solving.We report on a practical application of information technology techniques to aid system engineers effectively explore large design spaces. We make use of heuristic search, visualization and data mining, the combination of which we have implemented within a risk management tool in use at JPL and NASA.This approach is demonstrated on the planning for development of an advanced technology for spacecraft applications. In this context of risk‐informed design, numerous risk abatement options give rise to a huge space of potential design solutions. We show how our approach enhances the system engineers' ability to explore this design space.
5.1.1 From Stakeholder Values to Product Requirements
Authors: Weiss Stanley I. 
Published: November 2014

AbstractThe identification of all stakeholders, as well as their values, has become a basis, often insufficiently achieved, for understanding, prioritizing and realizing requirements for a product. Traditionally, these are gathered from a variety of sources and a widely used method for organizing, evaluating and tracking customer needs translation to design information is Quality Function Deployment (QFD).QFD is commonly understood as a matrix tool for collecting, organizing and prioritizing data for evaluation of requirements and their translation to technical characteristics of a system or product. Since true requirements are derivatives of the values of the many stakeholders associated with complex systems or products, a sequence of identifying stakeholders with their values and prioritization, leading to the development of requirements, provides a logical path to product design characteristics. QFD provides a means that facilitates this.The method described here has further value for data collection, reference and traceability since it is highly adaptable to changes in stakeholders and values
5.2.2 An Innovative Partnership in Systems Engineering for Schools
Authors: Brown Samantha 
Published: November 2014

AbstractMust the teaching of Systems Engineering be restricted to a postgraduate level? Evidence from Loughborough University's undergraduate course has taught us that this is not the case. So why stop there? Can you teach systems engineering in schools – to children from 5 to 18 years? Focussing mainly on the secondary level (11–18 years), this paper look at some of the issues, some of the UK‐wide activities and at BAE Systems's own programme of working with schools to bring the basics of systems engineering to the workforce of the future.
5.4.2 Architecting a Command and Control (C2) System
Authors: Cropley David H 
Published: November 2014

AbstractThe C4ISR Architecture Framework (C4ISRAF) mandates architecture products that are needed to describe typical defense information environments and hence entities such as a hypothetical future Command and Control (C2) Architecture. However, as is commonly understood, the C4ISRAF does not describe a methodology for creating the architecture products. This paper seeks to redress this deficiency by identifying a suitable methodology to create and evolve a C2 Architecture that maps to the C4ISRAF and its products.The strong influence of human activity in the problem domain necessitates both a functionalist and an interpretive approach to system design. This has been used to define an approach based on a multi‐methodology. The paper describes the steps taken to identify appropriate candidates for the multi‐methodology and concludes that there are two leading candidate hybrid multi‐methodologies: one that could be described as a soft mantle with a hard systems core and one that follows a more traditional hard systems paradigm.
5.5.3 Systems Engineering Management
Authors: Smith Alan , Cowper Douglas , Emes Michael 
Published: November 2014

AbstractOrganizations may have sophisticated and detailed systems engineering process models yet struggle to implement them effectively in the face of conflicting internal priorities, legacy practices and slowly changing cultures.Taking experiences from a number of sources this paper identifies a range of current systems engineering issues and suggests that it is the interface of systems engineering with other business activities that is a cause of many implementation problems. By taking a systems view of the business (a systems‐make‐systems approach), one can use systems engineering principles to address these problems. A broader remit for Systems Engineering Management is recommended.
6.3.1 Decision Oriented Systems Engineering (DOSE)1 – A Structured, Systematic Approach to Function Allocation
Authors: Buckley Michael E. , Stammnitz Volker 
Published: November 2014

AbstractPerhaps the most important reason Systems Engineering exists as a discipline lies in the observation that complex systems cannot be treated merely as an assemblage of so many building blocks. Systems Engineering employs techniques and practices that attempt to consider the whole throughout the design process. Systems Engineering offers quite an assortment of processes, and tools devices to capture, describe, derive, and otherwise characterize various aspects of systems under design or analysis. There are many evolving Systems Engineering processes and practices, including processes in which the object‐oriented paradigm dominates. Unfortunately, the set of available processes, models, and tools remains weakest where they are needed the most: where decision tradeoffs are most negotiable, where “requirements” are not yet firmly established, where the use of legacy systems can have the greatest impact, and where the (projected) life cycle impacts of such decisions are greatest.This paper describes a new system development practice named Decision Oriented Systems Engineering (DOSE). If consistently and diligently applied in tandem with other more conventional practices, DOSE provides a solid Systems Engineering “hook” to the application of Human Systems Integration principles and offers considerable promise in simplifying the design of even the most complex systems involving teams working with mixes of new, evolving, and legacy systems.
6.4.3 Ontology‐Enabled Validation of System Structure
Authors: Mayank Vimal , Kositsyna Natalya , Austin Mark 
Published: November 2014

AbstractThis paper describes a vision for team‐based synthesis of engineering systems, enhanced by technologies for ontology‐based computing, cast in a Semantic Web framework. As a first step, in this paper we describe an ontology‐enabled procedure for validation of system structure. We apply the procedure to the validation of connectivity relationships in a home theatre system.
7.2.2 On Methodology and System Framework for Knowledge Management in Allied System Engineering
Authors: Chen Yuh‐Min , Chen Yuh‐Jen , Kuo Jen‐Yao , Wang Chin‐Bin , Ho ChengTer 
Published: November 2014

AbstractThis paper presents a systematic approach to development of a methodology and a system framework for knowledge management to support allied system engineering. The approach of this research has laid‐down four phases: allied system engineering characterization, knowledge identification, analysis and modeling, KM strategy and methodology development, and system development. The methodology consists of a rationale behind the methodology, a life cycle model for knowledge management, and a distributed knowledge management framework. Based on the proposed methodology, a knowledge management system framework is developed using component technology. Besides providing functions for knowledge management and sharing, the system possesses properties to meet the hierarchical, distributed, flexible and dynamic‐configurable characteristics of allied system engineering.
8.1.2 Requirements Risk Assessment ‐ Integrating QFD and Risk Assessment
Authors: Kenley C. Robert 
Published: November 2014

AbstractA modified Quality Function Deployment (QFD) analysis [Hauser and Clausing, 1988] was applied to evaluate development risk for user requirements across multiple system architectures. Applying QFD to the risk assessments required tailoring the approach to capture and quantify subjective risk judgments and to reconcile them with raw risk assessment data from specific designs. Initial evaluation of development risk from each architecture showed that overall risk reduction activities were acceptable as planned. Risk assessments were also conducted on updated designs using the QFD assessment to confirm validity of the final risk reduction plans.This method extends previous work by Clausing and Cohen [1999], which described the use of QFD to capture requirements relationships, and U.S. Air Force guidance [AFMC, 1977], which describes methods for risk evaluation. It allows capture of the strength of relationship between user requirements and development risk early in a program by use of conceptual system architectures. This permits early evaluation of the trade offs between user requirements and risk mitigation efforts prior to committing a program to a functional baseline is established for user requirements and the design solution.
8.5.1 Design Reviews: A Customer's Confessions
Authors: Armstrong James R. 
Published: November 2014

AbstractEven when guidance was available on design reviews in MIL‐STD‐1521, much was left to the reader. Since the cancellation of the standard, specifics on design reviews have been limited. This paper provides several lessons learned and best practices that can be applied at any point in the program. As the title indicates, most of the lessons were learned from the viewpoint of the customer. They are augmented by experiences as the one being reviewed.