Software Bug Prediction Model Presented byUnder the supervision of Under the co-supervision of Muthukumaran K Dr. N L Bhanu Murthy Dr. Aruna Malapati 2011PHXP415H
My Research in Word Cloud - obtained with wordle.net, idea inspired by Tom Zimmermann
The Road Map Objectives Inspiration Mining Software Repositories Bug Prediction Code Refactoring Work Plan References
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
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.-
Mining Software Repositories“we are drowning in the deluge of data that are beingcollected worldwide, while starving for knowledge atthe same time”. J. Naisbitt, Megatrends: Ten New Directions Transforming Our Lives. New York: Warner Books, 1982.
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.
Literature Survey: Bug PredictionWhere 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”
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.
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.]
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.
Work PlanActivity 0 6 12 18 24 30 36 Duration in Months
References1. 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.
“ Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. ” - Rick Osborne