How to compare Web Application and Normal Software Project

Sr.

# What are we going to build?

# How does it compare to products currently available?

This is typically supported by a detailed requirements specifications.

# We need to get this product out now.

This is purely driven by available time window and resources.

# How long will it take our available resources to build this product?

# How will we test this product?

This typically involves experience-based estimation and planning.

# How should the site look?

# What kinds of logos and graphics will we use?

# How do we develop a ‘brand’ for our site?

# Who is our ‘typical’ customer?

# How can we make it usable?

# What technologies will we use?

This involves short, iterative cycles of design moving parallel with implementation activities.

# What technologies should we use?

# Any designpatterns we should follow?

# What kind of architecture is most suitable?

This is mostly based on well known technologies and design methods. This is generally complete before the implementation starts.

Let us put in the framework and hang some of the key features. We can then show it as a demo or pilot site to our customers.

This is Iterative prototyping with transition of prototype to a website.

Let us decide on the sequence of building blocks that will optimize our integration of a series of builds.

This involves sequential development of design components.

This phase typically does not exist. It is a point in time when prototyping stops and the site goes live.

# “How does the product begin to take shape, as the constituent pieces are bolted together?

# Are we meeting our requirements?

# Are we creating what we set out to create in the first place?

This involves assembly of components to build the specified system.

# Do you think – It’s just a website – the designer will test it as he develops it, right?

# How do you test a website?

# Make sure that all the links work properly?

This involves testing of implied features based on a general idea of desired functionality.

# Have we tested the product in a reproducible and consistent manner?

# Have we achieved complete test coverage?

# Have all serious defects been resolved in some manner?

This involves systematic testing of functionality against specifications.

# “Go live NOW! We can always add the rest of the features later!”

This involves transfer of the development site to the live server.

# Have we met our acceptance criteria?

# Is theproduct stable?

# Has QA authorized the product for release?

# Have we implemented version controlmethods to ensure we can always retrieve the source code for this release?

This involves building a release candidate and burning it to CD.

# We just publish new stuff when it’s ready.

# We can make changes on the fly, since there’s no installation required.

# Any changes should be transparent to our users.

This is an Integral part of the extended development life cycle for web apps.

Average timeframe for the above can be around 4 months

# What features can we add for a future release?

# What bug fixes?

# How do we deal with defects reported by the end-user?

This involves periodic updates based on feature enhancements and user feedback.

Average timeframe for the above can be one to three years