Mestrado em Inform - PowerPoint PPT Presentation

1 / 30
About This Presentation
Title:

Mestrado em Inform

Description:

On the Bene ts of Planning and Grouping Software Maintenance Requests Gladston Aparecido Junio (PUC Minas, Brazil) Marcelo Malta (PUC Minas, Brazil) – PowerPoint PPT presentation

Number of Views:36
Avg rating:3.0/5.0
Slides: 31
Provided by: Ricard219
Category:

less

Transcript and Presenter's Notes

Title: Mestrado em Inform


1
On the Bene?ts of Planning and Grouping Software
Maintenance Requests
Gladston Aparecido Junio (PUC Minas, Brazil)
Marcelo Malta (PUC Minas, Brazil) Humberto
Mossri (PUC Minas, Brazil) Humberto Marques-Neto
(PUC Minas, Brazil) Marco Tulio Valente (UFMG,
Brazil)
CSMR Oldenburg, Germany, March 2011
2
Motivation
  • Policies for scheduling maintenance requests
  • Continuous requests implemented as quick as
    possible
  • Periodic requests packaged in larger projects
  • In theory, the benefits of periodic policies are
    widely known
  • Several statistical models have been proposed
  • Example Banker et. al (30 of cost reduction)
  • Do such gains happen in real organizations?
  • Theoretical models have not been validated by
    field studies

3
In this Talk
  • Define a simple process called PASM for
    handling maintenance requests as projects
  • PASM Process for Grouping Maintenance Requests
  • Propose a methodology to evaluate maintenance
    policies
  • Evaluate the gains achieved by the PASM process
    in a real software development organization

4
PASM
  • Three phases
  • Registration
  • Grouping
  • Processing

5
1st Phase Registration
  • Pre-defined time frame for registration
  • Typical requests are buffered
  • Users can specify that a request is urgent
  • If ratified by the process manager
  • Request goes directly to implementation
  • No waiting-costs

6
2nd Phase Grouping
  • No rigid guidelines for grouping
  • Two forces size and cohesion
  • Size
  • Compatible with the production capacity
  • Should not imply in waiting costs that users
    will not tolerate
  • Cohesion
  • Requests of a project should be functionally
    coherent

7
3rd Phase Processing
  • PASM does not fix a development method

8
Characterization Methodoly
9
Characterization Methodology
  • How to evaluate the gains achieved by PASM in a
    real setting?
  • Adapted a methodology proposed to understand the
    behavior of web users
  • Central idea Software Maintenance Request Model
    Graph
  • Nodes states of each request
  • Edges transition between such states

10
Software Maintenance Request Model Graph
11
Metrics
  • QueueTime WaitTime ServiceTime
  • Service Time
  • PlanningTime AnalysisTime
  • ImplementationTime ValidationTime
  • DeploymentTime

12
Methodology
  • Classify the requests in the following groups
  • Before PASM, Urgent
  • Before PASM, Project
  • After PASM, Urgent
  • After PASM, Project
  • For each request in each of the previous groups
  • Generate the SMRMG
  • Generate a vector with the previous metrics
  • For the vectors in each group
  • Apply a clustering algorithm (k-means)

13
Goal with Clustering
  • Discover the characteristics of the typical
    projects
  • Before PASM
  • After PASM
  • Evaluate the positive and negative effects of the
    PASM adoption on such projects
  • Discover the characteristics of typical urgent
    requests
  • Before PASM
  • After PASM
  • Evaluate the positive and negative effects of the
    PASM adoption on such requests

14
Evaluation
  • We have evaluated the PASM process at DATAPUC
  • DATAPUC IT Department of PUC Minas
  • 34 developers
  • 40 systems, 4 MLOC
  • Until October 2008
  • (most) maintenance requests handled on demand, in
    a continuous way.
  • Starting on November 2008
  • DATAPUC has moved to the PASM process

15
PASM _at_ DATAPUC
  • Registering Phase first 10 days of each month
  • Grouping next 20 days
  • Requests are evaluated and grouped in projects
  • Cycle is repeated in the next month

16
Data Source
  • Same sequence of months
  • Before PASM February-October 2008
  • After PASM February-October 2009

Requests Before PASM (2008) After PASM (2009)
Urgents 1051 953
Projects 22 62
17
Results Maintenance Projects
18
Maintenance Projects Clusters
Metrics 2008 2008 2009 2009
Metrics Cluster 1(19 proj.) Cluster 2(3 proj.) Cluster 1(52 proj.) Cluster 2(10 proj.)
QueueTime 185,00 771,87 245,04 694,91
WaitTime 12,16 17,50 26,85 11,95
ServiceTime 172,84 754,37 218,19 682,97
AnalysisTime 31,51 7,48 48,71 141,61
PlanningTime 6,34 5,02 3,66 64,61
ImplementationTime 74,63 348,27 50,39 122,56
StandByTime 0,00 0,00 0,20 0,00
ValidationTime 39,34 377,46 94,19 249,70
DeploymentTime 21,01 16,14 21,04 104,49
  • ImplementationTime - 32
  • ImplementationTime / ServiceTime
  • 2008 43
  • 2009 23
  • ValidationTime 139
  • ValidationTime / ServiceTime
  • 2008 22
  • 2009 43
  • QueueTime 32
  • AnalysisTime 54
  • AnalysisTime / ServiceTime
  • 2008 18
  • 2009 22

19
Maintenance Projects SMRMG Probabilities
20
Maintenance Projects Summary
  • More projects
  • Before PASM 22 projects
  • After PASM 62 projects
  • Dominant development task
  • Before PASM implementation (43)
  • After PASM validation (43)

21
Results Urgent Requests
22
Urgent Requests SMRMG
23
Typical Urgent Requests
Metrics Cluster 2 - 2008(651 req) Cluster 5 - 2009(383 req)
QueueTime 16,79 12,82
WaitTime 2,80 3,22
ServiceTime 13,98 9,60
AnalysisTime 4,46 2,45
ImplementationTime 7,02 3,94
StandByTime 2,50 3,21
ValidationTime 0,00 0,00
DeploymentTime 0,00 0,00
  • ImplementationTime / ServiceTime
  • 2008 50
  • 2009 41
  • QueueTime - 4 hours

24
Complex, Error-Prone, Urgent Request
Metrics Cluster 5 - 2008(222 req.) Cluster 2 - 2009(212 req.)
QueueTime 25,82 26,51
WaitTime 3,56 3,05
ServiceTime 22,26 23,46
AnalysisTime 8,33 3,23
ImplementationTime 2,28 4,27
StandByTime 1,02 2,07
ValidationTime 10,63 13,89
DeploymentTime 0,00 0,00
  • ValidationTime / ServiceTime
  • 2008 48
  • 2009 59

25
Urgent Requests Summary
  • QueueTime, after PASM
  • Typical requests - 4 hours
  • Complex requests 1 hour (more time to
    validation)

26
Conclusions
27
Contributions
  • PASM Process for grouping maintenance requests
  • Lightweighted process
  • Three phases registration, grouping, processing
  • Methodology to evaluate maintenance policies,
    based on
  • Software Maintenance Request Model Graph
  • Clustering techniques
  • Classical queue model metrics
  • Field study to evaluate the benefits achieved by
    PASM

28
Benefits
  • More requests handled as projects
  • Side-effects
  • More time dedicated to analysis and validation
  • Less time dedicated to implementation
  • Urgent maintenance requests
  • Handled in less time

28
29
Further Work
  • Promote and evaluate the PASMs adoption by other
    organizations
  • Assess the internal and external quality of the
    software released under PASM guidelines

29
30
Thank you!
  • My-email mtov_at_dcc.ufmg.br
Write a Comment
User Comments (0)
About PowerShow.com