|
Building Quality Applications
Quality doesn't happen by accident. Development teams have to work at it intelligently.
by Peter Varhol
November 13, 2006
As software becomes more and more pervasive in everyday life, the need for higher quality grows almost exponentially. Mission critical has a far broader meaning than it did even a few years ago, with commerce dependent on Web sites, kiosks, up-to-the-second transactions, event processing, and a whole slew of other applications that keep the business moving forward on a daily basis.
As we depend more on software, that software is also becoming more complex. It can include hundreds of thousands of lines of code (or more), several different programming languages, multiple application platforms, loosely coupled interacting components, legacy code, and much more. Certainly our development tools are better than they were a decade ago, but the complexity of the software still greatly outstrips the advances in tools.
Which brings us to the question of how we measure and improve the overall quality of that software. Depending on the resources available and the culture on the development team, it can range the gamut from nothing at all to sophisticated tools, dedicated professionals, and statistical methods.
Today, quality is worth fighting for, and it is worth doing right. The downside—loss of business, customer or user dissatisfaction, or errors in business information—will have a much greater impact today and in the future. In some cases, poor quality software can have life-threatening consequences, raising the stakes still higher.
For those who give thought to application quality, the focus is usually on the functional behavior of an application after most or all of the code has been written. While this focus is surely important, it represents one of the most expensive times in the process to find errors. In fact, the farther along an application progresses in the development life cycle, the more expensive it gets to address bugs and other application errors. That expense is one reason why the first step, writing accurate and unambiguous requirements, is critical.
Quality Begins with Requirements
There are two reasons why good requirements make a difference. First, the development team has to know precisely what to build. Without clear requirements, there is a lot of uncertainty downstream when it comes to implementing features to fulfill those requirements. Second, requirements provide a basis with which to test an application in the later stages of development because bugs encompass more than just application crashes or wrong data. Bugs also include incorrect functionality, which occurs because requirements are ambiguous and misinterpreted by the developers or there is a missed feature or functional mistake.
Only by testing to requirements can an application have a demonstrated level of quality and adherence to original intent. Of course, the emphasis on requirements means that such requirements must be clear, complete, and traceable. Often words and even diagrams can be ambiguous in communicating needs, and analysts responsible for requirements are increasingly turning to formal approaches such as the Unified Modeling Language (UML).
Developers clearly play a key role in the building of high-quality applications. The process of turning requirements into specifications, and specifications into a working application offers ample opportunity for error. The potential for error can be based on misunderstandings, poor communication, bad coding practices, or a lack of understanding of the underlying application platforms.
Good processes, including code reviews and check-in gates, can take up much of the slack. Developer-oriented testing tools can also play a big role. Today, it is necessary, but not sufficient, to only be careful and meticulous in writing code. In addition, you have to not only trust but also verify.
Back to top
|