Sheffield Software Engineering Observatory

The process of creating software systems is quite a complicated one, which involves a number of different activities that need to be fitted together properly / there is much more to it than just writing simple programs, as various descriptions of different parts of the programs have to be produced as well. One of the reasons why this process is complicated is that, where the software is to be used in real business situations, the team developing it may have to cope with frequent changes in the details of what the business needs the software to do, because the business is in turn having to respond to changes in the market place in which it works.Traditional ways of fitting together the activities in developing software do not cope very well with frequent changes in what the software is required to do, and so newer ways (usually called agile methods ) have been developed to try to do this better. Those who have developed these agile methods claim that they are actually better than the traditional ways of doing things, but there is very little hard evidence to back up this claim. Thus, the main goals of this project are to try to find evidence as to which of these ways of developing software are actually better, and (perhaps more importantly) to find out why the better ones are better.To do this we will run a number of experiments, where in each a number of teams of students will build real pieces of software for a real business client, and will compete to see who can build the best, but with different teams using different methods. Thus, some teams will use the traditional methods, some will use the agile methods, and some will use methods that are a mixture of traditional and agile. During each experiment, we will measure how much time they spend on each separate activity, and we will analyse the software and the other descriptions of it that they produce while they are working, to see how well they match the actual requirements of the business client, as these are changing. From this, we will be able to work out for each method how well it allows the teams to develop the software, and how the different features of each method contribute to this.