Challenges of Establishing a Software Product Line for an Aerospace Engine Monitoring System

Habli,; Kelly,; Hopkins, David

doi:10.1109/spline.2007.37

Cited by 18 publications

(16 citation statements)

References 4 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…A simplified gas turbine engine is introduced by I. Habli, T. Kelly and I. Hopkins [41]. As Figure 2 shows, it has a fan and a compressor to absorb a large volume of air.…”

Section: A Engine Control Systemmentioning

confidence: 99%

Model-based systems engineering with requirements variability for embedded real-time systems

Batmaz

Guan

et al. 2015

2015 IEEE International Model-Driven Requirements Engineering Workshop (MoDRE)

View full text Add to dashboard Cite

Additional Information:• it proposes a mechanism for the evolution of variability; 3. stakeholders' specifications for variable requirements are extended by the proposed approach; 4. it increases the consistency of system models by directly using SysML Activity Diagrams and Block Definition Diagrams as a base model for refining variability models for requirement representation. The proposed method is illustrated by an Aircraft Engine Control System case study.

show abstract

“…A simplified gas turbine engine is introduced by I. Habli, T. Kelly and I. Hopkins [41]. As Figure 2 shows, it has a fan and a compressor to absorb a large volume of air.…”

Section: A Engine Control Systemmentioning

confidence: 99%

Model-based systems engineering with requirements variability for embedded real-time systems

Batmaz

Guan

et al. 2015

2015 IEEE International Model-Driven Requirements Engineering Workshop (MoDRE)

View full text Add to dashboard Cite

show abstract

“…With the growing investment by both public and private sector organizations in software product-line architecture, managers need to know the organizational factors affecting its success [25].…”

Section: R6-absence Of Domain Expertsmentioning

confidence: 99%

“…Only in conjunction with appropriate organizational behaviors can software architecture effectively control project complexity [25].…”

Section: R9-immature Architecturementioning

confidence: 99%

“…Some are developed but never used; others lose value as product teams stop sharing the common architecture; still others achieve initial success but fail to keep up with a rapidly growing product mix. Sometimes the architecture deterioration is not noticed at first, masked by what appears to be a productivity increase [25].…”

Section: R10-pollution Of the Platformmentioning

confidence: 99%

See 1 more Smart Citation

The importance of documentation, design and reuse in risk management for SPL

Lobato

O’Leary

Almeida

et al. 2010

Proceedings of the 28th ACM International Conference on Design of Communication

View full text Add to dashboard Cite

Software Product Lines (SPL) is a methodology focusing on systematic software reuse, multiple benefits have been reported as a result of this type of software development. However, establishing a SPL is not a simple task. It is a challenging activity raising many challenges for engineering and management. This research aims to manage the risks during SPL development to provide traceability among them. For this, it is important that the risks are documented and there is a common design related to them. As solution, we identified the strengths and weakness in SPL development and the importance in designing of communication for risk documentation.

show abstract

“…Variability engineering is practiced today both in open-source (e.g., see a study of variability engineering in open-software systems software, including the Linux kernel [3]) and industry (e.g., see the experiences of Danfoss [18], GM [14], and Rolls-Royce [17]). Variability engineering also offers abundant opportunities for software researchers to explore new directions in a wide range of areas within requirements, architecture, verification and validation, and beyond, including reverse engineering, programming languages, performance, reliability, and security.…”

mentioning

confidence: 99%

Variability in Software: State of the Art and Future Directions

Czarnecki

2013

Fundamental Approaches to Software Engineering

View full text Add to dashboard Cite

Variability is a fundamental aspect of software. It is the ability to create system variants for different market segments or contexts of use. Variability has been most extensively studied in software product lines [10], but is also relevant in other areas, including software ecosystems [4] and context-aware software [15]. Virtually any successful software faces eventually the need to exist in multiple variants.Variability introduces essential complexity into all areas of software engineering, and calls for variability-aware methods and tools that can deal with this complexity effectively. Engineering a variable system amounts to engineering a set of systems simultaneously. As a result, requirements, architecture, code and tests are inherently more complex than in single-system engineering. A developer wanting to understand a particular system variant has to identify the relevant parts of requirements and code and ignore those that pertain solely to other variants. A quality assurer verifying a variable system has to ensure that all relevant variants are correct. Variability-aware methods and tools leverage the commonalities among the system variants, while managing the differences effectively.This talk will analyze how variability affects the software lifecycle, focusing on requirements, architecture and verification and validation, review the state of the art of variability-aware methods and tools, and identify future directions. Variability modeling at the requirements level helps explaining a variable system and its evolution to all stakeholders, technical and nontechnical ones. A popular technique is feature models [19,11], which are hierarchically composed declarations of common and variable features and their dependencies. At the requirements level, system features represent cohesive clusters of requirements [7,8], providing convenient "mental chunks" to all stakeholders to understand the system, its variability, and its evolution. For example, changes at the code level can be explained as feature additions, removals, merges, or other kinds of modifications at the feature level [27]. As feature models provide only declarations of features, an obvious direction is to enrich them with feature specifications, such as behavioral ones (e.g., [30]). Feature models can also be enhanced with rich forms of dependencies, such as representations of feature interactions (e.g., [24]), and with quality attributes, such as performance (e.g., [2,26]). Feature-oriented software development (FOSD) aims at treating features as first-class citizens,

show abstract

Challenges of Establishing a Software Product Line for an Aerospace Engine Monitoring System

Cited by 18 publications

References 4 publications

Model-based systems engineering with requirements variability for embedded real-time systems

Model-based systems engineering with requirements variability for embedded real-time systems

The importance of documentation, design and reuse in risk management for SPL

Variability in Software: State of the Art and Future Directions

Contact Info

Product

Resources

About