I just handed in paperwork to say that Samira Ashtiani Abdi, Jeremy Handcock, and Carolyn MacLeod have completed their Master of Science degrees in Computer Science, and that Samira and Carolyn should be admitted to the PhD. (Jeremy’s going to go be a ski bum instead.) Congratulations to all three—I’m proud to have worked with them.
Samira Ashtiani Abdi: Recovering Related Artifacts in Software Projects’ History: a Comparison of Information Retrieval Based Methods
The average software project is made up of a rich history of artifacts or change events: discussions in mailing lists or forums, bug reports, source code revisions, documentation or wiki page edits, patches, and feature or support requests. Although each of these artifacts are independent, many events may be logically related. For example, an email in a proejct’s mailing list archives may discuss a related bug report. Similarly, the bug report may be fixed by a source code revision in version control repository, and this may cause a change in the wiki pages too. We present a system to automatically cluster related events into logical groupings, or find the artifacts related to a target artifact. In addition, we present a visualization tool to help project stakeholders explore these artifacts, which also let them to further expand their search to retrieve more related artifacts in a tree based fashion. We provide a comparison of three Information Retrieval based methods: Vector Space Model (VSM), Latent Semantic Indexing (LSI), and a novel approach based on approximating the most distinguishing words or phrases considering the properties of software repositories.
Jeremy Handcock: How Developers Use an Awareness Tool: Patterns and Usage Scenarios
Software developers consult numerous sources of information in order to maintain awareness of what happens within their teams. They seek out information about what their peers are doing and what project artifacts have changed. Although researchers have proposed many tools to facilitate developers in maintaining awareness, there is currently a lack of understanding about how developers might use them—if at all—in real software projects. We have developed a new awareness tool for software developers called Aufait. We studied developers using Aufait in two organizations over a three-week period and found that they adopted it and used it regularly. We identified a number of usage scenarios in each organization: most commonly, developers used Aufait to manage dependencies between team members and to determine how changes might affect them. We also found common usage patterns. Throughout the course of the study, developers were most interested in changes to source code relative to other artifact types and they were primarily interested in changes that occurred very recently. Together, these scenarios and patterns suggest necessary features and implications for the design of future applications. Our results also pose interesting areas of future research.
Carolyn MacLeod: Patterns in Novice Design Analysis Using Spin
I examined and categorized novice Spin users’ difficulties and errors in using it to solve simple concurrent design and algorithm problems, using a qualitative analysis and a grounded theory approach. I found that the novices had greatest difficulties in dealing with nondeterminism and the Promela control flow, and found it very difficult to specify properties in any formal way. In particular, I found that novices had difficulties in formalizing natural language specifications, and in defining abnormal behaviour.
Cory J. Kapser and Michael W. Godfrey: “‘Cloning considered harmful’ considered harmful: patterns of cloning in software.” Empirical Software Engineering, 2008, 13:645-692, DOI 10.1007/s10664-008-9076-6.
“…we have found significant evidence that cloning is often used in a variety of ways as a principled engineering tool.” Comes with a catalog of beneficial cloning design patterns.
Jeffrey C. Carver, Nachiappan Nagappan, and Alan Page: “The Impact of Educational Background on the Effectiveness of Requirements Inspections: An Empirical Study.” IEEE Transactions on Software Engineering, 34(6), Nov/Dec 2008, DOI 10.1109/TSE.2008.49.
“…a large-scale controlled inspection experiment with over 70 professionals was conducted at Microsoft that focused on the relationship between an inspector’s background and his effectiveness during a requirements inspection. The results of the study showed that inspectors with university degrees in majors not related to computer science found significantly more defects than those with degrees in computer science majors. We also observed that level of education (Masters, PhD), prior industrial experience, or other job-related experiences did not signficantly impact the effectiveness of an inspector.”
Lech Madeyski: “Impact of Pair Programming on Thoroughness and Fault Detection Effectiveness of Unit Test Suites.” Software Process Improvement and Practice, 2008, 13:281-295, DOI 10.1002/spip.382.
“…we examined pair programming versus solo programming with respect to both thoroughness and fault detection effectiveness of test suites. Branch coverage (BC) and mutation score indicator (MSI) were used as measures of how thoroughly tests exercise programs, and how effective they are, respectively. It turned out that the PP practice did not significant affect GC and MSU.”
Victoria Stodden: “The Legal Framework for Reproducible Scientific Research: Licensing and Copyright.” Computing in Science & Engineering, Jan/Feb 2009.
“The author proposes the Reproducible Research Standard for all components of scientific researchers’ scholarship, which should encourage replicable scientific investigation through attribution, the facilitation of greater collaboration, and the promotion of the engagement of the larger community…”
Khaled El Emam, Saida Benlarbi, Nishith Goel, and Shesh N. Rai: “The Confounding Effect of Class Size on the Validity of Object-Oriented Metrics.” IEEE Transasctions on Software Engineering, 27(7), July 2001.
The abstract doesn’t do it justice, so I’ll summarize. Previous work to validate software metrics (cyclomatic complexity, coupling, etc.) has looked at correlations between metric values and things like post-release bug count. The authors repeated those experiments using bivariate analysis so that they could allocate a share of the blame to code size (measured by number of lines) and the metric in question. Turns out that code size accounted for all of the variation, i.e., the metrics didn’t add have any actual predictive power once you normalized for the number of lines of code.
- My father was my English teacher from Grade 8 to Grade 12. (It was a small town…)
- My first paid-for publication was a description of an Inuit cult for a role-playing game I’d never actually played. Thirty years later, I still pretend to know more about obscure things than I actually do.
- My left calf is an inch smaller in diameter than my right one—I tore the muscle playing Ultimate frisbee, started favoring my strong leg, and have never properly re-balanced.
- The Mummy is my favorite movie of all time.
- I used to be pretty good with a railgun.
- I haven’t driven a car since 1992. You should be grateful for that.
- Pickled beets make me nauseous. Even just thinking about them makes me… Uh oh…