SECTION 9

ANCILLARY REQUIREMENTS

9.1 Evaluation and Validation

9.1A Evaluation. The PCIS should include a means of evaluating the qualities of a PCIS implementation other than conformance to specification.

Examples of the qualities to be evaluated are performance, capacity, usability, and reliability. Judgements of some of these qualities are to some extent subjective but the existence of a defined evaluation capability can reduce the subjectivity to a minimum. Examples of evaluation capabilities in the field of programming languages include the UK MOD Ada Evaluation System (AES) and the USA DoD Ada Compiler Evaluation Capability (ACEC).

9.1B Validation. The PCIS definition should include a means of validating a PCIS implementation for conformance to the specification. A validation suite should be defined for PCIS implementations.

The need for conformance validation of implementations of standards is widely acknowledged; examples for programming languages are the Pascal Validation Suite (PVS) and the Ada Compiler Validation Capability (ACVC). An example for a tool interface set is the CAIS-A Implementation Validation Capability (CIVC).

In order to understand the degree of conformance an implementation has to the PCIS standard, it is desirable that an impartial validation be done. Thus, it is desirable that a validation suite be developed for the PCIS and that a third party be responsible for performing PCIS validations.

9.2 Education and Training

As part of the PCIS Programme, education and training material should be produced for the PCIS.

This is necessary in order to encourage the use of PCIS. Education and training is an important aspect of the PCIS Programme. This form of technology transition applies to a wide variety of environment users, such as programmers, systems administrators, tool writers, and platform suppliers. Managers should also be the target of training materials, including PCIS and environment concepts, benefits and usage. Education and training materials must also address transition paths for potential user organization's adoption of PCIS technology.

The PCIS will be a large and complex set of facilities and mechanisms which will not be easily understood by browsing specifications. A PCIS specification and associated ancillary documentation may encompass several thousand pages. In order to assist users, developers, integrators, and maintainers, of the PCIS itself, tools, and applications, it will be necessary to have a solid programme of education and training.

PCIS sponsors should consider building tutorial and training material as part of the initial PCIS design effort. This will help early tool builders and adopters be ready to use the PCIS implementations.

9.3 Availability

All PCIS Specifications should be in the public domain.

All PCIS specifications shall not be protected by a copyright, and shall be available through appropriate (government) facilities.

Facilities not related directly to the framework or integrational aspects also need to be in the public domain to encourage portable tools and applications. These include operation definitions (so operations are portable between platforms of competing vendors) and communications protocols.

9.4 Non-technical Requirements

9.4A Nationalization. The PCIS shall support the customization of an environment so that one of a variety of natural language conventions can be used to interact with the environment.

It is expected that the market for PSEs and tools will be international. It is desirable that an environment or at least a set of tools be easily customizable to the conventions used in different nations.

9.4B Stability. The PCIS shall preserve investments made in previous PSE and framework Programmes.

It is highly desirable that environment definers and suppliers have their investment preserved, and returns on them are not endangered by over-frequent changes in framework standards.

This requirement recognizes that in order to live and continue to be used framework standards, such as PCIS, must evolve. However, the standards must change gradually over time with stable periods, allowing time for implementations to be developed and used. Frequent, radical changes are discouraged.

Go forward to Section 10, Definitions.