Given the requirement for software engineering graduates to operate in Global Software Development (GSD) environments, educators need to develop teaching methods to enhance and instill GSD knowledge in their students. In this paper, we discuss two projects that provided students with a first-hand learning experience of working within GSD teams. One project was with Siemens Corporate Research, whose focus was to shadow the development of a real-life GSD project. The second project, whose focus was virtual team software testing, was carried out in collaboration with Ball State University. In parallel with these projects we undertook qualitative research during which we analyzed students' own written reflections and face-to-face interviews that focused on their learning experiences in these contexts. We identified three specific forms of learning which had taken place: pedagogical, pragmatic and the acquisition of specific globally distributed knowledge. Our findings confirm that mimicking real work settings has educational benefits for problem-based learning environments.

We have been developing a tool to enhance the use of metrics during software development. This tool is a metrics visualization environment that graphically depicts the innate structure of software through a module signature along with an element of time. We call the tool module metric signature (MMS) visualization.

The Student Online Project Planning and Tracking System, SOPPTS, is an online system designed and implemented to enhance the communication avenues and the project planning/tracking requirements of student projects for the Ball State University (BSU) software engineering classes. This paper presents the design and assessment of this tool SOPPTS has been designed and field-tested to provide real-time feedback from faculty on student project progress, to offer online guidance for project planning and to produce automated tracking of student projects. The tool assessment included interviews of both students at the undergraduate and graduate level and faculty. The interview was a set of specific questions chosen to document each participant's experience and impressions of utilizing SOPPTS. Data evaluation consisted of compiling the reoccurring themes during the interview process. The major themes that emerged are the increased efficiency in developing, recording and tracking of student project plans, the visibility and immediate accessibility of this information and the improved and timely communication among the student team members, faculty and client partners. With the improved access to information and facilitated communication through SOPPTS, the project planning and tracking skills for the software development teams improved. Moreover, the informal aspects of team communication and synergy, factors that can be as important as the technical aspects, were enhanced.

Improvements in the software development process depend on our ability to collect and analyze data drawn from various phases of the development life cycle. Our design metrics research team was presented with a largescale SDL production model plus the accompanying problem reports that began in the requirements phase of development. The goal of this research was to identify and measure the occurrences of faults and the efficiency of their removal by development phase in order to target software development process improvement strategies. The number and severity of problem reports were tracked by development phase and fault class. The efficiency of the fault removal process using a variety of detection methods was measured Through our analysis of the system data, the study confirms that catching faults in the phase of origin is an important goal. The faults that migrated to future phases are on average eight times more costly to repair. The study also confirms that upstream faults are the most critical faults and more importantly it identifies detailed design as the major contributor of faults, including critical faults.

This paper introduces a framework to provide design and testing guidance through a stress-point resolution system based on a module signature for module categorization. A stress-point resolution system includes stress-point identification and the selection of appropriate mitigation activities for those identified stress-points. Progress has been made in identifying stress-point to target the most fault-prone modules in a system by the module signature classification technique. Applying the stress-point prediction method on a large Motorola production system with approximately 1500 modules and comparing the classified modules to change reports, misclassification errors occurred at a rate of less than 2%. After identifying the stress point candidates, localized remedial actions should be undertaken. This algorithmic classification may suggest more insights into defect analysis and correction activities to enhance the software development strategies of software designers and testers.

The purpose of this study was to identify fault-prone functions that are likely to contain faults in a given software system. Five metrics were used: Di, an internal design metric which incorporates factors related to a function's internal structure; De, an external design metric which focuses on a function's external relationships to the rest of the software system; D(G), a composite design metric which is a linear combination of Di and De; and the union and intersection of Di, De, and D(G). Since the system being considered was already developed, a very important aspect of our study was to extract the design information directly from the source code rather than from the corresponding design documentation which may not exist or, if it does exist, it may be incomplete, difficult to understand, or not updated. To make the analysis more accurate and efficient, a metric analysis tool (χMetrics) was implemented. We conducted experiments using χMetrics on part of a distributed software system, written in C, with a client–server architecture, and identified a small percentage of its functions as good candidates for fault-proneness. Files containing these functions were then validated by the real defect data collected between a recent major release and its subsequent release for their fault-proneness. The results indicate that our metrics are good indicators of fault-prone functions. Two extra experiments were also conducted to show that function size cannot replace any of our metrics; and where the function size was factored out our metrics performed better than the normalized metrics. The important benefit of our metrics is that they help project managers determine where additional testing effort should be spent and possibly which fault-prone functions should be assigned to more experienced programmers if modifications are required. Copyright © 2000 John Wiley & Sons, Ltd.

Three metrics were used to extract design information from existing code to identify structural stress points in a software system being analyzed: D/sub i/, an internal design metric which incorporates factors related to a module's internal structure; D/sub e/, an external design metric which focuses on a module's external relationships to other modules in the software system; and D(G), a composite design metric which is the sum of D/sub i/ and D/sub e/. Since stress point modules generally have a high probability for being fault-prone, project managers can use the information to determine where additional testing effort should be spent and assign these modules to more experienced programmers if modifications are needed. To make the analysis more accurate and efficient, a design metrics analyzer (/sub /spl chi//Metrics) was implemented. We conducted experiments using /sub /spl chi//Metrics on part of a distributed software system, written in C, with a client-server architecture, and identified a small percentage of its functions as good candidates for fault proneness. Files containing these functions were then validated by the real defect data collected from a recent major release to its next release for their fault proneness. Normalized metrics values were also computed by dividing the D/sub i/, D/sub e/, and D(G) values by the corresponding function size determined by non-blank and non-comment lines of code to study the possible impact of function size on these metrics. Results indicate that function size has little impact on the predictive quality of our design metrics in identifying fault-prone functions.