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.
Certainly this is not due to a lack of available tools or methodologies for testing applications because there are plenty of both. The move to distributed computing has contributed to the decline in software quality because decentralised application components make application testing more complicated, but it is not the root of the problem.
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 centralised computing to a compute-anywhere paradigm, the application development cycle has become increasingly compressed.
Certainly most organisations 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 pre-production 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 pre-production 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. The Standish Group, a technology research company, recently spent time examining this emerging trend. It found that the market for automated code inspection tools will reach $US250 million by 2002, while the market for automated code inspection services is expected to leap to nearly $1 billion by 2003.
To find out just how close business is to adopting these products and services, The Standish Group surveyed executives at Fortune 1000 companies to gauge their interest in increasing software quality by implementing automated code inspection tools and/or services. Of those executives surveyed, 33 per cent indicated that they were ready to implement this technology now, while another 24 per cent are considering doing so.
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 maximise 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. Some of the available tools and services support visual diagramming of your entire application set (multiple applications).
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. Furthermore, the visual output of these tools and services helps you validate business functions and the business rules in play during application execution. You can usually generate additional reporting from these tools and services that help you understand where to focus your staff to improve software quality.
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 analysing 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.
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 (see our Service Review). InstantQA uses a three-layer approach to automated code inspection.the bottom lineAutomated Code InspectionBusin-ess Case: Traditional source code inspection tools are combined 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.
Techn-ology 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.
Pros:- -l Complements traditional testing l Reduces long-term development costs l Helps identify developer education needs l Clarifies functions and rules in business logic l Predicts impact of proposed changes Cons-: l New market with nascent solutions