My Web Application Development Process

The First Step - Analysis and Planning

The planning stage is where you meet with the client and get t know exactly what they need. If they have an existing system in place — either a paper-based system, existing web-based or desktop system, have then run through their typical daily tasks and show you exactly what they do, and why they do it. The point here is not to start making recommendations but to get really inside their current system and get a complete understanding of how the system helps them. Almost assume you’re being trained for their job and have to do each of the tasks that they’re doing and why they’re doing it so you can start thinking about the system from their perspective.
You might be thinking that a lot of clients don’t currently have anything in place, but I’ve had clients to wrote down all their service calls on paper and then wrote them on a big white board before I worked with them. That was their system, and that’s the first place we started. The goal of any web-based application is to improve employee work flow, and subsequently increase productivity. Otherwise, it’s hard to make a business case to the client to spend thousands of dollars on your custom software.

Once you have a clear understanding of their business and how their existing system works you can start planning and making recommendations for improvements to the system. Start brainstorming with the client and ask them what immediately comes to their mind in an effort to start improving their current work flow. Here is where the documentation starts as well. Start off with a functional specification of the system that clearly outlines, in a high-level description, what the proposed system will do and how it will improve efficiencies and productivity. This does a couple things: it helps define the exact scope of the project at the start to help reduce any scope creep and change requests throughout the project, and also helps you define the project to include in your contract or service agreement.
A Note on Documentation:You might be thinking to yourself, that it sounds like a lot of documentation, and a lot to do up front. However, I’ve found that it is quite rare for a client to truly understand themselves what they want in a system when it is being developed, and the more discussion, brainstorming, and documentation you put in place it helps develop further discussion on the system, and finalize on a complete and accurate system spec. The more details you include in your up front documentation, the less questions and changes you’ll have down the road. For large complex systems, a lack of documentation and planning can mean stalled projects, delays in delivery (and payment), and unhappy clients due to confusion about the project.

Interface Design

Yes, the interface is the second step. Part of the planning should include how the client wants the interface to work. This is arguably the most important aspect of the development project, since the interface will effectively determine whether the application is a success or not. Keeping the users of the system happy is the single most powerful tool in turning a web application client into a long-term business relationship. If the users are constantly complaining to their boss about how difficult it is to use, then you’re going to have more minor fixes, and headaches than you’ll want.

They won’t have a clue about the technical underpinnings of the system like how the database is setup or structured, or whether you’ve coded it well or not. Although database and coding is equally important to the interface on your end, the clients really could care less.

During the interface design, you need to design every single screen from the login, to the user’s dashboard, reports, and forms. Each and every module should be clearly defined including mock error messages and notices. The reason for doing this separately before the actual programming is that you won’t be in a programming state of mind while designing the system. If you do all your mock ups in Photoshop or Fireworks you’re not thinking about how you’ll code the HTML or structure the database - you’re solely thinking about how the system works. If you do leave these elements out, while you’re programming it, you won’t give them the required time and attention and the entire application will suffer.

This also gives your user a way of seeing what the application will look like and give you very important feedback. You don’t want to have to re-work the interface once you’ve already coded it. That can be a huge hassle, and changing it at this step is simple.

As I’m drawing up mockups, I like to label them with their proposed URL structure. Rather than trying to set this up in the development stage, start thinking about it here. Label each of your screens as domain.com/app/module/function ex: domain.com/app/calendar/view and domain.com/app/calendar/edit/434. It doesn’t mean you need to split these functions into different actual web pages - through the use of mod_rewrite you can create some great-looking URLs.

Database Design

Now we can begin the database structure. Look at the proposed screens for the application and start grouping fields, entities, and the data you’ll be storing and create some high-level Entity-Relationship Diagrams or ERDs. Then get more detailed and create a complete database structure including the relationships between each table. I like to reduce to Third Normal Form (3NF), but you can go deeper if you want. You’ll find that this step is quite easy now that you’ve already done the interface design, as well, from doing the interface design, you’ll also have the fields and other data clearly outlined so you won’t have as many surprise changes to the structure of the data. You probably don’t want to show this document to the client as they most likely won’t understand it.

Class and Application Structure

At this point I like to start outlining any classes and data objects I’ll need in the system. Object-oriented programming (OOP) is always the way to go, especially in large, complex web applications since you’ll be maintaining the system for some time as well. The goal is to have as much code reuse as possible, and to come up with a logical set of programming objects to reduce the complexity of programming the system as well as the maintenance.

This doesn’t mean just coming up with standard database connection objects, and other standards libraries, you want to look at objects specific to functions of the application. For example, if the system includes an inventory module, you want to create one or more inventory objects so if you need to use an edit form in multiple places within your application you don’t need to cut and paste code, its a simple function call.

Directory Structure

Now I start planning my directory structure. I like to group my directories in a similar manner as the applications function, and I keep my images, javascripts, css, etc grouped as well. Here’s a sample:
• .htaccess
• /images
• /javascript
• /css
• /conf
• /includes
• /class
• /modules
• /tmp
• /files
o /images
o /documents

I like to have a temp directory for file uploads contained within the web application rather than uploading files to a server’s general temp directory, and I also like to put all uploaded files within the files directory and organize them accordingly witihin. The conf directory holds any configuration files (which will include system options and database connection variables). The modules directory will include folders and the files for each module within the system. Finally, the .htaccess file includes any rewrite rules and server configurations.

Development

Now we can start the development of the site. This consists of converting my mockups to HTML/CSS and getting the templates uploaded, then building the database and finally connecting the HTML templates to the database with code. I always work off my local file server and then do periodic uploads of the system to a web server where the client can play around with it while I’m developing off my own internal server. This way they can look at the system and do some testing while I’m developing. It also keeps them in the loop during the entire development process to ensure that you don’t go off track on the system.

Also, ensure that you have some sort of backup in place for your system while it’s in development. This is critical for the obvious reason that you don’t want to lose it and have to start over, but you’ll often mess something up and want to start over from the beginning of the day or earlier. In fact, setting up some sort of version control system like CVS or Subversion is your best bet, I recommend Subersion.

Quality Assurance and Testing

You’ll be testing while you develop the site, but you want to put aside some time to try and break your system once you have a working BETA of the application. This means entering invalid data, trying to hack into login forms, etc. Have your clients try the same, as they’ll probably think of entirely different methods of using the system since they haven’t been so close to the development of the system like you have.
During the development phase you should also be putting together a test plan to help test the system. This is where you’ll refine it and then run through your test plan and track any bugs as they are found. I like to track bugs in a spreadsheet using Excel or iWork Numbers.

Launch

Finally, launch the application. You’ll want to give your client a notice that there may be some minor tweaks to work out in the first couple weeks or months of using the system. Just have them track any issues and report back to you for fixing. I typically give them a period of 1 or 2 months where I’ll fix any other bugs they find, but after that point any fixes are billable to the client.

Maintenance

Now that the project is initially complete, you’ll want to setup a maintenance agreement with the client to maintain the system. THis means ongoing support and bug-fixes, web hosting for the system, and regular backups.

Web applications can be a lucrative part of your web development business, they have been for me, and I really enjoy the challenge of planning, designing and implementing the systems. As well from a business point of view, they’re a great source of continual revenue, and also a great way to build stable, long-term clients, which are essential to the long-term plans for your business.