Agile Systems Engineering Life Cycle Model for Mixed Discipline Engineering

Agile software development methods are widely accepted and valued in software-dominated industries. In more complex setups like multidisciplinary system development the adoption of an agile development paradigm is much less straightforward. Bigger teams, longer development cycles, process and product standard compliance and products lacking flexibility make an agile behaviour more difficult to achieve. Focusing on the fundamental underlying problem of dealing with ever ongoing change, this paper presents an agile Systems Engineering approach as a potential solution. Therefore a generic Systems Engineering action model was upgraded respecting agile principles and adapted according to practical needs discovered in an empirical study. This study was conducted among the partners of the S2QI agile workgroup made up from experts of automotive, logistics and electronics industries. Additionally to an agile Systems Engineering action model, a list of 15 practical success factors that should be considered when using an agile Systems Engineering approach is one of the main outcomes of this survey. It was also found that an agile behaviour in Systems Engineering could be supported in many different areas within companies. These areas are listed and it is also shown how the agile action model and the agile success factors are related to them.

ABSTRACTThe author was asked to define Agile Systems Engineering, and found it necessary, for context, to first develop some thoughts on what engineering and systems engineering might be. This led to thoughts on differentiating engineering from crafting and arting. Engineering, crafting, and arting are activities carried out by artifact creators with different purposes, but at the core, all are constrained and enabled by the laws of coherence. This article does not suggest what those laws might be; but does conclude that the definition of agile systems engineering is rooted in what it does, not how it does it.

INSIGHTVolume 17, Issue 2 p. 55-55 INCOSE Event Agile and Lean Systems Engineering: A Complimentary and Contradictory Relationship Avigdor Zonnenshain, Avigdor Zonnenshain avigdor.zonnenshain@incose.org Search for more papers by this author Avigdor Zonnenshain, Avigdor Zonnenshain avigdor.zonnenshain@incose.org Search for more papers by this author First published: 23 June 2015 https://doi.org/10.1002/inst.201417255AboutPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onFacebookTwitterLinked InRedditWechat No abstract is available for this article. Volume17, Issue2July 2014Pages 55-55 RelatedInformation

This study proposes a framework for managing knowledge in innovative product development by integrating the VSTE model and the CART approach. The VSTE model structures project knowledge across four layers—Vision, Strategy, Tactics, and Execution—based on Polanyi’s theory of explicit integration. To address key challenges such as stakeholder complexity, uncertainty, resource constraints, and nonlinear phase transitions, the CART model introduces four methods: Collective Impact (CI), Agile Systems Engineering (ASE), Risk-Based Approach (RBA), and TRL/IML Vision ConOps Management (TVCM). A case analysis of the HondaJet project confirms strong alignment between CART principles and actual project practices, particularly in vision sharing and collaboration. These findings suggest the framework’s practical relevance.

Rockwell Collins, in Cedar Rapids, Iowa, is using a product line approach for a family of radios they produce for military and international markets, with an agile systems engineering process tailored individually for synchronized software, firmware, and hardware development. This mixed-discipline engineering group encompasses some 350 employees working on multiple projects simultaneously for multiple customers. The product line approach provides an agile systems target-context for the agile systems engineering process — re-using common product-line hardware, firmware, and software whenever possible, evolving the product line with both internally-funded development and opportunities presented by customer project work, and accommodating special customer needs that grow the knowledge and capability base for potential later use in product-line extension. This article focuses on the mixed-discipline agile systems engineering process reviewed in the September, 2015, INCOSE Agile Systems Engineering Life Cycle Model (ASELCM) discovery workshop, and doesn't address the proprietary strategy and detail of the product line architecture. Notable elements that will be discussed include a parallel evolving product line roadmap as the strategic driving function, a facilitating central relationship-management role for systems engineering, synchronization of mixed engineering disciplines, an enabling infrastructure for agile hardware development, strong opportunity management complimenting traditional risk management, and comparison to the ASELCM Model-Based Systems Engineering (MBSE) pattern.

Agile model-based systems engineering of passenger train operational design

Systems engineering is defined as a “full life cycle” discipline and provides methodologies and processes to support the design, development, verification, sustainment, and disposal of systems. While this cradle-to-grave concept is well documented throughout literature, there has been recent emphasis on evolving and digitally transforming systems engineering methodologies, practices, and tools for the latter phases of system life cycles. This article adapts principles from the software engineering domain DevOps concept (a collaborative merger of system development and operations) into a Systems Engineering DevOps (SEDevOps) life cycle model. This facilitates a merger of systems engineering processes, tools, and products into a surrogate operational environment in which the sustainment of a system is tied closely to the curation of a system model expanded to include the enabling system elements necessary for operations and sustainment (procedures, scripts, etc.). This progression of the systems engineering mindset, focused on digitally transforming and enhancing system operations and sustainment, improves agility in later life cycle phases. A framework for applying SEDevOps is introduced as a new systems modeling language profile. A use-case leveraging this “model-based system operations” framework, shows how merging support elements into a spacecraft system model improves adaptability during operations, exemplifying elements of a DevOps approach to cyber-physical system sustainment.

Modeling chirped-pulse amplification (CPA)- and nonlinear optics (NLO)-based systems is crucial to advance CPA+NLO design and optimization. We present a modular and expandable start-to-end model for engineering and reverse engineering CPA+NLO systems.

The ever-increasing level of interaction across the "border" between software engineering and information systems is evidence of substantive maturity and sustained effort to articulate these closely-related disciplines. As software engineering principles have matured and proven themselves, information systems developers have incorporated them in the analysis and design process. We anticipate that continued development and improvement of software engineering methods and tools enables developers to continually improve the software development effort, resulting in better software and greater client satisfaction.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>

Reverse engineering technology plays an important role in a variety of manufacturing applications. It significantly reduces the production lead time and the costs of the part duplication processes. This paper evaluates the feasibility of using reverse engineering and concurrent engineering methods with data obtained from state-of-the-art laser scanning to remanufacture complex geometrical parts. Two aircraft structural components were evaluated in this study: a forward latch fitting of a C 141 and a leading edge rib of an F-15. The first phase of this project, accuracy characterisation of a reverse engineering system, demonstrated that laser scanning and CAD model reconstruction can duplicate aircraft structural components accurately and efficiently, within a tolerance of ±0.127 mm (0.005 in). The second phase of this project, development of a concurrent engineering system, showed that an integrated reverse engineering and CAM machining system can make the entire remanufacturing process snore automatic and efficient, further reducing part turnaround time.

Driven by customer demands and global competition, systems engineers often experience dramatic project shifts and rapid technological advances that can place great strains on an engineering organization. In addition, project teams also deal with changing personnel, mistakes or rework, and slow engineering response times to unplanned needs. These external and internal factors can lead to reduced quality, increased costs, and slipped schedules. An effective knowledge management architecture is a necessity in today's engineering environment, and should be treated as an important project activity. Due to constantly evolving projects and project teams, knowledge management must be able to adapt based on current needs and resources. The purpose of this paper is to present knowledge management issues that must be addressed during an engineering project, and to propose a useful operational architecture for knowledge management. This architecture will provide an image of how agile knowledge management can be used by systems engineers to counter the turbulence in today's technical work forces, and how it can be integrated into existing organizational structures. The proposed architecture is best described as adaptable pairing, where two or more individuals engage in knowledge sharing and assignment swapping to complete a specific project task. The pairing architecture will address three common knowledge management problems that may negatively impact project quality, cost, and schedule – uninformed decision making, lengthy response delays, and rework. Intents and traits of adaptable pairing may be appropriate for any industry, however, evidence will focus primarily on technology industries engaged in contract projects. Historical evidence of successful pairing in the world of software engineering is presented at the end of the paper.

This paper provides an overview of the process, practices, developments and synergies that Airbus Defence and Space are implementing Human System Integration (HSI) into the Continuous Engineering/Model Based System Engineering (MBSE) throughout the company. The paper highlights these developments, which include internal research programmes, European Union funded research projects and Airbus internal synergy projects to provide a complete system engineering lifecycle. This research includes an EU funded 3 year project HoliDes—Holistic Human Factors and System Design of Adaptive Cooperative Human Machine Systems [1]. HSI has been incorporated in the project lifecycle via US Military (DoD-Instruction 5000.2) [2] with the introduction of a Human System Integration Plan, which is a key requirement for the validation and verification of any new system or any modification to any existing US military system. Airbus DS has used HSI in several innovative approaches, these include, the dramatic reduction in the manpower and costs of deployment and logistic support for large scale military operations, the integration with our Architectural Framework to provide a system architecture that is compliant with the US and UK Lines of development—Training, Equipment, Personnel (HR), Organisation, Information, Logistics, Concepts and Doctrine and Infrastructure and the introduction of ILS and Training into our MBSE approach. Airbus DS recognises the need to integrate HSI into its system engineering lifecycle as in the past the inclusion of human interaction has generally been missed and as most systems interact with people, HSI provides Airbus DS with complete systems integration process. Our Human System Integration (HSI) work at Airbus DS is evolving from the initial Human View Architectural Framework research [4] and then the nine HSI domains—Manpower, Personnel, Training, Human Factors Engineering, Environment, Occupational Health, Safety, Survivability and Habitability [5].

This article presents a state-of-the-art review of recent advances aimed at transforming traditional Failure Mode and Effects Analysis (FMEA) into a more intelligent, data-driven, and semantically enriched process. As engineered systems grow in complexity, conventional FMEA methods, which are largely manual, document-centric, and expert-dependent, have become increasingly inadequate for addressing the demands of modern systems engineering. We examine how techniques from Artificial Intelligence (AI), including machine learning and natural language processing, can transform FMEA into a more dynamic, data-driven, intelligent, and model-integrated process by automating failure prediction, prioritisation, and knowledge extraction from operational data. In parallel, we explore the role of ontologies in formalising system knowledge, supporting semantic reasoning, improving traceability, and enabling cross-domain interoperability. The review also synthesises emerging hybrid approaches, such as ontology-informed learning and large language model integration, which further enhance explainability and automation. These developments are discussed within the broader context of Model-Based Systems Engineering (MBSE) and function modelling, showing how AI and ontologies can support more adaptive and resilient FMEA workflows. We critically analyse a range of tools, case studies, and integration strategies, while identifying key challenges related to data quality, explainability, standardisation, and interdisciplinary adoption. By leveraging AI, systems engineering, and knowledge representation using ontologies, this review offers a structured roadmap for embedding FMEA within intelligent, knowledge-rich engineering environments.

The engineering of systems has always been a multi-disciplinary activity carried out by teams of engineers operating within different domains of expertise. The paper discusses work in developing standardised approaches to systems engineering tool data exchange and developments which will support globally dispersed teams. The paper begins with a brief overview of the domain of systems engineering and the issues involved in exchanging Systems Engineering (SE) models. It discusses the SEDRES Project, a European project which developed an appropriate SE data model and transitioned it into the ISO, where it has become Application Protocol AP-233, within the ISO 10303 STEP environment. Other issues were raised within the SEDRES Project, and the results of experiments into the effectiveness of the system are discussed.KeywordsSystems EngineeringData ExchangeTeams.

Model‐Based Systems Engineering (MBSE) is the next step in the evolution of systems engineering (SE) in which documents are replaced by descriptive models as the authoritative embodiment of SE knowledge. These descriptive models possess a unique combination of the features and characteristics of documents, software, and data. Conscientiously applying appropriate modeling principles and practices is essential to make informed decisions to moderate the accumulation of model technical debt. This paper briefly explains the concept of technical debt and its adaptation to the domain of descriptive models for MBSE. The paper then describes 18 foundational modeling principles that model architects should consider when making architectural and implementation decisions about their models and describes some of the key model technical debt tradeoffs that result when these principles are not followed. These principles address commonly observed challenges regarding model federation architecture, the selection and use of model layers, the modeling of the domain, and the semantics of modeling constructs. Applying disciplined model architecting practices to conscientiously manage the accrual and payoff of technical debt can make the difference between an enduring model that provides substantial value throughout the life cycle of the modeled entity and a model whose value collapses under the weight of uncontrolled technical debt.