Adopting Agile methodology

for Product Line Engeerning

Presented by: Muhammad Shafiq

Supervised by: Dr yasir Hafeez

2 Contents
 Introduction
 Challenges
 Review of Literature
 Problem Statement
 Research Methodology
 Proposed Framework
 Phases Of Proposed Frame work
 Framework Evaluation
 Case studies Implemented On Proposed Framework
 Result Of Proposed Framework
 Conclusion
3 AGILE SOFTWARE DEVELOPMENT (ASD)
 Agile is an iterative, team-based approach [1]. It uses complete
functional components [2] and is “time-boxed” methodology [1,2].
 Customer collaboration.
 Responding to changes over following a plan.
 Short iterations (sprints).
 Highest priority is to satisfy the customer.
 Welcome the new changes.

 Agile software development include different light weight

methodologies, as mentioned below [2]:
 Lean Software Development
 Scrum
 Test Driven Development
 Extreme Programming
[1]Product Line Engineering in Large-Scale Lean and Agile Software Product Development Environments
Towards a Hybrid Approach to Decentral Control and Managed Reuse

[2] Joe Farah, CM: THE NEXT GENERATION – Agile Configuartion Management, Configuration Management Journal, Vol.5 No.4, April 2013.

[3] Thomas Stober Uwe Hansmann, ― Agile Software Development Best Practices for Large Software Development Projects:, ‖ Springer, no. 4, pp. 35-48, 2014.
4 SOFTWARE PRODUCT LINE (SPL)
 The concept of software reuse has always been a dream in the software industry, in order to

increase the productivity and reduced costs and time to enhancing quality .

 SPLE is further divided into two parts:

 Domain Engineering (DE) – refer to the commonality and the variability of the product line are
defined and realised. [1]

 Application Engineering (AE) refer to the applications of the product line are built by reusing
domain artefacts and exploiting the product line variability by a systematic way .[1].

[1] Frank van der Linden, Klaus Schmid, Eelco Rommes, ― Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering, || Springer
Berlin, pp. 3-9, 2007
5 Product Line Engineering

Software product line engineering is a approach to developing

software.
 Lower costs
 Shorter time-to-market.
 Higher quality requirements.
 It impact the business, organization and technology
 Same time delivering high-quality software.
6 Commonalities b/w SPLE and AMs
These approaches share some common goals:
 Increasing the productivity of the development teams

 Reducing the product's time to market;

 Reducing development costs.

 Improving customer satisfaction.

7 Benefits of Product Line Engineering

 Improved product performance

 Decreased product risk

 Increased market agility

 More efficient use of human resources

8 Software Product Line

 SPLE involves three major activities

 Core Asset Development

 Product Development

 Management
9 Major Activities of SPL

 Core Asset Development :- is responsible to the creation of the common assets of the
SPL and the evolution of the assets in response to product feedback.

 Product development :- creates individual products by reusing the core assets, gives
feedback to core asset development, and create the new products.

 Management:- includes technical and organizational management, where technical

management is responsible for the requirements control and the coordination between core
asset and product development.
10 Challenges in SPLE
There are four challenges in SPLE are given below:

 Lack of customer feedback .

 Heavy, top-down development process.

 Inefficient use of engineering resources.

 Low engagement of team members.

11 Literature Review
12 LITERATURE Review
Title Approach/
Paper Year & Author Weakness
Methodology
Knieke, C., Körner, M and A Holistic Approach The industrial case The approach improves
Rausch, A 2017. for Managed study the reusability but
Evolution of unable to manage
Automotive Software
variability and
Product Line
changing needs of the
, customers.

Bottom-up modeling Case Study Product Line Engineering is

for a software product non iterative. Which means
2014, Pietu
Pohjalainen line An experience it can not support
report on agile changing b/w
modeling of development
governmental mobile
networks.
 LITERATURE
13 Title Approach/
Paper Year & Author Weakness
Methodology
Hetrick et al. 2014 A Light weight presented their Technical issues
Software Product experience of (e.g. Core assets,
Line Development transitioning to quality assurance)
Process for Small software product Non- technical
and Medium Size lines. issues (e.g. team
Projects organization,
processes).

Hohl, P, Ghofrani, & Searching for Case Study by using Variability can not
Schneider K. 2017. Common Ground: both quantitative be handled
Existing Literature on and qualitative
Automotive Agile So analysis.
ware Product Lines.
14 LITERATURE
Title Approach/
Paper Year & Author Weakness
Methodology
Wood 2014 Using a multi-method one experimental The weaknesses
approach to study on a topic, factors are
understand Agile Multimethod 1- SPL Scalability,
software product 2- inadequate
lines technology transfer
strategy,
3- lack of company
commitment
 15 PROBLEM STATEMENT
 Adoption of agile method can be beneficial when combine with SPL. There

are few studies which show that adoption of agile with Software product line

have few challenges such as integration of Agile with SPL, Commonalities

and Variability Issues during product development. Hence required a

comprehensive framework in order to fulfill the above mention challenges

Knieke, C., Körner, M., Rausch, A., Schindler, M., Strasser, A., & Vogel, M. (2017). A Holistic Approach for Managed Evolution of Automotive Software Product Line
Architectures. Special Track: Managed Adaptive Automotive Product Line Development (MAAPL) along with ADAPTIVE.
Hohl, P., Ghofrani, J., Münch, J., Stupperich, M., & Schneider, K. (2017). Searching for Common Ground: Existing Literature on Automotive Agile So
ware Product Lines.
Díaz, J., J. Pérez, and J. Garbajosa. 2014. Agile product-line architecting in practice: A case study in smart grids. Information and Software
Technology, 56(7), pp: 727-748.
 Steps of Methodology

16
Methodology Step 1
Literature Review
Step 2
Data Collection
Step 3
Design and conduct Analysis
Step 4
Formulization of Approach
Step 5
Case Study Selection for Empirical
Evaluation
Step 6
Recommendation and
implementation

Step 7
Results
 PROPOSED APPROACH
17

 The main propose of this research is to present an innovative approach

based on Agile Product line development.

 This new approach will handle and overcome issues related to standalone

agile and product line. i.e.

 Commonalities and Variability

 Managing the changing needs of the stakeholders.
 Top down Change Management
Framework
18
19 Evaluation
Evaluation Through case study
 To validate our framework we selects a company operating in agile
PLE environment.
 Framework was tested in undergoing projects of PLE in real world
environment.
 The general objective that guided our case study was to justify the
use of Agile Method in SPL scoping and Change the needs of the
stockholders phases by characterizing them in term of possible
weakness.
20 Case Study

The case study was conducted in organization which is named as 7

Technology.

Company Information
 The company is using software Agile product line development
approach for designing web base projects by using existing data and
previously used core assets.
21 Seven technology demographic :

 More than 150 employ working in seven technology; twenty participants were selected based on
the different roles and profiles involved in the SPL project.
Team members and roles:
 The developers selected :
 Domain expert (from the company),
 Agile Coach from the ASD)
 A scoping expert (from the SPL team)
 A domain analyst (Company)
 An architect (company)
 Developers (SPL team),
 Risk manager (SPL team)
 Two requirement analysts (SPL team)
 As our case is small medium-sized company, the protocol developer assumed that a role could
be played by more than one engineer and the development team.
 Results of Case Study
22
PROJECT A : LMS system PROJECT B : E shopping system

Strongly Strongly Strongly Strongly

Agreed Neutral Disagreed Agreed Neutral Disagreed
Agreed Disagreed Agreed Disagreed

Understandable 30% 60% 8% 2% 0%

Understandable 30% 60% 8% 2% 0%

Less Complex 33% 59% 5% 3% 0%

Less Complex 33% 59% 5% 3% 0%
Easy To
44% 53% 2% 1% 0% Easy To Implement 44% 53% 2% 1% 0%
Implement

Time Complexity 25% 66% 7% 2% 0% Time Complexity 33% 59% 5% 3% 0%

Reduce Effort 36% 56% 6% 2% 0% Reduce Effort 44% 53% 2% 1% 0%

Change Change Management 33% 59% 5% 3% 0%

43% 54% 2% 1% 0%
Management
Inconsistency 44% 53% 2% 1% 0%
Inconsistency 44% 53% 2% 1% 0%
Ambiguity 54% 43% 2% 1% 0%
Ambiguity 54% 43% 2% 1% 0%
Incompleteness 33% 59% 5% 3% 0% Incompleteness 33% 59% 5% 3% 0%

Reusability 44% 53% 2% 1% 0% Reusability 44% 53% 2% 1% 0%

Domain
43% 54% 2% 1% 0%
Engineering Domain Engineering 43% 54% 2% 1% 0%

Risk
36% 56% 6% 2% 0%
Management Risk Management 33% 59% 5% 3% 0%

Technical
43% 54% 2% 1% 0%
Planning Technical Planning 44% 53% 2% 1% 0%
23 Graphically Results of Case Study
24 Comparative Analysis
 Comparative Analysis in which we compare and contrast two things: two texts,
two theories, two figures, two scientific processes.

 Now we compare the same parameters of the two projects A and B with two
methodologies APLM and Traditional method.
 Comparative Analysis
25 APLM METHOD TRADITIONAL METHOD
PARAMETERS
PROJECT A PROJECT B PROJECT A PROJECT B

Understandable 60% 60% 30% 30%

Less Complex 59% 59% 20% 20%

Easy To Implement 53% 53% 44% 44%

Time Complexity 66% 59% 25% 13%

Reduce Effort 56% 53% 36% 24%

Change Management 54% 59% 0% 0%

Inconsistency 53% 53% 12% 14%

Ambiguity 43% 43% 34% 34%

Incompleteness 59% 59% 33% 33%

Reusability 53% 53% 14% 10%

Domain Engineering 54% 54% 13% 18%

Risk Management 56% 59% 21% 31%

Technical Planning 54% 53% 21% 24%

26 Comparative Analysis
27 Expert review
28 Conclusion
 The findings on Agile SPL aim to increase the body of evidence about what
activities of Agile and SPL can be combined and how they can be
integrated.
 All the findings relate to the combination between Agile and SPL.
 In product line engineering the iterative and incremental development are
major aspects of software development.
 Now our proposed framework give the customer satisfaction, welcome to
the all changes which occur from the stakeholders, incremental
development, software components effective reuse and etc.
29

Thank You for Your Kind Attention...