7.0 Code Analysis
7.1.2 Integration and Unit Test Specification and Data Verification
The integration/unit test plan includes the integration/unit test specification and test data. It is necessary to verify the consistency of the test procedures and test data against the design (architectural and detailed respectively), the technical specification and the ICDs. Furthermore it is necessary to verify their correctness, completeness and feasibility. These tasks are not intended to re-execute the unit nor integration tests.
Code Analysis
•Verify interfaces consistency between different SW units
•Verify source code correctness with respect to technical specification, architectural design and detailed design by verifying the traceability matrices respectively
•Verify the source code readability, maintainability and conformance with the applicable standards
•Verify the dependability & safety of the source code
•Verify the accuracy of the source code
•Verify that the source code is testable
•Verify the timing and sizing budgets of the software
Detailed Design
Document (CDR) Interfaces Control
Doc (CDR)
SW Units Source Code (CDR)
Technical
Specification (DDR) SW Architectural
Design (CDR)
Integration/Unit Test Procedures and Test Data Verification
Technical Specification (DDR)
Interfaces Control Doc (PDR)
Integration/Unit
Test Plan (DDR) Interfaces Control
Doc (DDR) SW Architectural/Detailed
Design (DDR)
•Verify integration test procedures correctness and completeness
•Verify integration test procedures feasibility
•Verify consistency with
Technical Specification •Verify consistency with Software Architectural Design
Figure 19 Integration/Unit Test Specification and Test Data Verification
7.2 Activity Inputs and Prerequisites
The input work products are listed in Figure 17 defining the Code Analysis task.
The prerequisite for starting the code analysis activity is the availability of the listed inputs.
Moreover the listed inputs shall present a satisfactory maturity level.
7.3 Activity Outputs
The output work products are listed in Figure 17 defining the Code Analysis task.
Verification reports include at least overall analysis of the work products analysed, findings, list of open issues to probe further on subsequent analysis, suggested modifications (if any), and inputs for independent validation test cases specification. Traceability matrices might be provided as annexes of verification reports or as separate documents.
7.4 Activity Management
7.4.1 Initiating and Terminating Events
The Code Analysis activities may be initiated as soon as mature Source Code is available. In general this coincides with the CDR.
Although several iterations of the Code Analysis activity may be performed, thus extending it potentially until the end of the development project, the Code Analysis activity ends with the Code Analysis Review (CAR) (as defined in above section 2.2), which in general takes place before the QR.
7.4.2 Completion Criteria
Code Analysis becomes complete after Source Code, Unit and Integration Test Specification and Test Data verified in accordance with tasks IVE.CA.T1, IVE.CA.T2 and IVE.CA.T3 (refer to section 7.5).
7.4.3 Relations to other Activities
This section identifies the relations between this activity and the remaining ISVV activities.
The tailoring of the Code Analysis activity is performed as part of the Criticality Analysis activity. Criticality Analysis may also provide useful inputs to the Code Analysis activity, namely the subtask “Verify the safety and dependability of the source code” (refer to section 7.5).
Strong relations exist between the Technical Specification Analysis, and the Software Design Analysis and the Code Analysis. The outputs of the Technical Specification Analysis and Design Analysis are applicable inputs to the Code Analysis. In addition Technical Specification Analysis and Design Analysis may raise issues to be closed during Code Analysis.
Code Analysis is also likely to provide inputs to independent validation test cases specification.
7.5 Tasks Description
7.5.1 Source Code VerificationTASK DESCRIPTION
Title: Source Code Verification Task ID: IVE.CA.T1
Activity: IVE.CA Code Analysis Start event: CDR – Critical Design Review End event: CAR – Code Analysis Review Responsible: ISVV Supplier
Objectives: Evaluate the software source code for internal consistency, correctness, completeness, accuracy, testability, and readability.
Inputs: - From ISVV Customer:
- Software Requirements Specification [TS; DDR]
- Interface Control Documents [DDF; CDR]
- Software Architectural Design including software models if produced [DDF; CDR]
- Software Detailed Design including software models if produced [DDF; CDR]
- Software dependability and safety analysis reports [DJF; CDR]
- Schedulability Analysis (including WCET) [DJF; CDR]
- Technical Budgets [DJF; CDR]
- From ISVV Supplier:
- Technical Specification Verification Report [IVE.TA.T1]
- Software Architectural Design Verification Report [IVE.DA.T1]
- Software Detailed Design Verification Report [IVE.DA.T2]
- ISVV level definition (from Design Analysis – MAN.VV.T3)
- Contribution to Independent Validation (from Design Analysis) – IVE.DA.T2 Implementation:
- ISVV Level 1 and 2:
- IVE.CA.T1.S1: Verify source code external consistency with Technical Specification (by Inspection - reviewing the traceability matrices produced by the software developer):
Ensure that all software item requirements are traceable to a software unit (source code) and that the functionality described in the requirement is implemented by the source code unit (forward traceability);
Ensure that all software units (source code) have allocated requirements and that each software unit (source code) is not implementing more functionalities than the ones described in the requirements allocated to it (backward traceability)
For each requirement traced to more than one software unit (source code) ensure that implementation of functionalities is not repeated.
Ensure that the relationship between the software units (source code elements) and the software requirements are specified in a uniform manner (in terms of level of detail and format).
- IVE.CA.T1.S2: Verify source code external consistency with Interface Control Documents (by Inspection - reviewing the traceability matrices produced by the software developer):
Ensure that the interfaces implementation (with other software units, hardware, the user, etc.) is consistent with the applicable Interface Control Documents.
- IVE.CA.T1.S3: Verify source code external consistency with Architectural Design and Detailed Design (by Inspection - reviewing the traceability matrices produced by the software developer):
Ensure that the static architecture (e.g. software decomposition into software elements such as packages, and classes or modules) and dynamic architecture (e.g. specification of the software active objects such as thread / tasks and processes) are implemented according the design.
Ensure that the software units (source code) implement correctly the internal interfaces described in the software
architectural design.
- IVE.CA.T1.S4: Verify interfaces consistency between different SW units (by Inspection and or Reverse Engineering20) Ensure that software component internal interfaces (e.g. interfaces between software units) are consistent.
Consider both data and control flows. Include verification of data format, accuracy, and timing/performance.
Ensure that all inputs of one software unit are produced by the SW suppliers by some other unit and that all outputs of a unit are consumed by some other unit.
Ensure that interfaces are designed in a uniform way.
Ensure that each interface provides all the required information from the underlying component.
If auto-code is generated from models then also:
- Ensure that interfaces between the software units generated automatically from the functional software models and the manually written code are consistent. Consider data-flow (input/output vectors). Consider control-flow (model initialisation and compute function integration patterns). Include verification of data format and accuracy (e.g. integer vs. float, 32 bit vs. 64 bit, signed vs. unsigned, scalar vs. composite, alignment, in other words, all components whether manual or auto should use a common “types.h”). Include verification of variable initialisation, input parameter initialisation, absence of unused variables, and absence of unused output parameters.
- Ensure that wrapper software (or other software) does not use or modify variables that are supposed to be internal to the auto-code.
- Ensure that the interfaces between automatically generated code and imported foreign code are consistent.
Consider data-flow (input/output vectors). Include verification of data format and accuracy (e.g. integer vs.
float, 32 bit vs. 64 bit, signed vs. unsigned, scalar vs. composite, alignment). Include verification of variable initialisation, input parameter initialisation, absence of unused variables, and absence of unused output parameters.
- IVE.CA.T1.S5: Verify source code correctness with respect to technical specification, architectural design and detailed design (by Inspection and or Reverse Engineering20,, Bug pattern identification)
Ensure that the static architecture (e.g. software decomposition into software elements such as packages, and classes or modules) and dynamic architecture (e.g. specification of the software active objects such as thread / tasks and processes) implements adequately the software design.
Ensure that source code complexity and modularity is in accordance with quality requirements.
Ensure that the software source code implements proper sequence of events, inputs, outputs and interfaces logic flow.
Ensure that correct use of programming language, libraries, system calls, etc. is being made.
- IVE.CA.T1.S6: Verify the source code readability, maintainability and conformance with the applicable standards (by Inspection, software static analysis, metrics, coding standard conformance checking).
Ensure that the source code is written in a clear way and that it is properly documented.
Ensure that all source code files adhere to the same coding style and that the applicable coding conventions, if any, are followed.
Ensure that applicable coding standards are followed (e.g. Ada RAVEN, MISRA C, etc.). Note: a different tool than the possible one used by the SW supplier should be used by the ISVV supplier to check for coding standards.
Note: Detailed RIDs shall be raised against coding issues where there is a problem.
Ensure that a description is provided for every single subprogram.
Ensure that the basic types used are defined in an implementation independent way. E.g. ‘int’ could mean 32 bit or 64 bit integers depending on the target compiler. Look for implementation independent definitions of types with specific characteristics (size, precision, etc.).
If auto-code is produced from models:
- Ensure that the applicable coding standards and quality metrics, if any, are followed and fulfilled by all imported code, also from libraries of reusable model elements/reusable code (which may have been verified according to a different standard for previous uses)
- Ensure that the applicable coding standards, if any, are followed by the automatically generated code (e.g. Ada RAVENSCAR, MISRA C).
- Ensure that foreign code that is integrated with the automatically generated code is constructed according to any hypothesis, assumptions, and principles applicable to the corresponding modelling languages. NOTE: this subtask concerns foreign code that is imported into the auto-code at source level, not at model level. Importing code at model level is in the scope of IVE.DA.T1.S3 and/or IVE.DA.T2.S4 and IVE. DA.T2.S6..
- IVE.CA.T1.S7: Verify the dependability & safety of the source code (by Inspection, Modelling, Simulations, SFEMCA, Software Metrics Analysis, Bug pattern identification)
Ensure that the software source code minimises the number of critical software units without introducing
undesirable software complexity (e.g. critical software unit are not sharing resources with non-critical software units thus increasing their criticality) and that the assigned criticality level is kept till the end of the
20The Reverse engineering will create Control Flow, Data Flow, etc. from the source code. The ISVV supplier should notice the often difficulty to compile the code at the ISVV site when requiring the use of some automatic verification tools
development.
Ensure that code is defined to control software’s contribution to system hazardous events by analysing software failure modes and their possible propagation to system level. (Eg robustness related mechanisms are properly defined and used such as exception handling , or sub-set of coding standards”)
Ensure any new critical parts of the software model introduced by the design is identified and controlled Ensure that the software source code implements proper features for Fault Detection Isolation And Recovery
(FDIR) in accordance with the technical specification or the detailed design information.
Ensure that the implemented FDIR mechanisms are independent of the faults that they are supposed to deal with.
Ensure that the software correctly handles hardware faults and that the implemented software logic is not harming the hardware in any way.
Ensure that defensive programming techniques are used
Ensure that the source code includes proper verification of inputs and consistency checking.
Ensure that all relevant events are reported by the software using the appropriated channels.
Ensure that adequate and proper implementation of numerical protection is in place at the source level: no divide by zero, no logarithms to zero, no tan (PI/2 + nPI), etc.
Ensure that restricted code constructs (e.g. known code generator or compiler limitations or defects) have been identified. If there are any, ensure that they are avoided in the source code (via configuration of code generator, and/or proven absence via static analyser tools, or otherwise).
Ensure that the source code does not include any hazardous programming language construct or library function (non-deterministic, dynamic, non-portable, implicit/explicit recursion, etc.) or inefficient programming language constructs or library function calls are generated in the source code.
Ensure that no dead or deactivated code exists. If deactivated code exists ensure that its activation will not lead to a hazardous condition.
For concurrent systems ensure that no dead-lock or race conditions exist.
- IVE.CA.T1.S8: Verify the accuracy of the source code (by Inspection or Numeric analysis)
Ensure that the source code implements the required computational precision (e.g. rounding vs. truncation, single vs. double precision, etc.).
Ensure that the granularity of the reported error information is sufficient to trigger the necessary corrective actions.
Ensure that the parameter values and the computation made are conformant with the required units (e.g. meters, inches, volts, etc.).
- IVE.CA.T1.S9: Identify test areas and test cases for independent Validation (from other IVE.CA.T1 tasks) Identify areas and items that can not be sufficiently analysed by means of Independent Verification only and
therefore that require execution of validation tests. Annotate this information (test areas/items, test case, etc.) as a contribution to the Independent Validation activities.
NOTE: This subtask shall receive, refine and update the contribution to Independent Validation from the Design Analysis (IVE.DA.T1.S9. IVE.DA.T2.S11).
- IVE.CA.T1.S10: Verify the timing and sizing budgets of the software (by Inspection or Schedulability analysis (including WCET))
Verify the developer’s schedulability analysis of the implemented application (should be based on computed WCETs).
Verify the sizing budgets of the software (e.g. executable image size, stack size, buffers, etc.) and verify them with respect to the design and requirements.
Outputs: - Software Source Code Verification Report - Contribution to Independent Validation (updated)