What are Quality control and quality assurance? These two topics have very similar terms but different practices and meanings. These subjects apply to both classic waterfall project management and Agile methodologies.
We now discuss how the quality criteria of a product created by a project are checked. Ideally, the project takes place in an organization committed to quality with standards already in place for certain activities. If this is not so, part of the project set-up will be the creation of the framework for managing quality.
The following are examples of good and bad quality criteria:
- All screen layouts should have similar layouts and use the same terminology.
- Screens should be user-friendly.
- The system should be able to handle 50 transactions.
- The system should allow for 20 users at any one time without degradation.
- The response time should not be longer than three seconds.
- Comment on the effectiveness of each of these quality criteria.
Defining Maintainability and reliability in project management plans
Maintainability is defined as a quality characteristic. How can it be measured?
How can the reliability of a system be measured?
An organization that carries out many similar projects can usefully develop organizational standards for product definitions and quality practices applicable, with appropriate adjustments, to all its project work. This quality framework is called the quality management system (QMS). It may be based on the ISO 9000 series of standards.
Within the QMS, there will be a quality strategy and quality assurance processes. They are reviewed and, if necessary, modified to meet the specific requirements of each project.
Read more in our Quality Management in Project Management and Agile practices article.
Quality management system strategy
A quality strategy defines the QMS and includes:
- procedures and standards for creating a project quality plan;
- definitions of quality criteria;
- quality control procedures;
- quality assurance procedures;
- a statement of compliance with or allowed deviation from industry standards;
- acceptance criteria;
- allocation of responsibilities for defining or undertaking quality-related activities.
The methods for exercising quality control are discussed later, but generally these are either practical tests or a review.
Quality assurance stands alongside quality control but is external to it. Quality assurance is an audit to confirm that proper procedures are in place and applied correctly. The correctness of a software component can be verified by running tests and checking the results. That is control. Assurance would involve checking that the testing has actually been done by looking at evidence such as copies of the expected and actual results of testing.
Quality control and project team’s work
Quality control would normally be an integral part of the project team’s work. The quality assurance activities, on the other hand, are usually carried out by people outside the project team who report directly to the steering committee/project board. This separation of responsibilities helps to ensure that the process is transparent and reduces possible conflicts of interest.
Quality criteria are specified for each component. As each component is completed, a control process is undertaken to ensure that the criteria have been met. This is followed, at an appropriate time, by an assurance process which confirms that the agreed procedures have been followed and that all products have undergone the necessary checks.
Systems development life cycle has a number of stages – for example, requirements analysis is followed by systems design, followed by construction and testing. Each stage contains quality control processes, usually reviews, and a quality assurance process takes place at the end of each stage. If proper quality control is found to be lacking, corrective action may be mandated. The quality control and, if necessary, the quality assurance processes are repeated until the quality criteria are met.
The creation of a quality plan is vital to the success of a project. It specifies the particular standards that apply to the project. Ideally, they should be taken from existing organisational standards. These in turn may derive from industry standards. However, modifications to organisational standards may be needed because of the special characteristics of a project.
The plan also specifies how, when and by whom the quality control activities should be undertaken, the quality assurance processes to be followed and who will carry them out. It may also include configuration management and change control procedures. The quality plan itself is subject to quality control and quality assurance processes.
It is common for the quality plan to be integrated with the project management plan. The BVOP suggests a quality control process in its project management certification program.
Quality control of software products tends to use testing to establish the quality of deliverables to the client, and reviews for the intermediate products such as requirements, specifications and design documents. Software can be subject to both testing and review.
The V model
The V model is a useful model of the systems development process, in which the solid lines represent the forward progress of the project and the dashed lines represent the way in which quality control is exercised. PMA (Project Management Academy) presents detailed practical exercises in their project management course so every project manager should be prepared for this topic.
There are two quality control processes at work: one between stages and the other across the V. For example, the requirements specification describes the functions and quality attributes required in the system. This should include an acceptance test plan showing how the requirements are going to be assessed in the final system.
Using the acceptance test plan, testing can be undertaken to demonstrate that the final system to be delivered meets the requirements. This link between the requirements specification and user acceptance testing is shown by the dashed arrow between the two, identified as the ‘acceptance test plan’.
Simplified V model
Systems design follows requirements specification as shown by an arrow. Systems design has two dashed arrows: one across to systems testing and the other back to requirements specification. The horizontal arrow shows the systems testing that needs to be carried out to validate the design after it has been implemented. The arrow to the requirements specification indicates that the design process may discover errors in the systems requirements.
For example, gaps may be found in the definition of the requirements, or two requirements may be found to be inconsistent. The same kind of links to the previous source document and to the appropriate type of testing are applied to each stage of development.