| Welcome to RandyLoops! |
RandyLoops and the XP Process
Small Releases (10 points)
Our releases are available here.
Metaphor, Simple Design, and Refactoring (5 points)
Metaphor: We did not feel we needed a metaphor. The purpose of a metaphor is give us all a common language with which to talk about the project. For our project,
we already had the music and midi terminology to use as our language. This terminology is somewhat complex, and using another language to refer to these terms was
unnecessary. We tried to come up with a metaphor, but we realized we were just wasting our time, time that could be used to code.
Simple Design: Simple design is a key component of XP. The idea was to get something working as fast as possible. This is exactly what we did. Our project
at the end of the first semester was very simple in terms of functionality. This semester we tried to get new features working as easily as possible. Our biggest example
of this is how we skipped making tracks to play in the sequencer. We skipped the tracks step/layer to get the new functionality working as fast as possible.
Tracks would allow us to do other things such as saving our midi loops, but since we were just trying to get them to play, we left the tracks step out.
Also take a look at the CVS changelog. Very little tends to change between releases of each file.
Refactoring: Refactoring was really important for us. When we wrote things, we just tried to get them to work, and we didn't worry to much about how pretty things were.
For example, our styleparser had all public variables that we would refer to directly. When we ran our metrics, it told us not to do it this way, so we made them
variables private, and wrote public getter and setter methods for those variables. We would also do a lot of GUI adjusting, which did not directly change the
functionality, but just made things look better. At one point we realized that we had horrible directly dependancies, and during one refactoring, we took these out as well.
Testing (15 points)
An important part of the XP software development process is testing, and in particular automated testing. However, automated tests are really not
appropriate for the type of project that we are working on. The most important verications that needed to be made during development were whether
or not the GUI windows were being displayed correctly and if the MIDI music was being played as desired. These types of results do not lend themselves
well to automated testing. Instead we found it more worthwhile to verify the correctness of the GUI windows by actually looking at them, and similarly
handling the music output by listening to it. Automated tests could have been produced to verify existance of such outputs but would not have been
able to judge the quality of them, which is what was needed.
We did though, find other types of testing helpful with the development of our project.
In particular, we created unit-tests to test our back-end code to ensure its behavior. We also performed some white-box tests to test boundary
conditions and special cases of several routines. Other types of non-automated tests were also performed, especially when writing our components
to make sure we did them right the first time. Testing as would be expected, was an important part of our development process. However, our testing
was not carried out exactly as XP stipulates because of the nature of our project. In our project and in general, it is better to modify the process
in order to proliferate progress rather than to sacrifice product in order to avoid straying form those constraints.
Pair Programming (5 points)
Take a look at the files in CVS, which tell who was working on what with who when. Also, Riley has a list of what pairs worked on what during each 2-week period during the semester.
Collective Ownership and Continuous Integration (12.5 points)
We used CVS for collective ownership. Everyone has the ability to upload their changes into CVS. We also integrated our changes once or twice per coding
session, and uploaded it to CVS. Looking at the CVS changelog, it is easy to see that we were continuously integrating new features and changes into the system. Anytime a change was made, or
when something was added, we made sure it worked with the entire system, or we didn't consider the change to be complete.
See CVS at http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/randyloops/refactored/ for more details.
On-Site Customer and Planning Game (2.5 points)
A list and description of our user stories that were slated to be finished this semster are located here.
The technical estimates are located in the same place. We underestimated the difficulty of actually taking our style data and making a MIDI track
from it, so we were unable to complete tasks 5, 6, and 8.
We had a group member play the on-site customer, so there are no email logs - everything was done in the group meetings.