Quality Assurance

Chapter 66
66.1 ISO 9001: Approach
66.2 ISO 9001: Content
66.3 Industry Guides
66.4 The GAMP Guide
66.5 Validation
66.6 Documentation
66.7 Procedures
66.8 Additional Supplier’s Procedures
66.9 Additional End-User’s Procedures
66.10 Comments

The standard BS 5750 on quality systems was intro- a quality system, leaving the supplier to fill in the
duced in 1979 to address standards and specifica- details as appropriate. The essence of the standard
tions in the engineering industries. It rationalised is that it puts the onus onto the supplier to provide
the different quality assurance (QA) standards of documentary evidence to demonstrate that all of
the day, produced by various purchasing and third its activities and functions are oriented towards
party organisations, which were themselves based the attainment of quality.
upon Ministry of Defence standards. Consisting of Thus a supplier is required to consider and de-
four parts, BS 5750 has itself been superceded by fine its purpose, management structure and indi-
the identical ISO 9000 (1987) standards,correspon- vidual’s responsibilities, and to create a “quality
dence between the two being as listed in Table 66.1. policy”. Oversight of that policy becomes the re-
This chapter focuses on ISO 9001 which is the sponsibility of a “quality manager” who reports di-
standard that applies to the production of a con- rectly to the chief executive. This ensures that the
trol system by a supplier for an end-user on a quality manager has direct access to policy making
turnkey basis. It also draws upon ISO 12207, a and enables reporting that is objective and inde-
generic standard for information technology re- pendent.
garding the software life cycle. Detailed plans and procedures are required for
every process and activity,organised in accordance
with the quality policy. There must be checks and
balances to ensure that quality is achieved at all
stages or, if not, that action will be taken quickly
66.1 ISO 9001: Approach and reliably. Traceability is a key requirement: the
ISO 9001 requires organisations to establish, doc- ability to trace back from an error in order to iden-
ument and maintain an effective and economical tify and correct its cause. To this end, every stage
“quality system”. ISO 9001 is not in itself a qual- in a system’s development must be documented in
ity system but provides guidelines for constructing such a way that this backwards traceability can be
one. It seeks to set out the broad requirements of achieved. This requires records to prove who did
 532 66 Quality Assurance

Table 66.1 Summary of quality standards

ISO 9000 BS 5750 Part 0 A guide to selection and use of the appropriate parts of the standard
Section 1

ISO 9001 BS 5750 Part 1 Relates to quality specifications for design/development, production, installa-
tion and servicing when the requirements are specified by the end-user in terms
of how a system (or service) must perform and which is then provided by the
supplier (or contractor)
ISO 9002 BS 5750 Part 2 Sets out requirements where a supplier (or contractor) is manufacturing sys-
tems (or offering a service) to a published specification or to the end-user’s
specification
ISO 9003 BS 5750 Part 3 Specifies the quality system to be used in final inspection and test procedures
ISO 9004 BS 5750 Part 0 A guide to overall quality management and to the quality system elements within
Section 2 the standard

what, where, when, how, to what, with what and 66.2 ISO 9001: Content
why.
The standard provides brief guidance on the qual-
A“quality manual”has to be created which con-
ity requirements for each of the following activi-
sists of the various procedures, work instructions,
ties:
etc. created as a consequence of the quality policy.
This manual is to be accessible to all staff and kept
1. Management responsibility: policy, organisa-
up to date. Clearly staff have to be familiar with
tion and review
those parts of the manual that apply to their own
2. Quality system: documented procedures and
job functions.
effective implementation
Most suppliers provide services as well as
3. Contract review: defined requirements,queries
systems. For example, not only do they provide
resolved, capability to meet requirements
the hardware and system software but they also
4. Design control: planning, requirements, imple-
provide application software, after-sales support,
mentation, verification, change control
maintenance contracts and upgrades. These re-
5. Document control: approvals, changes and
quire the quality system to address the customer
modifications
interface and the less tangible considerations of
6. Purchasing: assessment of sub-contractors,
communications, care, treatment, satisfaction, etc.
specification of requirements, verification
ISO 9001 certification can be applied for once
7. Purchaser supplied (free issue) product: stor-
the procedures have been developed, put in place
age and maintenance procedures
and used for sufficient time, typically one to two
8. Product identification and traceability
years, to provide sufficient documentary evidence
9. Process control: work instructions, monitoring
that they are functioning effectively. Certification
and approval
provides contractors and end-users with an assur-
10. Inspection and testing
ance that the supplier has procedures which do
11. Inspection, measuring and test equipment
what it says they should do. However, this does not
12. Inspection and test status
provide any guarantee that the system sold is what
13. Control of non-conforming product
the end-user wants or that the application software
14. Corrective action
developed will do what is required.
15. Handling, storage, packing and delivery
16. Quality records
17. Internal quality audits
 66.3 Industry Guides 533

18. Training 66.4 The GAMP Guide

19. Servicing
20. Statistical techniques The guide’s purpose is to help suppliers of au-
tomation to the pharmaceutical industry ensure
that systems are developed with quality built in
and with documentary evidence that their sys-
66.3 Industry Guides tems meet the agreed specifications. It is intended
primarily for suppliers when developing systems
As stated, the standards simply set out the broad
and not for the retrospective validation of existing
requirements of a quality system, leaving the sup-
systems.
plier to fill in the details for the industry as appro-
It promotes a formal system for the develop-
priate. This has led to the formation of second tier
ment, supply and maintenance of automated sys-
guidance. Three guides have been produced relat-
tems by the supplier. Adherence to this manage-
ing to quality software: the STARTS (1989) guides
ment system by the supplier will provide sufficient
concentrate mainly on the various techniques and
documentary records for subsequent acceptance
tools used in software development, the TickIT
by the end-user and regulatory body. The formal
(1990) guide concerns quality systems for software
acceptance of an automated system and its docu-
production and the IEE guidelines (1990) relate
mentation by the end-user is an integral part of the
to the documentation of software for control (and
validation system.
other) systems.
The scope of the guide is broad and cov-
There are two further guides specifically pro-
ers a range of automated systems including auto-
duced for the pharmaceuticals industry. The
matic plant items, control systems, automated lab-
HMSO (1997) rules and guidance (the Orange
oratory equipment, manufacturing execution sys-
Book) for pharmaceutical manufacturers and dis-
tems (MES), and manufacturing and laboratory
tributors brings together the various EC directives,
database systems. It addresses both the hardware
the code of practice for qualified persons and the
and software components of automated systems
standard provisions for manufacturer’s licences
together with the controlled functions and associ-
and includes an annexe on computerised systems.
ated documentation.
Its title is somewhat misleading given that the regu-
The guide distinguishes between systems em-
lations contained are statutory, having roughly the
bedded in equipment, such as in complex filter
same status as the US Codes of Federal Register,
presses and compressor sets, and standalone sys-
and go far beyond mere guidance.
tems such as control systems, laboratory informa-
Regulatory bodies in the pharmaceuticals in-
tion systems, etc. The procedures for embedded
dustry in general, and the US Food and Drugs Ad-
and standalone systems are similar so the rest of
ministration (FDA) in particular, refuse to recog-
this chapter focuses on standalone control systems
nise ISO 9001 certification without validation. To
of the DCS, SCADA and PLC type.
address this the GAMP (2002) guide on good au-
The benefits that the principles defined in
tomated manufacturing practice was developed.
GAMP bring to end-users and suppliers include:
This relates directly to quality systems for valida-
tion of automated systems.Although developed for • Increase mutual understanding.
the pharmaceutical industry, the GAMP guide is • Eliminate the need for retrospective validation,
generic and may be applied throughout the pro- which is costly.
cess sector. The rest of this chapter is based on • Clarify the division of responsibility.
GAMP. • Provide a framework for defining and agreeing
standards for quality.
• Enable delivery on time, within budget and to
agreed quality standards.
 534 66 Quality Assurance

• Reduce the cost and shorten the period of vali- lates to the waterfall model.It should be recognised
dation through better project visibility. that these documents include or refer to most/all
of those identified in Chapter 60–64.
The management system requires procedures
to control the format, scope, contents, circulation,
66.5 Validation production and approval of each of these docu-
Validation is defined in GAMP as“establishing doc- ments. A typical format is as follows:
umented evidence which provides a high degree of Front page.
assurance that a specific process will consistently Name of procedure.
produce a product meeting its pre-determined Reference no.
specifications and quality attributes”. Issue number, date, author, status (e.g. draft
It follows that the existence of a separate and or final).
complete description of the product, that is a con- Authorisation.
trol system, is a prerequisite to the process of pro- Circulation.
ducing validation documentation. In the context
of a control system this is the detailed functional Revision status.
specification (DFS): this must be rigorously main- Changes since the last issue.
tained and kept up to date. Procedure.
The objective of validation therefore is to pro- Overview of procedure.
duce documented evidence which provides a high Scope (i.e. context in which procedure is to be
degree of assurance that all the parts of a system applied).
will consistently work correctly when brought into General guidelines (e.g. limitations to be
use. Traditionally, there are four stages to valida- strictly defined, ambiguities avoided).
tion: Contents (e.g. functions, data, interfaces,
1. Demonstration that the system has been de- responsibilities, etc.)
signed correctly. References.
2. Demonstration that the system has been in- Cross references to other procedures as
stalled as specified. appropriate.
3. Demonstration that the system works as speci-
fied.
4. Demonstration that the system produces ac-
ceptable product quality when running cor- 66.7 Procedures
rectly.
GAMP identifies ten major procedures which are
These stages can be related to the waterfall model, important for a quality management system. They
as depicted in Figure 63.1, in which stage 1 refers to are covered in the following sections. There are
the URS, DFS and software/module design, stage 2 many other procedures necessary,both for the sup-
is broadly equivalent to hardware acceptance,stage plier and the end-user: these are listed afterwards.
3 aligns with system acceptance (FAT) and stage 4
relates to commissioning.
66.7.1 Procedure for Project and Quality
Plan
66.6 Documentation This is produced by the supplier from the end-
The various documents involved in a quality man- user’s validation plan which sets out the regulatory
agement system are shown in Figure 66.1 which re- and project documentation requirements.
 This document Validation plan URS

Audit

Planning Project & quality plans

Specification, design &development DFS System acceptance test specification

Hardware design specification Hardware acceptance test specification Software design specification Software integration test specification

Module design specifications Module design test specifications

Hardware assembly Develop software

Testing Hardware testing and results Module testing and results

Software integration testing and results

Acceptance Hardware acceptance testing and results

System integration

System acceptance tests and results

66.7 Procedures

Operation Maintenance and change control

Fig. 66.1 Documentation for quality management system

535
 536 66 Quality Assurance

1. Each project has its own project plan and qual- 3. For smaller systems, design documents may be
ity plan. attached to the DFS as appendices rather than
2. The quality plan defines validation activities, exist as separate documents.
responsibilities and procedures to be used. The 4. Project implementation should not commence
end-user’s quality requirements take prece- until the end-user has formally agreed the DFS.
dence over the supplier’s. However, where 5. The system acceptance test specifications
the differences are small it is preferable that should be developed immediately after the DFS
the supplier’s procedures stand: the end-user is approved. Refer to Chapters 63 and 64.
should avoid imposing pedantic changes on the
supplier. There is less scope for error if the sup-
plier’s engineers are applying their own proce- 66.7.3 Procedure for Hardware Design
dures with which they are familiar. The impor- Specification
tant thing is that they cover the requirements.
This defines the system’s hardware. For a system
3. A project organisation chart is to be drawn:
comprising standard hardware items in a stan-
• Naming the project team and their job titles.
dard configuration most of the detail will already
• Identifying the single points of contact, nor-
be available on the supplier’s specification sheets
mally the project manager for the end-user
which should be cross referenced in this document.
and the contract manager for the supplier.
Any special hardware will be cross referenced
• Showing the interface to the supplier’s QA
to its requirements in the DFS and specified further
department.
as appropriate in this document.It may well require
4. The project plan should be produced in suf-
a further detailed design specification which may
ficient detail to allow accurate progress mon-
be appended to this document.
itoring. It should be regularly reviewed and
The hardware acceptance test specification
updated and hence is best included as an ap-
should be developed immediately after this doc-
pendix.
ument has been completed.

66.7.2 Procedure for Detailed Functional

Specification 66.7.4 Procedure for Software Design
Specification
The methodology behind the production of the
DFS is covered in detail in Chapter 62. It is written This follows on from the DFS and defines the soft-
by the supplier with detailed end-user input and ware sub-systems (modules) and the interfaces be-
the final document must be approved by the end- tween them. The emphasis is on a top-down ap-
user. It replaces the URS and becomes the princi- proach to design: structured programming tech-
pal reference document against which the system niques such as structure charts are appropriate.
is tested. Refer to Chapter 63.
1. The software effort should be re-estimated and
compared with that in the quotation: refer to
System Software
Chapter 61. Changes should be justified and
variation orders generated as appropriate. Pro- 1. Diagrams providing an overview of the system
vided there is no further change to the DFS depicting the software structure, system files
requested by the end-user, this estimate can be and data structures are recommended.
considered to be final. 2. For a standard system, the majority of the sys-
2. Complex functions may be specified in outline tem software modules will already be specified
in the main body of the document, with the de- in the standard system documentation and only
tail of the functionality included as appendices. need to be cross referenced.
 66.7 Procedures 537

3. Any special system software will be cross ref- 3. It doesn’t particularly matter how the detail of
erenced to its requirements in the DFS and sequence design is depicted, provided it is un-
decomposed into modules as appropriate in ambiguous. Sequence flow diagrams with plain
this document. Non-trivial modules will re- English statements or pseudo code is not un-
quire further detailed module design specifi- common. The SFC, ladder logic and structured
cations. text languages of IEC 61131 are all appropriate.
Refer to Chapters 29 and 47.
Application Software
1. A separate specification should be produced for The types of software, language, and relevant stan-
each substantial and distinct module, e.g. con- dards and guidelines used may be defined else-
trol scheme or procedure. where and cross referenced.
3. Control schemes should be decomposed into Design walkthroughs should be conducted
loops and channels as appropriate. regularly during the design process. Once com-
4. Procedures should be decomposed into opera- pleted, each module design specification should be
tions and phases in the correct order. Remem- checked and formally approved before configura-
ber that the phases are supposed to be config- tion and/or coding commences.
urable and are identified by name only at this Likewise, the module design test specifications
level of design. should be developed before configuration and/or
5. The higher level constructs of IEC 61131 and coding begins.
61512 are appropriate for articulating the se-
quence software design. 66.7.6 Procedure for Development,
Control and Issue of Software
Note that it is allowable to have several software de- The development of software, whether it be system
sign specifications provided that each refers back or application, either by means of coding or con-
unambiguously to the DFS. figuration, is controlled by this procedure which
The software integration test specification sets out the software production and version man-
should be developed once this document has been agement requirements.It applies to all the software
completed. produced by a supplier as part of a project.

66.7.5 Procedure for Module Design 1. GAMP states that there should be project spe-
Specification cific sets of standards: languages, reference
manuals, good practice guidelines, etc. which
This is essentially the same as for software design must be adhered to when developing soft-
in Section 66.7.4 above except that is at a lower ware. However, it is desirable on the grounds
and/or more detailed level, the differences being: of familiarity and efficiency for the supplier to
have generic standards for use on all turnkey
1. Loops, I/O channels and other configurable projects,irrespective of end-user.Also,from the
functions are defined in terms of the param- point of view of long term support, project spe-
eters required by their function blocks whose cific standards are not in the end-user’s interest
functionality is defined by the target system. and it is better to adopt the supplier’s without
Refer to Chapter 48. alteration whenever possible.
2. Structured programming techniques such as 2. GAMP recommends that naming conventions
data flow diagrams may assist in the detailed for modules, programs, directories, files, etc.
design of phases and/or steps. Refer to Chap- should be project specific.Again,it is better that
ter 63 again. they are set globally, provided they enable each
 538 66 Quality Assurance

project to be identified, say by incorporating Review and Approval

the project number in the reference.
1. All documents are subject to formal review.
3. Module headers should include name, version,
2. After the first review, a record is opened for that
date, author, cross references to any shared sub-
document and updated after each subsequent
modules, description and change history.
review. The GAMP guidance is that this history
4. Modules should be inspected and the code or
is part of a master document file but it is prob-
configuration approved before formal testing
ably best kept with the document and recorded
commences. Refer to Chapter 63.
on a revisions page.
5. Traceability. Once formal testing has com-
3. Any corrective actions consequent upon the re-
menced, any changes to a module should be
view should be completed, and themselves re-
identified in the source file.Additions and dele-
viewed before it is re-issued.
tions should be identified by a commentary
4. There should be at least two approval sig-
which includes a cross reference to the change
natures, typically the author and a manager.
control request. Deleted code may be com-
This will vary according to the document type
mented out.
and this relationship should be defined here.
6. Version control. The GAMP view on this is re-
Whereas the procedures for review and ap-
stricted to handling updates consistently, by
proval should be approved at Director level, re-
giving each module a unique name which al-
sponsibility for implementation should be de-
lows traceability to its design specification, and
volved as far as is sensible.
by providing a version control procedure. The
5. The persons responsible for approving docu-
supplier should go further than this and pro-
ments must accept that they have a responsibil-
vide an IPSE to support version control: it is
ity to read the documents carefully, and make
much better handled automatically than man-
available the time for doing so. Document ap-
ually.
proval is not intended to be a rubber stamping
exercise.
6. Any changes of substance to the content must
66.7.7 Procedure for Production, Control be subject to the change control (as opposed to
and Issue of Documentation version control) procedure.
This is a system for the production, review, ap-
proval, issue, withdrawal, change and archiving of
documents. It applies in particular to those docu-
Document Issue
ments identified in Figure 66.1 and should be com-
pany wide. 1. Approved documents must be issued to all copy
holders specified on the document front page
or elsewhere.
Production 2. Each document must be added to the project
document index when it is first issued.
1. Documentation standards should be specified 3. A transmittal notice should be issued with each
covering layout, style, contents, naming, ap- document sent between supplier and end-user,
proval and status. and vice versa.
2. Draft documents will have alphabetic issues 4. The GAMP guidelines advocate the concept of
starting with A, released documents will be nu- controlled copies with each copy of a document
meric starting with 1. numbered. This is overcomplicated for most
3. A document is its author’s responsibility prior project documents but some, such as the qual-
to release, it belongs to the project afterwards. ity procedures themselves, may be handled so.
 66.7 Procedures 539

5. Any superseded documents should be clearly jor updates it may be necessary to hold a further
stamped as such and stored in the archive docu- review prior to issue.
ment file and the entry in the project document 5. GAMP guidance is that each version of a docu-
index amended accordingly. ment reviewed should be retained. This seems
6. Any changes of substance are subject to the unnecessary provided that all changes are iden-
change control procedure. Following approval tified within the document and the revision
of the changes, the issue number must be up- page updated. As long as the changes are trace-
dated prior to release. able, the simplest method may as well be used.
7. A master document file will hold the master of
each project document. It will have an index Software Reviews
listing each document’s name, title and current
issue status. The review will check that the software is following
the documented design, adheres to configuration
and coding standards and to good practice guide-
66.7.8 Procedure for Document and lines. This relates to the section on module testing
Software Reviews in Chapter 63.
This covers formal document and software re- 1. The review team must include the programmer.
views. The purpose of a review is to check that 2. Formal testing should not start until at least
the functionality is correct and also that the rele- one formal review has been carried out.
vant procedures and guidelines have been followed 3. Corrective actions must be completed by the
correctly. Reviews are formal and must be minuted dates specified in the review minutes.
with all actions clearly identified together with the 4. Changes should be annotated within the files
name of the person responsible and the date for and/or code as in Clause 5 of Section 66.7.6
completion. above.

Document Reviews 66.7.9 Procedure for Change Control

Again, this applies to all the documentation iden- Change control is fundamental to maintaining vali-
tified in Figure 66.1. A review must be carried out dated systems and software.It applies to changes in
prior to formal issue of any document. Circulation documentation, software, hardware, etc. Note that
to the review team does not count as an issue! replacement, typically of hardware, on a like-for-
1. Copies of a document should be circulated to like basis does not count as a change. The issues
the team before the review, giving enough time underlying change control policy were considered
for the reviewers to read it properly. in Chapter 64: this section addresses its implemen-
2. The composition of a review team should be tation.
part of the quality plan.As a minimum it should Changes occur for three reasons:
include the author and the team leader. Other 1. Changes to correct faults in the software with
members of the team, especially those who respect to a correct DFS. Since fault correction
are working on related modules, should also has no effect on functionality, other than that
attend: this prevents misunderstandings and the function now works,it lies outside the scope
keeps module interfaces correct. of the change control procedure. However, if
3. Each section of a document should be covered. module testing is into its formal stages,any such
“No comments” as well as comments should be changes will still need to be recorded.
recorded. 2. Changes to correct functionality due to misin-
4. Corrective actions should be completed and the terpretation of the DFS by the supplier. Each
document updated by the dates agreed.For ma- change should be requested using a separate
 540 66 Quality Assurance

modification control form. Minor changes, i.e. • Hardware acceptance testing.

those that only affect a single module, will re- • System acceptance testing (FAT: at supplier’s fac-
quire modifications to that module’s design tory).
and test specification. Any such changes imple- • System acceptance testing (at end-user’s works).
mented must obviously be formally tested and
The procedure is similar for each type. The test
recorded.
specifications are written as soon as the implemen-
Major changes are likely to affect several mod-
tation specification has been completed.
ules. Depending on the complexity of the
The following format is recommended for test
changes, various module design and test speci-
specifications:
fications will almost certainly have to be modi-
fied.If testing has already started,repeat testing • Unique reference. Each test must be individually
will be required. Repeat testing of related mod- numbered and cross reference the relevant test
ules may well also be required to ensure that ex- specification.
isting functionality has not been inadvertently • Test title. Brief overview in plain English of the
affected. purpose of the particular test.
3. Changes in functionality, requested by the end- • Pre-requisites. All items needed to run the test,
user, due to mistakes and omissions in the DFS. such as simulated I/O, mimics, etc. and other
Changes in functionality will require modifica- software modules that must already be opera-
tions to the DFS itself, to the software design tional.
specification and to the software integration • Test description. Step by step details of how the
test specification, as well as to individual mod- test is to be carried out, including setting up ini-
ule design and test specifications. Such changes tial conditions, and the expected results for a
should be specified on the basis of a variation successful test.
order to the contract and quoted for. Only upon • Data to be recorded. A list of the specific test
acceptance by the end-user of the quotation data to be collected and appended to the test re-
should the change enter the change control pro- sults sheet, such as equipment serial numbers,
cedure and be implemented. Clearly the later in calibration certificates, loop responses, etc.
a project that changes are initiated, the greater
A test results sheet is used to record the results of
the impact and cost.
each test together with any additional data and ver-
The GAMP line is that a modification control form ifies, for example, that the initial conditions were
has to be completed for every change requested. set up as required. Also, all failed tests should be
This is clearly not necessary for correcting faults recorded, together with details of fault correction
or for changes made prior to formal testing, pro- and re-test results.Any changes required should be
vided the functionality is not affected. Neither is handled through the change control procedure.
it necessary for changes that lie outside the scope
of the change control policy. Otherwise, for each
change made, the modified software should cross-
reference the number of the modification control
66.8 Additional Supplier’s
form to provide traceability. Procedures
The ten procedures outlined in Section 66.7 above
66.7.10 Procedure for Testing an
are all very important as far as software develop-
Automated System ment is concerned. However, they are themselves
The various test specifications are: critically dependant upon underpinning by nu-
• Module design testing. merous other procedures in the supplier’s qual-
• Software integration testing. ity management system. For example, the GAMP
 66.8 Additional Supplier’s Procedures 541

guidelines hardly touch upon either the estima- downs into types of activity, based upon aggre-
tion of software effort or the monitoring of project gated timesheet returns, for feedback into the
progress. These are arguably the two most impor- metrics. The report should also provide a frank
tant procedures of all since inadequate estimates commentary on the problems encountered and
and ineffective monitoring are guaranteed to lead how to avoid them in the future.
to software chaos and project panic, attributes not 8. Procedure for project report. Normally writ-
normally associated with QA. ten by the contract manager at the end of the
project. Similar to the software report but pro-
viding an overview of the project as a whole,
Main Procedures including a detailed analysis of costs. It is nor-
1. General company organisation. The procedure mal for a summary of this report to be produced
outlines the function of each department and for general circulation. Such project profiles are
its interfaces to other departments with inputs useful documents for sales support.
and outputs clearly specified. This relates to the
notion of internal customers with each depart-
General Procedures
ment buying and selling products, services and
resources to/from each other. Procedures are required for handling all of the fol-
2. Application software manager’s guidelines and lowing:
project implementation procedures.These fully 1. Overtime forecasts and guidelines. The need
define the manager’s responsibilities and cross for consistent overtime to recover project time
references all relevant procedures, standards scales should be identified and planned.
and working practices.Refer to personnel man- 2. Holiday and illness forms. Staff holidays must
agement in Chapter 63. be reflected in project planning.
3. Software effort estimation procedure. This is 3. Secondment of end-user personnel. Involve-
the method with metrics used to determine ment of end-user staff in the supplier’s project
the effort required for software development. team is to be encouraged, but the seconded en-
It should allow for efficiency, management, etc. gineer must be competent and able to work as
Refer to the worked example of Chapter 61. a team member.
4. Timesheet procedure. This defines how time- 4. Works visit reports. Visits to the end-user’s
sheet data is to be recorded and analysed for works must be recorded, not only for invoicing
progress monitoring and metric evaluation. purposes but also to check that documentation
5. Progress monitoring procedures. These are has been formally updated from the knowledge
based upon metrics of an empirical nature gained.
gathered from work on previous projects. 5. Recruitment. Job descriptions, training records
Progress is monitored in relation to these met- and staff assessment all go towards ensuring
rics. Refer to the section on project manage- that personnel are correctly qualified to carry
ment in Chapter 63. out their allotted tasks and that documentary
6. Monthly report procedure. There should nor- evidence exists to justify involvement in the
mally be monthly progress meetings with a project team.
written monthly progress report. This covers 6. Rules of professional conduct. These should be
progress, issues, corrective actions, etc. based upon, and staff need to be aware of, the
7. Procedure for software report. Normally writ- guidelines of the professional institutions. For
ten by the application software manager at example, how to respond to end-user pressure
the end of the project, this consists of a de- for what they believe to be unsafe designs.
tailed analysis of actual vs estimates of soft- 7. Cost and timesheet codes. Base data for metri-
ware effort. It should include detailed break- cation and progress monitoring.
 542 66 Quality Assurance

66.9 Additional End-User’s With QC the loop is closed. Thus defects in the pro-
cesses of manufacturing a system and developing
Procedures its application software are identified. Feedback
There will be the equivalent of many of the GAMP then occurs to reduce the number of defects by
procedures in the end-user’s organisation, albeit in improving the procedures upon which those pro-
a form oriented towards the end-user’s process sec- cesses are based. Such feedback and improvement
tor. As far as the control and automation function is most readily realised in a manufacturing envi-
is concerned, additional underpinning procedures ronment where a limited number of virtually iden-
are required to address the following: tical products are being produced in bulk, say on a
production line. It is not so easy in the context of
• Analysis of costs and benefits. Refer to Chap- the supplier of control systems where the products
ter 59. are complex and every one is different.
• Formulation of user requirements specification. The environment within which quality is re-
Refer to Chapter 60. alised is said to be TQM if it satisfies the four ab-
• Process of vendor selection. Refer to Chapter 61. solutes:
• Auditing of suppliers’ quality procedures. Sup-
plier’s quality systems need to be audited prior • The definition of quality is conformance to re-
to vendor selection and thereafter on a regular quirements.
basis. • The system for causing quality is prevention, i.e.
• Monitoring of project progress. Attendance at QC, and not appraisal.
monthly progress meetings is essential. The • The performance standard is zero defects.
monthly reports from the supplier’s contract • The measurement of quality is the price of non-
manager should be received and carefully re- conformance.
viewed. Causes, and potential causes, of delay
must be examined critically. The characteristics of TQM are management com-
• Secondment of personnel to the supplier’s mitment, employee involvement, non-adversarial
project team. management-employee relationships, recognition
of success and determination.

66.10 Comments Observation

It is perhaps useful to draw a distinction between Good quality systems are not cheap.
quality assurance, quality control (QC) and total Cheap systems are not good quality.
quality management (TQM). Quality assurance is
effectively open-loop: you say what you are going to
do,you do it,and you check that you’ve done it.This Acknowledgement. Permission to quote from the
is underpinned by a raft of procedures and docu- GAMP guide and to include Figure 66.1, which is
mentation to provide evidence. However, there is an adaptation of the GAMP diagram on documen-
no feedback. tation in the life-cycle, is gratefully acknowledged.