Close
Web application development is a complex project involving a multitude of stakeholders who all have a hand in shaping the final application.
To make this process run smoothly, a certain amount of co-ordination is required and that's what's detailed in this article.
A web application is simply a computer application that's designed with Internet/intranet access in mind, with the additional caveat that it's built using Internet technologies such as Flash, Java, HTML, Javascript, etc.
Careful consideration must be paid to which technologies are used as each stakeholder will have their own requirements and these could be met or excluded by those choices.
Our choice is to use open technologies and build to standards so your web application will continue to work now and for years to come.
If you have a requirement for a specific technology (e.g. Flash, .NET), you can choose to have them incorporated but it could commit you to 'lock-in' (where you'll need to accept any conditions and changes that technology provider dictates).
When people come to us looking for a web application, they usually lie somewhere on a spectrum of experience:
Regardless of where you lie on that spectrum, we can help.
A specification or 'spec' for short, is the essential information any developer needs to create your application. It's effectively all the information that's currently inside your head, formalised into a number of documents.
A spec is also vital for accurate quotations of your application and how long it will take to create. Anyone providing you a quote without a spec is only guessing and is more than likely to only care about parting you with your money.
Without a high quality spec, the risks you face are:
Anything from a simple brochure website to a complex web application like Facebook will require a spec. How detailed that spec needs to be depends on the sophistication of that website/application.
Now you know what one is and how useful it is, let's look at how we produce one.
A stakeholder is anyone that has an involvement with the application. These are often (but not limited to):
A stakeholder can belong to one or many categories though we'll find that the smaller the company, the more categories a single stakeholder will belong to.
Whilst it's not always possible to obtain input from all stakeholders, it's very important to consider all needs if an application is to be successful in deployment; critical functionality missing for an important stakeholder can derail the project at the final stages.
Initially, we request any available information to be forwarded to us as a starting point.
From here, we'll arrange a series of meetings to produce a spec.
The purpose of these meetings is to find out exactly how your application works. Working with you, we'll capture and formalise the information required to produce it.
Should you no longer wish to continue development or you'd like to find out a fair market rate to develop your application, the spec documentation we produce can be taken to any development company to obtain an additional quote.
During our meetings, we will capture all the information required to build your application.
To do this, we will go through how your application should work, page by page and produce a number of design documents.
This information is initially captured on paper and pencil. Despite being centuries old, the paper and pencil is still one of the quickest and most efficient way to capture this information.
Now that we've captured all the information, we need to ensure our interpretation of that information is correct. We have two options:
The basic HTML model provides you with a series of web pages that show how your application will look on a screen by screen basis. This will satisfy most requirements where functionality is limited or basic. Where design is more complex, an Interactive model will be required.
The Interactive model will allow you to navigate the site, almost as if you were using it. Naturally there are limitations on the interactivity as it's just a model.
This process is lengthy and can take around 1 day per page to spec and one day to model but it's importance can't be stressed enough. Without a model, misinterpretations during the spec'ing phase won't be discovered until the application is fully built and complete.
Once a spec is finished (i.e. all the data captured to build the application), you'll be asked to 'sign off' on it. This simply means you accept the spec and that it will produce an application that will work as you expect. At this point, no further changes will be possible without resulting in delaying the completion date and adding more expense.
Once we have your spec, we will produce a quote to tell you how much it will cost you to build.
We're also happy for you to take the spec for a quote elsewhere as this keeps us fair or you may have a trusted developer you prefer to use.
When we start building your application, you'll have fortnightly updates on how it's proceeding.
On rare occasions we'll need to ask you for additional input but otherwise, there'll be very little for you to do until the application is finished.
Once completed, there will be a testing phase. During this period, the application is put through it's paces and any issues rectified.
When an application is finished you will have 1 month of active maintenance. This means any bugs found in this period will be fixed at no cost. After this period, you will need a support contract or pay at a per-incident charge.