Products
Morris Medical Monday: Work Item Type "Software Unit"
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.
Software Unit
Description
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.
Workflow Steps
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.
Attributes
Work Item Attributes
The following custom fields must be filled out before verification can be requested:
Attribute Name | Type | Description |
---|---|---|
Verification strategy used | Enum | 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. |
Acceptance criteria | Text | Software Unit acceptance criteria (as required by IEC 62304:2006->5.5.3). |
Additional acceptance criteria [C] | Text | 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 – Self-diagnostics – Memory management and memory overflows – Boundary conditions. (as required by IEC 62304:2006->5.5.4). |
Preset values for the “Verification strategy used” enumeration
Name | Description |
---|---|
Walkthrough | 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. |
Formal Inspection | A formal inspection is performed on this software unit. The procedure for a formal inspection must be documented and roles must be assigned. |
Pair Programming | This software unit is developed using pair programming. |
Unit Test | 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. |
Verification Attributes
The following custom fields must be filled out before verification can be finshed and the work item can be closed:
Attribute Name | Type | Description |
---|---|---|
Reviewer | Text | Person(s) to perform, performing or have performed a review. |
Review summary | Text | Short summary of the review. Attachments should be used for additional information. |
Last review date | Date | Hidden field automatically set when review has been finished. Intended to be used for sorting and statistical analysis. |
Verification Checklist
The following checklist must be filled out before verification can be finshed and the work item can be closed:
Checklist entry | Description |
---|---|
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). |
Possible Resolutions
The following table shows the possible resolution values when the work item is closed:
Resolution Name | Description |
---|---|
Implemented | The software unit has been implemented. |
Obsolete | The software unit has become obsolete and is no longer needed. |
Discarded | The work item entry has been discarded. No further attention is needed. |
For more information about Polarion’s MedPack visit our Extension Portal using following link:
http://extensions.polarion.com/extensions/31-polarion-alm-medpack-iec-62304. I hope you liked this article and you will visit our Blog again when there is another Morris Medical Monday article
FREE WHITEPAPER
Achieve Software Development Agility in Complex, Regulated Environments