In order to provide value for money and a return on investment from the funders there is a need for project deliverables not only to be functional in their own right but also to be widely accessible, easily repurposed and deployed in a service environment.
To achieve these aims projects should ensure that their deliverables comply with appropriate standards and best practices. Although it may be easy to require compliance, it may not always be easy to implement appropriate standards and best practices. In order to ensure that best endeavours are made it is recommended that projects should implement quality assurance (QA) procedures.
Projects may be concerned that implementation of QA procedures can be time-consuming. The approach recommended by QA Focus is designed to be lightweight and to avoid unnecessary bureaucracy, while still providing a mechanism for implementation of best practices.
The QA Focus methodology is based on the following:
It is felt that use of this methodology should not only be beneficial to the projects themselves, but also help to minimise problems when project deliverables are re-used.
As an example of implementation of this approach the QA policy for standards for the QA Focus Web site is given below.
Area: Web site standards
Standards: The Web site will be based on the XHTML 1.0 and CSS 2.0 standards.
Architecture: The Web site will make use of PHP. XHTML 1.0 templates will be provided for use by authors, who will use simple HTML tools such as HTML-kit. Web site will provide access to an MS Access database. This will also comply with XHTML 1.0 and CSS 2.0 standards. The Web site will also host MS Word and MS PowerPoint files. These documents will also be available in HTML.
Exceptions: Resources converted from proprietary formats (such as MS Word and PowerPoint) need not necessarily comply with XHTML and CSS standards if doing so would be too time-consuming.
Responsibilities: The QA Focus project manager is responsible for changing this policy and addressing serious deviations from the policy.
Checking: Resources should be validated when they are created
or updated usually using the ,validate
tool. When several
resources are updated the ,rvalidate
tool should be used.
Audit trail: A full audit should be carried out at least quarterly. The findings should be published on the QA Focus Web site, and deviations from the policy documented.
A second example describes the QA policy for link checking of the QA Focus Web site.
Area: Web site: link checking
Best Practice: There should be no internal broken links and links to external resources should work when a page is created. We should seek to fix broken links to external resources. Exceptions: There may be broken links in historical documents or surveys. In addition, if remote Web sites are updated it may be too time-consuming to update the links.
Change Control: The QA Focus project manager is responsible for changing this policy and addressing serious deviations from the policy.
Checking: When resources are created or updated the resource
should be link-checked, usually using the ,checklink
tool. When several
resources are updated the ,rchecklink
tool should be used.
Audit trail: A full audit should be carried out at least quarterly. Initially two tools should be used to spot deficiencies in the link-checking software. The findings should be published on the QA Focus Web site, and deviations from the policy documented.
These two examples illustrate that developing QA policies need not be time-consuming. In addition implementation of these policies need not be time-consuming and can improve the quality of the Web site.