Planning the Process

By now, you have probably met with your client a few times and have done your initial research. You have a pretty good idea about what your application is going to be about. You probably also are beginning to have a strong sense about how it will be laid out. In other words, you should be able to see the application in your mind. Time to get that down on paper. Then you can start doing the real work!

Design Documents

Even the most accomplished developers sometimes jump in without writing anything down on paper first. Those same developers will tell you that in most instances, working this way turns out to be a mistake. Sooner or later you realize you forgot some feature your client was expecting. Without documents, whether you really forgot the featureor whether your client simply didn't mention itcan't be proven. In short, it simply can't hurt to put things down on paper.

Specification Document

At the very least, you should have some type of project specifications document that describes the application in plain English (or whatever) and lists all the critical elements or features. This document should also include approximations of how long you think each item will take to complete.

The document should have a big picture or executive summary portion that, if read by an outsider, will provide an explanation of the project. It should also have a detailed portion that is as specific as possible about individual features.

You also might want the document to prioritize the various elements or features; it could be that a shopping cart and an events calendar are both required elements, but that the events calendar is to be your primary focus. Most importantly, the specifications document should include the expectations that you have agreed upon for the project (see the section "Setting Expectations," earlier in this chapter).

Flowcharts and Storyboards

Depending on the project and your client, you might want to put together some visual aids, such as flowcharts or storyboards, that visually explain the various pages that will make up your application and what elements will be visible on each.

If you own a copy of the software product called Visio, you could use it to lay out flowcharts or storyboards. You could also use just about any other drawing program (such as PowerPoint) or just plain old paper or whiteboards. These flowcharts might be logical (mapping out the flow of decisions a template will make or the flow of choices your users might make) or physical (representing the pages in your application and the sequence or links from one to the other).

You might even end up with sketches of each page. In any case, be sure the important elements and features from your specification document are represented.

Milestones Document

Just as most therapists stress the importance of setting boundaries in your personal life, most developers recommend establishing milestones during the development of an application. Milestones are like checkpoints along the way to an application's completion. You might try to set five milestones, say, each representing approximately 20 percent of the application's features or pages. After each milestone, your client should take a look, give you preliminary feedback, and generally let you know that you are on the right track.

Milestones are good for everyone involved. Your client gets a positive feeling of progress whenever a milestone is reached. You also get a positive feeling of accomplishment, but more importantly, you are ensuring that your client is reasonably satisfied with the development at a number of junctures. This involvement also protects youif your client has reviewed your progress as you reach these milestones, you know there's little chance of their disliking the whole project at the end because of some misunderstanding.

Planning the Testing Phase

You should now have a good roadmap for the development of your project, in the form of your specifications and milestones documents (see the previous section). Next, you should put together a similar type of roadmap for the testing phase. No matter how great a coder you are, your application is bound to have at least one bug the first time around. It's important that you and your client expect and leave time for some type of beta or testing phase.

Who Can Help with Q.A.?

Somebody should be assigned the job of overseeing quality assurance (Q.A.) for your application. In other words, someone should put the application through its paces to ensure that everything works as intended. Do all the links work? What if certain form fields are left out? What if a user submits a form more than once?

The Q.A. folks also can be the ones ensuring that your application meets all the expectations agreed upon earlier (see the section "Setting Expectations," earlier in this chapter). If you agreed on a maximum download time for modem users, trying some of the pages using a modem can be part of the Q.A. process. If you agreed on Internet Explorer and Netscape compatibility, someone should view the application using each relevant browser.

You also might want to make a list of all the items in your application that should be tested whenever you update the code. That way, your Q.A. team (which might be just you) has a checklist of links, mouse clicks, and form submissions, for example, that must function properly before an iteration of the application can be said to be complete.

Beta Testing

In addition to internal Q.A. work, it's often a good idea to have some kind of semi-public beta test in which real users get to put the application through its paces. Everyday users have a way of finding even the most obscure problems. Navigation elements that seem intuitive to you might be baffling to average folks. They might consistently overlook the most important button on the page, for instance.

Depending on the application, the appropriate beta testers can be select people within the company (perhaps the same folks you interviewed while you were defining the project, as discussed above), or a group of the company's customers. Or you might decide to open the beta site to the general public. There are also a variety of automated load-testing tools available that can test how your application will perform when used by many users at once.

Tracking Bug Reports

You might want to set up a way for people to report bugs in the application so that a list of unresolved issues will exist in a central place. Doing so will also keep your client off your back as you complete the project. Let's face it: People like to see progress. Anyone who can report bugs through some type of official channeland see that the bug has been fixed a few days laterwill be impressed with your professionalism.

You can approach bug tracking in many ways. Various commercial project-management applications include bug-tracking functionality. Check out Macromedia's SiteSpring product, or use ColdFusion to put together your own Web-based bug-tracker that your Q.A. people and beta users can use whenever they find a bug. Just be sure the bug tracker doesn't have any bugs of its own!

NOTE

If you do create a Web-based bug tracker, you could include a link to it whenever a ColdFusion error message gets displayed for whatever reason. See "Customizing Error Messages" in Chapter 19, "Introducing the Web Application Framework," for details.

Separate Development Environment

Plan to have a separate development environment (server or set of servers) that will be used only by you and the rest of your development team, if there is one. While your Q.A. people are checking out the application and finding bugs, you can be working on those bugs without worrying whether the Q.A. people can still work while you're making changes. Many people achieve this by installing a private copy of the ColdFusion server and database server on their own workstations. Performance might not be optimal, but it is usually fine for development.

Staging/Production

Most developers recommend having separate staging and production environments. The staging environment is a server or set of servers your client visits to review your progress. It's also the server your Q.A. or beta users visit. The production server is where the final code goes after everyone is satisfied with it, and it is the server your actual end users visit. Any updates to the code are made first to staging tested there, and then moved to production.

Ideally, the staging and production environments should be as identical as possible (same hardware, same software versions, and so on), so no surprise incompatibilities or other issues occur.