2:00 - 2:30 |
An Empirical Study of Structural Defects in Industrial Use-Cases
Use-cases perform an important role in capturing and analys-ing software requirements in the IT industry. A number of guidelines have been proposed in the literature on how to write use-cases. Structural defects can occur when use-cases are written without following such guidelines. We develop a taxonomy of structural defects and analyse a sample of 360 industrial use-cases to understand the nature of defects in them. Our sample comes from both client-based projects and in-house projects. The results show that, compared to a sample of theoretical use-cases that follow Cockburn's guidelines, industrial use-cases on the average exhibit defects such as complex structures, lack of customer focus and missing actors. Given the shortage of analysis of real industry samples, our results make a significant contribution towards the understanding of the strengths and weaknesses in industrial use-cases in terms of structural defects. The results will be useful for industry practitioners in adopting use-case modelling standards to reduce the defects as well as for software engineering researchers to explore the reasons for such differences between the theory and the practice in use-case modelling.
|
|
Deepti Parachuri, Sajeev A.S.M and Rakesh Shukla |
|
2:30 - 3:00 |
Where Do Developers Log? An Empirical Study on Logging Practices in Industry
System logs are widely used in various tasks of software system management. It is crucial to avoid logging too little or too much. To achieve so, developers need to make informed decisions on where to log and what to log in their logging practices during development. However, there exists no work on studying such logging practices in industry or helping developers make informed decisions. To fill this significant gap, in this paper, we systematically study the logging practices of developers in industry, with focus on where developers log. We obtain six valuable findings by conducting source code analysis on two large industrial systems (2.5M and 10.4M LOC, respectively) at Microsoft. We further validate these findings via a questionnaire survey with 54 experienced developers in Microsoft. In addition, our study demonstrates high accuracy of up to 90% F-Score in predicting where to log.
|
|
Qiang Fu, Jieming Zhu, Wenlu Hu, Jian-Guang Lou, Rui Ding, Qingwei Lin, Dongmei Zhang and Tao Xie |
|
3:00 - 3:30 |
Active Files as a Measure of Software Maintainability
In this paper, we explore the set of source files which are changed unusually often. We call these the active files. In an empirical study of six large software systems within Microsoft ranging from products to services, we found that active files constitute only between 2%-8% of the total system size, contribute 20%-40% of system file changes, and are responsible for 60%-90% of all defects. Not only this, but we establish that the majority, 65%-95%, of the active files are architectural hub files which change due to feature addition as opposed to fixing defects. Although discovery of active files relies only on version history and defect classification, this concept can deliver key insights into software development activities. Active files can help focus code reviews, implement targeted testing, show areas for potential merge conflicts and identify areas that are central for program comprehension.
|
|
Lukas Schulte, Hitesh Sajnani and Jacek Czerwonka |
|
3:30 - 4:00 |
Nondeterminism In MapReduce Considered Harmful? An Empirical Study On Non-commutative Aggregators In MapReduce Programs
The simplicity of the MapReduce model introduces unique subtleties that could cause hard-to-detect bugs; in particular, the unfixed order of the input to a reduce function is a source of nondeterminism that could be harmful if the reduce function is sensitive to input order, i.e. not commutative. Our extensive study on production MapReduce programs, the first of its kind, reveals interesting findings on commutativity, nondeterminism, and correctness. Although non-commutative reduce functions lead to five bugs in our sample of well-tested production programs, we have found surprisingly many non-commutative reduce functions, most of which are harmless; e.g. due to implicit data properties. These findings are instrumental in advancing our understanding on MapReduce program correctness.
|
|
Tian Xiao, Jiaxing Zhang, Hucheng Zhou, Zhenyu Guo, Sean McDirmid, Wei Lin, Wenguang Chen and Lidong Zhou |
|