DEBAT Development of EAST Based Access Tools Product Assurance...

DEBAT – Development of EAST Based Access Tools

DEBAT Development of EAST Based Access ToolsProduct Assurance Plan

Contract : 16562/02/I-LGReference : SS/DEBAT/PAPIssue : 1.1Date : 31/10/2002

Prepared by :

Jean-Yves SouillardDate :

Checked by :

Christine MauryDate :

Approved by :

Carlos GuerreiroAlain Roussel

Date :

DEBATProduct Assurance Plan

Reference : SS/DEBAT/PAP Issue : 1.1 Date : 31/10/2002 Page : i


Document Status Sheet

Document Title DEBAT Product Assurance PlanDocument Reference Number SS/DEBAT/PAPIssue Revision Date Reason for change

1 0 14/10/2002 First issue1 1 31/10/2002 Integration of the remarks of A. CIARLO from ESA


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.0

Page Paragraph Reason for changeAll First issue

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.


Reference : SS/DEBAT/PAP Issue. : 1.1 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 .......................................................................................................... 5

1. INTRODUCTION.......................................................................................................................... 6

1.1 CONTEXT OF THE DEBAT PROJECT ............................................................................................. 61.2 SCOPE OF THE PAP ...................................................................................................................... 61.3 DEBAT QUALITY OBJECTIVES ..................................................................................................... 6

1.3.1 Quality factors...................................................................................................................... 61.3.2 Quality criteria ..................................................................................................................... 7

1.4 RESPONSIBILITIES RELATED TO THE PAP..................................................................................... 71.5 PAP EVOLUTION PROCEDURE ...................................................................................................... 71.6 PAP DEVIATIONS PROCEDURE ..................................................................................................... 7

2. DOCUMENTATION MANAGEMENT...................................................................................... 8

2.1 DOCUMENTATION IDENTIFICATION.............................................................................................. 82.2 DOCUMENT FORMAT AND PRESENTATION.................................................................................... 82.3 DOCUMENT APPROVAL, DISTRIBUTION AND MODIFICATION......................................................... 8

3. CONFIGURATION MANAGEMENT........................................................................................ 9

3.1 DEBAT CONFIGURATION MANAGEMENT .................................................................................... 93.2 CONFIGURATION MANAGEMENT ACTIVITIES ................................................................................ 93.3 CONFIGURATION MANAGED OBJECTS......................................................................................... 103.4 CONFIGURATION MANAGEMENT ORGANISATION ....................................................................... 103.5 CONFIGURATION IDENTIFICATION.............................................................................................. 103.6 CONFIGURATION FOR SOFTWARE DEVELOPMENT....................................................................... 113.7 CONFIGURATION MODIFICATION................................................................................................ 123.8 CONFIGURATION TOOL............................................................................................................... 12

4. ANOMALIES MANAGEMENT................................................................................................ 12

4.1 ANOMALY DEFINITION .............................................................................................................. 124.2 ANOMALY TRACKING................................................................................................................. 12

5. METHODS AND TOOLS........................................................................................................... 12

5.1 PROJECT MANAGEMENT ............................................................................................................ 125.2 DEVELOPMENT........................................................................................................................... 13

5.2.1 Development environment .................................................................................................. 135.2.2 Requirements...................................................................................................................... 13


Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : iv


5.2.3 Specification and design..................................................................................................... 145.2.4 Coding ................................................................................................................................ 145.2.5 Validation and tests............................................................................................................ 14

5.3 TRACEABILITY........................................................................................................................... 14

6. SUPPLIERS CONTROL............................................................................................................. 14

6.1 SUB-CONTRACTORS ................................................................................................................... 146.2 CO-CONTRACTORS..................................................................................................................... 146.3 BOUGHT, RENTED, IMPOSED OR RE-USED SOFTWARE................................................................. 15

6.3.1 Case of bought software products...................................................................................... 156.3.2 Case of rented software...................................................................................................... 156.3.3 Case of imposed software .................................................................................................. 15

7. REPRODUCTION, PROTECTION, DELIVERY................................................................... 15

7.1 REPRODUCTION.......................................................................................................................... 157.2 PROTECTION .............................................................................................................................. 157.3 DELIVERY.................................................................................................................................. 15

7.3.1 Responsibilities................................................................................................................... 167.3.2 Delivery procedure............................................................................................................. 16

8. QUALITY ACTIONS.................................................................................................................. 16

8.1 PURPOSE AND RESPONSIBILITIES................................................................................................ 178.2 MEANS....................................................................................................................................... 178.3 ORGANISATION.......................................................................................................................... 178.4 CONTROLS ON THE DEVELOPMENT PROCESS .............................................................................. 178.5 CONTROLS ON THE DOCUMENTATION ........................................................................................ 188.6 ASSURANCE AND CONTROLS ON THE CODE ................................................................................ 188.7 CONTROLS ON THE TESTS........................................................................................................... 198.8 CONTROLS ON THE DELIVERIES .................................................................................................. 198.9 SOFTWARE PRODUCT ASSURANCE REPORTING.......................................................................... 198.10 QUALITY TRACKING................................................................................................................. 19

9. ANNEX : BASIC METRICS DEFINITIONS AND BOUNDS FOR CODE CONTROLS ..20

9.1 DEFINITIONS .............................................................................................................................. 209.1.1 Metric “Comments frequency”.......................................................................................... 209.1.2 Metric “Number of statements”......................................................................................... 209.1.3 Metric “Cyclomatic number (VG)” ................................................................................... 209.1.4 Metric “Number of levels”................................................................................................. 21

9.2 BOUNDS PER LANGUAGE ............................................................................................................ 21

10. ANNEX : HEADER COMMENTS.......................................................................................... 22

10.1 FILES HEADER COMMENTS ....................................................................................................... 2210.2 OPERATIONS HEADER COMMENTS............................................................................................ 22

11. ANNEX : CODING STANDARD RULES .............................................................................. 23

11.1 JAVA CODING RULES .............................................................................................................. 2311.1.1 asscal : Assignement in function calls (critical)............................................................... 2311.1.2 asscon : Assignement in conditions (critical)................................................................... 2311.1.3 assexp : Assignement in expressions (critical)................................................................. 23


Reference : SS/DEBAT/PAP Issue. : 1.1 Date : 31/10/2002 Page : v


11.1.4 blockdecl : Declarations in blocks................................................................................... 2411.1.5 brkcont : Break and continue forbidden (critical) ........................................................... 2411.1.6 condop : Ternary ?: operator........................................................................................... 2411.1.7 const : Literal constants................................................................................................... 2411.1.8 ctrlblock : Blocks in control statements........................................................................... 2511.1.9 declord : Order of member declarations.......................................................................... 2611.1.10 dmaccess : Access to members data (critical)................................................................ 2711.1.11 exprcplx : Expressions complexity (critical) .................................................................. 2711.1.12 exprparenth : Parenthesis in expressions....................................................................... 2711.1.13 headercom : Function and class header comments....................................................... 2811.1.14 identl : Identifier length.................................................................................................. 2811.1.15 identres : Reserved identifiers (critical)......................................................................... 2911.1.16 mclass : A single class definition per file ....................................................................... 2911.1.17 mname : File names ....................................................................................................... 2911.1.18 parse : Parse error ......................................................................................................... 3011.1.19 proxdecl : Variable declaration close to the use............................................................ 3011.1.20 sgdecl : A single variable per declaration ..................................................................... 3011.1.21 slstat : One statement per line (critical)......................................................................... 3011.1.22 swdef : default within switch (critical) ........................................................................... 3111.1.23 swend : End of cases in a switch (critical)..................................................................... 31

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 operationalservices of registration, archiving, and dissemination of datadescriptions. It comprises: The CCSDS Secretariat supported by the CAAgent, and Member Agency Control Authority Offices (MACAO)

CAID Control Authority Identifier: A four-character restricted-domain ASCIIstring, which identifies an individual CA office or the CCSDSSecretariat.

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 descriptionswith 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


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 operationalresponsibilities and constraints specified within CCSDSRecommendations 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




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 PlanQP 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 fieldspecification 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




Applicable Documents

Title Date ReferenceAD1 ESRIN SOW “Development of

EAST Based Access Tools”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 Manuel d’assurance qualité CS SI/AERO/MAQ/01




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




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 theentire data life cycle for various kind of users (scientists, engineers, end-users,…), overcoming thecurrent limitations and problems, and fulfilling a range of needs expressed by existing orforthcoming users. The project is also aimed at ensuring the promotion and the diffusion of thetechnology.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 newusers) 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 betweencost and potential added-value).

ü Following the first phase, a negotiation period will permit to reach an agreement with ESAabout the subset functionalities to be included in the implementation plan. An AuthorisationTo 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 reusedsoftware 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 PAPfor 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 requirementsReliability : capacity of the software to operate correctly without incidentsMaintainability: capacity of the software to facilitate debugging of residual errors in a shorttimePortability : capacity of the software to minimise the effects of a change of software orhardware 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 theuser, when used under specified conditionsFunctionality : capability of the software product to provide functions which meet stated andimplied needs when the software is used under specified conditions




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 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-providedconditionsSimplicity : development choices are easy to understand and do not needlessly increasethe 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 isdevelopedClearness : 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 interpretresultsConciseness : 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 ;




ü the discrepancy is not justified and an action in order to correct it must be launched ; in thatcase the discrepancy will induce to fill an dialog form whose handling is described in theanomalies 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 toapply all along the project.

2.1 Documentation identification

Each deliverable document must be referenced with an unique identification number in order towarranty 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 ofthe documents.All documents are written in English and are delivered in Microsoft Word 2000 or compatiblesystems.

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.




In reviewing documents for formal reviews, the ESA Technical Officer will produce Review ItemDiscrepancies (RIDs). For any RID the requested action is either performed or a different closingaction agreed with the ESA Technical Officer.Any document version ready for delivery is approved with signatures by the CS Project Managerand then by the ESA Technical Officer or duly authorized delegates by signing a delivery noteprovided 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 originalspecification document as result of a traceable and accepted change (as normally occurring in anyproject), the document shall be re-issued with the necessary modifications, even if it was preparedin a different project phase.When changes are issued, “change bars” are used but not on the header or foot page, on the firstpage 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 productand its evolution.Configuration management allows to warranty and control a complete and consistent reference ofthe 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.

ü 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 themodifications made on any objects,

o it makes it possible to identify and restore the configuration at previous definedstages,

o it also makes it possible, following a scheduled modification, to define the set of theobjects that will have to be modified.

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 forthe objects directly available on the configuration. The referenced way, applies to thedocumentation 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 areferenced way.

3.4 Configuration management organisation

Before each delivery of a product, its configuration has to be produced and checked in order toknow 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 DEBATconfiguration report.Before each delivery of a DEBAT version, the configuration have to be updated and checked andthe 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.




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 ofthe 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 severalShared spaces (one per version) each with its own set of private spaces (but the repository remainsunique).Private Space :It is owned by only one developer. A developer may own several different private spaces (if he hasto 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 theprivate 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 topublish it for all the developers to go one step ahead.

PrivateSpace 1

PrivateSpace 2

PrivateSpace n

Check in

Check out

Shared Space(Public)

Objcts

Repository

Sources

Update




3.7 Configuration modification

Software elements which are configuration managed can be modified after an evolution or acorrection of an anomaly, in that case the element is modified, tested and delivered to theconfiguration 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 thedelivery 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 occurduring 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 thespecified 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 testcondition, the problem causes and close out status.This anomaly status list are included in the product description of the configuration report.

5. Methods and toolsThis chapter will describe the methods, the techniques and tools used for the development ofDEBAT.

5.1 Project Management

Project management refers to the process of planning, organising, directing, and controlling theeffort to efficiently achieve the technical objectives within the constraints of time schedule andbudget.




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 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




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 standardsThe coding standards to be applied to the developed software are adapted from CNES Frenchagency standards (see Quality Action chapter).ToolLOGISCOPE 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




6.3 Bought, rented, imposed or re-used software

6.3.1 Case of bought software products

In 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 theinstallations procedure recommended by the constructor.Check the suppliesThe Project Manager or the authorised project team members examine the documentation state andits completeness.They execute the available constructor tests.If the controls done on the products show that the product is not conform, the remarks are trackedon the delivery note before to be returned to the supplier. A copy of each delivery note is saved atCS 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'sresponsibility.

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 byall 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.




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 quiteexpensive 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 deliveriesAny document version ready for delivery is approved with signatures by the Contractor's ProjectManager 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 originalspecification document as result of a traceable and accepted change (as normally occurring in anyproject), the document is re-issued with the necessary modifications, even if it was prepared in adifferent 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 reusedsoftware and documentation).Software deliveriesAny software package is delivered on the electronic medium agreed with the ESA TechnicalOfficer: 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 thePAP 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 :




ü 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) compliantwith the characteristics and the requirements asked for this project, and to ensure the final productquality 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 topre-defined quality clauses (AFNOR Z61-102);

ü if necessary, organising audits: an audit is a methodical examination of a situation relating toa product, a process, an organisation, performed in collaboration with the parties involved inorder to check the conformity of the situation to pre-defined dispositions and the adequacyof 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 responsibleof the product. Then the author of the product has to answer to the dialog form, either the remarksare 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 realisedby the quality manager but only on the elements thrown by the first control, he has to control thedialog form and how the remarks have been processed. The dialog form is then stored by the qualitymanager (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 thedifferent meetings and reports if the organisation is compliant with the planning, the progress of theproject.




8.5 Controls on the documentation

Each document is controlled by the Project Manager for the technical aspects and by the QualityManager for the quality aspects (coherence). The final version of the documentation deliveredchecked 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 indicationthat 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 ruleso 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 metricsrespect the defined level and also to verify that the standard code rules are respected.Technical crossed controls may be also done; the quality manager prepare a planning of thesecontrols according to the development team; developers report results of the tests on dialog formswhich 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




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 LANGAGEADA

RNC-CNES-Q-80-505 REGLES ESSENTIELLES POUR L'UTILISATION DU LANGAGEFORTRAN 77

RNC-CNES-Q-80-506 REGLES ET RECOMMANDATIONS POUR L'UTILISATION DULANGAGE 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 ADA, 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 thetimetable 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 thecurrent 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”.




9. Annex : basic metrics definitions and bounds for codecontrols

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, experiencehas 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 mustcontain a sufficient number of comments. It is also better to distribute the comments evenly at thelevel of the statements that need commenting, rather than placing them all at the beginning of thefunction 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 closingcurly 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 ofstatements contained in a function, the greater the number of its operands and operators, whichmeans that a greater effort will be required to understand the function. It is therefore desirable thatthe 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. Thisbreakdown makes it possible to establish a better hierarchy of the functions performed by theprogram, 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 aconnected graph. For a connected graph g, the cyclomatic number is calculated as follows:

V(g) = E - N + 1




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 orseveral 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) andwhatever 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 controlstructure.It is therefore a good indicator of the effort the reader must make to understand the function'salgorithm and for evaluating the effort that will be required to test its control structure. This metriccan also be interpreted to indicate the minimum number of tests cases that will have to be generatedto test the function.A high cyclomatic number is often due to the fact that the function contains too many executablestatements. So the number of statements will have to be reduced either by subdividing the functionor by factorizing any code repetitions that it contains.This subdivision will result in subroutines being created which will contain the part of the controlstructure 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 overseveral 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 CommentsFrequency

Number ofstatements

Cyclomaticnumber (VG)

Number oflevels

Goalvalue

Minvalue

Goalvalue

Maxvalue

Goalvalue

Maxvalue

Goalvalue

Maxvalue

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




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




11. Annex : coding standard rulesAs indicated in chapter 8, the coding standards used on the project are adapted from CNESstandards (RNC).For the automatic control part, the adaptation has been done from the rules used by Logiscope tool.As an example, we present here JAVA rules as customized for the project.Critical notion has been added to the standard.The same exercise will be done for the other languages used on the project.

11.1 JAVA coding rules

11.1.1 asscal : Assignement in function calls (critical)

Definition:Assignment operators ( = , += , -=, *=, /= , %= , >>= , <<=, &=, |=, ^= , ++ , - - ) must not beused 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 beused 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, anassigned 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 blockdecl : Declarations in blocks

Definition:Declarations must appear at the beginning of blocks.Justification:Makes the code easier to read.

11.1.5 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 theswitch statement.Parameters:C++: None.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 thecode easier to understand.

11.1.6 condop : Ternary ?: operator

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

11.1.7 const : Literal constants

Definition:Numbers, characters and strings have to be declared as constants instead of being used as literalsinside 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 thesame 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.8 ctrlblock : Blocks in control statements

Definition:Block statements shall always be used in control statements (if , for , while , do).Justification:Removes ambiguity about the scope of instructions and makes the code easier to read and tomodify.Example:// do not writeif (x == 0) return;elsewhile (x > min) x--;// writeif (x == 0) { return;} else { while (x > min) { x--;




}}

11.1.9 declord : Order of member declarations

Definition:In a class, declarations must follow a particular order, given in the parameters of the rule.The order depends on the types of the declaration. The type is defined by:- the acces type (public, private, protected or package if no access type is specified),- the scope (class or instance),- the variable type (constant, attribute, method, constructor, type).The order is defined by an ordered list of strings defining a set of declaration types.A declaration of one type can not follow a declaration of another type if its type matches a set oftype that is before the set of types of the first one in the ordered list.A declaration matches a set of types if the set of types is the first of the list of the highest numberof criteria which includes the type of the declaration.Parameters:A list of character strings representing the declaration types in the wanted order.Each string contains a set of the above keywords. Several keywords of the category arealternatives.Several categories increase the number of criteria of the set. In addition to the keywords describedabove, "allaccess" means private, protected, public or package; "allscope" means class or instance;"alldecl" means constant, variable, method, constructor or type; "others" means any types notlisted above.Class definitions have not to contain all the types defined in the standard.If the constructor type does not appear in the list, constructors will be considered as ordinarymethods.It is advisable to use "allaccess", "allscope" and "alldecl" to increase the number of criteria of a set.For instance, use "allaccess allscope constructor" to match any constructor, but use "method" tomatch the methods not matched by other sets.Justification:Makes the code easier to read.Example:// if the standard has the following strings in this order:// "allaccess allscope constructor" "public class method" "public method" "method" "constant""others",// following declarations are allowedclass aClass { public aClass(){} public int f() {} int i;}class aClass {




static public void p() {} public int f(int j) {} int f() {} static final int ID = 123; class subClass { }}// and not the following one:class aClass {int f() {}public F() {}}

11.1.10 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, thestandard may be expressed as below:STANDARD dmaccess ON LIST "public" "protected" EN LIST END STANDARD

11.1.11 exprcplx : Expressions complexity (critical)

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: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 standardviolation.

11.1.12 exprparenth : Parenthesis in expressions

Definition:




In expressions, every binary and ternary operator has to be put in parenthesis, so that theevaluation priorities are not ambiguous.Use the partpar option to allow the following rules: when the right operand of a + or * operatoruses the same operator, you can omit parenthesis for it. In the same way, you can omitparenthesis in the case of the right operand of an assignment operator. Moreover, you can omitparenthesis at the first level of the expression.Parameters:The character string "partpar", which, if used, allows programmers not to put systematicallyparenthesis, 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 ofresult = ((fact * (ind * 100)) + (rem + (10 + (coeff ** c))));

11.1.13 headercom : Function and class header comments

Definition:Functions and classes must be preceded by a comment.C++: It is possible to define a format for this comment depending on the type of the functiondefinition or declaration, or class definition: func_glob_def, func_glob_decl, func_stat_def,func_stat_decl, class.ADA: It is possible to define a format for this comment depending on the type of the package orsubprogram: pack_decl, pack_body, proc_decl, proc_body,func_decl, func_body.JAVA: It is possible to define a format for this comment depending on the type of the item:module, interface, class, method, attribute.The format of the comment is defined as a list of regular expressions that shall be found in theheader comment in the order of declaration.Parameters:Five or six lists of character strings concerning the five cases listed above.Each list begins with one of the five strings (func_glob_def for instance), followed by a stringrepresenting the regular expression.

11.1.14 identl : Identifier length

Definition:




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

11.1.15 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.16 mclass : A single class definition per file

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

11.1.17 mname : File names

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 (theseincluded). This character string should be found in the identifier according to the abovecomparison 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 , minusthe first 3: Graph_N , minus non alphanumeric characters: GraphN )Then, the class can be declared on the following filesCgraphnode.hgraph_node_def.hhgraph-n.hxxBut not in the following onesgraph.hNodeGraph.h




11.1.18 parse : Parse error

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

11.1.19 proxdecl : Variable declaration close to the use

Definition:Variables must be declared as close as possible to their uses. Each local variable shall be declaredin the block where it is used or in the smallest block containing the blocks where it is used.If a variable is used in a loop (do, while, for) or a multiple alternatives statement (switch)it can be declared in the enclosing block.Local variables that are declared but not used is a violation of the rule.Justification:Improves code legibility and reliability.

11.1.20 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.1.21 slstat : One statement per line (critical)

Definition:There must not be more than one statement per line.A statement followed by a brace (instr { ) or a brace followed by a statement ({ instr ) is allowed inthe same line, but not both of them (instr { instr ).Example:// writex = x0;y = y0;while (IsOk(x)) {x++;}// do not writex = x0; y = y0;while (IsOk(x)) {x++;}




11.1.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.1.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 lastcase.

Date post:	01-Jul-2018
Category:	Documents
Upload:	buihanh
View:	221 times
Download:	0 times