bluuebunny/crossref_metadata_2025_split huggingface dataset:
11.4.3 Measuring Systems Engineering Productivity
Authors: Wang Gan , Shernoff Alex , Saleski Lori , Deal John C. 
Published: November 2014

AbstractProductivity measurement has long been employed to guide economic activities. Engineering organizations, as labor‐intensive economic entities, have used a variety of labor productivity metrics to capture the underlying productivity and efficiency (a reciprocal notion), in their ever‐enduring attempts to produce more outputs with fewer human resources. Depending on the functional disciplines, some widely embraced and de facto standard measures range from hours per drawing in hardware engineering, to lines of code per hour or day practiced in software engineering. Systems engineering, a relatively young profession still struggling to find its identity at times, has not yet reached an agreement on how it should capture its productivity and efficiency. However, such a measure is critical in managing resources, improving processes and work output, and establishing its utility as a bona‐fide field of engineering in production of goods and services.This paper presents a proposed systems engineering productivity and efficiency (P&E) measure for system development projects, where there is usually the greatest amount of systems engineering content. This measure is defined by using parameters described in COSYSMO, a parametric estimating model for systems engineering. We provide the definition, recommendations for deployment, and relay our experience in applying this measure to organizational productivity and efficiency improvement.
Enabling Collaborative Decision Making through Applied Systems Engineering Tools, Methods, and Processes
Authors: Ender Tommer R. 
Published: November 2014

AbstractIncreasingly complex problems involved in systems development drive systems engineers to develop novel decision making processes. The breadth of complex problems demands the interaction of various stakeholders, including both decision makers and subject matter experts, each focusing on specific areas but all addressing a higher level common cause. The process brought forth in this tutorial integrates a series of methods, some widely accepted and others which are novel in nature, in order to enable a collaborative process for technology selection. Quality Function Deployment is used to capture customer desires and focus engineering level requirements. Multi‐Attribute Decision Making is used to identify system configurations when multiple and competing objectives exist, which is a situation where traditional system optimization struggles. System modeling is a necessary step to analyze and understand the impact of various systems options. This seminar therefore introduces the process of surrogate modeling in order to rapidly access elements of modeling and simulation, a necessary step to analyze system options. The very integration of these applied systems engineering methods enables collaborative decision making throughout system development. A proof of concept is presented where each of these methods is applied in the technology selection portfolio analysis of renewable energy system options for a remote off‐grid site.
Establishing and Using Risk Management Effectively
Authors: Powell Mark A. 
Published: November 2014

AbstractWe manage risk every day of our lives. You would think all good SE's would be good risk managers. Yet many enterprises fail because some unidentified or un‐handled risk materializes. Many enterprises fail to take advantage of positive risks (opportunities) that could all but ensure success. Risk Management is not as easy as it seems it should be.This tutorial reveals to both the new SE and the seasoned veteran looking for a refresher the secrets of Risk Management and how to make it work. We will review the basic concepts of formal Risk Management and how it is executed in Systems Engineering. We will cover in depth all seven areas of Risk Management: Identification, Analysis, Assessment, Mitigation, Accounting, Planning, and Communication. Each of these areas will be approached with a specific emphasis on how they work together to make an enterprise successful. Further, we will set up a framework for introducing Risk Management within Systems Engineering, to work synergistically by integrating it with Project Management. And as icing on the cake, we will introduce some new methods for risk assessment that make the practice much more effective.
Lean Enablers for Systems Engineering
Authors: Oppenheim Bohdan “Bo” W. 
Published: November 2014

AbstractLean Thinking is the paradigm that enabled Toyota to rise to the best and largest auto company in the world. The paradigm includes not only Lean manufacturing but also extraordinary effective Product Development and Systems Engineering, as well as a culture based on Respect for People.Systems Engineering is regarded as a technically sound process but often burdened with waste and inefficiencies. Lean Systems Engineering is a new body of knowledge applying the wisdom of Lean Thinking to Systems Engineering. Systems Engineering and Lean have overlaps and differences, but both represent processes that evolved over time with the common goal of delivering product or system lifecycle value to the customer. Lean Systems Engineering represents synergy of the two, leading to superior systems engineering process.Most emphatically, Lean Systems Engineering is not a re‐packaged FBC or Acquisition Reform“. Lean Systems Engineering does not mean ”less Systems Engineering”; it means more and better Systems Engineering, with better preparations, planning, front‐loading, training, and more common sense, leading to better program execution.Lean Enablers for Systems Engineering is a product designed by 14 experts from industry, academia, and U.S. and foreign governments, supported by 115+ strong Lean Systems Engineering Working Group of INCOSE. Lean Enablers are formulated as 194 “do's” and “don'ts” of Systems Engineering practice focused on Mission Assurance/Product Success and elimination of waste.The workshop will cover three parts:
Description of the development process of Lean Enablers for SE
Presentation of 194 Lean Enablers organized into six Lean Principles: Value, Value Stream Mapping, Flow, Pull, Perfection, and People.
“Validation” of the Lean Enablers by surveys, and by benchmarking with recent studies by NASA and U.S. Government Accounting Office.
Early feedback from past tutorials and implementation
Roadmapping for Strategy Support
Authors: Muller Gerrit 
Published: November 2014

AbstractFormulating and deploying a strategy requires a combination of vision and analysis. Roadmapping is a tool to explore and articulate future needs and trends for different dimensions.Unfortunately most companies limit their roadmaps to either products and technology. In this tutorial we will show how to increase the roadmap value by integrating dimensions such as the market and customer context, the product portfolio, the technology, competences and supply chain, and processes. Roadmapping helps by relating these different dimensions in time, with a horizon of many years. We will discuss how to create and maintain roadmaps and give practical tips on the format.All information (System Architecture articles, course material, curriculum vitae) can be found at: Gaudí systems architecting http://www.gaudisite.nl/
A Model Driven Development approach to supporting System Engineering Trade Studies
Authors: Bleakley Graham John 
Published: November 2014

AbstractIt is very common in manufacturing organizations for the organization to build its new products using the same or similar technology as the previous versions of the product. This means that the organization is not making the best use of new technology or components that could potentially improve their products and/or profitability. This presentation demonstrates an objective approach to evaluate and select complex physical architectures, i.e. doing a Trade Study. It is based upon SysML and it uses a modeling toolset (ref 1) to demonstrate the technique. The approach is based upon the definition of assessment criteria and target values for the product under consideration. Various means of physically realizing the architecture are proposed and the combined effect of the various components evaluated against the target values for the product. The results of this are used as the basis for final selection of the architecture. A practical worked example is provided throughout the paper to further demonstrate the techniques involved.
Applying Systems Engineering in a Renewable Energy Research & Development Environment
Authors: Snyder Neil , Antkowiak Mark 
Published: November 2014

AbstractSystems Engineering (SE) practice has largely developed around a few specific industries, especially aerospace/defense and IT. SE is well understood by, and remains associated with, these industries. The classical systems engineering process starts with conceptual development of a specific system that will ultimately be produced and deployed. In the renewable energy R&D environment, neither of these normal cases apply; the work is being conducted in a culture that is generally unfamiliar with systems engineering, and the R&D activities are mostly oriented toward technology development and refinement rather than toward development of a specific deployable system. Nevertheless, systems engineering principles can be applied to enhance the management of the Research & Development (R&D) process, but significant tailoring of SE processes is required, and enhanced modeling and simulation techniques must be applied to deal with all the unknowns at a very early part of the system lifecycle. The lessons learned from several years of experience in this unique environment at the National Renewable Energy Laboratory, as well as a number of new ideas for future process enhancements, will be explored in this paper.
A Student's Perspective on the Education of Systems Engineers
Authors: Calderon Juan C. 
Published: November 2014

AbstractThe education of systems engineers is a main focus of the International Council on Systems Engineering (INCOSE). INCOSE released its latest guidance via the Systems Engineering (SE) Vision 2020 which describes the need for an increase in several aspects of systems engineering including how we educate systems engineers. Being a current graduate student of systems engineering provides me with unique insights into this process. To augment my academic experience, I also bring several years of experience in the military defense industry. This paper presents my experience through multiple perspectives, while analyzing the current curriculum for systems engineering education. The main lesson learned is that the study of systems engineering is a journey and not a destination.
A Day in the Life of a Verification Requirement
Authors: Scukanec Stephen J , van Gaasbeek James R 
Published: November 2014

AbstractOne measure of the quality of a product requirement is that it be verifiable. Verifiability assessment is one of the exit criteria for the Systems Requirements Review and is necessary for requirement validity. Nomination of one or more verification methods (examination, analysis, demonstration or test) is often taken as the sole evidence of verifiability. A completed Verification Cross Reference Matrix is frequently considered as the final verifiability assessment and responsibility for the remainder of the verification effort is transferred to the test and evaluation and other implementing communities for completion.Lessons learned from many Programs have shown that a more robust application of systems engineering should include the requirements engineers (with detailed knowledge of product requirement intent) working with the verification implementing organizations as the best combination to define the verification requirements. Such definition should include statement of the verification objectives, success criteria and environment. Including this information in the “Quality Assurance” section of the requirements document allows for buy‐in by the customer well in advance of implementing the verification activities. This information is used by verification personnel to generate one or more verification plans and to develop the detailed verification program. Verification requirements are planned into verification events which are executed using the proper system elements and environments. These verification requirements are key to establishing long lead verification facilities, tools and laboratories. Early definition of these requirements helps prevent facility re‐designs and verification re‐plans that can cause expensive delays. Finally, verification data analysis is performed, and the information compiled into verification reports certifying system product requirements compliance. This robust verification approach will provide proof of requirements satisfaction, leading to systems that meet the customers' needs at a lower life‐cycle cost.This paper is written to explore the value of well‐crafted verification requirements developed early in the Program. A “Day in the Life of a Verification Requirement” shows the interaction and benefits of verification requirements to the verification execution teams. The reader will be offered a lifecycle description of the verification requirement from conception to certification.
3.3.1 System Phases, Modes, and States: Solutions to Controversial Issues
Authors: Wasson Charles S. 
Published: November 2014

AbstractSystem phases, modes, and states are often one of the most controversial concepts in System Engineering due to a lack of standards for implementation. Yet, the topic serves as one of the most critical guiding principles of System Engineering: Decompose system complexity into manageable levels and entities with acceptable risk that lead to optimal system design solutions.Four issues contribute to the challenges of implementing system phases, modes, and states:
Issue #1 – Definitions of “mode(s)” and a “state(s)”
Issue #2 ‐ Do “modes” contain “states” or do “states” contain “modes”?
Issue #3 ‐ Should specifications specify “modes and states”?
Issue #4 ‐ Should specifications flow down “modes and states”?To address these four issues, this paper provides a statement of the problem, identifies sources of the problem, provides clarifying definitions, and provides illustrative examples of “modes” and “states”. Building on the foundational definitions, the paper explores the entity relationships (ERs) between phases, modes, and states and how they can be employed as a problem solving‐solution development framework to identify and link system phases of operation, modes, use cases, various types of states to the system architecture.This paper proposes that due to the abstractness and understanding of the term “state”, communications among engineers becomes confusing and conflicting. Investigation and analysis of this reveals that “states” have at least four contexts of usage: 1) organizational or logistical employment of a system as an asset – i.e., System States, 2) the operating condition of a system– i.e. Operational States, 3) the time and operating environment‐dependent dynamics of a system – i.e., Dynamic States, and 4) the physical arrangement of architectural capabilities to achieve performance‐based outcomes – i.e., Physical Configuration States.Based on a solution to Issues #1 and #2 that fuel the controversy, the paper addresses the final two issues – i.e., Issues #3 and #4 ‐ concerning specifying and flowing down “modes and states” in specifications. We conclude with a summary of recommendations concerning the four issues and provide suggestions for effective SE leadership to lead, apply, and orchestrate the concept of system phases, modes, and states.
4.6.3 An MBSE Feasibility Study using the Systems Integration Sandpit
Authors: Do Quoc , Lovric Bojan , Cook Stephen 
Published: November 2014

AbstractModel‐Based Systems Engineering (MBSE) involves a focal shift from document‐centric to model‐centric systems engineering practices in which the model becomes the primary systems engineering artifact to represent the system specification and design. For an organization, early adoption of new approaches such as MBSE requires careful consideration of the cultural change, staff training needs, and introduction mechanisms to inform the cost‐benefit tradeoff and to ascertain the level of risks. To this end, this paper describes a pilot study conducted to investigate the above using an in‐house robotic surveillance system. The paper opens with a brief introduction to MBSE tools and methodologies, and the advantages advocated by the MBSE research community. The body of the paper describes the SysML model development activities undertaken in the pilot study and the lessons learned in the process. The paper concludes with a discussion on the potential of MBSE for major defence programs and for systems of systems integration.
11.3.1 Transforming the Enterprise Using a Systems Approach
Authors: Martin James N. 
Published: November 2014

AbstractEnterprise Systems Engineering (ESE) is an emerging discipline that can be used to more confidently and rapidly create the essential changes for the modern enterprise to survive in these days of enormous economic and social uncertainty. Systems Engineering (SE) could have much to offer in enabling this transformation, but significant enhancements to traditional SE tools and methods must be brought to bear. This paper describes a set of principles and concepts that enables greater benefits when using the systems approach for enterprise transformation. These enhancements include technical activities, of course, but they also address the substantial leadership and managerial challenges at the enterprise level.
1.1.2 Applying Model Based Systems Engineering approach to Smart Grid Software Systems Security Requirements
Authors: Lakshminarayanan Sitaraman , Souvannarnarth Manyphay 
Published: November 2014

AbstractSmart Grid Systems are a classic example of a System of Systems. Smart Grid brings intelligence to the existing electric grid by integrating various software and devices from domains [1] such as Transmission, Distribution, Customer, Bulk Generation, Operations, Markets and Service providers. Security is very critical both from a reliability and compliance standpoint. Smart Grid as a System of Systems contains various Software Systems that provide the necessary intelligence and integration. Therfore building security within software systems is very critical as opposed to bolt on solution that is often deferred until deployment. System Architects face a tough challenge in understanding what are the various security requirements, how such requirements are applied to software systems at various interfaces, how to capture the system security artifacts and articulate it better to stakeholders. We describe how various model based systems engineering concepts are applied in capturing the requirements and how those requirements are applied to various components and interfaces and can provide traceability.
1.2.1 The Architecture and Design of a Corporate Engineering Data Repository
Authors: Wang Gan , Saleski Lori 
Published: November 2014

AbstractHistorical data has increasingly become an essential asset to enable engineering organizations to optimize its processes and improve its performance, as it empowers business organizations to engage and maneuver the challenging marketplace. In this paper, we present an enterprise‐level engineering data repository developed to systematically capture the corporation's historical program data. We highlight the architecture and design aspects that aim to support the lifecycle data needs of multiple engineering organizations and discuss the major components including the database, a set of data collection and analysis tools, and a collection process. We also relay our experience in governance issues and practical lessons learned. This repository has been systematically populated over the past five years and used in support of business winning and program execution.
1.3.2 Tailoring Systems Engineering Processes in a Conceptual Design Environment: a case study at NASA Marshall Spaceflight Center's ACO
Authors: Mulqueen John , Maples C. Dauphne , Fabisinski Leo 
Published: November 2014

AbstractThis paper provides an overview of Systems Engineering as it is applied in a conceptual design space systems department at the National Aeronautics and Space Administration (NASA) Marshall Spaceflight Center (MSFC) Advanced Concepts Office (ACO). Engineering work performed in the NASA MFSC's ACO is targeted toward the Exploratory Research and Concepts Development life cycle stages, as defined in the International Council on Systems Engineering (INCOSE) System Engineering Handbook.This paper addresses three ACO Systems Engineering tools that correspond to three INCOSE Technical Processes: Stakeholder Requirements Definition, Requirements Analysis, and Integration, as well as one Project Process – Risk Management. These processes are used to facilitate, streamline, and manage systems engineering processes tailored for the earliest two life cycle stages, which is the environment in which ACO engineers work.The role of systems engineers and systems engineering as performed in ACO is explored in this paper. The need for tailoring Systems Engineering processes, tools, and products in the ever‐changing engineering services ACO provides to its customers is addressed.
1.4.3 The Open Academic Model and the Impact of the Stevens Systems Engineering Program
Authors: Lasfer Kahina , Pyster Art 
Published: November 2014

AbstractThe Open Academic Model (OAM) is the research and education concept adopted by the Systems Engineering Program at Stevens Institute of Technology. Applying OAM principles, the Stevens program has grown from inception in 2001 into one of the largest in the U.S. in terms of education and research. The Stevens Systems Engineering program performance and consequent impact is characterized with respect to the OAM, which is based on five principles: (1) Broad Partnerships, (2) Blurred Boundaries, (3) Agile Environment, (4) Community Sharing; and (5) Second‐Career Faculty. The individual aspects of the OAM are not unique to Stevens, but the combination is novel and has underpinned Stevens' impact when the program is measured against the four general criteria of size, quality, publication record, and faculty leadership. The OAM has been implemented via a number of strategies that correlate with the performance of the program.
2.3.1 The U.S. Department of Defense Technology Transition: A Critical Assessment
Authors: Sharif Azi , Yu Junfang , Stracener Jerrell 
Published: November 2014

AbstractTechnology transition and implementation is a major challenge for the U.S. Department of Defense (DoD). The DoD utilizes the Technology Readiness Level (TRL) to measure technological maturity of projects for transition to the acquisition phase. However, the TRL is just a technology maturity metric and does not consider other factors, such as the project's costs benefits and risks rewards, that the acquisition community needs to consider in implementing a project; and this has led to delayed acquisition of projects with high TRL. Rapid technology transition requires additional metrics to supplement TRLs. The focus of this paper was on a critical review of methodologies developed for DoD's technology transition process. The literature review examined major empirical studies that have evaluated DoD's technology transition outcomes to identify main bottlenecks and shortcomings. We conclude that DoD's technology transition and acquisition needs improvement in measure of effectiveness.