Knowledge Sharing Pattern Language

Problem	No knowledge about what work results might already exist and how to find those as potential reusables for projects.
Initial Context	An organization wanting to establish systematic reuse of earlier produced work results.
Roles	Organization represented by a person in a role responsible for developing software engineering, products etc. The right role varies much between organizations. A Project Manager etc. defining the required work results.
Forces	In most of the customer projects the time-to-market is very critical and if it would be possible to use, for example, earlier produced and tested software modules it would speed up the process and to bring more reliability to the final product. Jacobson et al. (1997, p. 6) say that through reusing software "developers can save problem-solving effort all along the development chain. They can minimize redundant work. They can enhance the reliability of their work because each reused component system has already been reviewed and inspected in the course of its original development." Jacobson et al. (1997, pp. 8-6) define reasons why a systematic approach is required for reusing. Here are some of their topics: To reuse, a software engineer etc. must know what exists and could be reused. Traditional software development process alone is not adequate to support systematic reuse. Most of the software engineering organizations focus on one project at a time when reuse requires a broader focus. Reuse takes capital and funding.
Solution	Define the Products and Services etc. that you want to deliver in the future and that the markets most probably are ready to buy from you. Define Approach to Reuse. Check from your past, what similarities there are regarding to work results. Check also the planned products/services, what similarities there could be. What could be the granularity in your reuse. Is it just some code from earlier projects or are there reasonable possibilities for large scale reuse, for example, to product-line approach. Define what could be reused and how. Study Feasibility. Study the feasibility of your reuse approach and planned reusable assets. Do for example, cost-benefit analyses, market surveys. Make decision about the approach. The decision can also be, that the projects are so different from each other and systematic reusing will not pay off. Establish Assets. Start the production of reusable assets according to your decisions. Define also owner(s) for the asset and the maintenance responsibilities. Define Terms of Use. Define terms of use for reusable assets. Notice also possible IPR restrictions and warnings. Publish Assets Publish the existing and planned assets, terms of use and contact persons. Pay attention to easy finding and use. Study Assets. Project Managers etc. need to get familiarized with the assets at such a level that they know what those are and when those could be applicable. Note that this is an overly simplified model and is meant just to start reusing and thinking about the reuse approach.
Resulting Context	Clearly defined approach to reuse. First reusable assets initiated and communicated to the organization. Organization initiated to maintain and to support the use of the assets in projects. See Quickly Made (KSP13) for how to utilize the assets in projects.
Instances	Utilize once to initiate this kind of work and after that for each new asset. Maintenance should then be continuous during the lifetime of the asset. One potential pitfall is reuse because of reuse and not because of business or effectivity reasons. This could lead to a situation where efforts are taken to establish reusable assets that will not have an adequate return on investment.
Process Connection	Software engineering