What Is Software Impact Analysis?
The goal is to implement the change to make its influence on the system in the right way and select the best option available.
Join the DZone community and get the full member experience.Join For Free
Every time a developer makes a change to a code, there is some impact on a system. Ideally, the impact is either fairly small or fully expected. The goal is to implement the change to make its influence on the system in the right way and select the best option available. That is when a software impact analysis is relevant.
Impact analysis is the process of analyzing, predicting, and estimating the potential consequences before carrying out a change in the deployed product, focusing on unexpected side effects of a decision or change in a system and indicating potentially affected areas. It tells us what part of the system can be unintentionally affected by a change and helps deal with potential problems before they arise.
What is the need and importance of impact analysis in the development cycle?
The Importance of Impact Analysis in Software Development
The point of doing software impact analysis is to help a tester or developer focus only on those areas that are influenced by a change or those tasks that are urgent and require instant fixes because of modifications. It is performed when there is a need for an improvement in a system or requirements. Ignoring the impact analysis, that is, probable outcomes and unexpected behaviors of a potential modification in one single module can negatively affect the proper performance of the whole system. It can cause issues in the cost and time estimation, quality, history, and dependency relations between the module that requires the change and other modules in the software.
Advantages of Impact Analysis
The impact analysis, conducted before modifications are applied, minimizes potential loss of resources, future risks, and failures that can impact a user experience with a product. It is necessary for many reasons. But the key benefit is the ability to predict the consequences of future modifications in code and the risks associated with them before implementation. The impact analysis highlights what and how much will be affected in a system after a change.
Among other significant advantages of impact, analysis is the ability of a team to:
- understand modules and the way they are going to change;
- have a clear vision of how the whole system or individual modules are going to react to the introduced changes in terms of performance (including the performance on different platforms and operating systems);
- understand how to update the testing process according to new features or changes (additional tools, new skills);
- stimulate alternative solutions without requiring them to be implemented first;
- review budget and schedule (whether they are going to be affected and how);
- provide accurate information about module modifications and the vulnerability of critical parts in the program;
- improve the efficiency by providing QA specialists with the essential data to prioritize tasks and plan the process thoroughly, decreasing testing time and focusing on serious changes first;
- arrange a synchronized work process with well-balanced cooperation and keep everyone in a team involved, updating the analysis document regularly.
The impact analysis is equally important for both developers and testers. Usually, there is a team of developers involved in one project. Thus, it is difficult to monitor the impact of modifications on more than one or two modules during the whole development process. Developers may not be aware of the workflows handled by each of them in different modules. In this case, there is a high risk of some features remaining untested. In the same way, impact analysis keeps testers continuously informed about every change to the requirements or system, allowing them to not miss a new feature while performing tests and prioritizing test cases according to the recently added changes.
So, how to do impact analysis in software projects?
How to Conduct Impact Analysis
There is an impact analysis meeting conducted by developers, testers, and product managers every time a developer is trying to make a modification in the code, introduce a new feature, or remove an old one. They discuss what areas may be affected by the change, how they may be affected, and whether something in a product is at the risk of breaking because of that. The impact analysis is conducted in almost any phase of the software development process before making something different. It assesses every possible threat that might be introduced to the system. Here is how it works.
There are five steps to perform for an effective analysis:
- Preparation (a team collects data about the proposed change);
- Brainstorming the areas of a system that might be affected by the proposed change;
- Brainstorming affected elements in each area;
- Evaluating (the team identifies positive and negative impacts of the proposed change);
- Dealing with negative consequences (the team decides whether to accept the proposed change or not; the regression testing is performed).
Any change should be thoroughly analyzed and discussed by a team before being added to the system. Those areas of the system that are going to be affected most by the change are analyzed first. At this stage, the team members should be aware of every high-level module in the software. Only then do they move to brainstorm every low-level affected element in each area. An impact analysis document is prepared. It contains a list of potential impacts in each area.
So, what is an impact analysis document and how do you prepare it?
Impact Analysis Documentation
An impact analysis document is an up-to-date written report in the form of a table or matrix that is easy to interpret, and represented with a file supported by Excel or Word. It is created to minimize time spent implementing changes in software and keep track of the maintenance process.
The impact analysis document reduces the number of communication gaps in the team. It contains information about the decisions made during the analysis (features, modules, installations, options, etc.). The file has a brief description of a problem with the root cause, complexity level estimation, time and budget required for fixing, and a list of test cases and functionalities to test.
The influence estimation table consists of columns representing the modules with modifications and rows representing the modules that are going to be affected by the modifications. Whenever there is a feature that influences another feature or a module that influences another module, a developer makes a mark and passes the report to a tester.
Red, yellow, and green colors are used to define high influence, medium influence, and low influence levels, respectively, in the dependency impact analysis table. Or they can be replaced by numbers. High influence, or red level, equals three, medium influence, or yellow level, equals two, and low influence, or green level, equals one.
This technique is relevant for simple projects. In large, complex projects, the ranking is more comprehensive. There are five levels in the checklist – very low, low, medium, high, and very high. The team uses a slightly different approach. Developers do not mark the modules or features that have been adjusted. They indicate the modules or features that have been influenced or potentially can be influenced only.
With the analysis and a clear checklist presented in the table, it is hard to overlook or forget a feature when evaluating the impact of a modification in module A on module B or module C, especially in a large, expensive project. They coordinate a work process, not allowing developers and testers to miss the response after particular areas of the module have been tested and analyzed. Impact analysis is important in regression analysis as well. It simplifies the understanding of the level of regression testing that has to be performed and reduces the time required for testing and the frequency of code checks during a development process.
Published at DZone with permission of Anna Smith. See the original article here.
Opinions expressed by DZone contributors are their own.