Impact Analysis: Why Not Use the Best?
When you need to make a code change, you need to know how the code relates to other things. Your change in one module could affect others. A utility capable of analyzing code change impacts like this is vital to producing accurate changes quickly. You need it to be always available and natural, not an option you have to invoke and wait for.
One Click Limit
What I’ve learned about user interfaces is that people will do one click. You can’t count on them to go to another panel, do two clicks or, certainly not, access required functionality in another product. You get past one click and you’ve lost most of your users because they expect simplicity.
Simpler Impact Analysis With ISPW
With Compuware ISPW integrated into Topaz, the Impact Analysis feature is already there, instantly and graphically (Figure 1). All source and JCL can be analyzed first at install time, and, thereafter, reanalysis is done automatically at each promote. If you need more in-depth information you can bring up Topaz for Program Analysis to see the flow within your program and external program calls and data access—in your same view. It’s really that simple.
Example of Hidden Impact Analysis
For an example of a more difficult way to handle this, CA Endevor uses the ACMQ facility to manage impact analysis. You have to remember it exists, remember the proper command on the proper panel and then initiate it. But, if you’ve made any changes, you will need to remember that the data needs to be updated. And how do you update the data? Well, you need to exit the ACMQ facility and then re-enter it. This is yet another cyclical, repetitive process CA Endevor requires users to commit to.
These roadblocks—knowing it exists, remembering the command, waiting for it to come up, switching from panel to panel—means very few will benefit from impact analysis. It will only be used when it is really, really complex and they feel they really need the analysis. So, for cases where they just need to see which programs use a copybook, they may turn to a scan, which can take five minutes—what are they doing while they wait? Or they may assume they know the impact so won’t take the time to check. This is how errors are made, errors you detect in testing if you are lucky—and in production if you aren’t.
Making Source Code Management Agile
As I’ve explained in previous posts of my “Why Not Use the Best?” blog series, ISPW’s integration of automatic, graphical Impact Analysis is another example of how source code management can be made much more simple and Agile by automating certain aspects of the tool, rather than leaving them for users to accomplish manually. This means faster, more accurate changes—vital when you are doing two-week Agile sprints.
Read my other posts in the “Why Not Use the Best?” blog series
- Data Access: Why Not Use the Best?
- Balancing Complexity and Flexibility: Why Not Use the Best?
- Exit Strategies: Why Not Use the Best?
- Compile Skeletons: Why Not Use the Best?
- Waterfall to Agile SCM Conversion: Why Not Use the Best?
Latest posts by Mark Schettenhelm (see all)
- What Makes ISPF So Scary? Five Reasons to Banish the ‘Green Screen’ - October 31, 2017
- 10 Cross-platform and Mainframe DevOps Tools You Need Today - August 7, 2017
- Waterfall to Agile SCM Conversion: Why Not Use the Best? - May 11, 2017