6.5 Tasks Description
6.5.2 Detailed Design Verification
TASK DESCRIPTION
Title: Detailed Design Verification Task ID: IVE.DA.T2
Activity: IVE.DA - Design Analysis Start event: DDR – Detailed Design Review End event: DAR – Design Analysis Review Responsible: ISVV Supplier
Objectives: Evaluate the software detailed design for internal consistency, correctness, completeness, accuracy, readability and consistency with software detailed design of other software items.
Inputs: - From ISVV Customer:
- Software Requirements Specification [TS; DDR]
- Interface Control Documents [ICD(TS); DDR]
- Software Architectural Design including software models if produced [DDF; DDR]
- Software Detailed Design including software models if produced [DDF; DDR]
- Software Dependability and Safety Analysis Reports [PAF; DDR]
- Traceability Between TS and SW Detailed Design including software models if produced [DJF; CDR]
- Traceability Between SW Architectural Design and SW Detailed Design including software models if produced [DJF; CDR]
- Traceability Between ICD and SW Detailed Design including software models if produced [DJF; CDR]
- From ISVV Supplier:
- Technical Specification Verification Report [IVE.TA.T1]
- Software Architectural Design Verification Report [IVE.DA.T2]
- ISVV level definition (from Technical Specification Analysis – MSN.VV.T2]) - ISVV level definition (from Architectural Design Analysis – [MAN.VV.T3])
- Contribution to Independent Validation (from Architectural Design Verification) [IVE.DA.T1]
Sub Tasks (per ISVV Level):
- ISVV Level 1 and Level 2:
- IVE.DA.T2.S1: Verify the detailed design external consistency with the Technical Specification (by Inspection - reviewing the traceability matrices produced by the software developer):
Ensure that all software requirements allocated to a software component (or component model if produced) are traceable to its software units (or model elements) and that the functionality described in the requirements is correctly implemented by the corresponding software component (or model element) (forward traceability) Ensure that all software component (or model elements) have allocated requirements and that each software
component (or model element) 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 component (or model elements) ensure that implementation of functionalities is complete and not repeated.
Ensure that the relationship between the software component (or model elements) and the software requirements are specified to a uniform manner (in terms of level of detail and format).
- IVE.DA.T2.S2: Verify the detailed design external consistency with the Interface Control Documents (by Inspection -reviewing the traceability matrices produced by the software developer):
Ensure that the interface detailed design (with other software components, hardware, the user, etc.) or model interfaces if models are produced by the SW suppliers, is consistent with the applicable Interface Control Documents (NOTE: Ensure that any traces between hardware interfaces and any software model are adequately justified since modelling languages are in general not able to work at the hardware interface level).
- IVE.DA.T2.S3: Verify the detailed design external consistency with the Architectural Design14 (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 threads / tasks and processes) described in the software detailed design implements adequately the software requirements. In case models are produced by the SW supplier, this also means to
a) Ensure that each software model correctly addresses all functionality assigned to it and that the static and dynamic structures of the model adequately implement the design. NOTE: The verification concerns the pure functionality as well as the compliance of the model with the tasking/process/thread model, the synchronous vs. asynchronous aspects, and the event driven vs. data driven control aspects; and
b) If there is a logical model developed by system engineers, ensure that there is a corresponding software engineering model developed by the software engineers. (NOTE: The logical and software engineering models should be functionally equivalent.).
c) Ensure that all model components identified in the architectural design are traceable to a software model and that the functionality described for the model component is implemented by the software model (forward
14 The verification of the Detailed Design traceability to Architectural Design is only considered under the condition that traceability matrices be available at the beginning of Detailed Design Traceability Verification.
traceability).
d) Ensure that all software models, traceable to a model component identified in the architectural design, do not implement more functionality than what is described for that model component (backward traceability).
e) For model components identified in the architectural design that are traced to more than one software model ensure that the implementation of the functionality described for the model component is complete and not repeated.
f) Ensure that all software components of foreign code designated in the architectural design to be imported in model components are traceable to placeholders in the software models and that the placeholders correctly implements the interfaces of the software units.
Ensure that the software components (and model elements) implement correctly the internal interfaces described in the software architectural design (and model components)
Ensure that the software design method used for the detailed design is consistent with the one used for software architectural design (when models are produced by the SW suppliers, it also means to ensure that the modelling method used for software models is consistent with the one used for model components in the architectural design).
For real-time systems ensure the consistency of the detailed design (and model elements) with the computational model defined in the software architectural design (e.g. the SW components implementing a given component are consistent with the computational model of that component).
- IVE.DA.T2.S4: Verify interfaces consistency between different SW components (by Inspection and or Modelling11) Ensure that software item internal interfaces (e.g. interfaces between software components) are consistent.
Consider both data and control flows. Include verification of data format, accuracy, and timing/performance.
Ensure that interfaces (and model interfaces if any) are designed in a uniform way.
Ensure that each interface (or model interfaces) provides all the required information from the underlying component (or component model respectively).
Ensure that all inputs of one software unit are produced by the SW suppliers by some other component and that all outputs of a component are consumed by some other component.
Ensure that all function inputs are set before used (no undefined variables).
Ensure that for each function called, the output of the function is consumed.
In case models are produced by the SW supplier, then also:
- Ensure that all static rules imposed by the modelling language are adhered to. Note that modelling environments usually provide automated checking for conformance to the static semantics of the modelling language, including data formats.
- Ensure that the specified input / output profile (signature) of an imported entity defined in a foreign language is consistent with the signature of the placeholder in the model. This check can be skipped if it has been performed in the scope of IVE.DA.T2.S1 and no new external entities have been imported since then
- IVE.DA.T2.S5: Verify detailed design correctness (by Inspection or Modelling15 or Simulation16)
Ensure that detailed design (and any model element) complexity and modularity is in accordance with quality requirements.
Ensure that the software detailed design implements (and model elements) proper sequence of events, inputs, outputs, interfaces logic flow, allocation of timing and sizing budgets, FDIR and error handling.
Ensure that the detailed design (and element models) is compatible with the target platform (i.e. ensure that platform dependent issues are compatible with the target hardware).
If element models are produced by the SW suppliers, also:
- Ensure that the underlying assumptions, basic mechanics, and inherent limitations for the selected type of model and its particular application are correctly identified, documented, and justified with reference to the requirements.
- Ensure that the retained data model is as required (we refer to the part of the state vector which is internal to the model).
- Ensure that the basic nodes (i.e. model atoms) have clear, unambiguous, and unique functionality.
- Ensure that the model behaves as expected. Even if the model is compliant with requirements it may still not behave as the customer or developers expected. This check may be based on model behavioural test via simulations. Note that the ISVV supplier can provide a complementary probing of the customer satisfaction with the functionality and behaviour of the model.
- Ensure that assertions expressed in the model are consistent with the requirements and are used correctly and as intended for the particular modelling language and tools.
15 UML: class, component, package, activity, interaction, sequence, state machine
16 Simulation can be used to verify sporadic algorithms (e.g. communication protocols)
17 This methods used here aims at verifying the independence of the FDIR mechanisms from the faults they are supposed to handle
- Ensure that there are no assertions on input and no assertions on output unless they come from system level or otherwise justified.
- Ensure that formal proofs provided by the developers are considered as complementary indications of absence of faults and they are not replacing simulations, i.e. they are never used as a justification to omit simulations, except where it is obvious that there is no risk of numerical “surprise” (e.g. pure Boolean logic) - IVE.DA.T2.S6: Verify detailed design completeness (by Inspection)
Ensure that the detailed design description includes decomposition of the software into software low level components, update of the software item internal interfaces design, and the physical model of the software items described during the software architectural design.
For real-time software ensure also that a computational model is provided as part of the software detailed design.
In case models are produced by the SW suppliers and even of there is no clear formalise requirements on what models shall contain, and that the modelling environment will normally provide mechanisms and tools for automatic check of formal completeness, leaving very little if anything to be verified manually, also - Ensure that all declared functions in the model are called (this is usually checked automatically).
- Ensure that all called functions in the model are declared (this is usually checked automatically).
- Ensure that no declared function in the model has an empty body unless it is a placeholder for an imported entity defined in a foreign language.
- Ensure that modelling environment version and configuration is documented. This is particularly important if new versions of the modelling environment are released frequently. There is a risk of incompatibility between previously developed libraries of reusable model elements and newly developed model elements. There is also a risk of confusion if the system engineers and the software engineers are not using the same versions of the modelling tools.
- IVE.DA.T2.S7: Verify the dependability & safety of the design (by Inspection or Modelling or Simulations or SFMECA17 or Formal Methods)
Ensure that the software detailed design (and the model) minimises the number of critical software components without introducing undesirable software complexity.
In case models are produced by the SW suppliers, ensure that the properties of the model, which are related to safety and dependability, are identified and either proven to hold or have withstood any attempts of falsification at the model level.
Ensure that software design (and model) is defined to control software’s contribution to system hazardous events by analysing software failure modes and their possible propagation to system level. (E.g. robustness related mechanisms are properly defined such as exception handling where relevant”).
Ensure that the software detail design (and model) implements proper features for Fault Detection Isolation And Recovery (FDIR) in accordance with the technical specification.
Ensure that the implemented FDIR mechanisms are independent of the faults that they are supposed to deal with.
Ensure that the software design (and the model) correctly handles hardware faults and that the implemented software logic is not harming the hardware in any way (NOTE: that in case models are produced by the SW suppliers, modelling languages are usually not very good at handling hardware (low level) interfaces. This has the consequence that the parts of the software to handle the low-level interface and the parts of the software logic to process the low-level data (i.e. the model) might have to be separated into different software and model elements. This increases the risk of faults).
Ensure that no run-time errors can happen and defensive programming techniques (and if models produced, also modelling techniques) are used, e.g. implementation of proper numerical protection at the model level: no divide by zero, no logarithms to zero, no tan (PI/2 + nPI), etc.
Ensure that the detailed design (and the model) includes proper verification of inputs and consistency checking.
Ensure that software detailed design (and the model) implements proper error handling mechanisms.
If models are produced by the SW suppliers, also:
- Ensure that relevant events are reported by the model using the appropriate channels.
- Ensure that the model does not include any hazardous modelling language constructs.
- Ensure that no dead or deactivated model elements exist. If deactivated model elements exist, ensure that their activation will not lead to hazardous conditions. Note that model coverage measurements can be used to prove that there are no dead model elements.
- For concurrent systems ensure that the model does not contribute to any dead-locks or race conditions.
- IVE.DA.T2.S8: Verify the readability of the detailed design (by Inspection)
Ensure that the detailed design documentation has a clear and consistent structure.
Ensure that the documentation (and the models) is intelligible for the target readers and that all the required elements for its understanding are provided (i.e. acronyms, terms, conventions used, etc.) including an overview of the system context in which the model elements (if produced) appear and the purpose of each model element .is described
In case models are produced by the SW suppliers, ensure that no model component is over-complex due to an
inadequate modelling language and should rather be replaced with a simple unit written in a foreign language, preferably from a library of reusable components.
- IVE.DA.T2.S9: Verify the timing and sizing budgets of the software (by Inspection or schedulability analysis (including WCET))
Ensure that software detailed design implements proper allocation of timing and sizing budgets (e.g. memory usage, CPU utilization, etc.) by reviewing the analysis performed by the software developer.
For real-time software verify developer’s schedulability analysis.
- IVE.DA.T2.S10: Verify the accuracy of the model (in case models are produced by the SW suppliers) (by Inspection) Ensure that information necessary to evaluate computational precision, units (kilograms, meters, seconds, etc.),
and error reporting is present at the model level.
Ensure that the model implements the required computational precision (e.g. rounding vs. truncation, single vs.
double precision, etc.). Note that the verification of required computational precision by analysis at the model level can only be indicative unless the code generator and the compiler have been qualified and can be trusted. It is therefore recommended to consider the verification at model level to be indicative and valuable to prevent gross errors at an early stage. The ISVV supplier can perform an independent and complementary verification of the computational precision of the model by simulation. Due to the difference between the simulation platform and the target platform, this verification by simulation can only be indicative and should be used to prevent gross errors in the model at an early stage.
Ensure that the numerical types (int, float, double, etc.) used in the model are portable to the target platform.
Ensure that the granularity of the reported error information is sufficient to trigger the necessary corrective actions.
Ensure that the parameter values and computations are conformant to the required units (kilograms, meters, seconds, etc.)
- IVE.DA.T2.S11: Identify test areas and test cases for independent Validation (from other IVE.DA.T2 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 Architectural Design Verification (IVE.DA.T1.S9).
- IVE.DA.T2.S12: Verify detailed design conformance with applicable standards (by Inspection)
Ensure that the detailed design (and models if produced) is compliant to applicable standards, references, regulations, policies, physical laws, and business rules (including naming standards, typing rules – e.g. strong typing).
When modelling is used by the SW suppliers, ensure conformance to modelling standards (see questionnaire in Annex G.8)
Outputs: - Software Detailed Design Verification Report - Contribution to Independent Validation (updated)