eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Software quality assurance can be applied at any point in the pipeline that connects a users need with a deployed solution. The choice of where to put that pressure must balance concerns of schedule, cost and business reputation.
Design time is the highest leverage point in terms of least effort to prevent greatest harm. Modern development tools, regrettably, encourage prototyping that all too quickly turns into production coding without the benefit of a specification.
End-user testing is all too often the default quality strategy, but this so-called gamma testing wont survive the transition from software as boxed good to software as online service. Development teams must find a way to reconcile the rising expectations of software-as-service with the human nature of developers and their managers.
Process guru Edward Yourdon opines that the price of pursuing perfection is being far too late to market; that users will choose the continuing cost of putting up with bugs in what theyve already learned to use, rather than enduring the short, sharp pain of converting to even a higher-quality product. Yourdon hopes that improved understanding of the development process will enable rational calculation and negotiation.
“The project manager,” Yourdon urges, “should be able to say something like, Our standard approach for developing the software youve described will require X number of people and Y units of time, with a cost of Z dollars; well deliver P units of functionality, with a defect level of Q bugs per function point.” Hes quick to warn, however, that “the relationships between X, Y, Z, P and Q are something we dont know enough about.”
Static source code inspection is gaining ground among methods of defect prevention. Dynamic testing is becoming a daunting task in event-driven applications, and many studies make the case that inspection is cheaper: Ratios have ranged from 6-to-1 at TRW Inc. to as high as 20-to-1 at IBMs Santa Teresa (Calif.) Lab for costs of fixing bugs found in testing compared with those found by source code analysis.
Unconstrained languages such as C or C++ might seem to defy such scrutiny, but the same techniques that perform compile-time optimization of code can also ask the question “Is there any way that this code can get itself into trouble?” Thats what Reasoning Inc., for example, does with its Illuma analysis service, which will be unveiled this week.
Finding defects today is not, however, the same thing as preventing them tomorrow. The origin and spread of defects is important to understand, and reports such as those produced by Illuma must be analyzed with that goal in mind.
Illuma also offers metrics analysis, comparing defect densities with those that Reasoning has observed in many other projects. Managers can not only ask “How many bugs do we have?” but also can ask “Are we good enough?” Its up to software buyers to tell them how good that is.