explore the technical feasibility of a system – experimental prototyping.

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 130 Chapter 6 n Software development working on which parts of the system and consider these questions – will these parts integrate seamlessly? Do you need to define certain coding standards that everyone must adhere to? What are the likely effects of one part of the system on another when they are merged? If configuration management is going to be an important part of your project it may be worth considering using a software tool to support this. An example of such a tool is TortoiseSVN see http:tortoisesvn.tigris.org , which is free. Running under Windows, TortoiseSVN is a version control system that works with any development tool. It can also be used for document control so can be useful when trying to piece together a final report when working on a group project and each team member is working on a different part of the report. • 6.10 Which approaches should I use? 6.10.1 Which development approach should I use? In the majority of projects that I supervise, the students tend to follow an evolutionary prototyping approach for their software developments. For a six-month project starting in October, I usually recommend that students provide their client with and get feed- back on a prototype before Christmas i.e., within two to three months of the start. This allows them to consider any revisions, modifications and changes to their system over the Christmas break. In these cases, the students usually end up providing no more than two evolutionary prototypes to their clients before the final deliverable is released. However, some projects do follow a conventional model while others use incremental or throw-away prototyping approaches. So which is best to use? The following provides some guidance on which model is suitable in which circum- stances. You should discuss these options with your supervisor and choose what is right for you. You may, as part of your project report, be expected to justify and evaluate the process model you used, so make sure you choose an appropriate one. Some of the following advice was adapted from LevelA Software [2005]. Conventional waterfall-type model This is well-suited to projects that have a low risk in areas such as the user interface and performance, but a high risk in terms of schedule and control. It is useful in projects where the requirements are understood clearly by all involved and are unlikely to change during the course of the project. An example would be a specification provided by your supervisor that requires implementation. Incremental development This is appropriate for systems in which the requirements are generally clear and the system can be partitioned into a series of intermediate deliverables. It is preferable to the conventional approach in that it provides some user involvement and it can also be ‘terminated’ at any time yet still leave the user with a partially working system.