ANEXO 4: ANEXO TÉCNICO
8. PLANES DE PREVISIÓN Y PROCEDIMIENTO DE CONSTITUCIÓN DE LA RED
8.4.1 Initiating and Terminating Events
The IVA activity can be initiated as soon as sufficient documentation is available. This means that the independent validation activity can start at CDR or as soon as corresponding information is available and mature. If independent verification is being performed, the IVA activity is recommended to start during the independent code analysis.
The completion of the independent software validation activity does not have to be linked with the development process, but should take place while the software supplier is still available for maintenance of the software and preferably close to the AR.
8.4.2 Completion Criteria
The independent validation activity closes with the delivery and review of the test report.
It can be an advantage to deliver the applied software validation facility to the operation phase along with the test procedures, SVF User Guide and the independent validation test plan. This will enable execution of the independent validation test suite when updates to the software are to be investigated.
8.4.3 Relations to other Activities
The IVA activity is dependent of the result of the IVE activities. If important analyses do not exist and sufficient knowledge about the software under tests is not achieved, sufficient activities enforcing these must be executed prior to the formal IVA.
8.5 Task Descriptions
8.5.1 Identification of Test Cases
TASK DESCRIPTION
Title: Identification of test cases Task ID: IVA.T1
Activity: IVA - Independent Validation
Start event: DAR - Design Analysis Review (during the independent code analysis) End event: IVTPR – Independent Validation Test Plan Review
Responsible: ISVV Supplier
Objectives: The purpose of this task is to identify areas to be subjected for independent validation. The task relies on the development documentation for the system, including requirements and design specifications and output from the IVE analysis. The identified test cases must be described in the test plan to be used when implementing the tests.
Inputs: - From ISVV Customer:
- ISVV level definition at System level – MAN.VV.T1) - Requirement Baseline[RB; SRR]
- Software Requirements Specification [TS; DDR]
- Interface Control Documents[ICD; CDR]
- Software User Manual [DDF; CDR]
- Safety and Dependability Analysis Reports (SFMECA and SFTA reports) [PAF; CDR]
- Unit and Integration Test Cases & Test Reports [DJF, CDR]
- Software Architectural Design including software models if produced [DDF; PDR]
- Software Detailed Design including software models if produced [DDF; CDR]
- Software User Manual [DDF, CDR]
- From the ISVV Supplier (if available)
- Technical Specification Verification Result (including ISVV findings) [IVE.TA.T2]
- Architectural Design verification Result (including ISVV findings) [IVE.DA.T2]
- Detailed Design verification Result (including ISVV findings) [IVE.DA.T4]
- Code Verification Result (including ISVV findings) [IVE.CA.T2]
- Criticality System Functions List [MAN.VV.T1]
- Critical Software Requirements List [MAN.VV.T2]
- Critical Software Components List [MAN.VV.T3]
- Critical Software Units List [MAN.VV.T4]
- Test plan, test data, and test results from independent model validation (when applicable) Sub Tasks (per ISVV Level):
- ISVV Level 1 and 2:
- IVA.T1.S1: Evaluate Task Input (by Inspection)
Evaluate the results from the IVE analysis (if performed).
Evaluate the validation test performed by the software supplier.
Achieve basic knowledge about the software, either during the IVE activities or during this evaluating subtask.
Achieve detailed knowledge about the subjects from the critical function list.
- ISVV Level 1 only:
- IVA.T1.S2: Perform Analysis Use checklist in Annex G.7.
- ISVV Level 2 only:
- IVA.T1.S2: Perform Analysis
Analyze the interaction with external software with focus on degraded functionality of the external software products.
Investigate worst case load scenarios, covering robustness of the software with respect to deviations from timing requirements, e.g., events happening too early/late.
Investigate worst case scenarios, including robustness of the software with respect to injections outside or at the boundary.
Investigate potential runtime errors, overflow/underflow, and dataflow conflicts.
- ISVV Level 1 and 2:
- IVA.T1.S3: Writing Independent Validation Test Plan (by Inspection)
Describe each identified test case in terms of: Test Rationale, Test Overview, Test Environment, Input Data, Output Data, Starting Conditions and Detailed test Step descriptions including step description, expected results and pass/fail criteria. NOTE: In case models and autocode generation is used, a significant portion of test cases can probably be reused directly from the validation Test performed for the models, see
IVE.CA.T3.
Outputs: - Independent Validation Test Plan
8.5.2 Construction of Test Procedures
TASK DESCRIPTION
Title: Construction of Test Procedures Task ID: IVA.T2
Activity: IVA - Independent Validation Start event: At delivery of the SVF User Guide
End event: When all Test Cases are implemented and described in the Test Plan.
Responsible: ISVV Supplier
Objectives: - The purpose of this task is to express the test cases in the test language provided by the software validation facility
Inputs: - From the ISVV Customer - Object code [DDF; CDR]
- Source code (including autocode and external code) [DDF; CDR]
- From the SVF Supplier or ISVV Customer
- Software Validation Facility (SVF) User Guide - Software Validation Facility or operational test platform
- SVF Hardware (if any) - SVF Software - From the ISVV Supplier
- Independent Validation Test Plan [IVA.T1]
Sub Tasks (per ISVV Level):
- ISVV Level 1 and 2:
- IVA.T2.S1: Achieve knowledge about the SVF (by Inspection or dry runs) Achieve knowledge about the SVF.
Achieve knowledge about the test language to implement the test cases, the method to store test cases for subsequent execution, and the method for capturing and saving test results.
- IVA.T2.S2: Implement Test Cases into Test Procedures
Express the test cases in the test language provided by the software validation facility:
Relate test case parameters with software parameters Relate test case actions with software functions Setup conditions for test procedure failure/success Include test report generation commands
Describe test data TM/TC in the Test Plan if applicable - IVA.T2.S3: Updating the Independent Validation Test Plan
Update the independent Validation test plan with possibly additional test cases.
Outputs: - Independent Validation Test Procedures - Updated Independent Validation Test Plan
8.5.3 Execution of Test Procedures
TASK DESCRIPTION
Title: Execution of Test Procedures Task ID: IVA.T3
Activity: IVA - Independent Validation Start event: When IVA.T2 is performed.
End event: IVR – Independent Validation Review Responsible: ISVV Supplier
Objectives: - The purpose of this task is to execute the test procedures and generate a test report
Inputs: - From the ISVV Customer - Object code [DDF; CDR]
- Source code (including autocode and external code) [DDF; CDR]
- From the SVF Supplier or operational test platform supplier - Software Validation Facility (SVF) User Guide - Software Validation Facility or operational test platform
- SVF Hardware (if any) - SVF Software - From the ISVV Supplier
- Independent Validation Test Procedures [IVA.T2]
- Independent Validation Test Plan [IVA.T1]
Sub Tasks (per ISVV Level):
- ISVV Level 1 and 2:
- IVA.T3.S1: Execute the Test Procedures
Execute all implemented test procedures and generate report.
- IVA.T3.S2: Investigation of failed tests
Check that the failure is due to the software under test.
- IVA.T3.S3: Produce Test Report Describe all tests and observations.
Attach all test procedures (scripts) and test logs to the report.
Outputs: - Independent Validation Test Report (including the log and trace files of the test front-ends and the test nodes)