Lucas Layman

Local versus Global Lessons for Defect Prediction and Effort Estimation

Existing research is unclear on how to generate lessons learned for defect prediction and effort estimation. Should we seek lessons that are global to multiple projects or just local to particular projects? This paper aims to comparatively evaluate local versus global lessons learned for effort estimation and defect prediction. We applied automated clustering tools to effort and defect datasets from the PROMISE repository. Rule learners generated lessons learned from all the data, from local projects, or just from each cluster. The results indicate that the lessons learned after combining small parts of different data sources (i.e., the clusters) were superior to either generalizations formed over all the data or local lessons formed from particular projects. We conclude that when researchers attempt to draw lessons from some historical data source, they should 1) ignore any existing local divisions into multiple sources, 2) cluster across all available data, then 3) restrict the learning of lessons to the clusters from other sources that are nearest to the test data.

Exploring extreme programming in context: an industrial case study

A longitudinal case study evaluating the effects of adopting the extreme programming (XP) methodology was performed at Sabre Airline Solutions/spl trade/. The Sabre team was a characteristically agile team in that they had no need to scale or re-scope XP for their project parameters and organizational environment. The case study compares two releases of the same product. One release was completed just prior to the teams adoption of the XP methodology, and the other was completed after approximately two years of XP use. Comparisons of the new release project results to the old release project results show a 50% increase in productivity, a 65% improvement in pre-release quality, and a 35% improvement in post-release quality. These findings suggest that, over time, adopting the XP process can result in increased productivity and quality.

Personality types, learning styles, and an agile approach to software engineering education

This paper describes an initiative at North Carolina State University in which the undergraduate software engineering class was restructured in layout and in presentation. The change was made from a lecture-based coursed that followed the waterfall method to a lab-oriented course emphasizing practical tools and agile processes. We examine the new course layout from the perspective of Myers-Briggs personality types and Felder-Silverman learning styles to discuss how the new software engineering class format appeals to a wide variety of students. The new course format resulted in some of the highest student evaluations in recent course history. It is now the standard for the undergraduate software engineering course at the university and has since been used in other North Carolina institutions.

Examining the compatibility of student pair programmers

Pair programming has been shown to be beneficial for both students and teaching staff in university courses. A two-phased study of 1350 students was conducted at North Carolina State University from 2002-2005 to determine if teaching staff can proactively form compatible pairs based upon any of the following factors: personality type, learning style, skill level, programming self esteem, work ethic, or time management preference. We examined compatibility among freshmen, advanced undergraduate and graduate student pair programmers. We have found that overall 93% of students are compatible with their partners. Students notably preferred to pair with a partner that he or she perceived to be of similar or higher skill level to them, which can be predicted by grouping students with similar grade point average. Additionally, pairs comprised of a sensor and an intuitor learning style seem to be compatible, and pairs with differing work ethic are generally not compatible

Eleven Guidelines for Implementing Pair Programming in the Classroom

Utilizing pair programming in the classroom requires specific classroom management techniques. We have created nine guidelines for successfully implementing pair programming in the classroom. These guidelines are based on pair programming experiences spanning seven years and over one thousand students at North Carolina State University. In Fall 2007, pair programming was adopted in the undergraduate human-computer interaction (HCI) course at Virginia Tech. We present the pair programming guidelines in the context of the HCI course, discuss how the guidelines were implemented, and evaluate the general applicability and sufficiency of the guidelines. We find that eight of the nine guidelines were applicable to the Virginia Tech experience. We amended our peer evaluation guideline to account for constantly supervised pairing, as was the case at Virginia Tech. We add two guidelines stating that a pair should always be working toward a common goal and that pairs should be encouraged to find their own answers to increase their independence and self-confidence.

Coordination in large-scale software teams

Large-scale software development requires coordination within and between very large engineering teams which may be located in different buildings, on different company campuses, and in different time zones. From a survey answered by 775 Microsoft software engineers, we learned how work was coordinated within and between teams and how engineers felt about their success at these tasks. The respondents revealed that the most common objects of coordination are schedules and features, not code or interfaces, and that more communication and personal contact worked better to make interactions between teams go more smoothly.

Undergraduate student perceptions of pair programming and agile software methodologies: verifying a model of social interaction

One of the reasons that undergraduate students, particularly women and minorities, can become disenchanted with computer science education is because software development is wrongly characterized as a solitary activity. We conducted a collective case study in a software engineering course at North Carolina State University to ascertain the effects of a collaborative pedagogy intervention on student perceptions. The pedagogy intervention was based upon the practices of agile software development with a focus on pair programming. Six representative students in the course participated in the study. Their perspectives helped validate a social interaction model of student views. The findings suggest that pair programming and agile software methodologies contribute to more effective learning opportunities for computer science students and that students understand and appreciate these benefits.

Motivations and measurements in an agile case study

With the recent emergence of agile software development technologies, the software community is awaiting sound, empirical investigation of the impacts of agile practices in a live setting. One means of conducting such research is through industrial case studies. However, there are a number of influencing factors that contribute to the success of such a case study. In this paper, we describe a case study performed at Sabre Airline Solutions evaluating the effects of adopting Extreme Programming (XP) practices with a team that had characteristically plan-driven risk factors. We compare the teams business-related results (productivity and quality) to two published sources of industry averages. Our case study found that the Sabre team yielded above-average post-release quality and average to above-average productivity. We discuss our experience in conducting this case study, including specifics of how data was collected, the rationale behind our process of data collection, and what obstacles were encountered during the case study. We also identify four factors that potentially impact the outcome of industrial case studies: availability of data, tool support, co-operative personnel and project status. We believe that recognizing and planning for these factors is essential to conducting industrial case studies, and that this information will be helpful to researchers and practitioners alike.

Iterative identification of fault-prone binaries using in-process metrics

Code churn, the amount of code change taking place within a software unit over time, has been correlated with fault-proneness in software systems. We investigate the use of code churn and static metrics collected at regular time intervals during the development cycle to predict faults in an iterative, in-process manner. We collected 159 churn and structure metrics from six, four-month snapshots of a 1 million LOC Microsoft product. The number of software faults fixed during each period is recorded per binary module. Using stepwise logistic regression, we create a prediction model to identify fault-prone binaries using three parameters: code churn (the number of new and changed blocks); class Fan In and class Fan Out (normalized by lines of code). The iteratively-built model is 80.0% accurate at predicting fault-prone and non-fault-prone binaries. These fault-prediction models have the advantage of allowing the engineers to observe how their fault-prediction profile evolves over time.

Toward Reducing Fault Fix Time: Understanding Developer Behavior for the Design of Automated Fault Detection Tools

The longer a fault remains in the code from the time it was injected, the more time it will take to fix the fault. Increasingly, automated fault detection (AFD) tools are providing developers with prompt feedback on recently-introduced faults to reduce fault fix time. If however, the frequency and content of this feedback does not match the developers goals and/or workflow, the developer may ignore the information. We conducted a controlled study with 18 developers to explore what factors are used by developers to decide whether or not to address a fault when notified of the error. The findings of our study lead to several conjectures about the design of AFD tools to effectively notify developers of faults in the coding phase. The AFD tools should present fault information that is relevant to the primary programming task with accurate and precise descriptions. The fault severity and the specific timing of fault notification should be customizable. Finally, the AFD tool must be accurate and reliable to build trust with the developer.