IRAC Preface |
1 Introduction |
2 General Design Objectives |
3 General Syntax and Semantics of the Abstract Specification |
4 Object Management System |
5 Program Execution Facilities |
6 Input and Output |
7 Protection and Security |
8 Requirements for Tool Management and Services for Tools |
9 Ancillary Requirements |
10 Definitions |
Submission of Comments
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
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
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.
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
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
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.