ࡱ> q  mbjbjt+t+ AA0gU] Dp p p p \Lp O4j$LLLLLIMPXNPO$gQ[S^O O 4  L Lv#GP L\0p p L\KLr ENTERPRISE GFG Microsystems Limited IT Department  Information Technology Department IT Project Quality Assurance Plan  DOCTITLE Quality Assurance Plan for Client_name  SET ENTERPRISE GFG Microsystems Limited GFG Microsystems Limited  SET UNIT "GFG IT Development" GFG IT Development  SET UNITID "GFG IT" GFG IT  SET DOCTITLE "Quality Assurance Plan for  CLIENT Client_name" Quality Assurance Plan for  CLIENT Client_name  SET PROJECTNAME "project name" project name  SET PROJECTNUMBER "XXXX" XXXX  SET VERSION "0.02" 0.02  SET DOCUMENT  UNITID GFG IT-UK-99-SO 104/ VERSION 0.02" UNITID GFG IT-UK-99-SO 104/ VERSION 0.02  SET VERSIONDATE 4 February 1998 4 February 1998  SET CLIENT "Client_name" Client_name DOCUMENT DISTRIBUTION Document Identification Document Ref:  DOCUMENT GFG IT-UK-99-SO 104/0.02 Authors Ref:  FILENAME S104O002.DOT Author:  Date:  VERSIONDATE 4 February 1998 Dept/Section:  UNIT GFG IT Development Version:  VERSION 0.02 Reason for Distribution For Review Status: Draft  Distribution of Approved Version:               ReviewersDepartmentResponsibilitiesComments Received              Issued By:  ...........................................   ...........................................   Copy No:   Issued To:    CONTENTS  TOC \o "1-2" 1 Introduction  PAGEREF _Toc411248302 \h 4 1.1 Purpose  PAGEREF _Toc411248303 \h 4 1.2 Scope  PAGEREF _Toc411248304 \h 4 1.3 Audience  PAGEREF _Toc411248305 \h 4 1.4 Related Documents  PAGEREF _Toc411248306 \h 4 1.5 References  PAGEREF _Toc411248307 \h 5 1.6 Revision History  PAGEREF _Toc411248308 \h 5 2 Management  PAGEREF _Toc411248309 \h 6 2.1 Personnel  PAGEREF _Toc411248310 \h 6 2.2 Tasks  PAGEREF _Toc411248311 \h 6 3 Documentation  PAGEREF _Toc411248312 \h 8 4 STANDARDS, PRACTICES AND CONVENTIONS  PAGEREF _Toc411248313 \h 9 5 REVIEWS AND AUDITS  PAGEREF _Toc411248314 \h 10 5.1 Reviews  PAGEREF _Toc411248315 \h 10 5.2 Audits  PAGEREF _Toc411248316 \h 14 6 TESTING  PAGEREF _Toc411248317 \h 16 7 CONFIGURATION MANAGEMENT  PAGEREF _Toc411248318 \h 16 8 PROBLEM REPORTING AND Version CONTROL  PAGEREF _Toc411248319 \h 17 9 TOOLS, TECHNIQUES AND METRODOLOCIES  PAGEREF _Toc411248320 \h 17 10 RECORDS COLLECTION, MAINTENANCE AND RETENTION  PAGEREF _Toc411248321 \h 17  Introduction This document is a skeleton Project Quality Assurance Plan that is intended to be used as a basis for actual PQAPS. Please take a copy of this file and modify it as appropriate. This skeleton has been produced in accordance with the Project Quality Assurance Planning Standard ( UNITID GFG IT UK-99-SO-4). This skeleton is not included as part of  UNITID GFG IT UK-99-SO-4 for two for two reasons. Firstly, it may be subject to more frequent revision than the body of the standard. Secondly, it has to be available in machine readable form to provide significant benefits in terms of time saved. This paragraph and the previous paragraph should be deleted before this skeleton is used. Use of this skeleton does not avoid the need to think about the contents of a PQAP and all parts of this skeleton may need to be subject to amendment. WARNING - This document is not guaranteed in any way and any faults or flaws in this it are the responsibility of the person editing it to correct. In other words, if you get picked up for any faults in this document then it's your own fault. However, if you do find a fault then please inform the Standards Librarian or any member of the Standards committee so it can be corrected for future use. Purpose This document is the Project Quality Assurance Plan for project  PROJECTNUMBER XXXX. This document describes how Quality Assurance (QA) is to be planned and implemented on the project. Scope This document is concerned with planning the Quality Assurance of the project. it does not deal with planning other aspects of the project or with Quality Assurance of other projects. Audience This document is intended for the staff of  UNIT GFG IT Development concerned with project  PROJECTNUMBER XXXX as part of the project team or in a Quality Assurance capacity and for the staff of  PROJECTNUMBER XXXX client concerned with the project. A knowledge of Quality Assurance techniques and the relevant standards is assumed throughout. Related Documents It is assumed that the reader is familiar with the following documents. [1] UNITID GFG IT UKSO1The Object and Documentation Numbering System[2] UNITID GFG IT UKSO3Document Writing Standard[3] UNITID GFG IT UKSO17Commenting and Layout Checklist[4] UNITID GFG IT UKSO18Coding Checklist[5] UNITID GFG IT UKSO4Project Quality Assurance Planning Standard[6] UNITID GFG IT UKSO2Configuration Management Standard[7] UNITID GFG IT UKSO5Project Management Standard[8] UNITID GFG IT UKSO14Reviewing Standard[9] UNITID GFG IT UKSO15Auditing Standard[10] UNITID GFG IT UKSO16Software Test Planning Standard Any other standards  PROJECTNUMBER XXXX, Project Plan  PROJECTNUMBER XXXX, Proposal  PROJECTNUMBER XXXX, Contract  PROJECTNUMBER XXXX, Functional Specification ? Any other project related documents, such as Requirements Specifications References Any referenced documents should be mentioned here. Revision History VersionDateAuthorDescriptionSections Affected 0.0298/02/04GFGVersion changedDocument re-saved0.0197/12/04GFGFirst draftAll, diagrams and forms to be added  Management Personnel The Project Supervisor for this project is XXXX. The Project Manager for this project is XXXX. The Project Auditor for this project is XXXX. The Team Leaders for this project are XXXX and XXXX. The client contact for this project is XXXX. XXXX is responsible for signing off documents after reviews. This will normally be the Project Supervisor but may be a client as well. This data could be presented in a table format as follows: The project management roles are assigned as follows: Project Supervisor: xxxx Project Manager: xxxx Project Auditor: xxxx Team Leaders: xxxx xxxx Sign-Off Authority: XXXX for  UNITID GFG IT XXXX for the client The client contact for this project is XXXX. Tasks The following tasks are the Quality Assurance tasks for this project: Carrying out reviews and audits (see Section  REF _Ref408374720 \w \h 5) Conforming to standards in the creation of code and documents (and hardware perhaps). Possibly the creation of specialised QA tools Possibly training in QA techniques or standards All members of the project team are responsible for conforming to all relevant standards when producing code and documents (and hardware perhaps). The people responsible for carrying out reviews and audits are listed in Section  REF _Ref408374747 \w \h 5  REF _Ref408374758 \p \h below along with the agendas, tasks and success criteria. The success criteria for compliance with standards is to pass document reviews or code audits. If any specialised QA tools are to be created then state the success criteria, such as passing reviews or tests. If training is required then state the success criteria. Unless end of course tests are administered then there may not be any real success criteria. Documentation The following documents will be produced and reviewed in this project: Delete those which do not apply, add any more that do apply and dont forget to set up multi-part documents. Object numbers should be included where known. On small projects not all of these documents may be necessary and others may be combined. Project Plan Project Quality Assurance Plan (this document) Requirements Specification Functional Specification Architectural Design Specification Detailed Design Specification User Manual Acceptance Specification Software Test Plan Hardware Test Plan Software Test Report Hardware Test Report STANDARDS, PRACTICES AND CONVENTIONS All relevant  UNITID GFG IT standards are to be used on this project, as listed in Section  REF _Ref424533051 \r \h 1.4. If not all are to be used then state which ones are not to be used. List any external standards that are to be used. List any other practices or conventions that are to be used. Examples of these are: Formal design tools (for example Jackson or Yourdon tools) Spelling checkers (if not then why not?) LINT or similar program checkers 'make' or SCCS based build tools File or routine header prototypes (which could be included in appendices to this document) The entire development environment may be described here. This would avoid having to partially repeat information elsewhere. If this is done then Section REF _Ref424533096 \r \h 6 just needs to refer back to this section and Sections  REF _Ref424533121 \r \h 7 and  REF _Ref424533131 \r \h 8 may be similarly affected. REVIEWS AND AUDITS Reviews The following reviews will take place during the project: Not all of these reviews may be required on all projects. In addition some of them may be split, either as described in  UNITID GFG ITUK-99-SO-14 or due to design specifications being multi-part documents. Project Plan Review Project Quality Assurance Plan Review Requirements Specification Review Functional Specification Review Architectural Design Specification Review Detailed Design Specification Review User Manual Review Acceptance Specification Review Software Test Plan Review Hardware Test Plan Review Software Test Report Review Hardware Test Report Review All documents should be subjected to informal inspection by at least one person of the author's choice before being considered ready for review. State which reviews the client is to be invited to participate in. Possibly all code should be subject to informal inspection by at least one person of the author's choice before testing commences? The following review details may have to be altered for specific projects. In particular, if some documents are not present then the dependencies change. The review participants may have to be altered, the lead times have to be defined and the review criteria and tasks may have to be altered. Do not use this section blindly but try to think about the reviews. Project Plan Review The Project Plan Review should take place as early as possible in the project. A lead time of XXX days should be allowed between distribution of the Project Plan and the Project Plan Review. The following people should participate in the Project Plan Review; the Project Manager, the Project Auditor and the Project Supervisor. The criteria and tasks for the Project Plan Review are listed in the Reviewing Standard ( UNITID GFG IT UK-99-SO-14). The success criterion for the Project Plan Review is for a review report to be produced. Project Quality Assurance Plan Review The Project Quality Assurance Review should take place as early as possible in the project. A lead time of XXX days should be allowed between distribution of the Project Quality Assurance Plan and the Project Quality Assurance Plan Review. The following people should participate in the Project Quality Assurance Plan Review; the Project Manager, the Project Auditor and the Project Supervisor. The criteria and tasks for the Project Quality Assurance Plan Review are listed in the Reviewing Standard ( UNITID GFG IT 14). The success criterion for the Project Quality Assurance Plan Review is for a review report to be produced. As the Project Quality Assurance Plan is expected to change substantially during the life of the project a single review is unlikely to be sufficient. The first review should take place as early as possible and subsequent reviews should take place whenever the Project Quality Assurance Plan is significantly amended. This does not mean that a full-blown review is necessary whenever a trivial change is made. In the case of localised changes it is sufficient to review the altered section or sections. The personnel and criteria remain the same for all reviews of the Project Quality Assurance Plan. Requirements Specification Review The Requirements Specification Review should take place before a significant amount of work is done on the Functional Specification. A lead time of XXX days (Allow time for internal circulation within client staff) should be allowed between distribution of the Requirements Specification and agenda and the Requirements Specification Review. The following people should participate in the Requirements Specification Review; the author, the Project Auditor, the Project Manager and XXXX the client manager. The criteria and tasks for the Requirements Specification Review are as listed in the Reviewing Standard ( UNITID GFG IT 14). The success criterion for the Requirements Specification Review is for a review report to be produced. Functional Specification Review The Functional Specification Review should take place before a significant amount of work is done on the Architectural Design. A lead time of XXX days (Allow time for internal circulation within client staff) should be allowed between distribution of the Functional Specification and agenda and the Functional Specification Review. The following people should participate in the Functional Specification Review; the author, the Project Auditor, the Project Manager and XXXX the client manager. The criteria and tasks for the Functional Specification Review are as listed in the Reviewing Standard ( UNITID GFG IT 14). The success criterion for the Functional Specification Review is for a review report to be produced. Architectural Design Specification Review The Architectural Design Specification Review should take place before a significant amount of work is done on the Detailed Design Specification. A lead time of XXX days should be allowed between distribution of the Architectural Design Specification and agenda and the Architectural Design Specification Review. The following people should participate in the Architectural Design Specification Review; the author, the Project Auditor, the Project Manager, XXXX the client manager and the team leaders. The criteria and tasks for the Architectural Design Specification Review are as listed in the Reviewing Standard ( UNITID GFG IT UK-99-SO-14). The success criterion for the Architectural Design Specification Review is for a review report to be produced. Detailed Design Specification Review The Detailed Design Specification Review should take place before a significant amount of work is done on implementation. A lead time of XXX days should be allowed between distribution of the Detailed Design Specification and agenda and the Detailed Design Specification Review. The following people should participate in the Detailed Design Specification Review; the author, the Project Auditor, the Project Manager, and the team leaders. The criteria and tasks for the Detailed Design Specification Review are as listed in the Reviewing Standard ( UNITID GFG IT -14). The success criterion for the Detailed Design Specification Review is for a review report to be produced. User Manual Review The User Manual Review must take place before the first release. A lead time of XXX days (Allow time for internal circulation within client staff) should be allowed between distribution of the User Manual and agenda and the User Manual Review. The following people should participate in the User Manual Review; the author, the Project Auditor, the Project Manager and XXXX the client manager. The criteria and tasks for the User Manual Review are as listed in the Reviewing Standard ( UNITID GFG IT -14). The success criterion for the User Manual Review is for a review report to be produced. Acceptance Specification Review The Acceptance Specification Review should take place at least XXX weeks before testing of the complete system starts. A lead time of XXX days should be allowed between distribution of the Acceptance Specification and agenda and the Acceptance Specification Review. The following people should participate in the Acceptance Specification Review; the author, the Project Auditor, the Project Manager and XXXX the client manager. The criteria and tasks for the Acceptance Specification Review are as listed in the Reviewing Standard ( UNITID GFG IT -14). The success criterion for the Acceptance Specification Review is for a review report to be produced. Software Test Plan Review The Software Test Plan Review should take Place before a significant amount of work is done on the Detailed Design Specification. A lead time of XXX days should be allowed between distribution of the Software Test Plan and agenda and the Software Test Plan Review. The following people should participate in the Software Test Plan Review; the author, the Project Auditor, the Project Manager and the team leaders. The criteria and tasks for the Software Test Plan Review are as listed in the Reviewing Standard ( UNITID GFG IT -14). The success criterion for the Software Test Plan Review is for a review report to be produced. Hardware Test Plan Review The Hardware Test Plan Review should take place before a significant amount of work is done on the Detailed Design Specification. A lead time of XXX days should be allowed between distribution of the Hardware Test Plan and agenda and the Hardware Test Plan Review. The following people should participate in the Hardware Test Plan Review; the author, the Project Auditor, the Project Manager and the team leaders. The criteria and tasks for the Hardware Test Plan Review are as listed in the Reviewing Standard ( UNITID GFG IT -14). The success criterion for the Hardware Test Plan Review is for a review report to be produced. Software Test Report Review The Software Test Report Review should take place before the system is released. A lead time of XXX days should be allowed between distribution of the Software Test Report and agenda and the Software Test Report Review. The following people should participate in the Software Test Report Review; the author, the Project Auditor the Project Manager and the team leaders. The criteria and tasks for the Software Test Report Review are as listed in the Reviewing Standard ( UNITID GFG IT -14). The success criterion for the Software Test Report Review is for a review report to be produced. Hardware Test Report Review The Hardware Test Report Review should take place before the system is released. A lead time of XXX days should be allowed between distribution of the Hardware Test Report and agenda and the Hardware Test Report Review. The following people should participate in the Hardware Test Report Review; the author, the Project Auditor, the Project Manager and the team leaders. The criteria and tasks for the Hardware Test Report Review are as listed in the Reviewing Standard ( UNITID GFG IT -14). The success criterion for the Hardware Test Report Review is for a review report to be produced. Further reviews may be required. These may include reviews for QA tools and design walkthroughs. Audits The following audits will take place during the project: Physical Audit In-Process Audit Code Audits Not all of these audits may be required on all projects. On some projects other audits may be required. The tasks for the audits may need to be changed. Physical Audit A Physical Audit must be held before each release and the release may not go ahead until an audit report has been produced stating that the release has been satisfactorily audited and no problems have been found. Make sure that the time required for the Physical Audit is included in the Project Plan. This should include lead time and time required of the Project Auditor and any other staff. Possibly include a reference to the task code in the Project Plan. The tasks for a Physical Audit are as listed in the Auditing Standard ( UNITID GFG IT -15). The success criteria for the Physical Audit is for an audit report to be produced. If a report is produced from a Physical Audit that specifies any problems then the Project Manager is responsible for ensuring that the problems are dealt with before a repeat Physical Audit is scheduled. In-Process Audit At least one In-Process Audit should be held during the project and at the discretion of the Project Auditor further In-Process Audits may be held. If any serious faults are found during an In-Process Audit then the Project Auditor should conduct a repeat audit after the faults are supposed to have been addressed in order to check on them. Such a review may be a subset of a normal In-Process Review. The tasks for an In-Process Audit are as listed in the Auditing Standard ( UNITID GFG IT -15). Make sure that the time required for the In-Process Audit is included in the Project Plan. This should include lead time and time required of the Project Auditor and any other staff. Possibly include a reference to the task code in the Project Plan. The success criteria of the In-Process Audit is to produce an audit report. The Project Supervisor is responsible for planning corrections to any faults found in an In-Process Audit within XXX days of the audit report being produced. The planned corrections should have been implemented within XXX days of their being planned. Code Audits A Code Audit should be held on an example of the code produced by each member of the project team at some point early on in the implementation phase. Depending on the result of the first Code Audit of a person's code further Code Audits may or may not be required at the discretion of the Project Auditor. The Code Audits should be conducted either by the Project Auditor or by a Team Leader (as nominated by the Project Auditor). Make sure that the time required for all Code Audits is included in the Project Plan. This should include planning time, lead time and time required of the Project Auditor and any other staff. Possibly include a reference to the task code in the Project Plan. The success criteria of a Code Audit is to produce an audit report. If a Code Audit discovers problems in the code produced by a team member then the relevant Team Leader is responsible for ensuring that the problems are fixed, both in the sample of code audited and in all other code produced by the team member, within XXX days of the audit report being produced. TESTING The software will be tested by three levels of test. All modules will be tested in semi-isolation (module testing) and then integrated into subsystems that will be tested in isolation (integration testing) and the final system will be tested (system testing). Modules will be tested in semi-isolation in that the modules which interact directly with the operating system (list them here) will be tested in isolation and then the modules which depend on other modules for some functions (list them here) will be tested in conjunction with the other modules in order to avoid having to create unnecessary stubs during module testing. This implies that certain modules cannot be tested before other modules have been tested. List the dependencies here. Sub-systems will be tested in isolation and stubs will be created to allow this. Any stubs that are required for sub-system testing will also be required during module testing and these are the only stubs that will be used during module testing. These stubs will be maintained under normal configuration control for the project as they may be used for regression testing in the future. All tests will produce output in the form of a results file and each test result will be identified by the object number of the corresponding test plan and the group number and test number of the test. No module or sub-system tests will be controlled by user input. Instead all tests will be driven by files of test data. Final system testing will be driven by user input. CONFIGURATION MANAGEMENT This project will follow the Configuration Management Standard ( UNITID GFG IT UK-99-SO-2) for configuration management. Consider these options seriously and do not just accept the versions given here. Standard file naming conventions based on the  UNITID GFG IT numbering system are to be followed. All derived objects are to be controlled manually by means of an integration workbook. Or specify an alternative means that satisfies the configuration management standard. Revision histories are to be kept with all code and documents. Revision histories for code objects are to be kept at the head of the file (see the header included as Appendix X). Revision histories for documents are to be kept as part of the introduction. Revision histories must include the date of revisions and the initials of the persons making the revisions. Nested releases are not to be used and the whole system will be released when a release is performed. Each release will include all design documentation (both architectural and detailed), all user documentation, all source code and all executable programs. Incremental backups should be performed daily and full backups should be performed once a week. All backup tapes should be stored in a fire safe. PROBLEM REPORTING AND Version CONTROL This project will follow the Configuration Management Standard ( UNITID GFG IT UK-99-SO-2) for handling problem reporting and change control. Change control procedures are mandatory once design documents have passed a review and once software has passed module tests. The clients are allowed to raise any type of change requests but all change requests must be submitted to a change review board consisting of the Project Manager and XXX for the client. TOOLS, TECHNIQUES AND METRODOLOCIES This optional section states whether any unusual QA tools or techniques are being used. If only reviews, audits and testing are being used then there is no need for this section. RECORDS COLLECTION, MAINTENANCE AND RETENTION This optional section states how QA data is to be collected and stored. This is not necessary if the only data stored is review, audit and test reports stored in the project file. If other QA data is to be collected and stored then this section should state how this is to be done.  DOCUMENT GFG IT-UK-99-SO 104/0.02  PAGE 3 of  NUMPAGES 17  VERSIONDATE 4 February 1998  DOCTITLEQuality Assurance Plan for Client_name  ENTERPRISE GFG Microsystems Limited Project Name  PROJECTNAME project name Number:  PROJECT NUMBERXXXX  DOCTITLEQuality Assurance Plan for Client_name  ENTERPRISE GFG Microsystems Limited Project Name  PROJECTNAME project name Number:  PROJECT NUMBERXXXX  DOCTITLEQuality Assurance Plan for Client_name  ENTERPRISE GFG Microsystems Limited Project Name  PROJECTNAME project name Number:  PROJECT NUMBERXXXX  &'678Z}~,-./DEKLMNxy+,0123BCKLRSabklpqrst|} jUmHCJjCJOJQJUmH jUY(68Z|}.M267$&%*1$a $d+D *1$a +D+!(68Z|}.M2679Ho}/;DKLMprtuvwy{} " $ Q S T   &%*+]HISTlm}~ } ~    jUmHjXUmHjUmH CJOJQJjCJOJQJU5 jU jUmHmHK79Ho}/;DKLMp$$$l4 yp#$$$l4# prtuvwy{} ($$l4 p# $$l4 p#$$$l4p#  " $ Q S (ͼ $$l4J $$l4 $$l4 p#$S T ^ ` b n p r s }  ? u  4 @$  8#  8# $$$$l40v      $$$l40v      $T ^ ` b n p r s }  ? u  4 ^ 8 d  [  \b#&Ŀz  -4   -4   U4   U4   4  4 $  .   : ; < = > U V p q r s t        / 0 1 2 3 > ? Y Z [ \ ] n o j: UmHj UmHj@ UmHj UmHjF UmHjUmHjLUmHjUmHjRUmHmH jUmH=4 ^ 8 d  [  \b & p@ P ! X8#  8# $  8#       2 3 4 6 7 C D ^ _ ` b c n o      : ; U V W Y Z jCJUj"UmHjUmHj(UmHj UmHj. UmHj UmHj4 UmHj UmHmH jUmH= %&,-\b#NOUVhi/089?@hiqrxy$%-.45efnoumH jU jUmH mH j6UmH 6mH CJX#&*+/DGIcdh}$$$$l `! $$ qn*+/DGIcdh}Ľ}vokd]VOH                               !  ;  =  @  U  YZ         $9<>`aez},$$l `! $$ qn $9<>`aez}ƿxqjc_XQJ  i  ~                                #$  F  H  K  `  deuvCVWXghlm|}9:Ex67M  '(W<=jUmH 5mH CJ5 jUmH mH 6mH mH jUT!ABCW|$$l `! $$ qn!ABCW|:Ex˽|ung`\UN                        94   9w4   w-ABC  c  f:Ex46$$l43: #$$l43: # $467CM?7Pf| W(X !|wrmhc^YTY g,4   ,e| B}4  4  BD  h  t  x67CM?7Pf| W(X !` & `p@ P !=VWXYZ[\uvw|} !!'!n!c"d"#######$$4$5$6$9$:$>$$$$$%%B%C%k%l%%%%%& &&&&&&&&&&&&'''''޿޳j6UmH j6UmH j6UmH jUmH 6mH jUmH  jUmH jUmH mH F!'!n!d"r"""""#(#B#V#j####$$%C%l%%% &U'i'q''|(((|thc^YT##4  4   *S4  ########@#Z#v##4  !'!n!d"r"""""#(#B#V#j####$$%C%l%%% &U'i'q''#'''5'6'7'8'9'T'U'q''''#($(,(-(3(4(C(J({(|()*,,i.j.r.s.y.z.. /11 1 111344455h6i6q6r6x6y6677777^9_9g9h9n9o99:p<q<y<z<<<=%=L?M?U?V?\?]???<@v@5mH  jUmH mH j6UmH j6UmH 6mH U'|(((((')M)a))))))**I+,,-. //134Y567#(((')M)a))))))**I+,,-. //134Y567S89:Ŀytoa\WI4   4   4   _4   -4   w#######B#m##7S89:?;=%=i==>??@9BYBdCDEFFGGHJ0J KLL{MNUO:?;=%=i==>??@9BYBdCDEFFGGHJ0J KLL{MNUO~pkfXkfS4  U4  U4  |4   |04   04   i4   iv@AAAAAA9BYBBBoDpDxDyDDDDE G GGGGGGGIIIIIIJ0JL LLLLLLLwNxNNNNNNOO;O])_`½~ytoje]XSN4  @DS4   S[4   r$4  ###4   UO\OOOOO^PmPBQ:RRRSS^UUVWXXAYYZ[0\9\>])_`#9\]] ^1^ _(_$b=b}b~bbbbbbbb c8c9cAcBcHcIccccccd!gGgggggggi4ii0k1k;k?IM, zgV*"zw"o#Q>w#x>Pwl@&bnmĨ@@ṟIENDB`}DyK _Toc411248302}DyK _Toc411248303}DyK _Toc411248304}DyK _Toc411248305}DyK _Toc411248306}DyK _Toc411248307}DyK _Toc411248308}DyK _Toc411248309}DyK _Toc411248310}DyK _Toc411248311}DyK _Toc411248312}DyK _Toc411248313}DyK _Toc411248314}DyK _Toc411248315}DyK _Toc411248316}DyK _Toc411248317}DyK _Toc411248318}DyK _Toc411248319}DyK _Toc411248320}DyK _Toc411248321}DyK _Ref408374720}DyK _Ref408374747}DyK _Ref408374758}DyK _Ref424533051}DyK _Ref424533096}DyK _Ref424533121}DyK _Ref424533131, [,@,Normal OJQJmH NN Heading 2$ & F<@&56CJOJQJHH Heading 3$ & F<@& CJOJQJLL Heading 4$ & F<@&5CJOJQJ<< Heading 5 & F<@&CJHH Heading 6 & F<@&6CJOJQJ@@ Heading 7 & F<@&OJQJDD Heading 8 & F<@& 6OJQJJ J Heading 9 & F<@&56CJOJQJ<A@<Default Paragraph FontVOVH1 - Heading 1$$ & F4@&5;CJOJQJjOjS0 - Standard Paragraph qnCJOJQJmH LOLL1 - Level 1 Body Text mHHO2HH2 - Heading 2 & F4@& @;@O2@L2 - Level 2 Body Text>O!R>H3 - Heading 3  & F4@&CJ@OR@L3 - Level 3 Body TextNbNT1 - Table of Content Level 1N!rNT2 - Table of Content Level 2NANT3 - Table of Content Level 3llA1 - Appendix 1*$$ & F6@& qn5;CJOJQJjjA2 - Appendix 2*$$ & F7@& qn5CJOJQJJAJA3 - Appendix 3 & F0 hHHA4 - Appendix 4`@& hFOFH0 - Title Heading$ 5;CJ$4@4TOC 1h5;CJOJQJ,@,Header  9r &)@& Page Number, @,Footer ! 9r "I2 - Level 2 Indented paragraph("p0 p@ nCJOJQJmH fO2fI1 - Level 1 Indented paragraph#0 A "@"TOC 2$lOl Title Cover'%$$1$d$d 5@CJ@KHOJQJmH XOQrXSubtitle Cover&d$d  5@CJ0*Br* Body Text'x8J@r8Subtitle(dTx$d@T>@TTitle)$$1$d@<$d5@CJKHOJQJmH jOjReturn Address,*$&1$d#$(+DH pCJOJQJmH nOn Company Name'+$$&P1$d#$/+DH5@CJ$KHOJQJmH s i-W"           st 8V#)J5 @mJS1Xbi A q% ] eeee      TTTTTW u='v@9\lm9<BDEJPSX[^7pS 4 6!'7UO`lm:=>?@CFHKMORTVZ]_T !(:UO`m;AGILNQUWY\ &},.DKMx+02BKRakprs|HSl} };=Uqs02>Z\n 36C_bn  : V Y  % , NUh/8?hqx$-4enuWgl|<WY[v| 5 9 """"###6#8##$,$3$i*r*y*- --h2q2x2^5g5n5p8y88L;U;\;===o@x@@ CCCEEEHHHwJJJNNNQQQ}^^^8_A_H_cccittt t%%%%%%%%%%%%%%%%%%%%ttt $&-/4?BDRbeo ;=Jcr%2<LQW!tttttttt) ENTERPRISEUNITUNITIDTITLEDOCTITLE PROJECTNAMEPROJECT PROJECTNUMBERVERSIONDOCUMENT VERSIONDATECLIENTIssuedByPosition _Toc411248302 _Toc411248303 _Toc411248304 _Toc411248305 _Toc411248306 _Ref424533051 _Toc411248307 _Toc411248308 _Toc411248309 _Toc411248310 _Toc411248311 _Toc411248312 _Toc411248313 _Ref408374720 _Ref408374747 _Ref408374758 _Toc411248314 _Toc411248315 _Toc411248316 _Toc411248317 _Ref424533096 _Toc411248318 _Ref424533121 _Toc411248319 _Ref424533131 _Toc411248320 _Toc411248321E,s" \:x8C U#U#U#U#i#UK0X0X$^$^!c!ceei  !"#$%&'(,K0" a"DBL&h#h#h#h#p#[K8X8X<^<^FcFc3efiBEwzKOaew{4!;!f$k$XXXY\Y0gi$O  &1|u!!""##&&)!)))h+q+N,O,001133446677i9t999::&</<==>>??AAYBZBD(DDDFFWGXGHHIIMMNN/R8RRRVVW/X>YZ]]0giGerald McMullonE:\DOC\STANDARDS\S104O002.DOTGerald McMullonE:\DOC\STANDARDS\S104O002.DOTGerald McMullon)D:\TEMP\AutoRecovery save of S104O002.asdGerald McMullonE:\DOC\STANDARDS\S104O002.DOTGerald McMullonE:\DOC\STANDARDS\S104O002.DOTGerald McMullon)D:\TEMP\AutoRecovery save of S104O002.asdGerald McMullonE:\DOC\STANDARDS\S104O002.DOTGerald McMullonE:\doc\standards\S104O003.DOTGerald McMullonE:\DOC\STANDARDS\S104O002.DOTGerald McMullonE:\DOC\STANDARDS\S104O002.DOT6r W G 9r? p- OT\&|L1:W  -]  6Z! K L . @ [ _ K 3" ]#%)z * fr+ ]~+ 0/ 3/ q3 !6 1VD8 4{8 >4; [4;vfs9yB? +iA FAh.)=3G*I vI L K EDK Qz- ~T_"V XW )`[ DP_ z%eE_ [#kd_k Rn 60SrH&k|u 9u (=z0s|( dd  hhOJQJo( hhOJQJo(0o(- hhOJQJo( hhOJQJo(P@@.0..``...  ....  .....  ...... `....... 00........0o(() hhOJQJo( hhOJQJo( hhOJQJo( hhOJQJo( hhOJQJo( hhOJQJo( hhOJQJo( hhOJQJo( hhOJQJo( hhOJQJo( hhOJQJo(0@@.0..``...  ....  .....  ...... `....... 00........ hhOJQJo( hhOJQJo( hhOJQJo( hhOJQJo( hhOJQJo( hhOJQJo( hhOJQJo( hhOJQJo( hhOJQJo( hhOJQJo(0o(() hhOJQJo( hhOJQJo( 0OJQJo(-p0po() hhOJQJo( hhOJQJo( hhOJQJo( hhOJQJo(hh.P.....x....   .....  X@  ......  ....... 8x........ `H.........P@@.0..``...  ....  .....  ...... `....... 00........ hhOJQJo( hhOJQJo( hhOJQJo( hhOJQJo(P@@.0..``...  ....  .....  ...... `....... 00........00.0..08...  ....  .....  ...... `....... 00........ hhOJQJo( hhOJQJo(P@@.0..``...  ....  .....  ...... `....... 00........ hhOJQJo( hhOJQJo(P@@.0..``...  ....  .....  ...... `....... 00........P@@.0..``...  ....  .....  ...... `....... 00........ hhOJQJo(7Qs|FA60Srz%e(=z~TOT|r6Z!LK+iA!63":W p-fr+ *9yB?DP_)`[dd_3/>4;RnL K.[q3EDKXW*IK@G 1VD8k"VvI?0/4{8W]~+-] 9u&k|u)=3G]#%)[4; [#k [#k6@IBM 4079 Color Jetprinter PSLPT1:winspoolIBM 4079 Color Jetprinter PSIBM 4079 Color Jetprinter PSO 4dhA4PRIV''''V IBM 4079 Color Jetprinter PSO 4dhA4PRIV''''V 8888i0@GTimes New Roman5Symbol3& ArialY CG TimesTimes New Roman;" Helvetica9Palatino"A  an)2fm8i$"fU+! >0dzhf>PROJECT QUALITY ASSURANCE PLAN FOR CLIENT COMPANY PROJECT XXXX>PROJECT QUALITY ASSURANCE PLAN FOR CLIENT COMPANY PROJECT XXXXGerald McMullonGerald McMullonOh+'0(@Ld |    ?PROJECT QUALITY ASSURANCE PLAN FOR CLIENT COMPANY PROJECT XXXX?PROJECT QUALITY ASSURANCE PLAN FOR CLIENT COMPANY PROJECT XXXXGerald McMullonera S104o002.dotonGerald McMullon4raMicrosoft Word 8.0U@F#@w1@|O@ U՜.+,D՜.+,l( hp|  e+zh1 ?PROJECT QUALITY ASSURANCE PLAN FOR CLIENT COMPANY PROJECT XXXX TitleL(RZ _PID_GUID _PID_HLINKSAN{29407B97-714C-11D1-BFE6-080009B54CC2}A76+E:\Users\Gerald\images\BITMAPS\GFGLOGO.DIB  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`bcdefghijlmnopqrstuvwxyz{|}~Root Entry_^  "   FPnData a 1TablekTWordDocumentSummaryInformation(DocumentSummaryInformation8CompObjjObjectPool  FMicrosoft Word Document MSWordDocWord.Document.89q