Home

Software Quality and Coding Rules

1. Table 24 List of metrics that cannot be found in SPEC Annex QUALITY MODEL TREE The table below provides the complete quality model as defined in RD 3 Goal property Property Metric Code Documentation Development A Code Comment frequency Quality maintenance Documentation clarity VERSION 1 0 DRAFT B 2004 12 01 27 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES Goal property Property documentation quality Documentation suitability DOQ AD M3 Operation related Documentation clarity DOQ OD M1 documentation quality Documentation suitability DOQ OD M2 Requirements quality Number of conflicting requirements DOQ RQ M1 Requirements clarity DOQ RQ M2 Requirements completeness DOQ RQ M3 Requirements volatility rate DOQ RQ M4 Requirements duplication DOQ RQ M5 Functionality Completeness Technical specification software requirements FUN CM M1 mapping rate Functional implementation coverage FUN CM M2 Requirements program units mapping rate FUN CM M3 Verification activities mapping rate FUN CM M4 Functional requirements user manual items FUN CM M mapping rate Correctness Efficiency Bodem ENEE Menen FOE Maintainability JAnalysability Changeability Modularity Modular span of control Average of MAIN MO M1 cu cdused Modularity size profile Average of Ic stat MAIN MO M2 Modular coupling MAIN M
2. O Oo 0D 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 3 1 2 Logiscope for classes Factor Criterion class MAINTAINABILITY class TESTABILITY VERSION 1 0 DRAFT B 2004 12 01 6 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES class STABILITY class CHANGEABILITY class ANALYZABILITY class REUSABILITY class ANALYZABILITY class SPECIALIZABILITY class USABILITY Table 5 Factors at class level in the Logiscope model Criterion Metric Weight class ANALYZABILITY COMEFclass 1 0 FAN OUTclass 1 0 FAN INclass 1 0 cl dep meth 1 0 in bases 1 0 cl wmc 1 0 class CHANGEABILITY SPEGIAL 1 0 USABLE 1 0 ENCAP 1 0 class STABILITY cu_cdusers 1 0 cl_cobc 1 0 In_noc 1 0 AUTONOM 1 0 class_TESTABILITY cu_cdused 1 0 TESTAB 1 0 in_bases 1 0 class USABILITY AUTONOM 1 0 ENCAP 1 0 USABLE 1 0 class SPECIALIZABILITY AUTONOM 1 0 ENCAP 1 0 SPECIAL 1 0 Table 6 Criteria at class level in the Logiscope model 2 3 1 3 Logiscope foir methods and functions Factor Criterion function MAINTAINABILITY function TESTABILITY function STABILITY function CHANGEABILITY function ANALYZABILITY relativeCall MAINTAINABILITY relativeCall TESTABILITY relativeCall STABILITY relative
3. The check precedure shall ensure that All software requirements are traced to system requirements All software requirements have been successfully tested All requirements are implemented and tested this includes requirements on performance resources etc VERSION 1 0 DRAFT B 2004 12 01 16 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES 3 Definition of the static model 3 1 Introduction In order to perform the verification of the software coding rules a mechanism was depicted to classify and verify the compliance of delivered source code against the established coding standards RD 6 and RD 9 In addition to this classification and in order to ease the conformance verification process the coding rules text was analysed and two classes of verification were identified automated verification and manual verification This is detailed in section 3 3 3 2 Rule classification An analysis of the rules defined in RD 6 was performed and these were aggregated in three different categories Category ID Description These rules are considered mandatory and shall be followed in the software Core rules development projects Recommended Rules These rules should be followed in the software development projects These rules are de scoped due to their non compliance with the existing code base De scoped rules and should not be followed in software development cycles Ta
4. 12 1 funcion Yes Number of direct used classes cu cdused 7 0 class Yes VERSION 1 0 DRAFT B 2004 12 01 4 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 name SOFTWARE QUALITY AND CODING RULES Logiscope Applicable to Number of direct users classes cu cdusers 4 Ojclass Number of callers dc_calling 7 0 funcion Number of direct calls de calls 5 0 funcion No Number of local variables dc_lvars 5 0 funcion No Encapsulation rules ENCAP 5 O class No Fan In FAN_IN 4 O funcion No Fan in of aclass FAN_Inclass 15 O class No Fan Out FAN OUT 4 0 funcion No Fan out value of a class FAN OUTclass 20 O class No Number of parameters passed ic paradd 2 O funcion No by reference Number of function parameters ic param 5 O funcion Yes Number of parameters passed IC parval 2 O funcion No by value Number of distinct uses of ic_varpe 2 0 funcion No external attributes Number of base classes in_bases 3 O class Yes Number of children in noc 2 O class Yes Number of relative call graph IND CALLS 30 1 funcion No call paths Number of statements Ic stat 20 1 funcion Yes Number of levels LEVL 4 1 funcion Yes Percentage of non member NMM Ratio 10 0 application No functions Ratio of recursive edges on the RECU Ratio 5 0 application No call graph Specializability SPECIAL 25 Ojclass Yes Testability TESTAB 100 Ojclass Yes Ratio of repeated inheritances URI Ratio 10 Ojapplication Yes in the applic
5. 2 5 defines the specific checks that need to be applied Detail traceability information between the SPEC model and the metrics and checks defined here can be found in 0 while Annex A contains a table that summarizes the SPEC model VERSION 1 0 DRAFT B 2004 12 01 2 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES 2 Definition of the quality model 2 1 Introduction A quality model is composed of several main properties sometimes also called factors that characterised the software quality These properties are further characterised by sub properties sometimes known as criteria which in turn can be measured using a specific methodology known as a metric The quality model is completed by assigning a value or range to each metric The quality model presented in this document is based on RD 3 and RD 4 There are two kinds of metrics The first group consists of measurements that can be obtained by inspecting the code e g number of lines per method Such measurements will provide a numerical result that has to fall within the specified range These metrics are suitable for automation using a tool The name metric is used in this document to refer to them The selection of the values for the metrics is mainly based on the values provided in RD 3 If the metric in question is not present in this document then a suitable value has been obtained based on common practice All t
6. 7 C 4 A PC 7 C const PC 8 C constrcpy PC 31 C constrdef PC 28 C PC 34 C PC 37 C A constrinit PC 28 C ctrlblock GI 3 C delarray PC 18 C B destr PC 29 C PC 10 C PC 27 C dmaccess PC 10 C B exprparenth PC 14 C PC 15 C fntype EMPTY Not in C coding conventions but Rule 61 of the BSSC funcres GL 7 C A headercom GL 11 C hmclass GL 9 C PC 6 C PM 1 C A PC 6 C hmdef GL 9 C hmstruct GL 11 C identfmt NC 1 C imptype PC 32 C PC 33 C inldef PC 27 0 E GL 15 C mname PM 1 C multiass EMPTY multinher PC 26 C nonleafabs PC 26 C PC 26 C B nostruct PC 52 C operass PC 35 C overload PC 13 C A ptrinit PC 34 C refclass PC 38 C returnthis PC 36 C sectord Appendix 1 sgdecl PC 10 C PC 9 C slcom EMPTY Not in C coding conventions but Rule 14 of the BSSC PC 25 C 4 B swdef PC 25 C A swend PC 25 C A varinit PC 37 0 PC 10 C virtdestr PC 30 C A voidptr PC 24 C H VERSION 1 0 DRAFT B 2004 12 01 22 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES Table 20 Automated Static Checks 3 3 2 Manual Inspections There are rules that due to their nature cannot be verified by means of automated tools such as Tau Telelogic s Logiscope Rulechecker RD 8 and where the manual intervention is
7. 8 C keyword if the actual language provides such a facility PC 9 C Each variable shall have its own declaration on its own line Each filename shall provide indication of modular relationship as well as functionality PM 1 C implemented For each class the implementation shall be distributed in two files one for the interface specification and one for the actual implementation respectively with the h and c PM 1 C A extensions PM 1 C B The first 3 5 letters of the filename shall indicate to which module the code belongs The programmer shall consciously use the namespace facilities to organize his name PM 2 C A SCopes Table 17 Core Static Rules 3 2 2 Recommended Rules Rule ID Rule title GC 11 C Minimize any debugging code Each project shall define the maximum length in characters of the source code lines e g GL 1 C each line of source code shall be no more than 80 characters in length GL 10 C The interface file must be the first included in its own corresponding implementation file GL 13 C The public interface file shall be self contained and self consistent Use a utility or proforma to provide the starting point for all files within each particular GL 8 C subsystem library or module NC 1 C Names shall in general not start with an underscore character _ NC 11 C Each enumeration within an enumerated type shall hav
8. C B lf the call to new uses then the corresponding call to delete must also use PC 18 C C After calling delete set the pointer to null or 0 PC 20 C The return values of functions should be checked for errors When fallible functions fail they shall indicate that they have failed by returning an error PC 22 C A code or an out of bound value Fallible functions should never return a reference when fallible functions fail they shall PC 22 C B indicate that they have failed by returning an error code or an out of bound value When fallible functions fail in ways that are fully described by their return value they should PC 22 C C not raise an msg error or warning PC 22 C D When infallible functions fail they should raise a fatal error PC 22 C E Whenever a fallible function is called the return code shall always be checked PC 22 C G C exceptions shall never be used without an appropriate design concept PC 23 C the programmer should use problem domain types rather than implementation types PC 24 C Use non portable code shall be minimized The programmer may only assume range char lt range short lt range int lt PC 24 C A range long The programmer may only assume that range float lt range double lt range long PC 24 C B double The programmer may not assume knowledge of the representation of data types in PC 24 C C memory which implies that the use of memory dumps are forbidde
9. CM M5 Documentation checks Me TG Functionality Correctness FUN CR M7 Static analysis Functionality Efficiency FUN EF M1 Traceability checks Maintainability Analysability MAIN AN M3 checks Maintainability Analysability MAIN AN M5 Static analysis Maintainability Analysability MAIN AN M8 VERSION 1 0 DRAFT B 2004 12 01 24 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES checks Maintainability Changeability MAIN CH M3 PA checks Maintainability Verifiability MAIN VE M1 N A checks Operability Usability OPE US M2 Documentation checks Operability Virtuality OPE VI M1 Operability checks Reliability Maturity REL MA M1 reliability checks Reliability Recoverability REL RC M1 reliability checks Reliability Robustness REL RO M1 Reliability checks Re usability Re usability Documentation REU RD M1 Reusability checks Software Development Software development process level SDE DL M1 Process checks Effectiveness Software Development Software development process SDE PE M1 Process checks Effectiveness evidence Software Development Software development process SDE PE M2 Process checks Effectiveness evidence System Engineering Interfaces management SEE IN M1 effectiveness Effectiveness checks System Engineering Requirements propagation SEE RQ M1 N A Effectiveness System Engineering System engineering process evidence SEE SE M1 N A Effectiveness System Engineering System e
10. Rules 3 3 Compliance methodology To verify the standards compliance each rule was analyzed to identify a method for checking compliance being two major categories depicted e Automated check This will make use of automated testing tools in our case the Logiscope suite from Tau Telelogic e Manual inspections This comprises the manual inspection of build outputs log files documents and source code 3 3 1 Automated checks The table below presents the mapping between the rules from RD 6 to the Tau Telelogic tool Logiscope set of checks As can be observed there are several cases where one single Logiscope check e g ansi verifies more than one coding convention rule and where one tule is verified in more than one logiscope check The reader is deferred to RD 8 for the detailed description of the Logiscope checks In the cases where the mapping to the C Naming and Coding Conventions RD 6 is not possible it is attempted to map against the BSSC C and C Coding Standards RD 9 rules This mapping is presented in the comment column VERSION 1 0 DRAFT B 2004 12 01 21 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES Logiscope check Rule Ids Comment ansi PC 33 C PC 32 C ansi PC 31 C C asscon PC 13 C boolean PC 13 C cast EMPTY Not in C coding conventions but Rule 91 of the BSSC cmclass PC 26 C cmdef GL 9 C GL 15 C PC
11. and information about the code GC 8 C Always identify the source of warnings and correct the code to remove them GC 9 C Do not attempt to optimize the code until it is proved to be necessary GL 11 C Each file shall contain a standard comment header block Each file header block shall contain information on configuration management tracking of GL 12 C changes spr numbers name of author etc VERSION 1 0 DRAFT B 2004 12 01 17 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES GL 15 C The interface file shall contain declarations only Each nested block of code including one line blocks shall be identifiable through the code GL 2 C layout GL 2 C A All aspects of indentation and formatting shall be consistent within a project Each project shall define its own indentation rules e g the contents of each nested block GL 4 C shall be indented by 3 spaces compared to the token which delimit the block GL 5 C Tabs are not allowed Use separate folders for each of the subsystems and libraries defined during the design GL 6 C phase GL 7 C A Never use goto longjmp setimp malloc free realloc GL 9 C Source code shall be separated into an interface and an implementation file Names for system global entities shall con
12. conditional compilation clauses that depend on the hardware ifdef SOLARIS and divide by total number of units total number of units provided by ap_clas Installability REU PO M3 stness Re usability bility e usability Reuse Documentation REU RD M1 Documentation Self contained Functional independence REU SF M1 functionality i Safety Evidence VERSION 1 0 DRAFT B 2004 12 01 29 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 Robu rta Re us EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES Goal property Property Mete Code Software Software development Process Maturity SDE DL M1 Development process level Software development activities adequacy SDE PE M1 Effectiveness Software verification activities adequacy System Interfaces Interface management Engineering management propagation rom system equine ments System engineering Ae Organisation and Management activities SEE SE M3 quality System software requirements traceability rate SEE SE M4 Table 25 The full SPEC model goal properties properties and metrics VERSION 1 0 DRAFT B 2004 12 01 30 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004
13. 0 B instantiated for PC 45 C E lf templates are used then auto_ptr pointers should be preferred to normal pointers All generic code shall work without modification when passed a valid subclass of a class it PC 45 C F is expecting as an argument PC 45 C G All functions should use references or pointers to base classes wherever possible The use of type conversion shall as widely as possible be avoided in order to maintain PC 46 C compiler specific type checking PC 46 C A Do not write code that force people to use explicit casts PC 49 C A parameter which is not changed by the function should be declared const PC 50 C The layout of a function shall be well defined and used throughout the project PC 51 C A In order to pass an object of type t as a function argument use type PC 52 C Records structs should be converted to explicit tagged types classes where possible PC 53 C The use of design patterns shall be done as much as possible Declarations should appear in predefined order e g constants and macros types structs DC GC and classes variables and functions Table 18 Recommended Static Rules 3 2 3 De scoped Rules Rule ID Rule title NC 10 C Class names shall begin with c or end with o or class NC 9 C User defined type names shall begin with t or end with _t or type PC 22 C F Calls to new should be assumed to succeed Table 19 De Scoped Static
14. Call ANALYZABILITY Table 7 Factors at method level in the Logiscope model Criterion Metric Weight VERSION 1 0 DRAFT B 2004 12 01 7 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES Function TESTABILITY ic param 1 0 ct path 1 0 LEVL 1 0 de calls 1 0 function STABILITY ic param 1 0 de calls 1 0 ct exit 1 0 ic_varpe 1 0 dc_calling 1 0 Function CHANGEABILITY ct_bran 1 0 VOCF 1 0 dc_lvars 1 0 ic_param 1 0 function ANALYZABILITY COMF 1 0 AVGS 1 0 Ic stat 1 0 ct vg 1 0 relativeCall ANALYZABILITY cg levels 1 0 cg strucpx 1 0 RelativeCall STABILITY cg hiercpx 1 0 IND CALLS 1 0 relativeCall TESTABILITY IND CALLS 1 0 cg testab 1 0 Table 8 Criteria at method level in the Logiscope model 2 3 2 The SPEC model for maintainability Using the mapping defined in A 2 it is possible to create a second model that will report any non compliance with a SPEC maintainability model The evaluation of the results of this model is based on a discrete failed passed output for each factor and criterium which can be traced to a specific metric Non compliances with SPEC shall be investigated and corrected or justified A known problem of SPEC is the use of switch constructs as they can easily break the maximum cyclomatic number If such an error is reported it can be ignored 2 3 2 1 Logis
15. EUROPEAN SPACE AGENCY OPS SOFTWARE QUALITY AND CODING RULES pp ae VE S o D ZEB Reference EGOS QA XX TN 9007 EGOS Date 2005 0425 EUROPEAN SPACE AGENCY OPS SrI MI TE ease Gl Document Title Software Quality and Coding Rules Document Reference EGOS QA XX TN 9007 Document Version 1 0 Draft B Date 2004 12 01 Approval Table Prepared by Eduardo Gomez 2004 10 29 Verified by YYYY MM DD Approved by Please update YYYY MM DD EgosAuthorisationList property Authors and Contributors Eduardo Gomez Eduardo Gomez esa int Author 2004 10 29 Nuno Sebasti o Nuno sebastiao esa int Contributor 2004 12 01 Distribution List COPYRIGHT EUROPEAN SPACE AGENCY 2005 The copyright of this document is vested in European Space Agency This document may only be reproduced in whole or in part stored in a retrieval system transmitted in any form or by any means electronic mechanical photocopying or otherwise with the prior permission of the owner Document Change Log YYYY MM DD Document Change Record 00 Originator Software Quality and Coding Rules EGOS QA XX TN 9007 VERSION 1 0 DRAFT B 2004 12 01 II COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES TABLE OF CONTENTS 1 DETAILED MAPPING TO SPEC INTRODUCTION 1 1 1 2 1 3 1 3 1 1 3 2 1 3 3 1 3 4 Reusability 1 3 5 Portability a quality character
16. IS MOD 26 TABLE 12 LIST OF METRICS THAT CANNOT BE FOUND IN SPEC cccccesssscssesecssesecscsscescssesecsssaeceeaesecssesecateaecsesaeenenaees 27 TABLE 13 THE FULL SPEC MODEL GOAL PROPERTIES PROPERTIES AND METRICS 30 TABLE OF FIGURES Error No table of figures entries found VERSION 1 0 DRAFT B 2004 12 01 III COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES 1 Introduction 1 1 Purpose The objective of this document is to provide the definition of a software quality and static model The quality model is expressed either by a set of values that can be measured on the source code and has to fall within a given range e g comment frequency or as a set of specific conditions that need to be verified at one or more points in the lifecycle e g the architectural documentation has to be based on the object oriented approach or all the requirements have to be covered by a validation mechanism The static model defined in this document presents a classification of the rules defined in and presents methods for checking the compliance of software code In general measurements on the source code are referred to as metrics while the verification of requirements that need to be met are referred to as checks 1 2 Scope This quality model is applicable to all development projects related to infrastructure software to be accepted by OPS GI The quality requir
17. Inspection Visual Observation PC 24 C D Manual Inspection Visual Observation PC 24 0 E _ Manual Inspection Visual Observation PC 24 C F Manual Inspection Visual Observation PC 24 C G Manual Inspection Visual Observation PC 24 C 1 Manual Inspection Visual Observation PC 24 C J Manual Inspection Visual Observation PC 3 C Manual Inspection Visual Observation Logiscope Audit PC 4 C Manual Inspection Visual Observation grep tool PC 5 C A Manual Inspection Visual Observation grep static PC 5 C B Manual Inspection Visual Observation Logiscope Audit PC 51 C Manual Inspection Visual Observation PM 1 C Manual Inspection Visual Observation PM 1 C B Manual Inspection Visual Observation VERSION 1 0 DRAFT B 2004 12 01 Table 21 Manual Static Checks 23 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES DETAILED MAPPING TO SPEC A 1 SPEC metrics mapped to checks documentation quality Checks documentation quality Checks quality Checks quality Checks Documentation Quality Requirements quality DOQ RQ M1 Documentation Checks Documentation Quality Requirements quality DOQ RQ M2 Documentation Checks Documentation Quality Requirements quality DOQ RQ M3 Checks Documentation Quality Requirements quality DOQ RQ M4 Documentation Quality Requirements quality DOQ RQ M5 Checks Functionality Completeness FUN
18. O M3 VERSION 1 0 DRAFT B 2004 12 01 28 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES Goal property Property Metric O Coe Modular cohesion MAIN MO M4 Portability Environmental software independence MAIN PO M1 Identify units with conditional compilation clauses that depend on the operating system ifdef SOLARIS and divide by total number of units total number of units provided by ap_clas System hardware independence Identify units MAIN PO M2 with conditional compilation clauses that depend on the hardware ifdef SOLARIS and divide by total number of units total number of units provided by ap_clas nstallability MAIN PO M3 Op GES Usabiiy erability On line Tutorial Readiness OPE US M2 Operator s Error Frequency OPE US M3 Operator s Judgement OPE US M4 Virtuality User operation virtuality OPE VI M1 Maury mene zz MTTRecover Mean Time To Recover REL RC M2 REL RO M Reliability Integrity Access controllabil ity REL IN M1 Data corruption indicator REL IN M2 Reliability Evidence Process Reliability activities adequacy REL RE M1 Failures tolerance REL RO M2 o P Environmental software independence REU PO M1 Identify units with conditional compilation clauses that depend on the operating system ifdef SOLARIS and divide by total number of units total number of units provided by ap_clas System hardware independence Identify units REU PO M2 with
19. PEC Min Max Weight logiscope function SPEC Analysablity LEVL MAIN AN M4 1 4 1 0 Ic stat MAIN AN M7 1 20 1 0 AVGS MAIN AN M6 1 7 1 0 ct vg MAIN AN M2 1 12 1 0 function SPEC Documentation COMF DOQ AD M1 E 1 1 0 function SPEC modularity Ic stat MAIN AN M7 1 20 1 0 function SPEC verifiability ct vg MAIN AN M2 1 12 1 0 Table 14 Criteria at method level in the SPEC model 2 4 Mapping to SPEC This section presents a simplified mapping to SPEC where only goal properties are taken into account A detailed mapping based on metrics can be found in section 3 Metrics are only relevant for the property maintainability The mapping between checks and goal properties is provided in Table 15 For C code the metric URI_Ratio Ratio of repeated inheritances in the application can be mapped to the existing coding standard rule PC 26 C D which completely forbids diamond shaped inheritances the value of this metric should therefore been set to zero for C Goal property as defined in RD 3 Checklist used 1 Value changed with regard to the original SPEC proposal The metric number of application classes ap class is also mapped to re usability however there are no values imposed for this metric and therefore it is not considered VERSION 1 0 DRAFT B 2004 12 01 9 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES Documentati
20. References 1 4 1 Applicable documents Ref AD 1 Document Title 1 42 Reference documents Ref Document Title RD 1 Space Engineering software Part 1 Principles and requirements RD 2 Space product assurance software product assurance RD 3 SPEC TN3 Space Domain Specific Software Product Quality Models Requirements and Related Evaluation Methods RD 4 Software engineering Product quality Parts 1 2 3 and 4 RD 5 Software Development Practices RD 6 C Naming and Coding Conventions RD 7 Generic Coding Conventions RD 8 Rulechecker C Reference Manual RD 9 Cand C Coding Standards 1 5 Document Overview SOFTWARE QUALITY AND CODING RULES Issue and Revision Date Issue and Revision Date ECSS E 40 part 1B 28 11 04 ECSS Q 80B 10 10 03 TBS 20 02 2002 ISO IEC 9126 15 06 01 1 2004 12 01 S2K MCS TN 9003 TOS GIG issue 1 1 04 11 2003 S2K MCS TN 9004 TOS GIG issue 1 1 22 10 2003 Logiscope 6 1 May 2004 BSSC 2000 1 issue 1 30 03 2000 Section 2 of the document defines the simplified quality model and how to apply it More specifically Paragraph 2 1 provides an introduction and some background details Paragraph Error Reference source not found explains how to apply the model from a practical point of view Paragraph 2 3 2 explains how the metrics and checks defined in this document map into quality properties as defined in RD 3 SPEC model Paragraph
21. application classes Re usability Portability REU PO M2 Number of ap clas application classes Table 23 Mapping between SPEC metrics and metrics measured in this model A 3 Additional metrics not in SPEC Metriename Logiscope reference Ratio of repeated inheritances in the application URI Ratio ercentage of non member functions MM Ratio verage coupling between objects AVG CBO Average of the VG of the application s functions AVG VG Ratio of recursive edges on the call graph Attribute hiding factor MOOD ap_ahf VERSION 1 0 DRAFT B 2004 12 01 26 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES P berge Polymorphism factor MOOD Coupling factor MOOD Weighted Methods per Class cl wmc Number of base classes in bases Number of dependent methods cl dep meth Number of children Coupling between classes Number of direct users classes CU cdusers Vocabulary frequency VOCF Number of levels LEVL Fan Out FAN OUT Number of distinct uses of external attributes ic_varpe Number of parameters passed by value ic_parval Number of parameters passed by reference ic_paradd Number of paths ct_path Number of direct calls dc_calls Relative call graph Hierarchical complexity Relative call graph Structural complexity Number of relative call graph call paths IND_CALLS Relative call graph System testability cg testab
22. are is running The user manual shall be self sufficient 2 5 4 PAchecks The check precedure shall ensure that All verification activities planned in the PA plan have been executed and documented in the progress reports Verification activities take into account the criticality of the software Verification activities ensure that the product meets the quality reliability maintainability and safety requirements stated in the requirements Walkthrough inspection are executed Internal audits are executed before the release of the software Progress reports include statistics on time spent on SPR corrections An estimate of the number of hours spent for every 1000 lines of code shall be provided mean time to diagnose MTTD the cause of the failure in hours Number of problems introduced as a consequence of SPR correction The report warns if any of the following values have been exceeded VERSION 1 0 DRAFT B 2004 12 01 13 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES 15 hours per 1000 lines of code 4 hours for MTTD more than 1 new problem for each solved SPR 2 5 5 Process checks The check procedure shall ensure that All the parties involved are ISO 9001 certified or present a S4S profile compliant with the following values for the related processes if the processes are relevant to their activities CUS 1 1 Acqu
23. ation Usability USABLE 10 Ojclass Yes Vocabulary frequency VOCF 4 1 funcion No Table 2 List of metrics based on C In summary applying this quality model consist of Measure the value of the metrics in Table 2 combine them using the provided models and identify these areas that should be improved It should be noted the failure of one single metric does not provide enough information to evaluate the code Metrics have to be combined using the models The measurement can be fully automated using Logiscope and batch processing see RD 5 Go through the checklists at the beginning and end of the lifecycle phases of the project ensuring that the relevant requirements are taken into account and verified 2 3 The quality models The experience in using the model has shown that the maintainability metrics cannot be used without further processing One single metric does not provide reliable information about a piece of code A VERSION 1 0 DRAFT B 2004 12 01 5 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES combination of them has to be used instead Unfortunately RD 3 does not define any criteria to classify the combination of the values of the metrics Therefore two approaches are proposed The first approach is based in using the model proposed by Logiscope with some minor corrections taken from SPEC The second approach is based on mapping SPEC metrics to Logiscope
24. ble 16 Static Rules Classification The prioritisation of the rules is done in Table 17 Core Static Rules Table 18 Recommended Static Rules and Table 19 De Scoped Static Rules For each rule a short description is also provided but the user is deferred to RD 6 for the rule complete text and examples 3 2 1 Core Rules Rule ID Rule title Appendix 1 Header and implementation file outlines GC 1 C Never break a rule without documenting it Provide meaningful saying comments in the source code and make sure that they are kept GC 10 C _ up to date Use appropriate tools to ensure that the code conforms to the rules and to catch potential GC 12 C problems as early as possible GC 13 C Write the comments in the common language of the project GC 14 C avoid fancy layout comments because they require time and effort to maintain GC 14 C A Comments must add to the code not detract from it GC 15 C Comments should never be used for commenting out code Maintain the source code and associated files under configuration control system and GC 2 C document cm information in the files GC 3 C Use a makefile or its equivalent for building the application GC 4 C Write the software to conform to the coding language international standards GC 5 C Do not rely on compiler specific features GC 7 C Use independent tools to provide additional warnings
25. cope metrics used in SPEC The Logiscope metrics used to build the SPEC model are reported in A 2 To simplify the reading of the tables the equivalent SPEC metric has been provided in an extra column 2 3 2 2 SPEC for applications Factor Criterion application SPEC application SPEC_modularity VERSION 1 0 DRAFT B 2004 12 01 8 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES Table 9 Factors at application level in the SPEC model Criterion Metric Metric SPEC Min Max Weight logiscope application SPEC modularity ap_cbo MAIN MO M3 1 0 Table 10 Criteria at application level in the SPEC model 2 3 2 3 SPEC for classes Factor Criterion class SPEC class SPEC Modularity class SPEC Documentation Table 11 Factors at class level in the SPEC model Criterion Metric Metric SPEC Min Max Weight Logiscope class SPEC Documentation COMFclass DOQ AD M1 3 1 1 0 class SPEC_Modularity cu_cdused MAIN MO M1 0 7 1 0 Table 12 Criteria at class level in the SPEC model 2 3 2 4 SPEC for methods and functions Factor Criterion SPEC function SPEG verifiability function SPEC modularity function _ SPEC Documentation function SPEC Analysablity Table 13 Factors at method level in the SPEC model Criterion Metric Metric S
26. cts The position of displayed elements and objects on the screen The size of displayed elements and objects The font size of alphanumeric characters The mapping of functions to key buttons etc The name of operator functions The arrangement of data in display panels The arrangement of data in printed plotted output The rate at which information is displayed The selection of I O devices Technical support information is identical to that stated in documentation Detailed Help information is available Help system is on line and easy to use Hypertext links jump to proper subject Glossary and search capabilities work correctly No specific Hw set up procedure shall be needed There shall be no need to re boot the hardware after an error It shall be possible to execute all functions without any Hw constraint Function execution shall not depend on the Hw Software outputs shall not be related to Hw configuration The software shall not require Hw related parameters Software shall not stop stop because of lack of resources e g memory disk space The software shall be easy to configure The man machine interface software shall be in line with standards the usage of software shall be described in a user manual Error messages sent by the software shall be documented in a user manual Error messages shall not be related to Hw It shall be possible to identify easily which version of softw
27. e a consistent prefix NC 2 C Names shall be meaningful and consistent NC 3 C Names containing abbreviations should be considered carefully to avoid ambiguity NC 4 C Avoid using similar names which may be easily confused or mistyped Names which have wide scope and long lifetimes should be longer than names with NC 6 C A narrow scope and short lifetimes Every c program using exceptions must use the function set unexpected to specify which user defined function must be called in case a function throws an exception not listed PC 11 C B in its exception specification PC 16 C The programmer must always use parentheses around bitwise operators PC 17 C B Other operators should be surrounded by white space PC 19 C The programmer should validate function parameters where possible Entities should be declared to have the shortest lifetime or most limited scope that is PC 2 C reasonable PC 21 C Diagnostic code should be added to all areas of code which should never be executed Error messages are not allowed to be hard coded but shall be handled through some sort PC 22 C lof central error message definition Any collection of data that does not warrant the work of writing a full class e g defining PC 26 C A accessor functions should be defined as a struct PC 26 C C Use of inheritance from non abstract classes shall be minimised Avoid the use of global objects with constructors the order in which global
28. eck procedure shall ensure that A safety analysis has been executed Criticality Classes are identified often by using traces from critical requirements to architecture The architectural design documentation shall clarify at least which components are mission critical A Software Safety Plan is defined if applicable specifying activities to be carried out the implementation schedule and the resulting products Hardware software interactions for safety are identified and evaluated if applicable ISVV activities plan are provided if applicable to identify taking into account the outcomes of the software safety analysis the ISVV activities to be performed The ISVV activities include reviews inspections testing and audits Software safety requirements are defined involving analysis of system safety requirements hardware software and user interfaces and areas of system performance 2 5 9 Static analysis The analysis shall ensure that There are no SPRs open in the system The ration SPR lines of code is less than 0 001 l e no more than 1 SPR every 1000 lines of code The code complies with mandatory coding standards This analysis can be supported by tools and SPR statistics SPR refers to SPRs detected after delivery VERSION 1 0 DRAFT B 2004 12 01 15 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES 2 5 10 Traceability checks
29. ember variables must not be declared public PC 27 C E Inline functions should be defined within the class definition PC 28 C __ It shall be ensured that an object of a class is created in a controlled manner PC 29 C __ It shall be ensured that an object of a class is deleted in a controlled manner PC 3 C Global entities must be declared in the interface file for the module Base classes capable of being derived should have virtual destructors but there is no PC 30 C A need to have virtual destructor when the class may not be derived from PC 31 C __ It shall be ensured that an object of a class is copied in a controlled manner PC 31 C B Any non member non global function shall be explicitly declared static In a function declaration the names of formal arguments shall be specified and should be meaningful if the function definition uses the parameters the names should match the PC 31 C C declaration PC 32 C Member functions shall have a standard layout Constructor functions which explicitly initialize any base class or member variable should PC 33 C not rely on a particular order of evaluation Objects should be constructed and initialized immediately if possible rather than be PC 34 C assigned after construction PC 35 C The class should always declare an assignment operator PC 36 C The assignment operator s must check for assigning an object to itself PC 37 C A_ assignment operator When poss
30. ements implicitly or explicitly contained in this document apply To the work performed by the contractor personnel Tothe acceptance process performed by OPS GI personnel 1 3 Glossary 1 3 1 Quality model software Set of characteristics and the relationships between them which provide the basis for specifying quality requirements and evaluating quality ISO IEC 9126 1 2001 from RD 2 1 3 2 Static model software Set of coding standards that in accordance to the quality model define the rules to which the software product source code shall comply with ISO IEC 9126 1 2001 from RD 2 1 3 3 Metric Defined measurement method and the measurement scale NOTE 1 Metrics can be internal or external and direct or indirect NOTE 2 Metrics include methods for categorising qualitative data ISO IEC 9126 1 2001 from RD 2 1 3 4 Reusability Degree to which a software module or other work product can be used in more than one computer program or software system IEEE 610 12 1990 from RD 2 1 3 5 Portability a quality characteristic capability of software to be transferred from one environment to another from RD 2 1 3 6 Check Verification of a quality requirement Note this definition is specific to this document 1 3 7 Acronyms Acronyms Description VERSION 1 0 DRAFT B 2004 12 01 1 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 1 3 8 Definition of Terms Terms Description 1 4
31. he values provided for the metrics will need to be tuned as experience is gained The metrics are based on C but the same values have been applied for JAVA This may need to be reviewed in the future based on the experience gained Some of the metrics are not relevant for Java The list of specific metrics to be applied for C and for Java is provided in Error Reference source not found The second kind of metrics consists of checklists The output of the metric is discrete in the sense that it can be 1 if the checklist is fulfilled or 0 if not Not all the items in the checklists maybe always applicable therefore some items in the checklist may simply be disregarded if proper justification is provided This set of checklists is strictly based on RD 3 and has been adapted to the type of developments typically carried out under OPS GIC control Safety related items in particular have been disregarded in most cases since infrastructure software developed under OPS GIC contracts has not yet been validated to be used on environments with safety implications For clarity reasons Metrics defined in RD 3 SPEC are referred to as SPEC metrics and the model defined in the same document as the SPEC quality model The complete quality model tree as defined in RD 3 with properties sub properties and SPEC metrics is presented in Annex A 22 The metrics This document attempts to simplify the application of the SPEC quality model by defining 10 c
32. hecklists instead of the 85 metrics defined in RD 3 which are listed in Table 1 Documentation Checks Effectiveness checks Operability checks PA checks Process checks Reliability checks Reusability checks Safety checks Static analysis Traceability checks Table 1 List of checks to be applied In addition to these checklists 56 metrics and their values have been defined The collection of these metrics can be easily automated A configuration file for the tool Logiscope from Telelogic can be provided The configuration file has adopted as metric value the one in RD 3 if the equivalent SPEC metric exists and the default Logicope value if an equivalent SPEC metric does not exist or if the default VERSION 1 0 DRAFT B 2004 12 01 3 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES Logiscope value is more restrictive or reasonable The full list of metrics is provided in Table 2 The last column in the table specified whether the metric is also applicable to Java code name Logiscope aggregated metric Applicable to Java applicability Attribute hiding factor MOOD lap ahf 0 7 application No Attribute inheritance factor ap aif 0 6 0 3 application No MOOD Coupling between objects ap cbo application No Number of Levels in the Call op cg ev 9 2 application Mo Graph Number of application classe
33. ible always use initialisation and initialisation list instead of assignment this means the copy constructor is called rather than the default constructor followed by an PC 4 C Declarations of extern variables and functions may only appear in interface files A full function prototype shall be declared in the interface file s for each globally available PC 47 C function PC 48 C Each function shall have an explanatory header comment Each function shall have an explicit return type a function which returns no value shall be PC 48 C A declared as returning void PC 5 C A Declarations of static or variables and functions may only appear in classes PC 5 C B All non global variables and constants shall be explicitly declared static PC 51 C JA function may not return a reference or pointer to one of its own local automatic variables Symbolic constants shall be used in the code magic numbers and strings are expressly PC 7 C forbidden Never use numbers in code nor any hardcoded string except when the use of these numbers is obvious for instance in mathematical expressions loop counter initialisation PC 7 C A end limit checking VERSION 1 0 DRA FT B 2004 12 01 19 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES All symbolic constants shall be declared using an enumeration technique or the const PC
34. isition preparation 3 CUS 1 2 Supplier selection 3 CUS 1 3 Supplier monitoring 3 CUS 1 4 Customer acceptance 4 Coding standards are enforced and verified Reliability maintainability and safety targets are defined e g in requirements and checked There are clear guidelines for configuration and change management and they are respected There is a software quality assurance plan that clearly establishes measurable quality objectives and the methods to measure them There is a Software Development Plan that defines the objectives standards and software life cycle s to be used in the software development process There is a Software Configuration Management Plan that establishes the methods to be used to achieve the objectives of the software configuration management process throughout the software life cycle There is a Software Verification Plan specifying the verification procedures to satisfy the software verification objectives note this may be presented as part of the software quality assurance plan The Outputs of Software Requirements and architecture engineering Process are verified regarding compliance of software requirements with system requirements accuracy and consistency of software requirements compatibility of software requirements with target computer verifiability of software requirements conformity of software requirements to standards traceability of software requirements to system requi
35. istic 1 3 6 Check 1 3 7 Acronyms 1 3 8 Definition of Terms vusssanssdraskvdndearnvk eda r E A E r stressede isje 1 4 REFERENCES senn cesses Saved e E E see Ee ovens Seefe e ecieg 1 4 1 Applicable documents 1 4 2 Reference documents eegene gege ee saadan GREG suber 1 5 DOCUMENT OVERVIEW instalere ed eebe e ate DEFINITION OF THE QUALITY MODEL esessssssvesesesssenenessssenenesensnenenenssseneneneneneseesenenensnenesssssnesenensnenenensssene 3 2 1 INTRODUCTION na nn 3 2 2 HOW TO MEASURE QUALITY n ssssnenesososeeeeoososerenososneseseseseseresreerenenesesese ERROR BOOKMARK NOT DEFINED 2 3 MAPPING TO SPECO ck iinet aden en asset 8 2 4 CHECKLISTS oe 2 4 1 Documentation Checks uinnsansalkskenn sidene eis Sa SEENEN eens See 10 2 4 2 e UE eden dene nedetid v 11 2 4 3 Operability checks 2 4 4 PA check 2 4 5 Process checks 2 4 6 Reliability checks 2 4 7 Reuisability checks riire oeer e Ea AEE E EEN 15 2 4 8 Safety checks ied 2 4 9 Static analysis tungene ea oO seat eie 15 24 10 Traceability Checks E 16 DEFINITION OF THE STATIC MODEVL sssssessssesevenesesssnesesenenenenessssenenenensnenenssssnenenenenesnsnesensnenenensssssenenenesene 17 3 1 INTRODUCTION sie ste se SE 32 RULE CLASSIFICATIONS sassanidene 3 2 1 Core 0 a A N 3 2 2 Recommended Rules fee 3 2 3 De scoped Rules kasse 3 3 COMPLIANCE METHODOLOGY Eeer dere erindre ease d e 21 3 3 1 Automated checks ccccccsecccssesscssesecseeeeseeees 3 3 2 Manual In
36. low between the components is defined The architectural design defines the major components of the software and the interfaces between them The architectural design defines or references all external interfaces The architectural design documentation covers all the software requirements CPU and memory shall be confirmed in accordance with the margins set by the system requirements A table cross referencing software requirements to parts of the architectural design is provided The architectural design is sufficiently detailed to allow the project leader to draw up a detailed implementation plan and to control the overall project during the remaining development phases The detailed design defines all components REQUIREMENTS There are no conflicting requirements There are no ambiguous requirements The set of requirements defines the system completely There are no replicated erquirements VERSION 1 0 DRAFT B 2004 12 01 10 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES USER DOCUMENTATION The User manual contains an overview of the system Each operation is described in the User manual Cautions and warnings are described in the User manual For each operation the User manual provides set up and initialisation input operations What results to expect The User manual provides probable errors and possible causes The User manual repor
37. metrics and defining a SPEC quality model based on them so that the code can be automatically reviewed 2 3 1 The logiscope quality model for maintainability The so called maintainability model is based on factors goal properties in RD 3 terminology and each factor is based on a number of criteria properties in RD 3 terminology Each criterion corresponds to a weighted combination of metrics The next sections will show the models used at the levels of application class and methods For each factor and criterium Logiscope provides a scale of results poor fair good and excellent Results labelled poor be it a function class or application level should be investigated and corrected or justified 2 3 1 1 Logiscope model for applications Factor Criterion application MAINTAINABILITY application TESTABILITY application STABILITY application CHANGEABILITY application ANALYZABILITY Table 3 Factors at aplication level in the Logiscope model Criterion Metric Weight application ANALYZABILITY RECU_Ratio 1 0 ap_cof ap_mif ap_aif AVG_CBO ap_inhg_levl application CHANGEABILITY ap_mif ap_pof NMM_Ratio URI Ratio ap inhg Jeu application STABILITY ap cof ap ahf ap mt ap inhg CDN AVG CBO application TESTABILITY ap cg levi ap ahf ap mit NMM Ratio AVG VG Table 4 Criteria at application level in the Logiscope model
38. n PC 24 C D The programmer may not assume that different data types have equivalent representations VERSION 1 0 DRA FT B 2004 12 01 18 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES in memory PC 24 C E The programmer may not assume knowledge of how different data types are aligned in memory PC 24 C 4 F The programmer may not assume that pointers to different data types are equivalent PC 24 C G The programmer may not mix pointer and integer arithmetic PC 24 C H It is not allow to use void pointers The programmer must use a wider type or unsigned values when testing for underflow or PC 24 C 1 overflow PC 24 C J the programmer must be careful when assigning long data values to short ones each case within a switch statement must contain a break statement or a fall through PC 25 C A comment PC 25 C B All switch statements shall have a default clause In class declarations shall the declaration of public protected and private data and PC 26 C _ functions be clearly separated and only one section for each type Classes for which it is not intended to instantiate any objects should be abstract i e they PC 26 C B should contain at least one pure virtual function PC 26 C D Diamond shaped inheritance hierarchies are not allowed PC 27 C Oase m
39. ngineering process evidence SEE SE M2 N A Effectiveness System Engineering System engineering process evidence SEE SE M3 N A Effectiveness System Engineering System engineering process evidence SEE SE M4 VERSION 1 0 DRAFT B 2004 12 01 25 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES Effectiveness Table 22 Mapping between SPEC metrics and checks in this model A 2 SPEC metrics mapped to metrics Documentation Development amp maintenance DOQ AD M1 Comments COMF Quality documentation quality frequency Maintainability Analysability MAIN AN M2 Cyclomatic number Ict vg VG Maintainability Analysability MAIN AN MA Number of nestings LEVL Maintainability Analysability MAIN AN M6 Average size of AVGS statements Maintainability Analysability MAIN AN M7 Number of Ic_stat statements Maintainability Modularity MAIN MO MiNumber of direct wu cdused used classes Maintainability Modularity MAIN MO M2 Number of CG stat statements Maintainability Modularity MAIN MO M3 Coupling between objects Maintainability Modularity MAIN MO M4 Lack of cohesion of cl_locm methods Maintainability Portability MAIN PO M1 Number of ap_clas application classes Maintainability Portability MAIN PO M2 Number of ap_clas application classes Maintainability Verifiability MAIN VE M2 Cyclomatic number ct_vg VG Re usability Portability REU PO M1 Number of ap clas
40. nstructions and functions are provided to restore the application after all but the most unlikely types of system and program crashes There is immediate feedback to show that the operator s action is understood by the system The system keeps the operator informed on the progress of operations that require more than 5 consecutive seconds of internal processing i e the operator is not left wondering if the system has died during lengthy silent functions Advanced functions are hidden or packaged so that beginners are not overwhelmed Operators are offered suitable default values and or assistance in setting parameter values VERSION 1 0 DRAFT B 2004 12 01 12 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES Fast Track is available to experienced operators command language operator definable macros operator definable function keys WYSIWYG by output editing formatting functions is used Elementary operator actions are processed quickly The operator can suspend a current function invoke other functions and then resume the suspended function The operator can choose his her own names for persistent information sets to which he she makes direct reference data files directories tables etc The operator can change at least 90 of the following aspects of the operator interface The colors of displayed elements and obje
41. objects are PC 28 C A initialised is not defined and can lead to chicken and egg problems PC 31 C A Stick to established conventions for overloaded operators PC 37 C The assignment operator s must also assign base class member data PC 38 C The assignment operator s should return a reference to the object Symmetric operators with the exception of assignment operator should be defined as friend functions All asymmetric operators i e unary and unary gt must be defined PC 39 C as member functions PC 40 C Member functions which do not alter the state of an object shall be declared const VERSION 1 0 DRA FT B 2004 12 01 20 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES Public member functions must not return non const references or pointers to member PC 41 C __ variables of an object Member functions shall only be declared as inline if the need for optimization has been PC 43 C identified PC 44 C A function shall not be declared as inline within the class definition itself PC 45 C Generic units should be encouraged as a convenient way of reusing code Templates should only be used if all instantiations of the template will use the same PC 45 C A algorithms There should be no functions in a template that do not depend on the type the template is PC 45
42. on Quality Documentation Checks Functionality Traceability checks PA checks Documentation checks Static analysis Maintainability Static analysis Documentation checks PA checks Operability Documentation checks Operability checks Reliability Reliability checks Re usability Reusability checks Suitability for safety Safety checks Software Development Effectiveness Process checks System Engineering Effectiveness Effectiveness checks Table 15 Association of checks and goal properties 25 Checklists 25 1 Documentation Checks The check procedure shall ensure that ARCHITECTURAL DESIGN DOCUMENTATION There are no ambiguities The object oriented approach is applied consistently A top down approach used to decompose the software into components Design trade offs are properly documented The architectural design contains a physical model which describesthe design of the software using implementation terminology For each component the following information is detailed data input functions to be performed data output Re used components are clearly identified COTS are clearly identified Data structures that interface components are defined Data structure definitions include the Description of each element e g name type dimension relationships between the elements i e the structure range of possible values of each element initial values of each element The control f
43. on files etc are present on the distribution medium and advices the operator if files are missing There a set of step by step instruction in a manual computer based installation guide or easily accessed file in the distribution medium that efficiently and unambiguously guides the installation If options relating to the customisation of the software are offered to the operator default options are proposed and explained in understandable terms Help is provided to operators on the choice of non default options Installation is allowed in operator specified directory or disk The operator can roll back to a previous step in the procedure without prejudice i e it is not necessary to re start whole procedure if for example the operator changes his mind about a choice of option If the installation upgrade process automatically modifies existing files such as those associated with the environment e g PATH the operator is informed The installation procedure be cancelled at any time If new directories are automatically created the operator is informed If new files are automatically added to existing directories the operator is informed Product parts are suitably identified inventoried and referenced without confusion in installation upgrade instructions The distribution medium is protected so that operators cannot inadvertently overwrite it The execution of the installation procedure is problem free Names of applica
44. rements accuracy of algorithms software architecture compatibility with requirements software architecture compatibility with target computer software architecture verifiability software architecture conformity to standards confirmation of software integrity The Outputs of Software design and implementation engineering Processes are verified regarding source code compliance with requirements source code compliance with software architecture source code verifiability source code conformity to standards source code traceability to requirements source code accuracy and consistency The outputs of the software integration completeness and correctness The inputs of the software validation process are verified regarding Completeness of the testing specification Completeness of the validation activities coverage of requirements The outputs of the software validation process are verified regarding Completeness in the execution of the testing activities Completeness in the execution of the validation activities VERSION 1 0 DRAFT B 2004 12 01 14 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES 2 5 6 Reliability checks The check procedure targets the operation of the system and shall ensure that Illegal operations are always trapped and handled by the software Data corruption never occurs Mean Time To Failure MTTF is grea
45. required These rules as defined in RD 6 are presented in Table 21 Manual Static Checks Rule ID Inspection methodology GC 1 C Manual Inspection Visual Observation GC 10 C Logiscope Auditing Manual Inspection Visual Observation GC 13 C Manual Inspection Visual Observation GC 14 C Manual Inspection Visual Observation GC 14 C A Manual Inspection Visual Observation GC 15 C Manual Inspection Visual Observation GL 11 C Logiscope Rulechecker Manual Inspection Visual Observation GL 12 C Manual Inspection Visual Observation GL 6 C Documentation Manual Inspection Visual Observation NC 5 C Manual Inspection Visual Observation NC 6 C B Manual Inspection Visual Observation NC 7 C A Manual Inspection Visual Observation NC 7 C B Manual Inspection Visual Observation NC 8 C Manual Inspection Visual Observation PC 18 C C Manual Inspection Visual Observation PC 20 C Manual Inspection Visual Observation PC 22 C A Manual Inspection Visual Observation PC 22 C B Manual Inspection Visual Observation PC 22 C C Manual Inspection Visual Observation PC 22 C D Manual Inspection Visual Observation PC 22 C E Manual Inspection Visual Observation PC 23 C Manual Inspection Visual Observation PC 24 C Manual Inspection Visual Observation PC 24 C C Manual
46. s ap clas application No Coupling factor MOOD ap_cof 0 18 0 03 application No Hierarchical Complexity of the ap inhg cpx 2 1 application Yes Inheritance Graph Number of Levels in the ap inhg lev 1 application Yes Inheritance Graph Method hiding factor MOOD ap mhf 0 4 0 1 application No Method inheritance factor ap_mif 0 8 0 6 application No MOOD Polymorphism factor MOOD ap_pof 1 0 3 application No Rate of class autonomy AUTONOM 100 30 class No Average coupling between AVG CBO 10 0 application No objects Average of the VG of the AVG_VG 5 Q application Yes application s functions Average size of statements AVGS 7 1 funcion No Relative call graph Hierarchical cg hiercpx 5 1 funcion No complexity Number of relative call graph co levels 12 1 funcion Mo levels Relative call graph Structural cg_strucpx 3 O funcion No complexity Relative call graph System cg testab 1 O funcion No testability Coupling between classes cl_cobc 12 Ojclass No Number of dependent methods cl dep meth 6 O class No Lack of cohesion of methods jd locm class No Weighted Methods per Class cl wmc 25 O class Yes Comments frequency COMF 0 99 0 3 funcion Yes Class Comments Frequency COMFclass 0 99 0 3 class Yes Number of destructuring ct bran 0 0 funcion Yes statements Number of out statements ct exit 1 0 funcion Yes Number of nestings ct nest funcion Yes Number of paths CL path 60 1 funcion Yes Cyclomatic number VG ct vg
47. spections ANNEX A QUALITY MODEL TREPE seeveoesvvevsevssvensenssvensenssvensensavensensavensenssvensensavensensensavensensavensensavensensavenseesne 27 TABLE OF TABLES TABLE 1 LIST OF CHECKS TO BE APPLIED sscsscssesscssessescssesscssesscossaccenscsecssesecaseaesecsacsccasesecaseaecaesaesecssesecasenecaseasenenaeeees TABLE 2 LIST OF METRICS BASED ON C TABLE 3 ASSOCIATION OF CHECKS AND GOAL PROPERTIES sssssssssseescsesscssesscseesecsessesecssesecaseaeeesacsecnsesecateascaeeaceneneses 10 TABLE 4 STATIC RULES CLASSIFICATION cssssscsssscescsseescssesscssesecsssaesccssesecasesecasseecenaesccasesecaseaeseesecaseaecsesaeeeesseeecaseneees 17 TABLE 5 CORE STATIC RULES TABLE 6 RECOMMENDED STIATICRuLES EEES EAE SE E AS FE Tarsia 21 TABLE EN DE SCOPED STATICRULES via 21 VERSION 1 0 DRAFT B 2004 12 01 HIN COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES TABLE 8 AUTOMATED STATIC CHECKS seseseseeeeeseresesosoeoeseseseseststereserenrnesososnesesesesesrsrosestorsesesesesrseeseoterornosososossese ses 23 TABLE 9 MANUAL STATIC CHECKS n eeesesesesesesescrereeeretoroeoososorororseseseserereestotoenenorororoeseseserererototeenenosorororovstrererevetororrer eror 23 TABLE 10 MAPPING BETWEEN SPEC METRICS AND CHECKS IN THIS MODEL n s snssseseooosesesososseesesesestststeresentnesesesse 26 TABLE 11 MAPPING BETWEEN SPEC METRICS AND METRICS MEASURED IN TH
48. tain a prefix which denotes which subsystem or NC 5 C library contains the definition of that entity NC 6 C B Variables with large scopes are not allowed to have generic names NC 7 C Each project shall define its own specific rules for naming conventions Any operation that matches one of the descriptions below should use the corresponding NC 7 C A term as the first part of its name Accessor functions for an attribute shall always be based on the attribute name without the NC 7 C B m prefix User defined type and class names consist of one or more words where each word is NC 8 C capitalised plus an appropriate prefix or suffix PC 10 C All local variables shall be initialised in their declaration PC 10 C A Avoid global data if at all possible static class data provides a much better alternative PC 10 C B No direct access to neither public nor private class variables are allowed Conditional expressions must always compare against an explicit value with boolean PC 13 C expressions as an exception PC 13 C A The programmer must not override the comma amp amp and operators The programmer shall make sure that the order of evaluation of the expression is defined PC 14 C Im typing in the appropriate syntax by using parenthesis The programmer must use parentheses to make intentions clear when it is needed for PC 15 C jimproving readability PC 18 C A Allocation using shall use new delete PC 18
49. ter than 1000 hours No critical failure occurs Mean Time To Restart is defined in the requirements and tested successfully Mean Time To Recover is defined in the requirements and never exceeded Design components and software modules are associated to specific reliability values and tested successfully MTTR and MTTF A dependability analysis has been executed during software specification and the software requirements have been enhanced in line with this analysis the analysis should provide at least the list of critical functionality Test execution is run in accordance to the module criticality classes Possible fault patterns have been identified during the dependability analysis and failure avoidance mechanisms have been implemented and successfully tested 2 5 7 Reusability checks The check procedure targets the documentation and shall ensure that A In case of software design for reuse There are requirements targeting the future reuse The organization and content of the user manuals is suitable for reuse of the software in line with requirements The definition of reusability limitation and criticality class reusability is stated Software units intended to maintain its correct behaviour in another environment are tested for that B In case of software reused from another mission source Justification of re use with respect to requirements baseline is provided 2 5 8 Safety checks The ch
50. tion specific menus functions commands keywords etc are self explanatory VERSION 1 0 DRAFT B 2004 12 01 11 30 COPYRIGHT EUROPEAN SPACE AGENCY 2004 EGOS QA XX TN 9007 SOFTWARE QUALITY AND CODING RULES Name of Application specific menus functions commands keywords are easy to remember Application specific Icons and other displayed objects have an obvious meaning Actions on application specific objects are generic At least 90 of each of the following conform to a common layout Data entry panels and forms Data display panelsFields Menus Command lines Prompts Error messages Help information There are consistent conventions for Operation of selection mechanisms Actions of non application dependent function keys buttons Operations on windows Display screens and panels are well laid out and uncluttered Character sets icons graphics etc have good legibility Window manipulation functions include a Close function Moving function Restore function Resize function Minimise function Maximise function Allows operator to save files in operator specified directory filename Prompts operator to save work whenever closing or quitting i e does not just exits Open files with the proper extension Files export to other applications Print to networked printer On completion of a function the operator is told or can easily find out
51. ts error messages and recovery procedure The user manual covers all software requirements The complete set of documentation is available on line and can be easily accessed by typing keywords or using a context based help environment OTHER DOCUMENTATION Traceability matrixes ensure that each input to a phase is traceable to an output of that phase Traceability matrixes ensure that each output to a phase is traceable to an input of that phase The validation tests are properly documented reporting test design cases procedures and reports The test documentation include traceability validation tests shall be traceable to the user requirement or upper level technical specification 2 5 2 effectiveness checks The check procedure shall ensure that The system components interfaces have been analyzed All Interface control Documents are available The correct implementation of the interfaces of the software component with other system components has been verified 2 5 3 Operability checks The check procedure targets the installation and checkout phases and shall ensure that A reliable estimate of how long the installation upgrade should take is described in the installation kit The installation documentation includes an accurate specification of all of required platform Operating system Other SW required other prerequisites The software automatically checks that all required installati
52. which functions he she can invoke next e g by means of a function menu bar On completion of a function the operator can directly move the program into a familiar home state e g into a root menu The design of menus commands selection mechanisms etc lets the operator move quickly to where he she wants to go minimum number of elementary operator actions required to move between the two most distant functions number of elementary operator actions required to select the deepest function from the opening program state Input data fields are validated to the maximum possible extent given the context Elementary input device mis operations are trapped and signaled appropriately Interface recover gracefully form anticipated operator errors e g invalid inputs Operator error messages show the location and type of errors and explain how to correct the error this information can be either on line or located in the operator documentation The system automatically proposes corrections to clearly correctable operator errors Operator error correction and roll back functions are adequate e g during an update original data should be recallable The system warns the operator before implementing operator actions that could have serious consequences Where important the system forces the operator to take data backups to regularly change passwords and to take other essential security measures I

Software Quality and Coding Rules

Contents

Download Pdf Manuals

Related Search

Related Contents