We are interested in how to expose our students to test driven development (TDD) and have experimented with a variety of ways of leveraging testing technology to help our students learn to program in our first programming course. Initially, we developed a framework that allows the students to run tests that are developed by the faculty member. That experience led us to developing a JUnit plug-in that allowed the students to specify the tests without having to write the test code. As a result of these experiences, we have re-structured this class into these roughly sequential phases: learning to read code, learning to write code, and learning to program. Throughout this course, the students are using TDD, writing their own JUnit tests, and refactoring as they develop their code iteratively. This change has been made without dropping any of the required course content.

Test-Driven Development is a design strategy where a set of tests over a class is defined prior to the implementation of that class. The goal is to use the tests to exercise the class being developed, to provide immediate feedback of the overall quality of the code, and to identify and correct bugs as they are written. Testing is usually performed with automated testing tools, such as JUnit, which give clear feedback about the status of the tests1. The test-first approach requires students to think about the problem, identify corner cases, analyze ways their code may fail, and evaluate the goodness of their design. This paper presents a tool for teaching CS1 using a Test-First approach that will allow students to construct their tests using a simple GUI interface. The goal is to give CS1 students the ability to do test-driven development independently.

Test-driven development is a design strategy where a set of tests over a class is defined prior to the implementation of that class. The goal is to use the tests to exercise the class being developed, to provide immediate feedback of the overall quality of the code, and to identify and correct bugs as they are written. This paper presents a method to teaching CS1 using a "test-first" approach that will be tried in fall 2006. The test-first approach requires students to think about the problem, identify corner cases, analyze ways their code may fail, and evaluate their design. Further, a proposed evaluation is presented for determining the success of the approach

Shippensburg University offers a computer science degree with the choice of five concentrations including software engineering. We first introduced agility as an XP component in part of our two-semester product development sequence. Within the software engineering concentration, agile concepts spread into our course on software metrics and process management. With that experience, our faculty have become interested in including agile concepts into other courses. This paper describes how a number of our undergraduate courses, the content of our computer science core, and our department's general health have been affected by agile techniques and philosophies

In Fall of 2004, we offered two software engineering courses: one in plan-driven methodologies and one in agile methodologies. In these courses, the students work on large projects in teams of 14 to 16 students using variants of Team Software Process (TSP) or Extreme Programming (XP). In order to compare the students' experiences with these methodologies, the team in the plan-driven course and one of the agile teams were given the same problem statement. Throughout the semester, we measured team cohesion and individuals' attachment to the project. To measure team cohesion, we modified the Group Environment Questionnaire that has been shown to accurately reflect team cohesion in sports teams. We also developed some of our own cohesion metrics and a measure of attachment to the project. While the GEQ showed no significant difference between the teams, our measures showed higher overall cohesion in XP, but higher sub-team cohesion in TSP. At the end of the semester, we also compared the functionality of the applications the teams developed and a variety of code metrics measuring the quality of their code and its design. While the team's developed approximately the same amount of functionality, in general, the XP team's code had better metrics. The TSP team required much more code to accomplish the same functionality because, although they had a strong design, their implementation did not leverage inheritance as the design expected

This paper describes an experiment in which student teams developed products using two different methodologies: the Team Software Process (TSP) as a plan-driven methodology and Extreme Programming (XP) as an agile methodology. We carefully define cohesion and derive instruments appropriate for measuring cohesion. Then, throughout the projects, the teams were surveyed to measure various aspects of team cohesion and those results support conclusions about how methodology was affecting cohesion. The results show that the measures developed lead to interesting observations that can be applied to current, non-academic projects. In addition, future work in broadening this study is justified.

In the modeling of vision systems of biological organisms, one of the important features is the ability to sense motion (BorgGraham et al. 1992, Huntsberger 1995, Klauber 1997, Missler and Kamangar 1995, Rosenberg and Ariel 1991). Motion is sensed by animals through neurons that receive input over some area of the field of view (Newman et al. 1982 and Rosenberg and Ariel 1991). For such a neuron to function properly implies the ability to remember how things were in the past and combine that information with how things are in the present. In attempting to come up with a computationally efficient model of a motion neuron a Jordan-Elman network has been utilized. The Jordan-Elman network allows for a one time step remembrance of the state space, making it suitable for motion sensing (Jordan 1986 and Elman 1990). To train the network an automatic method of building a training sequence was developed based off earlier work done mostly through hand coding to allow for easy construction of motion sensing networks of differing features. A network with a 3x3 input field and a network with a 5x5 input field were trained using the automatic method of training sequence generation. These two networks were tested against a network with a 3x3 input field trained using the training set constructed partially by hand. Results favored the latter network, but the former networks showed future promise. It is hoped with the right modifications to the creation of their training sequence they will become better than their hand built ancestor.