Gabriel de Souza Pereira Moreira - ITARoberto Pepato Mellado – ITARobson Luis Monteiro Júnior - ITAProf. Adilson Marques d...
 Introduction Case Study METACOM Results Limitations Conclusion2ITA - Instituto Tecnológico da Aeronáutica
 On the last decade, a growing interest onagile methods for software construction fromboth industry and academy has arise...
 Lehman defines the law of increasingentropy. He explains that, by a number offactors, a programming system undergoesneve...
XP Practices Project A Project B Project CSit Together X XInformative Workspace XEnergized Work X XPair Programming XStori...
Radar Chart is a visual indicator of XPpractices adoption. It is composed of fiveaxes, representing the dimensions of anXP...
 Metrics help software engineers to gainperception in the construction of productsthat they develop [Pressman 2009]. Pre...
 Lines of Code (LoC) - Number of valid class lines ofcode (excluding comments and blank lines); Afferent Coupling (AC) -...
 Three Brazilian industry projects: Project A,B, and Project C. Company process evolution: Ad-hoc, RUP,Agile Common com...
Project A B CPlatform Web Web ConsoleProgramming Language C# 2.0 C# 2.0 C# 3.5Development Start 08/2008 08/2009 07/2010Num...
 It was used just one XP practice.Therequirements analysis, documentation, andsystem design were conducted in thebeginnin...
 They worked distributed in two adjacent rooms,led by a technical leader which gave directionsfor the whole team. Develo...
 The requirements analysis anddocumentation were performed at theelaboration phase, the system design wasn’tentirely read...
 Average of 4 developers. Team was placed in the same room. The software product of Project B was 34%shorter than Proje...
 A higher number of agile engineeringpractices were applied in its development. The team was comprised of four developer...
 The Scrum Master responsibilities were spreadon the team. The team felt that lack of a dedicated ScrumMaster allowed to...
 Product quality was always the main focus ofthe team, and effort was dedicated tomitigate technical debts. The team app...
 Step 1 – RevisionsCheckout Step 2 – Build Step 3 – Static Analysis Step 4 – DataTransformation andLoad18ITA - Institu...
ITA - Instituto Tecnológico da Aeronáutica 19From left to right, Project A, B and C
ITA - Instituto Tecnológico da Aeronáutica 20
ITA - Instituto Tecnológico da Aeronáutica 21
ITA - Instituto Tecnológico da Aeronáutica 22From left to right, Project A, B and C
ITA - Instituto Tecnológico da Aeronáutica 23From left to right, Project A, B and C
ITA - Instituto Tecnológico da Aeronáutica 24From left to right, Project A, B and C
 The analysis conducted in this paper has usedhistorical measures fromVersion Control System(VCS) revisions. As it was n...
 Other variables that could cause impact onprojects like schedule pressures, resourcesavailability, team and management t...
 In this investigation it was conducted aninvestigation of three different softwaredevelopment projects history. Company...
 The major findings of this investigation pointedout that the average class measures for: Size (LoC and MPC); complexity...
 Analyse measures under other functions(max,min,std. Dev.) Analyse measures in different levels(packages, classes) Iden...
ITA - Instituto Tecnológico da Aeronáutica 30 Moreira, G. S. P., Mellado, R. P., Montini, D. A., Dias, L. A.V.,Cunha, A. ...
19 e 20 de Agosto de 2011http://www.agilevale.com.br/@agilevale#agilevale
Upcoming SlideShare
Loading in …5
×

An investigation of extreme programming practices and its impact on software quality metrics

243 views

Published on

These slides were created to support the presentation of a paper published on WBMA (Workshop Brasileiro de Metodos Ageis) in 2011. It describes the conducted experiments and its results on the topic of changes on product quality metrics observed after changes on software development process of a Brazilian company.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
243
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

An investigation of extreme programming practices and its impact on software quality metrics

  1. 1. Gabriel de Souza Pereira Moreira - ITARoberto Pepato Mellado – ITARobson Luis Monteiro Júnior - ITAProf. Adilson Marques da Cunha - ITAProf. Luiz Alberto Vieira Dias - ITA
  2. 2.  Introduction Case Study METACOM Results Limitations Conclusion2ITA - Instituto Tecnológico da Aeronáutica
  3. 3.  On the last decade, a growing interest onagile methods for software construction fromboth industry and academy has arisen. [Dybaet al. 2008][Hanssen et al. 2010] Extreme Programming (XP) is one ofestablished agile methods, has defined setsof values, principles, and practices. [Beck2009]3ITA - Instituto Tecnológico da Aeronáutica
  4. 4.  Lehman defines the law of increasingentropy. He explains that, by a number offactors, a programming system undergoesnever-ending maintenance. [Lehman et al. 1985] Recent works have conducted studies ofquality evolution metrics in agile developedsystems. [Capiluppi 2007]4ITA - Instituto Tecnológico da Aeronáutica
  5. 5. XP Practices Project A Project B Project CSit Together X XInformative Workspace XEnergized Work X XPair Programming XStories XWeekly CycleQuarterly Cycle X X XSlack XTen-Minute Build XContinuous Integration XTest-First Programming XIncremental Design X XRefactoring X X5ITA - Instituto Tecnológico da Aeronáutica
  6. 6. Radar Chart is a visual indicator of XPpractices adoption. It is composed of fiveaxes, representing the dimensions of anXP implementation: programming,planning, customer, pairing and team.[Wake 2000]6ITA - Instituto Tecnológico da Aeronáutica
  7. 7.  Metrics help software engineers to gainperception in the construction of productsthat they develop [Pressman 2009]. Previous works had proposed metrics fortracking aspects like size, complexity,coupling, and cohesion within object oriented(OO) systems. [Chidamber 1994] , [Martin 1994]7ITA - Instituto Tecnológico da Aeronáutica
  8. 8.  Lines of Code (LoC) - Number of valid class lines ofcode (excluding comments and blank lines); Afferent Coupling (AC) - Number of classes directlydependent on the class under analysis; Efferent Coupling (EC) - Number of classes that theclass under analysis directly depends on; Association Between Classes (ABC) - Number ofmembers of others classes that the class underanalysis directly uses in the body of its methods; Cyclomatic Complexity (CC) - Number of executionpaths of a class; and Methods per Class (MPC) - Number of methods of aclass under analysis.8ITA - Instituto Tecnológico da Aeronáutica
  9. 9.  Three Brazilian industry projects: Project A,B, and Project C. Company process evolution: Ad-hoc, RUP,Agile Common complaint: lack of quality built in9ITA - Instituto Tecnológico da Aeronáutica
  10. 10. Project A B CPlatform Web Web ConsoleProgramming Language C# 2.0 C# 2.0 C# 3.5Development Start 08/2008 08/2009 07/2010Number of Use Cases 103 93 N/ARevision Count a 2997 1358 453Distinct Developers 20 8 8Defects, Errors and Failures detected by testers and end users 1387 313 N/ATotal LoC 97488 70735 36202LoC without comments and blank lines 51017 33644 15523Types (classes, interfaces, structs) 297 407 238Assemblies b 23 10 610ITA - Instituto Tecnológico da Aeronáuticaa. Revision – Identifier of a change set in the source code, sent from the developers local copy to a Version Control System repository,through a commit or check-in operation.b. Assembly – Software binary component in .NET platform, generally an executable file or Dynamic Linked Library (DLL).
  11. 11.  It was used just one XP practice.Therequirements analysis, documentation, andsystem design were conducted in thebeginning of the project, and were notrevised during the construction phase. The team had about 10 developers directlyengaged in the project. Because of the highturnover rate, 20 different professionals haveparticipated in the system implementationITA - Instituto Tecnológico da Aeronáutica 11
  12. 12.  They worked distributed in two adjacent rooms,led by a technical leader which gave directionsfor the whole team. Developers were expected to implement code asmodeled by designers in UML case tools.Usually, design models became out of date inrelation to source code. There were not any kind of automated tests, soall regression tests were manually made by atesting team. Refactoring was totallydiscouraged, because of the risk of new defectsdue to changes.ITA - Instituto Tecnológico da Aeronáutica 12
  13. 13.  The requirements analysis anddocumentation were performed at theelaboration phase, the system design wasn’tentirely ready at this phase. Therefore, few units and integration testswere automated and, thus, refactoringpractices were not very much used.ITA - Instituto Tecnológico da Aeronáutica 13
  14. 14.  Average of 4 developers. Team was placed in the same room. The software product of Project B was 34%shorter than Project A, in terms of C# Lines ofCode (LoC), without comments and blanklines. Project B had 78% less defects detected bytest team and by end users than Project A. In this project, a framework was producedand successfully reused in other four projects.ITA - Instituto Tecnológico da Aeronáutica 14
  15. 15.  A higher number of agile engineeringpractices were applied in its development. The team was comprised of four developerson average. In this project, some concepts of Scrum[Schwaber 2009] and XP frameworks wereapplied. Average of 4 developers. There was no Project Manager working withthe team.ITA - Instituto Tecnológico da Aeronáutica 15
  16. 16.  The Scrum Master responsibilities were spreadon the team. The team felt that lack of a dedicated ScrumMaster allowed too much external interferenceson sprint objectives, which impacted the auto-organization, productivity and motivation of theteam. All stories were organized in kanban, amechanism for pull systems that providesupdated process visibility [Poppendieck 2003].ITA - Instituto Tecnológico da Aeronáutica 16
  17. 17.  Product quality was always the main focus ofthe team, and effort was dedicated tomitigate technical debts. The team applied extensively agile practiceslikeTest Driven Development (TDD),refactoring, incremental design, andcontinuous integration. The project C used the principle of test-firstprogramming, which generated 315 unit testsand 87% of code coverage.ITA - Instituto Tecnológico da Aeronáutica 17
  18. 18.  Step 1 – RevisionsCheckout Step 2 – Build Step 3 – Static Analysis Step 4 – DataTransformation andLoad18ITA - Instituto Tecnológico da Aeronáutica
  19. 19. ITA - Instituto Tecnológico da Aeronáutica 19From left to right, Project A, B and C
  20. 20. ITA - Instituto Tecnológico da Aeronáutica 20
  21. 21. ITA - Instituto Tecnológico da Aeronáutica 21
  22. 22. ITA - Instituto Tecnológico da Aeronáutica 22From left to right, Project A, B and C
  23. 23. ITA - Instituto Tecnológico da Aeronáutica 23From left to right, Project A, B and C
  24. 24. ITA - Instituto Tecnológico da Aeronáutica 24From left to right, Project A, B and C
  25. 25.  The analysis conducted in this paper has usedhistorical measures fromVersion Control System(VCS) revisions. As it was not guaranteed that each day a newrevision is committed, there weren’t measuresfor all days during project development.Thiscould add bias on charts time series analysis. The software product quality metrics analyzed inthis work were observed in isolation.25ITA - Instituto Tecnológico da Aeronáutica
  26. 26.  Other variables that could cause impact onprojects like schedule pressures, resourcesavailability, team and management turnover,marketing moment, team engagementamong others, could not be controlled in thisinvestigation of past projects.ITA - Instituto Tecnológico da Aeronáutica 26
  27. 27.  In this investigation it was conducted aninvestigation of three different softwaredevelopment projects history. Company has incorporated agile practices inits projects, in special the ones proposed byXP. A subjective analysis of XP practices usage inprojects was performed by the use of XPRadar chart assessment [Ware 2000].ITA - Instituto Tecnológico da Aeronáutica 27
  28. 28.  The major findings of this investigation pointedout that the average class measures for: Size (LoC and MPC); complexity (CC); and coupling(ABC) were reduced in projects which have beenapplying more XP practices. Coupling metrics of AfferentCoupling (AC) andEfferentCoupling (EC) were low affected by XPpractices usage in this investigation. Based on previous studies, experience, and consensusof the involved development teams, authors believethat XP practices lead to improved product quality inthe analyzed projects.ITA - Instituto Tecnológico da Aeronáutica 28
  29. 29.  Analyse measures under other functions(max,min,std. Dev.) Analyse measures in different levels(packages, classes) Identify entropy increaseITA - Instituto Tecnológico da Aeronáutica 29
  30. 30. ITA - Instituto Tecnológico da Aeronáutica 30 Moreira, G. S. P., Mellado, R. P., Montini, D. A., Dias, L. A.V.,Cunha, A. M. “Software Product Measurement and Analysis in aContinuous Integration Environment”, ITNG, Abril 2010, LasVegas, NE, EUA Moreira, G. S. P., Mellado, R. P., Dias, L. A.V., Cunha, A. M.“METACOM - Um Método para Análise de Correlação entreMétricas de Produto de Software eVolume deManutenção”, SBQS 2011, Jun. 2011, Curitiba, PRhttp://workingsweng.wordpress.com
  31. 31. 19 e 20 de Agosto de 2011http://www.agilevale.com.br/@agilevale#agilevale

×