bluuebunny/crossref_metadata_2025_split huggingface dataset:
8.4.3 What Question are You Trying to Answer? Identifying the Right Products for an Architecture Effort
Authors: Russell Michael S. 
Published: November 2014

AbstractDetermining what architecture products are needed to support systems development within a Systems Engineering process is a challenge. Existing documents, such as DoD's Architecture Framework Document, provide some guidance, but no defined product identification process. The method proposed in this paper provides a repeatable process for selecting the architecture products required to support a systems engineering lifecycle, defining the content of each product, and identifying each product's customer. The method has been successfully used by several DoD programs over the past five years.
9.4.1 The Axes Guiding Development of a Capability Engineering Process
Authors: Bernier F. , Mokhtari M. , Couture M. , Lizotte M. , Lemieux F. , Lam S. , Lalancette C. , Dussault G. 
Published: November 2014

AbstractSignificant changes in the nature of military systems and the military environment require improvements of the current military systems acquisition process. The Capability Engineering Process (CEP), to be delivered through the CapDEM project, aims at improving military capabilities acquisition in the Department of National Defence and the Canadian Forces (DND/CF). However, opportunities to improve capability acquisition are too numerous to implement all of them within the CEP. This paper presents a structured approach to better orient the development of a CEP.
9.4.3 Seamless Engineering Process to Enhance Systems Engineering Effectiveness
Authors: Shepard Lynn , Bean Susan , Hough Andy , Jolly James 
Published: November 2014

AbstractIn order to effectively execute large and complex programs, an engineering process must be established that eliminates multi‐disciplinary barriers. This process needs to be focused on the entire product development cycle and work to keep engineering disciplines from executing independently. This paper will describe the integration of the systems, hardware, and software engineering approach, the utilization of event driven, use case‐based, object oriented design practices, and the use of an integrated tool suite to perform the requirements decomposition, traceability, architecture design, and multi‐level documentation generation. The authors will also address how this process aids unit testing, system level testing, and regression testing methodologies throughout the product development and deployment lifecycles.
10.1.1 A Systems Approach to Process Infrastructure
Authors: Armstrong James R 
Published: November 2014

AbstractThis paper looks at several aspects of process infrastructure and maturity from the viewpoint of systems thinking concepts. To start, the paper addresses the position of process infrastructure relative to ISO 15288 (ISO/IEC, 2002) enabling systems. Next, the paper looks at the impact of multiple standards on the infrastructure and the programs using it. A third view is the use of a systems approach to deal with the problem of multiple standards for how processes are implemented. The final view is how the common features implement both the science and engineering approach activities and how maturity levels address them.
10.2.1 Requirements – The Good, the Bad and the Ugly
Authors: Arnold Stuart , Martin James N 
Published: November 2014

AbstractIn our efforts to make system requirements “good,” we often end up making them “bad.” It is proposed that the real goal should be to make requirements BaD—balanced and dynamic. This paper describes why the so‐called “good” requirements are really, in the larger sense, bad for success of the system and the organization that sponsors it. The paper will explain what it means to have “balanced and dynamic” requirements. Times have changed—the systems engineering discipline needs to change its methods to keep up with the global trade situation. For this, we need better tools and techniques that support the BaD approach.
10.4.1 Measuring the Lifecycle Value of a System
Authors: Browning Tyson R. , Honour Eric C. 
Published: November 2014

AbstractThe goal of systems development is to produce enduringly valuable systems—i.e., systems that are valuable when delivered to their users and which continue to be attractive to their stakeholders over time. However, quantifying the lifecycle value (LCV) provided by a system has proven elusive. We propose an approach to quantifying a system's LCV based on the key parameters that have perceived value to the system's stakeholders. For this, we draw upon insights from the management, marketing, product development, value engineering, and systems engineering literature. By designing systems for maximum LCV, systems architects and engineers will provide dramatically increased value to their organizations. However, to provide maximum LCV, a system may need to be designed to facilitate adaptability to changing circumstances and stakeholder preferences.
12.2 Fundamental Principles of Evolutionary Project Management
Authors: Gilb Tom 
Published: November 2014

AbstractThe Evolutionary Project Management method – abbreviated Evo – is arguably the best systems engineering project management method (Larman and Basili 2003). However, it is also probably the least known and the least discussed, so the aim of this paper is to shed some light on it. Evo is particularly good at dealing with large, complex, and innovative systems – it does so by breaking down the project into a series of numerous small incremental steps. Each Evo step is both an opportunity to deliver some useful results to the stakeholders, and an opportunity to learn more about the system.
1.1.4 Joint Cognitive Systems: Considering the User and Technology as One System
Authors: McKenna Brian , Gualtieri James , Elm William 
Published: November 2014

AbstractWith the addition of advanced technologies and automation within systems, the tasks that operators are asked to complete have grown more complex. This has led to greater opportunities for malfunctions, critical incidents, and catastrophes. A major contributor to these problems is the human operator and the technology not being explicitly designed as a single Joint Cognitive System (JCS). The operator is typically only blithely considered during system design and is typically expected to adapt to inputs from the other subsystems. Thinking of the operator and the automation/technology from a holistic perspective, as a single JCS, instead of separate subsystems, allows for more effective, agile, and robust decision‐making. The operator must have a complete understanding of the automated processes and the work domain, leading to more informed decision‐making. Thinking of the entities as co‐agents, rather than two isolated components that must interface, allows for more effective problem solving and decision‐making.
4.2.2 How Planning for Success Can Lead to Catastrophic Failure
Authors: Schoening William W. 
Published: November 2014

AbstractDespite significant advances and continuing efforts to improve our processes, major programs continue to fail – not slowly and gracefully, but suddenly and catastrophically. Examination of failed programs over several decades suggests that our traditional systems engineering and program management methods are inadequate for discovering and mitigating the underlying causes because they have significant difficulty coming to grips with such huge failures. This paper identifies several symptoms related to potentially catastrophic failures during product development. Each symptom is accompanied by suggestions for remedies that can illuminate the underlying potential problems without undue impact on the program.
1.4.3 Challenges in the Development of Systems Engineering as a Profession
Authors: Dixit Indrajeet , Valerdi Ricardo 
Published: November 2014

AbstractThis paper explores a fundamental and important question: is Systems Engineering a profession? It is fundamental because of the current existential crisis in the discipline and it is important because it helps in defining our role in the context of the greater technical community. By observing systems engineering through the theoretical lens of the professionalization literature rooted in sociology, we propose five key challenges to systems engineering as a profession. Firstly, defining the problem space, secondly, understanding the state of the body of knowledge, thirdly, the impact of lifecycle perspective, fourthly, the falsification of systems engineering theories and lastly, the question of standard of proof for systems engineering. The need for our thesis is motivated by understanding the current body of knowledge and proposing a direction that will enable the profession to overcome key challenges.
2.1.1 Defining Lean Systems Engineering Processes and Procedures
Authors: Olson Timothy G. 
Published: November 2014

AbstractMany systems engineering processes and procedures are large or difficult to use. The situation becomes even worse when complexity is involved. Putting large or difficult to use process documentation on a website does not usually solve the problems. This article will describe best practices for defining lean (i.e., short and usable) processes and procedures. These best practices have been used at real organizations over the last few years to define lean processes and procedures. Measurable results include cutting organizational processes and procedures in half while making them more usable (e.g., reducing 400 pages to 200 pages), without losing any useful information. This article will also describe some success stories and describe some lessons learned.The objectives of this article are to:
Describe common problems with process documentation, including some human aspects of using process documents.
Discuss some best practices for defining short and usable processes and procedures.
Describe some success stories in real organizations.
Provide some lessons learned.
2.1.3 The US Ballistic Missile Defense System: A Case Study in Architecting Systems‐of‐Systems
Authors: Hollon Heather , Dagli Cihan 
Published: November 2014

AbstractSystems‐of‐Systems (SoS) engineering for modern complex systems is one of the most difficult challenges facing today's engineer. This paper provides a detailed case study of architecting for a major modern SoS: the US Ballistic Missile Defense System (BMDS). The BMDS is a massive SoS that encompasses several existing and new missile defense programs on a variety of platforms covering most of the world. This paper includes a review of currently defined practices for architecting SoS, a discussion of how the BMDS was architected, and then suggestions for architecting future additions to the program.
2.2.3 Combined Requirements Engineering (CRE): The quest for widening the applicability of requirements engineering practices in the emerging product‐service paradigm
Authors: Agouridas Vassilis , Kossmann Mario 
Published: November 2014

AbstractCompetitive pressures and the globalisation have led enterprises to continuously seek innovative ways to create value for their customers whilst either minimising costs or keeping these at acceptable levels. To this end, enterprises have been offering product‐service bundles to promote and support their core products. This situation has led to the emergence of so‐called product‐service paradigm; a key characteristic of which is the provision of the requisite capability through a combination of service and product characteristics. However, the majority of current requirements engineering (RE) practices are aimed at solely addressing either product or service aspects of capability. This paper highlights the quest to widen the applicability of established requirements engineering practices, used mainly for product‐oriented systems, to encompass, in a complementary manner, aspects of service‐oriented systems. To this end, the term ‘combined requirements engineering’ (CRE) is introduced. The paper presents and discusses challenges and issues derived from the need for CRE under the emerging product‐service paradigm. The paper concludes by giving directions for future research in addressing such challenges and issues.
2.3.1 Benefits and Costs of Model‐Based Fault Diagnosis for Semiconductor Manufacturing Equipment
Authors: Pietersma Jurryt , van Gemund Arjan J.C. 
Published: November 2014

AbstractModel‐Based Diagnosis (MBD) is a promising solution for the fault diagnosis of complex systems. In this paper we review the benefits and costs of MBD. Our research is performed in cooperation with ASML which is the world's leading manufacturer of lithography systems for the semiconductor industry. We analyse the current way of working and the benefits that MBD offers. We present the results of practical modeling studies and discuss the benefits, costs, and cost reduction methods. We summarize the current research results and ongoing developments. Our results show that MBD has a high potential for diagnosis in a rapidly innovating industry. The fulfilment of this potential depends on the cost of modeling and the acceptance of MBD as part of broader pursuit for model‐based systems engineering.
2.4.3 DOES INCOSE NEEDS PR?
Authors: Zonnenshain Avigdor 
Published: November 2014

AbstractThe mission of INCOSE is to foster the definition, understanding, and practice of world class systems engineering in industry, academia, and government.INCOSE's vision is to be world's premier professional society for advancing the art and practice of systems engineering.INCOSE makes this vision a reality through its members, its chapters, its partners and through the systems engineering community.Even though INCOSE has grown significantly since its formation in 1990, there are only five thousand members. The potential base individual members is more than hundred thousands.There are hundreds of organizations which practice systems engineering and are familiar with the leading role of INCOSE in promoting systems engineering. But there are thousands of organizations that are not familiar with the benefits of systems engineering and the capabilities of INCOSE.In this paper we propose to use Public Relations (PR) as one of the approaches and tools to promote the mission and the vision of INCOSE.“PR is the practice of creating, promoting or maintaining goodwill and favorable image among the public towards an institution, public body.….”.We demonstrate the planning of PR campaign for INCOSE by proposing the goals & aims of the campaign, defining the target audience, suggesting the messages & ideas to be delivered through the campaign, presenting some examples for how to deliver the messages (the medium), and discussing the timing of the individual PR activity.This proposed PR campaign is not standalone, but it is part of the professional & managerial development of INCOSE, and a part of its marketing efforts.It is proposed to form a PR committee which will plan the campaign and execute it.The proposed goals for the PR campaign are very ambitious ‐ like doubling the number of members in 10 years, doubling the number of participating in INCOSE Annual International Conference in 5 years. But we assume these goals and aims are achievable, if we launch a PR campaign with broad perspectives:
Professional campaign
Excellence campaign
Globalization campaign
Business success campaign
Public decision making campaign.Also, we describe some ingredients of PR campaign that we are launching for the INCOSE activities in Israel through the Israeli Chapter – INCOSE‐IL.We propose that INCOSE management will consider to adapt our proposed approach for the benefit of INCOSE, its members, its chapters and the whole systems engineering community.
3.3.1 Driving system development process from strategic goals to requirements specification
Authors: GHAZI Hamid EL 
Published: November 2014

AbstractIn this paper we suggest a goal‐oriented requirements engineering method to guide the discovery of strategic goals of a company, and their operationalization by goals associated with its system under development. The method also allows the discovery of system requirements and it was applied within an industrial project that aims to fabricate a medical diagnostic instrument. For this purpose, we used the MAP formalism to describe the process and various deliverables associated with the development process. We also used the concepts of i* to model the dependencies between the strategic actors of the organisational environment, and to formalize the goals related to the system. Our method makes it possible to model the strategic goals of the company and their decomposition into tactical goals and thus ensuring requirements traceability.
3.3.2 Modeling Hierarchy, Coping with the Dynamic Range from Design Details up to Business Metrics; Illustrated by a Semiconductor Case
Authors: Muller Gerrit 
Published: November 2014

AbstractA system functions as part of a broader enterprise. For the design of a system understanding is required of its purpose within the enterprise, as well as of its internal functioning. Models are a means to create and capture understanding. Many different models are needed during the design of a system, from broad enterprise models down to detailed implementation models of components or functions. In this article we show the hierarchy of models, their relations and the level of detail in these models. We use the semiconductor industry as an example.
3.3.3 Reuse and Usage for System Engineering Model Elements
Authors: Smith Darold K. 
Published: November 2014

AbstractSystems engineers are being forced to address greater complexity caused by problems that extend the boundaries of existing systems by taking the larger view of systems of systems. The task of defining the total system with consistency and integrity becomes more complex and difficult to manage. More complex systems inherently tend toward larger combinations of variability in the system elements, thereby causing an explosion in the possible combinations of system configurations. At the same time, SysML is endeavoring to extend the capabilities of system engineering modeling capabilities to include more rigorous modeling (simulation), verification traceability, and traceability of critical components of delivered products. One way to consolidate system representations is by supporting the concepts of reuse and usages of system definitions. This paper provides an initial set of things to consider when developing the processes and the supporting system engineering data repository to address these needs.
3.4.1 Promoting the Real Value of Systems Engineering using an Extended SCARIT Process Model
Authors: Saunders Steven J. 
Published: November 2014

AbstractSystems engineering is the discipline that defines and delivers complex systems to meet the needs of multiple, often conflicting stakeholders. In the past, many books and papers have been published focusing on process areas such as Requirements Engineering, Requirements Quality, Requirements Traceability, and Model Based Systems Engineering. In this paper, the author proposes that by previously focusing on the processes used in Systems Engineering, the real value adding steps of systems engineering; to understand the enterprise needs and to define the problem, has been overlooked. To help overcome this bias, an extended systems engineering process model is presented that strives to elevate the visibility and understanding of key value adding steps in the Systems Engineering process.Six phases are highlighted in the extended systems engineering process model covering the technical phases of systems engineering. These phases are Stakeholder, Concerns, Architecture, Requirements, Implementation and Test (or SCARIT). Process oriented steps are characterized in the final three steps (Requirements, Implementation and Test) and result in definition and deployment of the solution. However, the extended process model precedes these steps with Stakeholders, Concerns and Architecture and postulates these three steps are where the real value of systems engineering is generated. These initial steps focus on defining the problem by looking at the enterprise needs.
3.4.2 The ROI of Systems Engineering: Some Quantitative Results
Authors: Boehm Barry , Valerdi Ricardo , Honour Eric 
Published: November 2014

AbstractThis paper presents quantitative results on the return on investment of systems engineering (SE‐ROI) from an analysis of the 161 software projects in the COCOMO II database. The analysis shows that, after normalizing for the effects of other cost drivers, the cost difference between projects doing a minimal job of software systems engineering – as measured by the thoroughness of its architecture definition and risk resolution – and projects doing a very thorough job was 18% for small projects and 92% for very large software projects as measured in lines of code.
4.1.0 Panel 4.1.0: Requirements Engineering for Software vs. Systems in General?
Authors: Kaindl H. , Griego R. , Hause M. , Hood C. , Mannion M. 
Published: November 2014

AbstractRequirements Engineering is dealt with concurrently and largely separately by a software‐based requirements engineering community anchored in the IEEE and by the INCOSE Requirements Working Group. Apart from such organizational issues, are there fundamental technical differences between Requirements Engineering for software vs. systems in general? It seems as though even functional requirements can mean something more general for a system including mechanical parts than for software alone. Quality requirements on safety deal with humans and their relationship with some real artifacts in their environment, so they cannot be dealt with by software alone. However, reliability of underlying software will be important in this context. While the internal structure of software will not normally be specified in its requirements, structure of a more general system may well be. These are just examples of what should be discussed.With regard to intelligent enterprises, there exist defined methodologies for enterprise modeling. Much as any other complex system, an enterprise may be better understood through modeling. Once an enterprise is better understood, it may be easier to make it intelligent. Whatever technical system is to be developed in an enterprise, it needs to fit into. By connecting enterprise modeling and requirements engineering, the likelihood of such a fit is increased. For software development, such connections have been worked out and are part of defined methodologies, some of them based on object‐oriented modeling. Are they applicable to the development of general systems?The software‐based requirements engineering community and the INCOSE Requirements Working Group have been slowly getting in touch with each other recently. This panel should help to discover more common ground and to exchange ideas on the commonalities and the differences of their respective tasks and methodology.
4.4.3 Applying Measurement Principles and Adapting a Defect Predictability Model to Hardware Development
Authors: Frenz Paul J. 
Published: November 2014

AbstractSoftware and Systems engineering are developing rich histories with measures and measurement tools to aid in project management. This paper addresses adapting those Software and System Engineering concepts and tools to a hardware development project.General Dynamics Advanced Information Systems (GDAIS) Mission Systems has been assessed as CMMI Level 5 rating November 2, 2005. using the CMMI‐SE/SW/IPPD/SS, V1.1, staged model.