bluuebunny/crossref_metadata_2025_split huggingface dataset:
2.4.1 A Case of Systems Engineering in Daily Life
Authors: Lee Cheol Woo 
Published: November 2014

AbstractEver since SE had been introduced in Korea in the early 1990s, many Korean SE preachers or System Engineers have tried to introduce SE to the Korean industry, Korean engineering society or Korean Government, but hardly succeeded.Then some questions arose. What is SE in a word? What does each SE process mean for us in our daily lives? If SE is so useful, it should also be easily understood even by any ordinary people.This paper shows a usual daily issue in a family about purchasing a new kitchen cooker, on which they could ‘successfully’ apply the ‘useful’ SE process. With this case, explaining SE to anybody has become easier in less than 10 minutes.The case also depicts how human factors in system design play a crucial role ie. emotional, psychological, value factors and other soft human factors, which are a new challenge for the systems engineers.
2.4.2 Systems engineering saves the day!
Authors: Haskins Cecilia , Welland Alexander 
Published: November 2014

AbstractThis paper is an experience report about how adding a systems engineer to a project helped the team achieve a second‐place result in a competition despite overwhelming technical and programmatic obstacles. The setting of the case in this report is Trondheim where the co‐author joined a student team that should design and construct a car to compete in the Shell Eco‐marathon. The project started August 2010 and ended May 2011, but the systems engineer joined the project late, and started his work in the middle of January 2011. The paper takes the reader on a journey following the steps taken to introduce and apply systems engineering techniques in a project that was time and resource constrained. The paper demonstrates the effectiveness of simple techniques, such as the “Systems Engineering Wall,” to implement systems engineering practices and improve team communications. The conclusion is that the systemic and systematic approaches of systems engineering, in this instance, helped the team achieve a winning result.
2.6.1 Graphical Representation of Situation Awareness in Joint Cognitive Systems
Authors: Hew Patrick , Byrne Lydia , O'Neill John 
Published: November 2014

AbstractWe propose a framework for modelling situation awareness (SA) in joint cognitive systems (JCS) of humans and machines. The key idea is to adopt a building block approach. The building block encapsulates the extant, mature theory of SA in an individual agent, for their individual workflows. We then articulate rules for assembling agents, for workflows that run across the JCS. Systems engineers gain an analytic tool and design patterns for improving SA in JCS, leveraging the potential of modern, digital technology.
3.4.1 Yes systems engineering, you are a discipline
Authors: Kasser Joseph , Hitchins Derek 
Published: November 2014

AbstractSystems engineering is currently characterized by conflicting and contradictory opinions on its nature. The paper begins by describing the evolution of systems engineering in the National Council on Systems Engineering (NCOSE)/ International Council on Systems Engineering (INCOSE) and the difficulty in defining and differentiating systems engineering as a discipline. The paper then identifies and discusses six different and somewhat contradictory camps or perspectives of systems engineering. After identifying the cause of the contradictions the paper suggests one way to reconcile the camps is to dissolve the problem to distinguish between the activity known as systems engineering and the role of the systems engineer with a return to the old pre‐NCOSE systems engineering paradigm. The paper then continues by testing the hypothesis and shows that systems engineering is a discipline that can be differentiated from other disciplines. However, it is not a traditional engineering discipline.
3.6.2 Next Generation Requirements Engineering
Authors: Favaro John , Mazzini Silvia , Schreiner Rudolf , de Koning Hans‐Peter , Olive Xavier 
Published: November 2014

AbstractEstablishing and managing a “good” set of requirements is one of the critical success factors for any space system project, and for the development of any complex product in general. The NextGenRE project sponsored by the European Space Agency has developed an innovative approach featuring the use of semantic wiki technology to enable users to specify structured, semantically‐rich requirements associated with canonical system designs in OMG SysML. Reuse of requirements through templates is supported, as well as semantic reasoning to check properties such as consistency and coherence among requirements. The approach is entirely model‐based, allowing tight integration of the requirements engineering and design processes and opening the way to the application of model checking and simulation techniques. The new approach is being validated alongside an existing space project.
4.4.1 Using MBSE Methodology to drive a PLM Initiative
Authors: Ciriello Daniele 
Published: November 2014

AbstractProduct lifecycle management (PLM) is recognized as one of the key leading technologies to facilitate companies to overcome global market challenges, by adopting a new way to rapidly plan, organize, manage, measure, and deliver new products or services much faster, better, and cheaper in the extended enterprise. Following these aspects, PLM initiatives have to be organized and managed to orchestrate overall complexity: although first activities related to PLM Vision & Strategy definition as well as PLM project organization and plan are strongly emphasized by literature and business excellence, PLM System Design is often underestimated with a general decrease of industrial ROI. Focusing on this aspect, this paper describes formal method for PLM Implementation based on Model Based System Engineering (MBSE) approach. Starting from an overview of domain related to System Development Lifecycle (SDLC) and System Engineering methodologies, description of a PLM Initiative is made, applying proposed approach to a PLM Project.
4.4.3 Efficiently Managing Product Baseline Configurations in the Model‐Based System Development of a Combat System Product Family
Authors: Mitchell Steven W. 
Published: November 2014

AbstractEfficient management of product configuration baselines is a challenge in the evolution of any industrial scale product family. This is particularly true with current standards‐based system modeling tools, as the standards themselves are just beginning to address this problem in a scalable fashion.In the case of the Submarine Warfare Federated Tactical Systems (SWFTS) common submarine combat system, dozens of product configurations must be managed in parallel, with many of those baselines being updated several times a year. To support this activity a new SysML modeling technique has been developed for constructing hardware and software component bills of materials. It extends the concepts of libraries with SysML catalogs to bound the complexity of the task, improving the quality and efficiency of the systems engineering process.General Terms: Systems Engineering, System Evolution
5.1.1 Verification & Validation; An inconvenient truth
Authors: Elich Erik , Schreinemakers Paul , Vullings Maarten 
Published: November 2014

AbstractThis paper addresses several inconveniences regarding the proper use of Verification and Validation. The inconvenient truth is addressed by discussing reality in projects and domains, versus the widely accepted definition of Verification & Validation, versus the way we think both projects and developments should be managed and versus the aim to achieve transparency in the relationship between principals and contractors.
5.5.1 A SysML‐based Approach for the Specification of Complex Systems
Authors: Petrinca Paolo , Gammaldi Mario , Tirone Lucio 
Published: November 2014

AbstractThis paper describes a SysML‐based approach for the definition of the different layers of requirements necessary for a full functional specification of complex systems and/or systems‐of‐systems. The approach is specifically suited to those cases in which the development of the system as a whole and that of the single system elements (or of subsets of system elements), are under the responsibility of different development teams, within the same firm or belonging to different firms.The process is based on a recursive approach, in which each layer of the development must: i) interact with its “customer”, through the acquisition and analysis of the stakeholder requirements applied to the system, ii) define the system‐level requirements as a result of a black‐box analysis of the system's behavior, and iii) perform a white‐box analysis for the definition of the system elements' requirements.
6.4.1 Systems Engineering Business Context: The Evaluation of the South African Systems Engineering Industry
Authors: Harding Charl 
Published: November 2014

AbstractSystems Engineering and Business Strategy might seem to be at different sides of the Business spectrum, but in reality Systems Engineering is a vehicle for achieving the goal set by Business Strategy and obtaining a competitive advantage. It is the author's experience in both military and commercial projects, that most Systems Engineers do not have an understanding of the business principles such as marketing and economics to be taken cognizance of during the design and development of system. The current Systems Engineering standards like the INCOSE handbook, ISO/IEC 15288‐2008 and ANSI/EIA‐632‐1998 also do not always provide any standard processes or activities that could guide Systems Engineers in looking at the business case during the Systems Engineering life cycle.The top management of the organization is responsible for defining the business strategy that defines the direction to enable the organization to satisfy the market demands and subsequently make profit to build a sustainable business. In a Systems Engineering organization, market needs are satisfied through products and services that Systems Engineers are responsible for, but the author's experience has shown that Systems Engineers do not partake in development of organizational strategy. In many cases the Systems Engineers do not even know the organizational strategy. This may cause a misalignment between the organizational strategy and the products and services delivered to customers.The importance of incorporating the business strategy into the Systems Engineering process is becoming more important in order to remain competitive in the global market. The business strategy alignment of Systems Engineering projects is even more important during the current recession of the global economy. This paper investigates the relationship between Systems Engineering, business and the business case of the project the system engineer is responsible for. The relationship between Systems Engineering and Business Strategy to enable Systems Engineering to become the competitive advantage of an organization is also investigated.
6.4.2 The 7 +/‐ 2 Uses For An Estimation Tool
Authors: Nolan Andrew J. , Pickard Andrew C. 
Published: November 2014

AbstractRolls‐Royce adopted COCOMO II in 2004 in order to improve its estimation capability. Since then COCOMO”s importance has grown within the business and has had far reaching effects well beyond its initial remit. COCOMO has been applied to software development, software supplier oversight, improvement identification, improvement validation, risk identification and even business decision making. The tool has become a common language that unites projects, engineering, business, risk and improvements. The tool was also read across into hardware Engineering. Through the adoption of COCOMO, we have seen an 11% reduction (on average) of project costs as well as greater program stability and predictability. This paper is intended to describe our journey and the next steps for Rolls‐RoyceThis paper is written in two parts. The first part describes the lessons learnt during a six sigma Black Belt to improve our estimation capability. Part two of the paper then describes the benefits we got after we had embedded the estimation capability into the business.
7.7.3 The Requirements Engineering Process Design for Six Sigma
Authors: Yurt Hakan , Brouse Peggy 
Published: November 2014

AbstractMany software projects continue to be over budget, over schedule, and fail despite the tools created for managing the life cycle and the continuous improvement efforts. A great number of the problems in systems development projects is caused by poor requirements management processes.The failure to understand the reasons behind the low quality requirements, to understand the relationship between the quality of requirements and requirements engineering process, and to take no actions for increasing the quality of requirements by eliminating the causes behind those effects result in increased cost, low reliability and maintainability, and a system that does not meet the stakeholders' requirements.The aim of this research, the Requirements Engineering Process Design for Six Sigma (REDFSS), is to improve the quality of requirements using Six Sigma methodology along with a set of metrics and tools to identify the low quality requirements and offer corrective actions to overcome the quality issues and identify and eliminate the causes for defects and help requirements engineers to make better judgments.
8.1.1 The Factors that Lead to Unidentified Risks in Software‐intensive Projects
Authors: Yuval Efrat , Kuflik Tsvi , Tahan Meir 
Published: November 2014

AbstractDevelopment and deployment programs continue to suffer from budget overruns, schedule delays and poor technical performance. In most cases, this is a result of failure in handling uncertainty in complex software system development. The development communities lack a systematic way of identifying, communicating, and resolving technical uncertainty.In this paper we focused on the risk identification stage and try to understand the reasons for unidentified risk appearing during project development. We interviewed project managers from industry. The findings suggest that the unidentified risk factors can be divided into three main types: Managerial, Behavioural and External. Each category consists of factors that through awareness and openness on the part of project teams and managers can help avert many problems and achieve project success.
8.1.2 Principles of Systems Engineering Management: Reflections from 45 years of spacecraft technology research and development at the Mullard Space Science Laboratory
Authors: Emes* M. R. , Smith A. , James A. M. , Whyndham M. W. , Leal R. , Jackson S. C. 
Published: November 2014

AbstractBased on 45 years of experience conducting research and development into spacecraft instrumentation and 13 years' experience teaching Systems Engineering in a range of industries, the Mullard Space Science Laboratory at University College London (UCL) has identified a set of guiding principles that have been invaluable in delivering successful projects in the most demanding of environments. The five principles are: ‘principles govern process’, ‘seek alternative systems perspectives’, ‘understand the enterprise context’, ‘integrate systems engineering and project management’, and ‘invest in the early stages of projects’. A common thread behind the principles is a desire to foster the ability to anticipate and respond to a changing environment with a constant focus on achieving long‐term value for the enterprise. These principles are applied in space projects and have been spun‐out to non‐space projects (primarily through UCL's Centre for Systems Engineering). They are also embedded in UCL's extensive teaching and professional training programme.
8.2.1 Enterprise Systems Engineering ‐ Practical Challenges and Emerging Solutions
Authors: Brook Peter , Riley Tom 
Published: November 2014

AbstractMuch attention has been given over the last 10–20 years to the development of mature practices for engineering complex systems, and these are now largely in place in many large organisations and companies, underpinned by professional bodies such as INCOSE and an increasing number of university departments. Moving the practice of systems engineering into wider fields remains problematic, with many false starts ‐ and even backward steps. While much has been written about Enterprise Systems Engineering – and the allied subject of Systems of Systems – making the transition from theory to practice has proved tortuous and complex, requiring attention to re‐engineering the organisation as well as the projects it undertakes. This paper draws on the authors' combined experience ‐ gained from working across a range of organisations, both inside and outside defence – and discusses emerging strategies for coping with the challenges of joined‐up projects and programmes. The paper finishes in a more speculative vein with some thoughts on how the practice of ESE might evolve.
9.1.1 Systems Engineering and Project Management Intersects and Confusion
Authors: Arnold Eileen P. 
Published: November 2014

AbstractCommonalities, differences, and confusion between the top level Systems Engineering, Systems Engineering Manager, and the Project/Program Manager views are explored based on the International Council on Systems Engineering (INCOSE) and Project Management Institute (PMI) process basis for Systems Engineering and Project Management certifications with an undercurrent of four initial factors that are observed to cause conflicts and confusion between the disciplines in the real world. The certification sources, the INCOSE Systems Engineering Handbook (SEHBK) which is aligned with ISO/IEC 15288, and the PMI Body of Knowledge (PMBoK), are the certification sources that guide Systems Engineers and Project Managers in their quest for credentials and on‐the‐job influence. These intersects are expected to work in concert, yet in real life, the interaction often results in mismatched expectations and confusion as to who has the responsibility for each process/knowledge area, in part due to mismatched certification bases. Recommendations are provided for initial alignment of the disciplines.
9.1.2 Antipatterns in Systems Engineering: An Opening Trio
Authors: Neill Colin J. 
Published: November 2014

AbstractPatterns provide a way for experts to document the lessons of their experience in such a way that novices can apply those lessons in new situations, and thus avoid costly errors. Furthermore, pattern languages provide a terse form of communicating complex situations and their solutions. While patterns are undoubtedly useful, learning what not to do in recurring situations is equally valuable, if not more so. Patterns that document the painful experience of negative consequences to familiar solutions are called antipatterns. In this paper three antipatterns relevant to systems engineering are introduced: Work‐Breakdown Architectures refers to the phenomenon of project management artifacts influencing engineering decisions; Planning with Gantt Regard explores the nuances of project management techniques when applied to complex engineering; and Dogmatic About Dysfunction explains the cultural inertia that can inhibit progress. No claim is made that these are the only antipatterns found in the application of systems engineering, rather that, as the title suggests, they might provide the inspiration and impetus for documentation and identification of a robust catalog.
9.2.2 Observations from applying SE principles on a large research project developing Processes, Methods & Tools for Modelling & Simulation of Aircraft Behaviour
Authors: Lochow Tim , Sharma Sanjiv , Laudan Timo , Coleman Peter 
Published: November 2014

AbstractThis paper describes experiences gained by applying System Engineering (SE) management practices within a particular EU research project (CRESCENDO). Additionally, we attempt to answer the underlying question: to what extent is it practical to apply SE management practices within the context of large‐scale, collaborative research projects? A common characteristic of these projects is that their structure is quite complex and requires a systematic management approach for their successful outcome. The benefits of managing industrial projects using SE management practices are well‐known. However, difficulties arise not only from the maturity of the SE processes, methods & tools available, but also from selecting the right toolsets from the plethora on offer. Therefore, significant investments are needed to develop methodologies to navigate the complexity of processes and products in the aerospace sector. In this paper, we highlight the advantages of the SE approach, but also point out some drawbacks and provide some recommendations for future adopters of SE management practices in similar project contexts.
9.3.1 A Deterministic Approach to Risk Management
Authors: Zeierman Shimon 
Published: November 2014

AbstractRisk management methodology and tools widely use risk analysis and mitigation methods based on the probabilistic approach. The following article suggests adding a new risk management tool, based on the deterministic approach, to the toolbox that serves the system engineer and project manager. It is suggested to base the risk mitigation process on the results of an analysis which identifies a deterministic source (root) for a risk and links each one of the roots identified to a unique deterministic activity aimed at mitigating that specific root. The deterministic approach further enables optimization of the work‐plan for the project, reducing need for time and budget to a minimum.The principles of the deterministic approach to risk management are presented, accompanied by a case study based on a multi‐disciplinary large scale project in which the deterministic approach was used to update project and risk mitigation plans that were, originally, designed and managed using the probabilistic approach. The project manager was thus able to improve his programmatic as well as financial achievements while being able to deliver the full product fulfilling all customer requirements.
9.7.2 “Looking Forward” Engineering Systems Integration
Authors: Tahan Meir 
Published: November 2014

AbstractEngineering systems integration involves dealing with a multiplicity of challenges. Different disciplines must be balanced, the work of several teams must be coordinated, and the issue of units that are necessary but not available on time must be handled; special test equipment must be designed, hubs and stubs must be prepared; and risks that are liable to occur during integration must be assessed and prevented – to name just a few of the tasks. All these problems and difficulties result in schedule delays and unplanned expenses. We present a structured methodology for building an integration preparation plan and thereafter guiding the actual integration. The methodology is based on the “V” model for systems engineering. The left side of the “V” represents the design stage and the right side represents the integration stage. The “looking forward” methodology follows the development steps and at each step looks forward to the relevant integration step, anticipating what may be required for successful integration. This action creates versatile integration tools that are flexible enough to absorb unexpected variations in the project.