INTRODUCTION

only for RuBoard - do not distribute or recompile

Project management is often the key to the success of a project. Every project needs a project manager and some kind of project management methodology. It does not matter what kind of a project we are engaged in. Large physical construction projects like the building of bridges, ships, and tunnels all need to be managed. Although these sometimes go spectacularly wrong, we have much more experience at building these kinds of structures than we do at building large software systems. The building of physical edifices has one great big advantage over the building of software: you can see how much has been done at all stages of the project. Even the untrained observer can look at a bridge and can make an assessment as to how far the project has progressed. Whether they are working on the foundations, the supports, or the span is fairly obvious, and any of us could hazard a guess at how much is left to do. With software this is not the case. Even a trained observer can experience great difficulty in assessing how far through the project we really are.

Another problem is that the level of complexity in software systems is far greater than most other kinds of projects. Take, for instance, a jet fighter. To design and build one of these amazing modern machines is a very daunting prospect. But the most complicated part of the airplane is not the wings, the engine, or the fuselage; it is the software that runs all the aircraft's systems and the software that manages those systems. This controls the guidance of the aircraft and its weapons and keeps the pilot aware of what is going on both inside and outside the plane. Incidentally, the wings, the engine, and the fuselage are all designed by computer software. None of this stuff can we see, and so our approach to the management of software projects has to be more sophisticated than that of more conventional projects.

One way of addressing this issue is to tie the project management methodology into the software development methodology that is adopted for the project. There are many, many different software development methods but, broadly, they fall into two general categories:

Waterfall approach
Rapid application development (RAD) approach.

This subject was touched upon in Chapter 1. It is expected that most readers of this book are familiar with these and so the explanation will be brief.

There are many different representations of the waterfall approach, depending on one's view as to the major components . It is generally accepted that the phases of requirements gathering, analysis, design, coding, testing, and implementation would be included, and these are often depicted in a diagram like the one in Figure 9.1.

Figure 9.1. Classic waterfall approach.

The principles of the waterfall approach are that each of the major components has to be completed before the next can begin. So, for instance, the system requirements must be complete before the analysis can begin, and that must be concluded before the design can proceed. There is a very pronounced finish-to-start dependency on each of the major components.

The other main presumption of the waterfall approach is that, generally, we do not go back more than one step. So, for instance, we might find that, during testing, the coding needs to be changed and there is an iteration between coding and testing until the code passes its test. In real life, of course, it doesn't work like that and we find that, actually, the testing has revealed a misunderstanding on the part of the analyst who captured the original requirement.

Having to partially redo the requirements and subsequently modify the design, code, and test plans is time-consuming , demoralizing, and, of course, very expensive and is one of the main reasons that the waterfall approach is not any longer a highly regarded method. Nevertheless it still remains, in its many forms, as one of the major approaches to software development today. This is particularly true in data warehouse developments where, in some respects, this approach still makes sense.

The RAD approach works on slightly different principles and can be effective for applications which demonstrate the following characteristics:

Interactive ”where the functionality is clearly visible at the user interface. RAD is strongly based on incremental prototyping with close user involvement. Therefore, the users must be able to assess the functionality easily through demonstration of working prototypes , hence the need for visible functionality.

Has a clearly defined user group . If the user group is not clearly defined, there may be a danger of driving the development from a wrong viewpoint or ( worse ) ignoring some important aspect of the application entirely.

Not computationally complex. The level of computational complexity of an application is quite difficult to determine and will vary from one project to another. For instance, if an application requires some complex statistical modeling, a project may consider two approaches to development: fitting in existing, well- tested statistical modeling components or developing the models from scratch. The first would be acceptable in a RAD project. The second would be considered a risk, unless it is possible either to decompose the complexity into simpler components or to make it transparent at the user interface.

If large, possesses the capability of being split into smaller functional components. If the proposed system is large, it should be possible to break it down into small, manageable chunks , each delivering some clear functionality. These can then be delivered incrementally or in parallel. Indeed, some of the functionality may be delivered using traditional waterfall methods.

Time constrained. There should be a fixed critical end date by which the project must be completed. If this is not the case, it will be relatively easy to allow schedules to slip and the fundamental benefits of RAD will be lost.

Although there are clear differences between the waterfall approach and the RAD approach, there is one fundamental similarity: they are both all about the creation of applications in the traditional sense. Applications tend to implement a set of business functions. This means that there is a lot of talk about functionality and about processes. If we think about data warehousing for just a moment, where is the functionality and just what are the processes? Sure, there are some processes, such as the VIM processing, but the raison d' tre of a data warehouse is not to implement business processes; rather its purpose is to support other applications such as decision making, campaign management, etc. In this sense a data warehouse is not, in itself, a business application. This makes it rather odd. It's been said before that data warehouses are different. So we need to consider this carefully when trying to figure out how to develop one.

only for RuBoard - do not distribute or recompile