Csc 532 Term Paper- Amith Kumar Vangala
Success and Failure factors in Software Reuse.
Term Paper By:
Amith Kumar Vangala.
Abstract:
For years and years now software has been modified and remodified and so on and so, When ever it is used it isn’t prepared from the scratch every time. We always start using the software already available and start building on it to develop our product; this is nothing but software reuse. But not always is software reuse successful, there lays many factors to make a software reuse successful. Systematic reuse is generally recognized as a key technology for improving software productivity and quality [1].
Most of the companies produce software with high commonality between applications and have at least reasonably mature processes [1].Despite this apparent potential for success, one-third of the projects fail. Four main factors affecting the success and failure in Software Reuse stand out to be:
1) Reuse specific processes
2) Modifying non-reuse processes and
3) Considering human factors.
4) Set up a repository
And above all these stands out the common factor of commitment of the top management. We should also consider the case of suitability of Software Reuse for the purpose of the company.And my paper aims at identifying these key factors in the
success and failure of Software Reuse.
INTRODUCTION:
What is Software Reuse?
Software Reuse is building up or updating of software using the existing software components. As of ever our first reaction towards software is simply another term for source code, this is not the case. Software Reuse includes all software products, from requirements to testing and evaluation. Anything that is produced from a software development effort can be reused.
Why Reuse Software?
It is for that a good Software Reuse always increases the productivity, quality, reliability, decreases the cost of project and saves the implementation time. In fact the development of a reuse process improves the quality after every reuse, it cut shorts the development time required for future projects, and which also minimizes the risk of undertaking a new project under the based knowledge. The initial amount of investment required for a software reuse is considerable, and need to be duly studied before the first step can be taken up ,but still the investment pays off for it self after a few reuses.
Types of Reuse:
There are two types of Software Reuse:
Horizontal reuse: It refers to the use of software assets in reuse in a wide variety of applications. They typically include library of components, such as linked lists, graphical user interface functions and string manipulation routines. It also refers to the use of third party applications within a larger system, such as word processor or an e-mail package.
Vertical Reuse: Vertical reuse is significantly untapped at this time, but potentially very useful for the current and future software development efforts. The basic idea is the reuse of system functional areas, or domains that can be used by a family of systems with similar functionality. [3] The study and application of this have given rise to a new software discipline of domain engineering, which is “a comprehensive, iterative, life cycle process that an organization uses to pursue strategic business objectives. It increases the productivity of application engineering projects through the standardization of a product family and an associated production process”. [4] Which brings us to Application Engineering, the domain engineering counterpart: it is a process by which project creates a product to meet customer requirements. Domain engineering focuses on the creation and maintenance of software of reuse repositories which are used by Application Engineering to implement new products.
Why Software Reuse failed over the years:
Software Reuse has been a topic of discussion and debate in the industry for the past 20 years .Many developers have been trying to use the existing software opportunistically to come up with a new one it has been successful in the case of small programs and individual programmers but this is not the case in business units or large companies. Like many other software techniques, Software Reuse has not universally delivered significant improvements in quality and productivity. There has certainly been success, e.g., sophisticated frameworks of reusable components are now available in OO languages running on many platforms [3].According to me some of the non-technical obstacles influencing the Software Reuse are as follows:
Administrative obstacles:
It is always hard for an organization to archive, catalog and retrieve multiple data files across multiple business units within large organizations.
Organizational obstacles:
It requires lot of development, deployment, and supporting to successfully reuse software, but as the number of developers and projects using Software Reuse increases it becomes increasingly hard to structure an organization to provide effective feedback loops between these groups.
Political obstacles:
It is always possible for application developers to have a skeptical eye on the groups that develop reusable middleware software as they think there key architectural decisions may not be valued. There starts the internal rivalry as a matter of job security for each of these two groups.
Psychological obstacles:
It is always a psychological feeling for the application developers to be let down in the organization irrespective of their talent.
As if these non-technical obstacles aren’t daunting enough, reuse efforts often fail due to the lack of technical ability and organizations lack core ability to create and integrate reusable components systematically.
Reuse Costs- The Investment:
The planning of a new Reuse Software has to always keep track of the associated large costs involved with it. Because it adds up for the cost on top of traditional development costs, since designing reusable assets takes more time and care than designing one-time development software. The additional costs involves organizational, technical, and process changes to go along with the cost of tools to support this reuse and the cost of training people to use these new tools and changes.
- Process: The project planning should include extra time for designing, implementation and testing of the required reuse assets as opposed to system-functionality, since the quality is important as this software is not just important for one system, but potentially many future systems within that organization. Time must also be taken into account for researching the repository to be included for reuse and matching them to requirements.
- Necessary Tools: Every organization has to take care of the costs and availability of tools as we need certain specific tools to be available on time. We need certain asset management tools such as repositories for architectures, designs, documentation and coding. Also needed are the tools to aid in the integration of architecture, design and software products to speed up the prototyping, full-scale development, modifications and maintenance. Other tools for the future are domain analysis tools, which are used for the development and maintenance of a domain architecture.
- People-Training: By far the most important part in the reuse process is played by the people .If the people in the organization can’t understand the concepts behind reuse it is hard to proceed forward with the reuse process. Since it’s not a command standard it requires training and subsequent input must be accomplished before expecting the reuse effort to succeed. And the extra effort put in by the people to bring out good results must be supported by the organization through reward and recognitions.
Software Reuse Decision Sequence:
It highlights issues that should be considered when starting a reuse program. But it merely explains the cases but does not claim any scientific validity as a prediction tool for new cases. [1]
1. Reuse potential: It involves identifying the functions likely to be reused and the number of times they could be used in a particular span of time. So that we could evaluate the need for reuse of the software, as reuse potential is much higher when similar software products are produced over time.
2. Reuse Capability: The capability of reuse depends upon the commitment of the
top management to get resources and power to:
- Change non-reuse specific processes.
- Add reuse-specific processes.
- Address human factors.
- Set up a repository.
Here, adding reuse-specific processes implies defining and assigning key reuse roles. And the first prerequisite exists in identifying the processes. Reuse is liable to
fail if any one or two of the above facts are not addressed. We should also check out the size of organizational unit which will always help if it is small and the process maturity should be high enough. Checking up the ownership of processes and requirements always helps as changing of non-reuse specific processes and adding up of reuse-specific processes becomes hard when subcontracting is involved.
3. Reuse Implementation:The implementation deals with addressing the above mentioned points in detail:
- Change non-reuse specific processes: Before reusing the Requirements definition and analysis, high level design and testing all the specific changes have to be taken into account of the reusable assets available.
- Add reuse-specific processes: Domain model analysis may not be good enough to drive the identification of reusable assets because of their larger or smaller size and understanding capacity to include the design and analysis phases. So it is always better for a specific group to develop from scratch and to do the add on process and maintain it before projects need them, or just in time for the first use.
- Address human factors: Some of the techniques such as awareness events, news letters, discussion groups, and training can be used to give good awareness of the reuse principles.
- Set up a repository: A specific tool, add-ons to the configuration management system is a good possible option.[1]
The availability of resources should be carefully examined by the company related to its size before arriving upon any decisions that can be sustained. If provided the approach is sustainable, integrated and adapted to the context any combination of the above choices is acceptable. And finally changes to processes and roles should be affordable, only bigger companies can afford to put up a separate reuse group and the same applies for domain engineering, a process were only a few can afford. Butoverall, successful cases always minimize the changes and use its own configuration management system for the repository.
Conclusion:
The root cause for the failure of a reuse often lists in the hands of top management were they lack the required commitment, or non awareness of the above mentioned factors, often coupled with the blind belief that using the object oriented approach or setting up of a repository by itself is a huge leap towards the success .But still given a reuse potential due to commonality between applications, the success of a reuse depends upon the decision sequence stated above. Further stating Software Reuse requires huge upfront investments, planning, commitment, and effort with substantial, but not immediate benefits.Despite the initial overhead, there lies a huge benefit for a Software Reuse, if appropriate planning and process is taken care.
The major factors affected by Software Reuse include the product quality and reliability can increase, development time decreases along with associated project costs. Project scheduling can be made easy and these benefits in long term can drastically increase the productivity of an organization and decrease the overall risk of project development.
References:
[1]. Success and failure factors in software reuse
Morisio, M.Ezran, M.Tully, C.
Dipt. Auto. E Inf., TorinoUniv.;
this paper appears in:Software Engineering, IEEE Transactions on
Publication Date:Apr 2002
[2].More success and failure factors in software reuse
Menzies, T.Di Stefano, J.S.
Lane Dept. of Computer. Science., West Virginia Univ., Morgantown, WV, USA;
this paper appears in:Software Engineering, IEEE Transactions on
Publication Date:May 2003
[3] .Why Software Reuse has failed and How to Make It Work for You
Douglas C.Schmidt
Department of Electrical and Computer Engineering
University of California, Irvine.
[4].Success factors of systematic reuse
Frakes, W.B.Isoda, S.
Virginia Polytechnic. Inst. & State Univ., Blacksburg, VA;
this paper appears in: Software, IEEE
Publication Date:Sep 1994
[5]. Why do so many reuse programs fail?
Card, D.Comer, E.
Software Productivity Solutions, Indialantic, FL;
this paper appears in: Software, IEEE
Publication Date:Sep 1994