applicability of a strategic tpm release planning model on ... · pdf fileobjectives....

International Journal of Applied Engineering Research ISSN 0973-4562 Volume 11, Number 24 (2016) pp. 11958-11966

© Research India Publications. http://www.ripublication.com

11958

Applicability of a Strategic TPM Release Planning Model on a

CRM Project Case

Samia Naciri1 and Mohammed Abdou Janati Idrissi2

1TIME team, ENSIAS, Mohammed V University In Rabat, Morocco. 2 TIME team, ENSIAS, Mohammed V University In Rabat, Morocco

Abstract

Building an effective release planning roadmap for pending

change requests and providing a whole visibility on customer

expectations remain among the main purposes of Third Party

Application Maintenance (TPM), while considering several

change requests characteristics and multiple conflicting

objectives. Furthermore, in outsourcing contract, service level

agreements (SLA) compliance is required in the release

planning process and might generate penalties to the

maintainer if TPM providers do not control SLA through an

efficient Release Planning (RP) process. In a previous paper,

we proposed a strategic TPM Release Planning Model (S-

TRPM). This Integer linear programming model supports, in a

systematic way, TPM manager’s decisions of when to deliver

customer’s change requests. In this paper we show the

applicability of our model on a large CRM project that was

maintained using an ad hoc release planning. We will also

compare the Change Requests release plans obtained by the

two models in terms of: roadmap visibility, SLA contractual

commitment and customer satisfaction degree.

Keywords: Software Engineering; Software Maintenance;

Third Party Application Maintenance; TPM; Release

Planning; Search-based software engineering; SBSE.

INTRODUCTION

The Third-party application maintenance (TPM) is a

particular type of outsourcing referring to the delocalization

of products maintenance. TPM allows companies to control

Information Technology costs, to improve products quality

and evolutivity, and to harness external resources to maintain

their software [1]. However, running TPM projects raises new

challenges for both companies requesting and providing such

services. One of the most challenging tasks within TPM

software process development relates to release planning as

summarized in [2], [3], [4].

Release planning aims to select an optimal set of change

requests to deliver in a release within constraints

consideration. From TPM point of view, software release

planning is considered as a tedious task. It takes into account

the perspectives of project stakeholders, integration problems,

functional and non-functional requirements, existing

technologies, anticipating coming changes, service

commitment, concurrency and other goals. The

interdependencies between change requests can be also

considered [5].

Scheduling requested changes and planning their delivery in

upcoming releases is considered as a strategic release

planning activity (called also Software Delivery Roadmap)

and not operational release planning activity [6], [7]. Strategic

RP involves the selection and assignment of requirements to

sequences of upcoming releases, in respect of technical and

organizational constraints. Once a strategic plan is generated,

a decision is made on what features should be part of which

release, while operational planning focuses only on the

selection of features to be included in the next release [8], [9].

Software engineering literature classify the Release planning

as a “Wicked problem”, [10] which means a problem

difficult to define and often, it has no clear and definitive

solution.

Release Planning exists on two main approaches. In [11],

Saliu and Ruhe have categorized software RP into ad-hoc RP

approach and science based RP approach. They have also

considered a hybrid RP approach that enjoys the benefits of

both categories to be the most effective. State of art practices

in software maintenance RP indicates that, typically, ad-hoc

RP is the most commonly used in the engineering industry

using judgment and experience of engineering staff.

We have proposed in our previous work [12] a Strategic

Release Planning model(S-TRPM) to support TPM manager

in RP process. This model aims to plan pending change

requests over a releases roadmap in a systematic way.

The first contribution of this model over existing works is the

consideration of contractual commitment in terms of service

levels agreement (SLA) which is not covered fully by existing

RP models. The second is to produce a maintenance roadmap

giving to the customers a whole visibility on the next releases

and when to deliver pending change requests contrary to the

RP. Furthermore, this generated release roadmap allows

customer and TPM manager to improve the software

evolution planning by scheduling efficiently major evolution

releases considering maintenance releases dates.

Our proposed approach is designed for outsourced software

maintenance, generating huge volume of change requests

affecting directly the use of the software under maintenance.

In our previous paper, we have applied our proposed model to

mailto:[email protected]



11959

a virtual testing dataset. In this paper, we try to show the

applicability of our model on a large TPM CRM project that

was maintained using an ad-hoc RP process. We aim also to

evaluate the performance of our proposed model compared

with the applied ad-hoc RP on this industrial case.

The Customer Relationship Management (CRM) is one of the

company’s business drivers requiring reliable software

support. This work applies our proposed S-TRPM on a CRM

Software case which is designed to help business meet the

companies CRM strategy goals. CRM software should be

reliable, available, robust and just in time. Managing

efficiently the maintenance phase of CRM software remains a

complex activity, specifically in TPM context. Business and

market conditions drive companies to focus effort on core

business and to outsource support activities like CRM

software maintenance.

The remainder of this paper is structured as follows: Section 2

presents related work and our proposed Strategic TPM RP

approach. Section 3 presents the CRM project case, the

applied ad-hoc RP processes and how are captured the inputs

of the RP process. Section 4 presents our resolution approach

and inputs in terms of variables and parameters, and then we

discuss the results of applying our S-TRPM to this CRM case

using lp_solve(a free linear integer programming solver based

on the revised simplex [13]) before concluding.

S-TRPM: A STRATEGIC TPM RP MODEL

As it was reviewed and analysed in our previous paper [12],

existing works don’t propose a strategic vision through a

release roadmap for TPM, they only focus on the next release

problem (NRP). Their proposals are often limited to one

release (the next release) or two software releases without

managing SLA constraint of TPM context. However, in TPM

context, managers require a full visibility on next releases

through a maintenance roadmap. Furthermore, few existing

works were validated by case studies derived from software

maintenance industry in outsourcing mode [14].

The EVOLVE models propose a comprehensive approach to

address the RP problem. However, it does not lead with SLA

constraints or roadmapping expectations in TPM context [15],

[16], [17].

Bagnall optimization [18], [19], COVAP [20], Provotype

[21], [22], [23], IFM [24] models addressed NRP but didn’t

tackle the TPM problematic in terms of compliance with

contractual obligation of the subcontractor, manage urgent

change requests, and generate roadmap. PASM (Process for

Arranging Software Maintenance Requests) advocates

consolidating maintenance requests in projects to challenge

ahead the benefit of grouping change requests in software

releases. This last helps to save allocated costs. However, it

fails to consider business factors to assess the customer

satisfaction degree, or risks associated with grouping CR [25].

S-TRPM Approach

Our proposed S-TRPM, Strategic TPM RP approach aims to

construct a roadmap of CR releases in outsourced projects.

The word strategic involves producing several releases [26]

which include all pending CRs, providing in result a global

maintenance roadmap, difficult to construct using an ad-hoc

RP process.

CR often arises when the client wants an addition, correction

or alteration to the agreed-upon deliverables [27]. Indeed,

releases are classified to enhancive releases, corrective

releases or mixed releases [12].

This approach concerns corrective releases. It helps TPM

managers planning releases without having an advanced

knowledge (functional and technical details) on CR.

Thereafter, it allows more effective software process

improvement and synchronization in both side’s customers

and TPM companies.

Our proposed approach considers four main constraint

categories (business constraints, resource constraints, system

constraints and monitoring constraints) and is based on five

stages as shown in figure 1. A deep description of these

constraints categories can be found in our preceding paper

[12]

Figure 1: Strategic TPM release planning approach [12].

1) Qualification stage: this stage which is executed by the

support chain team aims to identify the corrective CRs to be

planned. The team assesses the severity and urgency of each

CR and collects additional details of the request sender and

CR.

2) Evaluation and strategy choice stage: This stage involves

the consolidation and integration of the collected information

from the qualification stage in order to evaluate selection

factors for each CR described previously. This stage includes

a sub stage named “constraints capture” allowing to collect

resource constraints and to define RP policy. The release

delivery policy describes which factor will be considered to

limit the scope of releases. Define a delivery policy is

important in RP process. It can be of three types (Fixed cost

policy, Fixed number of CR policy or Fixed time policy).

3) Strategic TPM RP generation stage: It concerns the CRs

distribution to software releases, called also roadmapping.

Based on evaluation stage results, this stage searches for an

optimal combination of CRs, which maximizes stakeholder

satisfaction and CR business value within the constraints

respect. This stage includes several iterations depending on

CR stock.



11960

4) Execution stage: it’s a working stage of TPM team when

the next release is built.

5) Feedback capture and analysis stage: this stage is

essential to capture information concerning the quality of the

delivered releases and CRs and helps to improve next

releases.

S-TRPM formulation

According to the proposed approach, the third stage (strategic

TPM RP generation) involves an iterative activity; in each

iteration we fix the content of a current release. The process is

repeated until all pending change requests will be planned.

In [12], we have formulated this stage as an integer linear

programming model where we have used and adopted the

following sets and assumptions:

𝑫 = { 𝒅𝟏, 𝒅𝟐, … , 𝒅𝒏} the Change Requests to be

schedule and still present in the TPM backlog in the

beginning of a given iteration. D will be updated at each

iteration.

𝑹 = {𝑹𝟏, 𝑹𝟐, … , 𝑹𝒎} the maintenance releases set

where m corresponds to the number of iterations needed

by the third stage. CRs are affected to corrective

software releases named “Rk”, with Rk delivery date the

closest to the current date.

𝑪 = {𝒄𝟏, 𝒄𝟐, . . , 𝒄𝒕} represents stakeholders of the

software product. Inspired from [11], the TPM team can

assign to each customer a weight or a degree of

importance 𝜶 ∈ {𝟏, 𝟑, 𝟓, 𝟕, 𝟗}. Formally, 𝜶 ∈{𝟏, 𝟑, 𝟓, 𝟕, 𝟗} may mean respectively: ignored / not

important / neutral / important / very important. We will

note α(cj,di ) the customer weight concerned by the

change request di.

CR urgency: Depending on the emergency of each CR

di, a CR can be of high, normal or low urgency.

Considering the function urgency with urgency(di)

∈{U1,U2,U3} where U1,U2 and U3 are predefined

constants values. This function associates to each

urgency level one of the mentioned constants.

CR severity:

considering 𝑺𝒆𝒗 = {𝐻𝑖𝑔ℎ, 𝑀𝑒𝑑𝑖𝑢𝑚, 𝐿𝑜𝑤}, a severity

set defined for the Software Maintenance project, each

CR di depending on its severity level has a predefined constant (TC(High)/ TC(Medium)/TC(Low)) using a function TC( ).

The rest of the model is as follows:

Decision variables

Xk is a vector of binary decision variables. For each release

Rk :

𝑿𝒌 = (𝒙𝒌(𝒅𝒊))

𝑤𝑖𝑡ℎ 𝑖 = 1 … 𝑛 and 𝒙𝒌(𝒅𝒊)= 1 if the Change Request di has

not been assigned to Rl with l<k and assigned to the release

Rk. 𝒙𝒌(𝒅𝒊)= 0 otherwise. As consequence, we will

have∑ 𝑥𝑙(𝑑𝑖) ≤ 1𝑘

𝑙=1, for each di at each iteration k.

Objective function

To satisfy customers according to their weights and Change

Requests emergency degree, our S-TRPM proposes the

following objective function for each release Rk:

𝑴𝒂𝒙 ∑ ∑ 𝜶(𝒄𝒋, 𝒅𝒊) ∗ 𝒖𝒓𝒈𝒆𝒏𝒄𝒚(𝒅𝒊

𝒕

𝒋=𝟏

) ∗ 𝒙𝒌(𝒅𝒊)

𝒏

𝒊=𝟏

(𝟏)

The objective function aims to prioritise the change requests

that have both high urgency level and customer importance

weight.

Our model proposes to satisfy constraints detailed below:

Business constraints :

(𝑑𝑒𝑙𝑖𝑣𝑒𝑟𝑦𝑑𝑎𝑡𝑒(𝑑𝑖) − 𝑐𝑟𝑒𝑎𝑡𝑖𝑜𝑛𝑑𝑎𝑡𝑒(𝑑𝑖)) ∗ 𝒙𝑙(𝒅𝒊) ≤

𝑇𝐶(𝑆𝑒𝑣(𝑑𝑖)) ∗ 𝒙𝑙(𝒅𝒊) (2)

𝑑𝑖 ∈ 𝑅𝑘 , 𝑖 = 1, … 𝑛,

This last corresponds to the SLA constraint where the

delivery_date and creation_date are input parameters defined

for each CR and TC (Sev (di)) as defined above.

Resource constraints:

∑ ∑ 𝐶𝑜𝑠𝑡(𝑑𝑖) ∗ 𝒙𝑙(𝒅𝒊) 𝑖 ≤ 𝑏𝑢𝑑𝑔𝑒𝑡𝑘𝑙=1, (3)

(4) means that the release costs is under the allocated budget

of the global roadmap. Cost (di) and budget are input

parameters expressed in man-days. Budget is calculated based

on working man days.

(∑ 𝑒𝑓𝑓𝑜𝑟𝑡(𝑑𝑖)) ∗ 𝒙𝑘(𝒅𝒊) ≤ 𝛽

𝑛

𝑖=1

(𝑅𝑘) (4)

𝛽 corresponds to the available team effort defined by the TPM

manager for each Rk.. The effort () function returns the

required effort for each CR di.

System constraints:

𝑥𝑘(𝑑𝑖) = 𝑥𝑘(𝑑𝑖′) (5)

∀(𝑑𝑖 , 𝑑𝑖′) ∈ 𝐶𝑜𝑜𝑝𝑙𝑖𝑛𝑔 𝑠𝑒𝑡

Coupling means that the implementation of 𝑑𝑖 and 𝑑𝑖′ must

be scheduled in the same release.

∑ (𝑘

𝑙=1𝑥𝑙(𝑑𝑖′)) ≥ 𝑥𝑘(𝑑𝑖) , (6)

∀(𝑑𝑖 , 𝑑𝑖′) ∈ 𝑃𝑟𝑒𝑐𝑒𝑑𝑒𝑛𝑐𝑒 𝑠𝑒𝑡

Precedence means that the implementation of 𝑑𝑖 must precede

𝑑𝑖′ .

Constraints (5) and (6) express the dependencies constraints

that can exist between change requests.

Delivery policy constraints:

According to the maintenance delivery policy, we can add one



11961

or some of the three formulas bellow depending on the

business owner:

If delivery policy is a fixed time,

𝑑𝑒𝑙𝑖𝑣𝑒𝑟𝑦_𝑑𝑎𝑡𝑒(𝑅𝑘) − 𝑑𝑒𝑙𝑖𝑣𝑒𝑟𝑦_𝑑𝑎𝑡𝑒(𝑅𝑘−1) = 𝐷𝐼𝑆𝑇 (7)

Where DIST is a constant and delivery_date (R1) is fixed.

If delivery policy is a fixed cost,

∑ 𝐶𝑜𝑠𝑡(𝑑𝑖) ∗ 𝒙𝑘(𝒅𝒊)

𝑖

≤ 𝑏𝑢𝑑𝑔𝑒𝑡(𝑅𝑘) (8)

Where Cost (di) and 𝑏𝑢𝑑𝑔𝑒𝑡(𝑅𝑘) is defined

If delivery policy is a fixed CR number,

𝑐𝑎𝑟𝑑 (𝑅𝑘) ≤ 𝑁 (9)

where 𝑁 𝑖𝑠 𝑎 𝑔𝑖𝑣𝑒𝑛 𝑐𝑜𝑛𝑠𝑡𝑎𝑛𝑡 for all Rk

The given formulation of the TPM RP problem with equations

(1) to (9) constitutes an optimization problem that will require

efficient optimization algorithms to be solved. In section 5,

we will propose a resolution approach using an integer

programming framework.

In the next sections of this paper, we will apply our proposed

S-TRPM to a CRM project part of Tradecom company

projects portfolio. This large CRM project used an ad-hoc

approach to manage the CR release planning in TPM contract.

We aim through this case study to show the benefit of our

model in a real world release planning situations compared

with the ad-hoc RP approach.

A CRM CASE STUDY

This section describes the context of this CRM case study. It

presents the third party company (maintainer) and the

maintained software in the TPM contract. It describes also the

ad-hoc processes used to manage the TPM contract. Data

presented in this case are captured from this CRM case

repository and the presentations support.

Tradecom Company manages large and complex telecom

projects with outsourcing contracts such as ABC project

treated in this paper.

The ABC product is a complex and multi-business software

that supports ABC customers from end to end by providing an

order to cash solution. It is a modular solution, composed of 4

modules. In this study we focus on the front-end module

which manages web user’s interactions. This project has a

complex stakeholder organization composed on 5 levels that

start with the customer and end with the TPM team.

Support and maintenance services: With TPM contract,

ABC TPM team provides support and maintenance services

for the studied module. ABC product support chain is

organized on three levels in respect of ITIL (Information

Technology Infrastructure Library) standards. A CR escalates

from one level to other, depending on analysis result of the

upper level.

Level 1 or helpdesk: this first level receives all

rudimentary and repeated CR that the client or end

users submit daily.

Level 2: ensures and checks that the users and the

level 1 provide all necessary information helping to

analyse the CR. This level priority is to provide a

final or a workaround solution to establish the initial

service and then ensures that the software

specifications are in line with customer perception.

Level 3: if the CR is not resolved at level 2, level 3

solves the CR by acting on the production

environment or confirming that the CR has an

application origin requiring the intervention of

software maintenance team.

If the CR is still not resolved beyond level 3, the CR moves to

the maintenance team for a corrective action.

APPLICATION OF THE AD-HOC RP PROCESS ON

THE CRM ABC PROJECT

Approach

ABC project faces several challenges in release planning

process which are the lack of a continuous visibility of when

to deliver customer’s CRs, how much releases TPM team

must built, since the CR number changes frequently, the

multiplication of regression risk, the customer dissatisfaction

and so on.

To deal with these RP challenges, ABC project adopted an

improved ad-hoc RP process (from 2011 to 2012) that aims to

allow customers to have better visibility on CR delivery and

to guaranty the software quality. This ad-hoc RP produces a

release plan based on the improved rules, as illustrated in

Table 1.

Table 1: ad-hoc RP rules

rule 1 The ad-hoc RP process defines a maintenance

roadmap and fixes the frequency of release

delivery. (One release per month).

rule 2 A new ticketing tool is added to better support

maintenance process activities and logs CR

information.

rule 3 For each release, TPM manager defines the

followings milestones: Acceptance date(M3), Start

pilot phase (SPP) and the move to production

date(MTP).

rule 4 Urgent or critical CRs are to be scheduled in non-

planed (urgent) release in parallel with the

maintenance roadmap.

rule 5 Provide a Weekly Roadmap reporting that takes

account of customer expectations.



11962

This ad-hoc RP process allowed ABC maintenance team to

work more efficiently in each release and to avoid scope

frequent changes.

Inputs and results

The ABC ad-hoc RP process inputs are gathered from the

ticketing tool (for CR data) and from the TPM contractual

commitments (for SLA and budget).

Business parameters: The ABC contractual commitments

considers 3 urgency levels: Low, Normal and High and 3

severity levels: Critical, Major and Minor. Time of Correction

(TC) associated to these severity levels are respectively, 2

days, 4 days, and time to the next evolving release. If a critical

or Major CR has a workaround solution, the TC will be the

time of the next release.

The business owner evaluates the customer's weights based on

several criteria, as: customer history, customer revenue,

customer temperament and other subjective factors.

CR parameters: Table 2 illustrates the CR data structure

captured from the ABC ticketing tool related to our work. 95

is the number of CR gathered and scheduled in year 2011.

“CR dep.” presents dependent CRs.

“Dep. Type” is the type of dependency that exists

between CRs. Dep. type =1 if the CRs and its

dependent CRs are in coupling relation, dep. type

=2 if the CRs and its dependent CRs are in

precedence relation.

Table 2: CR data structure

CR d1 d2 d3 d4

Creation

date 01/02/2011 02/04/2011 03/05/2011 04/06/2011

Customer C1 C2 C1 C3

Severity Major Minor Critical major

Urgency Low Normal High Normal

Cost 5 3 5 4

CR dep.

d1

d3

Dep.

Type

1

2

Allocated resources parameters: Yearly, ABC stakeholders

define the contractual commitments related to the allocated

resources, Budget and maintenance team composition. TPM

budget depends on CR numbers for previous year, future

enhancement demands and business roadmap. Therefore, the

releases costs must not exceed the given budget.

ABC budget is equal to 2 FTE (Full Time Equivalent, FTE of

1.0 is equivalent to a full-time worker). The availability of

TPM team is a selector factor that helps to decide how much

time to allocate for maintenance activity. This CRM project

considers team effort at 100%, since TPM team dedicates 2

members fully to the software maintenance.

Figure 2: detailed ad-hoc RP roadmap

Delivery policy parameters: release delivery policy

describes, as mentioned in section “Delivery policy

constraints”, which factors to consider to limit the scope of

releases. Define a delivery policy, share it and approve it with

all project stakeholders is essential for an efficient TPM

management. In this project, the management team has

decided to fix the duration between releases (monthly

delivery). The constant “DIST” value is approximately equal

to 31 days.

Results: The ad-hoc RP results are extracted from ABC

project repository and then analysed. Table 3 and Table 4

show the main figures of the extracted data. 95 CR was

planned over the year 2011 in 16 releases.

Table 3 : ad-hoc RP results

CR

number

Studied

Period

Customers

number

Budget

allocation

Releases

number

95 Year

2011

14 2 FTE 16

w1 w2 w3 w4 w5 w6 w7 w8 w9 w10 w11 w12 w13 w14 w15 w16 w17 w18 w19 w20 w21 w22 w23 w24 w25 w26 w27 w28 w29 w30 w31 w32 w33 w34 w35 w36 w37 w38 w39 w40

Dev-Tronc

Dev-Branch

Dev-Branch

Pilote phase

Generalisation

(Prod)

pilot phase(open to customers) ROCO : release release delivery

July August September OctoberJanuary February March April Mai June

C1

C1

11/08

C2

23/09

C2

R6

R6C0

C0

23/07

G4R621/06

R6C4

19/07

C4

R5

C3

16/06C2

22/05

C2

C1

17/05

C1

G4R5

29/03

G4

C10

R4

C9

07/04

C9

C8

15/03

C8

C7P1

01/03

C7P1C6

C5

12/02

C5

03/02

C5

R3 R4 R5 R6

C418/01

R4C4

C10

05/05

C6

22/02

C2

07/06

C3

C0

06/08C2

04/10

C3

C7

03/03



11963

Table 4 presents the number of CR and releases delivered

each month in both software environments pilot and

production.

Table 4 : ad-hoc roadmap data and delivered CR per month

Month 1 2 3 4 5 6 7 8 9 10

Total of delivered CR 11 29 15 5 11 9 5 7 3 0

Pilot releases 1 2 3 1 3 2 2 1 1 0

Production releases 0 2 1 1 1 2 1 1 0 1

The ad-hoc RP process allowed for ABC project customer a

visibility (to know when to deliver CRs). For the ABC

maintenance provider, ad-hoc RP allowed to work more

efficiently in each release and to avoid conflict with customer.

However, this ad-hoc RP leads to an arduous daily task for

TPM manager that requires to plan manually submitted CR.

The synchronization with evolving releases generated a

technical challenges and integration problems for the

maintenance team particularly when deciding to merge or

generalize releases.

The schema in Figure 2 presents the ad-hoc RP roadmap of

year 2011. In yellow background, each bloc represents a

delivered release: Dev-tronc for maintenance (corrective)

releases and Dev-branch for evolving releases. Orange

background (in the bottom) represents the installation

environment for releases (maintenance and evolving) over the

year 2011 in the two deployment environments (pilot and

production).

APPLICATION OF THE S-TRPM MODEL ON THE

CRM ABC PROJECT

This section will describe how we have applied and

implemented our proposed S-TRPM to the CRM ABC project

and the results we have obtained.

Resolution approach and implementation

As mentioned in section 2.2, our S-TRPM model adopts an

iterative approach as shown in Figure 3. In each iteration k,

we will call an S-TRPM algorithm which is the

implementation of our model to the still non-planned CRs in

the iteration k to produce release Rk (planned CRs in Rk) and

reject CRs that not respect the given constraints.

Figure 3: S-TRPM resolution approach

To implement our S-TRPM algorithm, we opted to develop

our own java program that calls the lp_solve libraries which is

a free Mixed Integer Linear Programming solver [13] based

on the revised simplex and the Branch-and-bound methods.

The main steps of this S-TRPM algorithm are shown in Table

5.

S-TRPM algorithm represents Xk(di) the decision to include di

in Rk using a bit string with n bits. Each bit in the string

corresponds to a CR, and is set to 1 if the CR is included in

the Rk and 0 if the CR is excluded.

Our S-TRPM algorithm inputs (data and parameters) are

gathered from the ABC CRM project data. Main inputs are

outlined below.

- Sev ∈ {Critical, Major or Minor} having respectively

TC = {2, 4, 30}.

- Urgency ∈ {1: not, 3:low, 5: normal, 7: high}, we

use an ordinal seven-point scale here to allow

sufficient differentiation in the degree of urgency.

- Customer weight α∈ {1, 3, 5, 7, 9} and may mean

respectively: ignored / not important / neutral /

important / very important.

- Delivery policy: as referred previously, in the ABC

project, the constant value “DIST” is approximately

equal to 31j. The freeze period is 15 days before each

Rk delivery date.

- Cost, budget and team effort: the TPM budget of

ABC is defined as two FTE. 2 persons of the TPM

team are 100% allocated for maintenance tasks.

Table 5: S-TRPM algorithm

I-1 Build the D set: D includes CR di not yet scheduled

for which the creation date is less than or equal to

the freeze date. Each di is represented by a java

object of structure seen in Table 2

I-2 -set k=1

-set the delivery date and the freeze date of R1

I-3 While they still exist di which are at the same time

not planned and not rejected :

-set the Rk release Name,

-set the Rk delivery date and the freeze date

-do I-31

R1 content

S-TRPM algorithm

CRs file

Rk content

Generated Solution

Generated solution

R2 content

Non-

planed

CRs

Generated solution

Rejected

CR

S-TRPM

algorithm

S-TRPM

algorithm



11964

I-31 (To build the objective function inputs), for each of

these di do :

-calculate the objective function value :

"𝜶(𝒄𝒋, 𝒅𝒊) ∗ 𝒖𝒓𝒈𝒆𝒏𝒄𝒚(𝒅𝒊)"

-define Xk(di) integer type and values ranges

-if sev(di) is high or critical with a workaround

solution, define the TC extension time

I-32 Build dependencies constraints

I-33 Build resource constraints

I-34 Build SLA constraints, if the SLA constraints of di

is not respected, set the di state=rejected

I-35 Call the solver factory of lp_solve libraries

I-36 Build the Rk : read the solver generated bit string

which constitutes the Xk vector then update each

object of these di if its corresponding bit is equal to

1

- di release name = release name

- di delivery date = release delivery date

- di state = “planned”

- go to I-3

I-4 Write di objects in flat file (RP roadmap)

RESULTS AND DISCUSSION

Our resolution approach allows us to generate a release

planning roadmap of the CRM TPM project as showed in

Figure 4.

Figure 4 : The generated S-TRPM roadmap

In this section, we will compare results of the ad-hoc RP

process and the ones obtained by our S-TRPM model. The

roadmaps generated by these two models will be compared

according to two axes CR delivery date and SLA time of

correction (TC) commitment.

Regarding to axe 1:

The comparison of the delivery dates obtained by the

generated roadmaps of the two models can be summarized as

shown in Figure 5.

Figure 5: CRs delivery dates comparison

We note that 75% of change requests are scheduled in the

same release month (6% of CR are in the same date, 31% of

CR are in the same calendar month and 38% of CR are

delivered in less than 20 days of difference).

8% of change requests are not conform to the real delivery

period (delivered after more than 60 days of our RP model

proposition).

Several reasons may exist to explain the difference between

S-TRPM delivery dates and ad-hoc delivery dates. Firstly, the

extracted CR data does not trace customer decision to include

or delay a CR in the release, neither the urgent releases

decisions. In real context, customer may decide to include or

exclude a CR if the customer business context changes. A real

roadmap is based on human decision which remains a

subjective decision taking in consideration current context of

CRs and customers. We can also add the lack of all CR

dependencies data.

Regarding to axe 2:

Our generated roadmap allows us to monitor easily the SLA

of each CR. This work considers the SLA correction time

(TC) which is the difference between delivery date and

creation date. In table 7, we compare the CRs generated TC of

the two models. We observe than more than 49% of CRs have

a S-TRPM generated TC better than the ad-hoc RP TC. 11%

of CRs have an ad-hoc RP TC better than the S-TRPM

generated TC.

40% of CRs left are still have a better ad-hoc RP TC because

the freeze date and the delivery policy are not respected.



11965

Table 6: SLA TC comparison

Number of CR by severity

Min

or

ma

jor

Cri

tica

l

To

tal

Generated TC (lp_solve ) 40 12 2 54

Real TC (ad-hoc) 8 1 9

Real TC with non-respect of freeze date

11 6 17

Real TC with non-respect of policy

9 6 15

Total 68 25 2 95

In addition to the comparison done by the two axes mentioned

above, we can note that our model succeeds to plan 85% of

the CRs in the input file. The 15% non-planned CRs are not

scheduled by S-TRPM model because they have an exceeded

TC. SLA commitments expressed with formula (2) in our

model are difficult to satisfy in large and complex projects.

The main goal of TPM manager in the ad-hoc RP, in regard of

the CRs for which SLA deadline is exceeded; is to minimize

penalties by including the maximum number of CRs as soon

as possible in first releases.

CONCLUSION

In previous work, we have proposed a Strategic Release

Planning model (S-TRPM) for TPM projects. The goal is to

help TPM managers plan releases without having an advanced

knowledge (functional and technical) on CRs while respecting

the given constraints, allowing more effective software

process improvement and synchronization in both sides

customers and TPM companies.

In this paper, we have applied our proposed integer linear

programing model(S-TRPM) to a real TPM CRM project.

Our model generates for this case study and in a systematic

way a releases plan with 75% of CRs scheduled in the same

calendar month compared with the ad-hoc RP process and

furthermore respecting all the TPM constraints. Moreover,

49% of planned CRs have a better SLA than the ad-hoc RP

process. These SLA are easily monitored using our flexible

approach, allowing a best control of maintainer penalties.

In future work, we aim to apply our model in more real

projects and investigate how to deal with the non-planned

CRs.

REFERENCES

[1] G. Hu, C. Saunders et M. Gebelt, «Research Report:

Diffusion of Information Systems Outsourcing: A

Reevaluation of Influence Sources,» Information Systems Research, 1997.

[2] S. Naciri et M. A. Janati Idrissi, «Third-Party

Application Maintenance Management,» International Journal of Computer Applications, oct 2014.

[3] A. April, J. Bouman, A. Abran et D. Al-Shurougi,

«Software Maintenance in a Service Level Agreement:

Controlling the Customers Expectations,» FESMA, 2000.

[4] A. April, «Studying Supply and Demand of Software

Maintenance and Evolution Services,» In Quality of Information and Communications Technology (QUATIC), 2010 Seventh International Conference, 2010.

[5] A. S. Danesh et R. Ahmad, «Software Release Planning

Challenges in Software Development: An Empirical

Study,» African Journal of Business Management, 2012.

[6] A. Pitangueira, R. Maciel, M. Barros et A. Andrade, «A

Systematic Review of Software Requirements Selection

and Prioritization Using SBSE Approaches,» In International Symposium on Search Based Software Engineering, Springer Berlin Heidelberg, 2013.

[7] A. Pitangueira, P. Tonella, A. Susi, R. Maciel et M.

Barro, «Risk-Aware Multi-Stakeholder Next Release

Planning Using Multi-Objective Optimization,»

Requirements Engineering: Foundation for Software Quality, 2016.

[8] Y. Zhang, M. Harman, G. Ochoa, G. Ruhe et S.

Brinkkemper, «An Empirical Study of Meta-and Hyper-

Heuristic Search for Multi-Objective Release Planning,»

Research Note :UCL Department of computer science, 2014.

[9] X. Cai, O. Wei et Z. Huang, «Evolutionary Approaches

for Multi-Objective next Release Problem,» Computing and Informatics, 2012.

[10] A. Seyed Danesh, R. Ahmad, M. R. Saybani et A. Tahir,

«Companies Approaches in Software Release Planning --

Based on Multiple Case Studies,» Journal of Software, 2012.

[11] G. Ruhe et M. O. Saliu, «The art and science of software

release planning,» IEEE Software, 2005.

[12] S. Naciri, M. A. Janati Idrissi et N. Kerzazi, «A strategic

release planning model from TPM point of view,» In 2015 10th International Conference on Intelligent Systems: Theories and Applications (SITA), 2015.

[13] M. Berkelaar, K. Eikland et P. Notebaert, «lp_solve:

Open source (mixed-integer) linear programming

system,» http://groups.yahoo.com/group/lp_solve, 2004.

[14] D. Ameller, C. Farré, X. Franch et G. Rufian, «A Survey

on Software Release Planning Models,» Product-Focused Software Process Improvement: 17th International Conference, PROFES 2016. Springer International Publishing, 2016.



11966

[15] G. Ruhe et D. Greer, «Quantitative Studies in Software

Release Planning under Risk and Resource Constraints,»

Empirical Software Engineering, 2003.

[16] O. Saliu et G. Ruhe, «Software release planning for

evolving systems,» Innovations in Systems and Software Engineering, 2005.

[17] P. Bhawnani et G. Ruhe, «ReleasePlanner-Planning new

releases for software maintenance and evolution,» In Industrial Proceedings of the 21st IEEE International Conference on Software Maintenance, 2005.

[18] G. Ruhe et A. Ngo, «Hybrid Intelligence in Software

Release Planning,» International Journal of Hybrid Intelligent Systems, 2004.

[19] A. J. Bagnall, V. J. Rayward-Smith et I. M. Whittley,

«The next Release Problem,» Information and Software Technology, 2001.

[20] J. Karlsson et K. Ryan, «A Cost-Value Approach for

Prioritizing Requirements,» IEEE Software, 1997.

[21] P. Carlshamre, «Release Planning in Market-Driven

Software Product Development: Provoking an

Understanding,» Requirements Engineering, 2002.

[22] J. Ho et G. Ruhe, «Releasing sooner or later: an

optimization approach and its case study evaluation,» In Proceedings of the 1st International Workshop on Release Engineering. IEEE Press, 2013.

[23] J. Ho, S. Shahnewaz et G. Ruhe, «A prototype tool

supporting when-to-release decisions in iterative

development.,» 2nd International Workshop on Release Engineering(RELENG), 2014.

[24] M. Denne et J. Cleland-Huang, «The Incremental

Funding Method: Data-Driven Software Development,»

Software, IEEE, 2004.

[25] G. A. Junio, M. N. Malta, H. A. Mossri, H. T. Marques-

Neto et M. T. Valente, «On the benefits of planning and

grouping software maintenance requests,» Software Maintenance and Reengineering (CSMR), 2011 15th European Conference, 2011.

[26] M. Svahnberg, T. Gorschek, R. Feldt, R. Torkar, S. B.

Saleem et M. U. Shafique, «A systematic review on

strategic release planning models,» Information and Software Technology, 2010.

[27] H. Marques-Neto, A. Gladston J. et V. Marco Tulio, «A

quantitative approach for evaluating software

maintenance services,» Proceedings of the 28th Annual ACM Symposium on Applied Computing, 2013.

applicability of a strategic tpm release planning model on ... · pdf fileobjectives....

Documents