PuLSE-I: Deriving instances from a product line infrastructure

Bayer, Joachim; Gacek, Cristina; Muthig, Dirk; Widen, Tanya

doi:10.1109/ecbs.2000.839882

Cited by 25 publications

(20 citation statements)

References 6 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…PuLSE-I [8] activities include planning product derivation. However, the approach defines roles and tasks on a very high-level.…”

Section: Main Approachesmentioning

confidence: 99%

“…The framework assumes that 'engineers' perform all the work and does not specify responsibilities, nor does it define role and task structures. The framework focuses on product configuration and is only a high-level attempt at providing the methodological support that Deelstra et al [5] and others [8,12,13] agree is required for product derivation. DOPLER UCon [14] is a tool-supported approach for product configuration with capabilities for adapting and augmenting variability models to guide sales people and application engineers through product derivation.…”

Section: Main Approachesmentioning

confidence: 99%

“…Some of them, like FODA [17], capture only a small part of the process while others, like PuLSE-I [8] are much broader. All of them (with the exception of the SEI PLPF) come with different amounts of prescription and tool support.…”

Section: Main Approachesmentioning

confidence: 99%

“…All of them (with the exception of the SEI PLPF) come with different amounts of prescription and tool support. Some such as [5,8,11,16,18], describe a generic process at a high level while others such as [9,10,19] are very close to practice and are prescriptive in the definition of their process steps and documentation.…”

Section: Main Approachesmentioning

confidence: 99%

“…DOPLER UCon does provide some description of artefact flow however the specified level of granularity is too abstract to give useful guidance for practitioners. PuLSE-I [8] names the development items in a descriptive manner. However, like the others, it does not provide a detailed description of artefact usage within the process.…”

Section: Definition Of Flow Of Artefactsmentioning

confidence: 99%

See 4 more Smart Citations

The Pro-PD Process Model for Product Derivation within software product lines

O’Leary

Almeida

Richardson

2012

Information and Software Technology

View full text Add to dashboard Cite

a b s t r a c tBackground: The derivation of products from a software product line is a time consuming and expensive activity. Despite recognition that an effective process could alleviate many of the difficulties associated with product derivation, existing approaches have different scope, emphasise different aspects of the derivation process and are frequently too specialised to serve as a general solution.Objective: To define a systematic process that will provide a structured approach to the derivation of products from a software product line, based on a set of tasks, roles and artefacts. Method: Through a series of research stages using sources in industry and academia, this research has developed a Process Model for Product Derivation (Pro-PD). We document the evidence for the construction of Pro-PD and the design decisions taken. We evaluate Pro-PD through comparison with prominent existing approaches and standards. Results: This research presents a Process Model for Product Derivation (Pro-PD). Pro-PD describes the tasks, roles and work artefacts used to derive products from a software product line. Conclusion: In response to a need for methodological support, we developed Pro-PD (Process Model for Product Derivation). Pro-PD was iteratively developed and evaluated through four research stages. Our research is a first step toward an evidence-based methodology for product derivation and a starting point for the definition of a product derivation approach.

show abstract

“…PuLSE-I [8] activities include planning product derivation. However, the approach defines roles and tasks on a very high-level.…”

Section: Main Approachesmentioning

confidence: 99%

Section: Main Approachesmentioning

confidence: 99%

Section: Main Approachesmentioning

confidence: 99%

Section: Main Approachesmentioning

confidence: 99%

Section: Definition Of Flow Of Artefactsmentioning

confidence: 99%

See 3 more Smart Citations

The Pro-PD Process Model for Product Derivation within software product lines

O’Leary

Almeida

Richardson

2012

Information and Software Technology

View full text Add to dashboard Cite

show abstract

Agile product line engineering—a systematic literature review

et al. 2011

View full text Add to dashboard Cite

Software Product Line Engineering (SPLE) demands upfront long‐term investment in (i) designing a common set of core‐assets and (ii) managing variability across the products from the same family. When anticipated changes in these core‐assets have been predicted with certain accuracy, SPLE has proved significant improvements. However, when large/complex software product line projects have to deal with changing market conditions, alternatives to supplement SPLE are required. Agile Software Development (ASD) may be an alternative, as agile processes harness change for the customer's competitive advantage. However, when the aim is to scale Agile projects up to effectively manage reusability and variability across the products from the same family, alternatives to supplement agility are also required. As a result, a new approach called Agile Product Line Engineering (APLE) advocates integrating SPLE and ASD with the aim of addressing these gaps. APLE is an emerging approach, which implies that organizations have to face several barriers to achieve its adoption. This paper presents a systematic literature review of experiences and practices on APLE, in which the key findings uncover important challenges about how to integrate the SPLE model with an agile iterative approach to fully put APLE into practice. Copyright © 2011 John Wiley & Sons, Ltd.

show abstract

Using parameters and discriminants for product line requirements

Mannion

Kaindl

2007

Systems Engineering

View full text Add to dashboard Cite

Reuse and Requirements Engineering are very important for efficient and successful product development. However, there are many open issues for performing them well in practice, especially reuse of requirements. This paper addresses several of these issues by making use of parameters and discriminants for product line requirements. Discriminants are a special kind of requirement that differentiate one product from another. They represent qualitative variability in a product line model, while parameters represent quantitative variability. In this paper these techniques are combined in the form of parameterized discriminants. Using the techniques and a metamodel for the representation of a product line model, a stakeholder‐viewpoint oriented process is defined for capturing product line requirements and constructing a product line model. From such a generic model and with well‐defined semantics, selecting single product application requirements can be done systematically, guaranteeing the property that the resulting single product satisfies the constraints of the product line model. Even for unsystematic free selection as often used in practice, it can be formally verified whether this property holds. The approach is illustrated using a hypothetical mobile phone example and draws upon case study work with real‐world requirements. © 2007 Wiley Periodicals, Inc. Syst Eng

show abstract

PuLSE-I: Deriving instances from a product line infrastructure

Cited by 25 publications

References 6 publications

The Pro-PD Process Model for Product Derivation within software product lines

The Pro-PD Process Model for Product Derivation within software product lines

Agile product line engineering—a systematic literature review

Using parameters and discriminants for product line requirements

Contact Info

Product

Resources

About