.5
Xavier Franch
Group of Software and Service Engineering
Universitat Politècnica de Catalunya
Barcelona, Spain
franch@es...
Contents
• INTRODUCTION OF PARTICIPANTS
• PART I. BACKGROUND
• PART II. STATE OF THE ART
• PART III. THE EVOLVE APPROACH
•...
Contents
• INTRODUCTION OF PARTICIPANTS
• PART I. BACKGROUND
• PART II. STATE OF THE ART
• PART III. THE EVOLVE APPROACH
•...
Attendees
ICSE 2016, Austin, TX 6
Contents
• INTRODUCTION OF PARTICIPANTS
• PART I. BACKGROUND
• PART II. STATE OF THE ART
• PART III. THE EVOLVE APPROACH
•...
Context – Software Evolution
ICSE 2016, Austin, TX 8
Continuing Change — an [E-type] system must be continually
adapted or...
The planning onion
ICSE 2016, Austin, TX 9M. Cohn, Agile Estimating and Planning. Prentice Hall PTR, 2006.
Software release planning – definition
ICSE 2016, Austin, TX 10
Software release planning – “critical process of deciding ...
Example: SENERCON
ICSE 2016, Austin, TX 11
• Partner of the SUPERSEDE H2020 project
• Service provider for energy savings ...
Example: SENERCON
ICSE 2016, Austin, TX 12
• Main reasons:
– lack of detailed knowledge about QoE
• currently, email + hot...
What is a feature
ICSE 2016, Austin, TX 13
“A logical unit of behavior specified by a set of functional and
non-functional...
Typical features
ICSE 2016, Austin, TX 14
• Core functionality of the domain
– prime prerequisite for a company’s business...
Good and bad features
ICSE 2016, Austin, TX 15
Reasons for considering a feature as “good”:
• Customer satisfaction
• Dist...
Software release planning – A deeper view
ICSE 2016, Austin, TX 16
Amountofimplementedfunctionality
Amountofsuggestedfunct...
Software release planning – why?
ICSE 2016, Austin, TX 17
Release decisions
ICSE 2016, Austin, TX
Software release planning - Why difficult?
ICSE 2016, Austin, TX 19
Information is
 Uncertain
 Inconsistent
 Incomplete...
Main challenges in release planning
• Product management underestimated/not sufficiently established
• Product release pla...
Contents
• INTRODUCTION OF PARTICIPANTS
• PART I. BACKGROUND
• PART II. STATE OF THE ART
• PART III. THE EVOLVE APPROACH
•...
Approaches to Software Release Planning
Two main categories
• manual (“on-the-fly”) approaches
– rely on humans’ ability t...
On-the-fly approaches
ICSE 2016, Austin, TX 23
• emphasis on improving the decision process
– make estimates as accurate a...
Example: a case in Ericsson
V.T. Heikkilä et al. Continuous Release Planning in a Large-
Scale Scrum Development Organizat...
Team structure
ICSE 2016, Austin, TX 25
The release planning process
ICSE 2016, Austin, TX 26
Reported benefits
• Increased flexibility
– feature development schedule not tied to release schedule
– decreased developm...
Remaining challenges
• Misalignment with “the old way” of planning
– product manager still asking for long-term feature
de...
Limitations of on-the-fly approaches
• Informal process
• Informal decisions
• But: > 1.000.000.000.000 possibilities alre...
Analytical approaches
F = {f(1), ..., f(N)}
Set of features Set of constraints
X = {x(1), ..., x(N)}
Release plan
x(j) = a...
Analytical approaches
F = {f(1), ..., f(N)}
Set of features Set of constraints
X = {x(1), ..., x(N)}
Release plan
x(j) = a...
Example – release planning in agile projects
Approach Iterations Precedences Risk Change mgmt. Planning
[1] Multi Preced, ...
State of the art
Main source: systematic literature review until 2008
• 24 release planning models found
– 14 original and...
State of the art
Extension: ongoing non-systematic literature review until
2015 by the GESSI research group at UPC
• snowb...
New methods in a nutshell (sample)
ICSE 2016, Austin, TX 35
NRP for eXtreme Programming dealing with some uncertainty
Mult...
Input: constraints and factors
ICSE 2016, Austin, TX 36
Soft
factorsRisk factors Value factors
Resource consumption factor...
Input: constrains and factors (prevalence in 2010)
ICSE 2016, Austin, TX 37
Requirement dependencies (75%)
Quality constra...
Input: constrains and factors (prevalence in 2015)
ICSE 2016, Austin, TX 38
Requirement dependencies (75%)(75%)
Quality co...
Output
• Scope
– one release vs. multiple releases
• Object of planning
– features; user stories; requirements
• Prioritiz...
Objective function
• Optimization of the value given by the features while
managing the resources and fulfilling all possi...
A lot of computational approaches…
ICSE 2016, Austin, TX 41
Greedy
algorithms
Pareto opti-
mal fronts
Monte-Carlo
simulati...
Example – greedy solution (1)
• Principle: always add a feature to the solution that
maximizes value while not violating a...
Example – greedy solution (2)
• Input:
– Set of features, F = {f(1), …, f(N)}
– Resource consumption, cost: F  Integer
– ...
Example – greedy solution (3)
ICSE 2016, Austin, TX 44G. Ruhe. Product Release Planning, CRC Press 2010
Example – Multi-sprint planning in Scrum (1)
• Given a set S of m sprints and a set U of n user stories,
maximise a soluti...
Example – Multi-spring planning in Scrum (2)
Example of input:
ICSE 2016, Austin, TX 46
ID Name Deps. and
coupling
Utility...
Example – Multi-spring planning in Scrum (3)
• Objective function z:
– uj: utility of story j
– rj
cr: criticality risk of...
Example – Multi-spring planning in Scrum (4)
the sum of stories’ complexity
(considering uncertainty risks) fits
into each...
Summary: Analytical vs. on-the-fly planning
ICSE 2016, Austin, TX 49
Caracteristics Analytical methods On-the-fly
Time hor...
Summary
ICSE 2016, Austin, TX 50
• On-the-fly approaches criticised due to the difficulty
of taking into account all knowl...
Contents
• INTRODUCTION OF PARTICIPANTS
• PART I. BACKGROUND
• PART II. STATE OF THE ART
• PART III. THE EVOLVE APPROACH
•...
Release planning – Art or Science?
ICSE 2016, Austin, TX 52
• Art:
Focus on the human
intuition and
communication for
hand...
What’s the problem?
ICSE 2016, Austin, TX 53
“The mere formulation of a problem is far
more essential than its solution, w...
Optimized release planning – How it began
ICSE 2016, Austin, TX 54
EVOLVE: Greer, D. and Ruhe, G., Software Release Planni...
Optimized release planning – How it began
ICSE 2016, Austin, TX 55
F1(x) is a penalty function defined for plan x describi...
Empirical analysis
• EVOLVE was initially based on genetic search offered by
Palisade’s RiskOptimizer
• Early industrial f...
EVOLVE II: Three phases
• Phase 1 - Modeling:
– Formal description of the
(changing) real world to make it
suitable for co...
Evolution everywhere
• Evolutionary software development (iterative,
incremental)
• Evolutionary solution algorithms
• Evo...
The diversification principle
ICSE 2016, Austin, TX 59
A single solution
to a cognitive
complex problem
is less likely to
...
ICSE 2016, Austin, TX 60
Preparation
1
Planning criteria
weights
2
Pre-selection of
features
3
Prioritization of features
...
Criteria for feature selection
• Customer satisfaction
• Customer dissatisfaction
• Risk of implementation
• Risk of accep...
Feature dependencies
• For given features
A, B, and C, we
distinguish eight
types of
dependencies:
ICSE 2016, Austin, TX 62
Pre-assignment of features to releases
ICSE 2016, Austin, TX 63
Maximization of stakeholder feature points
ICSE 2016, Austin, TX 64
Stakeholder
weight
Score(n,q)
Criteria
weight
SCORE(n)...
Resource constraints
• Resource class 1: A resource type r belongs to class 1 if
the feature related consumption of the re...
Resource constraints
• Resource class 2: A resource type r belongs to class 2 if
the feature related consumption of the re...
Comparison of EVOLVE II with other methods
ICSE 2016, Austin, TX 67
Method
Characteristics EVOLVE II on-the-fly planning [...
EVOLVE II tool support - ReleasePlanner
ICSE 2016, Austin, TX 68
ReleasePlanner™ - Main components
ICSE 2016, Austin, TX 69
Use cases
1. Project definition: stakeholders, criteria, features, resources,
estimates, capacities, number of releases, p...
Contents
• INTRODUCTION OF PARTICIPANTS
• PART I. BACKGROUND
• PART II. STATE OF THE ART
• PART III. THE EVOLVE APPROACH
•...
ICSE 2016, Austin, TX 72
From closed to open world planning
Open innovation
• An (open) approach for integration of internal and
external ideas and paths to market that merges
distri...
Release Planning – Information needs
ICSE 2016, Austin, TX 74
Information needs
Type of release planning problem
Features
...
Analytic open innovation
• Open innovation with emphasis on analytics
(processes, tools, knowledge, techniques, decisions)...
How much planning is enough?
ICSE 2016, Austin, TX 76
Perfection of information 100%
Valueand
costofadditionalinformation
...
Pro’s of investment
• Pro-active evaluation of impact of decisions
• Support to find the most promising decision
alternati...
Con’s from investment
• Additional effort on decision-making
• Additional effort on information retrieval
• Effort to beco...
ICSE 2016, Austin, TX 79
Summary
• Basic assumption: The more qualified processes and
support is provided, the better the chance to find an
appropr...
Acknowledgements
• This work has been partially funded by the SUPERSEDE
H2020 project (2012-2015) under contract nb. 64401...
.5
Xavier Franch
Group of Software and Service Engineering
Universitat Politècnica de Catalunya
Barcelona, Spain
franch@es...
Upcoming SlideShare
Loading in …5
×

Technical briefing on Software Release Planning

425 views

Published on

One of the most critical activities in software product development is the decisional process that assigns features to subsequent releases under technical, resource, risk, and budget constraints. This decision-centric process is referred to as software release planning (SRP).

This briefing will expose a state of the art on SRP. A survey of the most relevant approaches will be presented. Emphasis will be made on their applicability (concerning e.g. type of development process and type of system, tool support and degree of validation in industry. One of these approaches, EVOLVE, will be analysed in detail.

The briefing is addressed to a wide audience. For researchers, an updated state of the art will be exposed, a particular method will be explored in depth, and the presentation will rely on scientific grounds. For practitioners, the practical dimension of SRP will be present. For educators, the briefing will provide the basis for developing course material.

Published in: Software
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
425
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Technical briefing on Software Release Planning

  1. 1. .5 Xavier Franch Group of Software and Service Engineering Universitat Politècnica de Catalunya Barcelona, Spain franch@essi.upc.edu Guenther Ruhe Software Engineering Decision Support Laboratory University of Calgary Calgary, Alberta, Canada ruhe@ucalgary.ca
  2. 2. Contents • INTRODUCTION OF PARTICIPANTS • PART I. BACKGROUND • PART II. STATE OF THE ART • PART III. THE EVOLVE APPROACH • PART IV. CONCLUSIONS ICSE 2016, Austin, TX 2
  3. 3. Contents • INTRODUCTION OF PARTICIPANTS • PART I. BACKGROUND • PART II. STATE OF THE ART • PART III. THE EVOLVE APPROACH • PART IV. CONCLUSIONS ICSE 2016, Austin, TX 3
  4. 4. Attendees ICSE 2016, Austin, TX 6
  5. 5. Contents • INTRODUCTION OF PARTICIPANTS • PART I. BACKGROUND • PART II. STATE OF THE ART • PART III. THE EVOLVE APPROACH • PART IV. CONCLUSIONS ICSE 2016, Austin, TX 7
  6. 6. Context – Software Evolution ICSE 2016, Austin, TX 8 Continuing Change — an [E-type] system must be continually adapted or it becomes progressively less satisfactory (Law 1) Continuing Growth — the functional content of an [E-type] system must be continually increased to maintain user satisfaction over its lifetime (Law 6) Laws of Software Evolution Manny Lehman (1925 – 2010) what/when/how to evolve? Release Planning
  7. 7. The planning onion ICSE 2016, Austin, TX 9M. Cohn, Agile Estimating and Planning. Prentice Hall PTR, 2006.
  8. 8. Software release planning – definition ICSE 2016, Austin, TX 10 Software release planning – “critical process of deciding which features are implemented in which releases” G. Ruhe. Product Release Planning, CRC Press 2010 Release planning – Strategic + operational Strategic release planning – “selection and assignment of requirements in sequences of releases such that important technical and resource constraints are fulfilled” Operational release planning – “development of the identified features in a single software release” Svahnberg et al. A Systematic Review on Strategic Release Planning Models. IST 52(3), 2010
  9. 9. Example: SENERCON ICSE 2016, Austin, TX 11 • Partner of the SUPERSEDE H2020 project • Service provider for energy savings based in Berlin with more than 75.000 users • After developing more than 20 services, still success is unpredictable, concluding that: – the success of a service mostly depends on fulfilling personal and individual needs of the end-user – mismatch QoS – QoE  The Black Box Problem
  10. 10. Example: SENERCON ICSE 2016, Austin, TX 12 • Main reasons: – lack of detailed knowledge about QoE • currently, email + hotline only – not having a systematic release planning approach in place • currently, based on expert judgement • Goal: a cost-effective exchange hub users developers – contextualized user feedback – discovery of service usage patterns – combine feedback with context • Once this information is known: – features’ value easier to quantify – systematic release planning may be put in place
  11. 11. What is a feature ICSE 2016, Austin, TX 13 “A logical unit of behavior specified by a set of functional and non-functional requirements” J. Bosch. Design and Use of a Software Architecture. ACM Press 2000 “A distinguishable characteristic of a concept (system, compo- nent, etc. ) that is relevant to some stakeholder of the concept” K. Czarnecki, U.W. Eisenecker. Generative Programming: Methods, Tools and Applications. Addison-Wesley 2013 “A set of logically related requirements that provide a capability to the user and enable the satisfaction of business objectives” K. Wiegers, J. Beatty. Software Requirements (3rd ed.), Microsoft Press 2013
  12. 12. Typical features ICSE 2016, Austin, TX 14 • Core functionality of the domain – prime prerequisite for a company’s business • Demanded by the market • Requested by a specific customer T. Berger et al. What is a Feature? A Qualitative Study of Features in Industrial Software Product Lines. SPLC 2015
  13. 13. Good and bad features ICSE 2016, Austin, TX 15 Reasons for considering a feature as “good”: • Customer satisfaction • Distinct functionality • Well implemented and error free What makes a feature “bad”: • Result of time pressure and rushed development • Compromises emerging during implementation • Duplicated and superfluous features • High volatility T. Berger et al. What is a Feature? A Qualitative Study of Features in Industrial Software Product Lines. SPLC 2015
  14. 14. Software release planning – A deeper view ICSE 2016, Austin, TX 16 Amountofimplementedfunctionality Amountofsuggestedfunctionally Releases • Corrective • Adaptive • Perfective • Preventive ISO/IEC/IEEE 14764:2006
  15. 15. Software release planning – why? ICSE 2016, Austin, TX 17
  16. 16. Release decisions ICSE 2016, Austin, TX
  17. 17. Software release planning - Why difficult? ICSE 2016, Austin, TX 19 Information is  Uncertain  Inconsistent  Incomplete  Fuzzy Decision space  Large size  High complexity  Dynamically changing Multiple objectives  Usability  Value  Time-to-market  Frequency of use  Risk Hard & soft constraints on  Time  Effort  Quality  Resources
  18. 18. Main challenges in release planning • Product management underestimated/not sufficiently established • Product release planning process immature • Product release planning not synchronized with other processes • Lack of systematic re-planning • Lack of transparency of release decisions • Lack of definition of planning goals/alignment with business goals • Lack of stakeholder involvement • Lack of resource consideration • More re-active than pro-active planning mode • Impact of better release content unclear • Impact (value) of individual features unclear • Planning for just the next release ICSE 2016, Austin, TX 20
  19. 19. Contents • INTRODUCTION OF PARTICIPANTS • PART I. BACKGROUND • PART II. STATE OF THE ART • PART III. THE EVOLVE APPROACH • PART IV. CONCLUSIONS ICSE 2016, Austin, TX 21
  20. 20. Approaches to Software Release Planning Two main categories • manual (“on-the-fly”) approaches – rely on humans’ ability to negotiate between conflicting objectives and constraints – mainly reported as experience reports • analytical approaches – formalize the problem – apply computational algorithms to generate best solutions – mainly reported as scientific technical papers ICSE 2016, Austin, TX 22 G. Ruhe, M.O. Saliu. The Art and Science of Software Release Planning. IEEE Software 22(6), 2005
  21. 21. On-the-fly approaches ICSE 2016, Austin, TX 23 • emphasis on improving the decision process – make estimates as accurate as possible – provide stakeholders a voice • emphasis is in the next release – planning long term is more difficult
  22. 22. Example: a case in Ericsson V.T. Heikkilä et al. Continuous Release Planning in a Large- Scale Scrum Development Organization at Ericsson. XP 2013ICSE 2016, Austin, TX 24 • Ericsson node development unit – traffic management in telecommunication networks – large systems – combining hardware and software • Large projects – 20 development teams fro Finland and Hungary – every team had 6-7 members – following Scrum • The products – yearly public releases – 2 internal versions per release, 2 internal deadlines for maintenance updates
  23. 23. Team structure ICSE 2016, Austin, TX 25
  24. 24. The release planning process ICSE 2016, Austin, TX 26
  25. 25. Reported benefits • Increased flexibility – feature development schedule not tied to release schedule – decreased development lead time • Eliminate waste in the planning process – early identification of too expensive or unfeasible features save development resources • Increased developer motivation – early involvement of developers in the feature planning process ICSE 2016, Austin, TX 27
  26. 26. Remaining challenges • Misalignment with “the old way” of planning – product manager still asking for long-term feature development plans • increasing detail of FCS • Managing non-feature specific work – non-feature specific problem reports, system documentation, external change requests, … • Low prioritization of system improvement work wrt implementing new features – some store points saved for system improvements ICSE 2016, Austin, TX 28
  27. 27. Limitations of on-the-fly approaches • Informal process • Informal decisions • But: > 1.000.000.000.000 possibilities already in case of 20 objects and three periods ICSE 2016, Austin, TX 29
  28. 28. Analytical approaches F = {f(1), ..., f(N)} Set of features Set of constraints X = {x(1), ..., x(N)} Release plan x(j) = assigned release C = {c(1), ..., c(M)} RP maximise some utility or objective function ICSE 2016, Austin, TX 30
  29. 29. Analytical approaches F = {f(1), ..., f(N)} Set of features Set of constraints X = {x(1), ..., x(N)} Release plan x(j) = assigned release C = {c(1), ..., c(M)} RP maximise some utility or objective function What information is processed? Which results are produced? How is the plan computed? ICSE 2016, Austin, TX 31
  30. 30. Example – release planning in agile projects Approach Iterations Precedences Risk Change mgmt. Planning [1] Multi Preced, coupling Some Some Heuristic [2] Multi Preced Yes No Greedy [3] Single Preced, coupling No Yes Exact [4] Single Preced No Some Exact [5] Multi Preced, coupling Yes No Exact [6] Multi Preced, coupling Yes No Exact [7] Multi Preced, anchor, coupling Yes Yes Exact [1] D. Greer, G. Ruhe. Software release planning: an evolutionary and iterative approach. IST 46, 2004 [2] M. Denne, J. Cleland-Huang. Software by Numbers. Prentice Hall, 2004 [3] M.O. Saliu, G. Ruhe. Supporting software release planning decisions for evolving systems. SEW 2005 [4] C. Li et al. An integrated approach for requirement selection and scheduling in software release planning. REJ 15, 2010 [5] A. Szoke. Conceptual scheduling model and optimized release scheduling for agile environments. IST 53, 2011 [6] G. van Valkenhoef et al. Quantitative release planning in extreme programming. IST 53, 2011 [7] M. Golfarelli, S. Rizzi, E. Turrichia. Multi-sprint planning and smooth replanning: An optimization model. JSS 86, 2013
  31. 31. State of the art Main source: systematic literature review until 2008 • 24 release planning models found – 14 original and 10 extensions, mostly from 1998 • Three main groups – EVOLVE-family + ReleasePlanner tool @ University of Calgary – SERG @ Lund University – Center of Organization and Information @ Utrecht University ICSE 2016, Austin, TX 33 Svahnberg et al. A Systematic Review on Strategic Release Planning Models. IST 52(3), 2010
  32. 32. State of the art Extension: ongoing non-systematic literature review until 2015 by the GESSI research group at UPC • snowballing based approach – forward snowballing from Svahnberg et al.’s SLR  C1 – backward snowballing from C1 – focus on selected journals and conferences – contributions from industry also sought • Final selection: 16 new methods found in the period 2009-2015 ICSE 2016, Austin, TX 34
  33. 33. New methods in a nutshell (sample) ICSE 2016, Austin, TX 35 NRP for eXtreme Programming dealing with some uncertainty Multsprint planning in an agile context Combining a planning algorithm with a scheduling method Efficient algorithm for NRP in the projects with large sets of requirements NRP in large scale agile organizations Calculate the impact of uncertainty with time constraints in release planning Define new releases in agile environments taking into account previous iterations Efficient NRP algorithm based on model checking considering dependencies Implement a risk-aware NRP algorithm
  34. 34. Input: constraints and factors ICSE 2016, Austin, TX 36 Soft factorsRisk factors Value factors Resource consumption factors Stakeholders’ influence factors Svahnberg et al. A Systematic Review on Strategic Release Planning Models. IST, 52(3), 2010 Requirement dependencies Quality constraints Budget and cost constraints Resource constraints Effort constraints Time constraints Hard constraints
  35. 35. Input: constrains and factors (prevalence in 2010) ICSE 2016, Austin, TX 37 Requirement dependencies (75%) Quality constraints (8.3%) Budget and cost constraints (29.1%) Resource constraints (33.3%) Effort constraints (50%) Time constraints (16.7%) Soft factorsRisk factors (12.5%) Value factors (37.5%) Resource consumption factors (20.8%) Stakeholders’ influence factors (29.2%) 28 methods Hard constraints
  36. 36. Input: constrains and factors (prevalence in 2015) ICSE 2016, Austin, TX 38 Requirement dependencies (75%)(75%) Quality constraints (8.3%) (5%) Budget and cost constraints (29.1%) (17.5%) Resource constraints (33.3%) (37.5%) Effort constraints (50%) (50%) Time constraints (16.7%) (25%) Soft factorsRisk factors (12.5%) (17.5%) Value factors (37.5%) (42.5%) Resource consumption factors (20.8%) (17.5%) Stakeholders’ influence factors (29.2%) (22.5%) 40 methods Hard constraints
  37. 37. Output • Scope – one release vs. multiple releases • Object of planning – features; user stories; requirements • Prioritization – none – ordinal – must-have, should-have, could-have • Time scheduling • Developer assignment ICSE 2016, Austin, TX 39
  38. 38. Objective function • Optimization of the value given by the features while managing the resources and fulfilling all possible constraints • How to measure value: – business value, stakeholder satisfaction, urgency, risk minimization, technical debt, return on investment, … • How to measure resources – personnel, availability – considering size/complexity of features • Constraints – dependencies, time constraints, … ICSE 2016, Austin, TX 40
  39. 39. A lot of computational approaches… ICSE 2016, Austin, TX 41 Greedy algorithms Pareto opti- mal fronts Monte-Carlo simulation Knapsack problem Branch and bound Backbone based algorithms Graph trans- formation AHPClustering
  40. 40. Example – greedy solution (1) • Principle: always add a feature to the solution that maximizes value while not violating any constraint or requiring more resources than available • Greedy algorithms: building a good global solution as the sequence of local optimum choices at every moment ICSE 2016, Austin, TX 42
  41. 41. Example – greedy solution (2) • Input: – Set of features, F = {f(1), …, f(N)} – Resource consumption, cost: F  Integer – Estimated values, value: F  Integer – Set of cost capacity for each release: totalCost: Integer  Integer • Output: – Release planning, Release: Integer  {Integer}, s.t. all sets are pair-wise disjoints ICSE 2016, Austin, TX 43 G. Ruhe. Product Release Planning, CRC Press 2010
  42. 42. Example – greedy solution (3) ICSE 2016, Austin, TX 44G. Ruhe. Product Release Planning, CRC Press 2010
  43. 43. Example – Multi-sprint planning in Scrum (1) • Given a set S of m sprints and a set U of n user stories, maximise a solution z for the m sprints • Goals: – customer satisfaction – coupling management – criticality risk management • Strategy – generalized assignment model M. Golfarelli, S. Rizzi, E. Turrichia. Multi-sprint planning and smooth replanning: An optimization model. JSS 86, 2013 ICSE 2016, Austin, TX 45
  44. 44. Example – Multi-spring planning in Scrum (2) Example of input: ICSE 2016, Austin, TX 46 ID Name Deps. and coupling Utility Comple- xity Criticality risk Uncert. risk s1 Fee configuration s1->s2 80 5 Low Low s2 Cash cost computation 0.3 s2+s10 85 2 Medium Medium s3 Import from DBMS 75 2 Medium Medium s4 Parameterization logic 30 1 Medium Medium s5 Amortization mask 60 2 No No s6 Exchange computation 60 2 Low Medium s7 Exchange import from SAP s7->s6 60 7 Low Low s8 Mngmt . control reporting 85 4 Medium Low s9 Operational reporting 100 10 Low Medium s10 Scenario management mask 0.3 s2+s10 65 3 Low Low
  45. 45. Example – Multi-spring planning in Scrum (3) • Objective function z: – uj: utility of story j – rj cr: criticality risk of story j – xij = 1 if story j is included in sprint i – G: set of coupling groups of stories; Al: a set of coupled stories – al: affinity between stories in Al – yijl: number of stories of Al affine to story j and included in sprint i ICSE 2016, Austin, TX 47
  46. 46. Example – Multi-spring planning in Scrum (4) the sum of stories’ complexity (considering uncertainty risks) fits into each sprint capacity each story is planned in exactly one sprint each forced story is planned in the planned sprint correct consideration of OR- and AND-dependencies among features restricting values of affine stories ICSE 2016, Austin, TX 48
  47. 47. Summary: Analytical vs. on-the-fly planning ICSE 2016, Austin, TX 49 Caracteristics Analytical methods On-the-fly Time horizon Next release, but applicable more general Next release Objectives Flexible, but typically value-based Vague and not explicitly described Stakeholder involvement Not directly supported Opportunistic and by communication Solution method Greedy heuristic, linear programming, simulation, .. Intuition and experience-based Quality of solutions Good on average, but unknown for specific case Difficult to judge. The more risky, the more complex the problem Feature dependencies Typically not considered Implicitly, hard to consider for more complex problems Human resource constraints If at all, then just cumulative effort Implicitly, hard to consider for more complex problems What-if analysis (explicit support) No No Integrated tool support Limited No
  48. 48. Summary ICSE 2016, Austin, TX 50 • On-the-fly approaches criticised due to the difficulty of taking into account all knowledge implied by software release planning • Conversely, analytical approaches criticised either because: – Too simple to be useful • Lack of information considered • Over-simplifications (e.g. requirement dependencies) – Too complex to be adopted • Learning curve • Lack of trust in result
  49. 49. Contents • INTRODUCTION OF PARTICIPANTS • PART I. BACKGROUND • PART II. STATE OF THE ART • PART III. THE EVOLVE APPROACH • PART IV. CONCLUSIONS ICSE 2016, Austin, TX 51
  50. 50. Release planning – Art or Science? ICSE 2016, Austin, TX 52 • Art: Focus on the human intuition and communication for handling tacid knowledge • Science: Emphasis on formalization of the problem and application of computational algorithms to generate best solutions.
  51. 51. What’s the problem? ICSE 2016, Austin, TX 53 “The mere formulation of a problem is far more essential than its solution, which may be merely a matter of mathematical or experimental skills. To raise new questions (and), new possibilities, to regard old problems from a new angle, requires creative imagination and marks real advances in science.” (Albert Einstein, 1879-1955)
  52. 52. Optimized release planning – How it began ICSE 2016, Austin, TX 54 EVOLVE: Greer, D. and Ruhe, G., Software Release Planning: An Evolutionary and Iterative Approach, Information and Software Technology, Vol. 46 (2004), pp. 243- 253. What constitutes a release plan? Max{ F(x, α) = (α - 1) F1(x) + α F2(x) subject to 0 ≤ α ≤ 1, x from X} Stakeholders Weightings for stakeholders Scores of stakeholders towards urgency (F1) and value (F2) X composed of - effort constraints - coupling and precedence constraints (between features)
  53. 53. Optimized release planning – How it began ICSE 2016, Austin, TX 55 F1(x) is a penalty function defined for plan x describing the degree of violation of the monotonicy property between all pairs of features F2(x) is a benefit function based on feature scores of the stakeholders and the actual assignment of the feature according to the plan under consideration. value(n,p) = value_score(n,p)(K – x(n) +1)
  54. 54. Empirical analysis • EVOLVE was initially based on genetic search offered by Palisade’s RiskOptimizer • Early industrial feedback (Corel, Siemens) • Development of our own GA (emphasis on avoiding premature convergence) • Empirical studies with 200 to 700 requirements comparing the GA with running ILOG’s CPLEX • Better solutions for LP solver in reasonable time • Known level of optimality • Development of our own solution method utilizing open source optimization combined with knapsack-type of heuristic for B&B • New approach more flexible and with higher level of diversification among top solutions. ICSE 2016, Austin, TX 56
  55. 55. EVOLVE II: Three phases • Phase 1 - Modeling: – Formal description of the (changing) real world to make it suitable for computational intelligence based solution techniques • Phase 2 - Exploration: – Application of computational techniques to explore the solution space, to generate and evaluate solution alternatives • Phase 3 - Consolidation: – Human decision maker evaluates current solution alternatives – Match with implicit objectives and constraints ICSE 2016, Austin, TX 57 Computational Intelligence Interation 1 Release 1 Release 2Interation 2 Interation 3 Release 3 Human Intelligence
  56. 56. Evolution everywhere • Evolutionary software development (iterative, incremental) • Evolutionary solution algorithms • Evolutionary problem solving (synergy between art and science) ICSE 2016, Austin, TX 58
  57. 57. The diversification principle ICSE 2016, Austin, TX 59 A single solution to a cognitive complex problem is less likely to reflect the actual problem when compared to a portfolio of qualified solutions being structurally diversified Consolidation
  58. 58. ICSE 2016, Austin, TX 60 Preparation 1 Planning criteria weights 2 Pre-selection of features 3 Prioritization of features 4 Voice-of-the stakeholder analysis 5 Technology constraints 7 Resource estimation 6 Optimization 8 Quality and resource analysis 9 Excitement analysis 10 Stakeholder evaluation of plans 12 What-if-analysis 11 Final plan decision 13 dependency between steps mandatory step optional step set of logically linked steps feedback link Stakeholder-centric release planning – Method EVOLVE II
  59. 59. Criteria for feature selection • Customer satisfaction • Customer dissatisfaction • Risk of implementation • Risk of acceptance • Financial value • Cost • Time to market • Volatility • Frequency of use • Ease of use ICSE 2016, Austin, TX 61
  60. 60. Feature dependencies • For given features A, B, and C, we distinguish eight types of dependencies: ICSE 2016, Austin, TX 62
  61. 61. Pre-assignment of features to releases ICSE 2016, Austin, TX 63
  62. 62. Maximization of stakeholder feature points ICSE 2016, Austin, TX 64 Stakeholder weight Score(n,q) Criteria weight SCORE(n) Releases weight sfp(n,x) TSFP(x) Features score(n,p,q) Plan x
  63. 63. Resource constraints • Resource class 1: A resource type r belongs to class 1 if the feature related consumption of the resource is limited to exactly the release in which the feature if offered. Resources of this class are called local based on its spending mode. ICSE 2016, Austin, TX 65 Consumption(k,r,x) = ∑n: x(n)=k consumption(n,r) ≤ Capacity(k,r)
  64. 64. Resource constraints • Resource class 2: A resource type r belongs to class 2 if the feature related consumption of the resource can be distributed across different release periods. Resources of this class are called global based on its spending mode. ICSE 2016, Austin, TX 66 ∑ n=1..N wx (n,k,r) consumption(n,r) ≤ ∑ Capacity(k,r) for all releases k = 1…K 0 ≤ wx (n,k,r) ≤ 1 for all n,k,r ∑ k = 1 .. K wx (n,k,r) = 1 for all n,r
  65. 65. Comparison of EVOLVE II with other methods ICSE 2016, Austin, TX 67 Method Characteristics EVOLVE II on-the-fly planning [van den Akker et al. ‘08] Time horizon Flexible Next release Next release Objectives Flexible in the number and type of criteria Vague and not explicitly described Maximize financial value function Stakeholder involvement Strongly supported with explicitly assigned individualized tasks at the different stages Opportunistic and by communication Not directly supported Solution method Specialized integer programming with additional heuristics Intuition and experience-based Integer linear programming (ILP) Quality of solutions Five near optimal alternative solutions with known level of optimality Difficult to judge. The more risky, the more complex the problem Near-optimal solutions based on ILOG Feature dependencies Precedence and coupling Implicitly, hard to consider for more complex problems Precedence, coupling, either or dependencies Human resource constraints number, type and granularity of the resources Implicitly, hard to consider for more complex problems Yes, including staffing of teams What-if analysis (explicit support) Yes No Yes Integrated tool support ReleasePlanner 2.0 No Prototype based on usage of ILOG
  66. 66. EVOLVE II tool support - ReleasePlanner ICSE 2016, Austin, TX 68
  67. 67. ReleasePlanner™ - Main components ICSE 2016, Austin, TX 69
  68. 68. Use cases 1. Project definition: stakeholders, criteria, features, resources, estimates, capacities, number of releases, permissions 2. Feature prioritization 3. Most controversial features 4. Alternative plan generation 5. Feature dependencies 6. Excitement analysis for a given plan 7. Customization of plans 8. Comparison between two selected plans 9. JIRA: Import of issues and subsequent plan generation 10. Change of data in JIRA and synchronization 11. Innovation planning where stakeholder represent competitors 12. Service portfolio planning 13. When to release planning 14. Feedback-driven planning 15. Planning functional versus quality requirements ICSE 2016, Austin, TX 70
  69. 69. Contents • INTRODUCTION OF PARTICIPANTS • PART I. BACKGROUND • PART II. STATE OF THE ART • PART III. THE EVOLVE APPROACH • PART IV. CONCLUSIONS ICSE 2016, Austin, TX 71
  70. 70. ICSE 2016, Austin, TX 72 From closed to open world planning
  71. 71. Open innovation • An (open) approach for integration of internal and external ideas and paths to market that merges distributed knowledge and ideas into production processes. ICSE 2016, Austin, TX 73
  72. 72. Release Planning – Information needs ICSE 2016, Austin, TX 74 Information needs Type of release planning problem Features Featuredependencies Featurevalue Stakeholder Stakeholderopinionand priorities Releasereadiness Markettrends Resourceconsumptions andconstraints What to release × × × × × × × Theme based × × × × × × × When to release × × × × × × × Consideration of quality requirements × × × × × × × Operational release planning × × × Consideration of technical debt × × × × Multiple products × × × × × × ×
  73. 73. Analytic open innovation • Open innovation with emphasis on analytics (processes, tools, knowledge, techniques, decisions). ICSE 2016, Austin, TX 75
  74. 74. How much planning is enough? ICSE 2016, Austin, TX 76 Perfection of information 100% Valueand costofadditionalinformation (Harrison 1987) Benefit Cost Cost-benefit ROI the better the more often investments are used
  75. 75. Pro’s of investment • Pro-active evaluation of impact of decisions • Support to find the most promising decision alternatives • Transparency • Understandability • Reducing the impact of human bias • Reducing the risk of failure • Increasing the chance of success 77ICSE 2016, Austin, TX
  76. 76. Con’s from investment • Additional effort on decision-making • Additional effort on information retrieval • Effort to become familiar with some support tool(s) • Unavoidable uncertainty (depending on scope) 78ICSE 2016, Austin, TX
  77. 77. ICSE 2016, Austin, TX 79
  78. 78. Summary • Basic assumption: The more qualified processes and support is provided, the better the chance to find an appropriate decision. • Benefit of a mature release planning process: – Better customer satisfaction – Higher competitiveness of products – Transparency of decisions – Ability to adjust to change – Alignment to business objectives – Higher predictability of results 80ICSE 2016, Austin, TX
  79. 79. Acknowledgements • This work has been partially funded by the SUPERSEDE H2020 project (2012-2015) under contract nb. 644018 • The first presenter wants to thank D. Ameller and C. Farré at UPC for their work in the topic of the tutorial • The second presenter acknowledges the support provided by NSERC and the collaboration with Maleknaz Nayebi on this topic. ICSE 2016, Austin, TX 81
  80. 80. .5 Xavier Franch Group of Software and Service Engineering Universitat Politècnica de Catalunya Barcelona, Spain franch@essi.upc.edu Guenther Ruhe Software Engineering Decision Support Laboratory University of Calgary Calgary, Alberta, Canada ruhe@ucalgary.ca

×