An Overview of the Design Process

Any nontrivial task requires some degree of planning before the task can begin. When building a house, an architect creates the blueprints, surveyors inspect the building site, and engineers ensure that the materials selected are sufficient. This process, which can take months or years, happens before the first brick is laid or the first nail hammered. You wouldn't want to live in a house that was built without any forethought, one whose design was decided on as the foundation was laid and the walls constructed.

While most web applications are not as complex as building a house from the ground up, they still warrant a sufficient amount of planning before the first web page is created or the first line of code is written. Applications that are started without a clear plan are typically buggier and more difficult to enhance or extend than those that were preceded with ample planning. Large and complex web applicationsthose with teams of dozens of developerscan take months of planning. For our much simpler online photo album application, however, an hour of planning should be sufficient.

The planning stage for any software application usually involves the following steps:

1. Collect design requirements from the customer.

2. For applications that need to persist data, implement the database schema necessary to capture the data spelled out in the design requirements.

3. Create mockups of the web application.

The goal of the first step is to understand the customer's needs for the application. What is the purpose of this application? What business requirements must be implemented by the system? How will the customer use the system on a day-to-day basis? What will the typical workflows be when using the system? Typically, this is the most challenging of the three steps because often a customer either doesn't know precisely what it is he wants to have the system accomplish, or there is some difficulty in fully explaining the requirements. Fortunately, we won't have this problem, since for this exercise we will be both the developer and customer!

By the Way

One way to help ascertain the customer's requirements is to ask her to provide use cases. A use case is a paragraph or two describing, in plain English, how a particular task would be accomplished. For example, a use case for our online photo album application might be as follows:

"Sally wants to upload an image to her photo album. She visits the website and can enter her login credentials from the home page. After she logs on, the "Add Picture" link is displayed. Clicking this, Sally is prompted to choose the picture from her hard drive that she wants to upload, along with a title for the picture, the category the picture belongs in, and a brief description."

The second step involves creating the database tables and defining their columns. The structure of the database will be highly dependent on the requirements gathered in step 1. The final step is to create a mockup of the application. This may be actual, working ASP.NET pages that have only a small subset of the functionality built in, or it may be something as simple as sketches on a piece of paper.

Commonly, the design process is iterative. That is, after creating the mockups, the customer is called back and shown the mockups. This provides an opportunity for the customer to refine the requirements or request changes to the appearance of the application. This cycle continues until the client is satisfied with the mockups and there is a solid understanding of the requirements between both the customer and the developers. When this point has been reached, the actual development of the working system can begin.

Over the next three sections, we'll perform each of these three software development steps. By the end of this hour, we'll have a solid understanding of the requirements of the system, along with the database structure defined. The final two hours take the concepts outlined in this hour and implement them.