CAOS XML CA SN

Document Sample
CAOS XML CA SN Powered By Docstoc
					DEBAT Development of EAST Based Access Tools
          Product Assurance Plan




Contract : 16562/02/I-LG
Reference : SS/DEBAT/PAP
Issue : 1.2
Date : 08/07/2003

Prepared by :
                                                   Date : 08/07/2003
                Maud Granet


Checked by :
                                                   Date : 08/07/2003
                Christine Maury


Approved by :
                                                   Date : 08/07/2003
                Carlos Guerreiro




                              DEBAT – De velopment of EAST Based Access Tools
                                                                             Reference   : SS/DEBAT/PAP
                                        DEBAT                                Issue       : 1.2
                                 Product Assurance Plan                      Date        : 08/07/2003
                                                                             Page        :i




                             Document Status Sheet

Document Title                               DEBAT Product Assurance Plan
Document Reference Number                            SS/DEBAT/PAP
 Issue  Revision      Date                          Reason for change
   1        0      14/10/2002 First issue
   1        1      31/10/2002 Integration of the remarks of A. CIARLO from ESA
   1        2      08/07/2003 Integration of C++ coding rules and specific controls for the
                              Phase 2.




                           DEBAT – De velopment of EAST Based Access Tools
                                                                              Reference   : SS/DEBAT/PAP
                                         DEBAT                                Issue.      : 1.1
                                  Product Assurance Plan                      Date        : 31/10/2002
                                                                              Page        : ii




                           Document Change Records

Document Title                                   DEBAT Product Assurance Plan
Document Reference Number                                SS/DEBAT/PAP
Document Issue/Revision Number                                  1.2
 Page Paragraph                                Reason for change
  17        8.6     The paragraph Assurance and controls on the code is completed.
  18       8.11     Adding a paragraph for the specific controls lead during the phase 1
18, 19,    8.12     Adding a paragraph for the specific controls lead during the phase 2
 20, 21
        Annex 11 Integration of the C++ coding rules


Document Title                                    DEBAT Product Assurance Plan
Document Reference Number                               SS/DEBAT/PAP
Document Issue/Revision Number                                1.1
 Page Paragraph                                 Reason for change
  5        1.2      Integration of the remarks of A. CIARLO from ESA
  7        2.1                                          “
  8        2.3                                          “
  12      5.2.1                                         “

  20         9.2      Metrics bounds : notion of “goal” value has been added.

Document Title                                DEBAT Product Assurance Plan
Document Reference Number                            SS/DEBAT/PAP
Document Issue/Revision Number                             1.0
 Page Paragraph                              Reason for change
                    Creation of the document




                            DEBAT – De velopment of EAST Based Access Tools
                                                                                                                  Reference     : SS/DEBAT/PAP
                                                            DEBAT                                                 Issue.        : 1.1
                                                     Product Assurance Plan                                       Date          : 31/10/2002
                                                                                                                  Page          : iii




                                                       Table of contents
DOCUMENT STATUS SHEET ............................................................................................................I

DOCUMENT CHANGE RECORDS ................................................................................................. II

TABLE OF CONTENTS .................................................................................................................... III

ACRONYMS AND ABBREVIATIONS ............................................................................................. 1

APPLICABLE DOCUMENTS ............................................................................................................. 4

REFERENCE DOCUMENTS .............................................................................................................. 4

1. INTRODUCTION .............................................................................................................................. 5
   1.1 CONTEXT OF THE DEBAT PROJECT ................................................................................................. 5
   1.2 SCOPE OF THE PAP ........................................................................................................................... 5
   1.3 DEBAT QUALITY OBJECTIVES ......................................................................................................... 5
     1.3.1 Quality factors .......................................................................................................................... 5
     1.3.2 Quality criteria.......................................................................................................................... 6
   1.4 RESPONSIBILITIES RELATED TO THE PAP ........................................................................................ 6
   1.5 PAP EVOLUTION PROCEDURE .......................................................................................................... 6
   1.6 PAP DEVIATIONS PROCEDURE .......................................................................................................... 6
2. DOCUMENTATION MANAGEMENT ......................................................................................... 7
   2.1 DOCUMENTATION IDENTIFICATION .................................................................................................. 7
   2.2 DOCUMENT FORMAT AND PRESENTATION ....................................................................................... 7
   2.3 DOCUMENT APPROVAL, DISTRIBUTION AND MODIFICATION ........................................................... 7
3. CONFIGURATION MANAGEMENT ........................................................................................... 8
   1.1 DEBAT CONFIGURATION MANAGEMENT ........................................................................................ 8
   3.2 CONFIGURATION MANAGEMENT ACTIVITIES ................................................................................... 8
   3.3 CONFIGURATION MANAGED OBJECTS .............................................................................................. 9
   3.4 CONFIGURATION MANAGEMENT ORGANISATION ............................................................................ 9
   3.5 CONFIGURATION IDENTIFICATION .................................................................................................... 9
   3.6 CONFIGURATION FOR SOFTWARE DEVELOPMENT .......................................................................... 10
   3.7 CONFIGURATION MODIFICATION .................................................................................................... 11
   3.8 CONFIGURATION TOOL ................................................................................................................... 11
4. ANOMALIES MANAGEMENT.................................................................................................... 11
   4.1 ANOMALY DEFINITION ................................................................................................................... 11
   4.2 ANOMALY TRACKING ..................................................................................................................... 11
5. METHODS AND TOOLS ............................................................................................................... 11
   5.1 PROJECT MANAGEMENT ................................................................................................................. 11
   5.2 DEVELOPMENT ............................................................................................................................... 12
     5.2.1 Development environment ...................................................................................................... 12
     5.2.2 Requirements........................................................................................................................... 12



                                            DEBAT – De velopment of EAST Based Access Tools
                                                                                                                    Reference      : SS/DEBAT/PAP
                                                             DEBAT                                                  Issue.         : 1.1
                                                      Product Assurance Plan                                        Date           : 31/10/2002
                                                                                                                    Page           : iv


    5.2.3 Specification and design......................................................................................................... 13
    5.2.4 Coding ..................................................................................................................................... 13
    5.2.5 Validation and tests ................................................................................................................ 13
  5.3 TRACEABILITY ................................................................................................................................ 13
6. SUPPLIERS CONTROL ................................................................................................................. 13
  1.1 SUB-CONTRACTORS ........................................................................................................................ 13
  6.2 CO-CONTRACTORS .......................................................................................................................... 13
  6.3 BOUGHT, RENTED, IMPOSED OR RE -USED SOFTWARE .................................................................... 14
    6.3.1 Case of bought software products ......................................................................................... 14
    6.3.2 Case of rented software .......................................................................................................... 14
    6.3.3 Case of imposed software ....................................................................................................... 14
7. REPRODUCTION, PROTECTION, DELIVERY ..................................................................... 14
  1.1 REPRODUCTION .............................................................................................................................. 14
  7.2 PROTECTION ................................................................................................................................... 14
  7.3 DELIVERY ....................................................................................................................................... 14
    7.3.1 Responsibilities ....................................................................................................................... 15
    7.3.2 Delivery procedure ................................................................................................................. 15
8. QUALITY ACTIONS ...................................................................................................................... 15
  8.1 PURPOSE AND RESPONSIBILITIES .................................................................................................... 16
  8.2 MEANS ............................................................................................................................................ 16
  8.3 ORGANISATION ............................................................................................................................... 16
  8.4 CONTROLS ON THE DEVELOPMENT PROCESS ................................................................................. 16
  8.5 CONTROLS ON THE DOCUMENTATION ............................................................................................ 17
  8.6 ASSURANCE AND CONTROLS ON THE CODE ................................................................................... 17
  8.7 CONTROLS ON THE TESTS ............................................................................................................... 18
  8.8 CONTROLS ON THE DELIVERIES ...................................................................................................... 18
  8.9 SOFTWARE PRODUCT ASSURANCE REPORTING ............................................................................ 18
  8.10 QUALITY TRACKING ..................................................................................................................... 18
  8.11 SPECIFIC Q UALITY ACTIONS FOR THE PHASE 1 ........................................................................... 18
  8.12 SPECIFIC Q UALITY ACTIONS FOR THE PHASE 2 ........................................................................... 18
    8.12.1 Type of controls during the Phase 2 .................................................................................... 19
    8.12.2 Control plan .......................................................................................................................... 20
9. ANNEX : BASIC METRICS DEFINITIONS AND BOUNDS FOR CODE CONTROLS .. 22
  1.1 DEFINITIONS ................................................................................................................................... 22
    9.1.1 Metric “Comments frequency” .............................................................................................. 22
    9.1.2 Metric “Number of statements” ............................................................................................ 22
    9.1.3 Metric “Cyclomatic number (VG)” ....................................................................................... 22
    9.1.4 Metric “Number of levels”..................................................................................................... 23
  9.2 BOUNDS PER LANGUAGE ................................................................................................................ 23
10. ANNEX : HEADER COMMENTS.............................................................................................. 24
  1.1 FILES HEADER COMMENTS ............................................................................................................. 24
  10.2 OPERATIONS HEADER COMMENTS ............................................................................................... 24
11. ANNEX : CODING STANDARD RULES ................................................................................. 25



                                            DEBAT – De velopment of EAST Based Access Tools
                                                                                                           Reference     : SS/DEBAT/PAP
                                                       DEBAT                                               Issue.        : 1.1
                                                Product Assurance Plan                                     Date          : 31/10/2002
                                                                                                           Page          :v


11.1 JAVA CODING RULES ................................................................................................................... 25
  11.1.1 asscal : Assignement in function calls (critical) ................................................................. 25
  11.1.2 asscon : Assignement in conditions (critical) ..................................................................... 25
  11.1.3 assexp : Assignement in expressions (critical) ................................................................... 25
  11.1.4 brkcont : Break and continue forbidden (critical).............................................................. 26
  11.1.5 condop : Ternary ?: operator .............................................................................................. 26
  11.1.6 const : Literal constants ....................................................................................................... 26
  11.1.7 dmaccess : Access to members data (critical) .................................................................... 27
  11.1.8 exprcplx : Expressions complexity ...................................................................................... 27
  11.1.9 exprparenth : Parenthesis in expressions ........................................................................... 28
  11.1.10 identl : Identifier length ..................................................................................................... 28
  11.1.11 identres : Reserved identifiers (critical) ........................................................................... 29
  11.1.12 mclass : A single class definition per file .......................................................................... 29
  11.1.13 parse : Parse error ............................................................................................................. 29
  11.1.14 sgdecl : A single variable per declaration ........................................................................ 29
  11.1.15 swdef : default within switch (critical) .............................................................................. 29
  11.1.16 swend : End of cases in a switch (critical)........................................................................ 29
11.2 C++ CODING RULES ...................................................................................................................... 30
  11.2.1 asscal : Assignement in function calls (critical) ................................................................. 30
  11.2.2 asscon : Assignement in conditions (critical) ..................................................................... 30
  11.2.3 assexp : Assignement in expressions (critical) ................................................................... 31
  11.2.4 brkcont : Break and continue forbidden (critical).............................................................. 31
  11.2.5 cmclass : A single class per code file .................................................................................. 32
  11.2.6 condop : Ternary ?: operator .............................................................................................. 32
  11.2.7 const : Literal constants ....................................................................................................... 32
  11.2.8 destr : Destructor (critical) .................................................................................................. 34
  11.2.9 dmaccess : Access to members data (critical) .................................................................... 34
  11.2.10 exprparenth : Parenthesis in expressions ......................................................................... 34
  11.2.11 fntype : Function types ....................................................................................................... 35
  11.2.12 goto : "goto" statement....................................................................................................... 36
  11.2.13 hmclass : A single class definition per header file ........................................................... 36
  11.2.14 hmdef : Header module content ......................................................................................... 37
  11.2.15 hmstruct : Header module structure ................................................................................. 37
  11.2.16 mconst : Macro constant usage ......................................................................................... 38
  11.2.17 mfunc : Inline functions instead of macro functions ........................................................ 39
  11.2.18 mname : File names (critical) ............................................................................................ 40
  11.2.19 parse : Parse error ............................................................................................................. 41
  11.2.20 ptrinit : Pointer initialization (critical) ............................................................................. 41
  11.2.21 sgdecl : A single variable per declaration ........................................................................ 42
  11.2.22 swdef : default within switch (critical) .............................................................................. 42
  11.2.23 swend : End of cases in a switch (critical)........................................................................ 42
  11.2.24 typeres : Reserved types ..................................................................................................... 43
  11.2.25 vararg : Variable number of parameters .......................................................................... 44
  11.2.26 varstruct : struct and union variables ............................................................................... 44
  11.2.27 virtdestr : Virtual destructors ............................................................................................ 45




                                       DEBAT – De velopment of EAST Based Access Tools
                                                              Reference : SS/DEBAT/PAP
                           DEBAT                              Issue     : 1.1
                   Project Assurance Plan                     Date      : 31/10/2002
                                                              Page      :1




          Acronyms and Abbreviations

ADAR     Advanced Data Archive for Earth Observation
ADD      Architectural Design Document
ADID     Authority and Description Identifier: The concatenation of the Control
         Authority Identifier (CAID) and the Data Description Identifier (DDID).
AGF      Advanced Ground Facility
AIP      Archival Information Package
AIS      Advanced Inventory Server
AMOR     Automated MOnitoring, control and Reporting tools
AMS      Archive Management System
API      Application Program Interface
AR       Acceptance Review
ASCESA   An e-Science and Collaborative Environment for Space Applications
ATV
BSSC     ESA’s Board for Software Standardization and Control
CA       Control Authority: An organisation under the auspices of CCSDS which
         supports the transfer and usage of SFDU by providing operational
         services of registration, archiving, and dissemination of data
         descriptions. It comprises: The CCSDS Secretariat supported by the CA
         Agent, and Member Agency Control Authority Offices (MACAO)
CAID     Control Authority Identifier: A four-character restricted-domain ASCII
         string, which identifies an individual CA office or the CCSDS
         Secretariat.
CAO      Control Authority Office
CAOS     Control Authority Office System
CCF      Computer Compatible Format
CCS      Cascading Style Sheets
CCSDS    Consultative Committee for Space Data Systems
CDF      Channel Definition Format
CDR      Critical Design Review
CEOS     Committee on Earth Observation Science
CFI      Customer Furnished Item
CNES
COTS     Commercial off-the-shelf Software
CORBA    Common Object Request Broker Architecture
CPU      Central Processing Unit
DDF      Design Definition File
DDID     Data Description Identifier: A four-character restricted-ASCII string,
         assigned by a MACAO or the CCSDS, to distinguish among descriptions
         with the same CAID
DDL      Data Description Language
DDU      Data Description Unit
DEBAT    Development of EAST Based Access Tools
DED      Data Entity dictionaries
DEDSL    Data Entity Description Specification Language
DIP      Dissemination Information Package


            DEBAT – De velopment of EAST Based Access Tools
                                                                  Reference   : SS/DEBAT/PAP
                             DEBAT                                Issue.      : 1.1
                      Product Assurance Plan                      Date        : 31/10/2002
                                                                  Page        :2


DJF          Design Justification File
DTD          Document Type definition
DW           Data Warehouse
EAST         Enhanced Ada Subset
ECSS         European Cooperation for Space Standardization
EMITS        ESA's Electronic Mail Invitation to Tender System
EO           Earth Observation
ERS          European Remote Sensing satellite
ESA          European Space Agency
ESRIN        European Space Research INstitute
ESTEC
EVA          ESA Virtual Archive
FDIR         Fault Detection, Isolation and Recovery
FMECA        Failure Mode Effect and Criticality Analysis
GS           Ground Segment
GSFC         Goddard Space Flight Center
HiProGenEx   High Level Product Generation and Extraction (ESA development)
HSIA         Hardware Software Interaction Analysis
HTML         Hyper Text Mark-up Language
HW           Hardware
ICD          Interface Control Document
IRB          Interface Requirements Baseline
IRD          Interface Requirements Document
ISI          Internet Storage Infrastructure
ISO          International Organization for Standardization
ISV          Independent Software Validation
ISVV         Independent Software Verification and Validation
ITT          Invitation To Tender
KEO          Knowledge-centric Earth Observation
LAN          Local Area Network
LVO          Label Value Object
MACAO        Member Agency Control Authority Office: An individual CCSDS-
             participating Agency organisation that has accepted the operational
             responsibilities    and     constraints   specified  within    CCSDS
             Recommendations on CA operations.
MAPS         Multi-mission Analysis and Planning Support tool
MF           Maintenance File
MGT          Management
MMI          Man-Machine Interface
MOTS         Modifiable off-the-Shelf
NAS          Network Attached Storage
NASA         National Aeronautics and Space Administration
NJPL         NASA Jet Propulsion Laboratory
NOAA         National Oceanic and Atmospheric Administration
NSSDC        National Space Science Data Center
NUARS        NASA Upper Atmosphere Research Satellite project
OAIS         Open Archival Information System
OASIS        Organisation for the Advancement of Structured Information Standards



                DEBAT – De velopment of EAST Based Access Tools
                                                             Reference   : SS/DEBAT/PAP
                        DEBAT                                Issue.      : 1.1
                 Product Assurance Plan                      Date        : 31/10/2002
                                                             Page        :3


OP      Operational Plan
ORR     Operational Readiness Review
PAC     Processing and Archiving Centres
PAF     Processing and Archiving Facility
PAP     Product Assurance Plan
PDF     Portable Document Format (an Adobe standard)
PDR     Preliminary Design Review
PMP     Project Management Plan
QP      Quality Plan
QR      Qualification Review
RB      Requirements Baseline
RDF     Resource Description Framework
RID     Review Item Discrepancies
RTD     Research and Technology Development
SAN     Storage Area Network
SCMP    Software Configuration Management Plan
SDE     Software Development Environment.
SFDU    Standard Formatted Data Unit: Data that conform to CCSDS SFDU
        Recommendations for structure, construction rules, and field
        specification definition.
SIP     Submission Information Package
SMOG    impact of Small Missions on earth-Observation Ground segment systems
SoW     Statement of Work
SPMP    Software Project Management Plan
SPR     Software Problem Report
SRR     System Requirements Review
SSP     Storage Service Provider
SVG     Scalable Vector Graphics
SW      Software
TM/TC
TS      Technical Specification
W3C     World Wide Web Consortium
WEU     Western European Union
WP      Work Package
WRS     World Reference System
WWW     World Wide Web
XHTML   Extensible Hypertext Mark-up Language
XML     eXtensible Mark-up Language
XSL     Extensible Stylesheet Language
XSLT    Extensible Stylesheet Language Transformation




           DEBAT – De velopment of EAST Based Access Tools
                                                                          Reference   : SS/DEBAT/PAP
                                     DEBAT                                Issue.      : 1.1
                              Product Assurance Plan                      Date        : 31/10/2002
                                                                          Page        :4




                           Applicable Documents

                 Title                      Issue       Date             Reference
AD1 ESRIN SOW “Development of                1.1     18/03/2002 GSPS-RTDA-EOAD-SW-02-0001
    EAST Based Access Tools”

AD2 Fax received from ESA                            07/06/2002 IMT-CR/9021/02/I-LG

AD3 CS SI Proposal "DEBAT"                           21/06/2002 CSSI/111-1/CG/LM/2/453-1

AD4 Minutes of Kick-off Meeting                      17/09/2002 /CRR/SS/DEBAT/001

AD5 ECSS – Space Engineering                                         ECSS-E-40B
    Standards – Software ECSS-E-40B

AD6 CS SI Proposal for Phase 2                       March 2003 CSSI/111-1/CG/PKV/3/140

AD7 Minutes of Phase 2 Kick-off                      30/04/2003 /CRR/SS/DEBAT/006
    meeting (Authorisation To Proceed)




                            Reference Documents

                  Title              Date             Reference
RD1 Statement of Work, GSPS-RTDA- 18/04/2002
    EOAD-SW-02-0001
RD2 DEBAT Project Management Plan 14/10/2002 SS/DEBAT/PMP




                        DEBAT – De velopment of EAST Based Access Tools
                                                                               Reference   : SS/DEBAT/PAP
                                          DEBAT                                Issue.      : 1.1
                                   Product Assurance Plan                      Date        : 31/10/2002
                                                                               Page        :5



1. Introduction

    1.1 Context of the DEBAT project
DEBAT is aimed at building a set of enhanced tools based upon EAST technology to support the
entire data life cycle for various kind of users (scientists, engineers, end-users,…), overcoming the
current limitations and problems, and fulfilling a range of needs expressed by existing or
forthcoming users. The project is also aimed at ensuring the promotion and the diffusion of the
technology.
The DEBAT project is to be carried out in two phases:
     The first one is dedicated to the analysis of the existing EAST tools, theirs limitations and
        the potential enhancements expected by the current users (or potentially interested new
        users) of the technology. This phase ends with the definition of DEBAT perimeter,
        identifying the evolutions that would be most relevant and cost effective (trade-off between
        cost and potential added-value).
     Following the first phase, a negotiation period will permit to reach an agreement with ESA
        about the subset functionalities to be included in the implementation plan. An Authorisation
        To Proceed (ATP) is necessary to start the next phase.
     The second phase covers the implementation of the selected subset and its demonstration.

    1.2 Scope of the PAP
All the software developed in the frame of the project is concerned by the PAP. The reused
software coming from EAST/OASIS is not covered by the PAP.
All the documentation delivered by the CS team is concerned by the PAP.

    1.3 DEBAT quality objectives
The quality objectives are to provide quality assurance and controls for the application of the PAP
for each deliverable produced.
The quality objectives are based on quality factors and criteria.

          1.3.1 Quality factors
The following quality factors will determine project development :
Conformity :          satisfying user requirements
Reliability   :       capacity of the software to operate correctly without incidents
Maintainability:      capacity of the software to facilitate debugging of residual errors in a short
time
Portability :         capacity of the software to minimise the effects of a change of software or
hardware environment, or a change of development language independently of target computers
Operability :         homogeneity and compatibility, conciseness and ease of use
Usability     :       the capacity of the software to be understood, learned, used and liked by the
user, when used under specified conditions
Functionality :       capability of the software product to provide functions which meet stated and
implied needs when the software is used under specified conditions




                             DEBAT – De velopment of EAST Based Access Tools
                                                                               Reference   : SS/DEBAT/PAP
                                          DEBAT                                Issue.      : 1.1
                                   Product Assurance Plan                      Date        : 31/10/2002
                                                                               Page        :6


          1.3.2 Quality criteria
These are software characteristics, which are used to estimate the factors.
The following criteria have been selected for the project :
Traceability :         specifications can be tracked all along the life cycle of the software
Completeness :        all of the components are present and have been correctly described
Consistency :         uniform notation and terminology are used
Robustness :          software can continue a correct functioning even if used in non-provided
conditions
Simplicity     :      development choices are easy to understand and do not needlessly increase
the complexity
Precision      :      the results or effects supplied are just and conform
Modularity :          software is composed of independent elements
Independence in relation to the system : software is not dependent of basic software environment
(operating system, inputs/outputs, utilities, ...)
Independence in relation to the computer : software is not dependent on the specific computer
Auto-description      : characteristic of software that can be used to explain how a function is
developed
Clearness      :      characteristic of software whose inputs and outputs are easy to understand
Ease of use :         characteristic of software for which it is easy to prepare data and interpret
results
Conciseness :         characteristic of software, which has no useless or redundant elements

    1.4 Responsibilities related to the PAP
Author
       The DEBAT quality manager is responsible for writing the DEBAT PAP.
Approval
       The PAP will be approved by the project manager and the quality manager of the
department of CS.
Diffusion
       PAP is a deliverable document.
Application
       The application of the PAP is ensured by the DEBAT project manager.

    1.5 PAP evolution procedure
Different events may induce to modify the content of the PAP, for instance:
     evolution of project characteristics,
     changing of techniques or tools.
The PAP evolution procedure has to be compliant with the documentation management procedure.

    1.6 PAP deviations procedure
The correct application of the PAP is checked by the quality manager or the project manager.
Some discrepancies in the PAP application may appear for different reasons, in that case:
    the discrepancy is justified, so an agreement between the project manager and the quality
       manager may authorise it, but the discrepancy will induce to modify the PAP ;



                             DEBAT – De velopment of EAST Based Access Tools
                                                                               Reference   : SS/DEBAT/PAP
                                          DEBAT                                Issue.      : 1.1
                                   Product Assurance Plan                      Date        : 31/10/2002
                                                                               Page        :7


    the discrepancy is not justified and an action in order to correct it must be launched ; in that
       case the discrepancy will induce to fill an dialog form whose handling is described in the
       anomalies management procedure.
Deviations from the initial PAP are agreed with the ESA Technical Officer.


2. Documentation management
This paragraph defines standard rules and procedures related to the documentation production to
apply all along the project.

    2.1 Documentation identification
Each deliverable document must be referenced with an unique identification number in order to
warranty the uniqueness of the documents.
The nomenclature (Reference name) is defined as:

                                          SS/DEBAT/XXX

where XXX is the acronym name.
Issue following the reference name is defined as:
                                                  x.y
where x is the edition number and y the revision number.
Edition number zero (0) is reserved to draft issues: 0.0, 0.1, 0.2, 0.3,…
For instance:
     SS/DEBAT/PAP Issue 1.1 is the second issue of Product Assurance Plan,
     SS/DEBAT/PMP Issue 0.3 is the third draft version of Project Management Plan.

    2.2 Document format and presentation
A standard frame for the documentation is used in order to obtain an homogeneous documentation.
This frame is provided by CS.
Each document will contain:
     a header page,
     a document status sheet,
     a set of document change records,
     a table of contents and figures,
     a glossary,
     the list of applicable documents and referenced documents,
     and annexes if necessary.
The identification number as well as the name of the document has to be printed on every page of
the documents.
All documents are written in English and are delivered in Microsoft Word 2000 or compatible
systems.

    2.3 Document approval, distribution and modification
The documents are provided in the required number of versions during the course of the project.
For the reviews, documents are delivered at least 5 working days before.



                             DEBAT – De velopment of EAST Based Access Tools
                                                                               Reference   : SS/DEBAT/PAP
                                          DEBAT                                Issue.      : 1.1
                                   Product Assurance Plan                      Date        : 31/10/2002
                                                                               Page        :8


In reviewing documents for formal reviews, the ESA Technical Officer will produce Review Item
Discrepancies (RIDs). For any RID the requested action is either performed or a different closing
action agreed with the ESA Technical Officer.
Any document version ready for delivery is approved with signatures by the CS Project Manager
and then by the ESA Technical Officer or duly authorized delegates by signing a delivery note
provided by CS.
Documents is considered delivered after acceptance by the ESA Technical Officer.
When the actual implementation of any delivered document does not correspond to the original
specification document as result of a traceable and accepted change (as normally occurring in any
project), the document shall be re-issued with the necessary modifications, even if it was prepared
in a different project phase.
When changes are issued, “change bars” are used but not on the header or foot page, on the first
page and on the table of contents (for readability of the changed document).
3. Configuration management

    3.1 DEBAT configuration management
The AFNOR Z61.102 norm defines the configuration management as the whole set of activities
(manual or automatic) allowing the identification and definition of configuration objects (e.g. data,
software, ...) and their relationship.
The configuration management is literally the management of the technical description of a product
and its evolution.
Configuration management allows to warranty and control a complete and consistent reference of
the products all along the project life.
Configuration management therefore makes it possible to ensure:
     Availability
            o each object must be continuously available,
            o the object must be available in various versions.
     Security
            o references of each object managed in configuration are controlled,
            o objects managed in configuration are saved/backed-up.
     Consistency
            o configuration management makes it possible to manage the consistency between
                 objects of different nature,
            o it makes it possible to define dependencies between these objects so that it becomes
                 possible to restore any kind of version in a coherent state.
     Visibility
            o configuration management makes it possible to follow-up and memorise all the
                 modifications made on any objects,
            o it makes it possible to identify and restore the configuration at previous defined
                 stages,
            o it also makes it possible, following a scheduled modification, to define the set of the
                 objects that will have to be modified.

    3.2 Configuration management activities
The following activities have to be handled:



                             DEBAT – De velopment of EAST Based Access Tools
                                                                               Reference   : SS/DEBAT/PAP
                                          DEBAT                                Issue.      : 1.1
                                   Product Assurance Plan                      Date        : 31/10/2002
                                                                               Page        :9


    List all the documents and products which will set up the whole managed configuration;
    Identify precisely the reference configuration by means of the applicable documents;
    Identify every object subject to configuration management as a unique object. Objects are
     identified by a name, a release number or revision number in a given release;
    Control the configuration, in particular when modifications occur during the project;
    Build and maintain an archive containing all the managed products and documents.

    3.3 Configuration managed objects
The types of objects managed in configuration are:
     documentation,
     software.
Each object can be managed either in a referenced way or in a resident way. The resident way is for
the objects directly available on the configuration. The referenced way, applies to the
documentation reference present on the configuration, but not the whole document.
For DEBAT, the software is managed in a resident way and the documentation is managed in a
referenced way.

    3.4 Configuration management organisation
Before each delivery of a product, its configuration has to be produced and checked in order to
know what is exactly the product made of, which version of the documentation is compliant with it,
and to be able to restore the product later.
At the general level, it is necessary to set up a configuration management for the whole product;
after each integration, CS has to update the DEBAT configuration and to fill the DEBAT
configuration report.
Before each delivery of a DEBAT version, the configuration have to be updated and checked and
the configuration report is delivered with the product.

    3.5 Configuration identification
Each object which must be configuration managed have to be identified in an unique way.
Several kinds of elements are managed :
    The documents are identified by their identification number and the edition/revision number
       as it is defined in the chapter “Documentation management”.
    The software elements as source files, interface files, test files are identified by their name,
       including their directory tree and also an edition/revision number.
    The software needed by the product have also to be identified by the reference given by the
       producer.




                             DEBAT – De velopment of EAST Based Access Tools
                                                                                Reference   : SS/DEBAT/PAP
                                           DEBAT                                Issue.      : 1.1
                                    Product Assurance Plan                      Date        : 31/10/2002
                                                                                Page        : 10



    3.6 Configuration for software development

                                                                   Check out           Repository

          PrivateS
          pace 1
                                                                 Check in
          PrivateS
          pace 2

                                                           Shared Space
                                                           (Public)                            Update


                                                           Sources
           PrivateS
           pace n
                                                           Obj
                                                           cts



Repository :
It is the space containing all source files and all their versions (configuration space).
Shared Space :
It is a space shared by all the private spaces that provides a view of a version of the configuration of
the software (usually the last integrated or validated one from the repository).
It may be divided in two parts :
      shared sources : source files ;
      shared objects : compiled files to avoid compilation of the whole software in every private
         space.
When several versions of the software have to be developed in the same time, there can be several
Shared spaces (one per version) each with its own set of private spaces (but the repository remains
unique).
Private Space :
It is owned by only one developer. A developer may own several different private spaces (if he has
to make unrelated improvements on the software).
The development is actually done in a Private space.
Within a Private space, the view of the software is composed by :
      the files that are present in this private space ;
      the files that are in the shared space and are not hidden by an other version in this private
         space.
When the shared space also support objects (result of source file compilation), only the files of the
private space have to be compiled to obtain the whole software.
The modification states are : a developer checks out a file from the repository, modifies it, tests it,
then checks it in.
The Shared space is only updated when some modified files works together and one wants to
publish it for all the developers to go one step ahead.




                              DEBAT – De velopment of EAST Based Access Tools
                                                                               Reference   : SS/DEBAT/PAP
                                          DEBAT                                Issue.      : 1.1
                                   Product Assurance Plan                      Date        : 31/10/2002
                                                                               Page        : 11


    3.7 Configuration modification
Software elements which are configuration managed can be modified after an evolution or a
correction of an anomaly, in that case the element is modified, tested and delivered to the
configuration manager to update the configuration.
The edition or the revision number of the element are updated.
In the intent to no overload the configuration management, it is proposed to group if possible the
delivery of modified elements.

    3.8 Configuration tool
The configuration tool that will be used is CVS.


4. Anomalies management
This chapter describes the procedure to identify, manage and resolve anomalies that may occur
during the qualification and the warranty of DEBAT.

    4.1 Anomaly Definition
An anomaly is generally defined as an apparent default on any item that is not conform with the
specified requirements or specifications.
The anomalies can be classified in major or minor:
    Major Anomaly: a major anomaly is a non compliance to the requirements involving safety,
        performance, durability, dependability, reliability, physical or functional use.
    Minor Anomaly: any minor anomaly which does not impact any areas specified here above,
        will be qualified as minor Anomaly.
Each anomaly is registered on a SPR.

    4.2 Anomaly tracking
All the anomaly reports are registered in a file.
When the anomaly is corrected, the anomaly report is updated in the file with the name of the
“Correction Form”.
Anomalies are compiled in the anomaly status list which identify the anomalies number, the test
condition, the problem causes and close out status.
This anomaly status list are included in the product description of the configuration report.


5. Methods and tools
This chapter will describe the methods, the techniques and tools used for the development of
DEBAT.

    5.1 Project Management
Project management refers to the process of planning, organising, directing, and controlling the
effort to efficiently achieve the technical objectives within the constraints of time schedule and
budget.



                             DEBAT – De velopment of EAST Based Access Tools
                                                                              Reference   : SS/DEBAT/PAP
                                         DEBAT                                Issue.      : 1.1
                                  Product Assurance Plan                      Date        : 31/10/2002
                                                                              Page        : 12


The project management includes:
    Project setting up;
    Project administration;
    Project organisation;
    Project technical management.
Reporting:
The project manager:
    produces a general plan at the beginning of each phase (included in the Project Management
       Plan),
    delivers at the end of each month to the ESA Technical Officer a Progress Report,
    foresees project presentations at the end of each phase, to be held through slides and
       demonstrations, as applicable.
Tools
Word
Excel
MS-Project

    5.2 Development

          5.2.1 Development environment
The development of the DEBAT product is produced on :
    SUN SOLARIS 2.8,
    WINDOWS NT,
    Potentially LINUX (the porting to LINUX is to be analysed in phase 1 of the project).
The tools used on the project are:
    STOOD V4.1,
    UML Rational Rose,
    GNAT compiler 3.13,
    Solaris F77 compiler,
    C/C++ Sun Workshop Compiler,
    GCC compiler,
    Microsoft Visual C++ (NT version),
    XVT-DSC++ for NT and Solaris,
    Rogue Wave Tools. h++,
    Java Development Kit and Forte For Java (IDE).

          5.2.2 Requirements
Method
    CS Interview methodology,
    CS requirements collection methodology
Tools
    Microsoft Word 97/2000, Excel




                            DEBAT – De velopment of EAST Based Access Tools
                                                                              Reference   : SS/DEBAT/PAP
                                         DEBAT                                Issue.      : 1.1
                                  Product Assurance Plan                      Date        : 31/10/2002
                                                                              Page        : 13


          5.2.3 Specification and design
Method
    HOOD,
    UML-CS methodology
Tools
    STOOD,
    UML Rational Rose
    Microsoft Word 97/2000

          5.2.4 Coding
Languages
    ADA,
    JAVA,
    C++,
    C,
    FORTRAN77.
Coding standards
The coding standards to be applied to the developed software are adapted from CNES French
agency standards (see Quality Action chapter).
Tool
LOGISCOPE will be used to compute metrics and check coding rules.

          5.2.5 Validation and tests
Integration and validation tests will be performed for DEBAT (a set of tests is included in EAST /
OASIS, this one will be reused and extended).

    5.3 Traceability
For large programs, the major interest of requirements traceability is well known :
     coverage matrix tracking requirements during the different project phases,
     impact analysis identifying requirements impacted by a modification,
     evaluation of answers for critic requirements.
A traceability matrix of “Top-level architectural design to requirements” (at PDR)               and of
“Acceptance tests to Requirements Baseline” (at AR) will be provided.


6. Suppliers control

    6.1 Sub-contractors
Without object

    6.2 Co-contractors
Without object



                            DEBAT – De velopment of EAST Based Access Tools
                                                                               Reference   : SS/DEBAT/PAP
                                          DEBAT                                Issue.      : 1.1
                                   Product Assurance Plan                      Date        : 31/10/2002
                                                                               Page        : 14


    6.3 Bought, rented, imposed or re-used software

          6.3.1 Case of bought software products
In case of bought software:
Receive the delivery
The Project Manager or the authorised project team members receive the ordered supplies.
They check the delivery completeness with respect to the delivery note.
Set up the supplies
The Project or the authorised project team members set up the supplies by implementing the
installations procedure recommended by the constructor.
Check the supplies
The Project Manager or the authorised project team members examine the documentation state and
its completeness.
They execute the available constructor tests.
If the controls done on the products show that the product is not conform, the remarks are tracked
on the delivery note before to be returned to the supplier. A copy of each delivery note is saved at
CS by the project manager.

          6.3.2 Case of rented software
Without object

          6.3.3 Case of imposed software
Without object


7. Reproduction, protection, delivery

    7.1 Reproduction
Reproduction or duplication of one or more elements is placed under the Project Manager's
responsibility.

    7.2 Protection
In order to protect the products, some precautions are taken as:
      daily or weekly back-up storage of the modified developments,
      back-up of all the elements which are configuration managed.
The back-up means for the developed products (software and documentation) have to be applied by
all the developers.

    7.3 Delivery
All the deliverables produced in the course of DEBAT project (documentation, source code,
comments in source code, error message, MMI labels,…) will be in English.



                             DEBAT – De velopment of EAST Based Access Tools
                                                                               Reference   : SS/DEBAT/PAP
                                          DEBAT                                Issue.      : 1.1
                                   Product Assurance Plan                      Date        : 31/10/2002
                                                                               Page        : 15


Concerning the EAST technology reused in DEBAT (and mainly produced in French):
    The error/output messages (standard out/err or MMI messages) and MMI labels shall be
      translated to English (if written in French),
    The original source code or source code comments, if written in French, will not be
      translated to English,
    The documentation (SUM, …), if available in French, will not be translated into English as
      our proposed approach suggests to favour on-line help for DEBAT product (it can be quite
      expensive to translate huge documentation).

          7.3.1 Responsibilities
The Project Manager is responsible for the deliveries of the DEBAT products.

          7.3.2 Delivery procedure
Documentation deliveries
Any document version ready for delivery is approved with signatures by the Contractor's Project
Manager and then by the ESA Technical Officer or duly authorised delegates.
Documents is considered delivered after acceptance by the ESA Technical Officer.
Where the actual implementation of any delivered system does not correspond to the original
specification document as result of a traceable and accepted change (as normally occurring in any
project), the document is re-issued with the necessary modifications, even if it was prepared in a
different project phase. Otherwise the discrepancy is treated as any other SPR.
The documents for the review are delivered at least 5 working days before the review.
The language to be used for all project deliverables is English (excepted for EAST/OASIS reused
software and documentation).
Software deliveries
Any software package is delivered on the electronic medium agreed with the ESA Technical
Officer: mail, CD or Disc.
Software package delivery include executables, source code (developed in the frame of DEBAT),
object code, link libraries, automatic rebuild procedures and installation procedures.


8. Quality actions
This paragraph describes the techniques that are used to ensure and to check the application of the
PAP on the DEBAT project.
Quality actions are two parts :
    assurance actions: prevention before each phase,
    control actions : checking during phases and before deliveries.
Quality assurance actions are at least :
    elaboration of Product Assurance Plan (this document),
    elaboration of Product Assurance Report,
    elaboration of documents type,
    elaboration of coding metrics and standard,
    participation to meetings : internal or external progress meetings, reviews
    presentation of quality dispositions to the members of the project team,
    planning follow-up.
Quality control actions are at least :



                             DEBAT – De velopment of EAST Based Access Tools
                                                                                Reference   : SS/DEBAT/PAP
                                           DEBAT                                Issue.      : 1.1
                                    Product Assurance Plan                      Date        : 31/10/2002
                                                                                Page        : 16


      control on the documentation,
      control on the code,
      control on the deliveries,
      control on the tests,
      control on the configuration management,
      control on the acceptance,
      control on the development process.

    8.1 Purpose and responsibilities
The aim of the quality actions is to deliver a DEBAT product (software and documents) compliant
with the characteristics and the requirements asked for this project, and to ensure the final product
quality and the respect of the project quality objectives.

    8.2 Means
Different ways can be employed by the persons involved in the actions as:
     participating to the meetings,
     crossed controls between the members of the team,
     organising inspections: inspection is a software or documentation checking quality action
       which by examination observation and measurement evaluates conformity of a standard to
       pre-defined quality clauses (AFNOR Z61-102);
     if necessary, organising audits: an audit is a methodical examination of a situation relating to
       a product, a process, an organisation, performed in collaboration with the parties involved in
       order to check the conformity of the situation to pre-defined dispositions and the adequacy
       of the dispositions to the desired goals (AFNOR Z61-102);
     assessments.

    8.3 Organisation
All of the actions executed by the persons involved in the controls of the products are tracked.
The results of the controls are written on a specific dialog form which is returned to the responsible
of the product. Then the author of the product has to answer to the dialog form, either the remarks
are not justified, either he has to take the remarks into account and he has to correct the product.
The dialog form is returned to the author of the control and a new review of the product is realised
by the quality manager but only on the elements thrown by the first control, he has to control the
dialog form and how the remarks have been processed. The dialog form is then stored by the quality
manager (electronic and paper format).

    8.4 Controls on the development process
These controls are mainly realised by the Project Manager who verifies, by the means of the
different meetings and reports if the organisation is compliant with the planning, the progress of the
project.




                              DEBAT – De velopment of EAST Based Access Tools
                                                                               Reference   : SS/DEBAT/PAP
                                          DEBAT                                Issue.      : 1.1
                                   Product Assurance Plan                      Date        : 31/10/2002
                                                                               Page        : 17


    8.5 Controls on the documentation
Each document is controlled by the Project Manager for the technical aspects and by the Quality
Manager for the quality aspects (coherence). The final version of the documentation delivered
checked by the Project Manager and by the Quality Manager. Different controls are led to verify if:
     the form of the document is correct, the presentation, the identification, the first pages, the
        summary, the glossary, the annexes, the plan, the production rules are respected;
     the content of the document is coherent itself and contains all the information necessary for
        its understanding;
     the content of the document is coherent and compliant with other documents;
     if the document has to be integrated in an other document, its coherence is also checked.
The signature on the document by the Project Manager and the Quality Manager is the indication
that the controls have been executed and their results are accepted.

    8.6 Assurance and controls on the code
In terms of code control, the process is the following :
     for each language :
            o the set of coding standard rules
            o and the bounds of basic metrics
       are defined with the members of the project in accordance with CNES standards;
     comments policy is defined : contents of the “module header comments”;
     code controls are issued with Logiscope tool;
     manual controls may be done by sampling (one module by language and developer);
     for the existing code (EAST and OASIS), an inventory is done but no corrections actions are
        issued.
The rules and the metrics bounds are given in annexes.
The controls on the code are done by the Quality Manager in order to check if the main metrics
respect the defined level and also to verify that the standard code rules are respected. In fact the
development team has to respect the coding standards rules on all the modified and created code.
The new files and the files which are globally modified, will be controlled.

Technical crossed controls may be also done; the quality manager prepare a planning of these
controls according to the development team; developers report results of the tests on dialog forms
which are sent to quality manager.
If some rules are not respected, different actions can be led:
     the discrepancy is not justified, so in this case, it has to be corrected;
     the discrepancy is justified, in which case the quality manager write a “derogation form” and
       send it to ESA Technical Officer for acceptance.
The results of these controls are stored with each version of the version of the code.

Tool :
LOGISCOPE




                             DEBAT – De velopment of EAST Based Access Tools
                                                                                 Reference   : SS/DEBAT/PAP
                                             DEBAT                               Issue.      : 1.1
                                      Product Assurance Plan                     Date        : 31/10/2002
                                                                                 Page        : 18


Coding standards :
The coding standards used on the project will be adapted from CNES standards (RNC):

RNC-CNES-Q-80-504            REGLES ESSENTIELLES POUR L'UTILISATION DU LANGAGE
                             ADA
RNC-CNES-Q-80-505            REGLES ESSENTIELLES POUR L'UTILISATION DU LANGAGE
                             FORTRAN 77
RNC-CNES-Q-80-506            REGLES ET RECOMMANDATIONS POUR L'UTILISATION DU
                             LANGAGE C
RNC-CNES-Q-80-513            REGLES POUR L'UTILISATION DU LANGAGE C++
RNC-CNES-Q-80-517            REGLES ESSENTIELLES POUR L'UTILISATION DU LANGAGE
                             FORTRAN 90
RNC-CNES-Q-80-527            REGLES ET RECOMMANDATIONS POUR L'UTILISATION DU
                             LANGAGE JAVA

For C++ and JAVA, the rules are also adapted from Logiscope tool for the automatic controls part.


     8.7 Controls on the tests
The quality manager proceed to a sampling of the tested classes (about 10%).

     8.8 Controls on the deliveries
Before each delivery, the quality manager has to verify that the delivery is complete according the
timetable of deliverables and that a delivery note is joined.

     8.9 Software Product Assurance Reporting
A Software Product Assurance Report is delivered at each review, including an assessment of the
current quality of software development process and of the current quality of the product.

     8.10 Quality tracking
All the quality records and actions are tracked in a “log book”.
All quality documents are stored in the “Quality assurance Folder”.

     8.11 Specific Quality Actions for the Phase 1
The quality actions lead during the Phase 1 are those described in the §8.4, §8.5, §8.8, §8.9 and
§8.10.

     8.12 Specific Quality Actions for the Phase 2
The quality actions described in §8 will be also performed during the phase 2. New quality controls
which are specific for the phase 2 are described below.




                               DEBAT – De velopment of EAST Based Access Tools
                                                                               Reference   : SS/DEBAT/PAP
                                          DEBAT                                Issue.      : 1.1
                                   Product Assurance Plan                      Date        : 31/10/2002
                                                                               Page        : 19


           8.12.1 Type of controls during the Phase 2
These are controls either on products or processes carried out during this phase. The controls are
done by the Project manager, by the development team (using the cross-checking) and by the
Quality responsible for documents and code. The aim of these controls is to detect deviations as
soon as possible and to limit corrections to be made at the end of the phase. These controls are a
global examination of the outputs of the phase using the different reports, matrix and controls made
during the phase.

The nomenclature of a control includes the manager as well as the phase during which it was
performed:
C-CP-PHASE-xx: for controls done by the Project manager or Technical Manager,
C-DV-PHASE-xx: for controls done by the Development Team,
C-IQ-PHASE-xx: for controls done by the Project Quality responsible.

8.12.1.1      Controls at the beginning of a phase 2
     C-IQ-BEG-1      Check for each individual that he or she has assimilated the method, the
                     formalism, the languages and tools.
                     Follow-up the effective implementation of the organisation planned for the
                     phase

8.12.1.2      Controls during the coding and unit test phase
     C-DV-CUT-2      Check the source codes in relation to the project coding standards. Each
                     developer controls his production by means of code control tools
     C-DV-CUT-3      Use cross-checking reviews to control a source code per language and per
                     individual
     C-IQ-CUT-4      Control a source code per language and per individual in order to check
                     that coding rules and their application have been assimilated
     C-IQ-CUT-5      Use control tools to check the whole of the production code
     C-IQ-CUT-6      Check the structure of documents which have been subjected to cross-
                     checking reviews and the structure and content of documents which have
                     not been subjected to cross-checking reviews

8.12.1.3      Controls during the validation phase
     C-CP-VAL-7      Check for the existence of validation tests and that the test strategy has
                     been correctly applied
     C-IQ-VAL-8      Check that the test has been recorded as well as the results of the
                     validation tests
     C-IQ-VAL-9      Check the structure of documents which have been subjected to cross-
                     checking reviews and the structure and content of documents which have
                     not been subjected to cross-checking reviews
    C-IQ-VAL-10      Check the production of the compliance matrix of Acceptance tests to
                     Requirements Baseline




                             DEBAT – De velopment of EAST Based Access Tools
                                                                                          Reference   : SS/DEBAT/PAP
                                                 DEBAT                                    Issue.      : 1.1
                                          Product Assurance Plan                          Date        : 31/10/2002
                                                                                          Page        : 20


8.12.1.4         Controls before submitting for acceptance
    C-CP-ACC-11          Check that a problem report has been sent to the customer for any problem
                         which has not been resolved before acceptance

8.12.1.5         Controls at the end of the phase 2
    C-CP-END-12          Check before delivery that the phase objectives have been achieved:
                                 Consistency between the phase products,
                                 Consistency with the previous phase,
                                 Completeness in relation to specifications.
    C-CP-END-13          Check the actions of the previous milestone
    C-IQ-END-14          Check before delivery that:
                                 The actions of the previous milestone have been taken into account,
                                 Comments made during different phase controls have been taken into account,
                                 Completeness of the delivery in relation to the supplies planned,
                                 Previous quality remarks have all been taken into account.
Once they have seen the controlled elements and checked that the comments have been taken into
account, the Quality responsible and the Project manager will either accept (possibly with
reservations) or reject the delivery or phase products.

            8.12.2 Control plan
The controls may be led:
          During a progress meeting,
          During production of a significant part of a document,
          Before delivery to ESRIN of a provisional version,
          After reception of recommendations, comments, requests for modification, corrections and problem report.

8.12.2.1       Summary of scope of controls
The following table summarises the controls and their scope when creating an element.

           CONTROLLED ELEMENT                            CONTROL RATE                CONTROL MANAGER
    Documentation                                   Control of form and     Quality responsible
                                                    content : 100 %
                                                    Cross-checking review : Development team
                                                    1 section of code per
    Source code
                                                    individual and per
                                                    programming language




                                   DEBAT – De velopment of EAST Based Access Tools
                                                                                           Reference   : SS/DEBAT/PAP
                                                   DEBAT                                   Issue.      : 1.1
                                            Product Assurance Plan                         Date        : 31/10/2002
                                                                                           Page        : 21


          CONTROLLED ELEMENT                                CONTROL RATE              CONTROL MANAGER
                                                      Automatic controls            Quality responsible
                                                      using tools (for the
                                                      programming languages
                                                      covered): 100% of
                                                      source files
                                                      (at the end of coding
                                                      phase)
                                                      1 per individual and per      Quality responsible
    Test environment
                                                      type of test
                                                      100% during first             Configuration
                                                      acceptance delivery           management manager
    Configuration Management
                                                      Control of consistency        Quality responsible
                                                      by sampling

8.12.2.2       Details on the scope of code controls
Codes produced by the development team are controlled automatically with Logiscope tool.
The source code is controlled during the coding phase per language and per individual participating
in coding, to ensure correct understanding and assimilation of coding rules and recommendations.
The complexity of the modules chosen is taken into account to ensure a representative sample.
Comment: the code generated by tools (by an MMI generator or by a data base generator) is not
controlled either manually or automatically. No statistical indicators are created for the code
generated.
The controls on the code provide the check of the metrics. The cyclomatic number V(G), the
number of instructions, and the level of comments have to respect the defined level and also the
coding standard rules.
If some coding rules and metrics code are not respected, different actions can be lead:
         The discrepancy is not justified, so in this case, it has be corrected,
         The discrepancy is justified and in which case the Quality responsible write a non conformance report and sent
          it to ESRIN Project Officer for acceptance.

8.12.2.3      Results expected from Controls
The controls done by the Quality responsible are all formalised on the dialog form.
Controls done by the technical team are:
         Either formalised on a dialog form,
         Or recorded in the project log which indicates what was controlled and the result of the control (OK, not OK).
All of these dialog forms are centralised in a Quality assurance log file. A summary table is kept up
to date by the Quality responsible and contains the list of dialog form issued, their author(s) and
recipient(s), the element controlled, their date of opening and closure. All of the actions opened
during meetings are listed on the action item list.




                                    DEBAT – De velopment of EAST Based Access Tools
                                                                                Reference   : SS/DEBAT/PAP
                                           DEBAT                                Issue.      : 1.1
                                    Product Assurance Plan                      Date        : 31/10/2002
                                                                                Page        : 22



9. Annex : basic metrics definitions and bounds for code
   controls

    9.1 Definitions
The basic metrics are :
    Comments Frequency
    Number of statements
    Cyclomatic number (VG)
    Number of levels
The definitions are issued from Logiscope tool and are evaluated by functions.

          9.1.1 Metric “Comments frequency”
The Comments Frequency is the number of lines of comments per statement in the function.
Although this metric cannot evaluate the relevance of the comments written in the code, experience
has shown that it is a good indicator of the effort made by the developer to describe the function.
To make it easier to understand the code when performing maintenance operations, the code must
contain a sufficient number of comments. It is also better to distribute the comments evenly at the
level of the statements that need commenting, rather than placing them all at the beginning of the
function and leaving all the statements without comments.

          9.1.2 Metric “Number of statements”
It’s the number of statements that can be executed between the function's header and the closing
curly bracket.
The following are statements:
        ;(empty statement)            IF [ELSE]      SWITCH                 WHILE
        DO             FOR            GOTO           BREAK                  CONTINUE
        RETURN                 THROW                 TRY            ASM
        expression;(simple statement)
        function definition (for C++, JAVA, ADA)
        variable declaration (for C++, JAVA, ADA)
Statements located in the external declarations are not taken into account.
This metric is a good indicator of a function's maintainability. In fact, the greater the number of
statements contained in a function, the greater the number of its operands and operators, which
means that a greater effort will be required to understand the function. It is therefore desirable that
the number of statements should be limited in each of the program's functions.
In order to reduce the size of a function, it must be broken down into several subfunctions. This
breakdown makes it possible to establish a better hierarchy of the functions performed by the
program, and therefore improves maintainability.

          9.1.3 Metric “Cyclomatic number (VG)”
This metric is based on the graphs theory and gives the number of linearly independent paths in a
connected graph. For a connected graph g, the cyclomatic number is calculated as follows:
      V(g) = E - N + 1



                              DEBAT – De velopment of EAST Based Access Tools
                                                                                Reference   : SS/DEBAT/PAP
                                            DEBAT                               Issue.      : 1.1
                                     Product Assurance Plan                     Date        : 31/10/2002
                                                                                Page        : 23


where:
         E is the number of edges between the graph's nodes,
         N is the number of nodes in the graph.
For a control graph, which is not a connected graph since it has one or several entries and one or
several exits, the cyclomatic number is given by the formula:
         V(g) = E - N + 2 + AEn + AEx
where:
         E is the number of edges between a graph's nodes,
         N is the number of nodes in the graph,
         AEn is the number of auxiliary entries (equal to 0 for programs written in C++)
         AEx is the number of auxiliary exits (number of exits by RETURN except for
                              the one at the end of the function).
Whatever the types of structured control used (selections, iterations, branches or sequences) and
whatever the way these structures have been assembled (sequentially, nested, structured or not, etc.)
the cyclomatic number is the metric that is used to quantify the complexity of the resulting control
structure.
It is therefore a good indicator of the effort the reader must make to understand the function's
algorithm and for evaluating the effort that will be required to test its control structure. This metric
can also be interpreted to indicate the minimum number of tests cases that will have to be generated
to test the function.
A high cyclomatic number is often due to the fact that the function contains too many executable
statements. So the number of statements will have to be reduced either by subdividing the function
or by factorizing any code repetitions that it contains.
This subdivision will result in subroutines being created which will contain the part of the control
structure concerning them, thus reducing by as much the original function's control structure.
Instead of having a function with a high cyclomatic number, the complexity will be distributed over
several functions that have a reasonable cyclomatic number.

           9.1.4 Metric “Number of levels”
The number of levels is the maximum number of control structure nestings in the function plus one.


    9.2 Bounds per language
Bounds of basic metrics are defined as following:

Language              Comments            Number of             Cyclomatic         Number of
                       Frequency           statements          number (VG)            levels
                     Goal     Min        Goal     Max          Goal    Max        Goal      Max
                     value   value       value    value        value  value       value    value
C                    30%     20%          70       100          20      30          4        6
C++                  30%     20%          70       100          20      30          4        6
JAVA                 30%     20%          70       100          20      30          4        6
FORTRAN              30%     20%          70       100          20      30          4        6
ADA                  30%     20%          70       100          20      30          4        6




                              DEBAT – De velopment of EAST Based Access Tools
                                                                               Reference   : SS/DEBAT/PAP
                                          DEBAT                                Issue.      : 1.1
                                   Product Assurance Plan                      Date        : 31/10/2002
                                                                               Page        : 24



10. Annex : header comments

    10.1 Files header comments
For each file of code, the header comments contains at least :
     Module name
     Creation date
     Language
     Author
     Description
     Historic log with date, author, modification reference, revision number
     Current version

    10.2 Operations header comments
For each operation (or method or function), the header comments contains at least :
     Operation name
     Description
     Calling parameters
     Return parameters
     Exception if needed




                             DEBAT – De velopment of EAST Based Access Tools
                                                                                       Reference   : SS/DEBAT/PAP
                                                  DEBAT                                Issue.      : 1.1
                                           Product Assurance Plan                      Date        : 31/10/2002
                                                                                       Page        : 25



11. Annex : coding standard rules
The development team will apply the RNC rules. The pertinent rules are composing a subset of
RNC rules, which will be controlled automatically by Logiscope tool. JAVA and C++ coding
standards rules with critical notion are described below.

       11.1 JAVA coding rules

               11.1.1 asscal : Assignement in function calls (critical)
Definition:
Assignment operators ( = , += , -=, *=, /= , %= , >>= , <<=, &=, |=, ^=) must not be used inside function calls
(the evaluation order is not guaranteed).
Justification:
Removes ambiguity about the evaluation order.


               11.1.2 asscon : Assignement in conditions (critical)
Definition:
Assignment operators ( = , += , -=, *=, /= , %= , >>= , <<=, &=, |=, ^=) must not be used inside conditional
expression in control statements if, while, for and switch.
Justification:
An instruction such as "if (x=y) { ..." is ambiguous and unclear.
One might think the author wanted to write "if (x==y) {...".
Example:
// do not write
if (x -= dx) { ...
for (i=j=n; --i > 0; j--) { ..
// write
x -= dx;
if (x) { ...
for (i=j=n; i > 0; i--, j--) { ...


               11.1.3 assexp : Assignement in expressions (critical)
Definition:
Inside an expression: An lvalue has to be assigned only once, With multiple assignments, an assigned lvalue
can appear only where it has been assigned.
Justification:
Removes ambiguity about the evaluation order.
Example:



                                     DEBAT – De velopment of EAST Based Access Tools
                                                                                      Reference   : SS/DEBAT/PAP
                                               DEBAT                                  Issue.      : 1.1
                                        Product Assurance Plan                        Date        : 31/10/2002
                                                                                      Page        : 26


// do not write
i = t[i++];
a=b=c+a;
i=t[i]=15;



              11.1.4 brkcont : Break and continue forbidden (critical)
Definition:
Break and continue instructions are forbidden inside conditional expressions in control statements ( for, do,
while ). Nevertheless, the break instruction is allowed in the block instruction of the switch statement.
Parameters:
JAVA: A string identifying the type of checking:
* "in_switch" (or no parameter) means that the break are allowed in switch statements,
break and continue are forbidden everywhere else,
* "without_label" means that any break or continue without a label is allowed,
* "with_label" means that any break and continue with a label is allowed,
break and continue without a label is forbidden everywhere.
Justification:
Like a goto, these instructions break down code structure. Prohibiting them in loops makes the code easier
to understand.


              11.1.5 condop : Ternary ?: operator
Definition:
The conditional operator ? ... : ... must not be used.


              11.1.6 const : Literal constants
Definition:
Numbers, characters and strings have to be declared as constants instead of being used as literals inside a
program. The user can list the allowed literal constants.
Parameters:
A list of character strings representing the allowed literal constants.
Note: In the case of constants used in initializing lists (concerning array and struct structures), only the first
five violations are shown.
Justification:
Makes maintenance easier by avoiding the scattering of constants among the code, often with the same
value.
Example:




                                  DEBAT – De velopment of EAST Based Access Tools
                                                                                   Reference   : SS/DEBAT/PAP
                                              DEBAT                                Issue.      : 1.1
                                       Product Assurance Plan                      Date        : 31/10/2002
                                                                                   Page        : 27


// do not write
char tab[100];
int i;
...
if (i == 7) {
p = "Hello World.";
}
// write
#define TAB_SIZE 100
enum i_val { ok =7; ko =11};
const char HelloWorld[] = "Hello World.";
char tab[TAB_SIZE];
i_val i;
...
if (i == ok) {
p = HelloWorld;
}


                 11.1.7 dmaccess : Access to members data (critical)
Definition:
The class interface must be purely functional: members data definitions can be limited.
Parameters:
A list of character strings corresponding to the forbidden access specifiers for the data members.
Justification:
The good way to modify the state of an object is via its methods, not its data members.
The data members of a class should be private or at least protected.
Example:
In order to prevent the use of data members in the public and protected access specifiers, the standard may
be expressed as below:
STANDARD dmaccess ON LIST "public" "protected" EN LIST END STANDARD


                 11.1.8 exprcplx : Expressions complexity
Definition:
Expressions complexity must be smaller than a limit given as a parameter.
This complexity is calculated with the associated syntactic tree, and its number of nodes.
By default, the maximum authorized complexity level is 10.
Parameters:




                                DEBAT – De velopment of EAST Based Access Tools
                                                                                       Reference   : SS/DEBAT/PAP
                                                  DEBAT                                Issue.      : 1.1
                                           Product Assurance Plan                      Date        : 31/10/2002
                                                                                       Page        : 28


A number representing the authorized complexity level.
Example:
For instance, this expression :
(b+c*d) + (b*f(c)*d)
is composed of 8 operators and 7 operands.
The associated syntactic tree has 16 nodes, so if the limit is under 16, there will be a standard violation.


              11.1.9 exprparenth : Parenthesis in expressions
Definition:
In expressions, every binary and ternary operator has to be put in parenthesis, so that the evaluation
priorities are not ambiguous.
Use the partpar option to allow the following rules: when the right operand of a + or * operator uses the same
operator, you can omit parenthesis for it. In the same way, you can omit parenthesis in the case of the right
operand of an assignment operator. Moreover, you can omit parenthesis at the first level of the expression.
Parameters:
The character string "partpar", which, if used, allows programmers not to put systematically parenthesis,
according to the rule above.
Justification:
Removes ambiguity about the evaluation priorities.
Example:
// do not write
result = fact / 100 + rem;
// write
result = ((fact / 100) + rem);
// or write, with the partpar option
result = (fact / 100) + rem;
// with the partpar option, write
result = (fact * ind * 100) + rem + 10 + (coeff ** c);
// instead of
result = ((fact * (ind * 100)) + (rem + (10 + (coeff ** c))));


              11.1.10 identl : Identifier length
Definition:
The length of a function, type or variable identifier has to be between a minimum and a maximum value.
Parameters:
A list of couples of character strings; the first string of the couple represents the type name (refer to the table
of the identfmt standard), the second one the MINMAX expression associated.




                                    DEBAT – De velopment of EAST Based Access Tools
                                                                                       Reference   : SS/DEBAT/PAP
                                                DEBAT                                  Issue.      : 1.1
                                         Product Assurance Plan                        Date        : 31/10/2002
                                                                                       Page        : 29


              11.1.11 identres : Reserved identifiers (critical)
Definition:
Some identifiers may be forbidden in declarations.
For instance, names used in compilation directives or in libraries.
Parameters:
A list of character strings representing reserved identifiers.


              11.1.12 mclass : A single class definition per file
Definition:
A file must not contain more than one class definition.
Nested classes are tolerated.


              11.1.13 parse : Parse error
Definition:
This standard identifies module parts that could not be parsed.


              11.1.14 sgdecl : A single variable per declaration
Definition:
Variable declarations have the following formalism: type variable_name.
It is forbidden to have more than one variable for the same type declarator.
Example:
// write
int width;
int length;
// do not write
int width, length;


              11.1.15 swdef : default within switch (critical)
Definition:
A default case is mandatory within a switch in order to cover unexpected cases.
Parameters:
The character string "last", which, if used, specifies that the default case has to be the last one.


              11.1.16 swend : End of cases in a switch (critical)
Definition:




                                  DEBAT – De velopment of EAST Based Access Tools
                                                                                       Reference   : SS/DEBAT/PAP
                                                DEBAT                                  Issue.      : 1.1
                                         Product Assurance Plan                        Date        : 31/10/2002
                                                                                       Page        : 30


Each case in a switch shall end with break , continue , goto , return or exit.
Several consecutive case labels are allowed.
Parameters:
The character string "nolast", which, if used, allows not to have one of these instructions in the last case.

      11.2 C++ coding rules

                 11.2.1 asscal : Assignement in function calls (critical)


Definition:
-----------
Assignment operators ( = , += , -=, *=, /= , %= , >>= , <<=, &=, |=, ^= , ++ , - - )
must not be used inside function calls (the evaluation order is not guaranteed).


Justification:
--------------
Removes ambiguity about the evaluation order.



                 11.2.2 asscon : Assignement in conditions (critical)


Definition:
-----------
Assignment operators ( = , += , -=, *=, /= , %= , >>= , <<=, &=, |=, ^= , ++ , -- )
must not be used inside conditional expression in control statements if, while,
for and switch.


Justification:
--------------
An instruction such as "if (x=y) { ..." is ambiguous and unclear.
One might think the author wanted to write "if (x==y) {...".


Example:
--------


// do not write




                                  DEBAT – De velopment of EAST Based Access Tools
                                                                                       Reference   : SS/DEBAT/PAP
                                                  DEBAT                                Issue.      : 1.1
                                           Product Assurance Plan                      Date        : 31/10/2002
                                                                                       Page        : 31


if (x -= dx) { ...
for (i=j=n; --i > 0; j--) { ..


// write


x -= dx;
if (x) { ...


for (i=j=n; i > 0; i--, j--) { ...



                 11.2.3 assexp : Assignement in expressions (critical)


Definition:
-----------
Inside an expression:


An lvalue has to be assigned only once,
With multiple assignments, an assigned lvalue can appear only where it has been assigned.


Justification:
--------------
Removes ambiguity about the evaluation order.


Example:
-------


// do not write


i = t[i++];
a=b=c+a;
i=t[i]=15;



                 11.2.4 brkcont : Break and continue forbidden (critical)


Definition:




                                     DEBAT – De velopment of EAST Based Access Tools
                                                                                     Reference   : SS/DEBAT/PAP
                                                   DEBAT                             Issue.      : 1.1
                                            Product Assurance Plan                   Date        : 31/10/2002
                                                                                     Page        : 32


-----------
Break and continue instructions are forbidden inside conditional expressions
in control statements ( for, do, while ).
Nevertheless, the break instruction is allowed in the block instruction
of the switch statement.


Justification:
--------------
Like a goto, these instructions break down code structure. Prohibiting them
in loops makes the code easier to understand.



                 11.2.5 cmclass : A single class per code file


Definition:
-----------
In a code file, every function must belong to the same class.
A C function is considered to belong to the main class.


Parameters:
-----------
A string representing the types of modules (metric type) that should be considered
as code files.



                 11.2.6 condop : Ternary ?: operator


Definition:
-----------
The conditional operator ? ... : ... must not be used.



                 11.2.7 const : Literal constants


Definition:
-----------
Numbers, characters and strings have to be declared as constants instead of being




                                  DEBAT – De velopment of EAST Based Access Tools
                                                                                      Reference   : SS/DEBAT/PAP
                                                DEBAT                                 Issue.      : 1.1
                                         Product Assurance Plan                       Date        : 31/10/2002
                                                                                      Page        : 33


used as literals inside a program. The user can list the allowed literal
constants.


Parameters:
-----------
A list of character strings representing the allowed literal constants.


Note: In the case of constants used in initializing lists
(concerning array and struct structures), only the first five violations are shown.


Justification:
--------------
Makes maintenance easier by avoiding the scattering of constants among the code, often
with the same value.


Example:
-------


// do not write


char tab[100];
int i;
...
if (i == 7) {
p = "Hello World.";
}


// write


#define TAB_SIZE 100
enum i_val { ok =7; ko =11};
const char HelloWorld[] = "Hello World.";
char tab[TAB_SIZE];
i_val i;
...
if (i == ok) {
p = HelloWorld;
}




                                  DEBAT – De velopment of EAST Based Access Tools
                                                                                   Reference   : SS/DEBAT/PAP
                                               DEBAT                               Issue.      : 1.1
                                        Product Assurance Plan                     Date        : 31/10/2002
                                                                                   Page        : 34




                 11.2.8 destr : Destructor (critical)


Definition:
-----------
Each class must contain its destructor explicitly.



                 11.2.9 dmaccess : Access to members data (critical)


Definition:
-----------
The class interface must be purely functional: members data definitions can be limited.


Parameters:
----------
A list of character strings corresponding to the forbidden access specifiers for the data members.


Justification:
--------------
The good way to modify the state of an object is via its methods, not its data members.
The data members of a class should be private or at least protected.


Example:
-------


In order to prevent the use of data members in the public and protected
access specifiers, the standard may be expressed as below:
STANDARD dmaccess ON LIST "public" "protected" EN LIST END STANDARD



                 11.2.10 exprparenth : Parenthesis in expressions


Definition:
-----------




                                 DEBAT – De velopment of EAST Based Access Tools
                                                                                      Reference   : SS/DEBAT/PAP
                                                  DEBAT                               Issue.      : 1.1
                                           Product Assurance Plan                     Date        : 31/10/2002
                                                                                      Page        : 35


In expressions, every binary and ternary operator has to be put in parenthesis,
so that the evaluation priorities are not ambiguous.
Use the partpar option to allow the following rules: when the right operand of
a + or * operator uses the same operator, you can omit parenthesis for it.
In the same way, you can omit parenthesis in the case of the right operand of an
assignment operator. Moreover, you can omit parenthesis at the first level of
the expression.


Parameters:
----------
The character string "partpar", which, if used, allows programmers not to put
systematically parenthesis, according to the rule above.


Justification:
--------------
Removes ambiguity about the evaluation priorities.


Example:
--------


// do not write
result = fact / 100 + rem;


// write
result = ((fact / 100) + rem);


// or write, with the partpar option
result = (fact / 100) + rem;


// with the partpar option, write
result = (fact * ind * 100) + rem + 10 + (coeff ** c);


// instead of
result = ((fact * (ind * 100)) + (rem + (10 + (coeff ** c))));



                 11.2.11 fntype : Function types



                                    DEBAT – De velopment of EAST Based Access Tools
                                                                                      Reference   : SS/DEBAT/PAP
                                                 DEBAT                                Issue.      : 1.1
                                          Product Assurance Plan                      Date        : 31/10/2002
                                                                                      Page        : 36


Definition:
-----------
Each function has to declare its type. If nothing is returned,
it must be declared of void type.



                 11.2.12 goto : "goto" statement


Definition:
-----------
The goto statement must not be used, except with the labels chosen by the user.


Justification:
--------------
Insures that structured programming rules are respected, so the code is easier
to understand. The goto statement often reveals an analysis error and its systematic
rejection improves the code structure.


Parameters:
-----------
A list of strings representing the labels that can be used with the goto statement.



                 11.2.13 hmclass : A single class definition per header file


Definition:
-----------
A header file must not contain more than one class definition.
Nested classes are tolerated.


Parameters:
----------
A string representing the types of modules (metric type) that should be considered as
header files.




                                    DEBAT – De velopment of EAST Based Access Tools
                                                                                       Reference   : SS/DEBAT/PAP
                                                DEBAT                                  Issue.      : 1.1
                                         Product Assurance Plan                        Date        : 31/10/2002
                                                                                       Page        : 37


              11.2.14 hmdef : Header module content


Definition:
-----------
The header files may not contain some of the language statements (data and function definitions).
The forbidden language items are function definitions (func-stat-def, func-glob-def)
and data definitions (var-stat, var-glob).


Parameters:
-----------
A string representing the types of modules (metric type) that should be considered
as header files.



              11.2.15 hmstruct : Header module structure


Definition:
-----------
To prevent multiple inclusions of header files, the main structure of
these files should be:


#ifndef
#define
...
#endif


where is an identifier built from the name of the header file.


The comparison is made only on alphanumeric characters and is not case sensitive.
The part of the filename taken into account is between the MINth and the MAXth
characters (including them). This character string should be found in the identifier
according to the above comparison rules.


Parameters:
----------
A MINMAX couple of values giving the part of the filename to take into account,
and a list of character strings giving the list of file types to be considered as




                                  DEBAT – De velopment of EAST Based Access Tools
                                                                                     Reference   : SS/DEBAT/PAP
                                                DEBAT                                Issue.      : 1.1
                                         Product Assurance Plan                      Date        : 31/10/2002
                                                                                     Page        : 38


header files for this rule.
The types are those defined by the metric type .


Example:
-------


// if the parameter is MINMAX 4 9,the following content
// of file div_audit_env.h is correct


#ifndef AUDIT_H
#define AUDIT_H
...
#endif




              11.2.16 mconst : Macro constant usage


Definition:
-----------
The usage of macro constants shall be limited.
It is possible to choose between three options:


 - var : global or static variables are used for string constants,
              other constants could be defined by macros,


Example:
-------


// write
const char *string = "Hello world!";
#define value 3


// do not write
#define string "Hello world!"




  - const : const data are always used instead of macros,



                                   DEBAT – De velopment of EAST Based Access Tools
                                                                                       Reference   : SS/DEBAT/PAP
                                                  DEBAT                                Issue.      : 1.1
                                           Product Assurance Plan                      Date        : 31/10/2002
                                                                                       Page        : 39




Example:
-------


// write
const char *string = "Hello world!";
const int value = 3;


// do not write
#define string "Hello world!"
#define value 3




 - nodefine : only compilation flags and macro functions are allowed.


Example:
-------


// write
#define VERBOSE
#define min(x,y) ((x)<(y)?(x):(y))


// do not write
#define value 3
#define current_value f(tab[0])




Parameters:
----------
One of the three character strings explained above.



              11.2.17 mfunc : Inline functions instead of macro functions


Definition:
-----------
Use inline functions instead of macro-functions.




                                     DEBAT – De velopment of EAST Based Access Tools
                                                                                       Reference   : SS/DEBAT/PAP
                                               DEBAT                                   Issue.      : 1.1
                                        Product Assurance Plan                         Date        : 31/10/2002
                                                                                       Page        : 40


Example:
-------


// write
inline char *GetName(aClass &object) {
return(object.name);
}


// do not write
#define GetName(s) ((s)->name)



              11.2.18 mname : File names (critical)


Definition:
-----------
A file name must be built from the name of the class declared or defined in this file.
The comparison is made only on alphanumeric characters and is not case sensitive.
The extension of the file name is not taken into account.
The part of the class name taken into account is between the MIN and the MAX
characters (these included). This character string should be found in the identifier
according to the above comparison rules.


Parameters:
----------
A MINMAX couple of values giving the part of the class name to take into account.


Example:
-------


if the MINMAX parameter is 4 and 10, and the class is
class CL_Graph_Node { ...}
then the comparison is made on the string : GRAPHN
(the first 10 characters: CL_Graph_N , minus the first 3: Graph_N , minus non alphanumeric characters:
GraphN )


Then, the class can be declared on the following files




                                 DEBAT – De velopment of EAST Based Access Tools
                                                                                    Reference   : SS/DEBAT/PAP
                                                DEBAT                               Issue.      : 1.1
                                         Product Assurance Plan                     Date        : 31/10/2002
                                                                                    Page        : 41


Cgraphnode.h
graph_node_def.hh
graph-n.hxx


But not in the following ones


graph.h
NodeGraph.h



              11.2.19 parse : Parse error


Definition:
-----------
This standard identifies module parts that could not be parsed.



              11.2.20 ptrinit : Pointer initialization (critical)


Definition:
-----------
Each auto variable that is explicitly declared as a pointer (using *),
must be initialized when declared.


Example:
-------


// write
int* y=&x;
...


// do not write
int *y ;
*y=&x ;
...




                                  DEBAT – De velopment of EAST Based Access Tools
                                                                                       Reference   : SS/DEBAT/PAP
                                               DEBAT                                   Issue.      : 1.1
                                        Product Assurance Plan                         Date        : 31/10/2002
                                                                                       Page        : 42


              11.2.21 sgdecl : A single variable per declaration


Definition:
-----------
Variable declarations have the following formalism: type variable_name.
It is forbidden to have more than one variable for the same type declarator.


Example:
-------


// write
int width;
int length;


// do not write
int width, length;




              11.2.22 swdef : default within switch (critical)


Definition:
-----------
A default case is mandatory within a switch in order to cover unexpected cases.


Parameters:
----------
The character string "last", which, if used, specifies that the default case has to be the last one.



              11.2.23 swend : End of cases in a switch (critical)


Definition:
-----------
Each case in a switch shall end with break , continue , goto , return or exit.
Several consecutive case labels are allowed.




                                 DEBAT – De velopment of EAST Based Access Tools
                                                                                     Reference   : SS/DEBAT/PAP
                                                 DEBAT                               Issue.      : 1.1
                                          Product Assurance Plan                     Date        : 31/10/2002
                                                                                     Page        : 43




Parameters:
-----------
The character string "nolast", which, if used, allows not to have one of these
instructions in the last case.



                 11.2.24 typeres : Reserved types


Definition:
-----------
Some types may be forbidden for variables or functions.
It is possible to define the list of types that are forbidden for variables
(extern , static , and automatic variables) and the list of types that are
forbidden for functions.
The type specifiers and qualifiers are forbidden in any order and even if
they are merged with other specifiers or qualifiers.
These types are allowed in typedef definition.


Parameters:
-----------
Two lists of strings beginning by the keywords "data" or "function".
The other items of the list are strings containing the forbidden groups
of type specifiers or type qualifiers separated by spaces.


Justification:
--------------
Not relying on predefined types improves code portability.


Example:
-------
The standard may be specified as following:


STANDARD typeres ON
LIST "data" "int" "char" "register double" END LIST
LIST "function" "unsigned int" "double" END LIST
END STANDARD




                                   DEBAT – De velopment of EAST Based Access Tools
                                                                                   Reference   : SS/DEBAT/PAP
                                               DEBAT                               Issue.      : 1.1
                                        Product Assurance Plan                     Date        : 31/10/2002
                                                                                   Page        : 44


              11.2.25 vararg : Variable number of parameters


Definition:
-----------
Functions with a variable number of arguments are not allowed.
Parameters of va_list type and ... are forbidden in function declarations.



              11.2.26 varstruct : struct and union variables


Definition:
-----------
Variables must not be directly declared using a struct or an union structure.
An intermediate type must be automatically used.


Parameters:
----------
The string "nostruct" which, if used, prevents from declaring a struct or
union variable except in a typedef structure.


WARNING! This option has no meaning in C++ programs, where class declarations
are always allowed outside a typedef structure.


Example:
-------


// write


typedef struct {
...
} typeName;


typeName varName;
struct structName;


typedef struct structName {
...




                                 DEBAT – De velopment of EAST Based Access Tools
                                                                                     Reference   : SS/DEBAT/PAP
                                                 DEBAT                               Issue.      : 1.1
                                          Product Assurance Plan                     Date        : 31/10/2002
                                                                                     Page        : 45


struct structName *ptr;
} typeName;
typeName varName;


// do not write


struct {
...
} varName;


// do not write, if the "nostruct" option is used


struct structName {
...
};
struct structName varName;



                 11.2.27 virtdestr : Virtual destructors


Definition:
-----------
Destructors of base classes must be declared virtual.
(This rule relates to Item 14 in "Effective C++", Scott Meyers).


Justification:
--------------
Ensures that base and derived destructors are called before memory deallocation.




                                   DEBAT – De velopment of EAST Based Access Tools