contract conditions, technical, standard · pdf filecontract conditions, technical, standard...

AMD04/03(W) UNCLASSIFIED

ISSUE: 1 A-STD-61 (Part 3) UNCLASSIFIED of 45

CONTRACT CONDITIONS, TECHNICAL, STANDARD FOR

SUBTITLE : PART 3: NON-COMPLEX PROGRAMMES

SUMMARY : ARMSCOR’S TECHNICAL CONTRACT REQUIREMENTS FOR ACQUISITION, MANAGEMENT OF ENGINEERING EFFORT AND OTHER TECHNICAL WORK.

KEY WORDS : TECHNICAL CONTRACT CONDITIONS, ENGINEERING EFFORT, PROGRAMME ACQUISITION, PROCUREMENT, PRODUCT SYSTEMS, MAINTENANCE

DATE OF APPROVAL OF THIS ISSUE: 27 AUGUST 2004



APPROVAL PAGE



AMENDMENT HISTORY

CM Conformance Doc

Issue Date Amendments Doc

Change Proposal

No. Name Initials

1 27-08-2004 Release. Supersedes K-STD-61. Document electronically converted from Word-Perfect to MS Word. Document number adapted to corporate policy.

None O Phiri



TABLE OF CONTENTS

1 SCOPE 6

1.1 PURPOSE 6

1.2 APPLICATION 6

2 REFERENCE DOCUMENTS 6

3 DEFINITIONS 6

3.1 ARMSCOR’S PROGRAMME MANAGER 6

3.2 CERTIFICATION 6

3.3 CERTIFICATION FOR SAFETY OF FLIGHT 7

3.4 CONCEPT PHASE 7

3.5 CONTRACTOR 7

3.6 CONTRACT BASELINE 7

3.7 DEFINITION PHASE 8

3.8 DEVELOPMENT PHASE 8

3.9 PRODUCTION PHASE 8

3.10 QUALIFICATION 8

3.11 QUALITY RECORD 8

3.12 SEGMENT PLAN 8

3.13 USER 9

3.14 VALIDATION 9

3.15 VALUE SYSTEM 9

3.16 VERIFICATION 9

4 GENERAL REQUIREMENTS 9

4.1 DOCUMENT BREAKDOWN 9

4.2 SELECTION GUIDELINES 10

4.3 TAILORING 11

5 DETAILED REQUIREMENTS 11

6 NOTES 11



APPENDIX 1: CONTRACT CONDITIONS, TECHNICAL NON-COMPLEX PROGRAMMES 13

APPENDIX 2: ABBREVIATIONS 43



1 SCOPE

1.1 PURPOSE

A-STD-61 formulates different sets of technical contract conditions from which Armscor’s requirements for the management of the technical effort during the execution of a contract or order should be selected.

1.2 APPLICATION

These sets of requirements must be tailored to suit the acquisition / procurement of specific product systems, products, product sub-systems and components for the specific ORDER.

When these requirements are applied to an ORDER between the Prime CONTRACTOR and a Sub-contractor, the Prime CONTRACTOR may, at his discretion or as specified by Armscor, impose tailored requirements based on these requirements.

2 REFERENCE DOCUMENTS

MIL-STD-756 Reliability Modelling and Prediction

MIL-STD-1543 Reliability Program Requirements for Space and Launched Vehicles

RSA-MIL-STD-3 Acquisition Baseline, Standards for

RSA-MIL-STD-8 Minimum requirements for Software Development

RSA-MIL-STD-10 Manuals, Technical: General Style and Format Requirements

RSA-MIL-STD-122 Documentation, User System, General Requirements for (SA Army)

RSA-MIL-STD-128 Training, User System, General Requirements for (SA Army)

3 DEFINITIONS

3.1 ARMSCOR’S PROGRAMME MANAGER

The person, or his delegated representative, designated by ARMSCOR to assume the programme management responsibility for user and CONTRACTOR interfaces.

3.2 CERTIFICATION

Legal recognition by the certification authority that a product, service, organisation or person complies with the requirements. Such certification comprises the activity of technically checking the product, service, organization or person and the formal recognition of compliance with the applicable requirements by issue of a certificate, license, approval or other documents as required.



3.3 CERTIFICATION FOR SAFETY OF FLIGHT

The definition in §3.2 applies.

In addition certification of a product for safety of flight involves:

i. The process of assessing the design of a product to ensure that it complies with a set of standards applicable to that type of product so as to demonstrate an acceptable level of safety;

ii. The process of assessing an individual product to ensure that it conforms with the certified type design; and

iii. The issuance of a certificate required by national laws to declare that compliance or conformity has been found with standards in accordance with items (i) or (ii) above.

3.4 CONCEPT PHASE

The period during which comprehensive system studies and experimental hardware efforts are accomplished. Activities that are included are:

- Feasibility assessment;

- Logistic support estimate;

- Trade-off studies; and

- Cost-effectiveness and utility studies.

The product of this phase is normally the Functional Baseline.

3.5 CONTRACTOR

The party with whom the order has been placed by ARMSCOR, and includes the CONTRACTOR’s successors, legal representatives and permitted assignees.

3.6 CONTRACT BASELINE

A document or set of documents formally designated and fixed at a specific time during a configuration item’s (CI’s) life cycle forming the basis for contracting and control. Baselines, plus approved changes to those baselines, constitute the current basis for control.

RSA-MIL-STD-3 identifies and defines the following six baselines:

- Statement of Requirements Baseline (SRBL);

- Functional Baseline (FBL);

- Allocated Baseline (ABL);

- Product Baseline (PBL);

- Manufacturing Baseline (MBL); and

- Operational Support Baseline (OSBL).



3.7 DEFINITION PHASE

The objective of the Definition Phase is to identify and analyse major system alternatives, examine risky sub-systems and determine whether to proceed with development. The product of this phase is normally the Allocated Baseline.

3.8 DEVELOPMENT PHASE

The purpose of the Development Phase is to provide the design documentation necessary for production and the integrated logistic support documentation necessary to fully support the system. This is done by completing detailed design and demonstrating that reliability, producibility, supportability and performance requirements have been met. The product of this phase is normally the Product Baseline.

3.9 PRODUCTION PHASE

The primary objective of the Production Phase is to produce and deliver an effective, fully supported system at an optimal cost within the timescales.

3.10 QUALIFICATION

The process of objectively demonstrating whether an entity is capable of fulfilling specified requirements.

3.11 QUALITY RECORD

A quality record provides objective evidence of the extent of the fulfilment of the requirements for quality or the effectiveness of the operation of a quality system element. The following are examples of quality records:

- Test data;

- Qualification reports;

- Calibration data; and

- Inspection reports.

3.12 SEGMENT PLAN

A Segment Plan is an engineering management plan which covers all the phases in the acquisition process of a specific sub-programme (see FIGURE 1 on page 36 for the relative position of segment plans in the plan tree).

Such a plan, agreed upon between the contracting parties, constitutes a memorandum of agreement between the parties and cover aspects such as:

- Major acquisition milestones and schedules;

- Key milestone schedule;

- Interface milestone schedule;

- High level Work Breakdown Structure (WBS);

- High level Contract WBS (CWBS);

- Deliverables;



- Client-furnished equipment (CFE);

- Mandates, policies, values;

- Technical conditions;

- Resource requirements and cash flow;

- Contract phasing; and

- Security.

3.13 USER

The delegated representative of the end user of the system(s)/equipment.

3.14 VALIDATION

Confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use are fulfilled.

3.15 VALUE SYSTEM

A collection of elements, including goals, limitations, evaluation factors and criteria for decision-making, which provides a basis for rational decision-making.

3.16 VERIFICATION

Confirmation by examination and provision of objective evidence that specified requirements have been fulfilled.

4 GENERAL REQUIREMENTS

4.1 DOCUMENT BREAKDOWN

Part 1 : Contract Conditions, Technical, Standard for Highly complex programmes

Part 2 : Contract Conditions, Technical, Standard for Medium complex programmes

Part 3 : Contract Conditions, Technical, Standard for Non-complex programmes

Part 4 : Contract Conditions, Technical, Standard for Production programmes

Part 5 : Contract Conditions, Technical, Standard for Commercial Off-the-shelf (COTS) procurement

Part 6 : Contract Conditions, Technical, Standard for Maintenance programmes

Part 7: Contract Conditions, Technical, Standard for Refining an Operating Baseline for Existing Systems.



4.2 SELECTION GUIDELINES

When these requirements are used for contracting, the following selection guidelines should be considered in order to select the most applicable contracting base (Parts 1 to 7) for compiling specific CONTRACT conditions (see Parts 1 to 7):

4.2.1 Part 1 should be used when:

- The programme’s technical complexity is high, i.e. many complex interfaces, multi-discipline, unknown/untried technologies, etc;

- Technical and financial risks are medium to high;

- System complexity and/or system CONTRACTOR maturity requires a well-structured engineering process and detailed Armscor management;

- System level 5 or higher is involved.


- The programme’s technical complexity is high, i.e. many complex interfaces, multi-discipline, unknown/untried technologies, etc;

- Technical and financial risks are medium to high;

- System level 5 or higher is involved;

- Management of the system engineering process is delegated to the CONTRACTOR because his maturity does not require in-depth Armscor management;

OR

- The technical complexity is medium;

- Technical and financial risks are low to medium;

- System level 5 or lower is involved;

- The system complexity does not require in-depth Armscor management.


- The technical complexity and risks are low, i.e. single-discipline, known technologies, simple or well-defined interfaces;

- There are well-defined and developed components for complex items;

- The system engineering process requires minimal Armscor involvement.


- The scope of the ORDER is limited to production.


- The scope of the ORDER is limited to procurement of commercial off-the-shelf items (COTS).




- The scope of the ORDER is limited to maintenance.


- The scope of the order is limited to the refining of an Operating Baseline for existing systems.

4.3 TAILORING

Since it is seldom possible to apply such a detailed set of conditions as is, tailoring normally becomes necessary. To assist with tailoring the separate parts of A-STD-61 are available in electronic format.

The basic procedure for tailoring these sets of requirements is as follows:

i. Select the part (i.e. Parts 1 to 7) of these sets of requirements that is most applicable to the programme and use it as a basis for tailoring.

ii. Select those individual requirements that need to be upgraded/downgraded and replace them with the relevant requirements from the remaining parts (without change).

iii. Update general or unique specifications, reporting frequencies and/or people responsible, if required (example : MIL-STD-756 for general components or MIL-STD-1543 for space systems, changing from monthly to two-monthly; replacing programme manager with quality assurance representative, etc.).

iv. Update those requirements which need to be adapted for use in the specific CONTRACT.

v. Add special requirements which are not included in the standard set of requirements.

5 DETAILED REQUIREMENTS

See Appendix 1 of Parts 1 to 7 for the detailed sets of standard CONTRACT conditions.

6 NOTES

6.1 Documents applicable only to certain Arms of the Service e.g. RSA-MIL-STD-122 and RSA-MIL-STD-128 for the SA Army or RSA-MIL-STD-10 for the SA Air Force, are not referred to in parts 1 to 7 of the standard contract conditions.

6.2 MINIMUM REQUIREMENTS FOR SOFTWARE DEVELOPMENT When tailoring contractual requirements for software development, minimum requirements as described in RSA-MIL-STD-8 must be adhered to.



6.3 Guidelines for tailoring of A-STD-61 for technology development are provided in the form of Annexures to Part 1, Part 2 and Part 3. Programme managers must select the part most relevant for the specific technology programme.

6.4 When a CONTRACTOR subcontracts, using the technical contract conditions of A-STD-61, the name ARMSCOR must be replaced by the CONTRACTOR’s own name.



APPENDIX 1: CONTRACT CONDITIONS, TECHNICAL

NON-COMPLEX PROGRAMMES



TABLE OF CONTENTS

1 GENERAL 18

1.1 APPLICABILITY OF DOCUMENTS 18

1.2 DOCUMENTS 18

1.2.1 Applicable Documents 18

1.2.2 Reference Documents 19

1.3 DEFINITIONS 19

1.4 GENERAL NOTES 19

2 ENGINEERING MANAGEMENT 19

2.1 ORGANISATION 19

2.1.1 Programme / Project Management Organisation 19

2.1.2 List of Major Sub-contractors 19

2.1.3 Appointment of Personnel to Committees, Boards and Work Groups 19

2.2 PLANNING 20

2.2.1 Information for Summary Work Breakdown Structure 20

2.2.2 Contract Work Breakdown Structure (CWBS) 20

2.2.3 Work Breakdown Structure (WBS) Dictionary and Statement of Work (SOW)20

2.2.4 Plan Tree and Contract Data Requirements List (CDRL) 20

2.2.5 Programme Master Plan 20

2.2.6 Programme Report 20

2.2.7 Cost and Schedule Planning and Control 20

2.3 CONTROL 20

2.3.1 Establishment of Resource Management Control Systems 20

2.3.2 Resource Management Systems Demonstration and Audit 20

2.3.3 Reporting 20

2.3.4 Monthly Progress Meetings 20

2.3.5 ARMSCOR’s Representatives Facilities 20

3 SYSTEM ENGINEERING PROCESS 21



4 CONFIGURATION DEFINITION AND MANAGEMENT 21

4.1 GENERATION OF SPECIFICATIONS 21

4.2 CONFIGURATION MANAGEMENT REQUIREMENTS 21

4.2.1 General 21

4.2.2 Configuration Management Plan 22

4.2.3 Baseline Audits 22

4.2.4 Configuration Identification 22

4.2.5 Configuration Management Records and Reports 22

4.2.6 Configuration Control 23

4.2.7 Configuration Verification 24

4.2.8 Security of Data 24

4.2.9 Handover of Documentation to ARMSCOR 25

5 TECHNICAL PERFORMANCE ACHIEVEMENT 25

5.1 RISK MANAGEMENT 25

5.2 TECHNICAL PERFORMANCE MEASUREMENT (TPM) 25

5.3 FORMAL REVIEWS 25

5.3.1 Technical Review Agenda 25

5.3.2 Technical Review Data Package 25

5.3.3 Technical Review Meeting Minutes 26

5.4 VERIFICATION AND VALIDATION OF DESIGN 26

5.4.1 Qualification Principles 26

5.4.2 Test and Evaluation and Qualification Planning 26

5.4.3 Design Qualification 26

5.4.4 Simulation Model 26

5.4.5 Specification Validation 26

6 OPERATIONAL FEASIBILITY AND OPTIMISATION 27

6.1 ENGINEERING SPECIALITY INTEGRATION 27

6.1.1 Reliability Engineering 27

6.1.2 Maintainability Engineering 27

6.1.3 System Safety 27



6.1.4 Standardisation and Parts Control 27

6.1.5 Human Engineering 27

6.1.6 Electro-magnetic Compatibility (EMC) and Electro-magnetic Interference (EMI) 27

6.1.7 Value Engineering 28

6.1.8 Nuclear, Biological and Chemical Protection 28

6.1.9 Thermal Analysis / Design 28

6.1.10 Classification of Characteristics and Failures 28

6.2 SYSTEM AND COST EFFECTIVENESS 28

6.3 LOGISTIC ENGINEERING 28

6.3.1 Logistic Support Analysis (LSA) 28

6.3.2 Interchangeability and Compatibility 28

6.3.3 Codification 28

6.3.4 Logistic Support Analysis Report 29

6.4 PRODUCTION ENGINEERING 29

6.4.1 Production Engineering Analysis 29

6.4.2 Production Processes 29

6.4.3 Production Plan 29

6.4.4 Production Readiness Review (PRR) 29

6.5 SOFTWARE ENGINEERING 30

6.5.1 Establishing a Software Development Environment 30

6.5.2 System Requirements Analysis 30

6.5.3 System Design 31

6.5.4 Software Requirements Analysis 31

6.5.5 Software Design 31

6.5.6 Coding and Unit Testing 32

6.5.7 Unit Integration and CSCI Testing 32

6.5.8 CSCI/HWCI Integration and Testing 32

6.5.9 Software Version Description (SVD) 32

6.5.10 Software Development File (SDF) 32

7 QUALITY MANAGEMENT 33



7.1 CONTRACTOR’S QUALITY MANAGEMENT SYSTEM 33

7.2 QUALITY PLAN 33

7.3 QUALITY REPORTS 33

7.4 RIGHT OF ACCESS 33

7.5 ACCEPTANCE AUTHORITY 33

7.6 QUALITY OF SUPPLIES 33

7.7 CONTROL OF INSPECTION, MEASURING AND TEST EQUIPMENT 33

7.8 ACCEPTANCE / FORMAL TEST AND EVALUATION 34

7.9 ACCEPTANCE 34

7.10 SOFTWARE QUALITY ASSURANCE 34

7.11 QUARANTINE SYSTEM 34

7.12 CORRECTIVE AND PREVENTIVE ACTION SYSTEM 34

7.13 CONTROL OF QUALITY RECORDS 35

ANNEXURE A: REFERENCES 37 ANNEXURE B: TAILORING GUIDELINES FOR TECHNOLOGY DEVELOPMENT 38



1 GENERAL

1.1 APPLICABILITY OF DOCUMENTS

This document forms ARMSCOR’s standard for technical contract conditions.

Where any of these conditions are in conflict with any special terms, conditions, stipulations or provisions incorporated in any documents in the ORDER, the following order of precedence of documentation shall prevail:

i. Special terms and conditions of the ORDER;

ii. ARMSCOR’s general conditions of CONTRACT (e.g. K-STD-0020);

iii. ARMSCOR’s standard technical contract conditions;

iv. RSA Military standards and directives;

v. DOD Military standards and directives;

vi. Other interpretive documents.

1.2 DOCUMENTS

The following documents, of the issue in effect on the date of request for proposal or as stated in the ORDER, form part of these conditions of the ORDER to the following extent:

1.2.1 Applicable Documents

Conformance required to the extent specified in the ORDER:

ACT No 6, 1983 Machinery and Occupational Safety Act

DOD-STD-2168 Defence System Software Quality Program.

ISO 9001 Quality Systems - Model for Quality Assurance in Design, Development, Production, Installation and Servicing.

ISO/IEC 12207 Information Technology: Software Life Cycle Processes

MIL-STD-461 Control of Electro-magnetic Interference Submissions and Susceptibility - Requirements for

MIL-STD-462 Electro-magnetic Interference Characteristics, Measurement of.

MIL-STD-490 Specification Practices.

MIL-STD-498 Software Development and Documentation.

MIL-STD-973 Configuration Management.

MIL-STD-1629 Procedure for Performing a Failure Mode Effects and Criticality Analysis.

RSA-MIL-PRAC-190 Praktyk vir die Kwalifikasie van Stelsels.

RSA-MIL-SPEC-47 Item Information Requirements for Codification.

RSA-MIL-STD-3 Acquisition Baseline Standards.



RSA-MIL-STD-105 The Engineering of Reliable and Maintainable Systems.

RSA-MIL-STD-176 Configuration Management Forms

DD-1376 Recommended Spare Parts List (RSPL).

K217 Modification Proposal.

K225 Inspection / Release / Acceptance Certificate.

K226 Inspection Rejection Note.

K227 Concession (Waiver).

K228 Deviation Permit.

1.2.2 Reference Documents

Use as guidelines - Refer Annexure A.

1.3 DEFINITIONS

The definitions in paragraph 3 of the main part of A-STD-61 are applicable.

1.4 GENERAL NOTES

1.4.1 Where practical, different deliverable documents may be consolidated into one document for cost-effective reasons. This note does not allow for any changes to contractual requirements with regard to content or authorisation.

1.4.2 The CONTRACTOR can obtain contracted technical documentation from ARMSCOR where copyright is vested in ARMSCOR.

1.4.3 In subcontracting, the CONTRACTOR shall make the relevant technical contract conditions applicable. (Refer to paragraph 6.4 in the main part of A-STD-61).

2 ENGINEERING MANAGEMENT

2.1 ORGANISATION

2.1.1 Programme / Project Management Organisation

The CONTRACTOR shall establish and maintain a programme / project management infrastructure, prior to commencement of work.

2.1.2 List of Major Sub-contractors

Not applicable.

2.1.3 Appointment of Personnel to Committees, Boards and Work Groups

Not applicable.



2.2 PLANNING

2.2.1 Information for Summary Work Breakdown Structure

The CONTRACTOR shall, on request, supply sufficient information to ARMSCOR’s programme manager for the development of a Summary Work Breakdown Structure (WBS), see FIGURE 1 on page 36.

2.2.2 Contract Work Breakdown Structure (CWBS)

Not applicable.

2.2.3 Work Breakdown Structure (WBS) Dictionary and Statement of Work (SOW)

Not applicable.

2.2.4 Plan Tree and Contract Data Requirements List (CDRL)

Not applicable.

2.2.5 Programme Master Plan

Not applicable.

2.2.6 Programme Report

Not applicable.

2.2.7 Cost and Schedule Planning and Control

Not applicable.

2.3 CONTROL

2.3.1 Establishment of Resource Management Control Systems

Not applicable.

2.3.2 Resource Management Systems Demonstration and Audit

Not applicable.

2.3.3 Reporting

The CONTRACTOR shall establish a monthly reporting system, which meets the requirements laid down in the ORDER.

2.3.4 Monthly Progress Meetings

Not applicable.

2.3.5 ARMSCOR’s Representatives Facilities

The CONTRACTOR shall make available to ARMSCOR’s representative(s), if and when required at his own and/or his sub-contractor’s works:

- Suitable partitioned office accommodation conforming to the Environmental



Regulations for Workplaces enacted in terms of the Machinery and Occupation Safety Act, Act No 6, 1983;

- Secure documentation storage facilities; and

- Equipment which is necessary for ARMSCOR’s acceptance/formal testing and evaluation.

3 SYSTEM ENGINEERING PROCESS

Not applicable.

4 CONFIGURATION DEFINITION AND MANAGEMENT

4.1 GENERATION OF SPECIFICATIONS

Specifications identified in the specification tree for the ORDER shall be generated in accordance with MIL-STD-490 or agreed alternative. Specifications shall be presented for approval to ARMSCOR’s programme manager.

Final configuration, interface definition and requirements, as well as any special processes and material shall be specified in accordance with MIL-STD-490 or agreed alternative.

Specifications for computer software elements shall be specified in accordance with MIL-STD-498. Software source listings shall form part of these specifications.

Site requirement, setting-to-work and installation specifications shall be developed, where applicable, using MIL-STD-490, type B4 specification format as a guideline.

The CONTRACTOR shall identify, define, document and control all functional and physical interfaces for which he is contractually responsible in accordance with MIL-STD-973 and RSA-MIL-STD-176.

4.2 CONFIGURATION MANAGEMENT REQUIREMENTS

4.2.1 General

The CONTRACTOR shall be able to demonstrate, prior to placement of ORDER, an integrated configuration management system, conforming to MIL-STD-973 and RSA-MIL-STD-176, tailored to satisfy the requirements of the ORDER.

ARMSCOR shall have the right to carry out periodic audits of the CONTRACTOR’s configuration management system, including independent Physical and Functional Configuration Audits.



4.2.2 Configuration Management Plan

Not applicable.

4.2.3 Baseline Audits

The CONTRACTOR shall use the initial contracted baseline as the point of departure for configuration and change management.

The CONTRACTOR shall formalise and maintain a Master Record Index (MRI), using K-STD-0003 as a guideline from the initial baseline, which shall include all applicable baseline documents and be kept under configuration / change control.

4.2.4 Configuration Identification

4.2.4.1 Configuration Items

The CONTRACTOR shall identify, not later than the end of the Definition Phase, configuration items (CI) for configuration management, for approval by ARMSCOR’s programme manager.

The CONTRACTOR shall identify configuration items and characteristics in accordance with MIL-STD-973 and RSA-MIL-STD-176.

4.2.4.2 Numbering System

The CONTRACTOR shall develop a numbering system, which shall be approved by ARMSCOR’s programme manager for the identification of configuration items and their corresponding documentation and shall ensure configuration traceability.

The CONTRACTOR’s numbering system for CI’s shall be traceable to the relevant WBS.

4.2.4.3 Specification Tree

The CONTRACTOR shall develop a specification tree for approval by ARMSCOR’s programme manager, using UDI-E-20235 as a guideline, and which shall define the primary items of hardware and software.

4.2.4.4 Documentation Plan

Not applicable.

4.2.5 Configuration Management Records and Reports

The CONTRACTOR shall maintain the following configuration records and reports:

- A configuration change status report, which contains full details of approval and implementation on all engineering changes, deviations and concessions (waivers);

- A MRI status report, indicating the full document detail and status;

- Build history records for all contractual hardware items. The build history records shall contain at least the following:

- An index agreed upon with the programme manager;

- As-built MRI;



- Full technical information on each deviation and concession (waiver) from the MRI applicable to the item, as well as all serial / lot numbers of the equipment to which these deviations / concessions (waivers) have been applied; and

- Test / Inspection results.

4.2.6 Configuration Control

The CONTRACTOR shall control changes to approved baseline documents in accordance with MIL-STD-973.

4.2.6.1 Engineering Changes

The CONTRACTOR shall classify engineering change proposals (ECP’s) into class I or class II in accordance with MIL-STD-973.

The CONTRACTOR shall submit, with sufficient supporting documentation, to ARMSCOR, on form K217, or an agreed upon alternative, class I engineering change proposals for consideration and decision-making and class II changes for concurrence of classification.

4.2.6.2 Deviations

The CONTRACTOR shall classify all deviations as critical, major or minor, in accordance with MIL-STD-973.

The CONTRACTOR shall submit to ARMSCOR, on form K228, or an agreed upon alternative, critical, major or minor deviations for consideration and decision-making, unless otherwise delegated.

4.2.6.3 Concessions (Waivers)

The CONTRACTOR shall classify all concessions (waivers) as critical, major or minor, in accordance with MIL-STD-973. The CONTRACTOR shall submit to ARMSCOR, on form K227, an agreed upon alternative, critical, major or minor classified concessions (waivers), for consideration and decision-making, unless otherwise delegated.

4.2.6.4 Configuration Control Board (CCB)

The CONTRACTOR shall establish a CCB qualified to advise the CONTRACTOR’s programme manager. ARMSCOR’s programme manager shall be entitled to attend these board meetings.

The CONTRACTOR’s CCB shall be responsible for:

- Reviewing and determining a need for change (unless the change originated from ARMSCOR);

- Determining total change impact;

- Approving submission of a change proposal to ARMSCOR, including specification Change Notices (SCN’s) and Interface Revision Notices (IRN’s); and

- Approving changes to sub-contractors’ controlled baselines and documents.

Minutes of the CCB shall accompany all proposed changes.



4.2.6.5 Material Review Board (MRB)

The CONTRACTOR shall establish a MRB composed of qualified technical representatives to advise the CONTRACTOR’s programme manager on the disposition of non-conforming material.

4.2.7 Configuration Verification

The CONTRACTOR shall plan and execute formal technical audits using the guidelines laid down in MIL-STD-973. The physical configuration audit shall be conducted prior to qualification testing. The functional configuration audit shall include an audit of qualification tests on CI’s.

4.2.8 Security of Data

4.2.8.1 Archive

The CONTRACTOR shall maintain an archive for the storage and safekeeping of all formal development, build and production documentation for a period agreed upon with ARMSCOR.

This shall include masters of each previous and present issue of each document pertaining to the programme.

4.2.8.2 Physical Security

i. Documentation

The CONTRACTOR shall maintain a duplicate set of masters of all documentation at a remote secure site. The CONTRACTOR shall, at least once monthly, transfer a master of all new or updated documentation to the secure site.

ii. Computer Software

The CONTRACTOR shall maintain at all times at least three copies of all operating systems, utilities, compilers, application programmes, command and/or data files required for the development, production or operation of equipment. Copies of both source and object data shall be retained in machine-readable form and shall include:

- As many copies of all the software as are required for the development, production or operation of the system;

- At least the following back-up copies of all software, including software currently under development:

- One copy shall be retained at the development site and shall at no time be older than one week;

- One copy shall be retained at a secure remote site (not less than 500 metres from the development site) and shall at no time be older than one week;

- One copy shall be retained at a secure remote site (not less than 500 metres from the development site) and shall at no time be older than two weeks.

The CONTRACTOR shall have a strategy in place to prevent loss of usefulness of computer software due to technology changes and ageing.



4.2.9 Handover of Documentation to ARMSCOR

The CONTRACTOR shall retain masters of all documentation relating to the system developed by the CONTRACTOR until the date on which all CONTRACTOR involvement in any form whatsoever ceases or until otherwise instructed.

On that date, the CONTRACTOR shall hand over to ARMSCOR a complete set of all masters of documentation in a suitable medium acceptable to ARMSCOR.

5 TECHNICAL PERFORMANCE ACHIEVEMENT

5.1 RISK MANAGEMENT

Not applicable.

5.2 TECHNICAL PERFORMANCE MEASUREMENT (TPM)

Not applicable.

5.3 FORMAL REVIEWS

The CONTRACTOR shall plan and conduct formal technical reviews, using the guidelines laid down in MIL-STD-973 and RSA-MIL-HDBK-176. See section 6.4.4 for production readiness review.

ARMSCOR’s programme manager reserves the right to include additional members of his choice on the Technical Review Board.

5.3.1 Technical Review Agenda

Technical Review Agendas shall be prepared, using DI-ADMN-81249 as a guideline, and containing at least the item identification, date, location, time of review and individual topics being reviewed.

5.3.2 Technical Review Data Package

The CONTRACTOR shall submit, together with the agenda, to all the members of the Technical Review Board, the relevant documentation.

The documentation shall contain at least the following:

- Specifications;

- Configuration and layout drawings;

- Analysis and simulation reports;

- Plans;

- Reliability, maintainability and availability data;

- Survivability and vulnerability data;

- Verification data;

- Master Record Index (MRI); and



- Any other relevant documents.

5.3.3 Technical Review Meeting Minutes

The CONTRACTOR shall prepare and distribute minutes of technical review meetings, using DI-ADMN-81250 as a guideline, to all members of the Design Review Board and other persons as may be deemed necessary.

The minutes shall at least include the following:

- Summary of significant comments, findings, decisions and directions provided at the meeting, with rationale, where appropriate;

- Meeting agenda;

- List of data package contents;

- List of attendees;

- Action items with responsibilities and due dates; and

- List of presentation material.

5.4 VERIFICATION AND VALIDATION OF DESIGN

5.4.1 Qualification Principles

The CONTRACTOR shall qualify systems and items in accordance with the principles set out in RSA-MIL-PRAC-190 (Part 1), section 4. The qualification process shall be an integral part of the system assurance process - as described in RSA-MIL-PRAC-190 (Part 1), section 5. The essential elements of the process shall be clearly addressed and referred to in the CONTRACTOR’s Programme Plan or Quality Assurance Plan.

5.4.2 Test and Evaluation and Qualification Planning

The CONTRACTOR shall plan to demonstrate conformance to design and qualification requirements.

NOTE: RSA-MIL-STD-257, RSA-MIL-STD-105, part 6 and DOD-5000.3-M-1 may be used as a guideline in developing the TEMP.

5.4.3 Design Qualification

The CONTRACTOR shall, before the start of the Industrialization Phase, formally qualify the design in accordance with documented test and evaluation plans. A qualification report shall be generated and kept under configuration control.

5.4.4 Simulation Model

Not applicable.

5.4.5 Specification Validation

The CONTRACTOR shall validate that all the development and product specifications generated, sufficiently specify:



- The system to meet the next higher level specifications; and

- The qualification test methods (in paragraph 4 of the specification according to the format of MIL-STD-490), before inclusion into the relevant baseline.

NOTE: Qualification test methods or reference thereto, for each requirement shall be an integral part of development specifications. The CONTRACTOR shall address all requirements in part 3 of the specification. This will preferably be done by way of a qualification cross reference matrix. The development specification must define a standard for successful qualification by specifying the type and extent of testing required, as well as sentencing criteria.

6 OPERATIONAL FEASIBILITY AND OPTIMISATION

6.1 ENGINEERING SPECIALITY INTEGRATION

6.1.1 Reliability Engineering

The CONTRACTOR shall demonstrate conformance to reliability requirements as agreed upon with ARMSCOR’s programme manager, prior to placement of ORDER.

6.1.2 Maintainability Engineering

The CONTRACTOR shall demonstrate conformance to maintainability requirements as agreed upon with ARMSCOR’s programme manager, prior to placement of ORDER.

6.1.3 System Safety

Not applicable.

6.1.4 Standardisation and Parts Control

Not applicable.

6.1.5 Human Engineering

Not applicable.

6.1.6 Electro-magnetic Compatibility (EMC) and Electro-magnetic Interference (EMI)

The CONTRACTOR shall ensure that Client-furnished equipment (CFE) and materiel designed and/or purchased by the CONTRACTOR is not detrimentally affected by electro-magnetic emissions generated:

- Within the materiel; and

- By its intended operating environment.

Any deviations beyond the control of the CONTRACTOR shall be made visible to ARMSCOR in writing.



Stray emissions of equipment supplied / designed by the CONTRACTOR shall not exceed those specified in MIL-STD-461, or such standard or specification as agreed upon and shall be tested in accordance with MIL-STD-462. RSA-MIL-HDBK-121 shall be used as a guideline for the implementation of MIL-STD-461 and MIL-STD-462. The CONTRACTOR shall submit a TEMP to ARMSCOR’s programme manager for approval. The TEMP shall include an EMI test plan, using DI-EMCS-80201 as a guideline.

6.1.7 Value Engineering

Not applicable.

6.1.8 Nuclear, Biological and Chemical Protection

Not applicable.

6.1.9 Thermal Analysis / Design

Not applicable.

6.1.10 Classification of Characteristics and Failures

The CONTRACTOR shall classify all design characteristics and failures into critical, major or minor, using DOD-STD-2101 as a guideline. The CONTRACTOR shall, with ARMSCOR’s programme manager’s approval, incorporate such classification into the various specifications, performance standards, engineering drawings, inspections and test procedures.

6.2 SYSTEM AND COST EFFECTIVENESS

Not applicable.

6.3 LOGISTIC ENGINEERING

6.3.1 Logistic Support Analysis (LSA)

Not applicable.

6.3.2 Interchangeability and Compatibility

The CONTRACTOR shall ensure that items and parts bearing the same number are fully interchangeable with regard to form, fit and function.

Any assembly, sub-assembly, module or part, which requires setting up, realignment or matching to restore full system capability, shall be clearly identified and clearly highlighted in technical and maintenance manuals.

6.3.3 Codification

The CONTRACTOR shall submit a report for ARMSCOR consideration, giving a Recommended Spare Parts List (RSPL) (DD 1376) of items to be codified in support of the system. These items shall be stocked or purchased. The item information for these items must be that of the original manufacturer.

The LSA, system architecture, other relevant engineering data and the proposed levels of support (maintenance) shall be used to motivate the items proposed.



All servicing equipment, spares and materiel, as agreed upon with ARMSCOR for maintenance, including all associated equipment and items, shall be codified in accordance with RSA-MIL-SPEC-47, the National Codification System (NCS) and/or the NATO Codification System (NATOCS). The agreed equipment / spares and materiel shall be supported by the necessary documentation (i.e. product specifications, drawings, etc).

In the event of servicing equipment, spares or materiel that have not been codified, the CONTRACTOR shall submit with his quotation, or as detail becomes available during the Development Phase, item information for codification.

6.3.4 Logistic Support Analysis Report

Not applicable.

6.4 PRODUCTION ENGINEERING

The CONTRACTOR shall perform production engineering, phased in accordance with RSA-MIL-STD-3 as an integral part of the system engineering process, using The System Engineering Management Guide of the Defence Systems Management College as a guideline.

The CONTRACTOR shall submit a Production Engineering plan to ARMSCOR’s programme manager for approval at the commencement of each programme phase. The plan shall sufficiently address the way in which Process Qualification will be performed and validated, using RSA-MIL-PRAC-190 Part 2 and DOD-5000.38 as a guideline.

The CONTRACTOR shall qualify all production processes prior to commencement of production, taking cognisance of the importance of each process based upon the classification of characteristics.

6.4.1 Production Engineering Analysis

Not applicable.

6.4.2 Production Processes

The CONTRACTOR shall demonstrate to ARMSCOR’s programme manager before production may commence (during the Industrialization Phase) the adequacy of his production processes and the process control methods introduced to meet the requirements of the ORDER.

6.4.3 Production Plan

The CONTRACTOR shall establish and agree with ARMSCOR’s programme manager, prior to the Production Readiness Review (PRR) upon a Production Plan, using DI-MISC-80074 as a guideline.

6.4.4 Production Readiness Review (PRR)

The CONTRACTOR shall, prior to the start of production, conduct a Production Readiness Review (PRR), using DOD-5000.38 as a guideline.



6.5 SOFTWARE ENGINEERING

The CONTRACTOR shall have a software Development Management System which conforms to principles in MIL-STD-498 with the necessary controls to ensure that the software product meets the contractual requirements. The Management System shall address software from the product and system point of view during the Software Development Life Cycle (SDLC).

The CONTRACTOR can agree with ARMSCOR to use ISO/IEC 12207, instead of MIL-STD-498, for Software development. Should this be the case, the DIDs from MIL-STD-498, as specified below in the sub-paragraphs of 6.5, shall be used as guidelines.

Software developed shall be phased in accordance with RSA-MIL-STD-3. The software development process shall at least include the following:

6.5.1 Establishing a Software Development Environment

The CONTRACTOR shall establish a software development environment to address:

- Software engineering environment;

- Software test environment;

- Software development library;

- Software development files; and

- Non-deliverable Software.

The CONTRACTOR shall develop a Software Development Plan (SDP) which shall at least describe the development process up to commissioning, standards/methodologies to be followed, all phases/builds during development, reviews that will take place, etc, using DI-IPSC-81427 as a guideline. Software quality assurance and software configuration management shall be adequately addressed, either included into the SDP, or separately addressed in the program’s Quality Assurance Plan (QAP) and Configuration Management Plan (CMP).

The CONTRACTOR may use non-deliverable software in the development of deliverable software as long as the operation and support of the deliverable software after delivery do not depend on the non-deliverable software. Otherwise the CONTRACTOR shall ensure that provision is made that ARMSCOR has or can obtain the same software. The CONTRACTOR shall ensure that all non-deliverable software used on the project performs its intended functions.

6.5.2 System Requirements Analysis

The CONTRACTOR shall conduct an analysis of the requirements and interfaces to be met by the system and the methods to be used to ensure that each requirement has been met. This should be documented into a System/Subsystem Specification (SSS), using DI-IPSC-81431 as a guideline.

Unless specifically otherwise required in the CDRL, requirements concerning system interfaces may be included in the SSS or in Interface Requirements Specifications (IRSs), using DI-IPSC-81434 as a guideline. One specification document is required as a minimum, either a SSS or a Software Requirements Specification (SRS).



The SSS, if generated, shall be formally reviewed (refer paragraph 5.3 on Formal Reviews) and presented to ARMSCOR for approval.

6.5.3 System Design

The CONTRACTOR shall conduct the system’s design, defining the system-wide design decisions (that is, decisions about the system’s behaviour design and identifying the different Computer Software Configuration Items (CSCIs)) and the system’s architectural design. The result should be documented in a System/Subsystem Design Description (SSDD), using DI-IPSC-81432 as a guideline.

Unless specifically otherwise required in the CDRL, no separate document needs to be generated and the contents can be included into the SSS. Design pertaining to interfaces may be included in the SSDD/SSS or in Interface Design Descriptions (IDDs), using DI-IPSC-81436 as a guideline.

The CONTRACTOR’s system engineer responsible for the overall system shall approve the SSDD. The SSDD shall be reviewed internally by the CONTRACTOR.

6.5.4 Software Requirements Analysis

The CONTRACTOR shall define and record the software requirements to be met by the CSCI, the methods to be used to ensure that each requirement has been met and the traceability between the CSCI requirements and system requirements. The results should be documented in Software Requirements Specifications (SRSs), for each of the CSCIs identified in the SSDD, using DI-IPSC-81433 as a guideline.

Unless specifically otherwise required in the CDRL, and if a SSS was generated, SRSs might not be required. Requirements concerning CSCI interfaces may be included in SRSs/SSSs or in IRSs.

The SRS, if generated, shall be reviewed and presented to ARMSCOR for approval.

6.5.5 Software Design

6.5.5.1 Preliminary Design

The CONTRACTOR should conduct a top-level design for each of the SRSs, defining the CSCI-wide design decisions (that is, decisions about the CSCIs behaviour design and other decisions affecting the selection and design of the software units comprising the CSCI) and the CSCIs architectural design. The result shall be recorded in the SDF as design notes.

The CONTRACTOR shall compile a test philosophy and record it in the SDF.

6.5.5.2 Detail Design

The CONTRACTOR shall develop a detailed design from the SSS/SRS and top-level design and include the design notes in the SDF. Design pertaining to interfaces shall also be included into the SDF.

The CONTRACTOR shall conduct a Critical Design Review for all CSCIs identified with minutes of all relevant comments and action items outstanding.



6.5.6 Coding and Unit Testing

The CONTRACTOR shall develop the code from the design and perform informal structural and functional tests.

The CONTRACTOR shall compile a Software Test Description (STD) (or Acceptance Test Plan (ATP) Document), using DI-IPSC-81439 as a guideline, for system testing and acceptance.

The CONTRACTOR shall conduct code reviews, addressing at least the adherence to maintainability coding standards (indents, comments, headers, etc). Track shall be kept of issues raised at these reviews and it shall be recorded for reference and included in the SDF.

6.5.7 Unit Integration and CSCI Testing

The CONTRACTOR shall integrate the units and perform informal functional testing design and requirements. Prove of these tests shall be kept for future reference (typically in the SDF). The CONTRACTOR shall inform ARMSCOR about the test results and status thereof.

6.5.8 CSCI/HWCI Integration and Testing

The CONTRACTOR shall integrate the CSCI/HWCIs and perform functional testing against system requirements against an approved ATP.

The CONTRACTOR shall conduct a TRR before formal testing commences to ensure readiness for formal testing/acceptance.

The CONTRACTOR shall generate a test report which must be included or referred to in the SDF. ARMSCOR shall approve the format beforehand otherwise DI-IPSC-81440 must be used as a guideline. The CONTRACTOR shall present the test results to ARMSCOR for acceptance.

6.5.9 Software Version Description (SVD)

Project-, Make- or Build Files used to compile/link the software shall be required as substitute to the SVD. This shall be included in the SDF. If this cannot be provided, the CONTRACTOR shall ensure that each formal build shall be accompanied by a SVD, using DI-IPSC-81442 as a guideline, which identifies and describes a software version consisting of one or more CSCIs.

6.5.10 Software Development File (SDF)

The contractor shall maintain SDF’s as described in MIL-STD-498, which shall be under formal configuration management.



7 QUALITY MANAGEMENT

7.1 CONTRACTOR’S QUALITY MANAGEMENT SYSTEM

The CONTRACTOR shall maintain a Quality Management System and demonstrate its conformance to ISO 9001 before commencement of CONTRACT.

ARMSCOR shall have the right to carry out periodic audits of the CONTRACTOR’s management of quality, as well as specific product and CONTRACT audits.

7.2 QUALITY PLAN

Not applicable.

7.3 QUALITY REPORTS

The CONTRACTOR shall submit to ARMSCOR, in an agreed upon format, at intervals agreed upon with ARMSCOR’s programme manager a report, containing:

- Management summary;

- Product / System quality conformance;

- Process quality conformance;

- Level of conformance to ISO 9001;

- Outstanding corrective actions; and

- Summary of latest internal audit reports.

7.4 RIGHT OF ACCESS

ARMSCOR or persons designated by him shall have free access to all relevant sections of the place or places where work is performed to fulfil the requirements of the ORDER, for the purpose of conducting / witnessing any audits, inspections or tests.

7.5 ACCEPTANCE AUTHORITY

ARMSCOR shall be the acceptance authority in terms of the ORDER.

7.6 QUALITY OF SUPPLIES

The CONTRACTOR shall be responsible for all controls, reviews, audits, inspection and tests necessary to demonstrate the acceptability of all MATERIAL / WORK covered by the ORDER.

7.7 CONTROL OF INSPECTION, MEASURING AND TEST EQUIPMENT

The CONTRACTOR shall ensure and demonstrate the adequacy of inspection, measuring and test equipment used by the CONTRACTOR to demonstrate conformance to the specified requirements. Inspection, measuring and test equipment shall be calibrated and used in a manner which ensures that the measurement uncertainty is known and is consistent with the required measurement capability. Traceability to national calibration standards shall be maintained and on request, be demonstrated.



7.8 ACCEPTANCE / FORMAL TEST AND EVALUATION

Acceptance / Formal test and evaluation shall be undertaken at a venue agreed upon with ARMSCOR’s programme manager. The CONTRACTOR shall notify ARMSCOR of such acceptance / formal test and evaluation dates at least five (5) working days or such periods agreed prior to the date of such acceptance / formal test and/or evaluation.

7.9 ACCEPTANCE

MATERIEL shall be accepted by ARMSCOR’s programme manager or his representative by means of an Inspection Release Certificate (form K225) or an agreed upon alternative, once the following conditions have been met:

- Certificate of Conformance / Analysis has been issued, providing objective evidence that the MATERIEL conforms to the requirements of the ORDER and has been controlled in terms of the quality plans agreed upon. The certificates shall be issued and signed by an authorized representative of the CONTRACTOR agreed upon with ARMSCOR’s programme manager, and shall include all concessions (waivers) and deviations from the ORDER; and

- ARMSCOR’s programme manager or his representative has satisfied himself that the MATERIEL conforms to the ORDER.

MATERIEL which is found not to conform to specified requirements shall be rejected by means of an Inspection Rejection Note (form K226). The reasons for rejection and the requirements necessary for re-submission will be stated on the Inspection Rejection Note.

7.10 SOFTWARE QUALITY ASSURANCE

The CONTRACTOR shall, when software development is included in the ORDER, update his Quality Management System to also conform to DOD-STD-2168.

7.11 QUARANTINE SYSTEM

The CONTRACTOR shall provide and maintain a quarantine system.

Any MATERIEL which is found on inspection not to conform to specified requirements, shall be placed in quarantine and shall be marked or labelled.

Items placed in quarantine shall only be released for use when a concession (waiver) has been authorized in terms of the ORDER.

Items, for which application for a concession (waiver) has been refused, shall be released from quarantine for disposal or rework purposes only.

Adequate records of all items placed in and removed from quarantine shall be kept. These records shall be made available to ARMSCOR on his request.

7.12 CORRECTIVE AND PREVENTIVE ACTION SYSTEM

The CONTRACTOR shall provide and maintain a corrective and preventive action system. The CONTRACTOR shall act promptly on corrective action requests issued by ARMSCOR.



7.13 CONTROL OF QUALITY RECORDS

The CONTRACTOR shall provide and maintain a quality record system. Quality records shall be maintained to demonstrate conformance to specified requirements and the effective operation of the quality system. Pertinent quality records of sub-contractors shall be an element of this data.



FIGURE 1: TYPICAL PLAN TREE, SPECIFICATION TREE AND WORK BREAKDOWN STRUCTURE RELATIONSHIP FOR COMPLEX SYSTEMS

SUMMARYWBS

SUMMARYWBS

PROJECTSUMMARY

WBS

PRELIM.CWBS

CONTRACTWBS

EXTEND.WBS

USERSYSTEMMASTER

PLAN

PRODUCTSSYSTEM

PROGRAMMASTER

PLAN

SEGMENT1

HARDWARE

SEGMENT2

HARDWARE

SEGMENT3

HARDWARE

CONTRACT1

DEFINITION

CONTRACT2

DEFINITION

CONTRACT3

DEFINITION

USERREQMTS

SPEC

PRODUCTSSYSTEMTYPE ASPEC

SEGMENT1

TYPE ASPEC

SEGMENT2

TYPE ASPEC

SEGMENT3

TYPE ASPEC

SEGMENT2

TYPE BSPEC

SEGMENT2

TYPE CSPEC

SEGMENT2

TYPE DSPEC

SEGMENT2

TYPE ESPEC

NOTE: WORK ON HARDWARE / SOFTWARE SEGMENTS ARE DEFINED BY STATEMENTS OF WORK AND SPECIFICATIONS

WORK BREAKDOWN STRUCTURE PLAN TREE SPECIFICATION TREE



ANNEXURE A: REFERENCES

A-STD-0020 Armscor’s General Conditions of Contract

DI-ADMN-81249 Conference Agenda

DI-ADMN-81250 Conference Minutes

DI-EMCS-80201 Electro-magnetic Interference Test Plan

DI-IPSC-81427 Software Development Plan (SDP)

DI-IPSC-81431 System / Sub-system Specification (SSS)

DI-IPSC-81432 System / Sub-system Design Description (SSDD)

DI-IPSC-81433 Software Requirements Specification (SRS)

DI-IPSC-81434 Interface Requirements Specification (IRS)

DI-IPSC-81436 Interface Design Description (IDD)

DI-IPSC-81439 Software Test Description (STD)

DI-IPSC-81440 Software Test Report (STR)

DI-IPSC-81442 Software Version Description (SVD)

DI-MISC-80074 Manufacturing Plan

DOD-5000.3-M-1 Test and Evaluation Master Plan

DOD-5000.38 Production Readiness Review

DOD-STD-2101 Classification of Characteristics

UDI-E-20235 Specification Tree

K-STD-0003 Standaard vir MRI’s

MIL-STD-470 Maintainability Program for Systems and Equipment.

MIL-STD-490 Specification Practices.

MIL-STD-973 Configuration Management.

MIL-STD-1629 Procedure for Performing a Failure Mode Effects and Criticality Analysis.

RSA-MIL-HDBK-121 Electro-magnetic Compatibility - Guideline for Implementation of MIL-STD’s 461 and 462.

RSA-MIL-PRAC-190 Praktyk vir die Kwalifikasie van Stelsels.

RSA-MIL-STD-105 The Engineering of Reliable and Maintainable Systems.

RSA-MIL-STD-257 Test and Evaluation Master Plan (TEMP), Preparation of.



ANNEXURE B: TAILORING GUIDELINES FOR TECHNOLOGY DEVELOPMENT

Although contracts, for the fulfilment of technology projects, should not be "loaded" with "unnecessary" technical contract conditions which monopolise the time and energy of the researches, it is indeed necessary to consider what the minimum requirements should be under specific circumstances.

The two extremes of the spectrum, as depicted by FIGURE 2, that currently exist are:

- a "skunk works" environment, where flexibility and in-time rate adjustments are the norm, vs.

- a typical development program, where fixed baselines are formally identified and managed against fixed timescales; and this will form the basis of control which will be exercised over the program.

FIGURE 2

FIGURE 2: SCOPE FOR THE APPLICATION OF STANDARDS ON PROJECTS

Given the window of the technology environment within the abovementioned spectrum, one can now look at:

- “Fundamental” research on the one side, vs

- Technology projects, of which the deliverables have advanced beyond the stage of research/study, up to the point where a physical demonstrator will be built. (Indications that the project will move into Acquisition).

An objective which should at all times be adhered to in the Technology environment is the maintenance of good engineering practices and disciplines, which should result in logically structured and available results.

Thus, taking into consideration the “nature” of research and the ability of the relevant Research- and Development authority, appropriate standards and requirements should be applied.

Other obvious valid aspects are things such as accountability/transparency and “propagation” of Technology.

NOTE: One, or more, of these aspects may implicate that stricter requirements than normal apply under certain circumstances.

Taking into account all of the above principles, the following matrix is suggested as a point of departure:

FEW MANY

“SKUNK”WORKS

FUNDAMENTAL RESEARCH

DEMONSTRATOR TECHNOLOGY

FORMAL ACQUISITION

FEW MANY

“SKUNK”WORKS

FUNDAMENTAL RESEARCH

DEMONSTRATOR TECHNOLOGY

FORMAL ACQUISITION



TABLE 1: TAILORING MATRIX FOR TECHNOLOGY DEVELOPMENT

Part Paragraph Description Tailoring Guide

1. GENERAL

1.1 APPLICABILITY OF DOCUMENTS Applicable

1.2 DOCUMENTS Applicable

1.2.1 Applicable Documents Applicable

1.2.2 Reference Documents Applicable

1.3 DEFINITIONS Applicable

1.4 GENERAL NOTES Applicable

2. ENGINEERING MANAGEMENT

2.1 ORGANISATION Applicable

2.1.1 Programme / Project Management Organisation Tailored Application

2.1.2 List of Major Sub-contractors Not Applicable

2.1.3 Appointment of Personnel to Committees, Boards and Work Groups

Not Applicable

2.2 PLANNING Applicable

2.2.1 Information for Summary Work Breakdown Structure Tailored Application

2.2.2 Contract Work Breakdown Structure (CWBS) Not Applicable

2.2.3 Work Breakdown Structure (WBS) Dictionary and Statement of Work (SOW)

Not Applicable

2.2.4 Plan Tree and Contract Data Requirements List (CDRL) Not Applicable

2.2.5 Programme Master Plan (PMP) Not Applicable

2.2.6 Programme Report Not Applicable

2.2.7 Cost and Schedule Planning and Control Not Applicable

2.3 CONTROL Applicable

2.3.1 Establishment of Resource Management Control Systems Not Applicable

2.3.2 Resource Management System Demonstration and Audit Not Applicable

2.3.3 Reporting Tailored Application

2.3.4 Monthly progress meeting Not Applicable

2.3.5 ARMSCOR’s representative facilities Applicable





3. SYSTEM ENGINEERING PROCESS Not Applicable

4. CONFIGURATION DEFINITION AND MANAGEMENT

4.1 GENERATION OF SPECIFICATIONS Tailored Application

4.2 CONFIGURATION MANAGEMENT REQUIREMENTS Applicable

4.2.1 General Applicable

4.2.2 Configuration Management Plan Not Applicable

4.2.3 Baseline Audits Tailored Application

4.2.4 Configuration Identification Tailored Application

4.2.5 Configuration Management Records and Reports Tailored Application

4.2.6 Configuration Control Tailored Application

4.2.7 Configuration Verification Tailored Application

4.2.8 Security of Documentation Tailored Application

4.2.9 Handover of Documentation to ARMSCOR Applicable

5. TECHNICAL PERFORMANCE ACHIEVEMENT

5.1 RISK MANAGEMENT Not Applicable

5.2 TECHNICAL PERFORMANCE MEASUREMENT (TPM) Not Applicable

5.3 FORMAL REVIEWS Tailored Application

5.3.1 Technical Review Agenda Applicable

5.3.2 Technical Review Data Package Tailored Application

5.3.3 Technical Review Meeting minutes Applicable

5.4 VERIFICATION AND VALIDATION OF DESIGN Applicable

5.4.1 Qualification Principles Tailored Application

5.4.2 Test and Evaluation and Qualification Planning Tailored Application

5.4.3 Design Qualification Tailored Application

5.4.4 Simulation Model Validation Not Applicable

5.4.5 Specification Validation Tailored Application





6. OPERATIONAL FEASIBILITY AND OPTIMISATION

6.1 ENGINEERING SPECIALTY INTEGRATION Applicable

6.1.1 Reliability Engineering Tailored Application

6.1.2 Maintainability Engineering Tailored Application

6.1.3 System Safety Not Applicable

6.1.4 Standardisation and Parts Control Not Applicable

6.1.5 Human Engineering Not Applicable

6.1.6 Electro-magnetic Compatibility (EMC) and Electro-magnetic Interference (EMI)

Tailored Application

6.1.7 Value Engineering Not Applicable

6.1.8 Nuclear, Biological and Chemical Protection (NBC) Not Applicable

6.1.9 Thermal Analysis / Design Not Applicable

6.1.10 Classification of Characteristics and Failures Tailored Application

6.2 SYSTEM AND COST EFFECTIVENESS Not Applicable

6.3 LOGISTIC ENGINEERING Applicable

6.3.1 Logistic Support Analysis (LSA) Not Applicable

6.3.2 Interchangeability and Compatibility Tailored Application

6.3.3 Codification Tailored Application

6.3.4 Logistic Support Analysis Report Not Applicable

6.4 PRODUCTION ENGINEERING Applicable

6.4.1 Production Engineering Analysis Not Applicable

6.4.2 Production Processes Tailored Application

6.4.3 Production Plan Tailored Application

6.4.4 Production Readiness Review (PRR) Tailored Application

6.5 SOFTWARE ENGINEERING Applicable

6.5.1 Establishing a Software Development Environment Tailored Application

6.5.2 System Requirements Analysis Applicable

6.5.3 System Design Tailored Application

6.5.4 Software Requirements Analysis Tailored Application

6.5.5 Software Design Tailored Application





6.5.6 Coding and Unit Testing Applicable

6.5.7 Unit Integration and CSCI Testing Tailored Application

6.5.8 CSCI / HWCI Integration and Testing Tailored Application

6.5.9 Software Version Description (SVD) Tailored Application

6.5.10 Software Development File (SDF) Tailored Application

7. QUALITY MANAGEMENT

7.1 CONTRACTOR’S QUALITY MANAGEMENT SYSTEM Tailored Application

7.2 QUALITY PLAN Not Applicable

7.3 REPORTS Tailored Application

7.4 RIGHT OF ACCESS Applicable

7.5 ACCEPTANCE AUTHORITY Applicable

7.6 QUALITY OF SUPPLIES Applicable

7.7 CONTROL OF INSPECTION, MEASURING AND TEST EQUIPMENT

Applicable

7.8 ACCEPTANCE / FORMAL TEST AND EVALUATION Applicable

7.9 ACCEPTANCE Applicable

7.10 SOFTWARE QUALITY ASSURANCE Applicable

7.11 QUARANTINE SYSTEM Not Applicable

7.12 CORRECTIVE AND PREVENTIVE ACTION SYSTEM Applicable

7.13 CONTROL OF QUALITY RECORDS Applicable



APPENDIX 2: ABBREVIATIONS

ABL Allocated Baseline

ARAR Accident Risk Assessment Report

ATP Acceptance Test Plan

CCB Configuration Control Board

CDR Critical Design Review

CDRL Contractor Data Requirements List

CFE Client-furnished equipment

CI Configuration Item

CIL Critical Item List

CMP Configuration Management Plan

COTS Commercial Off-the-shelf

CSCI Computer Software Configuration Item

CWBS Contract Work Breakdown Structure

DID Data Item Description

DRI Documentation Record Index

DTC Design to Cost

ECP Engineering Change Proposal

EMC Electro-magnetic Compatibility

EMI Electro-magnetic Interference

ESS Environmental Stress Screening

FBL Functional Baseline

FFBD Functional Flow Block Diagram

FMECA Failure Modes, Effects and Criticality Analysis

FRACAS Failure Reports, Analysis and Corrective Action System

IDD Interface Design Description

ILSP Integrated Logistic Support Plan



IRN Interface Revision Notice

IRS Interface Requirements Specification

LCC Life Cycle Cost

LCCE Life Cycle Cost Elements

LPPS Logistics Plan for Pre-operational Support

LSA Logistic Support Analysis

LSAR Logistic Support Analysis Record

MBL Manufacturing Baseline

MRB Material Review Board

MRI Master Record Index

NATOCS NATO Codification System

NBC Nuclear, Biological and Chemical

NCS National Codification System

NEMP Nuclear Electro-magnetic Pulse

OSBL Operational Support Baseline

PBL Product Baseline

PDR Preliminary Design Review

PMP Programme Master Plan

PRAT Production Reliability Acceptance Test

PRR Production Readiness Review

QAP Quality Assurance Plan

RAP Risk Abatement Plan

RAS Requirement Allocation Sheet

RMPP Risk Management Programme Plan

RRR Risk Reduction Report

RSPL Recommended Spare Parts List



SCN Specification Change Notice

SDD Software Design Description

SDF Software Development File

SDLC Software Development Life Cycle

SDP Software Development Plan

SDR System Design Review

SEMP System Engineering Management Plan

SOW Statement of Work

SRBL Statement of Requirements Baseline

SRS Software Requirements Specification

SSDD System/Subsystem Design Description

SSS System/Subsystem Specification

STD Software Test Description

STP Software Test Plan

SVD Software Version Description

TEMP Test and Evaluation Master Plan

TPM Technical Performance Measurement

TRR Test Readiness Review

WBS Work Breakdown Structure