EmailName :     Password :         [BAN]  [END]
FORM SELECTION BAR - Please navigate directly to your form
Company : 
Goto: Help Page Form Search  :      

Golden Point Software Development

Introduction

This page anticipates that you are planning to build a Web Application (webapp).

Golden Point Development is the process which IT Form Developer uses to design and project manage the creation of new webapps.

The information provided here is general advice which is directed at our clients. It may not be universally applicable.

Please contact us if you need clarification or advice.

Creating a Web Application

For convenience we classify web sites as:

  • Business Card - A static web site with a small number of pages and fixed information which needs updates very rarely. It takes days to develop and requires little ongoing maintenance.
  • Basic Web Site - A static web site with a medium number of pages whose content may require to be updated by administrative staff on a daily basis. It takes weeks to develop and requires little ongoing maintenance.
    A number of content management packages exist which can be used to allow people who are not trained in web design to update a web site. We are developing a simple web content management system using plain XML files which we would encourage you to consider.
  • Web Tools - Single page tools which add dynamic elements to a static web site in order to provide some functionality. Web tools take weeks to develop.
    IT Form Developer now provides the ability to rapidly create online web tools and forms which can quickly add dynamic content and help to manage administration.
  • Web Application (Webapp) - A dynamic web site normally linked to a database which performs a dedicated activity for the public or business. It takes months to develop and requires both a developer and an administrator to maintain and run it.
  • Enterprise Web Application - A dynamic web site which integrates directly in the IT operation of the company. It takes a number of staff years to develop and is seen as one as part of an integrated IT policy.

Some features of a Web Application include:

  • Dynamically created content.
  • A high degree of interaction with the user.
  • Usually includes an account into which the user has to log in.
  • Dedicated to a single business activity.
  • Is standalone.
  • Written in a web programming language.
  • Has a database back end.
  • Requires an administrator to run it and a developer to maintain it.
  • Normally has a significant number of pages hidden to the public which help with administration.

How much will the development of a Web Application cost?

The development of a dynamic webapp: user driven, with a database back end and which will be completed by a single developer within a time span of around 3-9 months.

Initially you will be shown a comparably sized project and given an indication of the cost and time to completion. A cost quotation will then be given for the development of a User Requirements Documentation only. Once your software requirements are clear, the information in the User Requirements documentation can then be used as a basis for asking for a quotation to complete the work.

You may anticipate a cost in the order of £9,500 to complete a three month project. Once a project is complete: it is important to understand that the site will require administering and that there will be ongoing costs to discuss associated with maintaining the software.

Having accurately stated your requirements, the size of the project or the technologies which you wish to use may mean that it's inappropriate for IFD to continue with the project. Naturally we hope that is not the case. However having assistance in drawing up a User Requirements document will mean that any subsequent bids which you receive will be properly informed.

Development roadmap

The aim of the 'Golden Point' development roadmap is to ensure that there is a clear understanding between the client and the development team about what exactly is required. When creating software it is also important to provide an indication that progress is being made and the milestones deliverables are a way of demonstrating this.

There are eight stages each with clearly defined outcomes. The stages are:

As each stage of the process is completed it is signed off. This allows for the process to be suspended after any stage. The road map also incorporates a dynamic time line which gives a time scale for the completion of the project.

The 'Golden Point' is the point at which both parties are mutually confident that each understands how the software will appear and what functionality it will contain. The reason that the 'Golden Point' is so important is it marks the line between the design and the development. Changes are easy to incorporate into a design. However once the design has been completed and the development has begun, making changes 'on the fly' will only lead to expensive and poor quality software.

Analysis and Design

Software analysis and design is about producing a concise definition of the software. It is also about looking at the big picture and creating a long term plan. Its aim is to ensure that both parties understand the software which is about to be produced.

The design doesn't start with a blank sheet of paper. It is the formal description of an idea which has already been formulated. Ideally the client will have a business process for which they wish to produce a piece of software and they will be able to describe to the developer both the business process, and anticipate the software solution.

In the worst case scenario a client will start by not have a very clear understanding of either the process being modelled or have any expectation of the software. In this case more work will be required in the analysis stage to ensure that the client actually does have a requirement to produce software.

The relative amount of time spent in analysis and design compared with development will depend upon the nature of the project, however what is clear is that well designed software is easier to write and maintain. Please bear in mind that; design is cheap, code is expensive.

This process employs Unified Modelling Language (UML) which is the standard for software design.

1. Analysis

Future Proofing

It is crucial to understand that designing new software is not done in increments. As many as possible anticipated uses of the software are considered at the outset and written in to the user requirements document so that the ability to include future developments can be incorporated in the design.

An analogy is helpful. Imagine that you ask an architect to find you a plot of land and build you a house. If you don't mention that you may later want to build a large extension, garage, green house and swimming pool etc. then you risk discovering that you don't have sufficient room to build these additions.

Please be aware; if the requirements significantly change and an application has not been properly planned then the software may have to be completely rewritten.

While the benefits of writing software become clear in the long term there is often pressure for results more immediately. Having milestone deliverables helps to indicate that progress is being made, but it is often noticeable that people are happier once the software has started to do something productive.

Although in the design process we are making a 'grand plan', the software itself will be modular. This means that as part of the design process we can identify which modules need to be written first. In some cases this decision will be determined by programming issues but at other times it can be driven by business requirements. Consequently within the design we hope to identify area's which are easier to build and will make the biggest impact on the efficiency of the business - all with a view to providing 'a quick early result'.

The Nominee

Many web sites fail because they are designed by committee. This is because what constitutes a 'well designed web site' is partly subjective. For that reason, in this process, one person - 'the Nominee' - is nominated to manage the project and represent the requirements of the client to the developer. A wide range of opinions should be canvassed as the user requirements are gathered and analysed. However the final decision about what should be done in any situation becomes the responsibility of a single person, the Nominee.

Testers

A further common issue is that many webapps are not properly tested. It is useful to start by creating a list of designated testers who will be formally consulted throughout the development process. This step is also helpful because it makes a wider group of people directly involved and encourages a sense of collective ownership for the project.

Background

Before starting the analysis it is useful to gather background information which will be helpful to the developer and may have a bearing on the design. Information which will be required includes:

  • Addresses of web sites to reference.
  • Templates from an existing web sites.
  • Content for the web site.
  • Test data.
  • A business plan.
  • Corporate advertising and logos.
  • Any relevant standards.
  • Details of existing hardware and software.
  • Information upon the platform which you are using.
User Requirements Documentation

The analysis begins with a detailed written description of the user requirements. This should take the form of a simple list of ideas and issues - where any descriptions of processes are dealt with as a list of steps. Creating the User Requirements is simply a process of 'thinking out loud.' Because is an iterative process it is fine to just write down the information as it occurs - initially in the a form of wish list - and then gradually re-organize and revise it as the structure appears. As the document begins to take shape it should be expanded by including input from consultation with the test group.

Once the Nominee has made an attempt to express the ideas and requirements there will be an interview with the developer and the User Requirements document will be jointly revised. If necessary, as a result of the interview, the process of user consultation and revision is repeated.

The purpose of the User Requirements documentation is to clarify what the requirements are and to solicit input about what is needed from a wide group of prospective users. Later, during the testing stage, the User Requirements will essentially be used as a check list to ensure that all expectations have been met.

The User Requirement document can be updated through out the analysis and design process so that the document reflects the current thinking about the project. Changes can be made up to the 'Golden Point' and the code starts being written.

In describing the User Requirements there are a number of broader issues which should also be addressed.

Content Generation

Content, content, content; never underestimate the importance of content when creating a web site. For a webapp content refers to any information, text or images, which is not directly produced by, or related to the software. The relative amount of content will vary considerably between webapps. For example, a publicly facing web site which aims to provide up to date information will need to generate a lot of content. In such a situation if the web site is to succeed the information must be accurate, well presented and entertaining. Creating such high quality content requires a degree of skill and is time consuming. In any situation it is important not to underestimate the production of content; to consider who will produce the content and how it will be generated.

Projected Uses

When considering how the application will be used don't forget to include how it may be used in other parts of your organisation. This may in itself be enough to justify the decision to build the software. Similarly you should also consider the potential of licensing the software which you find useful to other parts of your industry.

Report Generation

As a manager it is important to recognise that information which may previously have been captured on paper or in word documents etc. will be going into a database. Gathering information in a database allows you to run queries and generate reports, providing you with more scope to analyse how your business is running. Often the benefit of this information only becomes apparent after the event. If you take time to consider the sort of queries which you would like to make at the analysis stage these can more easily be accommodated in the design.

Existing Data

When a work process is transformed into a web application there can often be a requirement to bring existing information into the new system. In practice the process of pre-populating a database with existing information can be a time consuming activity. Consequently it is important to consider how the transfer of data will impact upon the size of the project.

Existing Systems

A single standalone application can be hosted on a commercial server. For a small monthly fee you are provided with the platform, hardware and maintenance which is required to run your application. This is a simple cost effective way to operate. On the other hand you may already be running your own servers and prefer to have complete control of the application. For example you may not want sensitive data to be held on an external host.

A related issue is the impact and pattern of usage that your business traffic will make on the web server. Ideally you require high numbers of repeat users making short and infrequent visits.

Consideration also needs to be given to the technologies which are already employed within the organisation. Using the same technology across an organisation allows the development of enterprise applications; it also reduces costs and the skill set needed by your technicians.

Enterprise Applications

If a number of databases exist within your organisation the current trend in information technology is to allow the transfer of information between the different applications. This technique brings a number of significant benefits to how an organisation operates and the way that it is perceived.

Administration

It is important to understand that the new software will require administering and that there will be ongoing costs associated with maintaining the software. These overheads may be offset by improvements which the new software brings to the way in which you are working. However consideration should be given to who will be responsible for managing the running of the live webapp and particularly what skills they will require to do so.

Risk Analysis

It is important to bring the consequences of a failure of the code or Internet going down to the attention of the developer as soon as you realise that there maybe a problem. This includes the impact that the failure of the webapp has on all other work processes. A risk analysis can be performed and a time table for dealing with the perceived problem drawn up. It is far better to anticipate problems and incorporate the solutions in the design then it is to rectify problems as they arise in the working application.

Confidentiality

If you wish to keep the information which you are sending across the Internet transparent then you may wish to consider using a secure server or some other form of encryption.

Off the shelf solutions

Don't re-invent the wheel. Having written a fairly detailed description of the requirements it is useful at this stage to have the developer considered whether any 'off the shelf' products are available for you to use. There is a wealth of software which is either free or can be used under license. If you do find a 'ready made solution' you may then want to start tailoring the software to meet your more specific requirements.

UML - Unified Modelling Language

Any functionality that will be included in the web site is highlighted in the User Requirements. This is used by the developer in the production of UML use cases and scenarios. These are diagrams which document and flesh out the specific functionality and form the basis of an agreement about what the system will do and how it will do it.

Requirements of the nominee:

  • Significant input into the User Requirement document.
  • A list of designated testers.
  • Reference web sites.
  • Existing web site templates.
  • Web site content.
  • Test data.
  • A business plan.
  • Corporate advertising and logos.
  • Relevant standards.

Outcomes :

A User Requirements document which includes :

  • A revision of the Users Requirements.
  • A description of key functionality as use cases with scenarios.

2. Design

Formal Design

The information which has been gathered during the analysis is now formalized by the creation of a number design documents. Unified Modelling Language (UML) is an industry standard which provides a number of diagrams which may be used according to the circumstance but perhaps the two most useful designs to create are class diagrams and a database schema.

The design documents are largely of benefit to the developer as they form the blue print which the programmer will follows once they begin coding.

Design documents will often highlight problems before they occur. They also provide important documentation when the code is being maintained or extended later. They can save time because tools exist which will translate the diagrams directly into a code framework.

In the design stage the nominee will often be asked to provide clarification about terminology and the definition of different roles.

Storyboard

A tool commonly used in the design of a webapp is the storyboard - which is a paper 'mock up' illustrating the proposed layout and structure of the webapp. The story board gives a broad pictorial impression of the webapp and is particularly useful for; getting an impression of issues such as 'where things will go,' how the site will navigate and giving an indication of the number of pages which will be required etc.

Outcomes :

  • Class diagrams and database schema.
  • A story board description of the webapp.

3. Prototyping

A prototype is an early demonstration version of the software which contains little or no functionality. Prototypes are useful because they give a good impression of the finished software, in particular the appearance and navigation of the user interface.

The content of a static html web page is fixed, whereas the content for a web page dynamically created by a webapp is determined by the choices made by the user. Because static web pages do not contain functionality they are easier to construct. This makes static web pages suitable for creating a prototype.

A web page template is created which illustrates how the layout of each of the pages will appear without any content or functionality. Many other static layout and navigational issues can be resolved e.g. how you navigate menu bars, the use of fonts, style sheets, screen size issues, browser compatibility etc.

The finished template is used to create the pages which were identified in the design and these pages effectively create a prototype of the application. The prototype presents a version of the whole webapp in which the structure and navigation have been completed. At this stage graphics may be place holders or part finished. Any functionality - getting the software to actually do anything - is 'faked' in order to give the impression to the Nominee and Testers of 'what might happen.'

Using a prototype is an excellent design tool. When creating web based software the prototype pages are reused later when the static pages are transformed into the dynamic web pages.

The prototype will be built online so that it is continuously available for inspection and comment. When the process is complete it is appropriate to ask the nominated testers provide their feedback.

During the prototyping stage the nominee should provide continuous feedback upon the developing prototype and the results of the survey from the nominated testers.

Outcomes :

  • A prototype html framework of the webapp which allows the user to see how the webapp will look and feel, and also appreciate the how it will function.

4. The Golden Point

The Golden Point
The analysis and design is now complete.

The aim of the process so far has been to describe the software and ensure that all parties understand how the software will appear and how it will work. If you feel that this is not the case it is still possible to revise the design.

Up to this point the analysis and design has been a relatively fluid, iterative process. Changes to both requirements and design occur as problems are identified and new functionality added. In the development stage the work has a fixed form and so changes become much more difficult to make.

5. Development

Under normal circumstances the development - actually writing the code - will be the longest part of the cycle of development. Note however - that the development time will be significantly shorter if the analysis and design has been done properly.

A live version of the new application will be put online immediately. Changes to the site will occur in small only increments. However developing the system online will enable the nominee and the testers to view the changes as they take place. Milestones will be indicated by emails.

During the development stage the nominee should be aware of the progress and provide ongoing feedback upon the developing webapp.

Outcomes :

  • The development of dynamic web pages and the associated classes.

6. Testing

It is important that the software is rigorously tested. Rushing to release buggy software will only alienate the user.

Test framework

There are a number of tests which can be carried out on web pages and the aim is always to automate the testing process as fully as possible. To this end as pages are created they are included in a testing framework. This framework is used in the development of the code. As new functionality is added, the framework is run to ensure that the already existing code is not broken by the changes. Later, when the application is live, the framework can continue to be used as a means of checking that it is functioning properly.

For the developer there are some tools which automate the checking process; a HTML doctor ensures that the HTML which is produced is correct. A HTML conformance validator will ensure that the HTML and CSS meets with the relevant standards. To a degree these checks future proofs your webapp.

The HTML produced is written for the latest versions of Internet Explorer and Firefox at a screen resolution of 1024*800 screen resolution. A check should be made that the code behaves reasonably consistently with other resolutions and web browsers.

Nominee testing

Once the system is complete, and before it goes live, the webapp should be tested to ensure that it works properly. This involves the testers using the webapp for the full range of functionality for which it was intended and also seeing how the system copes when the testers try and 'break' it by entering unusual sequences of actions or values.

The testers are testing the webapp to see 'if it works' not 'how it works.' For the testers there should be no surprises about 'how it works'. This should already be clear to them because of their involvement in the design process. If during the testing stage people are not happy with 'how it works' then the design process has failed.

The webapp should then be run in parallel with the existing live process for an agreed upon period. Once you are confident that the application is sufficiently robust the testing can be signed off.

7. Implementation

Documentation

Documentation has to be provided for;

The Users who will be able to refer to:

  • A per page inline help option.
  • User online help pages.

An Administrator who will be able to refer to:

  • Administrator online help pages.

Future Developers who will be able to refer to:

  • The design UML.
  • Development issues which are highlighted in both the code headers and at the relevant sections of the code.
  • Code documentation. Both php and java code is documented according to the Javadoc convention. This means that hmtl documentation can be automatically generated for the code.
  • In the case of an emergency a brief document containing passwords and important contact details etc. should be produced for local storage.

If more information than this is deemed necessary, rather than create a rich document about 'how the webapp works', a series of examples which run in a media player can be used to take a new user through the important functionality.

Training

Most people are now familiar with entering information in to webapps on the Internet. However some training on using any unusual features may be necessary for power users locally.

Training will almost certainly be required by the person whom you intend to administer the webapp. The webapp produced has a dynamic nature, which means that it will normally be linked to a database. The project will usually contain its own secure customized administration interface which mediates between the administrator and the database. Alternatively the database could be directly accessed using a package such as phpAdmin.

The administrator should have a basic understanding of how a database is maintained and is able backup and recover any data that is lost. This may be a task undertaken by the web host.

Outcomes :

  • Online documentation and administrator training.

8. Support

Please be aware that once the project is live a commitment will still have to be made to administering and maintaining the webapp.

Bug fixing

All software has bugs. Agreement needs to be reached about who will fix any webapp software problems and timetable needs to be created for how soon they will take place.

Version Churn

Software is progressively updated as bugs are fixed and new features are added. Periodically after major changes have taken place a new version of the software is deemed to have been created.

Unfortunately web technologies rely on the interaction of a number of different technologies and when new versions are released existing software is not always guaranteed to continue working. For example if in the past you changed from Windows 95 to Windows XP you may have found that not all your windows programs were certain to work. This situation is know as 'version churn'.

If you are not responsible for maintaining your own web servers this could lead to your webapp suddenly failing because your web host has run an upgrade. When running webapps it is important to know what version of software are being run on the web host and to receive notification of changes prior to the new version being released.

Testing

The test framework which was developed during coding can continue to be used when the site is live to ensure that the site is working correctly. When the testing software is run each page on the site is visited and the content returned checked against expected values. This means that many problems can be discovered automatically.

IT Form Developer : Rapid form creation, data capture, information tracking & work process development.

IT Form Developer is simple to use and has the potential to transform your business.
Please contact us and find out exactly how we can help you.
Browser icons [TOP]