Download Talk Critique By SAMPATH K AKKINENI

Paper Critique by SAMPATH AKKINENI
Paper: Software Reuse Strategies and
Component Markets
By: T.Ravichandran & Marcus A.
Rothenberger
Due: 10th September 2003
Summary
The paper, Software Reuse Strategies and Component Markets focuses on different kinds
of software reuse strategies available, advantages and risks associated with those
strategies and problems preventing them from being widely used.
Software development efficiency can be improved by making use of the software artifacts
that are readily available either in-house or in the market. This not only reduces the size
and time of the development and testing effort, but also reduces the error finding and
fixing because the software being reused is already rigorously tested. This paper
discusses three different reuse strategies, white-box reuse, black-box component based
development(CBD) which could be in-house or market based.
White-box reuse refers to strategy where development has access to the available code
which can be modified to match new project’s requirements. The problems with this
strategy are identifying the reuse components and the resources ( developers ) that have
the knowledge of the reuse components. And also, code modification requires high
degree of familiarity with implementation details.
In in-house black-box CBD strategy, the software components that can be reused are
identified within the organization. The reuse components are implemented on “as is”
basis. No code modifications are permitted to the reuse components. In the market
procurement black-box reuse strategy, reuse components are identified and procured
from the market. Black-box reuse involves providing interfaces that can be used by
application developers to integrate the reuse components with the application code. One
problem with this strategy is the use of reuse components on an “as is” basis. This limits
the application developers’ ability to customize the components to their project
requirements. If there are not many suppliers available for reusable components, then
component acquisition costs could be quite high.
The paper defines two terms for estimating the acquisition/customization cost. Domain
distance is the effort required to modify an existing component to exactly meet the
requirements. Contextual distance is the effort required to convert an existing component
to the desired implementation environment. Reuse strategy decisions can be made by
measuring these distances and using these distances in estimating different kind of cost
involved.
Comments
This study tried to address the problems faced by organizations in the selection of reuse
strategy. It clearly defines the strategies available and discusses them in detail with
respect to their advantage and risks. The study also showed how costs can be estimated in
each of the strategies before selecting any one of them.
Software reuse definitely helps to reduce the timeframe involved in the development
process, but sometimes it can create problems like troubleshooting. Developers who
implemented the reuse components may not know the inner details of those components
which make it tough to troubleshoot and fix problems in the testing phase.
What kinds of tools are available to implement software reuse process? Can design
tools like Rational Rose reduce some of the design complexities of the software reuse
implementation? Also, availability of any other design tools affects the reuse strategy
selection decision?
Was there any survey conducted to understand the preferences of the people
working in the industry? Were there any organizations that implemented any of
these reuse strategies? If so, what is their success rate?
What is the affect of quality and standards in the selection of a reuse strategy? Some
organizations may have touch quality standards, what happens when the reuse
components doesn’t meet those quality standards? Are there any standards established for
the vendors that produce reuse components?
Is there any process to identify the reusable components either in the in-house
repository or in the market place?
Does the choice of programming language affect the software reuse strategy?
Sometimes choice of programming language may affect software reuse strategy decision.
Software reuse may be easy to implement in certain programming languages ( like object
oriented ). But is the software reuse possible in non-object oriented environment?
What is the impact of the reuse strategy on testing? Do the reused components need to
be tested again?