RITIK KUMAR 18SCSE1010646

ASSIGNMENT-04

Boehm’s maintenance model: -

Boehm’s Model performs maintenance process based on the economic models and
principles. It represents the maintenance process in a closed loop cycle, wherein
changes are suggested and approved first and then are executed.

In 1983, Boehm proposed a model for the maintenance process which was based
upon the economic models and principles. Economics model is nothing new thing,
economic decisions are a major building block of many processes and Boehm’s
thesis was that economics model and principles could not only improve
productivity in the maintenance but it also helps to understand the process very
well.
RITIK KUMAR 18SCSE1010646

Boehm maintenance process model represented as a closed-loop cycle as shown in

the below diagram.

He theorizes that it is the platform where management decisions are made that
drive the process. In this stage, a set of required changes is determined by applying
particular strategies and cost -benefits evaluations to a set of proposed changes.
Those approved changes are accompanied by company budgets, which will largely
determine the extent and type of resources expanded.
Boehm had understood that the maintenance manager’s task is one of the balancing
and the pursuit of the objectives of maintenance against the constraint imposed by
the environment in which maintenance work is carried out. That’s why, the
maintenance process should be driven by the maintenance manager’s decisions,
which are typically based on the balancing of objectives against the constraint.
Boehm proposed a formula for calculating the maintenance cost as it is a part of
the COCOMO Model. All the collected data from the various projects, the formula
was formed in terms of effort.
RITIK KUMAR 18SCSE1010646

Legacy Code: -

Legacy code is source code inherited from someone else or inherited from an older
version of the software. It can also be any code that you don’t understand and
that’s difficult to change.

Tips for Working with Legacy Code: -

You can’t improve the inherited code overnight. But you can take gradual steps to
improve it.
Whether you’re just getting started — or you’ve been working on it for a while —
here are eight tips that you should follow.

1. Test the Code

One way to understand the code is to create characterization tests and unit tests.
You can also run a static analyzer over your code to identify potential problems.
This will help you understand what the code actually does. And it will reveal any
potentially problematic areas. Once you understand the code, you can make
changes with greater confidence.
2. Review Documentation

Reviewing documentation of the original requirements will help you understand

where the code came from.
Having that documentation handy will help you improve the code — without
compromising the system. Without this information, you could accidentally make
changes that introduce undesirable behavior.
3. Only Rewrite Code When It’s Necessary

Rewriting an inherited codebase can be tempting. But it’s usually a mistake.

RITIK KUMAR 18SCSE1010646

It takes too much time and too many programmers to rewrite everything. And even
if you do it, rewriting code can introduce new bugs. Or it can remove hidden
functionality.
4. Try Refactoring Legacy Code Instead

It’s better to try refactoring legacy rather than rewrite it. And, it’s best to do it
gradually.
Refactoring is the process of changing the structure of the code — without
changing its functionality.
This cleans the code and makes it easier to understand. It also eliminates potential
errors.
When refactoring legacy code, it’s best to:
• Refactor code that has unit tests — so you know what you have.
• Start with the deepest point of your code — it will be easiest to refactor.
• Test after refactoring — to make sure you didn’t break anything.
• Have a safety net — e.g., Continuous Integration — so you can revert to a
previous build.
5. Make Changes in Different Review Cycles

Don’t make too many changes at once. It’s a bad idea to refactor in the same
review cycle as functional changes.
Plus, this makes it easier for code reviews. Isolated changes are much more
obvious to the reviewer than a sea of changes.
6. Collaborate with Other Developers

You may not know the codebase very well. But some of your fellow developers
probably do. It’s much faster to ask questions from those who know the codebase
best.
So, if it’s possible, collaborate with someone who knows it better than you do. A
second set of eyes on the code may help you understand it better.
RITIK KUMAR 18SCSE1010646

7. Keep New Code Clean

There’s a way to avoid making the code more problematic. And that’s by ensuring
new code is clean. It ought to be written to adhere to best practices.
You can’t control the quality of the inherited code. But you can make sure that the
code you add is clean.
8. Do Further Research

Working with an inherited codebase gets easier with time. A junior developer may
not understand why a codebase hasn’t been refactored (and may be keen to refactor
it). But a senior developer will know when to leave it alone.
Learning more about the codebase will help you improve it.
A good starting point is this article by Michael C. Feathers, which contains some
good examples of how to make changes to the codebase.
Another good source is “Refactoring: Improving the Design of Existing Code” by
Martin Fowler. This book offers many tips for effectively refactoring legacy code.