What’s the Impact?

in category

Alan Hirsch
Product Support Director, Claims Workstation, Policy STAR® and FAB Billing Systems

What do you think is the best way for a software provider to minimize (or hopefully eliminate) the need for application corrections? Specifically, we’re talking about situations in which customers use the application software in ways the software provider did not anticipate, or where functionality has been added or changed. Occasionally what used to work no longer does, so issues surface quickly.

One of our Products Support groups has instituted a new process known as Impact Analysis, which serves to identify the potential impacts of code corrections made within the application, identify test scenarios required for the correction, and to enhance overall testing.  

Here’s how it works.

When a highly critical issue gets reported, our Support Business Analysts (BA) analyze the issue and ensure they can recreate the problem.  Assuming they find a system defect, the Analyst evaluates the issue to determine how a possible code correction might impact the overall application. They look at this from the immediate functional and overall lifecycle perspectives. With this review, they identify areas that technical staff should address as part of the corrective action, including recommended testing. Collectively, this provides direction to Developers about where and how to focus their coding actions and to our QA staff to ensure they know where testing should occur.

Upon assignment to a Developer, this Impact Analysis gets re-reviewed, this time from a technical angle. The coder researches the code, identifies where specific data fields associated with the defect get used, and compares that to the analysis performed by the BA.  They update the Impact Analysis with the results of their research, including additional areas for testing. 

Combined with the initial BA’s analysis, this creates a comprehensive understanding of the issue, how code changes will impact the overall application, and how to test the resulting corrective actions.

Quality Assurance staff tests the changes once the corrections have been made. Using the Impact Analysis as a guide, they test the functional correction itself (i.e., the specific issue reported by the client), and test all the areas identified within the Impact Analysis. This ensures that no unexpected or adverse issues have surfaced because of the correction.  And when the correction is packaged within a fix pack release, we test the entire application again to ensure no additional or unforeseen issues surface.

Any ideas on how to improve the system?

Your rating: None Average: 5 (3 votes)


I think that you covered a

I think that you covered a lot of ground here, but, in my opinion, the first step is making sure all changes are properly QA'd before they get to the client or Production. However, for any QA or code review/testing to occur properly, what is needed is to have testing environments that are exactly like Production or your live/client environment. Unless the QA or test environment is identical to the Production environment, at the platform and application level, then there will be different or unexpected results. So, essentially, the canvass becomes the most important factor. Canvass here being the environment. Once your canvass is verified as exactly the same as the Production or client environment, then one can QA or review/test confidently and get reliable results. So, I am suggesting that environmental review is as important as the code/process review itself.

This is what we do in day to

This is what we do in day to day support and you have described it very well in your post. Many times however we have seen critical issue reported by client involves scope change to the original requirement and it should be addressed by the methodology construction team usually follows. e.g. full life cycle vs agile.