Welcome back to Morris Medical Monday: a weekly series for medical device development companies (and companies who are related to such companies), providing some useful information about Polarion solutions and Polarion extensions.
Today we will continue on the subject of Polarion's MedPack extension, and have a look into MedPack's Software Unit type Work Item.
A description of a software unit according to clauses 3.28 and 3.25 of IEC 62304:2006. Any issue of this type must be linked to its parent software item(s). See the note in clause 3.25 for further information about software decomposition.
The Software Unit Work Item uses the standard Verification Workflow.
Traceability & Impact
A Software Unit Work Item must be traceable to a Software Item Work Item and a Detailed Design Work Item and can be traceable to a Architectural Design Work Item. It has an impact on a Hazardous Situation Work Item and can has an impact on a Integration Test Work Item.
For more information on traceability and impacts, see the Traceability wiki page.
Work Item Attributes
The following custom fields must be filled out before verification can be requested:
Verification strategy used
This list (multi-selection is possible) describes strategies, techniques and procedures as required by IEC 62304:2006->5.5.2. Several values are predefined, however, the enumeration can and should be adapted to the specific project. Preset values are described below.
Software Unit acceptance criteria (as required by IEC 62304:2006->5.5.3).
Additional acceptance criteria [C]
Additional Software Unit acceptance criteria. Only in software safety class C necessary.
When present in the design, the manufacturer shall include additional acceptance criteria as appropriate for:
- Proper event sequence
- Data and control flow
- Planned resource allocation
- Fault handling (error definition, isolation, and recovery)
- Initialisation of variables
- Memory management and memory overflows
- Boundary conditions.
(as required by IEC 62304:2006->5.5.4).
Preset values for the "Verification strategy used" enumeration
At least one walktrough is performed on this software unit. In a walkthrough, the developer explains his code to others and asks for comments.
Inverse Peer Review
An inverse peer review is performed on this software unit. In an inverse peer review, the reviewer tries to understand the code and explains the code to the developer.
A formal inspection is performed on this software unit. The procedure for a formal inspection must be documented and roles must be assigned.
This software unit is developed using pair programming.
A unit test exists for this software unit.
Code Metrics Check
An (automated) check for coding metrics is performed and evaluated. Metrics and threshold values must be documented.
Coding Guidelines Check
An (automated) check for compliance to coding guidelines is performed and evaluated. Coding guidelines must be documented.
The following custom fields must be filled out before verification can be finshed and the work item can be closed:
Person(s) to perform, performing or have performed a review.
Short summary of the review. Attachments should be used for additional information.
Last review date
Hidden field automatically set when review has been finished. Intended to be used for sorting and statistical analysis.
The following checklist must be filled out before verification can be finshed and the work item can be closed:
Acceptance criteria met
see Work Item Attributes (as required by IEC 62304:2006->5.5.3/5.5.4)
Documented process has been used
Documented development or maintenance process has been used for implementation. (as required by IEC 62304:2006->6.3.1).
The following table shows the possible resolution values when the work item is closed:
The software unit has been implemented.
The software unit has become obsolete and is no longer needed.
The work item entry has been discarded. No further attention is needed.