UNIT-V

Computer-aided software engineering (CASE) is the implementation of computer-facilitated tools and methods
in software development. CASE is used to ensure high-quality and defect-free software. CASE ensures a check-
pointed and disciplined approach and helps designers, developers, testers, managers, and others to see the project
milestones during development.
CASE can also help as a warehouse for documents related to projects, like business plans, requirements, and design
specifications. One of the major advantages of using CASE is the delivery of the final product, which is more likely
to meet real-world requirements as it ensures that customers remain part of the process.
CASE illustrates a wide set of labor-saving tools that are used in software development. It generates a framework
for organizing projects and to be helpful in enhancing productivity. There was more interest in the concept of CASE
tools years ago, but less so today, as the tools have morphed into different functions, often in reaction to software
developer needs. The concept of CASE also received a heavy dose of criticism after its release.
What is CASE Tools?
The essential idea of CASE tools is that in-built programs can help to analyze developing systems in order to
enhance quality and provide better outcomes. Throughout the 1990, CASE tool became part of the software lexicon,
and big companies like IBM were using these kinds of tools to help create software.
Various tools are incorporated in CASE and are called CASE tools, which are used to support different stages and
milestones in a software development life cycle.
Types of CASE Tools:
1. Diagramming Tools: It helps in diagrammatic and graphical representations of the data and system processes.
It represents system elements, control flow and data flow among different software components and system
structures in a pictorial form. For example, Flow Chart Maker tool for making state-of-the-art flowcharts.
2. Computer Display and Report Generators: These help in understanding the data requirements and the
relationships involved.
3. Analysis Tools: It focuses on inconsistent, incorrect specifications involved in the diagram and data flow. It
helps in collecting requirements, automatically check for any irregularity, imprecision in the diagrams, data
redundancies, or erroneous omissions.
For example:
 (i) Accept 360, Accompa, CaseComplete for requirement analysis.
 (ii) Visible Analyst for total analysis.

4. Central Repository: It provides a single point of storage for data diagrams, reports, and documents related to
project management.
5. Documentation Generators: It helps in generating user and technical documentation as per standards. It
creates documents for technical users and end users.
For example, Doxygen, DrExplain, Adobe RoboHelp for documentation.
6. Code Generators: It aids in the auto-generation of code, including definitions, with the help of designs,
documents, and diagrams.
7. Tools for Requirement Management: It makes gathering, evaluating, and managing software needs easier.
8. Tools for Analysis and Design: It offers instruments for modelling system architecture and behaviour, which
helps throughout the analysis and design stages of software development.
9. Tools for Database Management: It facilitates database construction, design, and administration.
10. Tools for Documentation: It makes the process of creating, organizing, and maintaining project documentation
easier.
Advantages of the CASE approach:
 Improved Documentation: Comprehensive documentation creation and maintenance is made easier by CASE
tools. Since automatically generated documentation is usually more accurate and up to date, there are fewer
opportunities for errors and misunderstandings brought on by out-of-current material.
 Reusing Components: Reusable component creation and maintenance are frequently facilitated by CASE tools.
This encourages a development approach that is modular and component-based, enabling teams to shorten
development times and reuse tested solutions.
 Quicker Cycles of Development: Development cycles take less time when certain jobs, such testing and code
generation, are automated. This may result in software solutions being delivered more quickly, meeting
deadlines and keeping up with changing business requirements.
 Improved Results: Code generation, documentation, and testing are just a few of the time-consuming,
repetitive operations that CASE tools perform. Due to this automation, engineers are able to concentrate on
more intricate and imaginative facets of software development, which boosts output.
 Achieving uniformity and standardization: Coding conventions, documentation formats and design patterns
are just a few of the areas of software development where CASE tools enforce uniformity and standards. This
guarantees consistent and maintainable software development.
Disadvantages of the CASE approach:
 Cost: Using a case tool is very costly. Most firms engaged in software development on a small scale do not
invest in CASE tools because they think that the benefit of CASE is justifiable only in the development of large
systems.
 Learning Curve: In most cases, programmers’ productivity may fall in the initial phase of implementation,
because users need time to learn the technology. Many consultants offer training and on-site services that can be
important to accelerate the learning curve and to the development and use of the CASE tools.
 Tool Mix: It is important to build an appropriate selection tool mix to urge cost advantage CASE integration
and data integration across all platforms is extremely important.
Case Environment:
 A schematic representation of a CASE environment is shown below

Figure A CASE Environment

 Although individual CASE tools are useful, the true power of a tool set can be realized only when these
set of tools are integrated into a common framework or environment. CASE tools are characterized by
the stage or stages of software development life cycle on which they focus. Since different tools
covering different stages share common information, it is required that they integrate through some
central repository to have a consistent view of information associated with the software development
artifacts.
 This central repository is usually a data dictionary containing the definition of all composite and
elementary data items. Through the central repository all the CASE tools in a CASE environment share
common information among themselves. Thus a CASE environment facilities the automation of
the step-by-step methodologies for software development.

 Central Repository - CASE tools require a central repository, which can serve as a source of common,
integrated and consistent information. Central repository is a central place of storage where product
 specifications, requirement documents, related reports and diagrams, other useful information regarding
management is stored. Central repository also serves as data dictionary.

CASE TOOLS
 CASE tools are set of software application programs, which are used to automate SDLC activities. CASE
tools are used by software project managers, analysts and engineers to develop software system.
 There are number of CASE tools available to simplify various stages of Software Development Life Cycle
such as Analysis tools, Design tools, Project management tools, Database Management tools, Documentation
tools are to name a few.
 Use of CASE tools accelerates the development of project to produce desired result and helps to uncover
flaws before moving ahead with next stage in software development.
 CASE tools can be broadly divided into the following parts based on their use at a particular SDLC stage:
 Various CASE tools are listed below:
1. Diagram tools
These tools are used to represent system components, data and control flow among various software
components and system structure in a graphical form. For example, Flow Chart Maker tool for creating state-
of-the-art flowcharts.
2. Process Modelling Tools
Process modelling is method to create software process model, which is used to develop the software. Process
modelling tools help the managers to choose a process model or modify it as per the requirement of software
product. For example, EPF Composer

3. Project Management Tools

These tools are used for project planning, cost and effort estimation, project scheduling and resource planning.
Managers have to strictly comply project execution with every mentioned step in software project
management. Project management tools help in storing and sharing project information in real- time
throughout the organization. For example, Creative Pro Office, Trac Project, Basecamp.

4. Documentation Tools
Documentation in a software project starts prior to the software process, goes throughout all phases of SDLC
and after the completion of the project.
n tools generate documents for technical users and end users. Technical users are mostly in-house
professionals of the development team who refer to system manual, reference manual, training manual,
 installation manuals etc. The end user documents describe the functioning and how-to of the system such as
user manual. For example, Doxygen, DrExplain, Adobe RoboHelp for documentation.

5. Analysis Tools
These tools help to gather requirements, automatically check for any inconsistency, inaccuracy in the
diagrams, data redundancies or erroneous omissions. For example, Accept 360, Accompa, Case- Complete for
requirement analysis, Visible Analyst for total analysis.

6. Design Tools
These tools help software designers to design the block structure of the software, which may further be broken
down in smaller modules using refinement techniques. These tools provides detailing of each module and
interconnections among modules. For example, Animated Software Design

7. Configuration Management Tools

An instance of software is released under one version. Configuration Management tools deal with – Version
and revision management
Baseline configuration management Change
control management
CASE tools help in this by automatic tracking, version management and release management. For example,
Fossil, Git, Accu REV.

8. Change Control Tools

These tools are considered as a part of configuration management tools. They deal with changes made to the
software after its baseline is fixed or when the software is first released. CASE tools automate change tracking,
file management, code management and more. It also helps in enforcing change policy of the organization.

9. Programming Tools
These tools consist of programming environments like IDE (Integrated Development Environment), in- built
modules library and simulation tools. These tools provide comprehensive aid in building software product and
include features for simulation and testing. For example, Cscope to search code in C, Eclipse.

10. Prototyping Tools

Software prototype is simulated version of the intended software product. Prototype provides initial look and feel
of the product and simulates few aspect of actual product.
Prototyping CASE tools essentially come with graphical libraries. They can create hardware independent user
interfaces and design. These tools help us to build rapid prototypes based on existing information. In addition,
they provide simulation of software prototype. For example, Serena prototype composer, Mockup Builder.

11. Web Development Tools:

These tools assist in designing web pages with all allied elements like forms, text, script, graphic and so on. Web
tools also provide live preview of what is being developed and how will it look after completion. For example,
Fontello, Adobe Edge Inspect, Foundation 3, Brackets.
 12. Quality Assurance Tools
Quality assurance in a software organization is monitoring the engineering process and methods adopted to
develop the software product in order to ensure conformance of quality as per organization standards. QA tools
consist of configuration and change control tools and software testing tools. For example, SoapTest, AppsWatch,
JMeter.

13. Maintenance Tools

Software maintenance includes modifications in the software product after it is delivered. Automatic logging and
error reporting techniques, automatic error ticket generation and root cause Analysis are few CASE tools, which
help software organization in maintenance phase of SDLC. For example, Bugzilla for defect tracking, HP Quality
Center.
Architecture of a CASE environment

 The architecture of a typical modern CASE environment is shown below. The important components of
a modern CASE environment are user interface, tool set, object management system (OMS), and a
repository. Characteristics of a tool set have been discussed earlier.

Figure: Architecture of a Modern CASE Environment

User Interface

The user interface provides a consistent framework for accessing the different tools thus making it
easier for the users to interact with the different tools and reducing the overhead of learning how the
different tools are used.

Object Management System (OMS) and Repository

Different case tools represent the software product as a set of entities such as specification, design, text
data, project plan, etc. The object management system maps these logical entities
such into the underlying storage management system (repository). The commercial relational
database management systems are geared towards supporting large volumes of information
structured as simple relatively short records. There are a few types of entities but large number of
instances. By contrast, CASE tools create a large number of entity and relation types with perhaps a
few instances of each. Thus the object management system takes care of appropriately mapping into
the underlying storage management system.

Components of CASE Tools

Computer aided software engineering CASE tools tool components can be divided into three main
categories depending on the Software Development Life Cycle phases. Each type plays an essential role
in facilitating specific stages of software development and providing efficiency and consistency.

Central Repository

The central repository is the core component of CASE tools. It acts as a shared database where all project-
related information, including system models, documentation, and design elements, is stored. This
ensures consistency, easy access, and collaboration among developers, testers, and project managers.

Categories of CASE tools:

CASE tools are classified into three main categories based on their role in different phases of the
Software Development Life Cycle (SDLC), CASE tools are classified into the following categories:

1. Upper CASE tools

These tools support the early stages of software development, including planning, requirement analysis,
and system design. They help in diagramming, modeling, and documentation, ensuring a well-structured
blueprint for the software. Examples include ER diagrams, data flow diagrams (DFD), and UML
modeling tools.

2. Lower CASE tools

These tools assist in the later phases of development, such as coding, testing, debugging, and
maintenance. They help automate code generation, error detection, and software deployment. Examples
include compilers, debuggers, and test management tools.

3. Integrated CASE tools

Integrated CASE tools provide end-to-end support throughout the entire SDLC, combining both Upper
and Lower CASE functionalities. They allow seamless design, coding, testing, and documentation within
a single framework, improving software consistency and reducing errors. Examples include IBM Rational
Rose and Enterprise Architect.

1. Upper CASE Tools (U-CASE)

These case tools in software engineering are used during the initial stages of software development,
focusing on planning, analysis, and design. They assist developers in understanding project requirements
and creating high-level system models that act as blueprints for the software.

Functions:

 Requirements Gathering: Collecting and documenting user needs to define the size of the
project.
 System Design: Developing logical structures, workflows, and architectures for the software.
 High-Level Modeling: Creating diagrams such as Use Case, Data Flow, and Entity-Relationship
(ER) models to represent the software concept.

Examples of U-CASE Tools:

Here are some examples of U-Class to help you understand and recognize them better.

 IBM Rational Rose - A powerful tool for creating Unified Modeling Language (UML) diagrams
and supports object-oriented systems and workflow design.
 Sparx Systems Enterprise Architect - A complete platform for designing and visualizing
software systems and helps in development with extensive support for UML.

2. Lower CASE Tools (L-CASE)

These tools come into space during the later stages of development and are geared toward implementing,
testing, and maintaining the software. They help simplify repetitive and detailed tasks, which ensures
code quality and easier software management post-deployment.

Functions:
  Coding Support: It Provides tools and environments that help developers write clean and
efficient code.
 Testing: It enables automated and manual testing to identify bugs and ensure functionality.‍
 Maintenance: It Supports updates and fixes after the software has been deployed.

Examples of L-CASE Tools:

Here are some examples of L-CASE Tools In Software Engineering to help you understand and identify
them effectively.

 Microsoft Visual Studio - An integrated development environment (IDE) that offers features
like code editing, debugging, and performance profiling. It also supports multiple programming
languages and frameworks.
 Git - A version control system that helps developers track code changes, manage project versions
effectively, and facilitate collaboration among team members.
 Selenium- A testing tool specifically for web applications that allows developers to automate
browser interactions to validate application functionality.

3. Integrated CASE Tools (I-CASE)

Integrated computer aided software engineering case tools provide a complete solution that supports all
phases of the SDLC, from planning and design to implementation and maintenance. They combine the
features of upper and lower CASE tools to create a unified environment for seamless workflow
management.

Functions:

 This bridges the gap between early design and actual implementation.
 It facilitates traceability and consistency across the entire development lifecycle.
 This Supports model-to-code generation and vice versa.

Examples of I-CASE Tools:

Here are some examples of I-CASE tools to help you educate yourself with them.
  IBM Rational Software Architect - An end-to-end solution for designing, coding, and
deploying software applications, also offers advanced support for modelling and integrated
workflows.
 Altova UModel - A tool specifically designed for creating and managing UML diagrams, Which
provides a seamless way to connect design models with underlying code.

Software Maintenance
● Software maintenance denotes any changes made to a software product after it has been delivered to
the customer.
● Maintenance is inevitable for almost any kind of product.
● Most products need maintenance due to the wear and tear caused by use.
● Software products need maintenance to correct errors, enhance features, port to new platforms,
etc.

Types of Software Maintenance:

● Software maintenance is becoming an important activity of a large number of organizations.

● Given the rate of hardware obsolescence, the immortality of a software product per se, and the
demand of the user community to see the existing software products run on newer platforms, run in
newer environments, and/or with enhanced features.
● When the hardware platform changes, and a software product performs some low-level functions,
maintenance is necessary.
● Whenever the support environment of a software product changes, the software product requires
rework to cope up with the newer interface.
● Every software product continues to evolve after its development through maintenance efforts
● There are three types of software maintenance, which are described as follows:
○ Corrective: Corrective maintenance of a software product is necessary either to rectify the bugs
observed while the system is in use.
○ Adaptive: A software product might need maintenance when the customers need the product to
run on new platforms, on new operating systems, or when they need the product to interface
with new hardware or software.
○ Perfective: A software product needs maintenance to support the new features that users want it
to support, to change different functionalities of the system according to customer demands, or
to enhance the performance of the system.

Characteristics of Software evolution:

Lehman and Belady have studied the characteristics of evolution of several software products.
They have expressed their observations in the form of laws. These are generalizations and may
not be applicable to specific cases.
Lehman’s first law:
● A software product must change continually or become progressively less useful.
● Every software product continues to evolve after its development through maintenance efforts.
● This law clearly shows that every product irrespective of how well designed must undergo
maintenance.
 ● In fact, when a product does not need any more maintenance, it is a sign that the product is about to
be retired/discarded.
● Good products are maintained and bad products are thrown away.
Lehman’s second law:
● The structure of a program tends to degrade as more and more maintenance is carried out on it.
● When you add a function during maintenance, you build on top of an existing program, often in a
way that the existing program was not intended to support.
● If you do not redesign the system, the additions will be more complex than they should be.
● Due to quick-fix solutions, in addition to degradation of structure, the documentations become
inconsistent and become less helpful as more and more maintenance is carried out.
Lehman’s third law:
● Over a program’s lifetime, its rate of development is approximately constant.
● The rate of development can be quantified in terms of the lines of code written or modified.
● Therefore this law states that the rate at which code is written or modified is
approximately the same during development and maintenance.

Special problems associated with software maintenance:

● Software maintenance work currently is typically much more expensive than what it should be and
takes more time than required.
● The reasons for this situation are the following:
○ Software maintenance work in organizations is mostly carried out using ad hoc techniques.
Still software maintenance is mostly being carried out as fire-fighting operations, rather than
through systematic and planned activities.
○ Software maintenance has a very poor image in industry. During maintenance it is necessary
to thoroughly understand someone else’s work, and then carry out the required modifications
and extensions.
○ Another problem associated with maintenance work is that the majority of software products
needing maintenance are legacy products. Though the word legacy implies “aged” software,
but There is no agreement on what exactly is a legacy system. The typical problems associated
with legacy systems are poor documentation, unstructured (spaghetti code with ugly control
structure), and lack of personnel knowledgeable in the product.

Software Reverse Engineering:

● Software reverse engineering is the process of recovering the design and the requirements
specification of a product from an analysis of its code.
● The purpose of reverse engineering is to facilitate maintenance work by improving the
understandability of a system and to produce the necessary documents for a legacy system.
● Reverse engineering is becoming important, since legacy software products lack proper
documentation, and are highly unstructured.
● Even well-designed products become legacy software as their structure degrades through a series of
maintenance efforts.
● The first stage of reverse engineering usually focuses on carrying out cosmetic changes to the code
to improve its readability, structure, and understandability, without changing any of its functionalities.
Cosmetic changes carried out before reverse engineering

A process model for reverse engineering.

● After the cosmetic changes have been carried out on a legacy software, the process of extracting
the code, design, and the requirements specification can begin.
● In order to extract the design, a full understanding of the code is needed.
● The structure chart (module invocation sequence and data interchange among modules) should also
be extracted.
● The SRS document can be written once the full code has been thoroughly understood and the design
extracted.
Software maintenance process models:

● Before discussing process models for software maintenance, we need to analyze various activities
involved in a typical software maintenance project.
● The activities involved in a software maintenance project are not unique and depend on several
factors such as:
(i) the extent of modification to the product required,
(ii)the resources available to the maintenance team,
(iii) the conditions of the existing product (e.g., how structured it is, how well
documented it is, etc.),
(iv)the expected project risks, etc.
● When the changes needed to a software product are minor and straightforward, the code can be
directly modified and the changes appropriately reflected in all the documents.
● However, more elaborate activities are required when the required changes are not so trivial.
Usually, for complex maintenance projects for legacy systems, the software process can be
represented by a reverse engineering cycle followed by a forward engineering cycle with an
emphasis on as much reuse as possible from the existing code and other documents.
● No single maintenance process model can be developed. Two broad categories of process models
can be proposed.

First Model:

● The first model is preferred for projects involving small reworks where the code is changed directly
and the changes are reflected in the relevant documents later.
● The project starts by gathering the requirements for changes.
● The requirements are next analyzed to formulate the strategies to be adopted for code change.

Maintenance Process Model 1

● The association of at least a few members of the original development team goes a long way in
reducing the cycle time.
● The availability of a working old system to the maintenance engineers at the maintenance site
greatly facilitates the task of the maintenance team as they get a good insight into the working of
the old system and also can compare the working of their modified system with the old system.
● Also, debugging of the reengineered system becomes easier as the program traces of both the
systems can be compared to localize the bugs.

Second Model:

● The second model is preferred for projects where the amount of rework required is significant.
● This approach can be represented by a reverse engineering cycle followed by a forward
engineering cycle. Such an approach is also known as software re-engineering.

Maintenance Process model 2

● The reverse engineering cycle is required for legacy products.

● During the reverse engineering, the old code is analyzed (abstracted) to extract the module
specifications.
● The module specifications are then analyzed to produce the design.
● The design is analyzed (abstracted) to produce the original requirements specification.
● The change requests are then applied to this requirements specification to arrive at the new
requirements specification.
● At this point a forward engineering is carried out to produce the new code.
● At the design, module specification, and coding a substantial reuse is made from the reverse
engineered products.
● An important advantage of this approach is that it produces a more structured design compared to
what the original product had, produces good documentation, and very often results in increased
efficiency.
● This approach is more costly than the first approach. An empirical study indicates that process 1 is
preferable when the amount of rework is no more than 15 per cent.

Empirical estimation of maintenance cost versus percentage of rework.

● Besides the amount of rework, several other factors might affect the decision regarding using
process model 1 over process model 2 as follows:
○ Re-engineering might be preferable for products which exhibit a high failure rate.
○ Re-engineering might also be preferable for legacy products having poor design and code
structure.

Estimation of maintenance cost:

● We had earlier pointed out that maintenance efforts require about 60 per cent of the total life cycle
cost for a typical software product.
● However, maintenance costs vary widely from one application domain to another.
● For embedded systems, the maintenance cost can be as much as 2 to 4 times the development
cost.
● Boehm proposed a formula for estimating maintenance costs as part of his COCOMO cost
estimation model.
● Boehm’s maintenance cost estimation is made in terms of a quantity called the annual change
traffic (ACT).
● Boehm defined ACT as the fraction of a software product’s source instructions which undergo
change during a typical year either through addition or deletion.
 where, KLOCadded is the total kilo lines of source code added during
maintenance. KLOCdeleted is the total KLOC deleted during maintenance.
● Thus, the code that is changed, should be counted in both the code added and code deleted.
● The annual change traffic (ACT) is multiplied with the total development cost to arrive at the
maintenance cost:
Maintenance cost = ACT × Development cost
● Most maintenance cost estimation models, however, give only approximate results because they do
not take into account several factors such as experience level of the engineers, and familiarity of the
engineers with the product, hardware requirements, software complexity, etc.
Software Reuse
● Software products are expensive.
● Therefore, software project managers are always worried about the high cost of software
development and are desperately looking for ways to cut development costs.
● A possible way to reduce development cost is to reuse parts from previously developed software.
● A reuse approach that is of late gaining prominence is component-based development.
● Component-based software development is different from traditional software development in the
sense that software is developed by assembling software from off-the-shelf components.

What can be reused?

● It is important to deliberate about the kinds of the artifacts associated with software
development that can be reused.
● Almost all artifacts associated with software development, including project plan and test plan can
be reused.
● However, the prominent items that can be effectively reused are:
○ Requirements specification
○ Design
○ Code
○ Test cases
○ Knowledge
● Knowledge is the most abstract development artifact that can be reused.
● Out of all the reuse artifacts, reuse of knowledge occurs automatically without any conscious effort
in this direction.
● However, two major difficulties with unplanned reuse of knowledge is that a developer experienced
in one type of product might be included in a team developing a different type of software.
● Also, it is difficult to remember the details of the potentially reusable development
knowledge.
● A planned reuse of knowledge can increase the effectiveness of reuse.
● For this, the reusable knowledge should be systematically extracted and documented.
● But, it is usually very difficult to extract and document reusable knowledge.

Why almost no reuse so far?

● A common scenario in many software development industries is explained further.

● Engineers working in software development organizations often have a feeling that the current
system that they are developing is similar to the last few systems built.
● However, no attention is paid on how not to duplicate what can be reused from previously developed
systems.
● Everything is being built from scratch.
● The current system falls behind schedule and no one has time to figure out how the similarity
between the current system and the systems developed in the past can be exploited.
● Even those organizations which embark on a reuse program, in spite of the above difficulty, face
other problems.
● Creation of components that are reusable in different applications is a difficult problem.
● Even when the reusable components are carefully created and made available for reuse,
programmers prefer to create their own, because the available components are difficult to understand
and adapt to the new applications.
● The following observation is significant:
○ The routines of mathematical libraries are being reused very successfully by almost every
programmer.
○ No one in their mind would think of writing a routine to compute sine or cosine.
○ Let us investigate why reuse of commonly used mathematical functions is so easy.
○ Several interesting aspects emerge.
■ Cosine means the same to all.
■ Everyone has clear ideas about what kind of argument should cosine take, the type of
processing to be carried out and the results returned.
■ Secondly, mathematical libraries have a small interface.
■ For example, cosine requires only one parameter.
■ Also, the data formats of the parameters are standardized.
● These are some fundamental issues which would remain valid for all our subsequent
discussions on reuse.

Basic issues in any reuse program

The following are some of the basic issues that must be clearly understood for starting any
reuse program:
● Component creation: For component creation, the reusable components have to be first
identified. Selection of the right kind of components having potential for reuse is important.
● Component indexing and storing: Indexing requires classification of the reusable
components so that they can be easily searched when we look for a component for reuse.
The components need to be stored in a relational database management system
(RDBMS) or an object-oriented database system (ODBMS) for efficient access when the
number of components becomes large.
● Component searching: The programmers need to search for the right components
matching their requirements in a database of components. To be able to search
components efficiently, the programmers require a proper method to describe the
components that they are looking for.
● Component understanding: The programmers need a precise and sufficiently complete
understanding of what the component does to be able to decide whether they can reuse
the component. To facilitate understanding, the components should be well documented
and should do something simple.
● Component adaptation: Often, the components may need adaptation before they can be
reused, since a selected component may not exactly fit the problem at hand. However,
tinkering with the code is also not a satisfactory solution because this is very likely to be
a source of bugs.
● Repository maintenance: A component repository once created requires continuous
maintenance. New components, as and when created have to be entered into the
repository. The faulty components have to be tracked. Further, when new applications
emerge, the older applications become obsolete. In this case, the obsolete components
might have to be removed from the repository.

Self study:
A reuse approach
and
Reuse at
organizational
level