bluuebunny/crossref_metadata_2025_split huggingface dataset:
2.4.1 10 Pitfalls of System Process Development with Avoidance Solutions
Authors: Arnold Eileen 
Published: November 2014

AbstractProcess literature has provided excellent guidance on what to include when writing new process descriptions, but very little has stated clearly what actions must be taken by companies during the course of developing usable, integrated processes. Countless hours have and are being spent on development of company processes, which end up sitting on shelves in their unopened, shrink‐wrapped notebooks, or archived to sparsely accessed and often ignored internal web sites. Management assumes the processes must not be the right ones, or personnel would joyfully use them. The result is yet another extensive effort to “get it right” by re‐writing the processes with a different slant. Why is it that processes are not well received or utilized by some companies, yet others embrace process with open arms? This paper explores the author's experienced pitfalls of integrated, system process development at an organizational level, whether that translates to a program, division, or enterprise level, and offers avoidance solutions to help remedy the maladies. This paper is intended to provide solutions to circumvent the common maladies associated with process development and process improvement.
2.5.1 Collaborative processes enabler
Authors: MOLY Marlène , TREBUCQ Bruno , CALLOT Martine , SAINT‐MARC Laurent 
Published: November 2014

AbstractIn Concurrent Engineering, multi‐disciplinary teams of experts perform design activities. They contribute to the design activities collaboratively, which induce them to make decisions and share the information with each other with no systematic traceability.The purpose of this paper is to anticipate decisions by proposing rules and methods to enhance collaborative work concerning data engineering exchanges between all involved skills whatever their site or their firm. The main objective of this work is to enforce Discipline Collaboration in Engineering by :
Supporting Collaborative Processes complexity,
Enhance collaboration work through Engineering objects availability and quality control,
Decrease rework with obsolete information or over information.
To address the complexity, the method relies on invariant objects independently of the organization and discipline processes. A “collaborative platform” demonstrator based on the method will support the designers in their daily work.
2.6.3 Understanding Cost Analysis Process in United States Government Systems Acquisition
Authors: Covert Raymond P. , Jones Susan E. , Anderson Timothy P. 
Published: November 2014

AbstractCost estimates are one of the most widely known attributes of a program, but from an outsider's perspective, the process of cost estimation and analysis often appears to be a “black art.” The purpose of this paper is to describe the development and use of cost estimates and cost analysis, particularly with respect to United States (U. S.) government systems acquisition, and describe the systems engineers' role in this process.First, we discuss why a systems approach to cost analysis is critical to mission success and needs to begin at the time of program formulation. Second, we describe the cost analysis process. Third, we examine the most common methods used in cost estimation; the estimates' accuracies often depend on which methods are chosen and when these methods are used. Fourth, we describe the evolutionary process of cost estimation throughout the program lifecycle. Since the amount of information available to estimate the cost of a program changes over the lifecycle as the program evolves, so too should the methods used to estimate the program's cost. Finally, we describe the use of cost estimates in cost‐risk and cost‐benefit analysis.
3.1.1 Embedded Systems Engineering: Managing Systems Complexity, Change, and Crises
Authors: BeVier John L. , Calimer Colleen A. 
Published: November 2014

AbstractThe concept of the “Embedded Systems Engineer” is proposed by the authors. The purposeful inclusion, and redefinition of, the Systems Engineer from that of a specialist supporting engineering activity to that of the persistent critical function underlying the management and direction of the Dynamic System. Today, Dynamic Systems, as described by John Sterman in Business Dynamics, have become commonplace. However the Systems Engineering Profession has not adequately responded by creating a correspondingly dynamic engineering management structure.Crises driven Engineering Change Proposals in lieu of knowledge‐driven systems engineering has become the standard response. Systems Engineers are challenged to adopt a new and even more important role responsible for management and oversight, maintenance and operations, and especially architecture and behavior in a Learning System context. Because Dynamic Systems are primarily Learning Systems, the Systems Engineering function is placed “on‐line” to manage rapidly changing systems requirements. These modern Learning Systems are based on the seminal work of Jay Forrester. The Embedded System Engineer's unique capabilities are critical to competent management and decision‐making within Dynamic Systems.
3.1.2 The Seven Samurai of Systems Engineering: Dealing with the Complexity of 7 Interrelated Systems
Authors: Martin James N 
Published: November 2014

AbstractThere are seven different systems that must be acknowledged and understood by those who purport to do systems engineering. The main system to be engineered is the Intervention System that will be designed to solve a real or perceived problem. The Intervention System will be placed in a Context System and must be developed and deployed using a Realization System. The Intervention, when installed in the Context, becomes the Deployed System which is often different in substantial ways from the original intent of the Intervention. This Deployed System will interact with Collaborating Systems to accomplish its own functions. A Sustainment System provides services and materials to keep the Deployed System operational. Finally, there are one or more Competing Systems that may also solve the original problem and will compete for resources with your Deployed System. All seven systems must be properly reckoned with when engineering a system.
3.2.3 An Approach to Design for Safety in Complex Systems
Authors: Dulac Nicolas , Leveson Nancy 
Published: November 2014

AbstractMost traditional hazard analysis techniques rely on discrete failure events that do not adequately handle software intensive systems or system accidents resulting from dysfunctional interactions between system components. This paper demonstrates a methodology where a hazard analysis based on the STAMP accident model is performed together with the system development process to design for safety in a complex system. Unlike traditional hazard analyses, this approach considers system accidents, organizational factors, and the dynamics of complex systems. The analysis is refined as the system design progresses and produces safety‐related information to help systems engineers in making design decisions for complex safety‐critical systems. The preliminary design of a Space Shuttle Thermal Tile Processing System is used to demonstrate the approach.
3.5.1 How can Systems Engineering Improve Socioeconomic Conditions in Developing Countries? The Jamaica Situation
Authors: Gaynor Horace 
Published: November 2014

AbstractThe increased demand being placed on the dwindling resources of developing countries by rising populations, and the need to compete with more advanced nations in the global economy, have forced the implementation of projects that are stifling socioeconomic growth. The need to apply systems engineering concepts and methodologies in the field of socioeconomic engineering is discussed. A proposal for a collaborative effort of systems engineering experts working with targeted professional bodies to initiate a paradigm shift toward increased self‐reliance is outlined.
4.2.1 A Pattern for Enacting Systems Engineering Reviews in Systems Development
Authors: Fohn Steffen M. , Popick Paul 
Published: November 2014

AbstractOver the last several decades, various software development models have been articulated and discussed in literature. These models (stagewise, waterfall, spiral, iterative and incremental, etc.) have evolved in an effort to accommodate project environments' distinguishing characteristics: business volatility, organization and technical complexity, validation and delivery strategies. A project must consider these characteristics in choosing an appropriate development method, hence underlying development model. A project's adoption of a given development method however, often leaves the systems engineer with questions on how to integrate systems engineering planning and control, specifically technical reviews, into the development and integration effort. A pattern is proposed that abstracts the problem of applying systems engineering's reviews across various development models to achieve the benefits of the systems engineering technical reviews in conjunction with the benefits of a development model other than the waterfall model. The pattern is demonstrated with the stagewise and the RUP iterative development model and the resulting benefits are described.
5.1.2 Requirement Architecture Framework(RAF)
Authors: Lee Joong Yoon , Park Young Won 
Published: November 2014

AbstractThis paper describes a requirement architecture framework(RAF) intended for use during the front end of requirement definition processes. The requirement definition process is a highly conceptual process that is difficult to carry out. While there are several systems engineering standards, these standards describe only “what to do” not “how to do“. This study focuses on how to perform the requirements definition process including the integration of process, methods and tools for the front‐end activity of requirements definition process. Requirement architecture framework represents a model for use to define systems requirements in a systemic approach. The RAF model is structured in four segments, including 6W2H2V requirement representation method, requirement categorization, life cycle stakeholder and requirement definition process. The study also proposes a requirement quality metric, that measures defects per hundred requirements (DPHR), and requirement baseline control guidelines using DPHR as a metric. The study demonstrates the effectiveness of RAF applying DPHR by presenting the results of an experiment.
5.3.1 Adaptive Design Using System Representations
Authors: Dare Robert , Rebentisch Eric , Murman Earll 
Published: November 2014

AbstractAir Force weapon system development is a complex enterprise in which the stakeholders have differing and time‐varying needs and constraints. An uncertain environment of shifting budgets, evolving threats and rapid technology advances contributes to complexity. This paper explores how complexity can be addressed through collaborative efforts to enhance program adaptability. Case studies provide data on patterns of interaction during system design between the Air Force acquisition agency, operational users, and the development contractor. The studies focus on a form of boundary object referred to as a “system representation” that facilitates knowledge sharing across organizational boundaries, enhancing adaptability and enabling ongoing verification and validation of the emerging design. As programs used system representations to provide higher levels of knowledge sharing, they were found to be more adaptable. System representations were more effective at promoting adaptability when they portrayed the design with higher fidelity, providing system‐level detail and covering stakeholder emphasis areas.
5.4.3 Architecting and Innovating
Authors: Campbell Ronald B. 
Published: November 2014

AbstractInnovating is essential to sustained industrial growth and profitability. But experience amply demonstrates how difficult innovation is, especially for large companies. The synthesis of valued offerings by aligning customer needs with technology possibilities lies at the heart of innovation. System architects working at the strategic level are ideally positioned, as a consequence of their experience and training, to play a key and even a leadership role in enabling, energizing, and leading this synthesis. The scope of the architecting effort must include the process architecture of the entire value chain as well as the more conventional product architecture to address all potential wellsprings of innovation. This paper outlines an architecture‐centric approach to innovation, based on the concept of the system platform architecture.
5.6.3 Zoned Analysis: A Middle‐Out Method to Join the Top‐Down and Bottom‐Up Approaches During Mission Analysis1
Authors: Zirker Larry , Hamelin Douglas 
Published: November 2014

AbstractZoned analysis (ZA) is a decomposition methodology, which ultimately evolves into a graphical “big picture” of a project. This methodology maps the “journey” a systems engineer uses during the mission analysis phase to facilitate collaboration of team members, enhance management understanding of the project, show team members their responsibilities, link requirements to deliverables, and aid in the gap analysis between what is wanted and what is tasked. A ZA appears as a bull's‐eye or target with partitioned pie‐shaped sections emanating from the center circle to outer circles, or zones. The title of the project or program is placed in the center zone. Subsequent partitioned zones facilitate the decomposition hierarchy of the project, with the outer‐most zones or elements evolving as terminal elements or deliverables. This paper show how a ZA was used to flesh out the details in between top‐down and bottom‐up approaches during the mission analysis phase.
6.1.1 Compliance Mapping of Industry Standards to the Rockwell Collins' Technical Consistent Process Using a Requirements Database
Authors: Thompson Anthony J. , Povacz John F. , Bennett Richard A. 
Published: November 2014

AbstractThe growth in quantity, variety, and merging of industry standards, process capability models, regulatory requirements, and customer request has inundated many Original Equipment Manufactures' (OEMs) process groups. Customer requests for objective evidence corroborating capability and maturity of documented internal design and development processes are necessary to demonstrate compliance to these source requirements. This paper discusses Rockwell Collins' approach to manage these changes using a requirements database to assist projects in tailoring Enterprise standard design and development processes and processes assets to meet the customer requirements.
6.1.3 A Requirements Assessment Architecture that Combines Natural Language Parsing And Artificial Intelligence
Authors: Scott William , Cook Stephen 
Published: November 2014

AbstractWhile the need for good requirements is well understood, and there many sources that describe what constitutes a set of good requirements, poor requirements continue to plague projects. In recent years tools have become available to assist in requirements management and their rapid adoption throughout industry attests to their efficacy in data handling and display. Contemporary requirements engineering tools, however, provide few assessment capabilities and no semantic processing. This paper addresses that deficiency while building on the capability of existing tools. The paper opens by describing the philosophy we used to tackle the problem: emulate human reasoning; use several tiers of analysis; parse the requirement against a purpose‐designed a context‐free grammar; and employ case‐based reasoning to assess both individual requirements and the total requirements set. The paper concludes with descriptions of the architecture of a tool termed REWARD, its operational concept, and its implementation.
6.2.1 Systems Engineering Principles Revisited
Authors: Han Myeong‐Deok 
Published: November 2014

AbstractMaking a short list of principles and repeatedly using them to various systems engineering problems from time to time may help us to handle the complexity and changes of the systems engineering environment. KCOSE has been established in KOREA in February 2002. Just as INCOSE tried to set up some principles on SE right after they established the council, KCOSE is now trying to set up its own SE principles so that its members can share a common perspective about what is SE, what is the value of SE, what is the core of the SE processes, etc. Here I report the first draft of KCOSE SE Principles with how we approached to this.
6.3.3 A PS covering Functional Architecture support in SEDRES developed drafts of AP‐233
Authors: Herzog Erik 
Published: November 2014

AbstractThis paper takes a data exchange perspective on the multitude of methods proposed for capture of system functional architecture. The particular focus of the paper is the different approaches proposed for representing the control flow view of a model. We show that an extended Petri‐net notation can be used to capture control flow for methods like FFBD, behaviour diagram and also UML activity diagrams. An example is used to illustrate how the SEDRES developed drafts of AP‐233 can represent FFBD control flow. The paper also contains a general discussion on AP‐233 and the underlying non‐functional requirements for a data exchange standard.
6.5.2 Concepts Pertinent to the Future of INCOSE
Authors: Ring Jack 
Published: November 2014

AbstractINCOSE has the opportunity to emerge as the lead catalyst for evolving both SE practitioners and practices. The purpose of this paper is to point out key concepts for future versions of INCOSE that will enable such opportunity. This paper presents the envisioning phase of a system design by describing some of the options for INCOSE effectiveness thus its content, structure and behavior. Envisioning what INCOSE could be is a valuable step in sorting out what INCOSE should be. If properly considered, these options will serve to preclude blind spots or misassumptions when subsequent analysis is performed and decisions are taken. Uncertainties abound thus a broad span of alternatives is addressed.
7.1.3 Using a Requirements Management Tool in Technical Requirements Negotiations
Authors: Dale R.S. 
Published: November 2014

AbstractThis paper records the experiences of tracking the technical requirements for a missile system during the contract negotiation phase. Initially WORD documents were used to record the requirements but, because of their complexity and the frequency of change, these were abandoned in favour of using a Requirements Management tool. The paper tells the story as it was and then comments on this using the wonders of hindsight.Whilst the process worked well on this particular contract, it is recognised that contract negotiations can take a wide variety of forms from formal multi‐billion dollar contracts to strawman discussions for in‐house projects. I believe, however, that the underlying problems and approach to combatting them are sufficiently general to be applied universally. This paper highlights 10 tips as encouragement to anyone contemplating facing such negotiations.
7.2.1 Issues for Systems Engineering Research
Authors: Sahraoui Abd‐El‐Kader , Buede Dennis M. , Sage Andrew P. 
Published: November 2014

AbstractAs a professional activity, and as an intellectual activity, systems engineering (SE) has strong links to such associated disciplines as decision analysis, operation research, project management, quality management, and systems design. When focussing on systems engineering research, we should distinguish between subjects that are of SE essence and others that more closely correspond to those that are more relevant for related disciplines. In this paper, we propose selected research topics that are believed central to progress and growth in the application of SE.
8.3.3 Unique Identification Yields Total Asset Visibility from Lust to Dust – P236
Authors: Leibrandt Rob 
Published: November 2014

AbstractThis paper is based on application of an approach to globally unique item identification that fully integrated into the design, development, manufacture, use and disposal of a system will revolutionize the business processes of the United States Department of Defense (DoD). As this approach becomes embedded in the Department's business practices and “flowed down” to Prime Contractors and Suppliers it will revolutionize item marking and use much like the Universal Product Code (UPC) did for consumer goods. Ultimately Unique Identification (UID) and a commercial equivalent, the Electronic Product Code (EPC), will transform serialization and item management globally.In this paper I will explain what drove the development of the need and the approach that has resulted. Practical examples of implementation will be provided and a “business case” will be supported. In the end, I expect to convince the reader that this mandatory DoD policy should be embraced not only in the DoD, but supported throughout the United States Government and international communities.
9.3.3 The value of UML Use‐case modeling in Product Life‐Cycle context
Authors: Broeze Henk , Samplson Mark , Lagarde Remco , Davis Pete 
Published: November 2014

AbstractThe importance of Requirements Engineering in a Systems/Product Life Cycle context does not get the attention it deserves. Requirements definition practices mainly concentrate on defining functionality and selecting conditions for systems so that the system is sold successfully.Use‐case modeling, which is part of the Unified Modeling Language, is getting a lot attention these days. It defines scenarios of system usage to reach a specified goal. Unified Modeling Language is widely used in software development projects but the Use‐case modeling is only applied to requirements discovery.This paper describes the increased value of Use‐cases when using them in a wider scope, in the context of a Systems/Product Life Cycle. The paper starts with an introduction on Requirements management and Use‐case modeling, followed by some facts on the value of combining Use‐case modeling and Requirements managemen. Finally statements are made on the value of Requirements management and Use‐case modeling in Product Life‐Cycle context.
9.5.3 Teaching Continuous Risk Management Using A Requirements Management Tool
Authors: Helm James C. 
Published: November 2014

AbstractThis paper presents a technique to teach the continuous risk management (CRM) paradigm using a requirement management tool. The paper explains the CRM process and shows how to implement the risk information using a requirement management tool. Teaching students the continuous risk management implementation is important to show them how the tool will: assist the project management and team members to establish and use consistent documentation; instantiate and store each identified risk; associate for each risk a mitigation or task plan; and visually presents each risk with the capability to be tracked, watched or mitigated throughout the project's iterative life cycle. The IBM Rational Suite Enterprise RequisitePro tool used to show the students how to capture and store the organizational and management system risk knowledge into a database. The students gain hands on risk management knowledge that can be used for product, process and project improvement. They learn how to write risk statements, collect risk metrics, and capture the risk lessons learned for future projects.