FD2121 - Software protocols and architecture specification for RASP work and Joint programme outputs

Theme:Strategy and Policy Development
Project status:Completed
Start date:28/04/2006
End date:31/10/2006
  • Flood and Coastal Defence,
  • Modelling,
  • Flood Defence,
  • Land,
  • Environmental Protection
  • Halcrow Group Ltd


This project has underlined the need for effective software standards in FCERM. Through the use of trial applications, the research has presented guidance for the integrated production of software, placing emphasis upon dialogue between the contractor and the EA’s IT specialists. Useful steps have also been made towards identifying a future framework for RASP related project outputs. This research will be of relevance to all those involved in software development and modelling outputs within the joint Defra/EA R&D programme.

Summary Objectives
1. to draw up and agree with EA CIS a common set of protocols covering CIS standards on architecture, languages, softwards platforms (e.g GIS systems), interface and data exchange protocols, testing and acceptance, applicable to all software outputs of the joint R&D programme, in order to permit fair tendering and the efficient production of the conforming software.
2. To draw up for the RASP family an overall system architecture which will identify and specify common modules. This will be declared openly in order to facilitate competition.

Key Customer Purpose
It is clear that the joint R&D programme is going to produce, as an important part of its outputs, a considerable number of software products. Some of these will be operational or planning tools which will be mounted on EA systems. They will therefore need to conform with CIS standards on architecture, languages. software platforms (e.g. GIS systems), interface and data exchange protocols, testing and acceptance.
A second point is that a number of them will be inter-related. The RASP family is perhaps the prime example, but there are parallel systems being scoped or developed in other fields such as WFD. For efficient development and support these should be designed so as to use common modules wherever possible, within an open software architecture.
A third point which follows from the first two relates to competition. unless we want to be restricted to Halcrow and HRW, we will want to open up to others opportunities to work on the RASP family. This will be greatly assisted if we have an open, common set of protocols and architecture for the RASP family.