Method engineering: Product Line Evolution Support at
Scoping-method (PLEvo-Scoping)
Angeliki Iliana Triantou
University of Utrecht, Utrecht
a.i.triantou@students.uu.nl
Utrecht 2012
Introduction
Product line engineering is a software development approach that aims to improve the
development efficiency for families of systems by facilitating large-scale reuse
(Bayer, Flege & Gacek, 1999). Nowadays, Product line (PL) engineering is
widespread used in industry (John &Villela, 2010) and there are many companies
which implement the Software Product line engineering (SPLE) principles. With this
way, companies try to develop embedded software-intensive systems as well as
information systems (Pohl, Böckle, & van der Linden, 2005), (Bosch 2002).
In 2008, Karina Villela who was an academic in University of Salvador (UNIFACS)
in Computing and Network Research Center, Joerg Doerr who was a Doctor at
Fraunhofer Institute for Experimental Software Engineering (IESE) in Germany and
Anne Gross who was a Researcher at the same institute (IESE) observed the lack of
methods that provide “explicit support for estimating the evolution expected in a
software system over a specified period of time” (Villela, Dörr & Gross, 2008), thus
they coined the Product Line Evolution at Scoping (PLEvo-scoping) method. The
main goal of this method is to facilitate the PL scoping team to identify the unstable
PL features of the embedded system and predict possible adaptation needs in the
future. Furthermore, the method facilitates the improvement of the initial product plan
by identifying the adaptation needs and postponing the unstable features.
The method contains four steps and each step is separated by different activities. The
main steps of PLEvo-scoping method are the “Preparation for Volatility Analysis”,
the “Environment Change Anticipation”, the “Change Impact Analysis” and the
“Product Evolution Planning”.
The first step’s (Preparation for Volatility analysis) main propose is to define the
timeframe of the volatility analysis, through the estimation of the product’s life
expectancy and the determination of the types of components that are responsible for
future changes in customers needs and in market in general. With other words the
product manager should investigate the possibility of changes in the system’s
environment and establish a relevant timeframe for the product’s lifespan. The step of
the Environment Change Anticipation contains the identification of the actors and the
description of the facts that are relevant to changes in the system environment.
Propose of the third step which is the Change Impact Analysis, is the investigation of
facts from the previous step. By identifying, characterizing and classifying the
adaptation needs of the identified facts the domain experts give a complete overview
of the technical penalty and the technical risk that are related to each adaptation need.
The last step, called Product Evolution Planning, edits the most relevant adaptation
need and creates the plan of product evolution by analyzing and selecting the most
appropriate alternative solutions that deals with the relevant adaptation need. After the
integration of the PLEvo-scoping method tables are provided and be available to the
product managers.
Example
In this chapter an example of a software product is illustrated for the better
understanding of this method. The example which will be analyzed in the following
paragraphs is a software product for ATM’s. There are a lot of deliverables that are
available to the product managers after the integration of the PLEvo-scoping method.
In this paragraph some deliverables (the system components, the generic actors and
facts and the adaptation needs) depicted in tables to give a clear view of the example.
In the first step (Preparation for Volatility Analysis) the product manager has to
estimate the lifespan of the product. The product manager approximately identifies the
product’s life expectancy, with other words, the time that the product is expected to be
used without reinvestment in the infrastructure. For the ATM software product the
timeframe should not be longer than 5 years, because of the technological needs that
change every year and because of the fact that the biometrics technology has already
integrated in many sectors of security systems. Already in Japan four big banks have
adopted biometrics technologies to replace the existing ATM cards (Xiao, 2007).
Furthermore, in this step the domain experts identify components and provide
characteristics that may change in the future. In the Table 2 below are illustrated some
of these characteristics.
Embedded system components
Size of PIN code
PIN verification
Identify the Maestro or Visa card
Limit in the amount of money
withdrawing
Up to 3 times wrong PIN, stop the
transaction
Protection of each data account
Table 2: Embedded system components
In the second step (Environment Change Anticipation) it is necessary to identify the
actors who interact with the system. In our case the actors are the bank’s customers,
the bank’s employees and competitor companies that sell similarly software products.
After that it is very important to identify the facts that probably cause changes in the
system’s environment. In the Table 3 there are some facts that indirectly cause
changes in the software product.
Actors
User
Technology
Competitor
Facts
Need to have more safety transactions
Need to withdrawn money in less time
Decision of bank to change the system
Biometric security systems
Adoption of a new technology
Innovate extremely new software product
Table 3: Generic Facts
The third step (Change Impact Analysis) identifies, characterize and prioritize the
adaptation needs. In ATM’s software product these needs could be mistakes or lacks
in the programming code, or new technology that have to adapt on the product, like
the integration of cameras in the ATMs. The Table 4 below provides the
characterization and the prioritization of adaptation needs. In the left part of the table
the name and the code of some adaptation needs are given (AN = Adaptation Need).
Identification
AN1 Support of security system
AN7 Users’ identification
AN34 Camera scanning
AN60 Easy product use
AN65 Technological inventions
AN89 Emergency trigger
POI
3
4
2
1
5
5
BI
4
5
5
5
3
5
TP
1
2
1
4
3
1
TR
2
3
4
3
1
3
AAI
5
3
2
5
5
3
P
1
1
4
5
2
1
Characterization: BI (Business Impact), TP (Technical Penalty), TR (Technical Risk)
Prioritization: POI (Potential Occurrence Indicator), AAI (Anticipation Advantage Indicator), P (Priority)
Table 4: Characterization of adaptation needs
The last step (Product Evolution Planning) contains the activities of planning
introduction of adaptation needs, analyze alternative solutions, select alternative
solution and revise plan for introduction of adaptation needs. All the alternative
solutions analyzed in tables provided by the PLEvo-scoping method. In ATM’s
software product case the Product Evolution Planning step is difficult described
because of the lack of real facts and features that could be analyzed and give an
adequate solution.
Related literature
Until 2008, many researchers had worked on the software evolution field. In 2000,
Bayer, Flege & Gacek published their work in which they evaluate traditional
software architecture with a context of PuLSE-DSSA software architecture (Bayer,
Flege & Gacek, 2000). In 2001, Aoyama in his paper with the title “Continuous and
Discontinuous Software Evolution: Aspects of Software Evolution across Multiple
Product Lines”, observed the continuous and discontinuous evolution of software
systems by conducting an empirical study on the evolution of software systems in
mobile phones (Aoyama, 2001). Three years later, in 2004, Nurmuliani, Zowghi and
Fowell published a paper about the “Analysis of Requirements Volatility during
Software Development Life Cycle” and their main purpose is to focus on analyzing
the changes for identifying and characterizing the requirements volatility (Nurmuliani,
Zowghi & Fowell, 2004).
In the following years many research were made, like the Buckey’s and Zenger’s
paper with title “Towards a Taxonomy of Software Change” in which the two authors
focus more on technical aspects and provide framework of software changes
(Buckley, Mens & Zenger et al). However, none of the existing researches until 2008
had focused on the same aspect with PLEvo-scoping method.
Taking into consideration that the PLEvo-Scoping method is a new PL scoping
method, first mentioned in 2008, it is understandable that there is not enough
literature to illustrate and evaluate this method. Karina Villela, Joerg Doerr and Anne
Gross based on the elements proposed by Software Evolution Model (Villela, Dörr &
Gross, 2008) coined, described and analyzed the PLEvo-scoping method. The
Software Evolution Model’s include the following concepts, Actor, Fact, Adaptation
Need, Adaptation Type, Level of Variation, Change and Impact. All these concepts
played an important role in the construction of the PLEvo Scoping method as it will
be described in the next paragraph. Except from the aforementioned authors' two
papers, there is not any other scientific work that is referred in this method.
Their first paper that is written in 2008, with title “Proactively Managing the
Evolution of Embedded System Requirements”, provides the methods description and
a useful example of its use. The purpose of the second paper that is written in 2010,
with title “Evaluation of a Method for Proactively Managing the Evolving Scope of a
Software Product Line”, is to evaluate the method inside a quasi-experiment. In this
study the authors achieve to verify that the PLEvo-scoping method is adequate and
feasibly.
Process-Deliverable Diagram of the PLEvo Scoping method
In this chapter the activity table (Table 5) and the concept table (Table 6) for the
PLEvo Scoping method are provided. Also the Process-Deliverable Diagram (PDD)
of PLEvo Scoping method is illustrated in Figure 1. The activity table describes the
main activities and the sub-activities that are formulated as steps and activities
respectively, in the PLEvo Scoping method. Their corresponding concepts are all
spelled out in capital letters. The concept table is a description of the deliverables that
each of the main activities and sub-activities have.
In Figure 1 the Process-Deliverable Diagram shows that the result after the
implementation of the aforementioned method is the revision of the PL Evolution
map. The four main activities in the PDD are the Preparation for Volatility Analysis,
the Environment Change Anticipation, the Change Impact Analysis and the Product
Line Evolution Planning. Each activity is divided in sub-activities that are all depicted
on the right side of the Process-Deliverable Diagram. Moreover, all the activities are
sequential, as they need to carry out in a predefined order, except from the first one
(Preparation for Volatility Analysis) which is unordered, as its sub activities can be
executed in any order. On the left side of Process-Deliverable Diagram depicted the
deliverables (concepts) of the sub-activities. All the explanations about the activities
and the concepts descriptions are taken from the paper that has written by Villela,
Dörr and Gross in 2008 and the paper by Villela, Dörr and John that has written in
2010.
Figure 1: PDD of PLEvo Scoping method
Table 5: Activity Table
Activity
Prepare Volatility
Analysis
Change
Environmental
Anticipation
Change Impact
Analysis
Sub-activity
The product manager establishes the TIMEFRAME that
restricts the current VOLATILITY ANALYSIS. The
TIMEFRAME should not be longer than 10 years.
Identify the
system
components
The domain experts identify the types of SYSTEM
COMPOMENTS involved in the assembly of the embedded
system.
Identify
environmental
actors
The domain and market experts identify the environmental
ACTORS who are related with the PRODUCT LINE (PL)
ENVIRONMENT and realize FACTS that may affect the PL.
Characterize
potential facts
The product manager identifies and characterizes potential
FACTS that may be caused by the identified ACTORS.
Verify perspective
of new actors and
facts
The domain and market experts verify the PERCPECTIVE of
new ACTORS and characterize how these ACTORS may
cause environment changes.
Classify potential
facts
The product manager prioritizes the potential FACTS
according to their relevans, in order to decide whether and
when they have impact in ADAPTATION NEEDS analyzed
terms.
The domain and market experts identify the ADAPTATION
NEEDS that may be allowed or required in the PL as a
consequence of the previously identified FACTS.
Identify adaptation
needs
Characterize
adaptation needs
Prioritize
adaptation needs
Plan the PL
Evolution
Description
Establish the
timeframe
The domain experts characterize the ADAPTATION NEEDS
by identifying the PL FEATURES to be affected by them, and
by estimating business impact, technical penalty and technical
risk.
The product manager prioritizes the ADAPTATION NEEDS in
order to decide whether and when the inclusion of an
ADAPTATION NEED should be planned.
Plan introduction
of adaptation
needs
The domain experts make the plan introduction of the
expected ADAPTATION NEEDS.
Analyze
alternative
solutions
Domain experts analyze ALTERNATIVE SOLUTIONS for
dealing with relevant ADAPTATION NEEDS.
Select alternative
solution
The product manager selects the best ALTERNATIVE
SOLUTIONS for dealing with the ADAPTATION NEEDS.
Revise plan for
adaptation needs
The product manager revises the plan for introducing the
ADAPTATION NEEDS into the PL ENVIRONMENT and
makes the necessary adjustments.
Table 6: Concept Table
Concept
Description
TIMEFRAME
A timeframe that restricts the current volatility analysis. In practice a
timeframe should not be longer than 10 years, as the technology evolution
change every year (Villela et al., 2008).
The types of system components involved in the assembly of the
embedded system (Villela et al., 2008).
An analysis that consists of a timeframe and one or more system
components (Villela et al., 2008)
A single entity that is related with the PL environment and realize facts
that may affect the PL (Villela et al., 2010).
The result of interference of the actors with the PL environment. Has a
property, called “Relevance”, which is a description of the consequence of
the facts in the PL environment. More detailed the relevance is an
indication that shows if the characterized facts should further analyzed in
iterations (Villela et al., 2008).
The current environment of the PL related with actors and plays important
role in the PL evolution map creation (Villela et al., 2008).
A verification of new actors playing a part in PL’s environment within a
specific timeframe and secondly an explanation on how these actors may
change the PL environment (Villela et al., 2008).
A list of facts of a PL environment, ordered by the relevance of facts.
Classification contains two attributes, the “Potential Occurrence Indicator”
that combines the probability of the first time that facts are associated with
the same adaptation need and the attribute “Anticipation Adaptation
Indicator” that combines the three attributes of the adaptation needs
(Villela et al., 2008).
The adaptation needs that required in the PL as a consequence of the
previously identified facts. The concept “adaptation needs” has three
properties, the “Business impact” which is the adaptation needs’ impact on
business or customers, the “Technical penalty” that is the penalty that the
embedded system suffer if the adaptation needs and the alternative
solution did not met from the begging and the “Technical risk” which is the
risk that is related to each adaptation need and take into consideration the
technology, the complexity and the quality. All the values of these
attributes are defined by a ordinal scale of five points (1 = low to 5 = high)
(Villela et al., 2008).
A feature of the Product Line that characterizes the adaptation needs
(Villela et al., 2010).
An ordered list that consists of one or more adaptation needs based on
the volatility analysis and the PL features. The order list is based also on
the properties, Business impact, Technical penalty and Technical risk
(Villela et al., 2008).
A description of when and in which products relevant adaptations are
expected to be introduced. This concept gives rise to the Product Line
evolution map (Villela et al., 2008).
Four alternative solutions provided by the PLEvo Scoping method and
deal with relevant adaptations needs. Alternative solution contains five
properties, the “Prior effect” which is “the effort required to perform the
adaptation need before the fact required the adaptation need takes place”,
the “Further effort” which is the “effort required to perform the adaptation
need when the fact takes place”, the “Cost” that is the cost associated to
the introduction of necessary new technologies, the “Effectiveness” that is
“the capability of the alternative solution for introducing the adaptation
need into the embedded system without causing rework” and the
“Strategic alignment” which is the “capability of the alternative solution to
contribute to the achievement of the results target by the product evolution
strategy”. All the values of these attributes are defined by a ordinal scale
of five points (1 = low to 5 = high) (Villela et al., 2008).
SYSTEM
COMPONENT
VOLATILITY
ANALYSIS
ACTOR
FACT
PRODUCT LINE
ENVIRONMENT
PERSPECTIVE
CLASSIFICATION
ADAPTATION
NEED
PRODUCT LINE
FEATURE
MAP OF
ADAPTATION
NEEDS
PRODUCT
EVOLURION MAP
ALTERNATIVE
SOLUTION
PRODUCT LINE
EVOLUTION MAP
A description of the most relevant adaptation needs and of the best
alternative solution that are likely to be allowed or required (Villela et al.,
2008).
References
Aoyama, M. (2001). Continuous and discontinuous software evolution: aspects of software
evolution across multiple product lines. Proceedings of the 4th International
Workshop on Principles of Software Evolution, IWPSE ’01 (pp.87–90). New York,
NY, USA: ACM. doi:10.1145/602461.602477
Bayer, J., Flege, O., Knauber, P., Laqua, R., Muthig, D., Schmid, K., Widen, T. (1999).
PuLSE: a methodology to develop software product lines. Proceedings of the 1999
symposium on Software reusability, SSR ’99 (pp.122–131). New York, NY, USA:
ACM. doi:10.1145/303008.303063
Bayer, J., Flege, O., & Gacek, C. (2000). Software Architectures for Product Families.
Lecture Notes in Computer Science, 1951, (pp.210–216). Springer Berlin /
Heidelberg. from http://www.springerlink.com/content/1yvvgyhel7ue7w7m/abstract/
Bosch, J. (2002). Maturity and Evolution in Software Product Lines: Approaches, Artefacts
and Organization. In: G. Chastek (Ed.) 2nd Software Product Line Conference,
Lecture Notes in Computer Science, 2379, (pp.257-271). Heidelberg: Springer.
Buckley, J., Mens, T., Zenger, M., Rashid, A., & Kniesel, G. (2005). Towards a taxonomy
of software change. Journal of Software Maintenance and Evolution: Research and
Practice, 17(5), 309–332. doi:10.1002/smr.319
John, I., & Villela, K. (2010). Software Product Lines: Going Beyond. Lecture Notes in
Computer Science, 6287, (pp.515–516). Springer Berlin / Heidelberg. from
http://www.springerlink.com/content/n1564846l18n96v6/abstract/
Nurmuliani, N., Zowghi, D., & Powell, S. (2004). Analysis of requirements volatility during
software development life cycle. Proceedings of the Software Engineering
Conference, (pp.28–37). Australian, IEEE. doi:10.1109/ASWEC.2004.1290455
Pohl, K., Böckle, G., & van der Linden, F. (2005). Software product line engineering:
foundations, principles, and techniques. Birkhäuser.
Villela, K., Dörr, J., Gross, A. (2008). Proactively Managing the Evolution of Embedded
System Requirements. Proceedings of the 16th International Requirements
Engineering Conference, Catalonia, Barcelona, Spain, 13–22.
Villela, K., Dörr, J., & John, I. (2010). Evaluation of a Method for Proactively Managing
the Evolving Scope of a Software Product Line. In R. Wieringa & A. Persson, 16th
International Working Conference on Requirements Engineering: Foundation for
Software Quality, 6182, (pp. 113-127). Berlin, Germany: Springer-Verlag.
doi:10.1007/978-3-642-14192-8_13
Xiao, Q. (2007). Technology review - Biometrics-Technology, Application, Challenge, and
Computational Intelligence Solutions. IEEE Computational Intelligence Magazine,
2(2), 5–25. doi:10.1109/MCI.2007.353415
Appendix
Identification
AN
AN
AN
AN
AN
AN
POI
BI
TP
TR
AAI
Characterization: BI (Business Impact), TP (Technical Penalty), TR (Technical Risk)
Prioritization: POI (Potential Occurrence Indicator), AAI (Anticipation Advantage Indicator), P (Priority)
Table 4: Characterization of adaptation needs
P