Wing Lam
Interactive Systems Development Initiative
Department of Computer Science, University of Hertfordshire
College Lane, Hatfield
Herts AL10 9AB, UK
Tel: +44 01707 284337
Fax: +44 01707 284303
Email:
W.Lam@herts.ac.uk
Technology transfer is an issue of major significance for organisations wishing to exploit reuse technology. This paper describes how a reuse project manager can encourage the successful institutionalisation of reuse technology by a process of risk analysis and management. In short, the risk analysis and management process involves four main tasks: 1) the anticipation of potential problems, 2) the development of strategies for averting problems or minimising their effects, and 3) the active application of strategies and 4) the monitoring of problems during the course of technology transfer. However, it should be noted that the scope of risk analysis and management covers not just technical processes, but social and organisational ones too.
Keywords: technology transfer, reuse institutionalisation, reuse management.
Workshop Goals: To exchange ideas on how to and how not to transfer reuse technology.
Working Groups:
1. Component certification tools, frameworks and processes.
2. Reuse of the earliest life-cycle artefacts.
3. Reuse and product lines.
* Success factors: Why was a project which involved reuse technology successful?
* Failure factors: Why was a project which involved reuse technology unsuccessful?
* Warning signs: How can unsuccessful projects be identified? What are the early warning signs?
* Risk management: Can failures in reuse technology be prevented, minimised or rectified before they get worse?
* Risk planning: What can we do on the next reuse technology project to ensure a greater chance of success?
A number of papers have made contributions towards this. Fafchamps (1994) and Joos (1994), for example, both highlight the importance of organisational factors in successful reuse. However, more documented case-studies like these are needed before a more detailed success-failure model can be developed.

Figure 1 Model of the risk analysis and management process
Risk analysis involves three tasks:
* Risk identification: Identifying potential problems before they occur.
* Risk estimation: Quantifying these problems, often in terms of some measure of severity.
* Action planning: Generating alternative choices of actions that would help prevent a problem occurring in the first place or reduce the adverse effects of the problem if it did occur.
Risk management involves making decisions about risks after they have been analysed. It involves choosing the most appropriate choices of actions from the action planning task, building them into the project plan, carrying them out when necessary and monitoring their effect on problems. Maximum benefit from risk analysis and management is gained when it is used to provide managerial foresight, allowing for less reactive, and more pro-active management.

Figure 2: A categorisation of risks relating to the transfer of reuse technology
The grey boxes represent general risk areas, in which more specific risks, represented by the white boxes, can be identified. Often, specific risks have a close affinity with risks in another risk area, indicated by a connecting line. For example, `no technology transfer plans' is closely related to `insufficient (reuse) technology investment'. The categorisation is not exhaustive, but the author believes that it does cover many of the risks an organisation is likely to encounter during the institutionalisation of reuse technology.

Figure 3: Some risk management techniques
Again, the list is not exhaustive; the identification, collection and documentation of a full set of risk management techniques is part of the author's ongoing research. Note that when a risk management technique is applied, its effect on a problem also needs to be monitored - this is an integral part of the risk management process.
Table 1 Summary of related work
[2] Charette, R.N. (1989), Software Engineering Risk Analysis and Management, McGraw-Hill, New York.
[3] Fafchamps, D. (1994), Organisational factors and reuse, IEEE Software, 11(5):31-41.
[4] Frakes, W.B. and Isoda, S. (1994), Success Factors for systematic reuse, IEEE Software, 11(5):15-19, 1994.
[5] Frakes, W. and Fox, C. (1996), Quality Improvement Using A Software Reuse Failure Modes Model, IEEE Transactions on Software Engineering, 22(4):274-279, 1996.
[6] Gilb, T. (1988), Principles of Software Engineering Management, Addison-Wesley, England.
[7] Green, C. and Cisneros, G. (1996), Software Risk Assessment and Mitigation Procedure, Proceedings of the 4th International Workshop on Software Reuse Education and Training, Morgantown, West Virginia, 14-18th August, 1995.
[8] Griss, M.L., Favaro, J. and Walton, P. (1994), Managerial and Organisational Issues - Starting and Running a Software Reuse Program, In Software Reusability, eds. W. Schaefer, R. Prieto-Diaz and M. Matsumoto, Ellis Horwood, Chichester, GB, 1994 pp.51-78, 1994.
[9] Joos, R. (1994), Software reuse at Motorola, IEEE Software, 11(5):42-47, 1994.
[10] Kelly, T.P., Lam, W. and Whittle, B.R. (1996), Diary of a domain analyst: a domain analysis case-study from avionics, In Proceedings of IFIP Working Groups 8.1/13.2 Conference, Domain Knowledge for Interactive System Design, (Eds. Sutcliffe, A.G., Benyon, D. and Assche, F.V.), Geneva, May 8-10, 1996.
[11] Lam, W., Whittle, B.R., McDermid, J. and Wilson, S. (1996), An Integrated Approach to Domain Analysis and Reuse for Engineering Complex Systems, In Proceedings of International IEEE Symposium and Workshop on Engineering of Computer-Based Systems (ECBS `96), Friedrichshafen, Germany, March 11-15, 1996.
[12] Lam, W. and Whittle, B.R. (1996), A Taxonomy of Domain-Specific Reuse Problems and their Resolutions - Version 1.0, Software Engineering Notes
[13] Lam, W. (1997), Achieving Requirements Reuse: a Domain-Specific Approach from Avionics, Journal of Systems and Software. (To appear 4th quarter 1997)
[14] Lim, W.C. (1994), Effects of Reuse on Quality, Productivity, and Economics, IEEE Software, 11(5):23-30, 1994.