Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

So you're fixing bugs, then you encountered one that could affect other modules of the software product. Your data is not enough to support your claim about the effects of the fix and you were asked to create an impact analysis document.

  1. Is there a defined process on how to do this?
  2. What are the key information needed?
  3. Are there any known formats / templates for this document?
share|improve this question
1  
seems to me some one cooked up fancy term to put you on the spot and get you to fix that bug without any arguments. –  Aditya P Apr 11 '11 at 12:32
4  
This question and its answer make me happy I don't work in such an environment. "Bidirectional Traceability Matrix"? "Decision Analysis and Resolution forms"? Really? How many different ways of not getting work done do you need? –  Rein Henrichs Apr 13 '11 at 17:40
1  
@Rein, it is all work. Work is not only coding. Besides, it's not one person's. In small organizations where Analysis, Design, Coding, Estimation is done by one person, it's like hell indeed but with large teams with specialization it's not a big deal. –  M.Sameer May 14 '11 at 0:42
4  
@AdityaGameProgrammer, @Rein Henrichs: I don't understand your comments. Do you suggest not doing planning and management at all? Of course, it's ok to start coding directly if the project is done by one person, and the change is easy to implement. But what about large-scale projects, and changes which can have a large impact on the different parts of a project? –  MainMa Jun 12 '11 at 18:23

3 Answers 3

The templates I have seen for impact analysis where made inside the company I work for. We use it to evaluate Change Requests and before working on them (and possibly to reject some). It had sections like this:

  • Impact on Requirements: In this section the Analyst writes what needs to be changed in the Use Cases to support the change requested.
  • Impact on Design and Architecture: In this section the architect and the designer mention which parts of the model need to be modified or redone to support the change.
  • Impact on Test: The QC writes the test cases need to be updated.
  • Estimation and Impact on Schedule: The project manager estimates the effort needed and the cost of the change and the impact on project schedule.

To cover all possible impacts you need to walk through the dependencies. If you have Bidirectional Traceability Matrix it will make it easier.

We used the above order because the designer will need to know the the impact from analyst point of view to get better insight of the change and so does the tester need to know the opinion of the analyst and the architect. Similarly, the PM needs all the information to know the cost and schedule.

We used this with CRs but you can use it with bugs the same way. Also, if you need to do this to choose between several fix solutions to solve the bug, you will need to repeat the impact analysis for every possible solution and consolidate all data into one Decision Analysis and Resolution (DAR) form to know which solution is the best. In the DAR form you should add some evaluation factors like future maintainability or other factors that are not included implicitly in the impact analysis. Then give each factor weight and give every solution score in each factor. Finally multiply and sum score*weight and choose the best. Note that the cost may be included in the factors or the PM may have another opinion.

share|improve this answer
    
That sounds… burro-cratic. (That is, it sounds like you're being run by donkeys.) –  Donal Fellows May 13 '11 at 19:47
2  
@Donal Fellows, That was recommended by CMMi consultants and by process improvement consultants from IBM. –  M.Sameer May 14 '11 at 0:38

I believe with any documentation that the agile approach is a good one. Now, there are some misconceptions out there that agile means "no documentation or analysis at all" but that's not the case. The things I've read about agile say, "use what works." I take that to mean the document should be of length and detail commensurate to the task.

Templates can be helpful as a checklist, but I would not require every section to be filled out for small or low-risk changes. For a one line change, maybe you don't need a doc at all. I've never used a template for an impact analysis document, but I regularly deal with business requirements or technical specs. A template can be too restrictive; a good guideline is instead to consider who the audience will be. If it's for managers that are not technical, focus on the business justification for the change. If it's for technical people, provide a little background so a new person on the team won't be lost and give them enough to get going if they have to support the change. Also, if you want something even more friction-less and lightweight, don't use a doc at all, put it on a wiki.

Information to include:

  • Brief description of issue
  • Explain or show example of how defect is causing failure and/or inefficiency
  • Include estimate of complexity
  • Include estimate of cost and time for fix

That's a decent minimum. The other post highlighted some pretty heavy CMMi stuff from IBM; that's great if you have the time and resources for it (and when you're building systems for NASA where human life is at stake, then people better be serious about it) but for small teams you probably don't need to be that heavy. Be careful with the estimate, as always. Managers are prone to assuming an estimate is the actual.

Note that there are dangers in the agile approach. Some developers do think it means, "no docs needed, just start hacking away" (which might be OK in some situations). Also, others will take the latitude given the task and simply write really crappy docs that don't really help (not necessarily OK in most situations). Part of the problem is that writing well takes some effort, skill, and time; most of us are short on at least two of those things ;)

I've always been big on documentation because it proves you at least put in enough thought to qualify as having a plan. But in my old age I've also come to appreciate that too much documentation can itself become a maintenance hassle, and that not enough people care enough to keep documentation updated.

share|improve this answer

Impact Analysis document is indeed required in large scale project specially where the programmers are working geographically in different locations.

The Impact Analysis document should be approved by the lead to make sure that the change won't affect the other component which is working fine in production.

Impact Analysis is required to make sure that the requirement is completely understood and all the components to be changed are identified to avoid re-work

The Impact Analysis is required for accountability from client stakeholders too. Otherwise, when an issue occurs post deployment the developer becomes the scapegoat.

The Impact Analysis is the base for estimation. Without that the estimation does not have any stand. It may be too high or it may be too low. With Impact Analysis if the actual effort exceeds, it is easy to explain as well.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.