Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 3

Name : Samiullah

Reg No : F19BCSE7A037
ASSIGNMENT 1 SRE

Question 1
Bug fixes: Maintaining software involves fixing bugs and errors in the existing code. In contrast,
developing new software involves creating code from scratch.

Upgrades: Maintaining software requires keeping the software up to date and compatible with new
versions of the underlying operating system or other software components. This may require making
changes to the existing codebase, whereas developing new software does not have this requirement.

Legacy code: Maintaining software often involves working with older code that may be difficult to
understand or modify. In contrast, developing new software involves starting with a clean slate and
building code from scratch.

Code complexity: Maintaining software often involves dealing with complex code that has evolved over
time. In contrast, developing new software allows for simpler and cleaner code designs.

Question 2
Corrective maintenance is concerned with fixing errors or bugs in the software, which typically involves
changing the functional specification to ensure that the software works correctly. Therefore, making a
change to the system that leaves its functional specification unchanged would not fall under Corrective
maintenance.

On the other hand, Adaptive maintenance deals with modifying the software to adapt to changes in the
environment, such as changes in hardware or software platforms. Perfective maintenance deals with
enhancing or improving the software's functionality or performance, while Preventive maintenance
involves making changes to prevent future problems or improve the software's maintainability.

Question 3

Source of software: COTS-based software development relies on using pre-existing, third-party software
components or applications that are purchased or licensed, while traditional in-house software
development involves creating software from scratch.
Development effort: COTS-based software development often requires less development effort than
traditional in-house software development, as pre-existing software components can be used to provide
much of the system's functionality. However, the effort required to integrate and customize these
components may still be significant.

Development time: COTS-based software development can often be faster than traditional in-house
software development, as pre-existing software components can be used to speed up development.
However, integrating and customizing these components may still take time.

Control: Traditional in-house software development offers greater control over the development
process and the resulting software, as the development team has complete control over the design,
source code, and functionality of the software. In contrast, COTS-based software development relies on
pre-existing components that may not be fully customizable or controllable.

Cost: COTS-based software development can often be less expensive than traditional in-house software
development, as the costs of developing and maintaining pre-existing components can be spread across
multiple users or customers. However, licensing fees or customization costs may still apply.

Question 4

The reliance on one or more third-party software vendors in COTS-based development can present
several challenges for the evolution of such systems. Some of the evolution challenges that can be
directly attributed to reliance on the vendor are:

Vendor support: The vendor may stop supporting or updating the software components used in the
system, leaving the system vulnerable to new security threats or incompatibilities with other
components.

Vendor compatibility: The vendor may release new versions of their software components that are not
fully compatible with the existing version used in the system. This can lead to issues with integration and
may require significant effort to upgrade.

Vendor customization: The vendor may not provide customization options for their software
components that are required by the system. This can lead to additional development effort and may
limit the system's ability to evolve and adapt.

Vendor licensing: The vendor may change their licensing terms, which may increase costs or restrict the
system's use in certain ways. This can create challenges for the system's evolution, especially if the
system relies heavily on the vendor's components.

Vendor acquisition: The vendor may be acquired by another company, which may result in changes to
the software components, support, or licensing. This can create uncertainty and may require the system
to adapt to new requirements or compatibility issues.

Question 5
When rewriting or reengineering a piece of code, maintainers can face several problems that can cause
significant challenges in the process. Here are some of the common problems that maintainers face
when rewriting or reengineering a piece of code, along with their causes:

Understanding the original code: Rewriting or reengineering a piece of code requires a deep
understanding of the original code, including its architecture, design, and functionality. However, the
original code may be poorly documented, written in a different programming language, or implemented
using outdated technologies, making it difficult for maintainers to understand.

Maintaining functionality: Rewriting or reengineering a piece of code while maintaining its functionality
can be challenging, especially if the original code was poorly designed or implemented. Maintainers may
need to reverse-engineer the original code to understand its intended behavior and ensure that the
rewritten code meets the same requirements.

Integration with other systems: Rewriting or reengineering a piece of code may require integrating it
with other systems, which can be challenging if the original code relied on specific technologies or
interfaces. Maintainers may need to identify and address compatibility issues with other systems.

You might also like