bluuebunny/crossref_metadata_2025 huggingface dataset:
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

This 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

Risk 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

Engineering 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.
10.3.1 The Development of Systems Engineering International Standards and Support Tools for Very Small Enterprises
Authors: Laporte Claude Y. , Ptack Ken , Fanmuy Gauthier
Published: November 2014

Industry recognizes that there are very small organizations that develop parts which contain software components. These organizations, those with up to 25 people, are very important to the world‐wide economy, and the parts they develop are often integrated into products made by larger enterprises. Failure to deliver a quality product on time and within budget threatens the competitiveness of both organizations. One way to mitigate these risks is for all the suppliers in a product chain put in place proven engineering practices. Many international standards have been developed to capture such proven engineering practices. However, these standards were not written for very small development organizations and are consequently difficult to apply in such settings. An ISO Working Group has been established to address these difficulties. The working group developed standards and technical reports, ISO/IEC 29110, which were published in 2011 for organizations developing software. In 2009 an INCOSE working group was established to evaluate the possibility of developing a standard, using the ISO/IEC 29110 standard as a baseline and the ISO/IEC 15288 as the framework, for organizations developing systems. At the 2011 INCOSE International Workshop, a group of systems engineers reviewed the ISO/IEC 29110 software standard and proposed modifications to meet their needs. One constraint was to develop a document which will allow an organization developing systems with software components to be able to use the actual set of ISO/IEC 29110 standards as well as the proposed systems engineering standards. The future systems engineering standard is targeted at VSEs which do not have experience or expertise in tailoring ISO/IEC 15288. A draft document has been developed and reviewed. Recently, an ISO working group has been mandated to develop the ISO standard for very small organizations developing systems. The INCOSE Systems Engineering Handbook is used as the main reference for the development of a set of systems engineering deployment packages. A deployment package is a set of artefacts developed to facilitate the implementation of a set of practices of a standard in a very small organization.
10.4.1 The Dynamics of Water, Energy, Waste and Environment (WEWE) Systems
Authors: CHIA Eng Seng , CHEN Qiaoyi
Published: November 2014

The application of system engineering to a single system is well established and much research is currently been done to study the systems engineering of ‘system of systems‘. However, many systems are not tightly coupled together although their relationships can be complex and changes over time. In such systems, the need for system integration is less, but there is a need to study their interactions especially the effects they have on one another. This paper is focused on the water, energy, waste and environment systems (WEWE) of Singapore. A system dynamics model of WEWE centered on the water system is created to study the tradeoffs between the systems and to evaluate the effectiveness and impact of water policies on the WEWE systems. This paper further discusses whether Singapore will be able to respond to its growing population, their rising demand for water and energy and their increasing waste level, without damaging the environment and makes recommendation on sustainable development policies based on the findings.
11.3.2 “Rework: models and metrics”: An Experience Report at Thales Airborne Systems
Authors: TONNELLIER Edmond , TERRIEN Olivier
Published: November 2014

This experience report illustrates the implementation of metrics about rework in Systems Engineering at Thales Airborne Systems. It explains how models and quantification of rework contribute to reduce this waste in development processes.

This paper is based upon our real experiences. Therefore, it could be considered as an industrial contribution to share this method in Systems / Products Development and Engineering.

This experience report describes an achieved example of metrics and its positive impacts on Defense & Aeronautics Systems. However, this document proposes a scientific way to implement our results in other companies. Clues are also given to apply this methodology through a Lean Engineering approach.

Finally, Lean Enablers, key factors of success and upcoming steps are described to further improve the performance of Systems Engineering.
11.5.3 Cost‐Benefit Analysis of SysML Modelling for the Atomic Clock Ensemble in Space (ACES) Simulator
Authors: Maurandy Julien , Helm Achim , Gill Eberhard , Stalford Roland
Published: November 2014

Systems Engineering has successfully supported the space industry since its inception with methodologies and techniques to handle complex projects. However, the conventional design approach, ‘Document‐Based Systems Engineering’ (DBSE), is more and more reaching its limits. This research evaluates the benefits and the cost associated with the paradigm of ‘Model Based Systems Engineering’ (MBSE) instead of DBSE by applying the Systems Modelling Language (SysML) in the frame of the Atomic Clock Ensemble in Space (ACES) project. ACES is indeed deemed to be a suitable project for this study as it includes both a very complex ground segment as well as a challenging space segment on board the International Space Station.

Following an introduction to SysML and the ACES mission, we first develop the metrics on which the cost‐benefit analysis is based on. Then, we explain the methodology and models used to perform the analysis which targets to characterise DBSE versus MBSE based on the ACES ground segment development. Then, we use the Analytical Hierarchical Process to determine weighted criteria where attention is also given to the transitional process between DBSE and MBSE.

After a critical reflection upon the analysis methodology and its results, we focus on lessons‐learned from the use of SysML for the implementation of MBSE in space projects. We have identified five key areas of lessons‐learned for using MBSE with SysML itself as well as main deficiencies for Enterprise Architect, the tool used to implement SysML. We conclude with seven suggested improvements which are considered valuable to help improving the performance and acceptance of MBSE for the development of (space) projects in the future.
Architecting Diesel Engine Control System using A3 Architecture Overview
Authors: Wiulsrød Bjørnar , Muller Gerrit , Pennotti Mike
Published: November 2014

The Digital Governor System from Kongsberg Maritime (KM), has had an evolution period of 25 years. Technology has changed during this period and many new features have been incorporated. Consequently the product has increased in complexity over these years and the architecture was not explicit available. We decided to do reverse architecting to be able to decide what changes are needed to the architecture to support the next generation(s) of the product. This project was an opportunity to use the reverse architecting tool described in the System Engineering tool; “A3 Architecture Overviews”. Reverse architecting aimed to recover knowledge that remained in the expert's minds, in order to understand the system and its context. By doing so we were able to visually see where appropriate changes could be made. We learned that “A3 Architecting Overview” is more usable than traditional document, and easier to use as it only required a single sheet of paper.

The “A3 architecture overview” is a single page overview of the system relating several System Modeling views: a functional model, some visual aids, a physical block diagram and a quantitative section. This was important because it supported communication and gave focus during discussions.
The Architecture of the Systems Engineering Experience Accelerator
Authors: Wade Jon P. , Kamberov George , Bodner Douglas A. , Squires Alice F.
Published: November 2014

Systems engineering educators are struggling to meet the workforce development demand for senior systems engineers. The workforce challenge is to shorten the time it takes for a systems engineer to reach the senior level. The Systems Engineering Experience Accelerator research project was conceived as a critical response to these needs and challenges. The purpose of this paper is to provide a description of the Experience Accelerator architecture which will provide the foundation for post prototype development. While the prototype is only intended as a research vehicle for conceptual design and evaluation, this architectural description should address the foreseen issues for a deployable future version of the system.
Characteristic‐based risk assessment and its relation with event‐based risk assessment
Authors: Mathot Thijs , Hamann Rob , Gill Eberhard
Published: November 2014

Common risk management practice is based on events. Event‐based risk management consists of identifying and mitigating the most significant events that could possibly occur during a project and will have a negative impact on the key performance parameters, development schedule and cost of the product if they occur. The shortcomings of this approach are that this list of risk events is never complete, and is only partially available for the early important design decisions. The proposed solution is to complement event‐based risk management with a so‐called characteristic‐based method. This second method estimates the total risk of the project based on project and product characteristics. The advantages of the two separate methods not only complement each other, but it will also be shown that they enhance each other.
Complex Systems Advanced Modelling
Authors: Ciambra Francesco , Nardini Manuela , Protano Adriano , Tocci Andrea
Published: November 2014

Integrated Systems Functional Modelling (ISFM) is a Model Driven system design method, suitable for the complete representation of the dynamic behavior of complex systems, as required by modern Naval Combat Systems (C/S).

ISFM captures the whole system behaviour in a single object‐based DataBase, coded in SysML language, integrating the functional Models of each Combat System component (Sensors, Weapons, C4I capabilities), including the complete model of Combat Management System (CMS). ISFM supports the project Team during the whole project life‐cycle from the System Design to the SW definition and development, and the integration team as benchmark during integration and verification phases. The System Functional Design Test and Validation is included in the project life‐cycle at the System Design stage itself, where the early feedback gives an additional benefit to the quality of the product.
Cybernetics and SysML: First Steps
Authors: Raher Abraham , Pangaro Paul
Published: November 2014

Systems Engineering focuses on the design of a system, and Cybernetics focuses on understanding communication and control in designed and natural systems. In Systems Engineering, views of a system are typically represented in SysML in terms of Requirements, Structure, Behavior, and Parametrics. By supporting the analysis of constraints on subsystem properties, parametrics capture whether or not a system design “works”. Cybernetics measures the difference between current state and desired goal by accounting for information returning the system – “feedback” – and for the system's corrective action as it steers towards its goal. This paper shows how (1) cybernetic concepts can help focus a SysML modeling effort on critical questions, and (2) cybernetic characteristics of systems can be modeled in SysML.
Efficiency Management in Spaceflight Systems
Authors: Murphy Karen
Published: November 2014

Efficiency in spaceflight is often approached as “faster, better, cheaper – pick two”. The high levels of performance and reliability required for each mission suggest that planners can only control for two of the three. True efficiency comes by optimizing a system across all three parameters. The functional processes of spaceflight become technical requirements on three operational groups during mission planning: payload, vehicle, and launch operations. Given the interrelationships among the functions performed by the operational groups, optimizing function resources from one operational group to the others affects the efficiency of those groups and therefore the mission overall. This framework creates a context in which to understand the effects of resource trades on the overall system, improving the efficiency of the operational groups and the mission as a whole. This allows insight into and optimization of the controlling factors earlier in the mission planning stage.
Managing System of Systems Requirements with a Requirements Screening Group
Authors: Barden Ronald R. , Evans David D.
Published: November 2014

Figuring out an effective and efficient way to manage not only your Requirement's Baseline, but also the development of individual requirements during a System of Systems Program's Conceptual and Developmental Life Cycle Stages can be both daunting and difficult. This is especially so when you are dealing with a complex and large System of Systems (SoS) Program with many thousands of SoS Level Requirements as well as an even larger number of System, Subsystem and Configuration Item requirements that need to be managed. This task is made even more difficult when you add in integration of the efforts of multiple requirements development teams (e.g., Integrated Product Teams (IPTs)) and numerous System/Subsystem Design Teams.

One solution for tackling this difficult activity on a recent large System of Systems Program was to establish an empowered Requirements Screening Group (RSG). This group is a Team made up of co‐chairs from the Contractor, Customer, and User Stakeholders that are empowered by and accountable to the Program Manager for Requirements Development on the Program. The RSG co‐chairs, with the support of the System of System Requirements Team monitor, make decisions on, and provide guidance on all Requirements Development activities during the Conceptual and Development Life Cycle Stages of the Program. In addition, the RSG establishes and maintains the Requirements Baseline, monitors and enforces requirements traceability across the entire Program, and works with other elements of the Program to ensure integration and coordination.
Requirements Management Applied During a Campaign
Authors: Stephan Volker , Beasley Richard
Published: November 2014

The earlier in a programme that requirements management is applied and the higher in the document hierarchy, the bigger is the lever to achieve the potential benefits. The question is when is the right time to start ‘proper’ requirements management? The answer to this question depends on a lot of factors like size of project, number of people involved and time scales.

This paper explains how the requirements are managed for a Request for Proposal (RFP), i.e. when a potential customer has sent a suite of requirements documents together with the rules how to respond with a proposal.

A database is essential for the chosen process, since it allows parallel work on consistent data for all parties involved with a minimum of effort for the expert teams, rather than through documents. This does rely on committing to the effort of setting up and administrating the database properly.
Software Patterns for Traceability of Requirements to Finite State Machine Behavior: Application to Rail Transit Systems Design and Management
Authors: Delgoshaei Parastoo , Austin Mark
Published: November 2014

This paper describes a software design pattern (e.g., hierarchical graphs of modelview‐controllers) and models of visualization for ontology‐enabled traceability, where requirements are traced to elements of finite‐state machine behavior (e.g., actions, states, transitions and guard conditions). These ontology‐enabled traceability mechanisms will play an important role in the team‐based development of network‐enabled platforms for analysis, design, and early validation and verification of information‐age engineering systems. The application of these concepts is illustrated through the study of a simplified rail transit system.
Systems Engineering for the Design of a Smart Energy Box
Authors: Hickey Jon , Kashyap Pankaj , Moreno Jorge , Ranganath Naveen , Thomas Alex
Published: November 2014

This paper illustrates that the inclusion of system‐level safety analysis, in this case Systems Theoretic Accident Model and Processes (STAMP)‐based Process Analysis (STPA), in conjunction with systems engineering tools, such as Axiomatic Design, in the conceptual design phase of complex socio‐technical systems is critical to capturing key functional and non‐functional requirements early in the development lifecycle. In particular, capturing safety‐related non‐functional requirements during the conceptual design phase can help avoid operational scenarios that result in conditions hazardous to life and property. In addition, such an approach prevents costly “add‐ons” later in the design and implementation phases of the system life cycle. We illustrate this through the design of a “smart box” that enables large‐scale integration of distributed Renewable Energy Systems (RES) into the electrical power grid to more effectively and efficiently manage overall power demands across the grid. In the conceptual design of this system we arrive at a first set of functional requirements using stakeholder interviews and the Axiomatic Design approach. We then present a detailed discussion of the STPA tool and its application to our “smart box” concept, to arrive at unique safety‐related requirements identified through application of the STPA.
Topic‐based approach for contract‐based requirements development
Authors: Degen Helmut , Kaeppel Jochen G. , Laventhiran Sue
Published: November 2014

Many large‐scale industrial projects have a signed contract with many thousand contract clauses which are the input for requirements work. The structure and content of many contracts do not meet IEEE Std 830 quality criteria. The content in the contract is often incomplete, redundant, contradictory and/or ambiguous. The effort to develop requirements from the contract can take several person years effort. It is not trivial to manage such an effort effectively and efficiently. This paper describes a topic based approach for planning and monitoring requirements work for a contract based project. The topic based approach was applied to a large scale industrial system with more than 16,000 contract clauses. However, the approach can also be applied to projects with a smaller number of contract clauses. The paper describes the challenges, the topic based approach itself and lessons learned.
Integrating Reasoning with SysML
Authors: Graves Henson
Published: November 2014

Most engineering tasks require in‐depth reasoning. For some tasks, automated reasoning is feasible and can provide high leverage for solving difficult practical problems. Engineering questions can be represented as questions about a model, provided the model contains sufficient domain knowledge. The widely used UML family languages have been embedded within logics. By embedding a model as an axiom set within a suitable logic, engineering questions translate into questions about axiom sets. Automated reasoning can potentially be used to answer these questions. Examples of engineering questions that can be represented as logic questions include verification of a system capability (or a requirement satisfaction) and verification of whether a design change invalidates design constraints. By using this embedding engineers can use languages and tools that they are familiar with, have their models transparently translated into logic, automated inference applied, and the results be returned to their development environment. The logic embedding results of SysML, one of the UML family, is used to illustrate how engineering problems translate into logic problems and how the logic solutions translate back to engineering solutions. An engineering use case for air system capability analysis is used to show how a SysML model can be translated into an axiom set and the engineering question translates into a logic question and illustrates how formal reasoning about an axiom set can be used to answer the engineering question.
2.5.1 Functional Architecture as the Core of Model‐Based Systems Engineering
Authors: Carson Ronald S. , Sheeley Barbara J.
Published: November 2014

The application of functional architecture from a model‐based systems engineering process is examined throughout the product lifecycle. It is shown that focusing on the functionality of the system, in concert with the relationships to other elements of an integrated architecture, is a rich source of information for analyzing, developing, integrating, verifying, operating, and supporting a system. Lessons learned and examples from various product domains are provided.
3.1.2 Design Catalogues: An Efficient Search Approach for Improved Flexibility in Engineering Systems Design
Authors: Cardin Michel‐Alexandre , de Neufville Richard
Published: November 2014

This paper proposes and demonstrates design catalogues as a computationally efficient method for identifying improved designs for complex technological systems. This new process significantly speeds up the analysis of systems that will operate and will be managed under various uncertainty scenarios. It enables analysts to explore the design space more fully, taking into account a greater number of design parameters and variables. It can lead to design solutions with greatly improved lifecycle performance. The design catalogue consists of a small subset of designs that collectively perform reasonably well over a range of possible scenarios. The catalogue approach contrasts with the usual approach that optimizes designs for each scenario, and thus can only afford to examine a limited number of situations. Each design in the catalogue consists of combinations of design variables, parameters, and flexibility decision rules. The set of designs in the catalogue is determined using adaptive One‐Factor‐At‐a‐Time (aOFAT) analysis. An example demonstrates the use and how it leads to improved lifecycle performance compared to a standard benchmark design.
10.3.1 The Engaporean Air‐Defence Upgrade: A Framework for a Case Study development project
Authors: Kasser Joseph
Published: November 2014

Case studies have been shown to be a very effective way of learning, however the few case studies available in the systems engineering literature document the ‘what’ of the situation and fail to provide the ‘why’ the insight into the reason for the decisions. This lack of the ‘why’ is an undesirable situation because students will potentially be in similar situations in their futures and need to understand the reasons behind the decisions so they can make their own informed decisions. This paper addresses that gap and instead of providing yet another case study, it provides a framework or architecture for a case in which students can perform the activities and develop an understanding of not only the ‘what's but the ‘why's as well providing a broad overview with plenty of scope for discussion and exercises in each phase of the system development lifecycle (SDLC). The bulk of this paper sets out the timeline for, and provides a high level description of, the Air‐Defence system upgrade process in the fictitious nation of Engaporia. The last section of the paper points out some of the extension opportunities currently planned as well as proving a number of discussion points and exercises.
9.2.1 Developing Product Lines in Engine Control Systems: Systems Engineering Challenges
Authors: Atherton Malvern J. , Collins Shawn T.
Published: November 2014

Rolls‐Royce is developing a Full Authority Digital Electronic Control (FADEC) product line for helicopter and light turboprop applications. This is driven by market demand to reduce the proportional cost of control systems relative to the engine, and to field applications in timescales that preclude traditional clone‐and‐own approaches. The goal is to develop reusable control system architectures, requirements, and verification evidence, which can be used on a variety of applications. Key challenges include addressing military and commercial constraints with the same architecture, designing in flexibility for future applications, and leveraging global company capability in processes, tools, and supply chain strategy. This paper describes Rolls‐Royce's experience adapting existing software product line principles to apply at the control system (hardware and embedded software) level in light of certification guidelines from DO‐178B and ARP4574A. Lessons learned from moving through the “V” life cycle provide insight into how Systems Engineering adds value in this context.
8.2.1 Integrating System Models around Decisions
Authors: Mendonza Pradeep , Fitch John
Published: November 2014

Decisions are the primary future‐creating human thinking process. Every system or product in existence today is the direct result of a network of interdependent decisions that have been framed, analyzed, made and implemented. As such, a decision model is ideally suited to serve as the integrative framework for Systems Engineering knowledge, processes and practitioners.

The U.S. Army Tank Automotive Research Development and Engineering Command (TARDEC) has developed an Advanced Systems Engineering Capability (ASEC) framework that leverages a decision model as the integrative mechanism to provide the context for all other system models. These models, known collectively as the “5‐M Model” of integrated systems knowledge, include:

SE Process (Vee) model

Math/Physics models

Lifecycle models

Architecture models (e.g. SysML)

Roadmap models

This paper will describe the relationships between these models as implemented within the ASEC framework. The role of each model in informing decisions to improve decision confidence, speed, quality, leverage and implementation will be explained. A metrics strategy to confirm these benefits will be proposed.
6.1.1 A Framework for Harmonizing Systems Engineering and Off‐The‐Shelf Procurement Processes
Authors: Saunders Steven J.
Published: November 2014

Systems engineering, as a discipline, has been utilized since the middle of the twentieth century to successfully execute numerous complex system developments. Many of the practices and standards utilized are perceived as being biased towards new development systems. With the changing imperative to deliver “to market” quicker and cheaper, many programs are placing a higher reliance on the use of Off‐The‐Shelf (OTS) components in the final system solution. Integrating this strategy into traditional systems engineering practices has led to challenges in the past.

This paper describes a framework successfully utilized on the Royal Australian Navy (RAN) Air Warfare Destroyer (AWD) Program to integrate an OTS procurement strategy into a System Architecting and System Engineering environment. The framework highlights the benefits of integrating the stakeholder, System Architect, Systems Engineering and Program Management communities to form a “collaboration” to jointly work to rapidly ameliorate risk in the early phases of the program. Latent gaps between input needs and the emergent OTS capabilities are concurrently analyzed and the Technical Integrity Risk successively estimated. System architecting methodologies are employed to help hide unnecessary detail in the early concept definition phase to help support rapid alternate “trial” architectures to be effectively analyzed from a total risk point of view. The use of this risk based strategy from early program inception provides the mechanism to manage and minimize risk and in addition, predict the confidence in program success.
3.3.1 An Improved Taxonomy for Major Needs and Requirements Artifacts
Authors: Ryan Michael J.
Published: November 2014

Each of the major systems engineering standards and guides has a different focus, uses slightly different terms for the various needs and requirements artifacts, and reflects a different emphasis on each of the activities from the enterprise level down to the system level. While there is a lack of consistency among documents with the use of terms and artifacts (and all are internally inconsistent to some degree), the differences are not significant and mostly reflect the different emphases on particular levels or specific parts of the overall process. None‐the‐less, the disparate views result in considerable obscuration of the underlying process which can only be resolved after considerable study and deliberation. Worse, the lack of a common taxonomy in the early part of system/requirements engineering process adds confusion at a very critical time in the definition of the system of interest. This paper reviews the early processes and the needs and requirements artifacts described in the major systems engineering standards and guides. An improved (synthesized) taxonomy is proposed that clarifies the language used to describe the major processes and artifacts in the early portion of the system life cycle.
10.4.2 On an Appropriate Set of Characteristics for the Structure of Upper‐level Standards When Used to Establish Business Environments
Authors: Jones Bronwyn L. , Ryan Michael J.
Published: November 2014

The establishment of business environments has been greatly enhanced through the development of upper‐level standards that provide ‘strategic tools and guidelines…They ensure that business operations are as efficient as possible, increase productivity and help companies access new markets‘. (ISO 2012). Once a suitable upper‐level standard is adopted by an organisation, its processes, activities, and tasks must be mapped (or allocated) into the organisation's life cycle stages, procedures, and roles so that subsequent planning can occur, resources can be allocated, and work conducted. Organisations may also wish to claim (or will often be obliged to show) conformance to a particular standard. In many cases, however, this mapping is only able to be demonstrated in general terms, so that upper‐level standards are not always used as comprehensively as they are intended. In order to facilitate the establishment of business environments, this paper addresses what is required for an upper‐level standard to be mappable and then proposes characteristics for the structure of such standards that would enable them to be more readily mappable into a business environment. The Stakeholder Requirements Definition process of ISO/IEC 15288 is used as an example to illustrate how structuring a standard against such characteristics might improve the ability to establish business environments.
9.5.2 New Opportunities for Architecture Measurement
Authors: Carson Ronald S. , Kohl Paul V.
Published: November 2014

Recent industry progress in architecture definition, architecting tools, model‐based systems engineering, and customer policy has created both a nexus of demand and opportunities to advance the state of architecture measurement. In this paper we describe recent industry working group results and propose architecture measures intended to meet the needs of systems engineers and their program managers as leading indicators of system development health. The measures are documented using the PSM (Practical Software and Systems Measurement) methodology. General techniques are proposed that take advantage of the opportunities afforded by the current architecture modeling environment to provide a basic measurement plan for architecture, including leveraging existing measurement concepts found within the Systems Engineering Leading Indicators. The result is a comprehensive and tailorable suite of measures that can provide decision‐making data to program managers and technical program leaders.
10.1.1 Managing the Project Team as a Special Class of Stakeholder for Enterprise Transformation Projects
Authors: Hahn Heidi Ann
Published: November 2014

The Los Alamos National Laboratory's (LANL's) Enterprise Project – the implementation of a commercial off‐the‐shelf (COTS) enterprise resource planning (ERP) system to replace the home‐grown business computing systems in use since the early 1980's – provides a provocative case study regarding the management of project teams in which team members are, themselves, stakeholders. This paper describes the project's approach to stakeholder management for the project team, which had mixed success, discusses the theoretical underpinnings of the approaches used, and provides lessons learned for handling project team members as a special class of stakeholders who have special needs. Specifically, it is noted that project team members may be either system advocates or system critics or adversaries. It is recommended that transition management tactics be developed in anticipation of both types of stakeholders being present on the project team.
Product Owner Agile Systems Engineering Strategies
Authors: Palmer Kent
Published: November 2014

In the Scrum Agile approach there is an important role defined for the Product Owner who is the proxy for the Customer and who is supposed to be engaged in laying out the work to be performed by the team by prioritizing the product Backlog. It turns out that this is a neglected role in the literature with only a few books dedicated just to this role, the most interesting of which is by Pichler1, while there are many books dedicated to the Scrum Master role. Of course the role is mentioned in many other of the basic books on Scrum, but we would expect more explicit refinement of the role based on the fact it is essential in driving the process. Also in larger organizations this role becomes conflated with that of the Product Manager, and Leffingwell suggests that the Product Owner is a transformation of that role and that Product Owners probably work for the Product Manager on large projects. What is called Product Manager in commercial firms is the Systems Engineer role in aerospace. The Systems Engineer is the person responsible for the whole product working as advertised when delivered to the customer. The techniques that the Product Owner should draw from are those developed in Systems Engineering as a discipline. However, we need to make those techniques of Systems Engineering more agile in keeping with its spirit of increased efficiency and effectiveness in product development. Here we will apply what we learned about the essential structure of the product and its lifecycle in terms of traceability in the paper “The Essential Nature of Product Traceability and its relation to Agile Approaches” in order to explore the nature of this role, along with the idea of Pichler not mentioned in his book but developed later about multidimensional backlogs.
6.4.2 System Verification by Automatic Testing
Authors: Øvergaard Asgeir , Muller Gerrit
Published: November 2014

This study elaborates the application of automated testing on an integrated software intensive system. We have been able to research the topic using a Kongsberg Maritime (KM) system, K‐Master, as data provider. We have integrated an automated test framework into the test environment. The test team can use this framework to perform testing automatically.

The test team can use the effort released by automation to increase the amount of tests run. The test team can also choose to spend the released effort on other impending test activities. If we increase the amount of tests run, it can result in uncovering a higher number of problems in an earlier phase of the project.

This study shows that spending resources on automatic testing, resources, and save cost throughout the development project, while increasing coverage and frequency of testing. The result of this study will help justifying such decision.
Enterprise Scheduling for Large‐Scale Integrators (LSIs)
Authors: Sobolewski Chris
Published: November 2014

Large scale integrators (LSIs) are concerned with the assembly of multiple systems into a “system of systems.” Architecting an Enterprise schedule solution that supports LSI systems engineers requires examining tool commonality with the individual systems, total solution cost, schedule visualization, and cross‐schedule integration techniques. Examined are concepts for Enterprise schedule management unique to this level for configuration management, adherence to systems engineering control gate policy, and data trending.
6.5.2 Modeling and Analysis Framework for Risk‐Informed Decision Making for FAA NextGen
Authors: Blackburn Mark R. , Pyster Art , Zigh Teresa , Turner Richard , Dillon‐Merrill Robin
Published: November 2014

This paper discusses an analysis and modeling framework that is being developed to support risk‐informed decision‐making for the Federal Aviation Administration Next Generation Air Transportation System (NextGen). Discussions with over 60 stakeholders identified challenges for those responsible for planning, developing, and deploying NextGen capabilities. There are a confluence of technical and non‐technical factors that are important to effectively roll out capabilities. People's internal knowledge is much greater than what is captured externally or formally. Additionally, this knowledge and the causal relationships to program factors are not formalized in a way to support this complex decision‐making process. The paper describes a Bayesian network‐based analysis and modeling framework with usage scenarios for calculating cost, schedule and benefit risks to support collaborative decision‐making throughout the phases of the FAA's acquisition lifecycle process.
4.2.3 Aircraft Agile Integration‐Design for Quick Reaction Capability Programs
Authors: Anderson Steven , Dove Rick
Published: November 2014

Military Quick Reaction Capability (QRC) programs are becoming more typical; with miracles expected. Higher performance and quality are demanded in less time with reduced cost. Aircraft platforms are continually modified for the latest mission system technology, which often requires a unique balance of secondary aircraft systems (structure, environmental control, and electrical). This paper investigates an agile integration‐design architecture that is capable of reducing time and cost to the customer, while increasing mission performance and quality. A successful implementation would include increased risk mitigation for the program, as well as flexibility for future system evolution or even mission repurposing. With commercial aircraft as the platform for QRC mission systems integration, this paper shows how to create mission system modifications on a much shorter time scale then currently possible, by identifying and exploiting aircraft features that exist across multiple platforms, or exist in reoccurring patterns on the same platform.
6.3.1 COSYSMO Calibration Steps and Results
Authors: Valerdi Ricardo , Christopherson Timothy L.
Published: November 2014

This paper provides insight into calibrating a systems engineering cost model (COSYSMO) by providing a process that organizations can follow to improve their estimation accuracy. A specific example is provided from Raytheon Missile Systems to illustrate how data are collected and how they influence the cost estimating relationship. The results from this specific case are generalized to other organizations who wish to improve their cost estimation capabilities in systems engineering.
Behavioral Economics and the Design of Systems Engineering Measures
Authors: Brown Barclay
Published: November 2014

The design of measures is an art and a science. Taking a systems thinking perspective in designing a measure requires considering how the measure will be used, what it means, what kind of behavior it will produce, and the results of that behavior. Treating the implementation of a measure as a move in a game can give new insights into what will happen when the measure is introduced. Measures may be ignored if it is not clear what they mean, or if there are no standards or goals for the measure. Measures that are published, evaluated and used to determine performance levels of people and groups, and which have standards, norms and goals, in turn affect behavior and are subject to gaming. It is these measures which must be analyzed for unintended, or worse yet, adverse consequences. Short of finding perfect measures, the practice of balancing measures can be used to mitigate such consequences.

In theory there is no difference between theory and practice. In practice there is. (Yogi Berra)

In pursuing a comprehensive approach to the measurement of systems engineering and systems development work, we must face difficulties in both theory and practice. The central questions we must answer are,

What should we measure?

How should we measure it?

What does it mean?

How will measuring this affect behavior?

Most work in the area of measures focuses on the first two questions. The field of data analytics and interpretation focuses on the third, and the field of behavioral economics is interested in the fourth. This paper will present some key ideas about how measures can be designed and conducted, applying some insights from these diverse fields.

Part I will focus on current practice, as assessed in a series of informal interviews conducted by the author in 2011–2012 with several active, senior practitioners in systems engineering measurement, mostly in the aerospace and defense industry. The goal was to understand how systems engineering is measured in current practice and how those measures are used. Part II looks at the question of how measures are designed, their component parts and how meaning for measures can be determined. In Part III the focus is on unintended consequences of applying measures—the behavioral economics perspective. Some guidelines will be suggested for the successful design of measures that avoid or minimize unintended consequences. This paper aims at suggesting a new way of thinking about and designing measures and does not claim to present an explicit solution to any or all measurements needs. In fact, it is likely that the topic of measurement will appear more problematic after understanding what follows, than before.
11.4.1 SE approach to ubiquitous maintenance system design: Requirements development methodology
Authors: Jeong Suho , pil Kim Jun , Cha Jae‐Min , Suh Suk‐Hwan , Lee Joong‐Yoon
Published: November 2014

U‐maintenance system means a supporting system for maintenance of production facility via ubiquitous technology, such as RFID (Radio Frequency Identification, USN (Ubiquitous Sensor Network), RTLS (Real Time Locating System), etc. Compared with conventional maintenance system including e‐maintenance system, u‐Maintenance system has high potentials in many respects. However, from the system design perspective, u‐maintenance system is a complex system where many aspects should be taken into consideration. We approach the problem by systems engineering. In this paper, we focused on a requirement development methodology. The usefulness of the proposed methodology was illustrated by a u‐maintenance system for industrial steel‐plant.
3.3.2 Bridging the Gap Between Human Thinking and Machine Processing in Developing and Maintaining Domain Knowledge
Authors: Zayed Rami , Kossmann Mario , Odeh Mohammed
Published: November 2014

This paper is concerned with the gap between human and machine thinking in the area of the development and maintenance of domain knowledge; and how the differences in the way humans and machines think or process information can be exploited for the benefit of the domains in question.

Looking in turn at mind mapping as an effective human thinking technique and ontology as a machine readable standard, the paper will discuss the role of mind mapping in the Requirements Engineering (RE) process in general; and provide some insight into the development of the OntoREM‐MindMapper (OMM) tool that will serve to support the Ontology‐driven Requirements Engineering Methodology (OntoREM) by enabling controlled transfers of domain knowledge between mind maps and ontologies.