Project Approach

The Rational Unified Process (RUP) was used as the project management and software development approach. It is a software development process framework which enables adopters to select process elements to generate a process customized to their needs.

The development team’s aim in a project like SUNIWE was to produce a high quality portal implementation that met the needs of its users under the constraints of time, the small size of the development team and the skills and relative experience of the developers. The project needed a well-established, iterative process to enable the developers to succeed and RUP fitted the bill.

RUP projects are comprised of four Phases. Each phase is comprised of one or more Iterations through the software development workflows (Requirements Capture, Analysis, Design, Implementation, Testing). Requirements are captured as descriptions of how the user interacts with the system. Each iteration produces working software which implements some of the descriptions (use cases) or addresses some of the technical risks.

The phases have specific objectives:

1. Inception Phase - focuses on establishing the business case for the project

2. Elaboration Phase - focuses on addressing the major technical risks of the project

3. Construction Phase - focuses on building the beta version of the working system

4. Transition Phase - focuses on refining and fine-tuning the system to best meet the needs of the users

Each Phase and Iteration is planned at the start and evaluated at the end. This ongoing evaluation and feedback loop allows the project and the process to be refined to produce better quality software.

The project plan called for the portal to be developed first within SURF and then the outputs cascaded and implemented within WETN. This would give the WETN team more time to understand the extent of what was achievable and refine their requirements in light of the experience of the SURF implementation.

RUP offered several advantages:

1. it provided a well-defined structure for the lifecycle of the project and clearly articulated milestones and decision points

2. it focused on providing value for the user of the system

3. it focused on quality

4. it focused on producing working software

5. it included evaluation and refinement as a core part of the process

6. it was iterative and incremental

7. it comprised many software development best practices

8. it was well-supported with a large user base and extensive documentation

SUNIWE represented the first attempt at iterative development for the development team so the team wanted a methodology with a well-structured project lifecycle and the reassurance of good reference literature and a large user community. The customisable nature of the process was also important, as was the emphasis on producing working, tested software rather than documentation.

It was important to use an iterative software development approach because it better suited the R&D nature of the project.

The Traditional Approach

The traditional software development approach is one in which all the development workflows happen once in a series (requirements gathering, analysis, design, implementation, testing) hence it is also know as the Waterfall approach. All work is planned in detail at the start of the project. Changes to the project plan are considered exceptional events and are dealt with accordingly.

The Waterfall approach relies on some prior knowledge or experience of what is being implemented. This rarely is the case with research and development focused projects such as SUNIWE. With the development team unfamiliar with the nature of the problem and sometimes even the tools and technologies used to solve it, the initial project plan is essentially guesswork.

The Waterfall approach also defers testing and integration until the end of the project lifecycle. Consequently, problems tend to be harder and more expensive to resolve. A working system is only available after integration at the end of the project which rules out demonstrations and user feedback as the project progresses.

The Case for Iterative Development

Iterative development is an approach that builds software in a sequence of incremental steps. Each step, or iteration, includes some or all of the development workflows as well as management and evaluation activities. Each iteration produces a working system of limited functionality. Successive iterations build on the work of the previous iterations to evolve and refine the system until the final product is complete.

Iterative development has many advantages over waterfall development.

1. It embraces changing requirements. Change is seen as a natural part of the evolution of the system rather than an exceptional event. Evaluation of the working system from each iteration feeds back into the process. Decisions can be made as more is learned about the problem being solved, rather than guessing at the start. In this way the direction of development can be steered to ensure the system meets the needs of the users. The development process itself is also refined via evaluation.

2. Integration of components is done during each iteration. This means integration problems are spotted earlier when they are more easily and cheaply solved. Risks associated with the architecture of the system are also identified early on and can likewise be dealt with without major reworking of the product.

3. Similarly, performance bottlenecks are spotted early and can be dealt with over several iterations. Bugs are found and dealt with in each iteration so the core parts of the system will have been tested thoroughly and repeatedly by the time the system is complete. This results in a robust architecture and high-quality product.

4. Reuse is facilitated because it is easier to identify common functionality when encountering it during development iterations than in planning.

Iterative Development in the World of JISC

Iterative development is particularly suited to JISC project work. JISC projects often involve new technologies and standards and unfamiliar domains. An iterative approach allows the project team to run through the development workflows several times, each time learning more about the new aspects of the project. As the team gets a better handle on the new tools and technologies, this learning is fed back into subsequent development and a better quality system results.

JISC projects are often speculative and concerned with creating innovative and novel solutions. At the point of securing funding, project teams often don’t know what they are going to build in any detail. They have a good idea what they would like to build, of course, but they do not know whether it is feasible. The scope and nature of a system can change radically as more is learned about it as the project progresses. For this reason, a detailed project plan drawn up at the start of the project can be worthless as most of the plan will be guesswork. Using an iterative approach, the overall project plan is kept course-grained and detailed plans are made only for forthcoming iterations and phases. This allows development to be structured but allows the direction of the project to evolve as more is discovered about the system being built.