Assuring Software Quality

New tools help developers define problems clearly.

When the subject is software, the concern for today and tomorrow is quality. IT community concerns are apparent, for example, in the current draft program for next months International Conference on Quality Software, scheduled to take place in Dallas on Nov. 6 and 7. Presentation topics during those days will include test-case generation from software specifications, checklists and models for estimating software costs, and the challenges of defining and testing software quality in e-commerce environments involving highly distributed systems with varying performance of critical communication links.

In the product reviews on this and the following pages, eWEEK Labs looks at three sources of tools that should reset enterprise expectations for stakeholder involvement in software definition, for developer rigor in defining and applying quality standards to their work, and for thorough understanding of the more dynamic behavior of code in complex environments such as Microsoft Corp.s .Net.

We present the first review ever published of the breakthrough iRise Application Simulator, a product designed to ensure that the right problem gets solved; a hot-off-the-CD-burner review of this weeks release of Parasoft Corp.s Jtest 5.0, which brings open-source Eclipse integration and streamlined defect repair to an already proven Java assistant; and a review of Compuware Corp.s latest update of its testing and quality assurance extensions for Microsofts workbench, dramatically expanding the products support for .Net development.

The growing concern for software quality swims against a tide of programmer talent that was trained during the early years of the PC to make applications run fast as the principal goal. The painful paradox is that hardware has proved to have much less inertia than software. Todays machines and their high-speed networks run almost every enterprise application fast enough to find themselves waiting for the user much more often than the other way around.

Meanwhile, users and administrators waste thousands of hours and billions of dollars attending to the weaknesses of "live fast, die young" code that achieved speed by eschewing internal defenses against unexpected input or resource shortages (to say nothing of its fragility in the face of patient and deliberate attack). Both the Parasoft and the Compuware tools reviewed here address these problems.

The other, perhaps much greater damage thats done by bare-metal programming practices is that software takes on rigid form much too quickly, even in what are supposed to be prototyping stages of development. The resulting code rapidly becomes difficult to change without starting from scratch.

Modern languages make it possible to design in a modular and flexible fashion, but they often do not enforce that modularity; they certainly do not meet the need of nonprogrammer stakeholders to understand the impact of their requests to development teams or to have an opportunity to refine those requests as a project moves forward. Were pleased to see iRise taking on this challenge.

Largely ignoring these changing priorities, mainstream application development tool sets have made huge strides in their ability to fashion code quickly but have made much less progress in bringing design and test tools closer to the focus of the developer. Among the best-known tool makers, Borland Software Corp. has been the most conspicuous in its campaign of the last two years to acquire process-oriented toolsmiths.

Borland has been expanding its category-defining "edit, compile, debug" environments into more complete offerings—such as the recently released Enterprise Studio for C++, reviewed by eWEEK Labs here, —and into the longer mantra of "define, design, develop, test, deploy, manage." Failure at any of these points, todays developers increasingly are realizing, is failure of the entire process.

We hope developers will tell us where else we should be looking for solutions to the critical problem of solving the right problem in the right way, rather than writing code quickly to run fast in the wrong direction.

Discuss this in the eWEEK forum.

Technology Editor Peter Coffee can be contacted at peter_coffee