SAN MATEO (06/05/2000) - Mention the words "software quality" to any business or technology leader (or even any business or technology end-user) and you'll undoubtedly start a lively conversation. The majority of people will likely feel that software quality has declined during the last 10 years or so.
The principal cause of declining software quality can be attributed to one thing: time, or, more accurately, the lack thereof. As we have moved from centralized computing to a compute-anywhere paradigm, the application development cycle has become increasingly compressed.
Certainly most organizations that create software do have testing methods in place to catch and eliminate software defects. But at many sites, testing software has been demoted to the same priority level as the task of creating application documentation.
Less and less time is being devoted to testing. The rapid pace of change also makes it difficult to keep test cases updated with the latest application changes. What's more, the effectiveness of testing is sometimes significantly reduced due to insufficient testing facilities and a lack of skilled personnel.
Many companies have opted for a quick round of tests before rapid deployment.
Those companies that subscribe to this line of thinking essentially deploy a preproduction version of their software and assume that end-users will report problems that can then be fixed along the way. This approach ultimately drives up the cost of software over the long term because extra iterations of the development cycle are then needed.
The most vocal critics of software quality often cite the high quality of products and services in other sectors as a point of comparison. We certainly would not find it acceptable to purchase a preproduction refrigerator or car, so why should software be different? Shouldn't we expect higher quality?
The answer is yes, of course. But it is unlikely that application development cycles will gain any time given the intense competitive pressures of today's marketplace.
Think back for a moment to the Y2K remediation efforts on which your company recently spent time. We all had a hard and fast date for completion, yet we managed to complete an exhaustive inspection of our application code with extensive reporting along the way.
Now a page is being borrowed from the Y2K effort to create the next generation of testing tools and services. You'll soon begin to hear much more about this new paradigm: automated code inspection.
Automated code inspection is the process of performing extensive "code-level" analysis of applications using automated tools and detailed reporting. These tools and services impart a deep understanding of the properties of software at the code level and can be used to determine the impact that intended changes might have on the application.
The focus on examining an application's code in an automated way is vastly different than traditional approaches to testing. Some manual code inspection tools are available today, but the vast majority of testing that is performed now focuses on the application layer. Specifically, application functions are tested or perhaps performance is tested. This type of testing requires the use of test cases, which are difficult to maintain. Automated code inspection goes to the root of things -- the application code -- and it does not require test cases.
Automated code inspection can be used to find problems that were missed during the functional testing phase. For new projects, automated code inspection can reduce development costs by identifying code abnormalities and issues prior to the functional testing phase. Likewise, if you have existing software applications, automated code inspection that is performed at scheduled intervals reveals where changes have been made, reports on potential defects that have been introduced, and ferrets out inactive code.
The result of automated code inspection is positive in that it helps you maximize the time available to test applications prior to deployment. In addition, you will not incur as many long-term costs due to redevelopment and redeployment of applications once defects are discovered in the field. You'll more likely catch them before the first deployment, saving your customers the time and trouble of reporting them.
Things in common
As I said earlier, you have a choice between using a tools-based or a service-based approach when performing automated code inspection. These tools and services have two major things in common. First, a good automated code inspection tool or service should construct a graphical view of your application architecture.
Visual diagramming is a good method for uncovering application content, both for technical and business-oriented elements. You can then examine various application paths and the way that they correlate across the enterprise.
The outcome of such diagramming is usually a relationship model that can be used to strengthen the overall design of your applications. The model detects those application components that require modification, variables that are not used, and even poor coding practices.
Another side benefit of visual diagramming is that it can be used to evaluate analyst and developer education needs. After reviewing the visual output, you should clearly see where your staff is struggling and where logic is clear.
This will make it easier to plan curricula and foster knowledge and growth among your teams.
The second commonality among automated code inspection tools and services is the capability of supporting impact analysis (or the "what if" question). By analyzing the effects of proposed application changes before making them, you will significantly reduce the number of errors or code problems that might be introduced.
By simulating application execution during automated code inspection, the impact of changes over time is also evident. Mainframe and client/server legacy applications, in particular, benefit from this impact analysis because it identifies ways to streamline and improve existing processes and examines the impact of introducing new functionality.
Tools or services?
Because there are both tools and services available that perform automated code inspection, you might wonder which approach is better. The answer is that either will work, but you may lean more toward one than the other depending on your working environment.
For example, if you carry out in-house application design, development, and testing, it may make perfect sense to purchase an automated code inspection tool. On the other hand, if you already outsource most of your application development cycle, it may make more sense to contract with an external service.
You may want to consider a service for another reason, however: If you have mostly in-house developers, you might contract with an automated code inspection service to be certain the code inspection is carried out objectively.
One example of an automated code inspection service that recently launched is Reasoning's InstantQA. InstantQA uses a three-layer approach to automated code inspection.
First, a preliminary inspection of selected source code identifies potential defects as well as data-and application-related issues found in the overall flow. Detailed reporting and code inventory is included in this step.
Next, InstantQA drills down a level, performing a detailed inspection of problem areas that are identified by InstantQA personnel and your staff members. During this process, a software reliability report is generated that shows the results of the inspection and recommendations for improvement. The last step is to carry out scheduled reinspections over time to assure long-term software quality.
Today there is a downside to automated code inspection services and tools. This technology sector is just beginning to emerge, which raises questions regarding the stability and maturity of the offerings.
This also means a somewhat limited pool of solutions from which to choose.
Reasoning's is one of only a handful of solutions that are currently available.
Many other tool and service providers will implement automated code inspection technology in the near future, but early adopters will find the current choices limited.
As with most technology issues, automated software inspection is not a panacea for solving software quality issues. However, it is a great step in the right direction, and it appears to have enormous potential for making a positive impact on the software industry and business applications going forward.
Maggie Biggs (firstname.lastname@example.org) is director of the InfoWorld Test Center.
THE BOTTOM LINE
Automated code inspection
Business Case: Traditional source code inspection tools are combining with IT's newfound wisdom from Y2K compliance testing to create a new generation of automated code inspection tools and services that promises to improve the quality of software and business applications without increasing costs or lengthening time to market.
Technology Case: Automated code inspection identifies defects missed during traditional testing cycles and pinpoints code abnormalities prior to testing.
This new market space combines quality assurance practices with code remediation and automated testing-tool methodologies.
+ Complements traditional testing
+ Reduces long-term development costs
+ Helps identify developer education needs+ Clarifies functions and rules in business logic+ Predicts impact of proposed changesCons:
- New market with nascent solutions.