caos xml ca sndebat.c-s.fr/project/documents/pap1.2.doc · web viewthe project manager or the...
TRANSCRIPT
DEBAT Development of EAST Based Access ToolsProduct Assurance Plan
Contract : 16562/02/I-LGReference : SS/DEBAT/PAPIssue : 1.2Date : 08/07/2003
Prepared by :
Maud GranetDate : 08/07/2003
Checked by :
Christine MauryDate : 08/07/2003
Approved by :
Carlos GuerreiroDate : 08/07/2003
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue : 1.2 Date : 08/07/2003 Page : i
Document Status Sheet
Document Title DEBAT Product Assurance PlanDocument Reference Number SS/DEBAT/PAP
Issue Revision Date Reason for change1 0 14/10/2002 First issue1 1 31/10/2002 Integration of the remarks of A. CIARLO from ESA1 2 08/07/2003 Integration of C++ coding rules and specific controls for the
Phase 2.
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : ii
Document Change Records
Document Title DEBAT Product Assurance PlanDocument Reference Number SS/DEBAT/PAPDocument Issue/Revision Number 1.2
Page Paragraph Reason for change17 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, 20, 21
8.12 Adding a paragraph for the specific controls lead during the phase 2
Annex 11 Integration of the C++ coding rules
Document Title DEBAT Product Assurance PlanDocument Reference Number SS/DEBAT/PAPDocument Issue/Revision Number 1.1
Page Paragraph Reason for change5 1.2 Integration of the remarks of A. CIARLO from ESA7 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 PlanDocument Reference Number SS/DEBAT/PAPDocument Issue/Revision Number 1.0
Page Paragraph Reason for changeCreation of the document
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : iii
Table of contentsDOCUMENT 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............................................................................................51.2 SCOPE OF THE PAP......................................................................................................................51.3 DEBAT QUALITY OBJECTIVES....................................................................................................5
1.3.1 Quality factors......................................................................................................................51.3.2 Quality criteria.....................................................................................................................6
1.4 RESPONSIBILITIES RELATED TO THE PAP....................................................................................61.5 PAP EVOLUTION PROCEDURE......................................................................................................61.6 PAP DEVIATIONS PROCEDURE.....................................................................................................6
2. DOCUMENTATION MANAGEMENT......................................................................................7
2.1 DOCUMENTATION IDENTIFICATION.............................................................................................72.2 DOCUMENT FORMAT AND PRESENTATION...................................................................................72.3 DOCUMENT APPROVAL, DISTRIBUTION AND MODIFICATION.......................................................7
3. CONFIGURATION MANAGEMENT........................................................................................8
1.1 DEBAT CONFIGURATION MANAGEMENT....................................................................................83.2 CONFIGURATION MANAGEMENT ACTIVITIES...............................................................................83.3 CONFIGURATION MANAGED OBJECTS..........................................................................................93.4 CONFIGURATION MANAGEMENT ORGANISATION........................................................................93.5 CONFIGURATION IDENTIFICATION...............................................................................................93.6 CONFIGURATION FOR SOFTWARE DEVELOPMENT......................................................................103.7 CONFIGURATION MODIFICATION...............................................................................................113.8 CONFIGURATION TOOL..............................................................................................................11
4. ANOMALIES MANAGEMENT................................................................................................11
4.1 ANOMALY DEFINITION..............................................................................................................114.2 ANOMALY TRACKING................................................................................................................11
5. METHODS AND TOOLS...........................................................................................................11
5.1 PROJECT MANAGEMENT............................................................................................................115.2 DEVELOPMENT..........................................................................................................................12
5.2.1 Development environment..................................................................................................125.2.2 Requirements......................................................................................................................12
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : iv
5.2.3 Specification and design.....................................................................................................135.2.4 Coding.................................................................................................................................135.2.5 Validation and tests............................................................................................................13
5.3 TRACEABILITY...........................................................................................................................13
6. SUPPLIERS CONTROL.............................................................................................................13
1.1 SUB-CONTRACTORS...................................................................................................................136.2 CO-CONTRACTORS.....................................................................................................................136.3 BOUGHT, RENTED, IMPOSED OR RE-USED SOFTWARE................................................................14
6.3.1 Case of bought software products......................................................................................146.3.2 Case of rented software......................................................................................................146.3.3 Case of imposed software...................................................................................................14
7. REPRODUCTION, PROTECTION, DELIVERY...................................................................14
1.1 REPRODUCTION.........................................................................................................................147.2 PROTECTION..............................................................................................................................147.3 DELIVERY..................................................................................................................................14
7.3.1 Responsibilities...................................................................................................................157.3.2 Delivery procedure.............................................................................................................15
8. QUALITY ACTIONS..................................................................................................................15
8.1 PURPOSE AND RESPONSIBILITIES...............................................................................................168.2 MEANS.......................................................................................................................................168.3 ORGANISATION..........................................................................................................................168.4 CONTROLS ON THE DEVELOPMENT PROCESS.............................................................................168.5 CONTROLS ON THE DOCUMENTATION.......................................................................................178.6 ASSURANCE AND CONTROLS ON THE CODE...............................................................................178.7 CONTROLS ON THE TESTS..........................................................................................................188.8 CONTROLS ON THE DELIVERIES.................................................................................................188.9 SOFTWARE PRODUCT ASSURANCE REPORTING........................................................................188.10 QUALITY TRACKING................................................................................................................188.11 SPECIFIC QUALITY ACTIONS FOR THE PHASE 1......................................................................188.12 SPECIFIC QUALITY ACTIONS FOR THE PHASE 2......................................................................18
8.12.1 Type of controls during the Phase 2.................................................................................198.12.2 Control plan......................................................................................................................20
9. ANNEX : BASIC METRICS DEFINITIONS AND BOUNDS FOR CODE CONTROLS. .22
1.1 DEFINITIONS..............................................................................................................................229.1.1 Metric “Comments frequency”...........................................................................................229.1.2 Metric “Number of statements”.........................................................................................229.1.3 Metric “Cyclomatic number (VG)”....................................................................................229.1.4 Metric “Number of levels”.................................................................................................23
9.2 BOUNDS PER LANGUAGE...........................................................................................................23
10. ANNEX : HEADER COMMENTS..........................................................................................24
1.1 FILES HEADER COMMENTS.........................................................................................................2410.2 OPERATIONS HEADER COMMENTS...........................................................................................24
11. ANNEX : CODING STANDARD RULES..............................................................................25
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : v
11.1 JAVA CODING RULES..............................................................................................................2511.1.1 asscal : Assignement in function calls (critical)...............................................................2511.1.2 asscon : Assignement in conditions (critical)...................................................................2511.1.3 assexp : Assignement in expressions (critical).................................................................2511.1.4 brkcont : Break and continue forbidden (critical)............................................................2511.1.5 condop : Ternary ?: operator...........................................................................................2611.1.6 const : Literal constants....................................................................................................2611.1.7 dmaccess : Access to members data (critical)..................................................................2611.1.8 exprcplx : Expressions complexity....................................................................................2711.1.9 exprparenth : Parenthesis in expressions.........................................................................2711.1.10 identl : Identifier length..................................................................................................2711.1.11 identres : Reserved identifiers (critical).........................................................................2811.1.12 mclass : A single class definition per file.......................................................................2811.1.13 parse : Parse error.........................................................................................................2811.1.14 sgdecl : A single variable per declaration......................................................................2811.1.15 swdef : default within switch (critical)...........................................................................2811.1.16 swend : End of cases in a switch (critical).....................................................................28
11.2 C++ CODING RULES.................................................................................................................2811.2.1 asscal : Assignement in function calls (critical)...............................................................2811.2.2 asscon : Assignement in conditions (critical)...................................................................2911.2.3 assexp : Assignement in expressions (critical).................................................................2911.2.4 brkcont : Break and continue forbidden (critical)............................................................3011.2.5 cmclass : A single class per code file...............................................................................3011.2.6 condop : Ternary ?: operator...........................................................................................3011.2.7 const : Literal constants....................................................................................................3011.2.8 destr : Destructor (critical)..............................................................................................3111.2.9 dmaccess : Access to members data (critical)..................................................................3111.2.10 exprparenth : Parenthesis in expressions.......................................................................3211.2.11 fntype : Function types....................................................................................................3311.2.12 goto : "goto" statement...................................................................................................3311.2.13 hmclass : A single class definition per header file.........................................................3311.2.14 hmdef : Header module content......................................................................................3311.2.15 hmstruct : Header module structure...............................................................................3411.2.16 mconst : Macro constant usage......................................................................................3411.2.17 mfunc : Inline functions instead of macro functions.......................................................3511.2.18 mname : File names (critical).........................................................................................3611.2.19 parse : Parse error.........................................................................................................3611.2.20 ptrinit : Pointer initialization (critical)..........................................................................3611.2.21 sgdecl : A single variable per declaration......................................................................3711.2.22 swdef : default within switch (critical)...........................................................................3711.2.23 swend : End of cases in a switch (critical).....................................................................3711.2.24 typeres : Reserved types..................................................................................................3811.2.25 vararg : Variable number of parameters........................................................................3811.2.26 varstruct : struct and union variables............................................................................3811.2.27 virtdestr : Virtual destructors.........................................................................................39
DEBAT – Development of EAST Based Access Tools
DEBATProject Assurance Plan
Reference : SS/DEBAT/PAP Issue : 1.1 Date : 31/10/2002 Page : 1
Acronyms and Abbreviations
ADAR Advanced Data Archive for Earth ObservationADD Architectural Design DocumentADID Authority and Description Identifier: The concatenation of the Control
Authority Identifier (CAID) and the Data Description Identifier (DDID).AGF Advanced Ground FacilityAIP Archival Information PackageAIS Advanced Inventory ServerAMOR Automated MOnitoring, control and Reporting toolsAMS Archive Management SystemAPI Application Program InterfaceAR Acceptance ReviewASCESA An e-Science and Collaborative Environment for Space ApplicationsATVBSSC ESA’s Board for Software Standardization and ControlCA 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 OfficeCAOS Control Authority Office SystemCCF Computer Compatible FormatCCS Cascading Style SheetsCCSDS Consultative Committee for Space Data SystemsCDF Channel Definition FormatCDR Critical Design ReviewCEOS Committee on Earth Observation ScienceCFI Customer Furnished ItemCNESCOTS Commercial off-the-shelf SoftwareCORBA Common Object Request Broker ArchitectureCPU Central Processing UnitDDF Design Definition FileDDID 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 LanguageDDU Data Description UnitDEBAT Development of EAST Based Access ToolsDED Data Entity dictionariesDEDSL Data Entity Description Specification LanguageDIP Dissemination Information Package
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 2
DJF Design Justification FileDTD Document Type definitionDW Data WarehouseEAST Enhanced Ada SubsetECSS European Cooperation for Space StandardizationEMITS ESA's Electronic Mail Invitation to Tender SystemEO Earth ObservationERS European Remote Sensing satelliteESA European Space AgencyESRIN European Space Research INstituteESTECEVA ESA Virtual ArchiveFDIR Fault Detection, Isolation and RecoveryFMECA Failure Mode Effect and Criticality AnalysisGS Ground SegmentGSFC Goddard Space Flight CenterHiProGenEx High Level Product Generation and Extraction (ESA development)HSIA Hardware Software Interaction AnalysisHTML Hyper Text Mark-up LanguageHW HardwareICD Interface Control DocumentIRB Interface Requirements BaselineIRD Interface Requirements DocumentISI Internet Storage InfrastructureISO International Organization for StandardizationISV Independent Software ValidationISVV Independent Software Verification and ValidationITT Invitation To TenderKEO Knowledge-centric Earth ObservationLAN Local Area NetworkLVO Label Value ObjectMACAO 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 toolMF Maintenance FileMGT ManagementMMI Man-Machine InterfaceMOTS Modifiable off-the-ShelfNAS Network Attached StorageNASA National Aeronautics and Space AdministrationNJPL NASA Jet Propulsion LaboratoryNOAA National Oceanic and Atmospheric AdministrationNSSDC National Space Science Data CenterNUARS NASA Upper Atmosphere Research Satellite projectOAIS Open Archival Information SystemOASIS Organisation for the Advancement of Structured Information Standards
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 3
OP Operational PlanORR Operational Readiness ReviewPAC Processing and Archiving CentresPAF Processing and Archiving FacilityPAP Product Assurance PlanPDF Portable Document Format (an Adobe standard)PDR Preliminary Design ReviewPMP Project Management Plan QP Quality PlanQR Qualification ReviewRB Requirements BaselineRDF Resource Description FrameworkRID Review Item DiscrepanciesRTD Research and Technology DevelopmentSAN Storage Area NetworkSCMP Software Configuration Management PlanSDE 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 PackageSMOG impact of Small Missions on earth-Observation Ground segment systemsSoW Statement of WorkSPMP Software Project Management PlanSPR Software Problem ReportSRR System Requirements ReviewSSP Storage Service ProviderSVG Scalable Vector GraphicsSW SoftwareTM/TCTS Technical SpecificationW3C World Wide Web ConsortiumWEU Western European UnionWP Work PackageWRS World Reference SystemWWW World Wide WebXHTML Extensible Hypertext Mark-up LanguageXML eXtensible Mark-up LanguageXSL Extensible Stylesheet LanguageXSLT Extensible Stylesheet Language Transformation
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 4
Applicable Documents
Title Issue Date ReferenceAD1 ESRIN SOW “Development of
EAST Based Access Tools”1.1 18/03/2002 GSPS-RTDA-EOAD-SW-02-0001
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 Standards – Software ECSS-E-40B
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 meeting (Authorisation To Proceed)
30/04/2003 /CRR/SS/DEBAT/006
Reference Documents
Title Date ReferenceRD1 Statement of Work, GSPS-RTDA-
EOAD-SW-02-000118/04/2002
RD2 DEBAT Project Management Plan 14/10/2002 SS/DEBAT/PMP
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 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 factorsThe following quality factors will determine project development :Conformity : satisfying user requirementsReliability : capacity of the software to operate correctly without incidentsMaintainability: capacity of the software to facilitate debugging of residual errors in a short timePortability : 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 computersOperability : homogeneity and compatibility, conciseness and ease of useUsability : the capacity of the software to be understood, learned, used and liked by the user, when used under specified conditionsFunctionality : capability of the software product to provide functions which meet stated and implied needs when the software is used under specified conditions
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 6
1.3.2 Quality criteriaThese 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 softwareCompleteness: all of the components are present and have been correctly describedConsistency : uniform notation and terminology are usedRobustness : 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 complexityPrecision : the results or effects supplied are just and conformModularity : software is composed of independent elementsIndependence 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 computerAuto-description : characteristic of software that can be used to explain how a function is developedClearness : characteristic of software whose inputs and outputs are easy to understandEase of use : characteristic of software for which it is easy to prepare data and interpret resultsConciseness : characteristic of software, which has no useless or redundant elements
1.4 Responsibilities related to the PAP
AuthorThe DEBAT quality manager is responsible for writing the DEBAT PAP.
ApprovalThe 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 – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 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 managementThis 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.ywhere 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 – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 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:
Availabilityo each object must be continuously available,o the object must be available in various versions.
Securityo references of each object managed in configuration are controlled,o objects managed in configuration are saved/backed-up.
Consistencyo 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.
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 9
3.2 Configuration management activities
The following activities have to be handled: 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 – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 10
3.6 Configuration for software development
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 – Development of EAST Based Access Tools
PrivateSpace 1PrivateSpace 2
PrivateSpace n
Check in
Check out
Shared Space(Public)
Objcts
Repository
Sources
Update
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 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 managementThis 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 – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 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.ToolsWordExcelMS-Project
5.2 Development
5.2.1 Development environmentThe 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 RequirementsMethod
CS Interview methodology, CS requirements collection methodology
Tools Microsoft Word 97/2000, Excel
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 13
5.2.3 Specification and designMethod
HOOD, UML-CS methodology
Tools STOOD, UML Rational Rose Microsoft Word 97/2000
5.2.4 CodingLanguages
ADA, JAVA, C++, C, FORTRAN77.
Coding standardsThe coding standards to be applied to the developed software are adapted from CNES French agency standards (see Quality Action chapter).ToolLOGISCOPE will be used to compute metrics and check coding rules.
5.2.5 Validation and testsIntegration 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 – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 14
6.3 Bought, rented, imposed or re-used software
6.3.1 Case of bought software productsIn case of bought software:Receive the deliveryThe 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 suppliesThe Project or the authorised project team members set up the supplies by implementing the installations procedure recommended by the constructor.Check the suppliesThe 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 softwareWithout object
6.3.3 Case of imposed softwareWithout 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 – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 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 ResponsibilitiesThe Project Manager is responsible for the deliveries of the DEBAT products.
7.3.2 Delivery procedureDocumentation deliveriesAny 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 deliveriesAny 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 actionsThis 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 – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 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 – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 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 – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 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 90RNC-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 – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 19
8.12.1 Type of controls during the Phase 2These 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 2C-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 phaseC-DV-CUT-2 Check the source codes in relation to the project coding standards. Each
developer controls his production by means of code control toolsC-DV-CUT-3 Use cross-checking reviews to control a source code per language and per
individualC-IQ-CUT-4 Control a source code per language and per individual in order to check
that coding rules and their application have been assimilatedC-IQ-CUT-5 Use control tools to check the whole of the production codeC-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 phaseC-CP-VAL-7 Check for the existence of validation tests and that the test strategy has
been correctly appliedC-IQ-VAL-8 Check that the test has been recorded as well as the results of the
validation testsC-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 – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 20
8.12.1.4 Controls before submitting for acceptanceC-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 2C-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 milestoneC-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 planThe 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 controlsThe following table summarises the controls and their scope when creating an element.
CONTROLLED ELEMENT CONTROL RATE CONTROL MANAGERDocumentation Control of form and
content : 100 %Quality responsible
Source code Cross-checking review : 1 section of code per individual and per programming language
Development team
Automatic controls using tools (for the programming languages
Quality responsible
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 21
CONTROLLED ELEMENT CONTROL RATE CONTROL MANAGERcovered): 100% of source files(at the end of coding phase)
Test environment 1 per individual and per type of test
Quality responsible
Configuration Management
100% during first acceptance delivery
Configuration management manager
Control of consistency by sampling
Quality responsible
8.12.2.2 Details on the scope of code controlsCodes 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 ControlsThe 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 – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 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 WHILEDO FOR GOTO BREAK CONTINUERETURN THROW TRY ASMexpression;(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 – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 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 + AExwhere:
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 Frequency
Number of statements
Cyclomatic number (VG)
Number of levels
Goal value
Min value
Goal value
Max value
Goal value
Max value
Goal value
Max value
C 30% 20% 70 100 20 30 4 6C++ 30% 20% 70 100 20 30 4 6JAVA 30% 20% 70 100 20 30 4 6FORTRAN 30% 20% 70 100 20 30 4 6ADA 30% 20% 70 100 20 30 4 6
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 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 – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 25
11. Annex : coding standard rulesThe 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 writeif (x -= dx) { ...for (i=j=n; --i > 0; j--) { ..// writex -= 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:// do not writei = t[i++];a=b=c+a;i=t[i]=15;
11.1.4 brkcont : Break and continue forbidden (critical)Definition:
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 26
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 ?: operatorDefinition:The conditional operator ? ... : ... must not be used.
11.1.6 const : Literal constantsDefinition: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:// do not writechar tab[100];int i;...if (i == 7) {p = "Hello World.";}// write#define TAB_SIZE 100enum 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:
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 27
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 complexityDefinition: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: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 expressionsDefinition: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 writeresult = fact / 100 + rem;// writeresult = ((fact / 100) + rem);// or write, with the partpar optionresult = (fact / 100) + rem;// with the partpar option, writeresult = (fact * ind * 100) + rem + 10 + (coeff ** c);// instead of result = ((fact * (ind * 100)) + (rem + (10 + (coeff ** c))));
11.1.10 identl : Identifier lengthDefinition:
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 28
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.
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 fileDefinition:A file must not contain more than one class definition.Nested classes are tolerated.
11.1.13 parse : Parse errorDefinition:This standard identifies module parts that could not be parsed.
11.1.14 sgdecl : A single variable per declarationDefinition:Variable declarations have the following formalism: type variable_name. It is forbidden to have more than one variable for the same type declarator.Example:// writeint width;int length;// do not writeint 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: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.
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 29
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
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.
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 30
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:-----------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 themin 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.
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 31
11.2.7 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, oftenwith the same value.
Example:-------
// do not write
char tab[100];int i;...if (i == 7) {p = "Hello World.";}
// write
#define TAB_SIZE 100enum i_val { ok =7; ko =11};const char HelloWorld[] = "Hello World.";char tab[TAB_SIZE];i_val i;...if (i == ok) {p = HelloWorld;}
11.2.8 destr : Destructor (critical) Definition:-----------Each class must contain its destructor explicitly.
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 32
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:-----------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 writeresult = fact / 100 + rem;
// writeresult = ((fact / 100) + rem);
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 33
// or write, with the partpar optionresult = (fact / 100) + rem;
// with the partpar option, writeresult = (fact * ind * 100) + rem + 10 + (coeff ** c);
// instead of result = ((fact * (ind * 100)) + (rem + (10 + (coeff ** c))));
11.2.11 fntype : Function types 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 easierto understand. The goto statement often reveals an analysis error and its systematicrejection 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.
11.2.14 hmdef : Header module content Definition:
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 34
-----------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 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:
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 35
-----------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:-------
// writeconst char *string = "Hello world!";#define value 3
// do not write#define string "Hello world!"
- const : const data are always used instead of macros,
Example:-------
// writeconst 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:-----------
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 36
Use inline functions instead of macro-functions.
Example:-------
// writeinline 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 isclass 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
Cgraphnode.hgraph_node_def.hhgraph-n.hxx
But not in the following ones
graph.hNodeGraph.h
11.2.19 parse : Parse error Definition:-----------
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 37
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:-------
// writeint* y=&x;...
// do not writeint *y ; *y=&x ;...
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:-------
// writeint width;int length;
// do not writeint 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.
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 38
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.
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 LISTLIST "function" "unsigned int" "double" END LIST END STANDARD
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.
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 39
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 {...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).
DEBAT – Development of EAST Based Access Tools
DEBATProduct Assurance Plan
Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : 40
Justification:--------------Ensures that base and derived destructors are called before memory deallocation.
DEBAT – Development of EAST Based Access Tools