This blog has moved here: | FOLLOW ME ON TWITTER @woork
Friday, January 9, 2009

Structured process you must know to develop a web application

Developing a web application is a hard work which requires much time you have to spend doing a myriad of things. If you don't use a methodic approach, especially in case of a complex project, you run the risk of losing sight of the project, not respecting times of delivery and wast your time for nothing.

This post illustrates a structured process which helps you to simplify the approach to develop your web applications saving time and more efficiently.

Download The Woork Papers N1 | Structured process you must know to develop a web application

Process main phases
In a generic web application developing process you can identify five main phases:

1. Requirements definition
2. Design
3. Implementation
4. Test
5. Release

Planning and Monitoring is a "cross phase" which follows developing process defining a project plan composed from a list of activities which you have to monitor during project execution. For each activity you have to define a set of information useful for its monitoring, for example:

- owner
- duration
- costs
- ...

Take a look at these posts I wrote some time ago about how to implement a project plan with a Gantt chart using Excel or Google Spreadsheets:

How to organize a project plan
Excel Gantt chart template
Implement a project plan and manage activities with Google Spreadsheets

1. Requirements Definition
In this first phase you have to define the scope and needs of your web application in terms of what your application must do, main features and technical requirements:

In order to define the scope of your web application is sufficient to compile a detailed list with a clear description of application features. At the moment is not important "how" you'll realize them but "what" you have to realize!

Needs analysis is a crucial part of developing process. In this step you have to estimate your potential traffic, choose a server-side language (PHP, ASP, Coldfusion...), database, choose an hosting service... Place a big attention on not to overrate/underrate your estimates! Evaluate every thing with a right balance between times, costs and objectives!

2. Design
After requirements definition phase, you have to "design" your application with a clear project. In this phase you can identify the following steps:

Design: Application Map
An application map contains just meaningful and essential information about the structure of your application: pages (represented with some blocks) and main relationships between them. Your application map could be something like this:

In this way you have a map with some "locations" (pages) and a "path" (relationships between pages) which you simply have to follow in order to proceed, page-by-page, to implement your application in the next phase. In this way you'll save a lot of time, having clear in mind what you have to implement.

Design: Database
Ok, now it's time to design application database. A simple way to do that it's using a entities-relationships (ER) model. In general you can follow this order: define first tables, than attributes and relationships between tables. Your ER model will be like this:

1:1 expresses the cardinality of a relationship (in this case for example 1 user is assigned only to 1 task, 1 user live only in a city). For more information about this topic take a look at my old posts:

Define the entities-relationships model
A correct approach to define relationships between database tables
10 Useful articles about Database design

Design: Page Structure
Next step is to design an approximate structure of the page, identifying all main sections using a name (for example #header, #navbar, #mainContent, #sidebar).

Design: Server-side Language
Taking a mind an object-oriented approach for developing your application, you can defining classes, functions and all server-side features you need. Remember... that's not the "implementation" but a way to have a "guide" for that you'll implement in the next phase.

Design: JS Framework
In this step choose a JavaScript Framework (jQuery, Scriptaculous, MooTools...), than pass to identify the main features you want to implement (drag and drop, animation effects...) compiling a simple list which associates each specific feature to one or more pages identified in you application map.

A this point design phase is completed. Let's start with implementation!

3. Implementation
Ok.. now starts the real challenge because "implementation" is the realization of your application. You can divide this phase in the following steps:

Implementation: Database
Create a new database and write SQL code defining tables, attributes and relationships. In the past I dedicated some posts about this topic. Take a look at the following links for more information:

How to use PHP and SQL to create DB tables and relationships
Create tables and relationships with SQL

Implementation: HTML
Use the page structure you defined in Design phase to implement HTML code:

<div id="header"> </div>
<div id="navbar"> </div>
<div id="mainContent"> </div>
<div id="sidebar"> </div>
<div id="footer"> </div>

This is the moment to add all HTML elements you need in sections identified during Design phase. For example if the sections mainContent contains a post with a title, a text body and post tags, add these elements:

<div id="header"> </div>
<div id="navbar"> </div>

<div id="mainContent">
<h1><!-- Post title --></h1>
<p><!-- Text body --></p>
<small><!-- Post tags --></small>

<div id="sidebar"> </div>
<div id="footer"> </div>

Implementation: CSS
When the main structure is ready, start to write CSS code to add styles to your application. If you need some suggestions about how to write a better CSS code take a look at these posts:

CSS coding: semantic approach in naming convention
Useful guidelines to improve CSS coding and maintainability

Implementation: Server-side language
Implement application class, application functions, DB interactions, queries, and every thing requires a server-side interaction.

Implementation: JavaScript
Implement Ajax features
(drag and drop, animation effects...) using the framework you chose in Design phase (jQuery, Scriptaculous, MooTools...).

4. Test
During this phase you have to "stress" your application executing your code in various conditions (for example using different browser). Your objective is to detect all application bugs and fix them before the final release.

Remember, this process must be methodic and require a lot of patience! Test each page and each features (also in this case can help you application map to proceed in a certain order). If you find a bug during test esecution, fix it modifying the code and than proceed with the final validation (an ulterior test) of the code.

5. Release
Finally you are ready to release your application! Publish it in a test folder and make a final test. If it's all ok proceed to the final release.

Read and download this post on Scribd

Download The Woork Papers N1 | Structured process you must know to develop a web application

That's all. I hope this post can halp all of you which asked to me to add a post about this topic.
If you have suggestions to improve this process add a comment! Thanks :)

Related posts
- Structured process you must know to develop a web application
- Simple process to estimate times and costs in a web project
- How to manage a small web project: a simple approach
- Simple process to estimate times and costs in a web project
- The Deming Cycle: an application to web design

blog comments powered by Disqus
Rudy said...

Excellent post! Absolutely EXCELLENT!

webexpert said...

Thanks for this great post as always...

Hendri said...

Thank you!

Kaushik said...

Extremely informative and handy stuff Woork... as usual...

Jamie said...

Very useful, well-documented, and I appreciate the visual aides. Thanks!

Naeem said...

simply marvelous good job antoni

ThemeLib said...

Thanks for the awesome post.

Very useful!

Unique culture said...

I was looking for that information for a long time. Thanks!

Scott Radcliff said...

Nice post. This type of structure really helps break the entire process down into more manageable chucks. I don't always break the tasks down like I should. Therefore, I often make certain tasks more difficult than they need to be, and as you mentioned waste a lot of time doing things inefficiently.

I read this post at a perfect time. I was just taking a break from working on a project, and I probably need a little more planning to make the tasks a little simpler.

Greg Jorgensen said...

This is called the waterfall process or BDUF (big design up front), and is one of the oldest and most widely-used software development models.

Contrast waterfall development with the various agile methodologies.

The big problem with waterfall/BDUF, especially with clients/users not used to formal design processes, is capturing requirements completely and unambiguously. The requirements part is the hard part, but programmers generally wave that part away and focus on design and implementation.

Arnold said...

Of all the great posts you blog, this is probably the best!

Out of curiosity, what program did you use to create the visuals?

Antonio Lupetti said...

@Arnold: PowerPoint for Mac :)

William Pietri said...

A process like this can be better than no process at all, especially for people with very modest professional experience. But as Greg J. points out, this is one instance of the Waterfall process, and people should be aware of the drawbacks.

Phased processes in general, and this one in specific, have very high costs of change. That means you shouldn't use them if you are expecting to do anything innovative, if you are working in a volatile or fast-changing industry, or need to respond quickly to users, stakeholders, or competitors. It is also best at projects that get released exactly once before the team moves on. If that doesn't sound like your project, look into an agile method.

This particular phased process also includes no user research and no user testing. So it's most appropriate for things where user behaviors are very well understood (e.g., because you're copying a simple existing app) and the user experience does not matter (e.g., your audience are in-house users who don't use the app much and can be ordered to use it). If that doesn't sound like your project, consider an agile method plus a design approach like Cooper's Goal-Directed Design or Constantine & Lockwood's User-Centered Design.

Ralph said...

There are many nice ideas to improve the development of the webside-process. Thank you. Ralph

Anonymous said...


Mister Gingle said...

Thanks so much! that's exactly what I was looking for!

Andy Bright said...

Ah yes, I've lived with this kind of process for some time now.

I think main issue I have with it is that requirements documents almost are always wrong. Always our of scope etc. You cannot rely on them to get everything right at the outset, so you cannot depend on the spec as you go in with the rest of the project.

Still, I think it's a good and process with main merits, not least that in my experience it's well accepted in the industry and well understood by clients. I don't agree that it should always be thrown out and replaced with agile.

What we can do to add value is to incorporate agile methodologies along with quick and dirty user testing at the checkpoints where they can really make a difference.

For example, as you are concepting and developing your functional specification take the time to consider internally (or ideally by surveying real users on what they think) the impact and necessity of each feature you're adding.

Again, with the IA, iteratively develop enough fidelity into your wireframes that you may peform user tests with them. This way you can identify if your layout, taxonomy, etc falls in line with your users mental model and so on.

PLzAlliance said...

You are the BEST! :D

Doug McCaughan said...

This is a very good post. You have outlined a "waterfall" method of development.

I want to note that your 4th step "testing" should be singled out as "stress testing."

You cannot test quality into a product! Testing is not a stage. It must be an ongoing process. For instance, in your first phase "Requirements definition" if there was no testing you would be developing on a flawed concept. Many projects assume that because a requirements statement was given that it is correct and possible. If the requirements are flawed then the whole project will be flawed. For a web application, a common requirement flaw may be "under NO circumstances should an enduser be able to save or make a copy of the website." If we moved straight into design without testing the requirement/concept our analytical programmers might start wasting budget to develop javascript scripts to deny access to source, or Flash to prevent cut and pasting, or maybe writing the site as an AIR app in some convoluted way to prevent copying. However, many of these are easily defeated and none of these stop the user from taking a screenshot or photograph.

If testing isn't applied at each phase of development the cost to fix a problem increases exponentially with the amount of time spent waiting to discover the problem.

niheel said...

Useful, thanks for taking the time to put this together.

Janko said...

Very nice!

Nikhil said...

Great posts. Really useful. Thanks.

Aleksey said...

Waterfall! Very very risky approach with huge possibility to fall into scope creep. :o(

bollywood girls said...

i like your blog ....

website design New York City, web designer nyc, web site design, web design said...

Your blog is very nice

jones said...

Nice blog...
visit also coldfusion example

Yizi said...

Amazing tut there, keep up, more on CSS please.

Carsten Senger said...

As some stated this is a traditional approach to software development and testing has to be done continuously. My experience in web projects is that requirements are subject to change (a lot).

Unittest and integration test are a good way to ensure that the system is working as expected at any point. I run all tests every time I check in changes into my scm of choice. If I start to refactor parts of the project and a test fails I know that I introduced a bug, forgot something (Oops, also a bug) or the test has to be refactored too.

Going a step further is switching to test driven development. Write your tests before you write the implementation. While you write the test you can identify wrong design decisions and keep a better overview over the implications of the design and the cases that you have to test.

One might think it's a big overhead to write and maintain a lot of tests. But it's small compared to hunting down bugs introduced within the last weeks, manually clicking through a web interface all the time, testing forms with a bunch of possible inputs and so on. Unittests can't replace manual testing, but they cover a lot of the needed tests.

dorsey said...

excellent job by you.
you have explain every think very nicely. This is very helpful in Website design

blowind said...

heyy antonio

you always post great articles that make me smile

Nhat said...

Your website now in my bookmark. Keep good job

mikegrungey said...

thanks..for the great tips. I'll will follow woork guidelines. thanks

shireesha06 said...


MohammadReza said...

very very thanks man you are great!

Anonymous said...

As many have said, good definition of waterfall methodology, just it's generally proved to be ineffective for fast moving technologies like the web.

Like bridge building on a river with moving banks.

Lacks any of the flexibility of more agile methods.

Would love to see a similar walkthrough of more modern methods

kikis said...

Your blog is awsome. Thanks a lot. You gathered everything i needed!

Paul said...

Nice article.

paul said...

brilliant! well illustrated and totally methodical. makes sense!

  • Twitter Follow woork on Twitter
  • RSS Feed Subscribe to stay up to date
  • Podcast Coming soon...
  • 0 delicious lovers save
Share your links. Do you want to suggest any interesting link about web design or tech news? Submit your link.
Submit a News