explore the requirements of the system with the user – requirements capture, andor

6.9 Configuration management 129 Extreme programming is an approach that is well suited to projects in which the requirements are likely to change. The approach actively encourages the users to be involved with the development process and anticipates the positive influence they will have on requirements capture. It emphasizes teamwork and, in the case of student projects, encourages the users, supervisors and the project team to work together towards a common goal of developing quality software. According to Wells 2006, extreme programming ‘improves a software project in four essential ways; communica- tion, simplicity, feedback and courage’. One of its principles is to deliver the software early, obtain feedback on the system and implement any required changes. In some ways the approach is similar to that of evolutionary prototyping although there is much more guidance on how the team should work together and how testing should be pre-planned than is provided by the evolutionary model. Although the detail of this approach’s methodology is beyond the scope of this book, some if its guiding principles are worth remembering; involve the user in the project, pre-plan testing before coding, deliver the system early and ensure strong communica- tion between all stakeholders. •

6.9 Configuration management

One thing that you must be careful to control when pursuing an evolutionary or incre- mental approach, or in a team project when a number of people are working on differ- ent parts of the system simultaneously, is the system’s configuration. Configuration management is used to control the different versions of a system that are produced as the system develops. It is closely related to version control and revision control. In large industrial projects configuration management is an important activity and typically involves four stages:

1. Configuration identification: identifying the attributes that define the item you

are hoping to control – what makes it as it is – and setting this as a baseline.

2. Change control: managing and approving changes to the item and adjusting the

baseline.

3. Status accounting: recording the configuration baselines.

4. Configuration audits: ensuring that changes to configuration do what they state

they will do and the system continues to satisfy the requirements it does not drift. For student projects a comprehensive configuration management system is unneces- sary. However, as you develop and release new versions of the system you must make sure that you keep track of these versions; what changes have been made, who has made these changes, who has received them, where they are savedbacked-up to, etc. If something goes wrong with a ‘release’ it is useful to be able to go back to the previous version to try to determine what has gone wrong. Make sure that you date stamp each version of the program that you produce no matter how small the change that is made – perhaps by including the date on a splash screen or main menu. You might also consider updating the version number too particularly for major changes. This will allow you to keep track of the latest version of your system and, as you make frequent back-ups, which back-up is the most up-to-date. Also, for team projects, keep a note of which team members are