Agile Product Line Engineering: The AgiFPL Method

Hassan Haidar

, Manuel Kolp

and Yves Wautelet

LouRIM-CEMIS, Université Catholique de Louvain, Belgium

KULeuven, Faculty of Economics and Business, Belgium

Keywords: Software Product Line Engineering, Agile Software Development, Agile Product Line Engineering, AgiFPL,

Scrum, Scrumban, Features.

Abstract: Integrating Agile Software Development (ASD) with Software Product Line Engineering (PLE) has resulted

in proposing Agile Product Line Engineering (APLE). The goal of combining both approaches is to overcome

the weaknesses of each other while maximizing their benefits. However, combining them represents a big

challenge in software engineering. Several methods have been proposed to provide a practical process for

applying APLE in organizations, but none covers all the required APLE features. This paper proposes an

APLE methodology called AgiFPL: Agile Framework for managing evolving PL with the intention to address

the deficiencies identified in current methods, while making use of their advantages.

1 INTRODUCTION

Over the past years, the software industry has been

searching for methods, processes and techniques to

increase the delivery of high quality software while

reducing development costs. Several paradigms have

been proposed in order to fulfil this target. “Agile

Software Development” (ASD) and “Product Line

Engineering” (PLE) are well-known approaches

proposed by researchers and practitioners for dealing

with the growing complexity of information systems

and handling competitive needs of the IT industry (da

Silva et al., 2011). The popularity of both approaches

and their positive results have motivated researchers

to find ways for integrating them (Farahani, 2014)

leading to “Agile Product Line Engineering”

(APLE).

The main goal of APLE is to maximize the benfits

of each individual approach and to fulfil their

common goals (Hanssen, 2011). Moreover, combi-

ning ASD and PLE presents a significant advantage

in terms of “synergy” in which, each approach

addresses the weaknesses of the other. But, among the

proposed APLE methodologies, only few have

proposed a specific process for this combined

approach, and can hence be actually referred truly to

as APLE methodologies (Asadi, and Ramsin, 2008).

After reviewing the literature on APLE and

anlysing, comparing and evaluating the relevant

APLE methodologies, each method can be considered

as presenting strengths and weaknesses. Furthermore,

the study of the existing APLE methods has revealed

that no single method covers all the needed APLE

features.

In this context, this paper proposes an APLE

methodology called AgiFPL (Agile Framework for

managing evolving SPL). The intention behind the

definition of this APLE method is to address the

deficiencies identified in current methods, while

making use of their advantages.

1.1 Research Method

In order to achieve our target we started by

identifying, studying and evaluating the relevant

APLE methodologies that exist in the literature.

(Díaz et al., 2011) and (da Silva et al., 2011) have

already surveyed several APLE methods in their

systematic literature reviews. (Farahani and Ramsin,

2014) have presented a recent study in which they

surveyed and analyzed APLE methodologies in a

more precise and systematic manner through using

“criteria-based evaluation”. Based on that, we made

an iterative evaluation of the methodologies based on

a “criterion set”. The results of the evaluation

performed in each iteration have allowed us to obtain

a deeper insight into the features of the

methodologies. The results are therefore used to

identify new criteria and thus enriching the criterion

set. Indeed, the results of this criteria-based

Haidar, H., Kolp, M. and Wautelet, Y.

Agile Product Line Engineering: The AgiFPL Method.

DOI: 10.5220/0006423902750285

In Proceedings of the 12th International Conference on Software Technologies (ICSOFT 2017), pages 275-285

ISBN: 978-989-758-262-2

275

evaluation have highlighted the strengths and

weaknesses of each methodology, have specified the

features expected of APLE methodologies, and have

identified the shortcomings of methodologies. Thus

these results could be used for improving current and

future APLE methodologies.

Secondly, we have studied and evaluate some

ASD methodologies such as, Scrum (Cohn, 2013),

XP, Scrumban (Ladas, 2009). We aim with this

evaluation to identify methods or reusable method

chunks that could help us to produce our intended

APLE. The results of this evaluation are used as a

basis for selecting and assembling reusable method

chunks, instantiating abstract process frameworks,

and extending existing methodologies in order to

define the bespoke APLE methodology.

Thirdly, after designing and defining the

proposed APLE we aim to validate it by establishing

an exhaustive case-study that shows the applicability

of the bespoke APLE. Due to lack of space, we only

present a short illustration in this paper.

1.2 Contributions

As said this paper is an effort to propose an adequate

APLE method that addresses the lacks and

deficiencies (see Section 4) of classical APLE

methods. For this purpose, we focus on the agile

methods Scrum (Cohn, 2013) and Scrumban (Ladas,

2009) as basis for AgiFPL as they adapt well to

software evolution and they are widely used by the

agile community. In addition, we focus on the

requirement engineering disciplines of I-Tropos

(Wautelet, 2008) (i.e. Organizational modeling and

Requirement Engineering) in order to define the RE

process of AgiFPL.

According to (Asadi et al., 2012) and (Hersari et

al, 2010) software development methodologies

consist of two integral parts: a “modeling language”

and a “process”. The modeling language part

provides the syntax and semantics used for expressing

the products, whereas the process prescribes the flow

of activities that should be performed and explains

how the products should be produced, enhanced and

exchanged along this flow. The agility feature of

APLE methods has deemphasized the role of

modeling, and hence the modeling language. In the

proposed APLE, we presented an adequate

Requirement Engineering (RE) process for both

Domain Engineering (DE) and Application

Engineering (AE). The proposed RE process of

AgiFPL make a trade-off between the requested RE

elicitation and the agility feature. The target of this

RE process is to introduce a suitable reuse strategy

and reduce the upfront design during the AgiFPL

development process. Moreover, for the process part

AgiFPL integrates Scrumban for the DE and Scrum

for the AE.

The paper is structured as follows. Sections 2 and

3 overview PLE and ASD. Section 4 highlights the

nowadays context of APLE. Section 5 presents our

AgiFPL framework. Section 6 introduces an

illustration with part of case study. Finally we

conclude the paper in Section 7.

2 PRODUCT LINE

ENGINEERING

Software Product Line Engineering or Product Line

Engineering (SPLE or PLE) provides an efficient way

to build and maintain portfolios of systems that share

common features and capabilities.

There are two essential phases to develop SPLs:

Domain Engineering (DE) and Application

Engineering (AE) (Pohl et al., 2005).

DE is the phase of creating a set of reusable assets

for building systems in a specific problem domain

(Díaz et al., 2011). It determines the scope and

handles the commonalities and the variability, i.e.

defines the core-assets, points of variations, and

expected variants for all the products of the PL (Kang

et al., 2010). DE is summarized in the following set

of activities or practices (O’Leary et al., 2009):

1. Domain Identification and Scoping;

2. Requirements Engineering;

3. Feature Modelling;

4. Architecture Design;

5. Core-Assets Development;

6. Traceability Management;

7. Evolution and Maintenance.

The AE phase consists of developing products

through systematic reuse of core-assets by deriving

the PL variability points, i.e. reusable assets are

extended from variability points with the selected

variants for a specific product (Clements and

Northrop, 2001 ; Pohl et al., 2005). AE is summarized

in the following set of activities and practices (Díaz

et al., 2011):

1. Release Planning (plan for product

applications);

2. Product Configuration (model application,

architecture application, platform

application);

3. Product Development;

4. Test, Integration and Deployment;

ICSOFT 2017 - 12th International Conference on Software Technologies

276

5. Traceability Management;

6. Evolution and Maintenance.

Figure 1 shows a framework for PLE, which

divides the product line into DE and AE.

Figure 1: The Software Product Line Engineering

framework (Pohl et al., 2005).

3 AGILE DEVELOPMENT

Agility is an umbrella term for a variety of agile

methods that are based on the Agile Manifesto (Shore

and Warden, 2007) principles and values. Agile

Software Development (ASD) is an approach that is

intended to enable rapid and flexible development of

small-scale software solutions from scratch, usually

addressing a single, well-defined customer

(Sommerville, 2011). Documentation, including

plans, is kept at a minimum, and work is organized in

short iterations developing the software product in

increments, which is continuously tested in

collaboration with customers and potentially

refactored (See Figure 2).

Figure 2: Basic ASD process (Shore and Warden, 2007).

External stakeholders such as clients and third-

party actors participate in nearly the whole period of

a development project (Larman, 2003).

All these methods, such as Scrum, XP, and

Scrumban implement iterative incremental life

cycles, share common values, and principles with

each one of them defining their own practices. We

only focus in on Scrum and Scrumban since we will

use them in the design of AgiFPL.

3.1 Scrum

In Scrum, projects move forward through aggressive

deadlines via a series of iterations called sprints to

implement dynamic requirements pulled from a

backlog. Each sprint is typically two to four weeks

long, at the end of which, the performed work should

create something of tangible value to the stakeholders

(Chon, 2013; Kenneth, 2013). Each sprint has a

sprint-planning meeting at the sprint beginning in

which the Product Owner and Team plan together

about what to be done for the sprint. The result is the

sprint backlog, a list of User Stories and tasks that

must be performed to achieve the sprint goal.

3.2 Scrumban

Scrumban proposes a transition method for moving

software development teams from Scrum to a more

evolved development framework. Since the

introduction of Scrumban, organizations have layered

the Kanban Method alongside Scrum to help them

achieve several different kinds of outcomes (Ladas,

2009 ; Reddy, 2016).

4 AGILE PRODUCT LINE

ENGINEERING

There has been growing interest in whether the

integration of Agile and PL could provide further

benefits and solve many of the outstanding issues

surrounding software development (da Silva et al.,

2011).

The following methods are proposed as APLE

methods and are considered as relevant:

− Component-Driven Development (CDD) –

(Ramsin and Paige, 2008 ; Wang, 2005);

− Extend FAP – (de Souza and Vilain, 2013);

− RiSE Process for Product Line Engineering

(RiPLE-SC) – (Balbino et al., 2011);

− A-Pro-PD – (O'Leary et al., 2010);

Agile Product Line Engineering: The AgiFPL Method

277

− Tailoring the Scrum Development Process

to Address APLE – (Díaz Fernández et al.

2011);

− An Iterative Model for Agile Product Line

Engineering – (Ghanam and Maurer, 2008);

− Extreme Product Line Engineering –

(Ghanam and Maurer, 2009);

− Agile Approach for Software Product Lines

Scoping – (da Silva, 2012);

− Agile PuLSE-I – (Carbon et al., 2006);

− Agile product line planning – (Noor et al.,

2008);

− Reactive Variability Management in Agile

Software Development – (Ghanam et al.,

2010).

The main shortcomings (deficiencies) (Farahani,

2014) of these methodologies concern the following

groups of criteria:

1. General criteria (e.g. modelling language,

the process);

2. Criteria related to the characteristics of

agile methods (teams, flexibility, leanness

etc.);

3. Criteria related to the PL characteristics

(DE activities, AE activities, core assets,

scope, features, etc.);

4. Criteria related to the common goals of

agile and PL (on-time software delivery,

software quality, HR management,

management of changes in requirements,

etc.);

5. Criteria related to issues arising due to the

combination of the two approaches (Reuse

approach, basis of the methodology, etc.).

Reviewing the existent APLE methodologies

shows the need of a new approach that cover all the

following APLE characteristics (Díaz et al., 2011;

Farahani and Ramsin, 2014):

7. Full coverage of the generic software

development lifecycle;

8. Comprehensive and precise definition of

the methodology;

9. Sufficient attention to the non-SDLC

activities (umbrella activities);

10. Prescription of a specific modeling

language;

11. Provision of model examples;

12. Attention to learning at project and

portfolio levels;

13. Attention to active user involvement;

14. Management of expected and unexpected

changes.

5 OUR AGIFPL FRAMEWORK

The intention behind our AgiFLP framework is to

develop a proper APLE methodology which

combines agility with PLE effectively, and embodies

the advantages of both approaches.

This section presents how our APLE is tackled by

means of a tailored Scrum, and Scrumban in which

the DE and AE processes are performed in an iterative

and incremental way. To overcome the PL-

architecture challenge and reducing the upfront

design, it is necessary to define the mechanisms and

strategies to be applied during the APLE development

process. This is why our contribution is based on two

main aspects: requirement engineering (RE) and

development process. In fact, using a goal-oriented

requirement engineering approach (GORE) such as

i*, will provide the mechanism to easily evolve PL-

architectures in an agile context and will establish a

suitable reuse strategy. Furthermore, adopting

Scrumban and Scrum for the development processes

in DE and AE will establish the agility of our method.

AgiFPL is thus an agile methodology designed to

improve the agility within the PLE and to meet

effectively any new emerged business expectations.

The main goal of AgiFPL is to move teams from the

classical approach to a more evolved APLE

framework.

In addition, the proposed approach adopts

forecasting and metric models and some project

management practices in order to address some

management issues.

In other words, on the one hand, for the DE stage,

AgiFPL implement an iterative process that uses i*

approach with Scrumban. On the other hand, for the

AE stage, AgiFPL implement also an iterative

process that use the Scrum approach with i*.

AgiFPL is a two a tier framework where the first

layer modelled in Figure 3, is dedicated to the

Domain Engineering (DE) and the second one,

modelled in Figure 4, is dedicated to the Application

Engineering (AE). Moreover, the framework

considers two spaces i.e. Problem Space and Solution

Space. Note, that each process of AgiFPL is based on

an iterative and incremental development.

ICSOFT 2017 - 12th International Conference on Software Technologies

278

Figure 3: Domain engineering (DE) process according to AgiFPL.

Agile Product Line Engineering: The AgiFPL Method

279

5.1 De Tier

The DE tier is detailed in Figure 3. First, the “Software

Vendor” has a business strategy for the domain. This

strategy is built from market trends, potential

investment opportunities and core-business

improvements. The domain strategy constitutes the

main base to define the scope of the domain and start

the phase of “Domain requirement engineering”

(DRE).

The strategy pushes to start the DRE phase, first

step in the problem space. DRE is a sub-process that

aims to understand the problem space by studying the

settings of the organizations related to the domain.

Roles involved in this sub-process are “Domain

Experts”, “Domain Sensei” and “Development Team”.

During this sub-process, the people involved model the

target domain in terms of social actors and their

intentions. In addition, when the “Software Vendor”

adopts a new or modified strategy, the “Domain

Experts” pull this strategy and upgrade the “Domain

Requirements”.

After receiving all the documentations and models

delivered at the end of the DRE phase, the “Domain

Design” (DD) phase starts. The DD phase takes the

reference RE models as input and creates a reference

architecture for the product line’s platform, which

gathers the common assets. At this phase, the scope of

the domain and the architectures have to be

determined, i.e., decide which products should be

covered by the product line and, consequently, which

features are relevant and should be implemented as

reusable artefacts. The DD phase contains two primary

tasks: domain scoping and domain modelling.

Once commonalities and variabilities are

identified and feature models are generated at the DD

phase, “Domain Experts” defines the “Features

Backlog” (FB). During this phase, the persons

involved document features in “User Stories” (US)

format (Cohn, 2004). At this stage, stories contain

rough estimates of both business value and

development effort. At the end of this stage, the

“Domain Experts” build a “Selected Backlog” (SB)

with defined capacity from the FB. The SB represents

a list of work the “Development Team” must address

next. It has a defined capacity limit. As soon as

capacity is available, it is filled up with user

stories/features from the top of the FB.

After building the SB, the “Domain Experts” and

“Development Team” hold the “Planning 1” meeting

in order to shape stories and estimate “Cycle Time”.

“Planning 1” is considered as the “WHAT”:

Whenever the “Domain Experts” pulls new user

stories into the SB. After this, the “Development

Team” should understand the different features.

Therefore, the team is able to estimate the complexity

of each user story.

Once “Planning 1” takes place, the “Development

Team” structures the “Stories in Progress Backlog”

(SIP Backlog) with defined capacity (K[n]). The SIP

Backlog is a list of user stories, which the

development team currently addresses. Team

members pull user stories from the selected backlog

when there are no more remaining tasks in the task

backlog.

After structuring the SIP Backlog, the “Domain

Sensei” and “Development Team” hold the

“Planning 2” meeting. With “Planning 2” starts the

“Domain Implementation or Production of Common

Assets” phase. The “Planning 2” is considered as the

“HOW”: Whenever team members pull new user

stories into the production flow. During the “Planning

2” meeting, the team establish the “Production

Flow” consisting of the following components:

1. Task Backlog;

Task in Progress with defined capacity (max

k[6]). Once the “Task in Progress” is done,

team members pull tasks from “Task

Backlog”.

3. Task Done with “Parking Lot”. Once the

story is completed (Story complete?)

“Development Team” members pull user

stories from the “SIP Backlog”.

4. Story Testing with defined capacity (max

k[2]);

5. Stories Done;

During the “Production Flow”, the “Domain

Sensei” and “Development Team” hold a “Daily”

meeting, which is a short, time-boxed meeting, taking

place every day at the same time.

Whenever the team ships an increment

(Increment Ready?), the “Domain Experts”, “Domain

Sensei” and “Development Team” hold a “Review”

meeting in order to review the work accomplished.

The team uses this meeting to present and review the

work it has completed since the last delivery. Usually,

it also includes a demonstration of the features

created during the latest increment or iteration. Once

the features are implemented as reusable artefacts

(Models, Source Codes,…), these are placed in the

“Common Assets Warehouse”.

After any “Review”, the “Scrumban Sensei”

holds the “Retrospective” meeting to reflect on the

past production cycle in order to ensure continuous

process improvements. The “Domain Sensei” always

asks two questions in the retrospective:

1. What went well during the last cycle?

2. What should improve in the next cycle

ICSOFT 2017 - 12th International Conference on Software Technologies

280

Figure 4: Application engineering (AE) process according to AgiFPL.

Agile Product Line Engineering: The AgiFPL Method

281

During the “Production Flow”, whenever a

problem occurs, the “Domain Sensei” organizes an

“Andon” meeting whenever problems in the

production flow occur.

5.2 AE Tier

The AE tier, represented in Figure 4 includes several

product lines where the outputs are client applications

(products). At this stage, “App i Owners” and “App i

Stakeholders” are more involved in the development

process.

Hereafter, we describe the AgiFPL proposition

for the “Line i” which deliver at the end the “App i”.

In fact, AgiFPL propose a simple agile. Each line of

the AE tier will follow this process.

First, an “App i Owner” comes with an idea of

what he/she wants to create. The App Line process

starts and lunches the “App i Requirement

Engineering” (ARE i) phase. This phase has two main

missions:

1. The “App i Owner”, “App i Stakeholders”,

“Line i Master”, and “Development Team i”

study the “Organization i” in order to

understand the motivations and rationales that

underline the “App i” requirements.

2. The “App i Owner” idea could be large,

therefore, through an activity called

“Grooming”; it is broken down into a set of

features that are collected into a prioritized list

called the “App backlog”.

The requirement assets produced in “Domain

Engineering” constitute some basis, but they will not

satisfy all “App Owners” and “App Stakeholders”

requirements. The gap between what is available and

what is required must be analysed, and a trade-off

decision has to be taken for each unsatisfied

requirement. At the end of the ARE phase two types

of features coexist:

1. Features that exist and could be selected from

the “Common Assets Warehouse”. The set of

these is called “Selection of Features” (SoF).

2. Features that are required for the development

of the application and does not exist in the

“Common Assets Warehouse”. Since these

features are defined during the ARE phase, the

set of these is called “Definition of Features”

(DoF).

Consequently, the building of the “App backlog” is

finished and it contain an ordered list of documented

US that the team maintains for an “App”. Note that

all new reusable artefacts issued from the AE process

have to be classified in the “Common Assets

Warehouse”.

Once the “App backlog” is finished, the work is

performed in “Sprints” up to a calendar month. The

work completed in each sprint should create

something of tangible value to the customer or user.

The “Sprint” starts with the “Sprint Planning”

(WHAT? And HOW?). The “App i Owner”, “Line i

Master” and “Team Development i” perform the

“Sprint Planning” in order to determine the most

important subset of “App backlog” items to build in

the next sprint. During the sprint planning, the “App

i Owner” and “Development team i” agree on a sprint

goal that defines what the upcoming sprint is

supposed to achieve.

At the end of the “Sprint Planning”, the “Sprint

Backlog” is defined and the “Definition of Done”

(DoD) list is established. In fact, DoD is a checklist

of activities required to declare the implementation of

a story to be completed.

Once the concerned people consider the “Sprint

Planning” as finished and agree on the content of the

next sprint, the “Development Team i”, guided by the

“Line i Master” coaching, performs all the task-level

work necessary to get the tasks done. This step is

called “Sprint Execution”.

Every day during the sprint, ideally at the same

time, the “Development Team i” members hold a

time-boxed “Daily” meeting. This “inspect-and-

adapt” activity is sometimes referred as the daily

stand-up.

The “Sprint” results are considered as a

“Potentially shippable App increment”, meaning that

whatever the “Development Team i” has agreed to do

is really done according to its agreed-upon definition

of done.

At the end of the “Sprint”, there are two additional

“inspect-and-adapt” activities:

1. “Sprint Review”: The goal of this activity is to

inspect and adapt the product that is being built.

Critical to this activity is the conversation that

takes place among its participants. The

conversation is focused on reviewing the just-

completed features in the context of the overall

development effort.

2. “Sprint Retrospective”: This activity

frequently occurs after the sprint review and

before the next sprint planning. Whereas the

sprint review is a time to inspect and adapt the

product, the sprint retrospective is an

opportunity to inspect and adapt the process.

Once the “Sprint Retrospective” is completed, the

whole cycle is repeated again — starting with the next

sprint-planning session, held to determine the current

highest value set of work for the team to focus on. At

the end of the “Sprint” the “Line i Master”,

ICSOFT 2017 - 12th International Conference on Software Technologies

282

“Development Team i”, and “App i Owner” perform

a “Backlog refinement”: (max. 60 min) used to

introduce and estimate new backlog items and to

refine existing estimations as well as acceptance

criteria. It is also used to break large stories into

smaller ones.

After an appropriate number of sprints have been

completed, the “App i Owner’s” vision will be

realized and the solution can be released.

6 ILLUSTRATION

In order to validate our proposed APLE method, we

suggest introducing briefly a case study based on the

Odoo open source ERP platform (Odoo Inc., 2017).

In fact, Odoo offers an All-in-one ERP management

software which fits small and medium companies and

our APLE method (AgiFPL) could be applied within

Odoo.

Due to lack of space, we only present a simple

example concerning “NST Shipping” which is a

maritime transporter that Odoo to implement their

cross functional business processes. In the requested

ERP, several modules and application are needed for

supporting NST activities, e.g. “Invoicing

Application” and “eTracking service”.

Odoo has an initial huge “Common Assets

Warehouse”. Among the reusable artefacts of Odoo

we found the “Invoicing Module”. Therefore, several

modules of NST ERP would be found in Odoo’s

common assets warehouse.

Once NST signs the contract of the NST ERP

implementation with Odoo, the Odoo “Line Team”

will proceed following the AE phase of AgiFPL.

Based on the results of the “ARE step” and “NST App

Backlog” the “Line Team” will recognize that the

requested “eTracking service” does not exist in the

“Common assets Warehouse” and there are no similar

artefact among the reusable ones. Therefore, the

“Line Team” will start the process of developing this

service. In other words, the team will transform the

related requirement model (See Figure 5) into a

feature model and then into USs and organize these

USs in the App Backlog. Then they will follow the

process until delivering the final version of the NST

ERP.

Following AgiFPL method, this “Goal Model” of the

eTracking service will be transformed into a feature

model (FM). Figure 6 shows the FM for the

eTracking service” module.

As said above, this FM for “eTracking Service”

will be transformed to USs in order to define the “App

Backlog”. According to the “Planning” the

development of this App will take a “Sprint” of 2

weeks. Table 1 shows the “Sprint” plan.

At the end of the sprint the final version of the

“eTracking service App” will be integrated to the

NST ERP. In addition, all reusable artefacts generated

from this step will be stocked on the “Common assets

warehouse”.

7 CONCLUSIONS

As mentioned in this paper, our contribution is to

propose a new proper APLE approach that addresses

the deficiences identified in current APLE methods,

while making use of their benefits. The proposed

APLE approach is called AgiFPL (Agile Framework

for managing evolving PL).

In order to design this APLE approach we have

reviewed the most relevant APLE approaches from

the literature. In addition, we present as an illustration

part of a case study in order to show how we intend

to validate our approach.

Further work undergoing to complete AgiFPL

approach. For instance, we are working on adopting

and developing metrics for performance.

Furthermore, we are developing tools that will

facilitate the implementation of AgiFPL. Also, we try

to simplify the RE processes by adopting adequate

frameworks that fit the agility of our proposal.

Table 1: Sprint plan.

Week 1

One of the first

days

Meeting with NST

stakeholder

Sprint post-mortem

1 Monday Technical meeting

Development sprint

kickoff

2 Tuesday

Development

3 Wednesday

4 Thursday

5 Friday

Week 2

1 Monday

2 Tuesday

3 Wednesday Internal demo

Sprint “planning 2” and

review meeting

4 Thursday Fix change requests

5 Friday Retrospective

Project Status Meeting

Agile Product Line Engineering: The AgiFPL Method

283

Figure 5: Goal Model (i* SR model) for eTracking service.

Figure 6: Feature Model for eTracking Service.

REFERENCES

Asadi, M., Bagheri, E., Mohabbati, B., and Gašević, D.

(2012). Requirements Engineering In Feature Oriented

Software Product Lines: An Initial Analytical Study. In:

Proc. SPLC ‘12, 2, pp. 36-44.

Balbino, M., de Almeida, E. S., and de Lemos Meira, S. R.

(2011). An Agile Scoping Process for Software Product

Lines. In: Proceedings of International Conference

SEKE2013, Miami (USA) pp. 717–722.

Carbon, R., Lindvall, M., Muthig, D., and Costa, P. (2006).

Integrating Product Line Engineering and Agile

Methods: Flexible Design Up-front vs. Incremental

ICSOFT 2017 - 12th International Conference on Software Technologies

284

Design. In: Proc. of International Workshop on Agile

Product Line Engineering collocated with International

Software Product Line Conference, pp. 1–8.

Cohn, M. (2013). Succeeding with Agile: Software

Development Using Scrum. 1st ed. Upper Saddle River,

NJ: Addison-Wesley Professional.

da Silva, I. F., Neto, P., O'Leary, P., de Almeida, E., and de

Lemos Meira, S.R. (2011). Agile Software product

lines: a systematic mapping study. Software: Practice

and Experience, 41(8) 2011, pp. 899–920.

da Silva, I. F. (2012). An Agile Approach for Software

Product Lines Scoping. In: Proceedings of

International Software Product Line Conference,

SPLC2012, Salvador, Brazil pp. 225–228.

de Souza, D. S., and Vilain, P. (2013). Selecting Agile

Practices for Developing Software Product Lines. In:

Proceedings of International Conference SEKE2013,

Boston (USA) pp. 220–225.

Díaz, J., Pérez, J., Alarcón, P. P., and Garbajosa, J. (2011).

Agile product line engineering—A systematic literature

review. Software: Practice and Experience, 41(8), pp.

921–941.

Díaz Fernández, J., Pérez Benedí, J., Yagüe Panadero, A.,

and Garbajosa Sopeña, J. (2011). Tailoring the Scrum

Development Process to Address Agile Product Line

Engineering. In: Proceedings of JISBD2011, Spain:

Coruña.

Farahani, F. F., and Ramsin, R. (2014). Methodologies for

Agile Product Line Engineering: A Survey and

Evaluation. In: Proceedings of the 13th International

Conference SoMeT_14, Amsterdam: IOS Press BV, pp.

545-564.

Ghanam, Y. and Maurer, F. (2008). An Iterative Model for

Agile Product Line Engineering. In: Proceedings of the

12th SPLC2008, Ireland: Limerick, pp. 377–384.

Ghanam, Y., and Maurer, F. (2009). Extreme Product Line

Engineering: Managing Variability and Traceability via

Executable Specifications. In: Proceedings of Agile

Conference, AGILE '09, IEEE Computer Society, USA:

Washington DC, pp. 41–48.

Ghanam, Y., Andreychuk, D., and Maurer, F. (2010).

Reactive Variability Management in Agile Software

Development. In: Proceedings of Agile Conference,

AGILE '10, Portugal: Guimarães, pp. 27–34.

Hanssen, G. K. (2011). Agile software product line

engineering: enabling factors. Software: Practice and

Experience, 41(8), pp. 883–897.

Hanssen, G. K., and Fægri, T. E. (2008). Process fusion: An

industrial case study on agile software product line

engineering. Journal of Systems and Software, 81(6),

pp. 843–854.

Kenneth, S. R. (2013). Essential Scrum: A Practical Guide

to the Most Popular Agile Process. Upper Saddle River,

NJ: Addison-Wesley Professional.

Kolp, M., and Mylopoulos, J. (2001). Software

architectures as organizational structures. In: Proc.

ASERC Workshop on” The Role of Software

Architectures in the Construction, Evolution, and Reuse

of Software Systems”, Edmonton, Canada.

Kolp, M., Giorgini, P., and Mylopoulos, J. (2002).

Organizational multi-agent architectures: a mobile

robot example. In: Proceedings of the first international

joint conference on Autonomous agents and multiagent

systems: part 1, pp. 94-95.

Ladas, C. (2009). Scrumban - Essays on Kanban Systems

for Lean Software Development. 1st ed. Seattle, WA:

Modus Cooperandi Press.

Larman, C. (2003). Agile and Iterative Development—A

Manager’s Guide (Agile Software Development

Series), Cockburn A, Highsmith JJ (eds). New Jersey:

Addison-Wesley.

Mohan, K., Ramesh, B., and Sugumaran, V. (2010).

Integrating Software Product Line Engineering and

Agile Development. IEEE Computer Society, 27, pp.

48-55.

Mylopoulos, J., Kolp, M., and Giorgini, P., (2002). Agent-

oriented software development. In: Hellenic

Conference on Artificial Intelligence, pp. 3-17.

Noor, M. A., Rabiser, R., and Grünbacher, P. (2008). Agile

product line planning: A collaborative approach and a

case study. Journal of Systems and Software, 81(6), pp.

868–882.

O'Leary, P., McCaffery, F., Thiel, S., and Richardson, I.

(2010). An Agile process model for product derivation

in software product line engineering. Journal of

Software: Evolution and Process, 24(1) 2012, pp. 561-

571.

Pohl, K., Böckle, G., and van der Linden, F.J. (2005).

Software Product Line Engineering: Foundations,

Principles and Techniques. Berlin: Springer-Verlag,

pp. 3-88.

Ramsin, R., and Paige, R. F. (2008). Process-centered

Review of Object Oriented Software Development

Methodologies. ACM Computing Surveys, 40(1), pp.

3:1–3:89.

Reddy, A. (2016). The Scrumban [r]evolution: getting the

most out of Agile, Scrum, and Lean Kanban. 1st ed.

New York: Addison-Wesley Professional.

Sommerville, I. (2011). Software Engineering. 9th ed.

Boston: Addison-Wesley.

van der Linden, F., Schmid, K., and Rommes, E. (2007).

Software Product lines in Action: The Best Industrial

Practice in Product Line Engineering. Berlin: Springer-

Verlag.

Agile Product Line Engineering: The AgiFPL Method

285