[Title of paper and title of section]
Generally, it is called software reuse that software is used for more than one project. Software is
not only code itself but it includes also requirements, designs, test plans, test suits, and
documentation produced through [within/in/during the] software lifecycle.
Software reuse has many different meanings in [the] software engineering community. Each
person has [a] different opinion according to one’s role. For example, high-level software
manager considers software reuse as technique for overall productivity and increasing quality of
product of his or her own organization. On the other hand, [a] developer, who uses reusable
code written by others, takes it as an efficient usage of [a] collection of usable assets. [a] Project
manage[r] of this development may regard thinks reuse is [as] useful if the reuse software is
easily obtained and has high quality. If this manager has seen not well- [poorly] tested code that
cause[s] many trouble due to shortage of modularity and adherence from standard, he may has
[have a] different view. On the other hand, developers, who make reusable code for their project
and others, think [a] limit[ed] resource is drained.
Reuse is defined as usage of existing things for desired ones [purposes]. Reuse is not obtainable
by special language paradigms, libraries, operating systems, or techniques. Frequently, this is a
problem only on what [we reuse] and how we reuse [it] and what is [the] trade-off.
Reusability is believed as a key for software development productivity and quality improvement.
By reusing high-quality software component[s], software developer can simplify product and
makes it more credible.
Reusable component
[A] Reusable component can be program source code but it brings more benefits to us when it is
considered at more wide[r] and high[er] level. Software specification, design, test script, project
plan, documentation, object framework, subroutine etc. are variable types of reusable
component[s]. Generally, some software project deliverables can be produced in reusable
component[s].
The upper part in [a] reusable component type list should be reusable skeletons to help
production of all kinds of project documentation, report[s], and plan[s]. Because these skeletons
are provided as [in] word processing template form, they are easily and rapidly created and
usable in [a] reuse catalog. The gain saves time and ensures [it] following[s] the standard of
[the] company and make [ensures/guarantees] keeping consistency through [the] process of
software production and [within/across the] system. This brings [a] better quality system that is
easily understood, maintained and usable. Finally, this type [of] reusable component is not easy
[likely] to interrupt creative requirement of system developers because documentation is not
thing they are likely to do. Many these skeletons may exist as part of organization and should be
usable in all software develop group[s].
Two different software components, which should be in [the] upper part in [of the] valuable
reusable component list, are design and test component[s].
Design components are important because they are [a] good position to maximize leverage due
to reuse in design time. Design components are in higher-level abstraction than code and make
them less implement[ation]-specific, and thus they are more portable and reusable. Also,
because Design is [more] expensive work than development, reusable design provides more
saving[s] than reuse [of] code. Additionally, reuse at design level leads [to] reuse at code level.
If there is some traceability between design and [the] code that implement[s] it, traceability can
be automatically handled [case] by case. We can solve problems existing through different
points among components written by different languages and [that are] incompatibility[e?] by
focusing in design component[s].
Test components such as test data, test scripts, test cases [and] test plans are also considered to
be important. For some cases in which we cannot reuse code due to the difference of language
and tool, test components are reusable. Reuse of test component[s] makes sure that system is
tested more sufficiently and this comes to be [a] more reliable and easily maintainable system.
Reusing test component[s] makes it possible to save many [a lot of] project time and resource
because testing is very expensive work like design [is].
Benefits of reuse.
Well-using chance of [Proper] reuse makes it possible to increase [improve on] amount of
software productivity, quality, and cost. Profits that reuse bring; [Benefits of code reuse:]
1. increment [Increase] of software productivity
2. decrease in software development time
3. possibility of software development with few[er] people
4. possibility of movement of people, tool[s], method from project to project.
5. decrease of software cost
6. production of software with better quality
7. interoperability of software system[s]
8. supply[increase] of competitive advantage
Disadvantage of reuse with possibility
There are several dilemmas in reusability. One is “general property of applicability on pay-off”.
Many description[s]/techniques are general and thus can be used in broad range of domain[s]. In
[the] producer’s view of reusable artifacts, this brings less pay-off compared to [a] focused
system in a few application domain[s] on each reused module
However, it brings many pay-off[s] for the case that small, flexible and high-quality routine[s] is
[are] used for several times.
The other is that component size on [the] potential reuse[d code] is based on average size of
component[s]. As component[s] become to be big and complex, pay-off on reuse is bigger than
just [in] linear thing[components]. As component[s] become to be more specific, the cost for
reuse for the narrow application could increase if modification is necessary.
There are various problems related to reuse of [a] library. Four kinds of things to be addressed
are; [:]
Finding appropriate component[s]
It is difficult to find perfectly matched component[s] in many cases. In some cases, just a little
modification of similar component helps to reduce cost and remove defects.
Understanding component[s]
It is necessary to understand process between whether component[s need] to be modified or not.
Proper model[s] should exist for execution of the component[s] in reuse system[s] without
respect to what kind of technique is used for [the] application.
Modifying component[s].  여기까지
It is not realistic that we achieve a significant amount of reuse without modifying some portion
of [the reused] component. How much we modify must be decided by models of cost and
quality.
Compositing component[s]
[The] Composition process brings the most difficult requirements. There must be the [an] ability
to explain the structure as independent entities, which have well defined computational
characters, and the ability to composite such composite structures more.
McClure pointed out that the reason of limited success across projects is the up-front planning
for reusability. A systematic cost of programming is especially important. Efforts are required
for understanding the target component in [the] reuse library and for deciding related useful
components.
Several factors that inhibit [the] advance of reusability
1. Representation technology
There are not [no] representative technologies that accelerate reusability across wide ranges of
domain[s].
2. Lack of [a] clear and obvious direction
There are not [no] special strategies [that can be used] as approach ways to justify reuse. It is
difficult to define a clear approach before the best way is assured[I can’t understand the phrase
‘best way is assured’]. However, it is true that reuse is an interdepartmental problem and there
should be lots of work before we have significant pay off.
3. The “not invented here” (NIH) syndrome
It is a relatively easy problem to solve for programmers. This issue relies on the managers’
criteria for rewards of reuse. When managers make proper customs[?], developers learn fast that
reuse doesn’t limit their creativity. They have now the free[dom] to solve more difficult
problems. Once it is recognized, resistance to reuse will be disappeared.
4. High initial costs
If there is no reusable library, it limits reuse technology at the same time. To have a reusable
library, a significant amount of initial cost is required.
5. Legal and contractual issues
This issue is divided into following categories:
Liability in case of failure of a reused component
Ownership of used components
Maintenance costing
Security of potentially reusable components
첫번째 케이스의 경우는 생명과 관련된 시스템에서 서브시스템을 리유즈 할 경우
아주 명백해진다. 심장을 모니터링 하는 시스템이 있다고 하자. --examples?
6. Lack of methodology
Most of software methodologies do not include reuse. Such methodologies do not define where,
when, how to reuse as a part of development process.
7. Lack of roles and responsibilities
Roles and responsibilities for the project team, users, and management department have not
been well understood.
8. Tools
The tools that support reuse have not been understood.
Techniques
3.1 add reuse techniques to software methods
Software methods describe which step, how many times [and] which orders the methods arise
during a software process. It describes how to do the techniques. Methods are the frameworks to
be executed, while techniques are specific ways to carry out the tasks. Techniques are ancillary
procedures to implement the methods.
Software methods are supported by many well[-]known techniques. For example, information
engineering is supported by entity relation modeling and data flow diagramming technique[s].
Object oriented methods also, are supported by many techniques such as the object modeling
and the use case technique.
Similarly, reuse must be supported by techniques that provide details of how to execute reuse[it].
Since reuse is a different software process paradigm, these techniques are unique for reuse. The
major part for expanding software methods to include reuse is to add reuse as the final level of
detail needed to explain [an explanation of] how to execute reuse.
There are three categories for basic reuse techniques.
1. Reuse Management Techniques: help management for executing reuse.
2. Consumer Reuse Techniques: support to use [for] reusable components that produce software
systems and project deliverables
3. Producer Reuse Techniques: support to identify, create, and prepare [for identification,
creation and preparation of] new reusable components
Management techniques
Among all elements for successive reuse, good management is most important. Reuse requires
more discipline and planning than any other software paradigm from following reasons:
- Reuse is a long-term strategy. It takes 3-5 years to emerge real benefits.
- Reuse often requires planning, coordination, and cooperation which [that] extend [the]
software project boundary.
- Reuse requires different organizational structures that separate roles and responsibilities of
reuse producers from reuse consumers.
Two types of reuse management techniques which [that] address how to manage reuse:
1. Corporate-level reuse management techniques
2. Project-Level Reuse Management Techniques
Corporate-Level Reuse Management Techniques
If the reuse techniques of cooperation[s] adopt reuse as [at the] department, division level, or
enterprise-wide, it cannot rely on an informal approach for reuse. It should be managed by a
formal Reuse Program prepared and implemented carefully. The elements of this Reuse
Program include following:
- Acquire management support and commitment
- Acquire reuse funding and reuse function
- Create reuse catalogue and reuse library that have classification schemes
- Define reuse infrastructure such as tools, process, and metrics for supporting reuse
- Promote [Promotions] through incentive[s] and award program[s]
Corporate-Level Reuse Management Techniques are used to formalize executing reuse across
development groups in corporation. These describe how to define and implement the elements
of reuse program that expand across projects, departments, and division boundaries. These are
the means to achieve reuse. There are four company level reuse management techniques that
provide the procedures to define and implement formal reuse programs:
1. Reuse Readiness Assessment
2. Corporation Reuse Plan Creation
3. Organizing for Reuse
4. Promoting Reuse
1. Reuse Readiness Assessment
The first step for implementing a successive reuse program is to understand how well prepared
the organization [is] for reuse is. This technique describes how to assess the readiness of the
organization, how to define the steps for improving the ability of organization which applies
reuse, how to define the risk of failure, how to minimize it, and reuse training program and
incentives.
2. Corporation Reuse Plan Creation
This technique describes how to create a reuse program implementation plan. All elements of
reuse programs, the order to implement them, time lines and resource to be needed are discussed.
3. Organizing for reuse
Reuse is [has] not happened in [a] corporation, if there is not a [no] formal supporting program.
This technique explains how to build deductive functions that provide the starting and on-going
support. It describes the relation between groups, repository administration, and all level of
managements.
4. Promoting Reuse
The cultural barrier for use is often bigger than the technical one. In order to accept from both
management and software steps, it is needed [necessary] that we actively promote the concepts
of reuse. This technique explains various ways to promote reuse concepts in a company.
Project-Level Reuse Management Techniques
If a company has a [the] intention [to implement] for reuse, it must make building a software
from reusable components a standard development practice. The responsibility to adopt reuse
can be stopped[?] by a software project team. The key to [effective] practice [of] reuse in a
project is not to focus on the technical part of reuse but to focus on the good planning and
management for the project. A project manager has to make all team members feel that reuse is
an important part for his/her works, and practicing reuse will be considered at the personal
performance review.
Project Level Reuse Management Techniques is [are] used to formalize executing reuse in a
project. It supports inner-project reuse.
Managing a reuse-driven project is different in several ways with managing traditional software
projects. First of all, the project manager has to expand his/her view points to recognize the
chances [opportunities] to share and reuse components with concurrent or future projects. It
needs more communication with other project managers and more emphasis on consistency and
coherence to the company standard.
Secondly, reuse affects project schedule and resources. For example, if the team did not
experience reuse before, the project schedule must include the time for reuse training. Also the
time to make reusable components must be included in the schedule, since it takes more time
and [higher] cost to make reusable components.
Third, project evaluation criteria and data collection must be affected from reuse. Reuse must be
included in the basis of productivity and quality so that the cost and benefits can be evaluated
and analyzed from practicing reuse.
Finally, the project activities must be expanded to add reuse activities. For example, project
reviews and examinations have to include reuse consideration and checks. A reuse specialist has
to participate in project review not to miss the chances for reuse. To guide managers in
managing a reuse-driven software development, there are four Project-Level Reuse
Management Techniques:
1. Project Reuse Plan
2. Reuse Cost/Benefit Analysis
3. Project Reuse Evauation
4. Reuse Cose/Benefit Tracking
1. Project Reuse Plan
This technique explains how to build a plan for executing reuse in a software project. The
planning process includes deciding which predefined reusable components are used to construct
this project’s deliverables, deciding the project’s reuse level from which what kind of new
reusable components [are] to be made from this project, deciding how to justify reuse in this
project, and deciding other considerations such as training needed to execute reuse successfully.
2. Reuse Cost/Benefit Analysis
This technique explains how to access costs and benefits to practice reuse in a software system.
To analyze reuse costs and benefits helps to justify reuse as a part of planning reuse for a
project[project planning]. This is used to examine an expected quantitative benefits such as cost
saving and to examine quality benefits such as lower error rate in building a software system
from using reusable components.
3. Project Reuse Evaluation
This technique describes how to evaluate practicing reuse in a software project. Reuse review
process is used to decide whether or not a project meets its reuse goal. It can be used to capture
reuse lessons learnt from the project to let other project teams to know and to improve the reuse
program.
4. Reuse Cost/Benefit Tracking
This technique examines the actual reuse in a project from two points of views. They are the
consumer reuse and the producer reuse. This technique identifies components used to create the
project and system deliverables and new reusable components made from the project. It
examines the actual effects of reuse to the project in the aspects of resources, schedule, costs
and benefits.
Consumer Reuse Techniques
Consumer reuse is the part of how to make a new system from existing components. The next
consumer reuse techniques explain how to implement consumer reuse mini life cycle steps.
1. Selecting Reuse Components
This technique describes the ways to identify and select reusable components which [that] will
be reused in a software application project. This technique makes assure that an application
builder will find all types of reusable components from all similar sources. Reusable
components can be used to develop various project deliverables. These deliverables include
system components such as design and code level components or document deliverables such as
test plans and user documentations.
2. Application Package Selection
This technique explains how to examine and select a proper application as an alternative to
build[ing] a new application. This technique also describes how to decide an application
package will provide cost-effective, high quality and timely solution to meet the company
requirements for a new or replacement system. This technique considers time and costs to buy,
modify, and manage a package and the reputation of the company which [that] sells the package
in the market.
3. Redundancy Checking
This technique describes how to check redundancy. Redundancy arises when several software
components provide [the] same function or same purpose. Redundancy can be arise at all
level[s] of system abstractions such as codes, designs and requirements. Once redundancy is
known, a generalized reusable component can be created to replace the redundant components.
Redundancy checking can be executed at various stages of application development to ensure
that the simplest system was made and the chance to reuse was known.
4. Identify Candidate Reusable Components
This technique explains the ways to identify candidate components that has potential for future
reuse. This technique identifies and prepares new reusable components from components that
are made during the application project. The components that have high potential for reuse have
to made with [while] considering future reuse. The components for reuse must be more
generalized, standardized, and documented than components of single use counter parts.
Producer Reuse Techniques
Producer reuse techniques are the details about how to make and prepare a component reusable
[component]. The following reuse techniques support producer reuse.
1. Creating a Reusable Component
Reuse is a property which [that] must be designed and built in a component. Reusable
components are different with the component designed for single use, because the reusable
components are used other applications and must meet a several set of requirements. This
technique explains how to make a component to reuse easily, safely and effectively. This
technique includes the ways to generalize, standardize, document, certify and classify different
types of reusable components, which are source code such as object class or framework, system
architecture design such as project plans and test plans and project documentations.
2. Building a Reuse Library
An important task to implement a successful reuse program is to create a reuse library. This
technique describes what a reuse library is, which types of reusable component will be saved in
the library, how to organize the library physically and logically, how to define classifying
schemes that classify usable components, how to set up reuse catalogue, and tools that are
needed to build the reuse library.
3. Configuration Management
Configuration is a process that control[s] software components’ changes. This technique
explains what a configuration management is, why configuration management is important,
what are the basic functions for configuration management, and the characteristics which must
be considered in examining and selecting configuration tools to support reuse.
4. Domain Analysis
Domain analysis is a technique which [that] is used to identify common components in a
domain and to make them available when using an application in the domain. Examples of
domains can be special business functions such as marketing and product line[s]. This technique
describe what domain analysis is, the steps in domain analysis, what are the deliverables in a
domain analysis process, what major types of domain analysis processes are used in these days,
and what kinds of tools to support domain analysis are.
Economics