 |
 |
 |
|
 |
|||
| SQA12 - Static Assessment of Code |
LQS12 - Code statisch prüfen
1 Allocation to V-Model and Methods Allocation
V-Model
SD6.3 - Self-Assesment of the SW Module/Database
(SW Module)
(SW Component)
(SW Unit)
(SW Module, SW Component, SW Unit)
(SW Module, SW Component, SW Unit)
Method
2 Brief Characteristics
This service unit defines the requirements for tools used to analyze program source code with regard to form and structure without having to execute the program. In this connection, it must be possible
- to investigate if certain programming guidelines are being followed,
- that syntactic/semantic assessments are realized which may go beyond the analysis of the compiler,
- to make a statement about the quality of the software (software metrics).
3 Requirements
3.1 Requirements for Interfaces
| SQA12.I.1 | Granularity | The exchange of control parameters with SWFM01 - Workflow Management is possible for individual closed function packages of the tool by means of a disclosed, documented interface. |
3.2 Requirements for the Methods Support
| SQA12.M.1 | STAT - Static Analysis | |
| SQA12.M.1.1 | Assessment of conventions | |
| SQA12.M.1.1.1 | Project standards | It is possible to define the conventions to be assessed with regard to individual projects. |
| SQA12.M.1.1.2 | Naming conventions | It is possible to assess naming conventions. |
| SQA12.M.1.1.3 | Limitations | It is possible to assess size and complexity limitations. |
| SQA12.M.1.1.4 | Layout conventions | It is possible to assess layout conventions. |
| SQA12.M.1.1.5 | Means of representation | It is possible to assess commitments to certain representation types. |
| SQA12.M.1.2 | Lexical analysis | |
| SQA12.M.1.2.1 | Overview of functions |
It is possible to display an overview of the functions defined in an object to be assessed. The overview contains at least a brief description of the definition (name, return type, parameters and their corresponding types) as well as the hit description together with the corresponding file name. |
| SQA12.M.1.2.2 | Cross references | It is possible to generate a cross reference list informing about all uses and declarations of variables and functions. |
| SQA12.M.1.3 | General syntactic analysis | |
| SQA12.M.1.3.1 | Undefined | It is possible to list variables utilized but not declared. |
| SQA12.M.1.3.2 | Not initialized | It is possible to list variables utilized and declared but not initialized. |
| SQA12.M.1.3.3 | Unused | It is possible to list variables declared but not used. |
| SQA12.M.1.3.4 | Type errors |
It is possible to list variables not utilized in the way they were declared with regard to their type. This must generate a warning, but not necessarily an error. |
| SQA12.M.1.3.5 | Type conversion |
It is possible to list types depending on the language or even the operating system. The handling of pointers as integer, or the assignment Long to Short. |
| SQA12.M.1.3.6 | Dead code | When listing the object to be assessed it is possible to list unreachable statements as well. |
| SQA12.M.1.3.7 | Number of parameters |
It is possible to list function calls in which the number of transmitted parameters does not match the number of declarations. This must generate a warning, but not necessarily an error. |
| SQA12.M.1.3.8 | Parameter types |
It is possible to list function calls in which the parameter types do not match the declaration types. This must generate a warning, but not necessarily an error. |
| SQA12.M.1.3.9 | Function type | It is possible to list functions for which no resulting function type has been declared. |
| SQA12.M.1.3.10 | Return |
It is possible to list declared, not type-free function types from which either no value or a value of the wrong type has been returned. This must generate a warning but not necessarily an error. A type-free function type is type "void" in C. |
| SQA12.M.1.3.11 | Ignore |
It is possible to list functions for which declared return values were not evaluated by the calling language construct. This must generate a warning but not necessarily an error. |
| SQA12.M.1.3.12 | Unused |
It is possible to list functions not utilizing declared and transmitted parameters. This must generate a warning but not necessarily an error. |
| SQA12.M.1.3.13 | Operational sequence structure | |
| SQA12.M.1.3.13.1 | Infinite loops | It is possible to detect infinite loops. |
| SQA12.M.1.3.13.2 | Jumps |
It is possible to detect undesirable jumps. Such undesirable jumps are jumps into loops. |
| SQA12.M.1.4 | Structural analysis | |
| SQA12.M.1.4.1 | Function graph | It is possible to represent the calling hierarchy of the functions as a graph. |
| SQA12.M.1.4.2 | Calling hierarchy | It is possible to illustrate for each function which other functions it is calling. |
| SQA12.M.1.4.3 | Utilization | It is possible to illustrate for each function by which other functions it is called. |
| SQA12.M.1.5 | Expanded lexical and structural analysis | |
| SQA12.M.1.5.1 | Import overview | It is possible to generate an overview of all functions and variables imported into a module. |
| SQA12.M.1.5.2 | Export overview | It is possible to generate an overview of all functions and variables exported from a module. |
| SQA12.M.1.5.3 | Reference overview | It is possible to generate an overview of all external references for each module listing the calling position or the calling sequence. |
| SQA12.M.1.5.4 | Module depth | It is possible to calculate the maximum nesting depth for each Module. |
| SQA12.M.1.5.5 | Function depth | It is possible to calculate the maximum nesting depth for each function. |
| SQA12.M.1.6 | Software metrics | |
| SQA12.M.1.6.1 | Lines of code | It is possible to determine the number of lines of code (LOC). |
| SQA12.M.1.6.2 | Statements | It is possible to determine the number of statements. |
| SQA12.M.1.6.3 | Length of code | It is possible to determine (in LOC) the average length of a statement or a function. |
| SQA12.M.1.6.4 | Jumps | It is possible to determine the number of unconditioned jumps and abnormal terminations. Examples for such constructs: Gotos or Breaks, Exits. |
| SQA12.M.1.6.5 | Frequency of comments | It is possible to determine the frequency of program comments. |
| SQA12.M.1.6.6 | Comment share | It is possible to determine the share of comment lines as compared to the total number of LOCs. |
| SQA12.M.1.6.7 | Frequency of key words | It is possible to determine the frequency with which the different key words of the language occur. |
| SQA12.M.1.6.8 | Number of calls | It is possible to calculate the linear number of calls for functions. |
| SQA12.M.1.6.9 | Number of references | It is possible to determine the number of references for each variable. |
| SQA12.M.1.6.10 | Complexity |
It is possible to calculate a measuring value for the complexity of individual modules/functions. This measuring value should identify typical deviations from the average complexity (single-line functions, multiple recursive functions, extremely long functions). |
| SQA12.M.1.6.10.1 | It is possible to represent the metrics as tables or graphs. | |
| SQA12.M.1.6.10.2 | It is possible to define planned values and to illustrate deviations. | |
| SQA12.M.1.7 | Adaptation | Individually adapted forms of representation for the object to be assessed are taken into consideration during the assessment. |
3.3 Requirements for Functions
| SQA12.F.1 | Delimitation of to the assessment | It is possible to delimit size and extent of the assessment to selectable characteristics. |
| SQA12.F.2 | Procedural language |
By means of a procedural language it is possible to check other individual assessment criteria. A procedural language offers an automatic assessment of further individual assessment criteria. |
| SQA12.F.3 | Logging |
It is possible to get the results of the assessment logged. In this case, "logging" refers to a protocol of all data that might be utilized for later documentation of the assessment (e. g. test cases, expected results, actual results, messages) and not, however, to an editing of the documentation in the sense of actual assessment protocols. |
3.4 Other Requirements
| SQA12.O.1 | Procedural command language | The tool has a procedural command language that can be applied by the user to generate and run macros or procedures. |
| SQA12.O.2 | Complexity | There is no limitation of the complexity caused by the tool itself. |
| SQA12.O.3 | Background |
Assessments run in the background mode unless an assessment in the foreground mode has been explicitly requested. Since an assessment may take some time it is not necessary to wait for the end of the processing when in the background mode, i. e. other tasks can be realized in the meantime. |
| SQA12.O.4 | End signal |
The end of an assessment is signaled. This signal may be acoustic (e. g. by means of a beep) or optic (e. g. by means of a special window with a corresponding message). |
| SQA12.O.5 | Invariance | Applying the tool does not change the object to be assessed. |
|
|
|
GDPA Online
Last Updated 01.Jan.2002
Updated by Webmaster
Last Revised 01.Jan.2002
Revised by Webmaster
|