Technology Transfer Working Group Membership: Co-Chairs: Susan Gerhart, George Cleland The Technology Transfer (TT) working group met twice during the WIFT '95 workshop, each time for three hours. Three sub-groups were formed during this time to tackle specific issues. The main issue tackled during the meting was to discuss and identify the prerequisites for successful uptake and exploitation of formal methods by industry. The overall findings are reported in summary below. The findings of the three separate working groups are presented as "bullet" points as an annex. 1. Domain Frameworks This was an issue which was visited and revisited by both other groups, and the workshop plenary sessions. Formal Methods research to date has largely concentrated on development of generic technology. While this advances general scientific understanding, it has proved difficult to apply in application domains. It was felt (almost universally by the whole meeting) that there is a need for a marked increase in both research and cases study work in a range of application domains. Domains discussed by the meeting included: embedded systems, control technology,..... The intention here is to develop a "common currency" within these engineering domains. The exact nature of this would depend on both the domain, and the outcomes of the research as it develops. Outcomes would be useful in areas such as, modelling techniques for domains, example models, parameterisation mechanisms, domain specific notations, and tools. Common process models are also thought desirable, but with the volatility of systems engineering process models at present, this is perhaps a longer term objective. A useful approach may be to explore the mapping of application domains (such as those above), against technical domains where there is already formal method activity and results. This will result, not only in the infusion of existing work into new domains, but the identification of common technical approaches across different domains. The beginnings of an applied science maybe? This kind of structural information is common i there engineering disciplines, and we should be aspiring to generate it as a major long term objective in the systems/software engineering area. 2. Supporters While localised technical success can be achieved without it, internal and external support is essential for systematic uptake in organisation. The kinds of support needed will depend on the organisation and the application, and an individual may play more than one of the roles below, but they include: Patron This is and external or internal sponsor of the technology who is interested in its uptake , either in a specific company basis, or in a broad cross industry basis. They are not usually involved directly in the work, but create an environment in which the initial expensive and more risky work can proceed i a protected fashion. This can be achieved through either political or financial means. A patron often will have a long term vision for the technology, and its impact of the market. Champion This is someone within the organisation directly concerned with the initiative. They may or may not be concerned with management of the project, but establish and maintain the environment within which the work progresses. As with a patron this can involve both political and resource issues. It is a more hands on role than a patron. Facilitator These might be agencies or regulatory authorities, which might take a more neutral position than a patron, responding rather to more objective pressures. In the case of a regulator, moving the goal posts forward to promote uptake of new techniques as they become viable. A funding agency might promote a strategic programme in identification of the maturing of a new technology whose adoption which might confer competitive advantage. 3. Core practitioners Without adequately educated and motivate members of the workhorse formal methods uptake will remain a local phenomenon whose success will depend on particular individuals, with little opportunity for diffusion across industries and companies. This needs a Critical Mass of practitioners. While the existing workforce can be re-educated to a certain extent, in the long term this must come through the education process. This needs appropriate development of the curriculum, but to achieve this on a broad basis may require a significant move in position between educators and industry. Move to define national core curricula (covering more than just formal methods) may go some way towards this. A second benefit here is that as those educated in formal methods progress through their companies they move into positions where they can influence company technical policy. It is important that the duration process leave graduates with a positive feeling of the usefulness of formal methods. This remains a problem, which might also be tackled by re-considering the position of formal methods in the curriculum , as well as re-evaluating the way that formal methods are currently taught. 4. Customers to buy products There is no point in pursuing "improved" technology without customers to buy the product or service at a economic rates. Leverage here comes from a number of factors: * a demand for higher assurance by customers including mission-critical, business-critical and safety-critical systems * satisfying regulatory demand, either in demonstrating product quality, or in use of formal methods during product development. * increased productivity in development, allowing products to be sold at more competitive rates, and with more predictable costs * higher reliability thus reducing customer maintenance costs. 5. Informed, adaptable managers Introduction of formal methods into a development will affect many process variables. Milestones, metrics, customer relations, skill requirements, budget profile are all likely to be affected. Managers of such projects will need to take all these issues (and probably more) into account during setting up and running a project