DECISION SUPPORT FOR RE-PLANNING OF SOFTWARE

PRODUCT RELEASES

S. M. Didar-Al-AlamDept. of Computer Science

University of Calgary, Calgary, AB, Canada

Dietmar Pfahl

Institute of Computer Science

University of Tartu,

Tartu, Estonia

Guenther Ruhe

Dept. of Computer Science

University of Calgary,

Calgary, AB, Canada

2

Outline • Context

• Research Questions

• Solution Approach

• Release plan Generation

• Monitoring Release plan Implementation

• Re-planning

• Case Study : Dyna-H2W

• Innovations

• Threats to Validity

• Future Works

3

Context

• Release plan fails, if implementation process is uncontrolled

• Key solution approaches are - • 1) Process Control [1]• 2) Release Re-planning [2]

• Multi-factor process control should monitor release plan implementation

• Multiple factors should help Re-planning decisions

4

Research Questions

• RQ1: How to provide decision support on detecting the appropriate time to initiate re-planning process?

• RQ2: How to provide decision support on performing dynamic re-planning in consideration of multiple factors?

• RQ3: How to integrate predictive models into the decision support provided under RQ1 and RQ2?

?

5

SOLUTION APPROACH

Statistical Process Control [3]

Multiple Re-planning Criteria

Δ1(t*) = g(t*) – h(t*) > 0 ( = β1)

Δ2(t*) = abs(effortpred(t, ri) - effortact(t, ri)) > β2

Δ3(t*) = abs( defectspred (t) - defectsact (t) ) > β3

Optimized Operational Plan

Co

nti

nu

ou

sly

Up

da

ted

P

roje

ct

Da

taOptimized Feature

Selection

7

Release Plan Generation

• Strategic Planning• Optimized feature selection to achieve maximum release value • Conducted using EVOLVE II [2,4]

• Operational Planning • Assign developers to implement selected features• Scheduling tasks to achieve minimum release time • Conducted using RASORP [5]

8

Monitoring Release plan Implementation

• Release plan implementation process is continuously monitored

• Inspired by Statistical Process Control (SPC) [3]

• Monitoring attributes are chosen based on process factors

• For each attribute maximum variation level is found

• Multiple Re-planning criteria are created

9

Monitoring Process: Hypothetical Example

Software Quality (Δ3)

Effort Usage (Δ2)

Feature Change Request (Δ1)

Process Factors

Continuous Monitoring

Re-planning Criteria

Δ1(t*) = g(t*) – h(t*) > 0 ( = β1)

Δ2(t*) = abs(effortpred(t,ri) - effortact(t, ri)) > β2

Δ3(t*) = abs( defectspred (t) - defectsact (t) ) > β3

10

Re-planning • Re-planning criteria are monitored

• If fulfilled a warning is triggered

• Re-planning decision is human expert driven

• Project data is updated

• Strategic re-planning is conducted using EVOLVE II

• Operational planning is conducted using RASORP

11

Case Study : Dyna – H2W

Dyna-H2W: Instantiation of proposed approach

Multi-factor process control and multi-factor re-planning are evaluated

Comparative study is conducted among three strategies

- Static re-planning with single factor monitoring

- Dynamic re-planning with single factor monitoring [6]

- Dyna-H2W: Dynamic re-planning with multiple factor monitoring

12

Case Study Setup• Real world text editor software development with-

• Fifty (50) candidate features.• Two future releases (planning horizon)• Two planning criteria- Urgency & Value • Ten developers

• Feature implementation is completed through five tasks-• Requirement Elicitation • Design• Application Development• Third party Development • Quality Assurance

13

Case Study Results

11 22 29 350

20

40

60

80

100

120

140

Dynamic single factor Static single factor Dyna H2W

Time

Sa

tis

fac

tio

n v

alu

e (

%)

Number of defects detected and fixed

Baseline (with no

re-planning)

Dynamic re-planning with

single factor

Static re-planning with

single factorDyna H2W

412 407 399 422

Comparison of different strategies in terms of quality

Comparison of different strategies in terms of release value

(satisfaction value)

14

Innovations

Utilizing multiple process factors in software development process control

Supporting detection of out-of-control situation

Dynamic re-planning based on multiple process factors

Achieved higher release value and better quality compared to other strategies

15

Threats to Validity• Only quality assurance (QA) effort is considered responsible for

defect detection and debugging

• Effort, value and strategic plan data are collected from real world but QA data are synthetically generated

• Accuracy of Dyna-H2W depends on prediction and experts knowledge

• Re-planning criteria are considered to have constant tolerance level

16

Future Works

• Comprehensive evaluation of Dyna-H2W in industry settings

• Utilizing different combination of process factors

• Altering re-planning criteria with varying threshold values

• Automating re-planning criteria generation with machine learning techniques

17

References[1] T.A. Hughes,”Measurement and control basics”, ISA-The Instrumentation, Systems, and Automation Society, 2002.

[2] G. Ruhe, “Product Release Planning: Methods, Tools and Applications,” CRC Press 2010.

[3] W. Florac and A. Carleton, “Measuring the Software Process,” Addison Wesley, 1999

[4] https://www.expertdecisions.com/

[5] A. Ngo-The, G. Ruhe, “Optimized Resource Allocation for Software Release Planning,” IEEE Transactions on Software Engineering, Volume 35, 2009, pp. 109-123.

[6] A. Al-Emran, D. Pfahl, and G. Ruhe, “DynaReP: A discrete event simulation model for re-planning of software releases,” Proc. ICSP 2007, LNCS 4470, pp. 246–258.

18

Thank you