300 likes | 428 Views
On the Benefits 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 ).
E N D
On the Benefits 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
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
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
PASM • Three phases: • Registration • Grouping • Processing
1st Phase: Registration • Pre-defined time frame for registration • Typicalrequests are buffered • Users can specify that a request is urgent • Ifratifiedbytheprocess manager: • Requestgoesdirectlytoimplementation • No waiting-costs
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
3rd Phase: Processing • PASM does not fix a development method
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
Metrics • QueueTime = WaitTime + ServiceTime • Service Time = PlanningTime + AnalysisTime + ImplementationTime + ValidationTime + DeploymentTime
Methodology • Classifytherequests in thefollowinggroups: • Before PASM, Urgent • Before PASM, Project • After PASM, Urgent • After PASM, Project • For eachrequest in eachofthepreviousgroups • Generatethe SMRMG • Generate a vector withthepreviousmetrics • For thevectors in eachgroup • Apply a clusteringalgorithm (k-means)
Goal with Clustering • Discover the characteristics of the typicalprojects • Before PASM • After PASM • Evaluate the positive and negative effects of the PASM adoption on such projects • Discover the characteristics of typicalurgentrequests • Before PASM • After PASM • Evaluate the positive and negative effects of the PASM adoption on such requests
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
PASM @ 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
Data Source • Same sequence of months: • Before PASM: February-October 2008 • After PASM: February-October 2009
Maintenance Projects: Clusters • QueueTime: + 32% • ValidationTime: +139% • ValidationTime / ServiceTime • 2008: 22% • 2009: 43% • ImplementationTime: - 32% • ImplementationTime / ServiceTime • 2008: 43% • 2009: 23% • AnalysisTime: +54% • AnalysisTime / ServiceTime: • 2008: 18% • 2009: 22%
Maintenance Projects: Summary • More projects: • Before PASM: 22 projects • After PASM: 62 projects • Dominant development task: • Before PASM: implementation (43%) • After PASM: validation (43%)
Typical Urgent Requests • ImplementationTime / ServiceTime • 2008: 50% • 2009: 41% • QueueTime: - 4 hours
Complex, Error-Prone, Urgent Request • ValidationTime / ServiceTime: • 2008: 48% • 2009: 59%
Urgent Requests: Summary • QueueTime, after PASM: • Typical requests: - 4 hours • Complex requests: + 1 hour (more time to validation)
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
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
Further Work • Promote and evaluate the PASM’s adoption by other organizations • Assess the internal and external quality of the software released under PASM guidelines 29
Thank you! My-email: mtov@dcc.ufmg.br