Developers each have their own approach to development. You may not know it, but you have one too. Having a set methodology allows you to sit back down at a project somewhere down the line and know what is going on immediately. Maintenance of the application is more cost effective. This article gives you an overview of the basic software development process, discusses what methodologies and frameworks are, and goes into some details on the methodology that I use in my own everyday development.

I have heard it said that the success of any software project occurs before a single line of code is ever written. Accordingly, we'll start our review by talking about the full software development life cycle. There are a few different models of software development, but they all contain similar elements, or phases.

These are the eight main phases:

1. Requirements: In the requirements phase, the client (software program user, your boss, whoever) defines some problem that they want to solve. You, as the programmer, will talk to the client about what they need a program to do. I like to think of the requirements phase as one where the client says, "This is what I want." In an ideal world, the client's request will be completely documented before I have to meet with them. Realistically, that rarely happens. This phase usually consists of multiple meetings with a client, project manager, or boss.
2. Specification: The specification phase comes after the requirements phase. Here we tell the client what we're going to do for them to solve their problem, as defined in the requirements phase. If we've done our job correctly, the requirements and specifications will sync up and all will be well in the world. I like to document both of these phases pretty heavily, and if possible have the client sign off on appropriate documentation.
3. Design: With the approval of a specification document, you can start your software design. You map out the flow of the program, mock up an interface (or rapid prototype), design the database, and flush out any business requirements not defined in the specifications.
4. Implementation: After you have the design all set, you can sit down and code. I'm sure that is what most of us do best. The implementation makes the design work.
5. Quality assurance: In this phase, you test the application from start to finish, looking for problems with the code or logic. Next to requirements, the client often has the most involvement in this phase. They will know immediately at this point if something is seriously wrong with the application.
6. Integration and rollout: In the past this would involve moving from machine to machine to upgrade to the new version of the software. With Web applications, those days are over. In the Web world, rollout is easy. Just tell people to point their browser to the new application.
7. Maintenance: Over time, businesses change - and so do requirements. The application will need to change to meet those changing business requirements. Often in the maintenance phase you go through the whole software development process in a smaller way, specifying requirements for changes, defining the specifications, modifying the design, and so on.
8. Retirement: All good things must come to an end. In this phase we put the application to rest. Business requirements have changed so much over the years that it's more cost effective to replace the application than to modify it.

As you might have guessed, the phases often overlap. Often requirements and specifications are lumped into a single phase, for example. And some design work may be done during specifications; or during the implementation. Debugging is done during both the implementation and testing phases. Having the client involved in all phases of the project is often critical for its success.

There are different models of software development using these phases. The waterfall model is the most common. It moves from one phase to the other in tandem. The rapid prototype model starts by building a rapid prototype, or mockup, of the application. A specification is built from the rapid prototype, and the rest of the phases continue one after the other. The rapid prototype or waterfall models encompass full applications.

There's a third model called the iterative model, that follows the whole process for each individual application feature. The intent of this model is that release cycles will come every few weeks. This model works really well during large projects. You wouldn't want to be halfway through development on a yearlong project and then find out that everything you've done is wrong. I often like to use this model for the maintenance phase also.

My Development Methodology
The rest of this article will specifically talk about how I myself develop during the implementation phase of a project. I'm going to explain my method for organizing code and approaching development. Every template I write starts with a documentation header. Good documentation is often crucial when modifying code at some future point.

First, I include a description of the template. Why am I creating this template, what code does it contain? I'll also include the name of the file and the date it was created. When working as part of a team, I'll specify the name of the creator (me), and my company name, if I'm developing for a client.

Second, I'll specify where the code fits into the flow of logic. Is it an include file, a custom tag, a form page, or something else? If there is a multistep process, what step does this file represent? What file represents the previous step? What file represents the next step?

Next I'll document any file dependencies such as custom tags, include files, or ColdFusion components that need to exist in order for this template to run correctly. Then I'll document variable dependencies. What variables must be defined for this template to properly process? Do we need any URL variables? Form variables? Are they required or optional? If they are optional what are their default values?

Sometimes it may seem like a lot of work to create this documentation up front, but you'll thank yourself down the line. It takes minimal extra effort when you create the page and can save loads of time during the maintenance phase.

Documentation aside, I try to keep each template as modular as possible. That means that each template does only a single set of related actions. Here are the common types of templates you'll encounter during your development:

• Application.cfm & OnRequestEnd.cfm: The Application.cfm is a page that ColdFusion runs at the beginning of every request. I use this page to set up the basic application, directory locations variables, and datasource names. OnRequestEnd.cfm runs at the end of every request. It is not used often.
• Header and footer: I usually have only one header and footer file in a site, called header.cfm and footer.cfm respectively. The header contains the standard navigation and most common graphical elements of the site. The footer contains any disclaimers at the bottom of every page. I use a cfinclude to put these two templates into every other template. Between the header and footer goes the individual content. I don't put the header information in the Application.cfm and footer information in OnRequestEnd.cfm is because I like to reserve those files for processing code, not display code.
• Index: The index template is your home page. Some Web servers are programmed to look for default.cfm instead of index.cfm, but many will look for both.
• List page: A list page is a page that lists data based on certain criteria. For example, if you are creating a page that lists all the users who have registered on the site, you might name this page register.cfm.
• Input: Input pages are pages that accept input from the user. In standard Web development an input page will contain an HTML form. I like to distinguish an input page by putting an "i" at the end of the file name. A file that accepts input for a user registration would be registeri.cfm.
• Processing: Processing pages are those that a form submits onto. These pages usually verify the data, and then insert or update it to the database. I like to distinguish these with a "p" at the end of the file name. In our registration example, the registration-processing page would be registerip.cfm. That signifies that we are processing the registration input.
• Update: Pages that update data are very similar to input pages, except the forms are already filled with data. I like to distinguish these files with a "u". A registration update page would be registeru.cfm. The processing page for the update registration functionality would be registerup.cfm.
• Verification: Verification pages are pages that lie between input and processing. They display all the data to the user and give the user an option of changing data before it goes into the database. If you want to have the user verify their data before committing it to the database, use a verification page.
• Delete: A delete page is one for deleting data. I distinguish these files with a "d" character. For example, to delete a registration, the file would be named registerd.cfm. Often these pages will trigger a flag to make the data inactive instead of completely deleting the data.

I've worked on sites that have tried to put a lot of the functionality into a single template, such as create, edit, and delete. I've had much better luck maintaining templates that don't do everything in a single template. There's also less processing because you don't have to figure out which "actions' of the template you're supposed to be executing. Using this method can make code less portable than having everything in a single template. If consistent naming conventions are used, this is rarely a problem.

Since the release of ColdFusion MX, I have been moving most of the functional code inside CFCs. For example, the verification page will call methods, which verify the data, but won't actually verify the data. If an error is returned, it displays the appropriate error. The process page will call a method to commit the data to the database. I've been storing the CFCs in the session scope, so I don't have to worry about excessive parameter passing from one template to another. The input page collects the data, the verification page stores it in component properties, and the processing page commits it to the database.

Other Development Methodologies and Frameworks
There's often a lot of confusion as to what a methodology is, what a framework is, and what the differences between them are.

A methodology is an organized approach to writing and organizing your code. What I've defined in this document is a rough methodology that I use for code development. A framework is a collection of code used as a template for writing applications. There is often a tradeoff for using a framework in your development and that is that it will most likely contain code you don't need to use. The performance hindrance of unused code is offset by the decrease in a development schedule. Using a framework will also make your code more consistent. In performance critical -applications you probably won't want to build your application within a framework.

Here are some common methodologies and frameworks used throughout the ColdFusion world:

• Fusebox: Fusebox is one of the most popular methodologies out there. Fusebox 1 was a strict methodology; although current versions provide some semblance of a framework. The most current version is Fusebox 4 and more information can be found at www.fusebox.org. Anyone looking at Fusebox should also take a look at the Fusebox Lifecycle Process (FLiP), which handles the full software development life cycle.
• cfobjects: cfobjects is a framework used to apply object-oriented principles to ColdFusion development. It is developed to work with pre-CFMX versions and consists of a lot of custom tags, plus a toolbar for ColdFusion Studio (HomeSite +). More information can be found at cfobjects.sourceforge.net.
• Mach-II: Mach-II is a framework used to apply object-oriented design principles to ColdFusion from development. It's relatively new in the world of development and was spun off development that was originally supposed to be Fusebox MX. You can find more information about Mach-II at www.mach-ii.com/. Macromedia has developed some of their site using the Mach-II framework.

Summary
This was intended as a high-level overview of approaches to development. No matter what type of development you are doing, you'll need a methodology - having one that you always follow keeps things consistent if nothing else. When working with teams, it's best to decide on a common methodology that all developers will use. Not every methodology will work in every situation. It's best to document the methodology that you are using as developers enter and leave your project.