At some point in the lifecycle process, a change request arises. This requires rethinking previous activities. What's the best way to handle requests for changes to a software or system? The goal is to implement changes systematically.
IEC 61508 describes what to do in such a case:
7.1.2.9- If at any phase of the software safety lifecycle, a modification is required pertaining to an earlier lifecycle phase, then an impact analysis shall determine (1) which software modules are impacted, and (2) which earlier safety lifecycle activities shall be repeated.
7.5.2.6- During the integration testing of the safety-related programmable electronics (hardware and software), any change to the integrated system shall be subject to an impact analysis. The impact analysis shall determine all software modules impacted, and the necessary re-verification activities.
To help you design such an impact analysis, I'm sharing excerpts from our impact analysis form today. We use this form in our software development process.
First, we identify the software and describe the change. We assign each impact analysis a unique ID (e.g., #2019-004). This allows for better management of impact analyses.
| Software Name | |
| Software Version | |
| Software manufacturer | |
| Description | |
| Impact Analysis ID |
#2019-004 |
The first part of the document represents the impact analysis plan. Here, we evaluate the changes and plan the documents to be changed and other activities. We first list the changes. Each change is stored in our bug tracking tool and has an ID and a description. This information is included in the impact analysis. Then, we assess whether the change is safety-critical. Changes are safety-critical if they affect essential performance characteristics, fundamental requirements, or risk control measures. Accordingly, a higher level of effort must be planned for safety-critical changes.
|
|
| Dipl.-Ing. Goran Madzar, Partner, Senior Systems Engineer E-mail: madzar@medtech-ingenieur.de Phone: +49 9131 691 240 |
|
Do you need support with the development of your medical device? We're happy to help! MEDtech Ingenieur GmbH offers hardware development, software development, systems engineering, mechanical development, and consulting services from a single source. Contact us. |
|
To assess the impact, the components, requirements, and tests affected by the change are identified. Changes to software or systems can always lead to interactions within the system that require consideration. For example, changing the color in a graphical user interface can result in the night mode no longer being displayed correctly. Therefore, it is important to consider what negative effects the change could cause and which regression tests should be performed. Regression tests are used to find errors caused by unintended interactions. Our table has the following structure:
| the change | Safety critical | Affected | Necessary | |||
| ID | Description | (Yes No) | Components | Requirements | Tests | Regression tests |
Changes to software or the system inevitably lead to changes to the documentation. This, too, must be carefully documented. The following illustration is useful for this purpose:
| Document name | Current version | Change description | Target version |
This shows which documents, and in which version, were valid before the change. The change description defines what needs to be changed in the document and specifies a target version once the change is complete. Only the documents relevant to the change are relevant.
In addition to the documents, further activities may be necessary. For example, code reviews may be required. We cover these tasks in the "Further Activities" chapter.
| title | Description | Responsible |
The second part of the document is the Impact Analysis Report. The Report section is completed once the change has been implemented. This ensures that the identified tasks from the plan have been successfully implemented. During planning, this section remains blank. We achieve this in our form by using a checkbox that must be checked either for the plan or for the report. At the end of the impact analysis, there are two signed documents: one for the plan and one for the report.
The report must confirm that the tasks from the plan have been implemented. This is done using a list of checkboxes and a table for any deviations. Deviations must be justified in each case. The whole process is presented as follows:
All tasks from the impact analysis plan have been implemented.
[x] yes
[ ] no
[ ] with deviation
| deviation | Reason |
Finally, the question remains whether the change can be approved or not. This is also handled with checkboxes:
Change is approved.
[x] yes
[ ] no
The document ends with a document release.
| Name / Role | Company / Department | Place, date | Signature |
In my opinion, impact analysis is a very useful tool for dealing with changes in a structured manner and documenting them comprehensibly, even retrospectively. Changes often lead to interactions that aren't considered and are often poorly documented. Therefore, I recommend analyzing and documenting the impact systematically, as described in the blog post.
If you have any questions about impact analysis or development processes, please feel free to contact me.
Best regards
Goran Madzar