Next: The build system Up: Used Tools and Resources Previous: The development team
The truth is that when the CLAM project started not much effort was put into studying and applying specific framework development methodologies. It turns out though that most decisions have been taken in the right direction and the development process now seems to be in line with what most authors recommend. In this section we will briefly describe the methodologies used in the CLAM development.
As already commented, the development of the CLAM framework has followed a bottom-up approach, starting from some sample applications that have gradually evolve into being usage examples of the framework itself. It is important to note that in section 1.3.4 we already reflected how this is an important guideline given by most authors.
User feedback has always been an important component of the CLAM development process. As a matter of fact the framework was used ever since it began to be implemented and in many occasions, the line between the framework developer and its user has been blurred (i.e. even the same person can be acting as a part-time framework developer and a part-time user).
The CLAM project started using quite traditional software engineering methodologies but has evolved and come closer to more agile methodologies like eXtreme Programming [Beck, 1999]. As even the proposers of the methodology admit though, it is difficult to apply XP to a framework development process. The main reason is that one of XP's fundamental principles, which is to promote simplicity and avoid unnecessary generalizations if not strictly necessary is hard to observe in a framework development process. When developing a framework we are not only interested in making an application work but also on generalizing or abstracting as much of the common behavior as possible in order to build an infrastructure for any further application. Furthermore, organizational issues, such as the fact that most developers in an educational institution are part-time collaborators, make it even harder.
But we are definitely interested in many of XP's objectives such as having a design that is as clean and simple as possible or the idea of continuous integration and thorough testing Therefore many XP practices have been considered and are used to some extent. These include:
2004-10-18