SC4_Quality_Manual.pdf

ISO TC184/SC4 N1110 (QC N171)

(Supercedes QC N146)

2000-11-08

Source: editor

ISO TC 184/SC4 QUALITY COMMITTEE DOCUMENT

Technical Committee 184 for Industrial Automation Systems and Integration Subcommittee 4 for Industrial Data

SC4 Quality Manual

ISO TC 184/SC4 Quality Committee National Institute of Standards and Technology Building 220/Room A127 Gaithersburg, Maryland 20899

USA

This document can be downloaded as a ZIP archive containing all the constituent HTML files and GIF images, or as a single printable PDF file.

Contents

1 Introduction

1.1 Objectives

1.2 Quality management versus quality assurance

2 Scope 3 Terms, definitions, and abbreviations

3.1 Terms defined in ISO 10303-1

3.2 Terms defined in ISO 10303-202

3.3 Terms defined in ISO 8402

3.4 Terms defined in the Guidelines for the content of application protocols using application modules

3.4 Other terms and definitions

4 Management responsibility

4.1 Quality policy statement

4.2 Organization

4.3 Management review

5 Quality system

5.1 General

5.2 Review and approval procedures

5.3 Specifications, review criteria and approval

5.3.1 Specifications

5.3.2 Review criteria

5.3.3 Appproval

5.3.4 Text parts

5.3.5 Language parts

5.3.6 Implementation methods

5.3.7 General data models

5.3.8 Integrated resources

5.3.9 Application protocols

5.3.10 Abstract test suites

5.3.11 Application interpreted constructs

5.3.12 Application modules

5.3.13 View exchange protocols

5.4 Planning

5.4.1 Quality plan

5.4.2 Required skills and resources

5.4.3 Verification and validation

5.4.4 Quality records

5.5 Maintenance of the Quality System

5.5.1 Procedure for approval of Checklists

5.5.2 Issues against Checklists

5.5.3 Procedure for approval of Standing Documents

5.5.4 Issues against Standing Documents

5.5.5 Issues against ISO Directives

6 Design control

6.1 Procedure for validation of EXPRESS models

6.2 Procedure for validation of formal syntax specifications

6.3 Procedure for validation of ISO 10303-21 files

6.4 Procedure for validation of programming language specifications

6.5 Procedure for validation of ISO 10303 application protocols

6.6 Procedure for validation of ISO 10303 integrated resources and application interpreted constructs

7 Document control

7.1 Project document control

7.2 Document identification

8 Process control 9 Quality audits

9.1 Project audits

9.2 QC audits

9.2.1 Triggers for QC audit

9.2.2 Audit process

9.2.3 Appointment of auditors

9.2.4 Audit procedures

10 Training Annex A Quality plan template Annex B Quality report requirements Bibliography

Acknowledgements

Allison Barnard Feeney (NIST) and Jesse Crusey (NIST) developed the initial structure and content of this quality manual. Members of the Quality Committee produced a revised structure for the document at a workshop held at NIST in March 1999. Allison Barnard Feeney edited a partial draft reflecting the revised structure. Julian Fowler (PDT Solutions) edited and Tom Warren (Oklahoma State University) performed an editorial review of the version (QC N121) circulated for SC4 Standing Document Ballot. Members of the Quality Committee reviewed and resolved the issues raised during the ballot at a workshop held in Long Beach CA in September 1999. Julian Fowler edited and Tom Warren performed an editorial review a draft version (QC N146) for final review by QC and Working Group conveners. Julian Fowler edited this version for publication as an SC4 Standing Document

Readers should note that this document includes references to other SC4 standing documents that are either not yet approved or are subject to revision. Every effort will be made to ensure that this document is updated as other standing documents are approved are revised; however, readers are encouraged to seek the latest versions of documents referenced here.

[ Next ] sc4n1110.htm Last update 2000-11-08

SC4 Quality Manual

Contents of this clause:

1 Introduction

1.1 Objectives

1.2 Quality management versus quality assurance

[ Start | Next ]

1 Introduction

ISO TC184/SC4 aims to produce standards of high and consistent quality. In particular, the following quality goals apply to the work of SC4:

! each SC4 standard shall be complete;

! each SC4 standard shall be fully comprehensible to those who review the technical content of the standard, implement the standard in software products, test implementations of the standard, and deploy standards-based software products in industry;

! each SC4 standard shall be developed, reviewed, approved, and published within the timescales laid down by ISO Technical Management Board and by SC4;

! each SC4 standard shall conform to ISO and SC4-approved directives for the structure and content of standards;

! each SC4 standard shall conform to ISO and SC4-approved directives for presenting standards.

SC4 has established a Quality Committee to document and monitor a quality system that supports these goals. This quality manual is the cornerstone of the SC4 quality system and defines the specifications, quality assessment criteria, and approval procedures that support built-in quality for all SC4 standards. All SC4 project teams shall use this manual as a guide for developing standards.

NOTE In this document "SC4 standard" refers to any of the standards deliverables of the approved ISO projects assigned to SC4. This manual also applies to deliverables that are published as Publicly Available Specifications (PAS), Technical Specifications (TS), or Technical Reports (TR). Where it is necessary to refer to a part (of a multi-part standard), the manual uses "SC4 part".

1.1 Objectives

The objectives of the SC4 Quality Manual are as follows:

! to provide SC4 projects with a stable document that enumerates the specifications, quality assessment criteria, and approval processes that they should use to achieve quality standards;

! to define methods and metrics that help to ensure that SC4 project teams perform their tasks to consistently high levels of quality;

! to provide a foundation for improving quality practices within SC4;

! to provide objective evidence for determining and correcting the causes of poor quality.

1.2 Quality management versus quality assurance

Lack of quality in a proposed standard impedes adequate technical review, increases the likelihood for misunderstanding, and causes delays in adopting the standard. SC4 projects focus attention on quality in two places:

! the processes, procedures, tools, and techniques that ensure quality in the developing standards;

! inspecting the draft standard at specific points during its development.

Each SC4 project applies quality management through accepted development methods, procedures, and assessments designed to achieve quality in the product as the team develops it. The project team performs quality assurance through in-process or post-production inspections that are performed with a different set of procedures. Quality assurance procedures only address evaluating the characteristics of a standard, as opposed to all aspects of developing the standard.

[ Start | Next ] qm_1.htm Last update: 2000-11-08

Contents of this clause:

2 Scope

[ Start | Previous | Next ]

2 Scope

This standing document includes specifications, quality assessment criteria, and approval procedures for developing all SC4 standards. These standards include the following:

! ISO 10303 Product data representation and exchange;

! ISO 13584 Parts library;

! ISO 15531 Manufacturing management data;

! ISO 15926 Integration of life-cycle data for process plants including oil and gas production facilities;

! ISO 18876 Integration of industrial data for exchange, access, and sharing.

This standing document defines the responsibilities for quality within SC4. These responsibilities are assigned to the following:

! SC4;

! the SC4 Chair and Secretariat;

! Working Group conveners;

! the SC4 Policy and Planning Committee (PPC);

! the SC4 Change Management Committee;

! project leaders;

! part editors;

! project team members;

! the SC4 Quality Committee.

This standing document specifies the elements required to assess and improve the quality of an SC4 part.

The following are within the scope of this standing document:

! assignment of responsibilities in areas such as quality reviews, training, and tool selection and use;

! specifications for developing the various portions of SC4 standards and different types of SC4 parts;

! quality assessment criteria applied by SC4 project teams to verify the technical quality of a standard;

EXAMPLE 1 Technical quality criteria include the relevance, clarity, and utility of the specifications documented in a standard. These criteria determine whether the specification can be be unambiguously and economically implemented.

! quality assessment criteria applied by SC4 project teams to verify the document quality of a standard;

EXAMPLE 2 Document quality criteria include the format and structure of the part document and the clarity of definitions, examples, graphical models, and illustrations.

! procedures for reviewing and approving SC4 standards.

The following are within the scope of the SC4 quality system, but are documented in other standing documents and Quality Committee documents that this quality manual references:

! the overall procedures for developing and approving SC4 standards;

! assessment criteria for evaluating the accuracy of the technical content of a part;

! definition of requirements that SC4 standards shall meet;

NOTE The requirements for parts derive from documents approved by SC4. Clause 5 below lists the primary references that contain these requirements.

! checklists for reviewing different types of SC4 standard and SC4 part;

! the procedures used for developing, documenting and approving SC4 parts, including those for ISO

10303 resource integration and application interpretation.

The other documents within the SC4 quality system are listed in this document's bibliography. A maintained listing of methods documents, guidelines, and other relevant materials for standards developers is maintained at http://www.nist.gov/sc4/www/necsdocs.htm.

[ Start | Previous | Next ] qm_2.htm

Contents of this clause:

3 Terms, definitions, and abbreviations

3.1 Terms defined in ISO 10303-1

3.2 Terms defined in ISO 10303-202

3.3 Terms defined in ISO 8402

3.4 Terms defined in the Guidelines for the content of application protocols using application modules

3.5 Other terms and definitions

[ Start | Previous | Next ]

3 Terms, definitions, and abbreviations

3.1 Terms defined in ISO 10303-1

For the purposes of this standing document, the following terms defined in ISO 10303-1 apply:

! abstract test suite (ATS);

! application activity model (AAM);

! application interpreted model (AIM);

! application protocol (AP);

! application reference model (ARM);

! integrated resource (IR).

3.2 Terms defined in ISO 10303-202

For the purposes of this standing document, the following term defined in ISO 10303-202 applies:

! application interpreted construct (AIC).

3.3 Terms defined in ISO 8402

For the purposes of this standing document, the following terms defined in ISO 8402 (repeated below for convenience) apply:

NOTE The definitions below are repeated verbatim from ISO 8402. The notes provided with some of the definitions are added or adapted from ISO 8402 for the purposes of the SC4 Quality Manual.

3.3.1 conformity fulfilment of specified requirements

NOTE The above definition is valid for the purposes of quality standards. ISO/IEC Guide 2 defines the term "conformity" differently.

3.3.2 corrective action action taken to eliminate the causes of an existing nonconformity (3.3.4), defect (3.4.1), or other undesirable situation in order to prevent recurrence

NOTE The corrective actions may involve changes in procedures (3.3.6) to achieve requirements for quality (3.4.4).

3.3.3 management review formal evaluation by top management of the status and adequacy of the quality system (3.3.9) in relation to quality policy (3.3.8) and objectives

NOTE 1 Management review may include review of the quality policy.

NOTE 2 Quality audit (3.4.6) results are one of the possible inputs to management review.

3.3.4 nonconformity nonfulfilment of a specified requirement

3.3.5 preventive action action taken to eliminate the causes of a potential nonconformity (3.3.4), defect (3.4.1), or other undesirable situation in order to prevent occurrence

NOTE The preventive actions may involve changes in procedures (3.3.6) to achieve requirements for quality (3.4.4).

3.3.6 procedure specified way to perform an activity

NOTE 1 In many cases, procedures are documented (for example, quality system (3.3.9) procedures).

NOTE 2 If a procedure is documented, "written procedure" or "documented procedure" is frequently used.

3.3.7 quality control operational techniques and activities that are used to fulfil requirements for quality (3.4.4)

NOTE 1 Quality control involves operational techniques and activities aimed both at monitoring the development of the SC4 part and at eliminating causes of unsatisfactory documentation at all stages of the SC4 part, through International Standard approval, in order to achieve economic effectiveness.

NOTE 2 Some quality control and quality assurance (3.4.5) actions are interrelated.

3.3.8 quality policy overall intentions and direction of an organization with regard to quality (3.4.4) as formally expressed by top management

NOTE The quality policy forms one element of the corporate policy and is authorized by top management.

3.3.9 quality system organizational structure, procedures (3.3.6), processes, and resources needed to implement quality management

NOTE 1 The organizational structure of the quality system will identify responsibilities, authorities, and relationships, arranged in a pattern, through which an organization performs its functions.

NOTE 2 The quality system should be as comprehensive as needed, to meet the quality (3.4.4) objectives.

3.3.10 specification document stating requirements

NOTE A specification should refer to other relevant documents and indicate the means and the criteria whereby conformity (3.3.1) can be checked.

3.4 Terms defined in the Guidelines for the content of application protocols using application modules

For the purposes of this standing document, the following term defined in the Guidelines for the content of application protocols using application modules (repeated below for convenience) applies:

NOTE This definition and its source are subject to change, as the referenced document has not yet been approved as an SC4 standing document.

3.4.1 application module a reusable collection of scope statement, information requirements, mappings and module interpreted model that supports a specific usage of product data across multiple application contexts

3.5 Other terms and definitions

For the purposes of this Standing Document, the following terms and definitions apply.

3.5.1 defect nonfulfilment of an intended usage requirement or reasonable expectation of any feature of an SC4 standard

NOTE 1 This definition is adapted from that specified in ISO 8402.

NOTE 2 Defects can result from nonconformity to the specifications contained in or referenced by this SC4 Quality Manual.

3.5.2 design review documented, comprehensive, and systematic examination of an SC4 standard to evaluate its capability to fulfil the requirements for quality, identify problems, if any, and propose the development of solutions

NOTE This definition is adapted from that specified in ISO 8402.

3.5.3 peer review assessment of the capabilities of an individual or group of people conducted by others with a similar professional or technical background, skills, and experience

3.5.4 quality meeting agreed customer requirements; the totality of features and characteristics of a product or service that bears upon its ability to satisfy stated or implied needs.

NOTE This definition is adapted from that specified in ISO 8402.

3.5.5 quality assurance all the planned and systematic activities implemented with the quality system (3.3.9) and demonstrated as needed to provide adequate confidence that the product or service will fulfil the requirements for quality (3.5.4)

NOTE 1 There are both internal and external purposes for quality assurance:

! internal quality assurance provides confidence to SC4;

! external quality assurance provides confidence to the user of SC4 standards.

NOTE 2 Some quality controls (3.3.7) and quality assurance (3.5.5) actions are interrelated.

NOTE 3 Unless requirements for quality (3.5.4) fully reflect the needs of the user, quality assurance may not provide adequate confidence.

NOTE 4 This definition is adapted from that specified in ISO 8402.

3.5.6 quality audit systematic and independent examination to determine whether quality (3.5.4) activities and related results comply with planned arrangements and whether these arrangements are implemented effectively and are suitable to achieve the quality objectives

NOTE 1 Quality audits are carried out by staff working in cooperation with relevant personnel but not having direct responsibility in the areas being audited.

NOTE 2 One purpose of a quality audit is to evaluate the need for improvement or corrective action (3.3.2). An audit should not be confused with routine quality reviews within a Project.

NOTE 3 Quality audits can be conducted for internal or external purposes.

NOTE 4 This definition is adapted from that specified in ISO 8402.

3.5.7 quality audit observation statement of fact made during a quality audit (3.5.6) and substantiated by information that can be proved true, based on facts obtained through observation, test, or other means

NOTE This definition is adapted from that specified in ISO 8402.

3.5.8 quality auditor person experienced in using SC4 standing documents, their stated requirements, and ISO standards requirements to perform quality audits (3.5.6)

NOTE This definition is adapted from that specified in ISO 8402.

3.5.9 quality management all activities of management that determine the quality policy (3.3.8), objectives and responsibilities, and implement them by means of a quality plan (3.5.11), quality control (3.3.7), and quality assurance (3.5.5) within a quality system (3.3.9)

NOTE 1 Quality management is the responsibility of all levels of management but must be led by top management. Its implementation involves all members of ISO TC 184/SC4.

NOTE 2 In quality management, consideration is given to economic aspects and the usefulness of the ISO TC 184/SC4 standards.

NOTE 3 This definition is adapted from that specified in ISO 8402.

3.5.10 quality manual document stating the quality policy (3.3.8) and describing the quality system (3.3.9) for ISO TC 184/SC4

NOTE 1 A quality manual may relate to the totality of an organization's activities or only to a part of it. The title and scope of the manual reflects the field of application.

NOTE 2 A quality manual will contain the following as a minimum:

! quality policy (3.3.8);

! the responsibilities, authorities, and interrelationships of personnel who manage, perform, verify, or review work affecting quality

(3.5.4);

! the quality system (3.3.9), procedures (3.3.6), and instructions;

! a statement for reviewing, updating, and controlling the quality manual.

NOTE 3 This definition is adapted from that specified in ISO 8402.

3.5.11 quality plan document setting out the specific quality (3.3.8) practices, resources, and sequence of activities relevant to ISO TC 184/SC4 projects that develop International Standards

NOTE 1 A quality plan usually makes reference to the portion of the quality manual (3.5.10) applicable to specific classes of SC4 parts.

NOTE 2 This definition is adapted from that specified in ISO 8402.

3.5.12 validation confirmation by examination and provision of information that can be proved true, based on facts obtained through observation or test that the particular requirements for a specific intended use are fulfilled

NOTE 1 In design and development, validation examines the product to determine conformity (3.3.1) with user needs.

NOTE 2 Validation is normally performed on the final product under defined conditions. It may be necessary in earlier stages.

NOTE 3 Multiple validations may be carried out if there are different intended uses.

NOTE 4 Project Teams validate SC4 standards as part of the development process. P-members, A-liaisons, and other interested bodies validate SC4 standards through trial implementations and reviews associated with the ISO ballot processes. Industry validates SC4 standards through implementation and use. Any errors in a published SC4 standard that are detected during industry validation can be reported and corrected through the SEDS process.

NOTE 5 This definition is adapted from that specified in ISO 8402.

3.5.13 verification confirmation by examining and providing information that can be proved true, based on facts obtained through observation or test that specified requirements have been fulfilled

NOTE 1 In design and development, verification concerns the process of examining the results of a given activity to determine conformity (3.3.1) with the stated requirements for that activity.

NOTE 2 This definition is adapted from that specified in ISO 8402.

[ Start | Previous | Next ] qm_3.htm

Contents of this clause:

4 Management responsibility

4.1 Quality policy statement

4.2 Organization

4.3 Management review

[ Start | Previous | Next ]

4 Management responsibility

4.1 Quality policy statement

It is SC4's policy to develop standards to a high and consistent level of quality, and to achieve quality by executing the appropriate procedures within projects. Quality of SC4 standards is measured by accurate satisfaction of industry requirements, implementation and deployment of standards in commercial software systems, and approval of standards through the ISO process without the need for rework or reballoting.

This policy is supported by a quality system that is described in this manual. The SC4 quality system is an implementation of ISO 9001 appropriate to the needs and capabilities of a voluntary standards organization.

The quality system consists of procedures, guidelines, and work instructions that supplement the ISO Directives, provides information that directs and guides the work of SC4 projects, and defines metrics for assessing the quality of SC4 standards.

Project teams are responsible for the quality of their deliverables.

4.2 Organization

SC4 is responsible for implementing the SC4 quality policy.

Project leaders of SC4 projects are responsible for ensuring that their products satisfy the requirements of the SC4 Quality Manual.

All members of SC4 project teams shall be familiar with the contents of the SC4 Quality Manual and shall comply with the policies and procedures specified in it and other documents referenced by it. Project teams are responsible for providing feedback to the Quality Committee for improvements to the review process, approval checklists, methods documents, and training materials.

Project teams provide resources to the Quality Committee to support continuous maintenance and improvement of the SC4 quality system and its components.

The Quality Committee maintains the quality system and its components, providing training and advice on quality issues to SC4 and to project teams, and performing audits of projects against quality requirements.

The P-members and A-liaisons of SC4 are responsible for nominating suitably qualified and experienced experts to the Quality Committee.

4.3 Management review

The Quality Committee, the Working Group conveners, the Policy and Planning Committee, and the Change Management Committee shall jointly conduct an annual review of SC4's quality performance.

This review shall include consideration of the following:

! success of projects in meeting ISO and SC4 schedule requirements;

! success of projects in meeting quality metrics;

! requirements for mandatory audits;

! requirements and opportunities for process improvement.

The SC4 Chair shall report the results of this review to SC4.

[ Start | Previous | Next ] qm_4.htm

Contents of this clause:

5 Quality system

5.1 General

5.2 Review and approval procedures

5.3 Specifications, review criteria and approval

5.3.1 Specifications

5.3.2 Review criteria

5.3.3 Appproval

5.3.4 Text parts

5.3.5 Language parts

5.3.6 Implementation methods

5.3.7 General data models

5.3.8 Integrated resources

5.3.9 Application protocols

5.3.10 Abstract test suites

5.3.11 Application interpreted constructs

5.3.12 Application modules

5.3.13 View exchange protocols

5.4 Planning

5.4.1 Quality plan

5.4.2 Required skills and resources

5.4.3 Verification and validation

5.4.4 Quality records

5.5 Maintenance of the Quality System

5.5.1 Procedure for approval of checklists

5.5.2 Issues against checklists

5.5.3 Procedure for approval of Standing Documents

5.5.4 Issues against Standing Documents

5.5.5 Issues against ISO Directives

[ Start | Previous | Next ]

5 Quality system

The SC4 quality system includes the SC4 Quality Manual (this document), checklists for approval of SC4 parts by project leaders and conveners, quality assessment criteria for use in project reviews, and approved SC4 methods documents that provide requirements on technical and editorial development of SC4 standards.

5.1 General

Whether SC4 standards developers use quality assessment criteria as a development aid or as a quality inspection tool, they shall fulfil the requirements for approval of SC4 standards specified in this quality manual. The value of the quality system within SC4 depends upon the following:

! the existence, acceptance, and dissemination of quality requirements for standards development;

! the existence, acceptance, and dissemination of quality requirements for standards;

! the understanding, practical application, and consistent use of these quality requirements by project teams.

5.2 Review and approval procedures

Figure 1 below shows an overview of the review and approval process that takes place before each ballot cycle. The review process is described in detail in 5.3.2 below. The approval process is described in detail in

5.3.3 below.

Figure 1 - Review and approval procedure

Project teams and working groups are responsible for the following:

! part quality;

! coordinating and conducting part reviews;

! documenting review processes used, issues raised, resolution of issues, deferment of issues, and quality methods used.

Project teams are responsible for following SC4-approved methods documents when developing their parts and for conducting internal reviews at appropriate points during part development.

Project leaders shall conduct part reviews prior to publication and shall sign-off that parts are of acceptably high quality for release.

Conveners shall conduct part reviews following the Project Leader sign-off and shall sign-off that parts are of acceptably high quality for release.

The Quality Committee conducts audits if a project team team fails to fulfil the quality requirements that apply to it. An audit focuses on the methods and procedures used by the project team. An audit does not normally include detailed review and correction of part documents.

NOTE See clause 9 of this document for details of the audit process. The Quality Committee may also conduct audits of projects in the context of quality and process improvement activities.

5.3 Specifications, review criteria, and approval

Each SC4 part class contains categories of material that are governed by different specifications and are subject to different evaluations. Some categories of material such as the scope, normative references, and definitions apply to all parts. Some categories of material such as application reference models apply to only one class of parts. SC4 parts are divided into the following classes:

! text parts;

! languages;

! implementation methods;

! general data model parts;

! intergrated resources;

! application protocols;

! abstract test suites;

! application interpreted constructs;

! application modules;

! view exchange protocols.

Procedures and guidelines for developing and documenting particular classes of parts are found in the various SC4 standing documents referenced in the class-specific clauses of this quality manual.

Project teams shall use these standing documents to develop parts to a high level of quality. The Quality Committee uses the same standing documents to derive the quality assessment criteria that evaluate SC4 parts. Procedures for modifying and approving standing documents are specified in the SC4 Organization Handbook.

5.3.1 Specifications

Table 1 below summarizes the specifications that apply to each class of SC4 part.

Table 1 - Specifications text language impl.

method gen.

data model

IR AP ATS AIC AM VEP

COED * * * * * * * * * *

IDP3 * * * * * * * * * *

SDs ** ** ** ** * * * * * **

Formal syntax

EXPRESS *** *** * * * * * ***

Part 21 *** *** *** ***

In this table, abbreviations and symbols have the following meanings:

Column headings:

text:

text parts (see 5.3.4);

language:

langugage definition parts (see 5.3.5);

impl. method:

implementation methods (see 5.3.6);

gen. data model:

general data model parts (see 5.3.7);

IR:

integrated resources (see 5.3.8);

AP:

application protocols (see 5.3.9);

ATS:

abstract test suites (see 5.3.10);

AIC:

application interpreted constructs (see 5.3.11);

AM:

application modules (see 5.3.12);

ATS

Guidelines

Programming language

Syntactic & semantic rules

Terminology *

AP

Guidelines

AIM

Guidelines

Interpretation procedures

AM Usage Guidelines

Modular AP Content Guidelines

MT

Guidelines

Part 31 * *

IDEF0 *

IDEF1X ***

Part 32 *

EXPRESS-I *** ***

Part 22 ***

AIC

Guidelines

AM

Guidelines

NOTE 1 See clause 5.3.12 below for information about the status of methods that apply to developing application modules.

VEP:

view exchange protocols (see 5.3.13).

Row headings:

The project team shall have access to, be familiar with, understand, and apply the following:

COED:

the Concise Oxford Dictionary of Current English.

IDP3:

the ISO/IEC Directives, Part 3.

SDs:

the Supplementary directives for the drafting and presentation of ISO 10303.

NOTE 2 Although ISO 10303 parts form the main focus of the Supplementary Directives, this document contains provisions which apply to other SC4 parts.

EXAMPLE 1 The requirements for wording of the Foreword, as specified by ISO Central Secretariat and documented in the Supplementary Directives, apply to all SC4 parts.

EXAMPLE 2 The conventions for documentation of EXPRESS schemas may be applied to general data model parts.

Formal syntax:

any formal syntax notation used as specified in the part by normative or informative reference.

EXPRESS:

ISO 10303-11: Description methods: The EXPRESS language reference manual.

Part 21:

ISO 10303-21: Implementation methods: Clear text encoding of the exchange structure.

ATS Guidelines:

the Guidelines for the development of abstract test suites.

NOTE 3 At the time of publication of this quality manual, a second edition of these Guidelines is being prepared for publication as an SC4 standing document. Project teams, particularly those who have not yet submitted their part for Committee Draft ballot, should be prepared to apply the specifications contained in the second edition.

Programming language:

any programming language used, specified in the part by normative or informative reference.

Syntactic & semantic rules:

STEP (Standard for the Exchange of Product Model Data) Resource Integration: Semantic & Syntactic Rules.

NOTE 4 Each project team developing a general data model part that is to be considered as "common resources" should take this specification into consideration as the basis for use of the general data model part by ISO 10303 application protocols.

Terminology:

materials such as terminology standards, dictionaries, or text books that are relevant to the domain of the part.

AP Guidelines:

the Guidelines for the development and approval of STEP application protocols.

AIM Guidelines:

the Guidelines for application interpreted model development.

Interp. Procs.:

the Procedures for application interpretation.

NOTE 5 At the time of publication of this quality manual, the Procedures for application interpretation are not yet complete and have not been approved as an SC4 standing document. Nonetheless, project teams are encouraged to apply the specifications contained in this document.

AM Usage Guidelines:

the Application module development points within the application protocol development process.

Modular AP Content Guidelines:

the Guidelines for the content of application protocols using application modules.

NOTE 6 At the time of publication of this quality manual, the two documents referenced above have not been approved as SC4 standing documents. Until they are so approved, they should not be used except by those projects that have been authorized by SC4 to apply the modularization approach on an experimental basis.

MT Guidelines:

the Guidelines for the development of mapping tables.

NOTE 7 At the time of publication of this quality manual, a second edition of these Guidelines (retitled "Guidelines for the development of mapping specifications") is being prepared for publication as an SC4 standing document. Project teams, particularly those who have not yet submitted their part for Committee Draft ballot, should be prepared to apply the specifications contained in the second edition.

Part 31:

ISO 10303-31: Conformance testing methodology and framework: General concepts.

IDEF0:

IEEE Std 1320.1-1998, Standard for Functional Modeling Language - Syntax and Semantics for

IDEF0..

IDEF1X:

IEEE Std 1320.2-1998, Standard for Conceptual Modeling Language - Syntax and Semantics for

IDEF1X.

Part 32:

ISO 10303-32: Conformance testing methodology and framework: Requirements on testing laboratories and clients.

EXPRESS-I:

ISO/TR 10303-12: Description methods: The EXPRESS-I language reference manual.

Part 22:

ISO 10303-22: Implementation methods: Standard data access interface specification.

AIC Guidelines:

the Guidelines for application interpreted construct development.

AM Guidelines:

the Guidelines for the content of application modules.

NOTE 8 At the time of publication of this quality manual, the document referenced above has not been approved as an SC4 standing document.

Until it is so approved, it should not be used except by those projects that have been authorized by SC4 to apply the modularization approach on an experimental basis.

Table cells:

Mandatory specification

Mandatory specification for ISO 10303 parts. Project teams developing other SC4 parts shall apply the provisions of this specification that relate to ISO or SC4 requirements, and are encouraged to apply this specification elsewhere.

Mandatory if the part includes content relevant to the stated specification.

Mandatory for ISO 10303 application protocols that are developed using modules

5.3.2 Review criteria

The quality assessment criteria for evaluating each class of part are documented in the Procedures for Internal Review. These procedures will be continuously improved through feedback from their users.

Table 2 below summarizes the quality assessment criteria that apply to each class of SC4 part.

Table 2 - Quality Assessment Criteria text language impl.

method gen.

data model

IR AP ATS AIC AM VEP

Internal review

Formal syntax

In this table, abbreviations and symbols have the following meanings:

Column headings:

text:

text parts (see 5.3.4);

language:

langugage definition parts (see 5.3.5);

impl. method:

implementation methods (see 5.3.6);

gen. data model:

general data model parts (see 5.3.7);

IR:

integrated resources (see 5.3.8);

AP:

application protocols (see 5.3.9);

ATS:

abstract test suites (see 5.3.10);

AIC:

application interpreted constructs (see 5.3.11);

AM:

application modules (see 5.3.12);

NOTE 1 See clause 5.3.12 below for information about the status of methods that apply to developing application modules.

VEP:

view exchange protocols (see 5.3.13).

Row headings:

Internal review:

The project team shall verify that the document meets the relevant specifications by using the Procedures for Internal Review. The Project Team shall conduct an internal review prior to each ISO ballot stage and shall publish the results of this review as an N-numbered document on SOLIS.

NOTE 2 The operation and use of SOLIS is specified in the Annex H of the SC4 Organization Handbook.

NOTE 3 Project teams are strongly encouraged to carry out additional internal reviews while developing a part, and to retain the results of these reviews as part of the project quality records.

EXAMPLE A Project Team may carry out an internal review on a Working Draft prior to its circulation for industry review. In such circumstances some of the review criteria specified in the Procedures for Internal Review may not be applicable. The Project Team should note any criteria that were not applied during such an internal review.

Formal syntax:

The Ppoject team shall validate the syntax specification using the procedure specified in clause 6.2 of this document.

EXPRESS:

The project team shall validate all EXPRESS schemas specified in the part using the procedure

EXPRESS ** ** * * * * * **

Part 21 ** ** ** ** ** **

Programming language

Semantic validation

AP

Guidelines Interpretation procedures

EXPRESS-I ** **

specified in clause 6.1 of this document.

Part 21:

The project team shall validate all ISO 10303-21 files using the procedure specified in clause 6.3 of this document.

Programming language:

The project team shall validate the programming language statements using the procedure specified in clause 6.4 of this document.

Semantic validation:

The project team is encouraged to perform semantic validation of the EXPRESS schemas specified in the part by developing and documenting trial populations and/or prototype software implementations using representative sample data from the application domain(s) that the schemas are designed to support.

AP Guidelines / Interpretation procedures:

The project team shall validate the technical content of the application protocol using the procedures and processes specified for this purpose in the Guidelines for the development and approval of STEP application protocols and in the Procedures for application interpretation.

NOTE 4 At the time of publication of this quality manual, the Procedures for application interpretation are not yet complete and have not been approved as an SC4 standing document. Nonetheless, project teams are encouraged to apply the review procedures contained in this document.

EXPRESS-I:

The Project Team shall validate ISO/TR 10303-12 files and provide documentation describing the validation methods and tools used, and the results of this validation.

Table cells:

Mandatory review procedure

Mandatory if the part includes content relevant to the stated review procedure.

5.3.3 Approval

The following approval procedure applies to all classes of SC4 parts.

The project leader shall verify that the document meets the above specifications by using the Project Leader Approval Checklist for SC4. The project leader shall review the document prior to each ISO ballot stage and shall publish the results of this review as an N-numbered document on SOLIS.

The convener of the Working Group to which the project is assigned shall verify that the document meets the above specifications using the Convener Approval Checklist for SC4. The Convener shall review the document prior to each ISO ballot stage and shall publish the results of this review as an N-numbered document on SOLIS.

5.3.4 Text parts

Text parts include part 1 and the 30-series parts of ISO 10303, parts 1 and 10 of ISO 13584, parts 21, 31, and 41 of ISO 15531, and parts 1 and 3 of ISO 15926.

5.3.4.1 Specifications

The specifications that apply to developing text parts are identified in the column labelled "text" in Table 1 above.

NOTE There are no specific methods documents that apply to text parts. If any specific methods are identified by the Quality Committee or by Project Teams, the methods will be referenced here.

5.3.4.2 Review criteria

The project team shall verify that the document meets the above specifications by using the review procedures identified in the column labelled "text" in Table 2 above.

5.3.5 Language parts

Language parts include ISO 10303-11, the EXPRESS language reference manual.

5.3.5.1 Specifications

The specifications that apply to developing language parts are identified in the column labelled "language" in Table 1 above.

5.3.5.2 Review criteria

The project team shall verify that the document meets the above specifications by using the review procedures identified in the column labelled "language" in Table 2 above.

5.3.6 Implementation methods

Implementation methods include the 20-series parts of ISO 10303.

5.3.6.1 Specifications

The specifications that apply to developing implementation methods are identified in the column labelled "impl. method" in Table 1 above.

5.3.6.2 Review criteria

The project team shall verify that the document meets the above specifications by using the review procedures identified in the column labelled "impl. method" in Table 2 above.

5.3.7 General data models

General data model parts include the 20-series parts of ISO 13584, the 40-series parts of ISO 15531, and ISO 15926-2.

5.3.7.1 Specifications

The specifications that apply to developing general data models are identified in the column labelled "general data model" in Table 1 above.

5.3.7.2 Review criteria

The project team shall verify that the document meets the above specifications by using the review procedures identified in the column labelled "general data model" in Table 2 above.

5.3.8 Integrated resources

Integrated resources include the 40- and 100-series parts of ISO 10303.

5.3.8.1 Specifications

The specifications that apply to developing integrated resources are identified in the column labelled "IR" in Table 1 above.

5.3.8.2 Review criteria

The project team shall verify that the document meets the above specifications by using the review procedures identified in the column labelled "IR" in Table 2 above.

5.3.9 Application protocols

Application protocols are the 200-series parts of ISO 10303.

5.3.9.1 Specifications

The specifications that apply to developing application protocols are identified in the column labelled "AP" in Table 1 above.

5.3.9.2 Review criteria

The project team shall verify that the document meets the above specifications by using the review procedures identified in the column labelled "AP" in Table 2 above.

5.3.10 Abstract test suites

Abstract test suites are the 300-series parts of ISO 10303.

5.3.10.1 Specifications

The specifications that apply to developing abstract test suites are identified in the column labelled "ATS" in Table 1 above.

5.3.10.2 Review criteria

The project team shall verify that the document meets the above specifications by using the review procedures identified in the column labelled "ATS" in Table 2 above.

5.3.11 Application interpreted constructs

Application interpreted constructs are the 500-series parts of ISO 10303.

5.3.11.1 Specifications

The specifications that apply to developing application interpreted constructs are identified in the column labelled "AIC" in Table 1 above.

5.3.11.2 Review criteria

The project team shall verify that the document meets the above specifications by using the review procedures identified in the column labelled "AIC" in Table 2 above.

5.3.12 Application modules

Application modules are the 1000-series parts of ISO 10303.

NOTE 1 The WG10 preliminary work item on STEP modularization is developing detailed methods and guidelines for developing application modules. As soon as these guidelines are completed and approved by SC4, they will be referenced by this quality manual, and the columns labelled "AM" in Table 1 and Table 2 will be completed. Until that time, developers of application modules should to use and review the draft module guidelines available from http://wg10step.aticorp.org/.

NOTE 2 Similarly, The WG10 preliminary work item on STEP modularization will generate changes and/or additions to the specifications and procedures for developing and reviewing ISO 10303 application protocols.

5.3.13 View exchange protocols

View exchange protocols include the 100-series parts of ISO 13584.

5.3.13.1 Specifications

The specifications that apply to developing view exchange protocols are identified in the column labelled "VEP" in Table 1 above.

NOTE There are no specific methods documents that apply to view exchange protocol parts. If any specific methods are identified by the Quality Committee or by Project Teams, the methods will referenced here.

5.3.13.2 Review criteria

The project team shall verify that the document meets the above specifications by using the review procedures identified in the column labelled "VEP" in Table 2 above.

5.4 Planning

In order to satisfy all requirements for quality, each SC4 project shall prepare and implement a quality plan, ensure that the project leader, part editor, and other project team members have the necessary skills to produce a standard, conduct periodic verification of the contents of the standard during its development, and maintain appropriate quality records.

5.4.1 Quality plan

In order to satisfy all requirements for quality, each SC4 project shall prepare and maintain a quality plan as part of its overall project management and planning activities. These activities shall ensure that the project delivers a complete, useful, and high quality standard within timescales that are acceptable to users and implementers in industry, and conform to scheduling requirements defined by the ISO TMB and by SC4.

A quality plan identifies the following:

! tasks and activities that contribute to the quality of the part being developed by the project;

! allocation of resources to quality tasks;

! requirements for training to be undertaken by project members;

! validation/verification actions to be taken before or at particular milestone in the development of the part;

! procedures for maintaining records of quality tasks.

SC4 recommends that each project allocates 10% of its resources to quality-related tasks in order to ensure that all its deliverables are of a high and consistent level of quality, and do not require substantial rework as they move through ballot review and approval. Projects are encouraged to support maintenance and improvement of the SC4 quality system by allocating resources to specific Quality Committee tasks.

The quality plan is part of the project documentation and may be subject to audit.

NOTE A template for creating a quality plan is provided in Annex A of this document.

The proposers of a New Work Item Proposal (NWIP) shall prepare a quality plan and include it as part of the documentation supporting the NWIP. The convener of the Working Group to which the project is allocated shall review each project's quality plan when the project is approved. The convener shall ensure that the quality plan meets the requirements defined in this quality manual, and may recommend any changes to the quality plan that will improve the efficiency or effectiveness of the project.

This requirement applies to all NWIPs that are submitted after the publication of this quality manual as an SC4 standing document.

5.4.2 Required skills and resources

The different roles within SC4 require varying sets of skills. These skills are documented in the following subclauses.

5.4.2.1 Convener

Skills required: Familiarity with ISO/IEC Directives (Parts 1 & 3), SC4 Organization Handbook, SC4 Quality Manual, and any SC4-approved methods documents that apply to the type of standard being developed within the working group, such as AP Guidlines or ISO 10303 Supplementary Directives.

5.4.2.2 Project leader

5.4.2.3 Part editor

5.4.2.4 Editorial part reviewer

5.4.2.5 Technical usage part reviewer

NOTE Some SC4 projects have produced "Readers' Guide" documents in association with CD or DIS ballots. Given that these include an element of "how to read a standard", they may be useful as part of basic training for industry reviewers. Without this basic training, reviewers may be daunted by the size, complexity, and/or content of the standard to be reviewed.

5.4.2.6 Technical methods part reviewer

Relevant training and/or experience:

ISO and SC4 Procedures, SC4 Quality System

Skills required: Project management experience, familiarity with ISO/IEC Directives (Parts 1 and 3), SC4 Organization Handbook, ISO 10303 Supplementary Directives, SC4 Quality Manual, Procedures for Internal Review, and any specific guidelines or procedures that apply to the type of standard being developed.

Relevant training and/or experience:

For all project leaders: ISO and SC4 Procedures, SC4 Quality System

For project leaders of all ISO 10303 parts: STEP Overview.

For project leaders of ISO 10303 application protocol parts:

AP Development

For project leaders of all ISO 13584 parts: PLIB Overview

For project leaders of all ISO 15531 parts: MANDATE Overview

For project leaders of all ISO 15926 parts: Oil & Gas Overview

Skills required: Highly skilled in written and spoken English. Qualification or experience in technical writing. Skill with the authoring tool selected for use on the project. Familiarity with ISO/IEC Directives Part 3 and the Supplementary Directives for the drafting and presentation of ISO 10303, edition 2.

Relevant training and/or experience:

! Technical writing;

! ISO and SC4 documentation requirements.

Skills required: Highly skilled in written and spoken English. Qualification or experience in technical writing. Familiarity with ISO/IEC Directives Part 3 and the Supplementary Directives for the drafting and presentation of ISO 10303, edition 2.

Relevant training and/or experience:

! Technical writing;

! ISO and SC4 documentation requirements.

Skills required: Familiarity with domain terminology, qualifications, and experience in the domain covered by the standard. Participation in other standardization efforts in the domain, and/or membership of relevant professional associations may also be useful.

Relevant training and/or experience:

None

5.4.2.7 Interpreter

For an ISO 10303 application protocol, an interpreter is a person who produces the mapping tables showing how each UOF and application object maps to one or more AIM constructs.

5.4.2.8 Integrator

For an ISO 10303 integrated resource, an integrator is a person who develops and/or restructures proposed extensions to the integrated resources…