Kurla Call Girls Pooja Nehwal📞 9892124323 ✅ Vashi Call Service Available Nea...
Software bug prediction
1. Software Bug Prediction Model
Presented by
Under the supervision of Under the co-supervision of Muthukumaran K
Dr. N L Bhanu Murthy Dr. Aruna Malapati 2011PHXP415H
2. My Research in Word Cloud
- obtained with wordle.net, idea inspired by Tom Zimmermann
3. The Road Map
Objectives
Inspiration
Mining Software Repositories
Bug Prediction
Code Refactoring
Work Plan
References
4. Objectives
To build resilient bug prediction model
Simulation of bug prediction model on open
source issue trackers like jira and bugzilla.
Comparative study of this new model with the
existing competitive models.
To build change prediction model
To facilitate re-factorization of code bases
5. Inspiration
Here at Google, we have thousands of engineers working on our
code base every day. In fact, 50% of the Google code base changes
every month. That’s a lot of code and a lot of people. -
Facebook updates the site with new features, product
improvements, and bug fixes every work day. hundreds of engineers
working on thousands of changes every week, and many of those
changes immediately impact the over 800 million people using
Facebook.-
At Mobile World Congress in Barcelona, Spain a few moments ago,
we unveiled the Windows 8 Consumer Preview to our partners and
press. Based on a broad range of feedback, we have made over
100,000 code changes.-
6. Mining Software Repositories
“we are drowning in the deluge of data that are being
collected worldwide, while starving for knowledge at
the same time”. J. Naisbitt, Megatrends: Ten New Directions Transforming
Our Lives. New York: Warner Books, 1982.
10. Bug Prediction
To make the project development team to utilize its
resources efficiently.
Previous bugs are good predictors of future bugs
The source control repositories, bug reports, design
and code artifacts etc. will be utilized as data
sources
Open source projects like Eclipse, Mozilla and
Android will be used for simulations
The data mining tools like WEKA and RAPID MINER
will be used extensively.
11. Literature Survey: Bug Prediction
Where are the bugs?
Previously fixed files [Hassan et al.]
Modified files [Nagappan et al.]
Complex files [Menzies et al.]
Nearby other bugs [Zimmermann et al.]
“There is no last bug in the software / application”
12. Code Refactoring
To cope up with growing complexity of evolving code.
It Improves the software maintenance activities like
adoption, modification and enhancement to a great
extent.
We will make use of the design, code, source control
repositories and the bug databases and their
associations to suggest software refactoring.
13. Literature Survey: Code Refactoring
• Function Level : High Cohesion and Low Coupling
[Lung et al.]
• Package Level : High Cohesion and Low Coupling
[Alkhalid et al.]
• Input and output dependence [Kang and Beiman]
• Prioritizing refactoring based on Code Bad Smells
[Min Zhang et al.]
14. Work Plan
Phase I: In-depth literature survey.
Phase II: Creating the test bed and analysis of existing bug
prediction models and Refactoring Approaches.
Phase III: Discovering an alternative to the existing biased
bug prediction approaches.
Phase IV: Designing a novel algorithms to facilitate effective
software refactoring.
Phase V: The results obtained throughout the research will be
compiled into a thesis.
16. References
1. N. Nagappan and T. Ball, “Use of relative code churn measures to predict system defect density,” Proceedings. 27th
International Conference on Software Engineering, 2005. ICSE 2005., pp. 284-292, 2005.
2. A. E. Hassan, “Predicting faults using the complexity of code changes,” 2009 IEEE 31st International Conference on
Software Engineering, no. 2009, pp. 78-88, 2009.
3. C.Horng Lung and M. Zaman, “Using clustering technique to restructure programs,” in Proceedings of the International
Conference on Software Engineering Research and Practice, 2004, vol. 853, pp. 853-858.
4. A. Alkhalid, M. Alshayeb, and S. a. Mahmoud, “Software refactoring at the package level using clustering techniques,” IET
Software, vol. 5, no. 3, p. 274, 2011.
5. J. Naisbitt, Megatrends: Ten New Directions Transforming Our Lives. New York: Warner Books, 1982.
6. T. X. T. Xie, S. Thummalapenta, D. Lo, and C. L. C. Liu, Data Mining for Software Engineering, vol. 42, no. 8. IEEE
Computer Society Press, 2009, pp. 55-62.
7. E. Murphy-Hill, C. Parnin, and A. P. Black, “How We Refactor, and How We Know It,” IEEE Transactions on Software
Engineering, vol. 38, no. 1, pp. 5-18, Jan. 2012.
8. S. Kim, T. Zimmermann, E. J. Whitehead Jr., and A. Zeller, “Predicting Faults from Cached History,” 29th International
Conference on Software Engineering ICSE07, pp. 489-498, 2007.
9. M. Zhang, N. Baddoo, P. Wernick, and T. Hall, “Prioritising Refactoring Using Code Bad Smells,” 2011 IEEE Fourth
International Conference on Software Testing, Verification and Validation Workshops, pp. 458-464, Mar. 2011.
10. J. Czerwonka, R. Das, and N. Nagappan, “Crane: Failure prediction, change analysis and test prioritization in practice--
experiences from windows,” Software Testing,, pp. 1-10, 2011.
17. “ Always code as if the guy who ends up maintaining your code will be a violent psychopath
who knows where you live. ” - Rick Osborne