Presentation is loading. Please wait.

Presentation is loading. Please wait.

Populating Software Repositories Incentives and Domain-Specific Software Jeffrey S. Poulin Journal of Systems and Software, 1995:30, p. 187-199.

Similar presentations


Presentation on theme: "Populating Software Repositories Incentives and Domain-Specific Software Jeffrey S. Poulin Journal of Systems and Software, 1995:30, p. 187-199."— Presentation transcript:

1 Populating Software Repositories Incentives and Domain-Specific Software Jeffrey S. Poulin Journal of Systems and Software, 1995:30, p. 187-199

2 RSL RSL - Reusable Software Library Often the core of an organizational reuse strategy Do not guarantee success Depending on factors like availability of quality and useful software Domain-specific considerations most often determine the usefulness of software and should therefore influence the population of an RSL

3 IBM’s RTSC IBM formed the Reuse Technology Support Centre (RTSC) to promote formal reuse throughout the corporation Replacing informal reuse with a formal, systematic, process of exchanging quality components RTSC worked with designated representative from development sites RTSC sponsored enhancement to an existing library system so that it could support and control worldwide distribution of assets

4 Populating the RSL High priority Incentive programs started to encourage depositing parts and using parts Slow progress Software available for general use stabilized around a set of low-level utilities and functions RTSC launched an incentive program to address this

5 Reuse library considerations 1980’s : reuse programs focused on RSL Quite often ”the reuse program become the library” Resources are spend on library related activities Little to show other than reports that cite a large library Library based reuse has resulted in a modes level of reuse, but it has not yielded a major change in reuse

6 Lack of major change in RSL-based reuse Caused by the way organizations implement the RSL The theory of a creating a central, large repository seems good, but large RSL’s suffer from a number of drawbacks

7 The Reuse Library Progression Phase 1 –very few parts Phase 2 –many parts of low or poor quality Phase 3 –many parts of little or no use

8 RSL overhead Overhead caused by the formality and rigor needed to manage large quantities of data Extensive classification scheme used to describer software components –difficult to classify –users need training Lack of standard method to classify software –may help solving the training problem

9 A corporate reuse library The IBM strategic RSL provides a –central repository for sharing, managing, and reusing software-related products to company cites worldwide A distributed system of shared libraries The library is owned by the ”local” organization and access is grants access to RSL users from other sites Based on a detailed classification scheme to support locating of relevant software Software in the library to be reused is copied to the local machine

10 The quality standard of the RSL The RSL supports incremental stages of quality –”use-at-your-own-risk”,......., ”highly-trusted” Provides supporting information to potential reusers –design documents, integration instructions, test cases and legal information A component receives one of three quality ratings based in part on the completeness and quality of the supporting information

11 Component management of the RSL To assist library managers: Library access control Component user registration Version control Problem reporting Library shadowing Standard enforcement

12 Incentive programs RTSC in 1991 faced a corporate RSL in the first stage of the three phases Feedback indicated a need for a wider selection of quality and useful software RTSC did not sponsor a centralized incentive program but encouraged and offered guidance to sites that wanted to start or have their own

13 The supplier-consumer relationship The supplier –those who write and and contribute quality reusable software and related information for others The reusers –those who extract from the RSL and incorporates the software in their products rather than develop it again (the consumer)

14 Reuse recognization Recognition programs usually allot points based on –supplying software for reuse –reusing software for reuse –on the level of a developers participation in the program Accruing a certain number of point results in the individual receiving prizes or financial awards

15 Recognizing suppliers When determining the proper recognition the program should address: –Participation allocating points to first.time users helps motivating developers and generates –Popularity Provide more points to authors of very popular components encourages contributors to look for high reuse opportunities in their projects –Value A large, robust and generalized component provides more economic benefit to the organization

16 SIRBO Source Instructions Reused By Others Recognizes part suppliers The size (line of codes) for each component the individual contributes by the number of products or organizations actually using it. Helps ensure that suppliers do not receive recognition for unused software Rewards suppliers who identify widely needed functions Rewards contribution of large parts

17 Recognizing users Reuse results from a business analysis showing possible financial savings to the organization Forms the basis for individual recognition Recognizing reusers also helps create a demand for reusable components RSI – Reused Source Instructions The number of code lines in each reused component Credit is received first time component appears in a product

18 Recognizing teams A team incentive can reward a number of group activities: –reward developer teams who achieve a pre-specified goal for the level of reuse receive an unforeseen exceptionally high level of reuse –reward ”parts centre” based on SIRBO –Reward any team with a high number of individuals participating in reuse activities

19 A corporate incentive program Local reuse programs at IBM started to develop and mature, but the overall quantity of parts available for general corporate use seemed to stabilize RTSC sponsored the development of reusable software ”The Parts Stimulation Program” Moving from phase 1 without the pitfalls of phase 2 and 3

20 The Parts Stimulation Program strategy getting development organizations to realize that the projects would be more valuable if they made portions of the software reusable the program funded the dev. organizations to study their projects and the business issues related to reuse the Parts Stimulation Program funded the front-end expenses of conducting the reuse study –performing a domain analysis –developing the specification for the reusable parts –completing a reuse business case detailing who else would benefit and the expected return of investments

21 Incentive Program Results problems identifying candidate projects RTSC decided to fund alternative projects that might benefit the corporation –reuse standard documents –development tools –study of an area of future development

22 What makes software usable Programmers cannot reuse a software unless it is useful Categories for software –Domain independent widest range of usefulness abstract data types, container classes, graphical ui, –Domain specific software contributes to reuse within the problem domain device drivers, special purpose libraries –Application specific software customized code needed to deliver a product tends to deal exclusively with application-unique functionality limited reuse

23 Domain independent software Tends to consist of form 50-200 lines of source code single function or set of variables higher-level abstractions may include numerous interrelated data and functions that act together to perform a specific task high quality rarely contributes more than 15 –20 % to the total product making it easy to reuse domain independent reusable components is and easy, straight-forward and low cost way to get started in reuse

24 Domain specific software Findings in various projects show high level of domain specific reuse The best results will come from a domain that: –has limited scope –programmers understand –has matured to a level of relative stability –requires a lot of custom development based on a set of core functions Creating a domain library can be bottom-up or top-down


Download ppt "Populating Software Repositories Incentives and Domain-Specific Software Jeffrey S. Poulin Journal of Systems and Software, 1995:30, p. 187-199."

Similar presentations


Ads by Google