In order to produce a successful system it is important to understand the development process. This page describes the high level development process to be used on our projects in order to provide a clear view of what can expected by all parties. The development process can be seen as a series of steps which can be represented by the following :
Requirements Capture. The Business Analysts work with the customer in order to capture their requirements.
Specifications Produced. The Business Analysts develop the specifications in line with the customers requirements.
Look and Feel Prototype. Raw HTML "look and feel" prototypes can also be produced at this time in order to enable the customer to visualise their requirements.
Specifications Reviewed. QA and development working together should review the specifications and the look and feel prototype with a view to their relevant needs. If there are problems raised either by QA or development then this becomes an iterative process and the BA will need to revisit the requirement's capture stage. If there are no issues then the documentation will be signed off by development and QA as suitable for use.
Specifications Signed Off. The customer is now required to sign off
of the specifications.
Development. Development should only start when specifications have been signed off by both Development and QA. Any development started before customer sign off must be considered disposable and would only usually be expected on a "times and materials basis". If this is carried out on a fixed price contract then it should be understood that any enhancement to functionality (deviating from original specifications) should be dealt with as a change request.
Quality Assurance. Quality assurance should only start when the specifications have been signed off by both QA and development. Any work carried out by QA before the specifications have been signed off by the customer should be considered disposable and would usually only be expected on a "time and materials basis". If this work is carried out on a fixed price contract then it should be understood that any enhancement to functionality (deviating from original specifications) should be dealt with as a change request.
Business Analysis. Once specifications have been signed off by the customer, business analysis will still continue. Any change requests will need to be added to the specifications and the specifications signed off again by QA, Development and the customer. Any problems or issues raised by development or QA as a result of development / testing may also lead to modifications to specifications which in turn may again will need to be signed off by all parties. Any disputes that arise between QA and Development as to interpretation of the specifications should also be settled by the BA this may or may not lead to clarifications to the specifications.
Development (Unit Testing). No software should be delivered to QA for testing without unit testing. It is expected that correct version control be maintained and that QA will not be given software with dependencies that prevent it working in their test environments. Development should not be carried out without the specifications being updated as this will lead to QA rejecting the work.
Testing (System testing). Any bugs raised should always be based on the latest specifications. Whether relevant steps to reproduce the problem along with relevant specification references will be included with the bug.
Customer Delivery. System delivery will take place when all parties agree that the software is either complete or that the current release is complete (and functional) enough for the customer to receive as part of a staged delivery. Both QA and development should sign basic release notes with every release (whether full or partial). Full configuration management will be in place and nothing will be issued to the customer without being archived, recorded and signed for by both Development and QA.