• accelerate the introduction and widespread use of high-payoff software engineering practices and technology by identifying, evaluating, and maturing promising or underused technology and practices;
• maintain a long-term competency in software engineering and technology transition;
• enable the UK academic community to make measured improvements in their software engineering practices by working with them directly;
• encourage the adoption and sustained use of standards of excellence for software engineering practice;
• foster collaborations with other groups, in the UK, Europe and the US, that have an interest in the applications of advanced software engineering techniques in computational science.

These goals will improve the level of software engineering practice within UK computational science research groups. As a result, the software they develop will be of a higher quality; more easily developed and maintained; more easily re-used within the community and be computationally more efficient.

General dissemination of the projects of SESP is covered in Section 7. Here we note how the tools and processes gathered by SESP will be introduced into CSED’s scientific software development programmes.

There are a number of threads in SESP ranging from tools to verify language conformance to tools to aid full scale re-engineering. The impact on the development project is clearly dependent on which tool or process is being adopted. Although much of the information flow between SESP and the science projects will be through web information pages and seminars/workshops, SESP will identify two or three Flagship projects in collaboration with the science groups.

For example, as part of CCP5 (Computer Simulation of Condensed Phases), we envisage a project to completely re-engineer DL_POLY to use all the features of Fortran 90/95. The degree of software engineering tools to be used could range from just simple transformation tools to the adoption of a complete IDE with CASE tools. SESP and CCP5 will therefore establish a short collaborative project to introduce and use the SESP tools, thereby enabling CCP5 to continue using the tools in future developments.

CSED will review the SESP programme after its first year in operation. If this review is positive, CSED intends thenceforth to commit to use SESP methodologies in all its major software development projects. With this commitment as a platform, CSED will develop ways of offering SESP methodologies to scientific applications developers in the CCPs and the wider computational research community.

4. Collaborations & Exchange

Within the UK community there are a number of groups interested in software re-engineering and software quality. However the majority of this work is directed to C++ or Java. Fortran is not seen as a great priority. Section 10.1 gives some web links to activities ongoing in the UK related to the proposed activities of SESP. There is a large variety of software engineering research in the UK and Europe however much of the transformation and re-engineering activity is directed to complex business systems and not toward computational science applications and Fortran. SESP will develop links with the leading European software engineering groups working on methods for high performance computing. CSED already has some contacts to institutions such as CWI in Holland, INRIA in France and CNR in Italy through ERCIM.

Software Engineering is an area of great activity within the US and organisations, such as the NSF with the Software Engineering Research Center focused at Ball State University and NASA with the Fortran Modernization Project among many, have made significant investments. SESP will develop specific software engineering links with NSF laboratories with which CSED already has Memoranda of Understanding (NCSA, PSC and SDSC). SESP will also seek to develop links with the teams in NASA and other US programmes that have active work in this area. In particular links will be sought with the groups at PNNL and the Computational Sciences and Engineering Division at ORNL. Part of this process will include attending the NASA/IEEE Software Engineering Workshop.

Section 10.2 lists some of the current and recent US activities from which SESP will draw on and develop collaborations. CSED will aim to cement such collaborations initially by organising an "N+N" meeting to share software engineering practices among those developing the most challenging scientific applications in Europe and the USA. This, we hope, will nucleate an international "Scientific Software Engineering" community.

5. The SES Programme

In the following sections we describe the main themes of activity the programme will undertake. Each section gives some of the background to the theme and a list of proposed objectives. In some themes the EPSRC SLA is already funding some activity: for these the current level of effort supported is indicated in Table 2. In general the scope of the current activity has been broadened with additional deliverables.

In the following paragraphs we emphasise the need to maintain a good awareness of the current trends in software engineering particularly as applied to software developments in computational science and engineering. The gathering of this information will enable CSED to take on broad practices and tools as appropriate. These initial steps have been characterised by the Technology Watch, Assessment & Evaluations process. Although the software engineering community has various very formally defined processes of Software Assessment & Evaluation we have defined below a rather more pragmatic approach for SESP.

Technology Watch: In each elements of the SESP information will be gathered on a regular basis and a rolling update made to a Technology Report. The primary sources of information will be:

All the information would contribute to a technology watch report that would be made available to the community through the SESP Web site.

Assessments: The starting point of selecting a tool for use in anger would be through paper assessment using a basic requirements document. The detail of the assessment would clearly depend on the area being addressed but there would be a collection of fundamental requirements such as operating systems, supported languages etc. developed by SESP. The applications Groups within CSED will be involved in developing and extending the requirements document for their own particular areas. These paper assessments would identify tools for practical evaluation. Much of the material developed in the paper assessments would be added to the technology watch reports.

Evaluations: Through the assessment, various tools will be selected for more direct evaluation. In discussion with the vendors, evaluation or some form of limited license would be agreed and the tools installed. They would be used in a realistic context either by SESP staff or those involved in the CCP and HEC programmes and their usefulness and effectiveness documented. Although in general the evaluations would not be placed on critical paths within the CCP or HEC activities, these programmes provide a considerable number of representative software packages that can be made the subject of an evaluation. The evaluations would lead to detailed reports and if successful the deployment of the tool or practice within the main stream.

5.1 Software Quality Assurance

Software Quality Assurance is the basic of software engineering processes that should be undertaken by all software developers. However the majority of codes in use and being developed within the community have not been through any process of QA save that of the compiler being satisfied.

The target language for most applications is now Fortran 95 or even Fortran 2000. Although the commercial world of Software QA is dominated by C, C++ and Java, there are good Fortran tools available. PlusFORT, ForCheck and the NAG Ware are but three examples. CSED has experience in using these tools and are developing web and GRID based interfaces to a collection of them.

The tasks for this activity are:

Part of this activity is already funded under the current Facilities Agreement (see Table 2).

5.2 Processes for Legacy Software

For many applications within the science and engineering community the root language has been Fortran 77 and for some - even Fortran 66. Software engineering has developed and languages have grown and now Fortran 95 and C provide the main modern vehicles for these applications. However we will make the assumption that the majority of the software of interest is in Fortran (of some form) and that the target language is Fortran 90/95.

To maintain and continue to develop the science encapsulated in these legacy codes a process of transformation and re-engineering must be formalised. This can be broken into three basic steps: standardisation, transformation and re-engineering.

Standardisation: As mention above often legacy codes are in Fortran 77 or 66 or even worst a mixture of standards and dialects. In general the standard of research programming is limited and most often not particularly portable. The codes often adopt mechanisms from other languages. The main example of this are the # directives from the Unix C pre-processor cpp - #include and #def are but two. To aid there transformation process these will need removing and documenting.

Transformation: Once the basic code is in a standard form automated transformation tools can be used to change the software format (e.g. fixed-form Fortran 77 to free-form Fortran 95). This is purely a source to source transformation and no structural changes are made. However it maybe thought necessary that the original legacy code be maintained for some compatibility reasons. If this is the case this code can be wrapped in some appropriate statements that will enable the legacy code to be called directly.

Re-Engineering: Within Fortran 90/95 there are many features that will improve the quality of an applications program in performance, maintenance and development potential. Examples are: modules, derived data types, dynamic memory management, pointers and allocatable arrays. This is the most difficult part of the process as it may require considerable re-writing of the software.

One of the major difficulties with this process is author recognition - the originator or current developer of the code no longer recognises the software and hence is reluctant to use the newer version as the basis of future development. The starting point of this process must therefore be a body of code, documentation, test data and their resultant outputs. This material will be used to inform, control and provide checkpoints within the process as well as ensure that the author(s) of the software will have confidence in the software in its new form. Involvement of the authors is essential, as they need to develop a new image of their software.

The tasks for this activity are:

• Survey approaches to the maintenance and renewal of legacy software
• Perform tools assessment on typical community applications
• Develop a legacy software process for community software
• Make tools available through suitable interfaces
• Provide web base documentation on tools

Part of this activity is already funded under the current Facilities Agreement (see Table 2).

5.3 Evaluation of Methodologies, Tools and Technology

The computer science community has a long history of developing new methodologies, tools and technologies to aid the development of computing applications. These range from new languages, such as JAVA, to frameworks and environments that gather these tools and processes together in an integrated form, such as the Microsoft Visual studio. Along side these elements the computer science community are at the forefront in developing tools to assist the applications writer exploit the most advanced computing architectures such as the IBM Regatta and the SMP structure of the NEC SX6 or Silicon Graphics 3000 Series.

Although the scope of the SES Programme will be the SLA, CCP and HEC programmes within CSED it is clear that the results of the programme should be of use to the general computational science community.

The programme will seek the requirements of the CCP and HEC communities and review the practices being currently used.

Clearly much of the software in this area is commercial. Where possible and where thought useful collaborations will be sought with software vendors. Preliminary contacts have been made with Intel and IBM over CASE and optimisation tools and approaches will be made to a number of the other tool vendors.

We view this as the development of a long-term support programme in the provision of software engineering technology and methodology to the computational science community. The SLA is the most appropriate framework in which this work should sit benefiting and participating in the SLA reviewing and assessment arrangements.

There are numerous threads to the SES programme. Table 1 below gives an initial broad estimate of the resources required by the programme and Table 2 gives an indication of the effort in FTE and time planned for each thread over the first two years.

	Year 1	Year 2 and on-going
Staff (FTE)	3	3
Software Licenses (£K)	10	5

Table 1: Summary of Resources

The SES Programme is viewed as a bringing together of a number of software engineering strands important to ongoing CSED activities. It will become an ongoing activity along side those of the CCP and HEC programmes providing the software engineering input to these programmes. Outlined above is an initial two-year programme, the second year of which is intended to be an estimate of continuing year-on-year resource needs. Following, and subject to, the review mentioned in section 3, the programme will be developed in consultation with the CCP and HEC activities during the early part of the second year and a rolling programme of activities proposed.

CSED believes that an enhanced investment in software engineering practices now will pay significant dividends in the future. These include: higher quality scientific software; shorter development cycles; easier maintenance, porting and performance tuning. As the computational research community increasingly recognises the strategic importance of cost-effective software support as well as hardware facilities, we believe this is a timely and appropriate initiative for CSED.

UK Groups and Resources

• The Research Institute for Software Evolution (RISE), Durham:
  http://www.dur.ac.uk/CSM/
• De Montfort's Software Technology Research Laboratory
  http://www.cms.dmu.ac.uk/STRL
• Report on first SEBPC workshop on legacy systems:
  http://www.dur.ac.uk/CSM/SABA/legacy-wksp1/report.html
• RENAISSANCE ESPRIT Project on Re-engineering:
  http://www.comp.lancs.ac.uk/computing/research/cseg/projects/renaissance/RenaissanceWeb/index.html
• Lancaster University's Computer Department:
  http://www.comp.lancs.ac.uk/computing/
• Distributed Software Engineering Group, Imperial College:
  http://www-dse.doc.ic.ac.uk/
• Software Evolution and Reengineering Group, De Montfort University:
  http://www.monkeydancer.co.uk/serg/

• Department of Computing Science and Mathematics at the University of Stirling:
  http://www.cs.stir.ac.uk

• The Center for Empirically-Based Software Engineering:
  http://www.cebase.org/www/home/index.htm
• The Experimental Software Engineering Group (ESEG) of the University of Maryland:
  http://www.cs.umd.edu/projects/SoftEng/tame
• The University of Southern California, Center for Software Engineering:
  http://sunset.usc.edu/index.html
• Fraunhofer Center for Experimental Software Engineering - Maryland:
  http://fc-md.umd.edu/fcmd/index.html
• The NASA Software Engineering Laboratory (SEL):
  http://sel.gsfc.nasa.gov/
• Laboratory for SEDS, University of Calgary
  http://www.seng-decisionsupport.ucalgary.ca/

• Software Engineering Research Center (SERC):
  http://www.serc.net/
• MIT Laboratory for Computer Science:
  http://www.lcs.mit.edu/
• The Software Engineering Institute (SEI):
  http://www.sei.cmu.edu/
• Software Technology Support Center:
  http://www.stsc.hill.af.mil/

• International Software Engineering Research Network:
  http://www.iese.fhg.de/ISERN
• Fraunhofer Institute for Experimental Software Engineering, Germany:
  http://www.iese.fhg.de/

• Software Engineering Group, CWI:
  http://db.cwi.nl/projecten/cluster.php4?clstnr=1