How is determined an impact of a requirement change on the existing code?

Question

How companies working on large projects evaluate an impact of a single modification on an existing code?

---

Since my question is probably not very clear, here's an example:

Let's take a sample business application which deals with tasks. In the database, each task has a state, 0 being "Pending", ... 5 - "Finished".

A new requirement adds a new state, between 2nd and 3rd one.

It means that:

• A constraint on the values 1 - 5 in the database must be changed,
• Business layer and code contracts must be changed to add a new state,
• Data access layer must be changed to take in account that, for example the state StateReady is now 6 instead of 5, etc.
• The application must implement a new state visually, add new controls for it, new localized strings for tool-tips, etc.

When an application is written recently by one developer, it's more or less easy to predict every change to do. On the other hand, when an application was written for years by many people, no single person can anticipate every change immediately, without any investigation.

So since this situation (such changes in requirements) is very frequent, I imagine there are already some clever techniques and ways to predict the impact. Is there any? Do you know any books which deal about this subject?

---

Note: my question is not related to How do you deal with changing requirements? question. In fact, I'm not interested in evaluating the cost of a change, but rather the way to predict the parts of an application which will be concerned by the change. What will be those changes and how difficult they are really doesn't matter in my question.

Answer 1

I don't think you can ever tell just how much a change will affect code.

That being said though, if one know the framework of the application well, he can generally predict about how long it will take and what needs to be done. It comes from experience, not metrics. I'm sure you've thought of cases that a user thought a change would be simple ('He's just adding one menu option! how hard can that be?!) but in reality was quite complex.

I have two possible solutions.

The first I think is critical: Documentation. Being able to read about the general layout of an application will help someone greatly in determining where changes will need to be made. Lower level docs about specific areas will help in actually making the changes.

The second would be to have a senior developer look at each request as he probably can tell quickly what it will entail. He then can give an estimate of how long it will take and what needs to happen before it is assigned to a person or team for development. This may not always be practical, so documentation is still extremely critical.

Answer 2

How much of an impact it will have is not a problem that can be solved mechanically. You'll have to evaluate how your current system behaves, what kind of work is required to implement it, and what risks go along with it, and it will require human judgement.

Answer 3

Make a very low level change to implement the feature, and then fix all the errors that it causes. Start with the compile errors, then move on to testing and fix those errors, and then release to customer and let them tell you about all the other problems.

Haha, only serious.

Answer 4

The way this MUST be done is with a GOOD source control system that forces developers to comment and label, and allows you to easily step back in time through various iterations of a deliverable.