1 Development of a Release Planning Tool Advanced Software Engineering CAP 541 Presented by: Alaa...

59
1 Development of a Release Planning Tool Advanced Software Engineering CAP 541 Presented by: Alaa Al-Othman Alia Al-Abdulkarim Eman Al-Attas Nora Al-Mohnna Nouf Al-Rumaih Nurah Al-Rageebah Sheroug Al-Megren Supervised By: Prof. Ghazy Assassa

Transcript of 1 Development of a Release Planning Tool Advanced Software Engineering CAP 541 Presented by: Alaa...

1

Development of a Release Planning Tool Advanced Software Engineering

CAP 541

Presented by:Alaa Al-OthmanAlia Al-AbdulkarimEman Al-AttasNora Al-MohnnaNouf Al-RumaihNurah Al-RageebahSheroug Al-Megren

Supervised By:Prof. Ghazy Assassa

2

Outline

What is Release Planning? Survey of Existing Tools Release Planning Parameters Release Planning Algorithms User Stories Conclusion References

3

What is Release Planning ?[1]

Determining requirements to be implemented in one or more future product releases

4

Survey of Existing Tools

We searched the Internet for release planning tools They were limited Most of them focused on project planning with release

planning capabilities Some of them had no trial versions available.

We surveyed the following tools: ExtremePlanner XPlanner ReleasePlanner VERSIONONE Solver

5

ExtremePlanner [2]

Web-based application for Agile project management User-friendly interface Prioritization (1..10) Technical risk (qualitatively) Scope Resource management (man hours) Importing & exporting from/to Excel Traceability Tracking progress (Burn down charts) Issues

6

XPlanner [3]

Web-based application for XP environment It does not support release planning, but it suggests

what features to be included in the next Iteration depending on Story Cards written by customers Planning Games

Prioritization exporting to MS Project and XML formats. Traceability Tracking progress (Burn down charts)

7

ReleasePlanner [4]

No trial access was available Survey was based on reviews and papers Web-based release planning tool Prioritization (0..5) Dependency Risk management Stakeholder management Scoping Resource management Based on the EVOLVE* algorithm Scenarios (alternative plans)

8

VERSIONONE [5]

Web-based application for Agile project management User-friendly interface Prioritization (High-Medium-Low) Technical risk (High-Medium-Low-None) Scope Dependency( Dependencies Grid ) Resource management (man hours) Importing & exporting from/to Excel and XML Traceability Tracking progress (Burn down charts) Scenarios( What-If )

9

Solver [6]

MS Excel Add-ins Specify an objective, variables, and

constraints The application produces best plan to satisfy

the objective

Feature/RP toolextremePlanner SolverXPlannerReleasePlanner

V1Proposed Planner

PrioritizationY NY YY Y 

DependencyN YN YY Y

Risk AnalysisY NN YY Y

Resource Management

Y NYYY Y

Scope Y NYYY Y

Stakeholders Management

N NYYY Y

Importing and exporting

Y NYexport

N/AY N

Report generationY YN N/AY Y

Tracking progressYNYYYY

Traceability YN Y N/AY N

ScenariosYNNYYN

Web basedYNYYYN

User friendlyYYN/AN/AYY

11

Release Planning Parameters

Priority Dependency Risk Resources (effort-time-cost)

12

Release Planning Algorithms [7]

Software release: is a collection of new and/or changed features that form a new product.

Release planning assigns features to releases such that the most important technical, resource, risk and budget constraints are met.

Features are an abstraction from requirements that both customers and developers understand

13

Release Planning Algorithms Cont. [7]

Without any constraints, all the features could be implemented in one release.

The existence of all the constraints implies the question: What comes first and why?

14

Release Planning Algorithms Cont. Planning Game EVOLVE* Lightweight Replanning Risk Driven

15

EVOLVE* [7]

Provides an intelligent decision support for release planning [8]

It is based on genetic algorithm and aimed at the evolutionary planning of incremental software development [8]

The algorithm results a number of features to be delivered in the next release

16

EVOLVE* cont. Because of the high degree of requirements volatility, It is better to plan two

releases only [7]

A set of features (F) will be assigned to one of three cases: [7]

Next release (option1) Next but one release (option2) Postponed, not yet considered for implementation (option3)

K possible release option [9]

a release plan is characterized by a vector of decision variables x = {x(1), x(2), ..... x (n)} where

x(i) = k if we assign feature i to release option k є {1,2,..K}

17

EVOLVE* parameters [9] Parameters considered in EVOLVE* approach:

Stakeholders Importance λ(p) є {1...,9} Imprtance is set using pair-wise comparision

Priorities assigned by stakeholders based on: Business-value (1-9)

value(i,p) є {1...,9} p stakeholder i feature

Urgency (stakeholders satisfaction) sat(i,p) є {1...,9} where

i feature p stakeholder

18

EVOLVE* parameters cont.

Fetures independency constraints two types of constraints:

Coupling x(i) = x(j) for all (i,j) є C subset from F x F

Precedence x(i) ≤ x(j) for all (i,j) є P subset from F x F

Resource consumption Resource capacity Cap(k) for each release option k if feature i requires r(i) of development resources then

∑x(i)=k

r(i) <= Cap(k)

19

EVOLVE* parameters cont.

System constraints each feature f(i) is assigned a set of impacted

components Impact(f(i)) subset from System S for each option k

∑ x(i)=k

Impact(f(i)) ≤ β(k) where β(k) is user-defined threshhold

20

EVOLVE* parameters cont.

WAP (Weighted Average Priority) combines the individual stakeholder evaluations from the perspective of value and urgency WAP(i,p) where

i feature p stakeholder

it is not necessary that each stakeholder gives his evaluation related to all features [7]

P(i) is the set of active stakeholders with respect to feature i

21

EVOLVE* parameters cont.

Further flexibility is introduced By assign weights to the importance of release

options ξ This yields the objective function F(x)

F(x) = ∑k=1…K ξ(k) [Σ x(i)=k WAP(i,p)] x release plan є X (set of release plans)

WAP(i,p)=∑ p=1…q λ(p) sat(i,p) value(i,p)⋅ ⋅ If we want to consider whether stakeholder is active or

not [7]

WAP(i,p) = [∑ pєP(i) λ(p) value(i,p) sat(i,p)]/[∑ ⋅ ⋅ pєP(i) λ(p)]

22

Formal Problem statement [9]

objective function F(x) is represented as v[i,k] x[i,k] є {0,1} binary decision variable

23

Lightweight Replanning Process Model[10]

The main goal of Lightweight Replan Model is to develop a new product plan that achieves higher stakeholder satisfaction given a limited capacity of time and resources.

It provides a basis for incorporating changes instantly into the development lifecycle.

Incorporating changes earlier in the product life cycle changes cost less.

24

Lightweight Replan Main

Steps

New Features

Feature Categorization

Stakeholder Voting

Resource Estimations

The Analytical Hierarchy Process (AHP)

Replanning Releases

25

Step1: New Features

As the product development starts, the development team begins receiving new

change requests for the features sets.

26

Step2: Feature Categorization

Features

Implemented Planned For AddedOngoing

27

Step3: Stakeholder Voting

Stakeholders are required to assign to all features (old and new features) a level of priority.

28

Step4: Resource Estimation The main goal is to maintain the effort and

time available so that the new replanned release does not exceed the capacity available.

For each featuer (fi)determine:

- Effort (fi)

- Time (fi)

29

Step5: The Analytical Hierarchy Process (AHP). [11]

AHP is a multi criteria decision making method

Each stakeholder compares between the old set of features and the newly added features with respect to a defined criteria

The AHP converts these evaluations to numerical values

We end with WAS for each feature

The Weighted Average Satisfaction (WAS) is a number that is given for each feature based on user preferences and mathematical operations

Higher WAS means more preference

The group of features with highest WAS are gathered in a new set to enter into the Greedy Replan algorithm in the next step [10]

Step6: Replanning Releases Applying the Greedy Replan algorithm

1. Define an objective Function F(fi) = 02. Define F'= Ø an empty set of features3. Define Effort = 0, Time = 0 4. Sort all features with the best attractiveness ratios gained from

the AHP comparison in a descending order5. While Effort and Time are less than the release capacity C do

steps 6 - 96. Add feature fi to F'7. F(fi) = F(fi) + WAS(fi)8. Effort = Effort + Effort (fi)9. Time = Time + Time (fi)10. Return F', F(fi), Effort, Time

Selected features in the new release Total WAS for the new release

Estimated effort & timefor the new release

31

Risk-driven method for RP [12] Developers construct a feasible release plans

from project profiles Risks in each feasible release plan are

analyzed Stakeholders decide a certain release plan for

the next iteration according to the result of risk analysis

32

Risk-driven method for XP release planning

33

Constructing Feasible RP

Feasible release plan A group of stories (requirements) that can be

completed in the next iteration under the iteration efforts and stories dependencies constraints

Criteria for evaluation feasibility of a release plan Business value of story Size Available efforts per iteration Dependencies among stories

34

Constructing Feasible RP (cont.) Business value evaluated using AHP method

Vi denotes story i’s business value

Man-hours used as measurement for size estimation ci denotes story i’s size Ct denotes available efforts for No. t iteration

Dependencies If story i depends on story k, we endue dik=1,

otherwise dik=0

35

Constructing Feasible RP (cont.) Assuming there are n uncompleted stories, and

xi=1 denotes story i will be completed in the next iteration; otherwise xi=0

Using the assumption and the formula (1), a partially feasible release plan according to the criterion “maximizing business value per iteration” will be generated

(1)

36

Constructing Feasible RP (cont.) Dependencies and available effort constraints

can be expressed by formula (2) and (3)

)2 (

)3(

37

Constructing Feasible RP (cont.) The Algorithm

A solution space is organized, where a path from the root to the leaf denotes and entire solution Xw ={x1,…,xn}

The algorithm will use DFS and back tracking in order to construct feasible solutions that satisfy the previous formulas

A feasible solution queue S is used to cache solutions Xw

Constructing Feasible RP (cont.)1. Do DFS from i=1

2. if i<=n and xi=1 is added into X, and X is still FPS

then add xi into X, i=i+1, goto 2;

else goto 3;

3. if i<=n and xi=0 is added into X, and X is still FPS

then add xi into X, i=i+1, goto 2;

else goto 4;

4. if for each x in X, x=0

then exit;

5. Compare gi and gmin,

if gi>gmin

then delete Xwmin from S, add Xi into S, and reorder S;

38

39

Analyzing Risks

Identify risks Risk type (requirements, estimation, technology,

personnel) Probability and loss of each risk are estimated

Qualitatively estimated Risk exposure, which is the product of the

probability of failure and the loss associated with that failure, is calculated [13]

Analyzing Risks cont.

Score of risk analysis is given to each story

To compare differences among feasible release plans, RE should be accumulated for each given solution

40

Risk ExposureScore

Unacceptable4

Critical3

Significant2

Minor1

41

Making decisions

A release plan is selected according to risk scores

In early iteration, choose highest risk release plans to understand system goals

Nearer to the milestone, choose low risk release plans to ensure useful system at the milestone point

42

Risk-Driven conclusion for XP Process Following this technique contribute to sensible

release plans A risk-driven method will be the basis of our

release planning tool to be developed

43

User Stories

44

User Stories

Creating a new project

You type the project name and submit. Then, the system will create

a new project .

45

User Stories (cont.)

Adding a new iteration

You will fill in a form containing the iteration name, description, starting date, end date and capacity. You will submit and the system will create a new iteration

46

User Stories (cont.)

Adding a new release

You will fill in a form containing the release name, description, date and capacity. You will submit and the system will create a new release.

47

User Stories (cont.)

Adding a new story

You will fill in a form containing the story name, description, type, priority, risk, estimated effort in hours, iteration, release and status. You will submit and the system will create a new story.

48

User Stories (cont.)

Adding a new task

You will view the existing stories. You will select the story you would like to add the task to, then you will add the new task. The system will ask you to fill in a form containing the task name, description, type, estimated hours, and status. You will submit and the system will create a new task associated with the story you have selected.

49

User Stories (cont.)

Viewing the release plan

First, you will select the release name. After that, you’ll get the release details showing the associated stories and their status. You will ask the system to generate the release plan for you. Finally, the system will show you the release plan.

50

User Stories (cont.)

Modify story

You select the story to be modified. You’ll be able edit any form item, name, description, type, release, status… you’ll submit and the system will save your changes

51

User Stories (cont.)

Modify task

You select the task to be modified. You’ll be able edit any form item, name, description, type, status… you’ll submit and the system will save your changes.

52

User Stories (cont.)

Delete task

You select a task and ask the system to delete it. The task will be deleted.

53

User Stories (cont.)

Delete story

You select the story and ask the system to delete it. The story will be deleted along with all associated tasks.

54

User Stories (cont.)

Delete iteration

You select an iteration and ask the system to delete it. The iteration will be deleted.

55

User Stories (cont.)

Delete release

You select the release and ask the system to delete it. The release will be deleted.

56

User Stories (cont.)

Delete project

You select the project and ask the system to delete it. The project will be deleted along with all associated iterations, stories and tasks.

57

Conclusion

A survey on existing release planning tools was made

There is a lack of RP tools Key parameters affecting release planning

were defined A number of algorithms were investigated The tool will be implemented using one of the

investigated algorithms

58

References

1. Ruhe, G. and Sakiu, M. S., “The Science and Practice of Software Release Planning”, In Proceedings of NASE SEW-29, 2004.

2. “ExtremePlanner”. http://www.extremeplanner.com/free_trial.html

3. "XPlanner“.  http://www.xplanner.org4. Kaarlas, J. & Vähäniitty

, J., "Tool support for software product and release planning - requirements and current solutions". Working paper, 2005

5. “VERSIONONE". http://www.versionone.com6. Van den Akker, M., S. Brinkkemper, G. Diepen, J. Versendaal

, “Software Product Release Planning Through Optimization and what-if Analysis”, Department of Information and Computing Sciences, Utrecht University, 2006

59

References cont.

7. Ruhe, G., “Software Release Planning”, University of Calgary, Handbook Software Engineering and Knowledge Engineering, 2005

8. Ruhe, G. and Greer, D., “Quantitative Studies in Software Release Planning under Risk and Resource Constraints”, In Proceedings of ISESE, 2003

9. SALIU, Moshood Omolade, “Software Release Planning For Evolving Systems”, University of Calgary, PhD Research Proposal, 2005

10. T.AlBourae, G. Ruhe and M. Moussavi, “Lightweight Replanning of Software Product Releases”, International Workshop on Software Product Management (IWSPM'06),2006

11. “Analytic Hierarchy Process “. http://en.wikipedia.org/wiki/Analytic_Hierarchy_Process

12. Li, M., Huang, M., Shu, F. and Li, J., “A Risk-Driven Method for eXtreme Programming Release Planning”, Chinese Academy of Science, ICSE, 2006

13. Greer, D., Bustard, D., “Towards and Evolutionary Software Delivery Strategy based on Software Systems and Risk Analysis”, IEEE, 1996