Group number: 1
Method engineering: Product Line Evolution Support at
Scoping-method (PLEvo-Scoping)
Angeliki Iliana Triantou
University of Utrecht, Utrecht
a.i.triantou@students.uu.nl
Notice of Originality
I declare that this paper is my own work and that information derived from published
or unpublished work of others has been acknowledged in the text and has been
explicitly referred to in the list of references. All citations are in the text between
quotation marks (“ ”). I am fully aware that violation of these rules can have severe
consequences for my study at Utrecht University.
Signed:
Date:
Utrecht 2012
Name:
Place:
1. 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, 2000). Nowadays, Product line (PL) engineering is widely
used in software development industry (John &Villela, 2010) and there are many
companies which implement the Software Product line engineering (SPLE) principles.
In 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, p. 13),
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” and illustrated in the following table.
Preparation
for voluntary
analysis
Environment
change
anticipation
Change
impact
analysis
Product
evolution
planning
Table 1: Product Line Evolution at Scoping method
The first step’s (Preparation for Volatility analysis) main purpose 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. The
purpose 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.
2. 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) are depicted in tables to give a clear view of the
example.
2.1. Preparation for Volatility Analysis
In the first step the product manager has to estimate the lifespan of the product. The
product manager approximately identifies the product’s life expectancy, in 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. In Japan four big banks have already 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.
Some of these characteristics are illustrated in the Table 2 below.
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
2.2. Environment Change Anticipation
In this step 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 competitors that
sell similar 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
Table 3: Generic Facts
Facts
Need to have more safety transactions
Need to withdraw money in less time
Decision of bank to change the system
Biometric security systems
Adoption of a new technology
Innovate extremely new software product
2.3. Change Impact Analysis
This step identifies, characterizes and prioritizes the adaptation needs. In ATM’s
software product these needs could be mistakes or lacks in the programming code, or
new technology that has to be adapted 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: Map of adaptation needs (Appendix A)
2.4. Product Evolution Planning
The last step 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 are analyzed in tables
that are provided by the PLEvo-scoping method. In the ATM’s software product case
the Product Evolution Planning step is difficult illustrated in tables because of the lack
of real facts and features that could be analyzed and give an adequate solution.
3. 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)
(Weerd & Brinkkemper, 2009) 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 Prepare Volatility Analysis, the
Change Environmental Anticipation, the Change Impact Analysis and the Plan
Product Line Evolution. 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
(Prepare 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 papers that have written by Villela, et
al. (2008) and by Villela, Dörr and John (2010).
Figure 1: PDD of PLEvo Scoping method
Table 5: Activity Table
Activity
Sub-activity
Establish the
timeframe
Prepare Volatility
Analysis
Change
Environmental
Anticipation
Identify the
system
components
Identify
environmental
actors
Characterize
potential facts
Verify perspective
of new actors and
facts
Classify potential
facts
Identify
adaptation needs
Change Impact
Analysis
Characterize
adaptation needs
Prioritize
adaptation needs
Plan the PL
Evolution
Plan introduction
of adaptation
needs
Analyze
alternative
solutions
Select alternative
solution
Revise plan for
adaptation needs
Description
The product manager establishes the TIMEFRAME
that restricts the current VOLATILITY ANALYSIS. The
TIMEFRAME should not be longer than 10 years
(Villela et al., 2008).
The domain experts identify the types of SYSTEM
COMPOMENTS involved in the assembly of the
embedded system.
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.
The product manager identifies and characterizes
potential FACTS that may be caused by the identified
ACTORS.
The domain and market experts verify the
PERSPECTIVE of new ACTORS and characterize
how these ACTORS may cause environment changes.
The product manager prioritizes the potential FACTS,
according to their relevance, in order to decide whether
and when they should 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.
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.
The domain experts make the plan introduction of the
expected ADAPTATION NEEDS.
Domain experts analyze ALTERNATIVE SOLUTIONS
for dealing with relevant ADAPTATION NEEDS.
The product manager selects the best ALTERNATIVE
SOLUTIONS for dealing with the 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
TIMEFRAME
SYSTEM
COMPONENT
VOLATILITY
ANALYSIS
ACTOR
FACT
PRODUCT LINE
ENVIRONMENT
PERSPECTIVE
CLASSIFICATION
ADAPTATION
NEED
PRODUCT LINE
FEATURE
MAP OF
ADAPTATION
NEEDS
PRODUCT
EVOLUTION MAP
ALTERNATIVE
SOLUTION
Description
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 are 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 be 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 are 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 also based 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 maps adaptation needs to
product versions over time and 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
PRODUCT LINE
EVOLUTION MAP
strategy”. All the values of these attributes are defined by an ordinal scale
of five points (1 = low to 5 = high) (Villela et al., 2008).
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).
4. Related literature
Until 2008, many researchers had worked on the software evolution field. In 1999,
Bayer, Flege and Gacek published their work in which they evaluate traditional
software architecture with a context of PuLSE-DSSA software architecture (Product
Line Software Engineering - Domain-Specific Software Architecture), (Bayer, Flege,
Knauber, Laqua, Muthig, Schmid & Widen., 1999). 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
volatility requirements (Nurmuliani, Zowghi & Fowell, 2004).
In the following years many research were done, like the Buckey’s and Zenger’s
paper about a Taxonomy of Software Change in which the two authors focus more on
technical aspects and provide a framework of software changes (Buckley, Mens,
Zenger, Rashid & Kniesel, 2005). However, none of the existing research documents
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 et al.,
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 previous paragraphs. Except from the aforementioned authors' two
papers, there is not any other scientific work that is referred in this method.
Villela et al. (2008) first paper about PLEvo-scoping method provides the methods
description and a useful example of its use. The purpose of the paper that is written by
Villela et al. (2010) 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 feasible.
5. Conclusion
In this paper has presented the Product Line Evolution at Scoping method (PLEvoscoping method). PLEvo-scoping method is useful for the PL scoping team because
facilitating the team to identify the unstable PL features of the embedded system and
predict possible adaptation needs in the future. In order to further describe the method
a Process Deliverable Diagram (PDD) was drawn in figure 1. In this way, the step by
step identification of the method’s steps gives a clear and visible explanation of the
method’s deliverables.
6. 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,
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, 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). Heidelberg, Germany:
Springer.
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, Germany:
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). Heidelberg, Germany: Springer.
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). Australia, 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. Heidelberg, Germany: Springer.
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 (Eds.),
Lecture Notes in Computer Science: Vol. 6182. 16th International Working
Conference on Requirements Engineering: Foundation for Software Quality (pp. 113127). Heidelberg, Germany: Springer. doi:10.1007/978-3-642-14192-8_13
Weerd, I. van de, Brinkkemper, S. (2008). Meta-modeling for situational analysis and
design methods. In M.R. Syed and S.N. Syed (Eds.), Handbook of Research on
Modern Systems Analysis and Design Technologies and Applications (pp. 3858). Hershey: Idea Group Publishing.
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 A: template
The following table is the deliverable “map of adaptation needs” of the PLEvoscoping method. In the left part of this table illustrated the properties of the
classification concept (Potential Occurrence Indicator, Anticipation Advantage
Indicator), the properties of the adaptation need concept (Business Impact, Technical
Penalty, Technical Risk) and the priority for each adaptation need in an ordinal scale
of five points (1 = low to 5 = high).
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: Map of adaptation needs
P