bluuebunny/crossref_metadata_2025_split huggingface dataset:
Model‐based Engineering of Emergence in a Collaborative SoS: Exploiting SysML & Formalism
Authors: Ingram Claire , Payne Richard , Fitzgerald John , Couto Luis Diogo 
Published: October 2015

AbstractA collaborative SoS is a system composed of constituent systems (CSs), which are independent and voluntarily cooperate without an agreed SoS director. Engineering emergent behaviour is just one of the key engineering challenges for which support is needed. In this paper we illustrate for the first time an integrated collection of model‐based techniques for verifying behaviours and properties, with the aim of assisting the engineering of collaborative systems of systems (SoSs). We provide an illustration of an approach that flows from requirements and architectural modelling to the use of formal techniques, integrating methods drawn from software and systems engineering fields to tackle engineering challenges in SoS. The approach incorporates architectural modelling (implemented in SysML) before transitioning to a formal modelling notation which has been developed specifically for SoSs. This formal modelling approach supports a wide range of analysis and verification techniques, such as: design space exploration; requirements verification; and consistency checks. We also discuss how our approach can be incorporated into a standard systems engineering approach.
One Size Fits All?: A model of human growth and its application to systems thinking
Authors: Nolan Andy J. , Russell Jennifer L. , Pickard Andrew C. , Beasley Richard 
Published: October 2015

AbstractThe Graves Model was developed in the 1950's by Dr. Clare W. Graves. The model proposes a number of levels that describe how people think and behave. It describes how people change, organize, make choices, create strategies, and communicate. But, unlike other models of human behavior, the Graves Model applies not only to individuals but also to teams, projects, and even organizations.The model was introduced into Rolls‐Royce in 2006 as a tool to increase the success of improvement/change projects. The model proved to be both simple and powerful at characterizing many situations we experienced over the years. The tool is useful for Systems Engineers, change leaders, managers and business leaders.The Graves Model is a tool to help a Systems Engineer understand how to approach a problem, the team they will require, how to communicate ideas, and also understand the end‐user's likely response to a solution. The model can help diagnose problems in projects as well as anticipate likely problems in future projects. This understanding can then be used to change a project approach and the people involved.This paper summarizes the Graves Model and provides examples of how it may be used in your organization.
Objects, Relations and Clusters for System Analysis
Authors: Simpson Joseph J. , Simpson Mary J 
Published: October 2015

AbstractThe use of Abstract Relation Types (ART) in the analysis of system structure and system component clustering is the primary focus of this paper. Two basic system definitions are presented along with two, object‐clustering definitions which were obtained from a literature search. Systems structuring mathematical properties, used in systems analysis, are outlined and discussed. The ART analysis approach is applied to classical N‐Squared Charts and Design Structure Matrices (DSM), with specific emphasis on clustering methods, types and meaning. The primary structuring relationship associated with N‐Squared ART and DSM ART are evaluated and discussed. Multiple DSM ART solution approaches and techniques are referenced and discussed.
Principles for Agile Development
Authors: Marbach Phyllis , Rosser Larri , Osvalds Gundars , Lempia David 
Published: October 2015

AbstractThe Manifesto for Agile Software Development [Beck 2001] and the Principles behind the Agile Manifesto were written specifically for software development teams. Since the manifesto does not appear to apply to systems or large programs with multiple teams of development, how it applies to systems engineers is not apparent. The Principles for Agile Development are recommended for cross‐functional teams that include Systems and Software Engineers working on customer “pull” projects to produce software products. These principles provide a foundation for the working relationship across the teams. We believe these principles apply to programs that include both hardware development and software development; however, we limit our examples to software intensive development for this discussion. As we strive to produce products more affordably in this ever‐increasing, global marketplace adopting these principles will serve as a foundation for working together to develop high‐value capabilities incrementally.
A practical guide to assuring the system resilience to operational errors
Authors: Zonnenshain Avigdor , Harel Avi 
Published: October 2015

AbstractStudies about the sources of critical accidents in operating human‐made systems indicate that most of them are commonly attributed to errors made by the human operators. These findings motivated the development of a guide for designing and developing systems which are resilient to operational errors. This article reports on the development of such a guide by the Gordon Center for System Engineering at the Technion. Assuming the Human Factors variant of Murphy's Law, the guide applies the STAMP paradigm of self‐control in scenario‐based design, relying on a model of resilient operation. The guide suggests designing three firewalls, for preventing latent threats, preventing escalation and learning from incidents. The effectiveness of the guide was evaluated collaboratively in a special INCOSE_IL working group, by examination of its applicability to case studies. The guide was validated by scoring the guidelines applicability to failure modes observed in a special database of 67 mishaps.
Towards a Method to Describe Resilience to Assist System Specification
Authors: Jackson Scott , Cook Stephen C. , Ferris Timothy L.J. 
Published: October 2015

AbstractThis paper arose from the challenges inherent in defining and specifying the complicated, non‐functional system characteristic of resilience in the presence of competing definitions. The approach adopted is to specify the resilience of a system using a state‐machine. In this class of model, the state of the system is modelled by the states, the threat events that can be expected to result in altered operational states modelled by the definitions of the state transitions, and the result of the occurrence of a threat event modelled by the state to which the system would transition. The paper describes a generic model that can be tailored to form the basis for specifying a range of system types and illustrates its utility through two case studies.
Model Based Systems Engineering‐Focus on the Initial Stages; “Get it Right in the First Stage”
Authors: Walker Loren Mark 
Published: October 2015

AbstractA fundamental premise of this paper is that capturing stakeholder needs and the initial development of Systems Engineering documents and architecture models, with top level of capability needs/requirements, in a well written Operational Concept Document (OCD) during the first stages of a development, is absolutely critical for the entire life cycle of the system development. With this information in the OCD, written substantially in the stakeholder's operational terminology, and with Systems Modeling Language (SysMLTM) architecture views, this set of integrated products provide the foundation for all future stages of a development and the system's operational life. The primary emphasis of this paper is the critical importance of “System” Use Case Diagrams (SysUCD), their associated Scenarios and Sequence Diagrams and how essential it is to develop these with the operational customer in this first stage. The use of “Initial Stages” refers to the activities in the upper left of the Systems Engineering Vee diagram where it is essential to develop and understand Stakeholder Needs. This is accomplished by applying the Stakeholder Needs Analysis process using the recommended Object Oriented Systems Engineering Method (OOSEM) and translating the information into well‐defined stakeholder and systems engineering products and architecture views/models.
Implementing Model Semantics and a (MB)SE Ontology in Civil Engineering & Construction Sector
Authors: Balslev Henrik 
Published: October 2015

AbstractIn the period from 2010 – 2015, the Danish Building Construction Sector has implemented basic parts of Systems Engineering as the new ‘common language’ in the building construction sector. The project is anchored in the public and EU supported “cuneco project”. www.cuneco.dk develops the common basis for digitalized cooperation in construction, operation and maintenance to increase efficiency and productivity through enhanced exchange of information. To allow maximum simplicity yet unlimited flexibility, systems and their constituents are first classified and then identified individually to be used consistently over the lifecycle of the component, suitable for IT support. The system‐of‐systems principle is a fundamental approach to achieve unambiguous identification based on the Reference Designation System principles as defined in ISO/IEC 81346 standard series, which originally is designed for modelling and labeling of any kind of industrial plant. Currently, the Danish result is used to update some parts of the 81346 standard series, and thereby introducing Systems Engineering to the building construction sector.
Effective System Engineering Peer Reviews
Authors: Drewien Celeste A. , Artery Georgia , Eras Ken , Ballard William , Nagel John F. 
Published: October 2015

AbstractEffective and rigorous technical peer reviews provide quality to a product realization process. This paper proposes a five‐step peer review process based on survey of the literature, experience with peer reviews, and pilot trials. Feedback was collected and integrated as lessons learned, resulting in a process that addresses key attributes of a peer review: roles & responsibilities; requirements; rigor; peer identification, independence, and external engagement; and follow‐up actions. An idea for a tool is provided to assist with rigor level determination and scoping of the peer review. Use of this peer review process can yield consistent peer review practices surrounding peer review practices for product realization teams.
A Systemic Framework to facilitate large and complex IT transformational Programs
Authors: Kummamuru Supriya , Hussaini Syed W 
Published: October 2015

AbstractThis paper presents a systemic framework for addressing the distinct challenges of Program management in the Information Technology (IT) services Industry environment. It was an outcome of the work carried out internally in the organization. The study involved identifying the challenges and defining the framework using a multi modeling approach. It was found Programs were treated with the same lens as projects, thereby missing the big picture and the benefits synthesized in a Program. Programs are a collection of projects, they differ in terms of scope, size, scale & complexity with respect to people involved, requirements, interfaces, time required etc. while programs are large and deliver benefits, projects deliver outcomes. The study also reviewed the existing program management frameworks and models for addressing these challenges and found they were domain agnostic and some areas specific to IT domain were not addressed. The nature of every IT programs is distinct because it belongs to different client domains, technology changes are rapid, and requirements keep changing as a result of changes in the environmental. The study identified several challenges which were then organized under five dimensions, each having similar concerns. Solutions were defined under each of these dimensions, they included new systemic frameworks and positioning existing ones appropriately. Given the enormity of the context not all areas could be addressed, which will be taken up latter. Some of the suggested models have also been validated in client program's contexts. This paper covers the multi modeling methodology used for the study, the findings and the proposed framework for Program Management at a conceptual level, because the solutions are proprietary and are the Intellectual Property (IP) of the organization.
Techniques for Conducting Effective Concept Design and Design‐to‐Cost Trade Studies
Authors: Di Pietro David A. 
Published: October 2015

AbstractConcept design plays a central role in project success as its product effectively locks the majority of system life cycle cost. Such extraordinary leverage presents a business case for conducting concept design in a credible fashion, particularly for first‐of‐a‐kind systems that advance the state of the art and that have high design uncertainty. A key challenge, however, is to know when credible design convergence has been achieved in such systems. Using a space system example, this paper characterizes the level of convergence needed for concept design in the context of technical and programmatic resource margins available in preliminary design and highlights the importance of design and cost evaluation learning curves in determining credible convergence. It also provides techniques for selecting trade study cases that promote objective concept evaluation, help reveal unknowns, and expedite convergence within the trade space and conveys general practices for conducting effective concept design‐to‐cost studies.
An Innovative Approach to the Development of Project Management Processes for Small‐scale Projects in a large Engineering Company
Authors: Laporte Claude Y. , Chevalier Frédéric 
Published: October 2015

AbstractA Canadian division of a large American engineering company has developed and implemented project management processes for their small‐scale and medium‐scale projects. The company was already using a robust project management process for their large‐scale projects. The objectives of this process improvement project were to reduce cost overruns and project delays, standardize practices to facilitate the integration of new managers, increase the level of customer satisfaction and to reduce risk‐related planning deviations. For this improvement project, the engineering organization used the new ISO/IEC 29110 standard developed specifically for very small entities. An analysis of the cost and the benefits of the implementation of small and medium scale project management processes was performed using the ISO economic benefits of standard methodology. The engineering enterprise estimated that, over a three‐year timeframe, savings of about 780,000$ would be realized due to the implementation of project management processes using the ISO/IEC 29110 standard.
When two is good company, but more is not a crowd
Authors: Nolan Andy J. , Pickard Andrew C , Russell Jennifer L , Schindel William D 
Published: October 2015

AbstractThis paper summarizes an approach to improve the effectiveness of the review (inspection) process. Effectiveness here is defined as the ability to reduce the number of defects escaping a review activity.By carefully pairing up developers and reviews, Rolls‐Royce was able to halve the rate of occurrence of defects in software, with no change to the process or tools, and with no changes to the team or the effort required to perform the reviews.The method hinges on an understanding of the capability of the developers and reviewers and making sure that only select pairings of team members will be allowed.The paper illustrates an example of the practice when applied to software code review but the principle can be applied to any development process. The code review process is an example of the principle but the philosophy can be applied to many more areas of the system development process. The paper ends by illustrating other ways to benefit from this approach.
A modeling pattern for layered system interfaces
Authors: Shames Peter M. , Sarrel Marc A. 
Published: October 2015

AbstractCommunications between systems is often initially represented at a single, high level of abstraction, a link between components. During design evolution it is usually necessary to elaborate the interface model, defining it from several different, related viewpoints and levels of abstraction. This paper presents a pattern to model such multi‐layered interface architectures simply and efficiently, in a way that supports expression of technical complexity, interfaces and behavior, and analysis of complexity. Each viewpoint and layer of abstraction has its own properties and behaviors. System elements are logically connected both horizontally along the communication path, and vertically across the different layers of protocols. The performance of upper layers depends on the performance of lower layers, yet the implementation of lower layers is intentionally opaque to upper layers. Upper layers are hidden from lower layers except as sources and sinks of data. The system elements may not be linked directly at each horizontal layer but only via a communication path, and end‐to‐end communications may depend on intermediate components that are hidden from them, but may need to be shown in certain views and analyzed for certain purposes.This architectural model pattern uses methods described in ISO 42010 [1], Recommended Practice for Architectural Description of Software‐intensive Systems and CCSDS 311.0‐M‐1 [2], Reference Architecture for Space Data Systems (RASDS). A set of useful viewpoints and views are presented, along with the associated modeling representations, stakeholders and concerns. These viewpoints, views, and concerns then inform the modeling pattern. This pattern permits viewing the system from several different perspectives and at different layers of abstraction. An external viewpoint treats the systems of interest as black boxes and focuses on the applications view, another view exposes the details of the connections and other components between the black boxes. An internal view focuses on the implementation within the systems of interest, either showing external interface bindings and specific standards that define the communication stack profile or at the level of internal behavior. Orthogonally, a horizontal view isolates a single layer and a vertical viewpoint shows all layers at a single interface point between the systems of interest. Each of these views can in turn be described from both behavioral and structural viewpoints.
Adapting Systems Engineering to the Development of Regional Jets
Authors: de Oliveira Wellington Martins , Jackson Scott 
Published: October 2015

AbstractRegional jet developers, like those for mainline jets, must strive to meet the needs of their customers while complying with rigid regulatory requirements. To meet these goals, developers face demands that require judicious adaptation of selected core systems engineering processes to this domain. These demands result from a more severe life cycle environment compared to mainline jets. This severe environment is seen to have a more far‐reaching impact on the architecture and requirements than one would expect. This adaptation requires the developer to consider the selection of which systems engineering processes are most critical to the successful development of an aircraft, and need more adaptation. This paper pays special attention to increased adaptation of stakeholder requirements and requirements analysis processes and their interaction with architectural design and tailoring with other systems engineering processes. The treatment of stakeholder requirements and requirement analysis needs to be efficient due the complexity and severity of the operational environment and life‐cycle scenarios. This issue results in new technologies that when incorporated in regional jet architectures result in high levels of complexity to deal with high level of performance. The architectural process must be rigorously traceable to the requirements process to deal with the top level requirements. A second area of focus is the discussion of organizational roles and responsibilities on stakeholder requirements and requirements analysis within an aircraft company, whether technical or not, these organizations may understand their role in these processes of capture the customer value on a severe life cycle and flow down to a complex architecture. The paper complements this analysis with the characteristic that regional jet developers apply an enhanced systems engineering process with focus on lean documentation.
On the Development of a Retirement Concept
Authors: Ryan Michael J. 
Published: October 2015

AbstractISO/IEC 15288 describes a number of Technical Processes that are invoked throughout the life‐cycle stages of a system. One of the concepts developed throughout the early technical processes is the Retirement Concept. This paper examines the role of retirement in the system life cycle and then differentiates between the retirement of a system at the end of each of its life cycles and the final disposal of the system at the end of its life. Three broad steps have been proposed to support design for retirement: identify the reasons for retirement, identify the potential retirement methods available, and identify the design issues that arise from the consideration of each retirement method. This paper identifies how that approach can support the development of a Retirement Concept. A simple example is offered by way of illustration.
Integrating Systems Safety into Systems Engineering during Concept Development
Authors: Fleming Cody Harrison , Leveson Nancy 
Published: October 2015

AbstractSafety should be designed into systems from their very conception, which can be achieved by integrating powerful hazard analysis techniques into the general systems engineering process. The primary barrier to achieving this objective is the lack of effectiveness of the existing analytical tools during early concept development.This paper introduces a new technique, which is based on a more powerful model of accident causality—called systems‐theoretic accident model and process (STAMP)—that can capture behaviors that are prevalent in these complex, software‐intensive systems. The goals are to (1) develop rigorous, systematic tools for the analysis of future concepts in order to identify potentially hazardous scenarios and undocumented assumptions, and (2) extend these tools to assist stakeholders in the development of concepts using a safety‐driven approach.
Guidance for Working Group Maintenance of the Systems Engineering Body of Knowledge (SEBoK) with Systems Security Engineering Example
Authors: Mailloux Logan O. , Garrison Cheryl , Dove Rick , Biondo Ryan C. 
Published: October 2015

AbstractRecently the Systems Engineering Body of Knowledge (SEBoK) was established to facilitate the advancement of the systems engineering discipline, the maintenance of which has been accepted by the International Council on Systems Engineering (INCOSE) and others. Within INCOSE the responsibility to update and maintain the SEBoK is assigned to individual working groups with respect to their specialty areas. These working groups are populated with volunteers, each with limited participation timelines, special interests, and individual motivations. While SEBoK Editors have the responsibility to maintain a coherent evolution; they depend heavily on inputs from these maintenance groups and their subject matter experts. However, maintenance teams may have different views of what should be covered by the SEBoK than those in other periods, raising the possibility of cyclical focus‐thrash in topic areas, beyond the normal evolution of relevant topic information. Therefore, it is beneficial, and perhaps even necessary, for working groups to facilitate a cohesive approach for maintaining SEBoK content. In this paper, we provide guidance for working groups to maintain SEBoK materials based on the INCOSE systems security engineering working group's recent experiences.