This is the final Report of the SERC's Software Technology Initiative (STI). Its purpose is to:
In 1979 an SERC Panel, chaired by Derek Roberts, recommended that SERC mount major new initiatives in several fields of Information Engineering. One of the new technologies recommended for encouragement was Software Technology.
The Roberts Panel reported that:
Already the cost of software is frequently greater than that of the associated hardware, and this trend will be accentuated by the reduction in (silicon) hardware costs. Software production must be one of the few industries where no adequate tools exist for specification, design, production updating and re-engineering. Despite the high cost, and long development cycle of most large systems, no serious attempt is being made to develop new software methods and standards which could reduce both costs and timescales. Add to that the need for improved hardware independence and more user-orientated approaches to high level language development and it is clear that this should be a major area for SERC support. The Panel is aware that the Computing Science Committee has devoted significant funding to this area but considers that more should be done, particularly in exploiting existing research and applying this in industry. As with Silicon Chip Design, there may be a need for a mechanism to bring Universities, Software Houses and Industry together and maximise the benefit of academic research, taking full account of the major contribution industry is able to make in this area.
The SERC's Computing and Communications Sub Committee acted on the Roberts Panel's recommendations and, in November 1981, launched the Initiative.
The CCSC identified three major objectives for the Software Technology Initiative.
The CCSC wanted to stimulate Software Technology research aimed at improving the short term situation (see section 5 Academic Software Technology Base) and to tackle the Software Crisis via longer term investigations (see section 9, Research Priorities).
The whole academic community, not just computer science, is a major user and developer of software and so the degree of ease with which software can be developed affects the scientific productivity of many researchers. The academic software technology base is that nebulous entity which encompasses the overall level of skill, experience and knowledge contained in the staff, tools and techniques which are used by the academic community to develop software.
In 1981 the academic software technology base was very non-uniform in that the knowledge, experience; tools and techniques varied considerably between individual projects. It was always heart-breaking to meet, say, a research assistant who spent 75% of his time programming but who had never heard of cross-reference generators, pretty-printers or screen editors let alone symbolic debugging packages or predicate transformers. Conversely, one sometimes found non computer science projects which had invested considerable time and effort in developing sophisticated programming tools and techniques to solve their own special problems but which, if they had been disseminated, would have been valuable to a wider community.
A task still facing programmers is finding out what tools and techniques already exist to help them with their jobs. There is currently no efficient way in which the benefits of existing work can be disseminated to potential users, except in some special areas in which the NAG library is a fine example.
The CCSC approved a plan containing the following major threads:
The Roberts Panel were aware that the Computing Science Committee has devoted significant funding to this area (ie software engineering) but considers that more should be done, particularly in exploiting existing research and applying this in industry there may be a need for a mechanism to bring Universities, Software Houses and Industry together and maximise the benefit of academic research, taking full account of the major contribution industry is able to make in this area.
Technology transfer consists of:
ideas people industry
techniques via paper between GRE
experience software academia
tools hardware
meetings
training
The Roberts Panel recognised that:
To achieve these two sub-objectives the CCSC considered it desirable to:
It was envisaged that by setting up software technology centres, coordination, collaboration between funding bodies, an increased level of research activity and the creation of software engineering development and user communities, the British academic community would be drawn into close and profitable associations with British industry.
The CCSC wanted to implement the following steps to try to improve the academic community's software development capability.
Tool users would access tools via:
The whole academic community, not just Computer Science, is a major user and developer of software and so the degree of ease with which software can be developed affects the scientific productivity of many researchers. The SERC's Common Base Policy relates to all SERC supported subject areas thereby giving the Software Technology Initiative the maximum opportunity to try to improve the software technology available to all scientists.
Currently the academic software technology base is very non-uniform in that the knowledge, experience, tools, techniques and equipment vary considerably between projects. The motivation to create a common Hardware and Software Base is to bring together a1l of the best existing tools and techniques into a uniform framework so that the whole is more effective than the sum of diverse parts. This is being achieved via EMR contracts to move existing tools into the common base, specific purchases, and the direct results of SERC research projects using the state of the art common hardware base. A good example of the common base snowball effect is the widespread use of the Unix operating system which has enabled a large number of software tools to be made available throughout the UK academic community.
The Common Base Policy and the STI Infrastructure Policy are described in detail in the appendices. Briefly the CCSC wished the common software base to be Pascal/Unix and the common hardware base to be the PERQ. The PERQs were to be networked together via the Cambridge Rings, JANET and PSS to allow widespread cooperation between tool users and developers. This combination of software and hardware was widely accepted as being the best combination for developing tools in the coming years. A common base does not imply rigid standardisation however.
The software tool development programme thus proceeds as follows:
he PERQ computers have been purchased from a British company, ICL. Network equipment is based on the Cambridge Ring, in line with the DCS Programme. Thus, the Common Base Policy means that the academic community directly contributes to improving and promoting state of the art industrial initiatives.
The mutually beneficial effect of practically linking academic research to industrial companies helps to build up technology transfer.
The Council became aware that powerful single user systems were going to change the way SERC provided computing resources to all scientists, not just Computer Scientists. The Council therefore approved a recommendation that all Single User System purchases and developments be handled centrally through the CCC with development activity coordinated by the RAL, who collaborated with ICL to promote technology transfer between industry and academia.
Thus the CCSC's idea of a common base policy has been endorsed and expanded by the Council. For further information contact Dr K Robinson, Head of Common Base Section, Informatics Division, RAL, tel Abingdon (0235) 21900x649l.
The common base policy was designed to have an effect on both the short and medium term aspects of programming efficiency by reducing duplicate production of tools for different machines, reducing training needs and increasing the quality and capability of tools available to scientists.
Whilst the Common Base Policy has made life better for practicing programmers by rationalising the activity of current technology, it was vital that the CCSC funded projects which were likely to lead to significant new techniques to solve the Software Crisis.
The Coordinator had a number of discussions with academic and industrial software engineering experts and a letter soliciting views was circulated. As a result of this activity the following list of priorities was identified.
Areas of importance in which the CCSC invited proposals included:
A coordinated approach to research in Software Engineering has two main advantages:
The coordination is achieved at two levels.
First within the Initiative itself, there is continuing contact with the investigators, starting with assistance in working out proposals with investigators. This is continued through the research by information services, including a regular research community mailshot, and a wide variety of collaborative workshops. The coordinator is available throughout for ad hoc assistance with technical and organisational difficulties.
Secondly, outside the Initiative, links are fostered with industrial organisations (including government establishments, etc.) likely to make use of research results. This aims at the transfer of technology to the industrial sector through involvement of investigators in industrial problems, the exploitation of research products and concepts, and the furtherance of projects through co-operative research. These aspects become of even greater importance as the programme approaches maturity.
There has existed, then, a positive programme of research into Software Engineering, managed by an STI Panel appointed by the Computing and Communications Sub-committee. The Panel monitored the activity of the programme, and advised the Sub-committee on questions of policy and finance. The Panel was advised and supported by the Coordinator, who acted as roving ambassador for the programme, and provided day-to-day support for researchers.
The precise mechanics of coordination evolved as the Initiative developed, but the essential features are as set out below. Coordination will continue from September 84 but within the Alvey context.
Within the Initiative, as its scope is very broad, the degree of coordination appropriate to each research project varies according to its nature. Effort has been concentrated on the following aspects:
As the programme matures, within the Alvey context, the emphasis lies increasingly on fostering industrial interest in the programme, with the objectives of promoting collaborative projects and facilitating a high degree of technology transfer. This is best achieved via:
The Coordinator provided information on the research programme. advised on mechanisms available for supporting collaborative research, and helped mediate potential researcher/industry relationships.
The SERC supports academic research by awarding grants to investigators for staff, equipment and travel. Investigators may also apply for practical support from the various SERC laboratories which provide specialised services and facilities such as the FRBo colour microfilm recorder, large mainframe computers and microelectronics design and fabrication facilities.
The STI was supported by the Rutherford Appleton Laboratory (RAL) from November 1981. The Coordinator was on the staff of RAL and other RAL staff provided software and hardware support for the Initiative. Typical ways in which RAL support was provided included:
The SERC's Roberts Panel Report farsightedly highlighted the national urgency for an increased level of UK Information Technology research.
When the Japanese launched their Fifth Generation Computing Systems initiative the UK government responded by setting up the Alvey Committee to consider the UK's position. The SERC was able to make a substantial contribution to the Alvey Report thanks to its Roberts Panel inspired Information Engineering activities, including the STI and the DCS Programmes. Experience had thus been gained of the management of IT research on a national scale and plans for further SERC initiatives were already in the pipeline.
Following the establishment of the Alvey Directorate, formed from a collaboration between SERC, DTI, MOD, academia and industry, it became clear that the STI was, in reality, a subset of the proposed Alvey Software Engineering Programme. Thus the STI was transferred to the Alvey Directorate and the STI Coordinator seconded in June 1983 to act as Deputy Director of the Alvey Software Engineering Programme. The STI was therefore prematurely terminated on 31 October 1984, in its role as an SERC programme, but lives on, in expanded form, as the academic portion of the Alvey Software Engineering Programme. The Alvey SE Director now has responsibility for all STI initiated activities.