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:



Scope
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
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:

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:

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

Estimating time for Web Projects more accurately: Part 2

In Part 1 of this article I discussed the common reasons why underestimating times for web projects is such a common occurrence. In this part I describe how I personally go about compiling estimates in ways that reduce risk to the project, and your business, and increase the accuracy of the estimate, and thus overall profit.

Estimating projects and the occult

After reading Alyssa Gregory’s recent article on Sitepoint.com, How to Estimate Time for a Project, I couldn’t help but feel that it was a good introduction but lacked a little when compared with the realities and complexities of estimating/quoting for a website or web application.

“The Devil is in the detail: When people say that the devil is in the detail, they mean that small things in plans and schemes that are often overlooked can cause serious problems later on.” Using English.com

I may not believe in the Devil, but I do believe this statement to be as true as it gets when it comes to estimating time for web projects.

Estimating web projects accurately

Some would say this is an oxymoron, and to some extent I would agree, but I do believe by applying a few techniques it’s possible to drastically increase the accuracy of most web project estimates and avoid the feeling of wanting to curl up in the foetal position and whimper helplessly under your duvet.

Confirm a ball park figure

Before you embark on any detailed estimate exercise it’s crucial to immediately confirm with the client a rough budget, or budget range, they feel would be acceptable for an estimate. After all, if you get a new business lead, spend three days estimating and deliver a proposal worth £30,000 only to hear that the client ‘appreciates your response’ but only has £3000 to spend, you probably deserve to be struck with reasonable force in the baby-making department.

When you receive a project brief, throw some figures out there for the client to comment on, only one of a possible few things will happen:

• They will laugh and hang up when they hear your daily rate
• You will laugh and hang up when you hear they want Facebook for £4000
• They will say you’re in the right area but probably need to come down or go up a little bit
• They will refuse to feedback and say “We are open to suggestions”

For these possibilities what the next steps are need little explanation, but the “we are open to suggestions” answer is always the trickiest. In these cases it really is down to you to make a decision if the project is worth the risk of spending time writing a proposal and estimating for. It could be that the potential for new work is huge, or the client is extremely high profile and thus often it’s worth it, however, if you feel none of these are true, you should probably ask yourself what this statement says about the client and if you want to work with them.

It’s understandable a client wants to get their website or web application at the lowest cost, but the best clients are the most professional, experienced and ethical ones and simply know that not providing a rough budget range could waste theirs and your time.

Assuming you have made the decision to pursue the lead, you can now begin the detailed estimating exercise.

Consistent project phase breakdowns

Most web projects can be broken down into the following high-level categories:

• Research and planning
• Solution design
• Functional specification
• Web design
• Front-end development
• Back-end development
• Content entry

Each individual project will contain unique tasks, but most can be encapsulated in the above phases.

The first step to increasing accuracy of web project estimates is to make sure you always begin with a consistent set of categories and then add as many sub-categories and tasks as you like.

Get granular, then get more granular

Now your consistent high-level project phases are defined, it’s time to get granular and add sub-phases and tasks e.g.:

• Research and planning
  • Requirements gathering
  • Project planning
• Solution design
  • Sitemap
  • Wireframes
  • User workflows
  • Functional specification
• Design
  • Initial homepage look and feel
  • Content page
  • Master content page template
  • News main page
  • News item
• Front-end development
  • Template x5 XHTML/CSS
  • Cross-browser fixes
• Back-end development
  • CMS Setup and configuration
  • News feature
  • Contact us form
• Content entry

This full list of required project tasks can be created based on the pre-sales research you have conducted with the client. It is imperative to nail down, in as much detail as possible, what exactly the client wants before you submit an estimate or begin work.

The more granular you can get, the more you are forced at this early stage to think through each part of the project, literally designing and building the website or application from beginning to end in your head.

By going through the project step-by-step, putting yourself in the shoes of the information architect, the designer and all developers, will often immediately result in many issues rearing their head that you need to clarify before putting in an estimate, take the News feature for example. Ideally you could break each feature down as much as you can, so the News feature may actually end up looking like the following:

• News feature
  • Add/edit/delete new item
  • Upload image
  • Attach PDF
  • Auto-archiving
  • RSS

By resisting the temptation to just think “News… ummm… 5 hours” and breaking it down to this level means you’re mentally building the feature step-by-step and raising questions as you go.

So the client needs to be able to upload images to their news items, ok, but do they need:

• Auto-resize capability?
• Auto-thumbnail generation?
• Full-screen viewing?
• Caption addition facility?

I’m sure you can think of many more questions that could be associated with a simple upload image for a news item requirement. This demonstrates the possible scope variations that are contained within even the smallest of features and that could impact your estimates / risk of underestimating.

By getting granular and mentally trying to build the solution you are able to identify and address these issues early on, making sure to cater for them in your final estimate.

“A Web Project Manager knows how to design and develop most of the project on his own, even if with poorer results compared to his team. This allows him to estimate projects with good approximation and to understand his team’s problems and difficulties” Introduction to Web Project Management: Fucina Web

Granularity: Good for the client and good for you

Don’t forget, by getting this granular not only increases your estimations accuracy, but it also gives you the instant ability to remove proposed features quickly if your estimate exceeds the client’s maximum budget! Need to shave 10 hours off the budget? Well, rather than removing the News feature entirely, how about remove the thumbnail and caption adding functionality from News, and a few other small niceties from other features and still allow the client to have the basic versions of all the features they need? Simply remove the lines and hey presto, a new estimate at warp speed and with full visibility to the client of what functionality they’re sacrificing for budget.

Roughly guessing the News feature will take 5 hours is one thing, but what about when the client comes to you after seeing the initial functional specification and asks where the archive section is or how they attach PDFs simply because they assumed the News section they would be getting is like the News section on another website they’d seen?

Getting granular will not always allow you to breakout a required feature in full because it is client industry specific. If you are ever in any doubts about what the client needs, ASK THEM! Take the time to understand their business so that you can fully understand why they want the feature and how it needs to work.

Few clients mind you asking questions, if anything it tends to give them more confidence that you will continue to be as diligent and thorough if they hire you.

Best of all, if you win the work, by getting granular you have:

• An instant statement of work
• A defined project scope
• The timings you need to put together an accurate project schedule with milestones
• Set your client’s expectations very early
• Demonstrated your thoroughness and understanding of their business to the client

By being methodical, transparent and getting granular from the very start means your client is well informed and you’re seriously reducing the chances of friction later down the line.

You won the work w00t! Time to start tracking time

The more projects you complete that are categorised with a consistent set of phases and tasks, the more useful data you can collect on how long you estimated versus how long each phase or task actually took.

Consistency here is the key again. By this stage you should have the final project estimate that was approved by the client, and this estimate should be broken down first into the same high-level phases as your previous projects, and then at a granular level by task and sub-task.

Simply replicate this structure and the time estimates for each in your time tracking tool of choice so that you can:

• See how long you have to complete each phase
• View how long you have for each task and sub-task
• At the end, report on how long everything took

Not only is this a perfect way to track the progress of the project you are working on, but the data you collect over multiple projects, using a consistent pattern, will become more and more valuable when it comes to estimating future projects and also allow you to identify bottlenecks in your project processes.

Analyse project estimates vs. actual time spent

Once you have defined a consistent set of high-level project phases to use when estimating all web projects, and committed to setting up your time tracking tool each time to match, you are ready to reap the rewards.

By tracking all the estimated and actual times of all past projects, using a consistent framework, will give you an average percentage that each phase and task took, and you can use these averages as a good guide for starting a new estimate.

For example, by collecting data for your past five projects you are able to identify trends like:

• Solution design took around 10% of the total project time to complete and get approved
• Web design 30%
• Front-end development 15%
• Back-end development 30%

And so on…

Using these averages, and with a client’s preferred budget, you can begin to immediately allocate a rough amount of time to each phase and then break out each in more detail, but with the roughly allowed hours available known beforehand.

With this initial capped time limit in place, you can estimate not only your times but also the most cost-efficient solution you can deliver based on the budget rather than going in with a blind quote that may be way to small or too high.

Of course, this is dependent on knowing the client’s budget beforehand, not always possible, but more possible than most seem to think if you just explain you want to deliver the best solution for the budget given that you could potentially offer a News feature that costs £750 or £7,500.

Get granular with features, again!

Aside from being able to determine the average percentage of time each high-level phase usually takes of each project, you can take this tracking and analysis one step further.

How many websites or web applications tend to need a feature you’ve implemented before? Small to medium business websites invariably demand the following functionalities:

• News
• Press Releases
• Case Studies
• Events
• FAQ
• Contact us form

At the estimating stage you will have identified these requirements and broken them down as much as you can. Not only can you re-use these common breakdowns in multiple quotes, if you track the time for each one over multiple projects you will also begin to have average times it takes to implement or migrate each feature – now that’s useful.

In summary

The approach for estimating time for web projects I have described to you in this article works for me. It’s something I’ve developed over several years through trial and error by having to estimate web projects of all shapes and sizes in a small web agency environment, combined with a lot of good old fashioned hours of research.

Its methodical, it’s laborious, isn’t a guarantee that a project will not go over budget and I’ve no doubt is something I will continue to develop and evolve as time goes by. But as any web project manager will tell you, the more you plan, the more chance there is your project will be successful and the same goes for estimating times.

When possible, resisting the temptation to throw some figures onto a proposal and send it off and instead splitting the project requirements into as granular detail as possible can really be a life saver. It not only identifies possible grey areas early on but forces you to think through everything you’re planning on offering the client and to what extent/scope.

It also presents you to the client as someone, or as an agency, who are very meticulous, diligent and thorough in how they approach things and this is often taken as a signifier of how you will approach the rest of the project and this always gives the client confidence.

Finally, by creating and maintaining a consistent pattern of high-level phases and tasks between your web project time estimates and time tracking means you can collect and analyse reliable data from multiple projects that can help you further increase the accuracy of, and cut the time needed to create, estimates for web projects.

If you want to read why underestimating web projects is such a common occurrence, please check out Part 1 of this article »