How to Build Quality Applications

In some of my previous Knowledge Center articles, I've talked about testing as a means to build confidence in the quality of your data center's applications. It's good to have confidence before you turn an application loose on users, but why wait until the end of the project? The most efficient form of quality assurance is building software the right way, right from the start. What can IT managers and professionals do, starting from the first day of the project, to deliver quality applications?

The first step in building a quality application is to know what you need to build. An amazingly large number of projects get started without clarity among the project stakeholders about what the requirements are. As many as 45 percent of defects are introduced in specifications. One working definition for quality is "fitness for use."

If we're unclear on the intended uses, how can we build something that is fit for use? Not only do we need some specification of the requirements—whether formal or informal—but we should also conduct a thorough project stakeholder review of this specification to look for defects and to build consensus and understanding.

Another important early step is properly organizing the project. The overall approach to application development is the software development life cycle (SDLC) model. There are four main varieties of SDLC in common use today:

1. Sequential (also called Waterfall or V-Model)

In this approach, the team proceeds through a sequence of phases, starting with requirements, then design, then implementation, and then multiple levels of testing. This model works best when you can specify requirements that will change very little, if at all, over the course of the project. It also works best when you can plan the project with great accuracy, which typically means it's similar to a project the team's done before.

2. Iterative (also called Incremental or Evolutionary)

In this approach, the high-level requirements are grouped together into iterations (or increments)—often based on technical risk, business importance or both. The system is then designed, built and tested group by group. This model works well if you need to deliver the most important features by a rigid deadline but can accept some features arriving later. This model can tolerate some change in the plan (often due to uncertainty or change in requirements) and still deliver the key features on time, which is not true of the sequential models.

3. Agile (such as Scrum and XP)

In Agile approaches, each iteration is compressed to as short as two weeks. Documentation is minimized, change is expected from one iteration to the next and within each iteration. Various rules help prevent devolution into churn and chaos. This model works when applied with discipline, and its emphasis on accommodating change allows it to produce results even in rapidly evolving situations.

4. Code-and-fix

This approach is actually the absence of an approach. It involves starting the development of the application without any requirements, without a clear plan, without anything but a deadline in many cases. This model can only work for the simplest, shortest and least risky of development projects.

Now, the first three of these models exhibit significant variation in practice. You should feel free to intelligently tailor the model to your specific needs, but beware of violating certain aspects of the model that enable other features of the model.

Next: How to Minimize Bugs >>