Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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.
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:
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.
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:
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.
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.
Here you have a normed template for an impact analysis report. It's customized for a specific branch of industry, but nevertheless is has useful sections that can serve as inspiration to write your own document.
The link: http://www.itu.int/en/itu-d/projects/documents/templateimpactanalysis.pdf
Cheers
