bluuebunny/crossref_metadata_2025_split huggingface dataset:
10.2.2 Architecture Framework for Spacecraft Computer Control Safety System
Authors: Shirasaka Seiko 
Published: November 2014

AbstractWe have a strong demand to design computer control safety system because crew stats to stay the international space station continuously, but there is no design framework for spacecraft computer control safety system. In this paper, we propose the architecture framework for spacecraft computer control safety system to guide a safety systems engineer to design computer controlled safety system. This framework is based on the general safety design process and NASA's computer safety requirements. The architecture framework can be proposed in accordance with the coming new IEEE1471 standard. This architecture framework can cover all design processes which are mandatory to be conducted to design system safety architecture. From this result, we suppose that this architecture framework reaches at least mandatory level.
10.4.2 Al‐Qaeda as an Adaptive Organization: a Case Study
Authors: Powell Trina , Hutchison Nicole , Pyster Art 
Published: November 2014

AbstractSince September 11, 2001, al‐Qaeda has proven itself to be an organization capable of surviving in a hostile environment where they are consistently targeted by the U.S. in political and military actions. Their survival is due, in large part, to their ability to adapt to the environment in which they operate. This level of adaptability—or agility—makes them an excellent target for a case study on adaptability. In ongoing research, the authors explain that by studying the organization and identifying elements which make them agile, some recommendation can be made for strategies to increase agility in similar, open organizations. Some potential implications for other types of organizations are also discussed.
11.2.1 Getting Started on the Right Foot: Developing Requirements for Constellation's Next Generation Space Suit
Authors: Wheatcraft Louis S. , Hill Terry R. 
Published: November 2014

AbstractA major challenge identified by the General Accounting Office and NASA's Inspector General is a project's inability to fully define project requirements prior to entering into contractual arrangements, placing projects at risk of significant cost overruns, schedule delays, and performance shortfalls. In 2007, the Constellation Space Suit Element (CSSE) was tasked to produce their Level IV Element Requirements Document (ERD) and baseline it within a 3‐month period. Aware of the consequences resulting from a poor set of requirements, NASA's Space Suit Project instituted a continuous requirement validation process that would allow the project team to develop a correct, consistent, and complete requirement set within tight schedule constraints. The result was an order of magnitude reduction of review comments against the ERD compared to the number of comments against the parent Level III System Requirements Document (SRD).
11.4.2 Systems Engineering Return on Investment
Authors: Honour Eric 
Published: November 2014

AbstractResearch work continues into Systems Engineering Return on Investment (SE‐ROI) following prior work on Value of Systems Engineering and Systems Engineering Effectiveness. This paper presents major results in the form of statistically proven relationships between systems engineering (SE) activities and the technical, schedule and cost success of programs. It has been found that all defined SE activities correlate positively with program success as measured in three of four success metrics used (cost overrun, schedule overrun and perceptive success). When the effect of program characterization parameters is included, the correlation is strong with optimum levels of SE activities as much as 25% of a program cost. The paper presents quantified values for the relationships, indicating appropriate levels of each SE activity that correlate to optimum levels of success. Results show a surprising lack of correlation between SE activities and the technical quality of the product system, for which some possible explanations are provided.
Prepare for SE Certification with an INCOSE Tutorial
Authors: Clark John O. 
Published: November 2014

AbstractInterested in Systems Engineering certification? John O. Clark will present a 2‐day tutorial immediately preceding the IS10 Conference. This tutorial provides an overview of the INCOSE SE Handbook to help you prepare for the INCOSE SE Certification exam. The tutorial covers the Certified Systems Engineering Professional (CSEP) process as well as the sections and appendices of the SE Handbook, Version 3.1 (the basis for the certification exam), in a study group format. It also provides example exam questions and tips on filling out your CSEP application. The tutorial consists of 16 sections from Saturday, July 10 through Sunday, Sunday July 11, from 8:00 a.m. ‐ 5:00 p.m. each day. The tutorial hardcopies, certificate of completion, and refreshments are included. For more information on the CSEP application process see http://www.incose.org/educationcareers/certification/, and to apply on‐line in advance of the tutorial see the IS10 Registration site, or contact John Clark at (tjohn.clark@incose.org). Registrants are encouraged, but not required, to attend the IS10.
Why Johnny Still Cannot Write Requirements
Authors: Hooks Ivy 
Published: November 2014

AbstractIn 1990, the Why Johnny Can't Write Requirements paper was published by IEEE and also presented to a Data Processing Management Association Symposium. During that year INCOSE was formed, Hubble Space Telescope was launched, Iraq invaded Kuwait, Alan Davis published a book on writing software requirements, several requirement management tools were marketed and a few classes existed. A lot has happened in 20 years. Our view of the universe has changed because of Hubble, our understanding of how wars will be fought in the future has changed because of what happened in Iraq and Kuwait, and many more people are on the requirements and system engineering band wagon than even knew it existed in 1990.We'll explore how things were 20 years ago with updates for the intervening years, to understand where we have been and what has happened in the world, to INCOSE, to SEs and to requirements processes, practices, use of tools and other changes. We'll share your feedback on where you think today's requirements problems lie, for you and for your organization.We'll look at where you are now by having you take a short quiz on requirements and grade yourself. This will help you understand if you need to learn more of the basics or move on to other topics and give you some ideas to take back to your own organization.We'll explore what still needs to be done now and how you can go about causing more changes to improve requirements processes and practices to help your organization or company, much more efficiently and effectively, develop or acquire the products that are needed for your success and the success of your customers and users.
Modeling with SysML
Authors: Friedenthal Sanford , Wolfrom Joseph A 
Published: November 2014

AbstractThe OMG Systems Modeling Language (OMG SysML™) is a general‐purpose, graphical, modeling language for specifying, analyzing, designing, and verifying complex systems that may include hardware, software, information, personnel, procedures, and facilities. In particular, it provides graphical representations with a semantic foundation for modeling system requirements, behavior, structure, and parametric equations that can integrate with a broad range of engineering analysis. SysML represents a subset of UML 2.0 with extensions to satisfy the requirements of the UML™ for Systems Engineering RFP. The OMG SysML™ Specification was adopted in May 2006. For more information on SysML, including articles, tool vendor and related links, and the specification, go to http://www.omgsysml.org/.This tutorial provides an introduction to how SysML can address your systems engineering needs, including: background and motivation, an overview of the SysML diagram types and language concepts, a demonstration of how the language can be used throughout a Model‐based Systems Engineering (MBSE) process. A class exercise is included to help solidify the student's understanding of the language. The course will also include a brief introduction to a typical SysML tool.Attendees should gain appreciation of the value of model‐based Systems Engineering versus legacy, document‐centric methods; awareness of the graphical notation; and a high level understanding of when and how a Systems Engineer can exploit the various diagrams and models as part of their systems engineering process.
Reuse of requirements in the context of product lines of a complex system
Authors: Fanmuy Gauthier , Djebbi Olfa 
Published: November 2014

Abstractthis paper is about Product lines. A product line is the development of products that have commonalities. It is based on reusing engineering artifacts (requirements, architecture, tests…) and on managing variants of products. The development of a set of products rather than developing single products independently, which minimizes costs and completion time. This paper is about reusing a set of common requirements. It describes the different techniques for requirements reuse and a panorama of the different tools. It presents an implementation in DOORS.
A Systems Engineer's Approach to Understanding Waldenstrom's Macroglobulinemia and Idiopathic Thrombocytopenia Purpura
Authors: Paasch John Howard 
Published: November 2014

AbstractThis paper describes the process followed by the author in attempting to understand the body/disease/treatment complex for the diseases he has, Idiopathic Thrombocytopenia Purpura (ITP) and Waldenstrom's Macroglobulinemia (WM) and the development of models and simulations to represent that complex. While little was known by the author about platelets and ITP, and IgM and WM at the time of diagnosis, a tops‐down approach was taken to learn the physiology and biology of each. Starting out at the most abstract level, the complete body system, research was performed to understand the processes from an organ/physiological perspective and put it into the context of the separate functional boxes that the author learned during his career as a system engineer working on complex aerospace systems. The models and simulations can become tools to create an interchange vehicle between the modeler and the medical person to further the understanding of this very complicated complex.
1.2.2 How applying models in work group sessions can help to retrieve information for making FTA and FMECA analysis
Authors: Vigdal Levi Andrè Berg , Muller Gerrit , Pennotti Mike 
Published: November 2014

AbstractDresser‐Rand Kongsberg is a company with a long history of building radial gas turbines in the 2MW range. Since the first gas turbine was developed at Kongsberg, the turbine has been subject to several upgrades, the latest being called KG2‐3E. To compete with radial gas turbines with newer technology, a decision was made to develop a completely new engine, (KG2–3G), based on the experience from the previous KG2 turbines. A gas turbine is a complex system; it is therefore challenging to prevent as many of the high risk failure modes as possible during the test and integration.To identify high‐risk failure modes a combination of Failure Mode Effect Criticality Analysis (FMECA) and Fault Tree Analysis (FTA) was applied. For the analysis, it was important to get input based on experience and knowledge within the company. Five senior engineers, who have been working with Gas Turbines for over 40 years, were the source of this knowledge. Work sessions were arranged to create discussions and extract as much “know‐how” as possible. The challenge during these sessions was to enforce engagement, creativity and discussion around the theme of concern. Methods such as applying different annotated diagrams representing the current theme and different methods of capturing the information were used to accomplish this.A comparison between central facilitation by electronic documents and active engagement of all participants by low‐tech means was performed. The low‐tech means of applying Post‐It and flip charts seemed to be the superior method that made participants more engaged. Different models, such as FTA graphs, technical drawings, and simpler block diagrams were applied and compared. It was discovered that it is important that the models displayed something the participants could recognize. It was also clear that applying models that represented the theme of concern helped to improve engagement and creativity around that theme.
1.3.1 Increase Requirements Understanding by Playing Cooperative Games
Authors: Gelperin David 
Published: November 2014

AbstractSerious games are games whose primary purpose is not entertainment. Cooperative games structure communication (e.g. contract bridge) and cooperation (e.g. soccer) between players in the same group.Using serious, cooperative games improves Requirements Understanding (RU). This paper defines six RU games, maps them into ‘initial understanding space‘, and shows how to use a special Ouija board to choose the games to play on your project. An example of RU game selection is included.
1.3.3 Technical Baseline Repair
Authors: Kipp Jeremy 
Published: November 2014

AbstractText books provide guidance on how Systems Engineering should be done. Multiple papers and reports provide statistics and dissections of Systems Engineering related program failures. Few papers discuss how to bring programs back from a self perpetuating Systems Engineering downward spiral. This paper provides real world examples of how major legacy programs facing schedule slips, funding overruns and customer dissatisfaction, choose not to become a failure statistic and instead developed fiscally realistic solutions to successfully repair fractured, neglected, contested, and inconsistent technical requirement baselines.
1.5.0 DARPA and NSF Advances in Systems Engineering: META and Value‐Driven Design
Authors: Miller Bill 
Published: November 2014

AbstractINCOSE's objective to be the preeminent authority on systems engineering is being challenged by the US Defense Advanced Research Projects Agency (DARPA) META program and the National Science Foundation (NSF) Value‐Driven Design (VDD) initiative.The goal of the DARPA META program is to dramatically shorten by a factor of five the design, integration, and verification timeline for defense systems. DARPA hypothesizes that a major cause of failed and challenged defense programs is the failure to update the systems engineering, integration and test process that has its roots in the defense programs of the 1960s. The progression from MIL‐STD‐499 to current EIA, IEEE and ISO systems engineering standards are evolutionary steps that are insufficient because of the complexity of current systems. DARPAs approach through META is to innovate model‐based composition to better manage complexity by proving correct‐by‐construction models using a proof of principle demonstration of a complex air or ground vehicle. META is the upfront portion of the Adaptive Vehicle Make (AVM) portfolio.The hypothesis of the NSF VDD Initiative is that the systems engineering approach to flow‐down and allocation of requirements results in systems that do not meet their system level requirements. The underlying cause is the nature of the human condition regarding risk taking and risk aversion. The VDD initiative is tapping into relevant fields in the social sciences and the use of objective functions in order to reinvigorate research into systems engineering and engineering design.
2.2.1 When is Enough Enough? Tailoring Processes in Systems Engineering
Authors: Pickard Andrew C , Nolan Andrew J 
Published: November 2014

AbstractSystems Engineering Processes are usually written to be applied to the development of a complex system, starting from a blank sheet of paper. The mindset is that the processes have to be followed with 100% compliance to even stand a chance of developing a successful system.In practice, many System Engineering activities involve the development of small, less complex systems, often by modification of a pre‐existing system. Even large, complex systems will be subject to incremental or spiral development where the increments are deliberately chosen to avoid complex interactions with the rest of the system. In addition, the full suite of systems engineering practices are designed to address all types of risks but not all projects will need such techniques. For example, stakeholder analysis and requirements elicitation will not be critical if the system is undergoing a refresh to address component obsolescence. One size fits all is a wasteful approach when you consider the processes are designed for all possible systems.Under these circumstances, is it appropriate to apply the full weight of the Systems Engineering processes used for the initial development of a complex system to these incremental developments or to less complex systems? If not, what parts of the process should be simplified or omitted, and why?It is said that “Processes are guidance for wise people” ‐ but if you don't follow the process, are you wise or otherwise? The focus of this paper is to present a “wise” approach to selecting which processes to follow, and to what level of rigor. It describes an approach grounded in Technical Risk Management and Probability Calculus to decide how to tailor Systems Engineering processes when developing less complex systems or introducing incremental developments or modifications to a complex system.
2.3.0 Is Requirements Engineering Really Necessary?
Authors: Berenbach Brian , Smiley Karen , Beatty Joy , Solomon Paul , Sampson Mark 
Published: November 2014

AbstractThis panel discussion will explore aspects of systems engineering where some engineers fear to tread. Some of the topics explored will include:
Should there be requirements engineers at all on systems development projects?
Can any systems engineer do requirements engineering (RE) well? If not, what additional training would be most useful?
Is RE really necessary (after all, big systems were built for hundreds of years without it)?
If RE is really necessary, should it be done by junior or senior staff?
Do we really need heavyweight RE processes and tools (ever, always, or never)?
The panelists are all senior engineers or project management professionals who have “seen it all” and do not necessarily share the same views. Perhaps through dialogue, some of the above questions can be answered; whether or not they are, everyone attending the panel will hopefully gain some new insights on the applicability of the field of requirements engineering to systems work.
2.4.1 Combining Lean and Sustainable Concepts with Systems Engineering for Manufacturing Enterprises
Authors: Nakano Masaru 
Published: November 2014

AbstractThe field of lean systems engineering (LSE) has recently emerged in systems engineering (SE). This concept applies the lean concept, which originally comes from the Toyota production system (TPS), to one‐off applications, such as large complex development projects for aerospace and the military. Some lean principles are generally used in Japanese manufacturing companies and are not unique to Toyota Motor Co.; the concept referred to as the Japanese production system (JPS), is an important factor in making an enterprise sustainable through continuous and endless improvement activities for marketing and quality management. TPS has been extended from production systems to product system development and enterprise management for repetitive manufacturing industries, and is called enterprise TPS (E‐TPS) in this paper.This paper decomposes the E‐TPS concept into three components from the original TPS, JPS, and SE, and proposes the idea of a lean and sustainable enterprise. This is yet another interpretation of LSE based not on lean concepts, but TPS.
3.1.1 A Look at the U.S. Energy System –A Strategic Impact Model (2050 SIM)
Authors: Pincock Layne F. , Collins John W. 
Published: November 2014

AbstractAlthough the United States (U.S.) energy infrastructure is reliable and accessible, it is also excessively reliant on foreign energy sources, experiences high volatility in energy prices, does not always practice good stewardship of finite indigenous energy resources, and emits significant quantities of greenhouse gases. The U.S. Department of Energy is conducting research and development on advanced nuclear reactor concepts and technologies, including High Temperature Gas Reactor (HTGR) technologies, directed at helping the United States meet its current and future energy challenges.This paper discusses the systematic approach used to develop the 2050 Strategic Impact Model (2050 SIM), which allows the user to analyze and depict the benefits of various energy sources in meeting the energy demand. It also provides an overall systems understanding of the tradeoffs between building and using HTGRs versus other existing technologies for providing energy (heat and electricity) to various energy‐use sectors in the United States. This paper also provides the assumptions used in the model, the rational for the methodology, and the references for the source documentation and source data used in developing 2050 SIM.
3.3.2 X‐driven development: finding the right combination of approaches for systems engineering
Authors: Woodcock Hazel , Chard Jonathon 
Published: November 2014

AbstractThis paper explores the relationship between requirements‐driven, model‐driven and test‐driven development, the value that each technique can provide and the circumstances under which each is appropriate. We propose that there is no one technique that represents the ‘right’ answer, rather that they are complementary techniques which can be combined to reduce risk within the development process—what we're calling X‐driven development.We further propose that the precise combination of techniques that should be applied is not constant between different development projects. Project and product characteristics influence the approach that should be taken, and different industries are aligned with particular combinations of characteristics.
3.4.0 Integrating MBSE into a Multi‐Disciplinary Engineering Environment
Authors: Friedenthal Sanford , Williamson Don , Jimenez Alex , Hoffman Mark , Liberto Nicholas Di , De Koning Hans Peter 
Published: November 2014

AbstractModel‐based systems engineering (MBSE) formalizes the practice of systems engineering through the use of models. This panel is intended to address considerations for incorporating MBSE into a broader multi‐disciplinary engineering environment. Engineering disciplines use multiple languages and tools whose results are not always easily integrated. The lack of integration is a source of design discrepancies and errors. The potential for MBSE is that it provides a means to integrate multi‐disciplinary engineering including systems, hardware, software, analysis, and test throughout the development life cycle.This panel will include representatives from other engineering disciplines to address questions such as: 1) What should other engineering disciplines expect from MBSE, and what should systems engineering expect from other disciplines to enable MBSE? 2) What can MBSE learn from model‐based approaches used in other engineering disciplines? 3) How should the practices and tools be integrated/coupled across disciplines? 4) How are the system, hardware, and software models managed to ensure an integrated technical baseline? 5) How should a program be organized to achieve more effective utilization and application of model‐based engineering? These are some of the questions that must be answered to more fully reap the benefits of MBSE.