There are a lot of SDMs. The oldest, and most frequently used one is the one where the client defines his requirements. Based on these requirements an extensive analysis (UML diagrams, workflow diagrams, …), is made. Once these steps are completed a development team starts developing on a first version, and after 9 to 12 months a first version will be shown to the client. The steps I described are some steps from the waterfall model, a sequential software development model.
Working with such an SDM could work in a big software factory, but not in open source projects. For open source projects — as well as closed source projects, there’s an SDM that could be better suited: agile software development.
Agile software development
Agile software development is an SDM that promotes development iterations throughout the life-cycle of the project. The modern definition of agile software development evolved in the mid 1990s as a part of a reaction against “heavyweight” methods. The use of the waterfall model were seen as bureaucratic, slow and inconsistent with the ways that software developers actually perform effective work. Therefore, agile methods were also called “lightweight methods”.
Agile methods are a family of development processes — not a single approach of software development. Some of the principles of the Agile Manifesto are:
- user satisfaction by rapid, continuous delivery of useful software
- working software is delivered frequently (weeks rather than months)
- even late changes in requirements are welcomed
- simplicity
- close cooperation between end-user and developers
- projects are built around motivated individuals — who should be trusted
- regular adaption to changing circumstances
It quickly becomes clear that working versions of the software are delivered on a regular basis. This shows that iterative development is one of the key aspects of agile software development. Analysts don’t create an extensive analysis document. Instead, the end user creates user stories. Once the user stories are finished, developers pick their user story and start implementing them. Once the iteration is done (which can be from 1 to 4 weeks) a working version of the software is deployed. This version will be shown to the client, and based on his input on the current version, the software gets modified.
By using iterative development, defects will be rapidly detected, as well as the changing needs of the client. Also, the client will be heavily involved in the development process. Also, this has as a consequence that there is a continuous integration: the build must be working at every moment, because implementations of other developers are dependent on your code.
At Joomlatools we are heavy proponents of agile development. Each of our client development projects gets it own “incubator-project” and divide the development into iterations or milestones of 2-4weeks depending on the nature and scope of the project. Right before each iteration ends, we deliver a working build of the project to the client.
This has a number of advantages: the client is heavily involved — even clients with a lack of technical know-how. A second advantage is that requirement changes can be made after each iteration at very low costs. We just needs to make sure that we can provide a working version at the end of each iteration, and that’s it! A certain milestone could only have implemented 5% of the initial goals, which isn’t a problem. By releasing often and early main defects detection and client input are increased enormously. After all, isn’t this what open source development is all about?