2011 0709-practices andquality-annotated-weiss-alessandro
Post on 09-Jul-2015
125 Views
Preview:
TRANSCRIPT
Impact of Software Development Practices on
Software QualityRodrigo Rocha G. e Souza <rodrigorgs@gmail.com>
2011-07-09
Software Dev. Practices
“Practices are contained, repeatable, and transferable techniques used to improve some aspect of the performance of a software organization that is pertinent to the creation of its products.”Jorge Aranda (2010) - A Theory of Shared Understanding for Software Organizations [PhD Thesis], p. 123
Software Dev. Practices
• Examples:
• Four eyes principle (verifier ≠ fixer)
• Test first
• Collective vs. strong ownership
• Coding standards
• Continuous integration
• Code documentation ...
Software Quality
• Many definitions and metrics
• Design quality (coupling/cohesion)
• Code quality (Findbugs, Checkstyle)
• Functional quality (# of bugs)
Do practices impact quality? What practices?
In what contexts?
Observational study #1
• Nonconformance to four eyes principle ⇒
bug is not 100% fixed and needs to be reopened?
• Data: bug reports on Eclipse’s Bugzilla
http://wiki.eclipse.org/Development_Resources/HOWTO/Bugzilla_Use
“It is important that the verifier be a different person than the fixer because the fixer is too close to the code and thus may not be as diligent at testing the corner cases.”
Methods
• Selected only verified bugs with last modification ≤ December, 2009.
Eclipse/JDT ¬reopened reopened
¬conform 6838 167
conform 9707 94
• Fisher’s exact test
Results
• In some subprojects, bugs verified by the fixer were more likely to be reopened.
• 5x more likely on Eclipse/JDT
• 2.5x more likely on Eclipse/Platform
• In some subprojects, the difference was not statistically significant. (why?)
• BIRT, EMF etc.
Next
• context
• other projects
• other practices
Next: Context
Crowston & Howison (2005) - The social structure of free and open source software development
Next: Context
Philippe Kruchten (2010) - Contextualizing Agile Software Development
Next: other projects
• Available data:
• Eclipse
• Netbeans
• Firefox
• Chrome
Related work
• Collective ownership vs. quality: enough eyeballs or too many cooks?
• Bird2010: high ownership and few minor contributors ⇒
less defects (mostly in commercial projects)
• Rahman2011: “implicated” code* more often associated with a single developer’s contribution. Experience in the modified files is more important than general experience. (context: FOSS)* Code that was changed in a bug fix.
• Maruping2008: collective ownership improves software quality (in low expertise teams)
Related work
• Coding conventions vs. quality:
• Butler2010: low quality identifiers ⇒ low quality code
(Findbugs)
• Maruping2008: coding conventions improve software quality
Related work
• Process mining
• Cook1998
• Poncin2011
References
• Bird2010 - An Analysis of the Effect of Code Ownership on Software Quality across Windows, Eclipse, and Firefox
• Rahman2011 - Ownership, Experience and Defects- A fine-grained study of Authorship
• Maruping2008 - Role of collective ownership and coding standards in coordinating expertise in software project teams-annotated
• Butler2010 - Exploring the Influence of Identifier Names on Code Quality_ an empirical study
• Cook1998 - Discovering models of software processes from event-based data-annotated
• Poncin2011 - Process mining software repositories
top related