Ameer Armaly

Detecting user story information in developer-client conversations to generate extractive summaries

User stories are descriptions of functionality that a software user needs. They play an important role in determining which software requirements and bug fixes should be handled and in what order. Developers elicit user stories through meetings with customers. But user story elicitation is complex, and involves many passes to accommodate shifting and unclear customer needs. The result is that developers must take detailed notes during meetings or risk missing important information. Ideally, developers would be freed of the need to take notes themselves, and instead speak naturally with their customers. This paper is a step towards that ideal. We present a technique for automatically extracting information relevant to user stories from recorded conversations between customers and developers. We perform a qualitative study to demonstrate that user story information exists in these conversations in a sufficient quantity to extract automatically. From this, we found that roughly 10.2% of these conversations contained user story information. Then, we test our technique in a quantitative study to determine the degree to which our technique can extract user story information. In our experiment, our process obtained about 70.8% precision and 18.3% recall on the information.

A Case Study of Automated Feature Location Techniques for Industrial Cost Estimation

We present a case study of feature location in industry. We study two off-the-shelf feature location algorithms for use as input to a software cost estimator. The feature location algorithms that we studied map program requirements to one or more function points. The cost estimator product, which is the industrial context in which we study feature location, transforms the list of function points into an estimate of the resources necessary to implement that requirement. We chose the feature location algorithms because they are simple to explain, deploy and maintain as a project evolves and personnel rotate on and off. We tested both feature location algorithms against a large software system with a development lifespan of over 20 years. We compared both algorithms by surveying our industrial partner about the accuracy of the list of function points produced by each algorithm. To provide further evidence, we compared both algorithms against an open source benchmarking dataset. Finally, we discuss the requirements of the industrial environment and the ways in which it differs from the academic environment. Our industrial partner elected to use Lucene combined with the PageRank algorithm as their feature location algorithm because it balanced accuracy with simplicity.

Pragmatic source code reuse via execution record and replay

A key problem during copy–paste source code reuse is that, to reuse even a small section of code from a program as opposed to an API, a programmer must include a huge amount of additional source code from elsewhere in the same program. This additional code is notoriously large and complex, and portions can only be identified at runtime. In this paper, we propose execution record/replay as a solution to this problem. We describe a novel reuse technique that allows programmers to reuse functions from a C or C++ program, by recording the execution of the program and selectively modifying how its functions are replayed. We have implemented our technique and evaluated it in an empirical study in which eight programmers used our tool to complete four tasks over four hours each. The participants found our technique to be easier than manually reusing the code as part of their project. We also found that the resulting code was smaller and less complex than it would have been had the participants manually reused the code. Copyright

Towards Prioritizing Documentation Effort

Programmers need documentation to comprehend software, but they often lack the time to write it. Thus, programmers must prioritize their documentation effort to ensure that sections of code important to program comprehension are thoroughly explained. In this paper, we explore the possibility of automatically prioritizing documentation effort. We performed two user studies to evaluate the effectiveness of static source code attributes and textual analysis of source code towards prioritizing documentation effort. The first study used open-source API Libraries while the second study was conducted using closed-source industrial software from ABB. Our findings suggest that static source code attributes are poor predictors of documentation effort priority, whereas textual analysis of source code consistently performed well as a predictor of documentation effort priority.

A comparison of program comprehension strategies by blind and sighted programmers

Programmers who are blind use a screen reader to speak source code one word at a time, as though the code were text. This process of reading is in stark contrast to sighted programmers, who skim source code rapidly with their eyes. At present, it is not known whether the difference in these processes has effects on the program comprehension gained from reading code. These effects are important because they could reduce both the usefulness of accessibility tools and the generalizability of software engineering studies to persons with low vision. In this paper, we present an empirical study comparing the program comprehension of blind and sighted programmers. We found that both blind and sighted programmers prioritize reading method signatures over other areas of code. Both groups obtained an equal and high degree of comprehension, despite the different reading processes.

Docio: documenting API input/output examples

When learning to use an Application Programming Interface (API), programmers need to understand the inputs and outputs (I/O) of the API functions. Current documentation tools automatically document the static information of I/O, such as parameter types and names. What is missing from these tools is dynamic information, such as I/O examples—actual valid values of inputs that produce certain outputs. In this paper, we demonstrate Docio, a prototype toolset we built to generate I/O examples. Docio logs I/O values when API functions are executed, for example in running test suites. Then, Docio puts I/O values into API documents as I/O examples. Docio has three programs: 1) funcWatch, which collects I/O values when API developers run test suites, 2) ioSelect, which selects one I/O example from a set of I/O values, and 3) ioPresent, which embeds the I/O examples into documents. In a preliminary evaluation, we used Docio to generate four hundred I/O examples for three C libraries: ffmpeg, libssh, and protobuf-c. Docio is open-source and available at: http://www3.nd.edu/~sjiang1/docio/.

An empirical study of blindness and program comprehension

Blind programmers typically use a screen reader when reading code whereas sighted programmers are able to skim the code with their eyes. This difference has the potential to impact the generalizability of software engineering studies and approaches. We present a summary of a paper which will soon be under review at TSE that investigates how code comprehension of blind programmers differs from that of sighted programmers. Put briefly, we found no statistically-significant differences between the areas of code that the blind programmers found to be important and the areas of code that the sighted programmers found to be important.

Reusable execution replay: execution record and replay for source code reuse

A key problem during source code reuse is that, to reuse even a small section of code from a program, a programmer must include a huge amount of dependency source code from elsewhere in the same program. These dependencies are no- toriously large and complex, and many can only be known at runtime. In this paper, we propose execution record/replay as a solution to this problem. We describe a novel reuse technique that allows programmers to reuse functions from a C or C++ program, by recording the execution of the program and selectively modifying how its functions are re- played. We have implemented our technique and evaluated it in a preliminary study in which two programmers used our tool to complete four tasks over four hours.