SlideShare a Scribd company logo
1 of 17
Download to read offline
Impact of Software
Development Practices on
    Software Quality
Rodrigo Rocha G. e Souza <rodrigorgs@gmail.com>

                  2011-07-09
Software Dev. Practices
                                  Segundo David Weiss, cada um faz
                                  de um jeito.



“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:                            How are the bugs verified? Code
                                       inspection? Automated testing?



 •
                                       Formal verification?

     Four eyes principle (verifier ≠ fixer)

 •   Test first

 •   Collective vs. strong ownership

 •   Coding standards

 •   Continuous integration

 •   Code documentation
      Object-oriented programming vs
                                              ...
      procedural
Software Quality

• Many definitions and metrics
 • Design quality (coupling/cohesion)
 • Code quality (Findbugs, Checkstyle)
 • Functional quality (# of bugs)
    Specify # of bugs:
    - reported by users or devs?
    - pre or post release?
    - what criticality?
    
    Also, there is much noise: people
    don't report correctly the
    criticality etc.
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?   Fix on the fix: about 1-2% of the
              bugs




• Data: bug reports on Eclipse’s Bugzilla
Alessandro. Quando o verifier
                                                  atua? So no final? QA?
                                                  Cristina. Os verifiers sao
                                                  developers? Sao core developers?




                                                 “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.”




http://wiki.eclipse.org/Development_Resources/HOWTO/Bugzilla_Use
Methods
• Selected only verified bugs with last
  modification ≤ December, 2009.
            ¬reopened reopened
  Eclipse/JDT

   ¬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?)
                                     Maybe verification is being done
                                     informally, and not being reported.
                                     
                                     Bugs per LOC correlates with need to



  • BIRT, EMF etc.
                                     reopen bug?
                                     
                                     How productivity affects quality? See
                                     "assessing the state of sw dev in a
                                     large enterprise", by Weiss, Mockus et
                                     al., j. Emp. Sw. Eng. 2009
                                     
                                     Present results to developers and see
                                     what they have to say (focus on
                                     valiation!)
Next


• context
• other projects
• other practices
Next: Context



                                            This is a key concept.


                                           What happens when there's
                                           turnover on the core developer
                                           team? Wrt productivity? Wrt
                                           quality? David Weiss is
                                           interested in seeing these
                                           layouts.

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
• Collectivetoo many cooks? quality: enough
  eyeballs or
              ownership vs.

  •   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

More Related Content

Viewers also liked

планета венера
планета венерапланета венера
планета венераchocolate98
 
Festivals celebrated in Hong Kong
Festivals celebrated in Hong KongFestivals celebrated in Hong Kong
Festivals celebrated in Hong Kongnvssleaders
 
MA Research Methods 2: Working Practices
MA Research Methods 2: Working PracticesMA Research Methods 2: Working Practices
MA Research Methods 2: Working PracticesClaire Lynch
 
Presentacion Flow´s Blog
Presentacion Flow´s BlogPresentacion Flow´s Blog
Presentacion Flow´s BlogLask33
 
NewTest-910080.ppt
NewTest-910080.pptNewTest-910080.ppt
NewTest-910080.pptIQM123
 
My experience with english
My experience with englishMy experience with english
My experience with englishmariocp3
 
Nt Cadcam Powerpoint For Linked In V3
Nt Cadcam Powerpoint For Linked In V3Nt Cadcam Powerpoint For Linked In V3
Nt Cadcam Powerpoint For Linked In V3kev_moran
 
Universidad de san bueneventura –cartagena2
Universidad de san bueneventura –cartagena2Universidad de san bueneventura –cartagena2
Universidad de san bueneventura –cartagena2stefany
 
New test
New testNew test
New testIQM123
 
网络新公益 ----支付宝公益教程
网络新公益 ----支付宝公益教程网络新公益 ----支付宝公益教程
网络新公益 ----支付宝公益教程cash0430
 

Viewers also liked (15)

Stamp album 2
Stamp album 2Stamp album 2
Stamp album 2
 
планета венера
планета венерапланета венера
планета венера
 
Festivals celebrated in Hong Kong
Festivals celebrated in Hong KongFestivals celebrated in Hong Kong
Festivals celebrated in Hong Kong
 
Sensorize FreeRehab
Sensorize FreeRehabSensorize FreeRehab
Sensorize FreeRehab
 
MA Research Methods 2: Working Practices
MA Research Methods 2: Working PracticesMA Research Methods 2: Working Practices
MA Research Methods 2: Working Practices
 
CLINIC PLUS – THE BRAND
CLINIC PLUS – THE BRANDCLINIC PLUS – THE BRAND
CLINIC PLUS – THE BRAND
 
Presentacion Flow´s Blog
Presentacion Flow´s BlogPresentacion Flow´s Blog
Presentacion Flow´s Blog
 
NewTest-910080.ppt
NewTest-910080.pptNewTest-910080.ppt
NewTest-910080.ppt
 
La guerra di piero
La guerra di pieroLa guerra di piero
La guerra di piero
 
Gerenciando um Projeto
Gerenciando um ProjetoGerenciando um Projeto
Gerenciando um Projeto
 
My experience with english
My experience with englishMy experience with english
My experience with english
 
Nt Cadcam Powerpoint For Linked In V3
Nt Cadcam Powerpoint For Linked In V3Nt Cadcam Powerpoint For Linked In V3
Nt Cadcam Powerpoint For Linked In V3
 
Universidad de san bueneventura –cartagena2
Universidad de san bueneventura –cartagena2Universidad de san bueneventura –cartagena2
Universidad de san bueneventura –cartagena2
 
New test
New testNew test
New test
 
网络新公益 ----支付宝公益教程
网络新公益 ----支付宝公益教程网络新公益 ----支付宝公益教程
网络新公益 ----支付宝公益教程
 

More from Rodrigo Rocha

Aula: busca e ordenação
Aula: busca e ordenaçãoAula: busca e ordenação
Aula: busca e ordenaçãoRodrigo Rocha
 
Patterns for Extracting High Level Information from Bug Reports
Patterns for Extracting High Level Information from Bug ReportsPatterns for Extracting High Level Information from Bug Reports
Patterns for Extracting High Level Information from Bug ReportsRodrigo Rocha
 
Patterns for Cleaning Up Bug Data
Patterns for Cleaning Up Bug DataPatterns for Cleaning Up Bug Data
Patterns for Cleaning Up Bug DataRodrigo Rocha
 
Introdução ao Android (minicurso 4h)
Introdução ao Android (minicurso 4h)Introdução ao Android (minicurso 4h)
Introdução ao Android (minicurso 4h)Rodrigo Rocha
 
Mineração de Repositórios de Defeitos
Mineração de Repositórios de DefeitosMineração de Repositórios de Defeitos
Mineração de Repositórios de DefeitosRodrigo Rocha
 
2011 seminario rodrigo 2011
2011 seminario rodrigo 20112011 seminario rodrigo 2011
2011 seminario rodrigo 2011Rodrigo Rocha
 
2012 qualificacao-rodrigo-2012
2012 qualificacao-rodrigo-20122012 qualificacao-rodrigo-2012
2012 qualificacao-rodrigo-2012Rodrigo Rocha
 
2012 doutorado - visita de dalton - comentarios de dalton, roberto e christina
2012 doutorado - visita de dalton - comentarios de dalton, roberto e christina2012 doutorado - visita de dalton - comentarios de dalton, roberto e christina
2012 doutorado - visita de dalton - comentarios de dalton, roberto e christinaRodrigo Rocha
 
Características de apps
Características de appsCaracterísticas de apps
Características de appsRodrigo Rocha
 
Characterizing Verification of Bug Fixes in Two Open Source IDEs (MSR 2012)
Characterizing Verification of Bug Fixes in Two Open Source IDEs (MSR 2012)Characterizing Verification of Bug Fixes in Two Open Source IDEs (MSR 2012)
Characterizing Verification of Bug Fixes in Two Open Source IDEs (MSR 2012)Rodrigo Rocha
 

More from Rodrigo Rocha (12)

Aula: busca e ordenação
Aula: busca e ordenaçãoAula: busca e ordenação
Aula: busca e ordenação
 
Patterns for Extracting High Level Information from Bug Reports
Patterns for Extracting High Level Information from Bug ReportsPatterns for Extracting High Level Information from Bug Reports
Patterns for Extracting High Level Information from Bug Reports
 
Patterns for Cleaning Up Bug Data
Patterns for Cleaning Up Bug DataPatterns for Cleaning Up Bug Data
Patterns for Cleaning Up Bug Data
 
Introdução ao Android (minicurso 4h)
Introdução ao Android (minicurso 4h)Introdução ao Android (minicurso 4h)
Introdução ao Android (minicurso 4h)
 
Beabá do R
Beabá do RBeabá do R
Beabá do R
 
Mineração de Repositórios de Defeitos
Mineração de Repositórios de DefeitosMineração de Repositórios de Defeitos
Mineração de Repositórios de Defeitos
 
2011 seminario rodrigo 2011
2011 seminario rodrigo 20112011 seminario rodrigo 2011
2011 seminario rodrigo 2011
 
2012 qualificacao-rodrigo-2012
2012 qualificacao-rodrigo-20122012 qualificacao-rodrigo-2012
2012 qualificacao-rodrigo-2012
 
2012 doutorado - visita de dalton - comentarios de dalton, roberto e christina
2012 doutorado - visita de dalton - comentarios de dalton, roberto e christina2012 doutorado - visita de dalton - comentarios de dalton, roberto e christina
2012 doutorado - visita de dalton - comentarios de dalton, roberto e christina
 
Características de apps
Características de appsCaracterísticas de apps
Características de apps
 
Mercado de apps
Mercado de appsMercado de apps
Mercado de apps
 
Characterizing Verification of Bug Fixes in Two Open Source IDEs (MSR 2012)
Characterizing Verification of Bug Fixes in Two Open Source IDEs (MSR 2012)Characterizing Verification of Bug Fixes in Two Open Source IDEs (MSR 2012)
Characterizing Verification of Bug Fixes in Two Open Source IDEs (MSR 2012)
 

2011 0709-practices andquality-annotated-weiss-alessandro

  • 1. Impact of Software Development Practices on Software Quality Rodrigo Rocha G. e Souza <rodrigorgs@gmail.com> 2011-07-09
  • 2. Software Dev. Practices Segundo David Weiss, cada um faz de um jeito. “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
  • 3. Software Dev. Practices • Examples: How are the bugs verified? Code inspection? Automated testing? • Formal verification? Four eyes principle (verifier ≠ fixer) • Test first • Collective vs. strong ownership • Coding standards • Continuous integration • Code documentation Object-oriented programming vs ... procedural
  • 4. Software Quality • Many definitions and metrics • Design quality (coupling/cohesion) • Code quality (Findbugs, Checkstyle) • Functional quality (# of bugs) Specify # of bugs: - reported by users or devs? - pre or post release? - what criticality? Also, there is much noise: people don't report correctly the criticality etc.
  • 5. Do practices impact quality? What practices? In what contexts?
  • 6. Observational study #1 • Nonconformance to four eyes principle bug is not 100% fixed and needs to be reopened? Fix on the fix: about 1-2% of the bugs • Data: bug reports on Eclipse’s Bugzilla
  • 7. Alessandro. Quando o verifier atua? So no final? QA? Cristina. Os verifiers sao developers? Sao core developers? “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.” http://wiki.eclipse.org/Development_Resources/HOWTO/Bugzilla_Use
  • 8. Methods • Selected only verified bugs with last modification ≤ December, 2009. ¬reopened reopened Eclipse/JDT ¬conform 6838 167 conform 9707 94 • Fisher’s exact test
  • 9. 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?) Maybe verification is being done informally, and not being reported. Bugs per LOC correlates with need to • BIRT, EMF etc. reopen bug? How productivity affects quality? See "assessing the state of sw dev in a large enterprise", by Weiss, Mockus et al., j. Emp. Sw. Eng. 2009 Present results to developers and see what they have to say (focus on valiation!)
  • 10. Next • context • other projects • other practices
  • 11. Next: Context This is a key concept. What happens when there's turnover on the core developer team? Wrt productivity? Wrt quality? David Weiss is interested in seeing these layouts. Crowston & Howison (2005) - The social structure of free and open source software development
  • 12. Next: Context Philippe Kruchten (2010) - Contextualizing Agile Software Development
  • 13. Next: other projects • Available data: • Eclipse • Netbeans • Firefox • Chrome
  • 14. Related work • Collectivetoo many cooks? quality: enough eyeballs or ownership vs. • 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)
  • 15. Related work • Coding conventions vs. quality: • Butler2010: low quality identifiers low quality code (Findbugs) • Maruping2008: coding conventions improve software quality
  • 16. Related work • Process mining • Cook1998 • Poncin2011
  • 17. 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