Technical Reviews and Audits

Brief Summary
Reviews will always be scheduled in the project/product Quality Plan, advertised well in advance, fully minuted and all actions completed before any review is regarded as being complete. Audits serve as a check on the system in place. Technical audits will be concerned with ensuring that the work done matches previously reviewed project/product documentation, and will be detailed and comprehensive. Reviews and audits often involve the discussion of a written document. It is important to avoid confusing the quality of a document with the quality of its contents, and the procedure for conducting any review should explicitly recognise this.

Intro
Reviews and audits are similar mechanisms with two quite different aims. They are considered together here because both involve independent objective assessment of work done. Both require careful preparation and a positive, constructive attitude by all of the parties involved. The following guidelines are just that; there is no substitute for commitment, careful preparation, insight, diligence, and common sense in any assessment process.

Reviews
3.2 Reviews Reviews are planned and controlled checks of progress or conformance against plans or specifications. Reviews can be of a number of distinct types, which should be clearly recognised: Reference Document Reviews, Technical Reviews, Planning Reviews. Reference Document Reviews will be concerned not only with document content, much of which may have been previously reviewed on a purely technical basis, but will also be concerned with such topics as adherence to COMP345 documentation styles, artwork, clarity, consistency, glossary, level of readership knowledge, examples, ease of use, and general appeal and utility to potential users. Technical Reviews should ensure that all work is independently evaluated through an acceptable review procedure at clearly defined stages in the development process. These will be specified and scheduled in the project plan, and will usually be based on technical documents through most of the development process. There must always be a formal evaluation of a piece of work after it has been implemented. This should include static checking, some form of code walk through, and a demonstration that the work meets its requirements, and that all formal project obligations have been met. Planning Reviews should recognise the close coupling which exists between plans and requirements: the question of trade-offs between available resources and requirements will probably continue throughout most of the project. This presents potential problems in that project plans and requirements are usually reviewed separately. Planning reviews must ensure that the proposed project deliverables are always consistent with the planned timescales and resources. It is important to recognise that plans frequently change, with the consequence that replanning needs to take place. Any such re-planning must always be conducted on a realistic and pragmatic basis there is no place for misguided optimism or the belief that things must get better! Significantly revised plans should always be reviewed and audited.

Audit
3.3 Audits Audits are planned and controlled checks on the quality of work done within the COMP345. They should always be conducted by senior staff, with a view to revealing weakness in existing procedures, seeking to identify danger signals and potential trouble spots. Audits are not bureaucratic exercises used to demonstrate conformance to standards (internal or external), rather they should be seen to be insightful and supportive activities aimed at constructive improvement. Audits should be planned to provide useful coverage, without getting in the way of the activities being audited. Often they will be planned well in advance, though they may take place at very short notice in response to particular difficulties a project or product is facing. For a large project, work at all stages, usually delineated by project milestones, must be audited. All audits must be approved by the Quality Manager, who is responsible for ensuring fair, objective and adequate sampling of project activities. Audits should be used in small projects as an effective way of confirming that requirements have been met. Project audits are needed to ensure that documentation matches work done, that reviews are being based on an accurate description of the task in hand, and that work meets accepted documentation standards. In particular the following areas should be addressed: code against design documentation, interface specifications, design implementation and test descriptions against functional requirements, and functional requirements against contractual/product requirements. After any module implementation and test activity, there must be a final audit prior to internal delivery to the integration and build team, to ensure that all requirements have been met. There should always be a pre-delivery audit of a product before it is handed over, in order to verify that the software, the user documentation, and all the provisions for maintenance and support are internally consistent, are ready for delivery and are in accordance with any contractual requirements. After an audit, the findings will be presented to the relevant project manager, and decisions made on the nature of any corrective action required. An audit report will then be produced and added to the project file. It is the responsibility of auditors to check that remedial action has been taken, where it was actioned, and report progress, or lack of it, to the Quality Manager. An audit is not deemed to be complete until all agreed actions have been taken, and a satisfactory (for all parties) situation prevails.