{"id":892,"date":"2014-12-22T12:00:28","date_gmt":"2014-12-22T20:00:28","guid":{"rendered":"https:\/\/blogs.plm.automation.siemens.com\/t5\/Polarion-Blog\/Morris-Medical-Monday-Work-Item-Type-34-Software-Unit-34\/ba-p\/380921"},"modified":"2026-03-26T05:32:18","modified_gmt":"2026-03-26T09:32:18","slug":"morris-medical-monday-work-item-type-software-unit","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/polarion\/morris-medical-monday-work-item-type-software-unit\/","title":{"rendered":"Morris Medical Monday: Work Item Type "Software Unit""},"content":{"rendered":"

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<\/A> and Polarion extensions<\/A>.<\/p>\n

Today we will continue on the subject of Polarion’s MedPack extension<\/A>, and have a look into MedPack’s Software Unit<\/EM> type Work Item.<\/p>\n


\n

Software Unit<\/H1>
\n

Description<\/H3>
\nA 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.
\n

Workflow Steps<\/SPAN><\/H3>
\nThe Software Unit Work Item uses the standard Verification Workflow<\/SPAN>.<\/p>\n

\"VerificationWorkflow_Overview\"<\/A>
\n

Traceability & Impact<\/SPAN><\/H3>
\nA Software Unit Work Item must be traceable to a Software Item<\/SPAN> Work Item and a Detailed Design<\/SPAN> Work Item and can be traceable to a Architectural Design<\/SPAN> Work Item. It has an impact on a Hazardous Situation<\/SPAN> Work Item and can has an impact on a Integration Test<\/SPAN> Work Item.
\nFor more information on traceability and impacts, see the Traceability wiki page<\/SPAN>.
\n

Attributes<\/SPAN><\/H3>
\n

Work Item Attributes<\/SPAN><\/H4>
\nThe following custom fields must be filled out before verification can be requested:
\n
\n
\n
\n
\n
\n
\n
\n
Attribute Name<\/TH>
\n		Type<\/TH>
\n		Description<\/TH>
\n<\/TR>
\n<\/THEAD>
\n
Verification strategy used<\/STRONG><\/TD>
\n		Enum<\/TD>
\n		This list (multi-selection is possible) describes strategies, techniques and procedures as required by IEC 62304:2006<\/SPAN>->5.5.2. Several values are predefined, however, the enumeration can and should be adapted to the specific project. Preset values are described below.<\/TD>
\n<\/TR>
\n
Acceptance criteria<\/STRONG><\/TD>
\n		Text<\/TD>
\n		Software Unit acceptance criteria (as required by IEC 62304:2006<\/SPAN>->5.5.3).<\/TD>
\n<\/TR>
\n
Additional acceptance criteria [C]<\/STRONG><\/TD>
\n		Text<\/TD>
\n		Additional Software Unit acceptance criteria. Only in software safety class C necessary.
\nWhen present in the design, the manufacturer shall include additional acceptance criteria as appropriate for:
\n– Proper event sequence
\n– Data and control flow
\n– Planned resource allocation
\n– Fault handling (error definition, isolation, and recovery)
\n– Initialisation of variables
\n– Self-diagnostics
\n– Memory management and memory overflows
\n– Boundary conditions.
\n(as required by IEC 62304:2006<\/SPAN>->5.5.4).<\/TD>
\n<\/TR>
\n<\/TBODY>
\n<\/TABLE>
\n
Preset values for the “Verification strategy used” enumeration<\/SPAN><\/H5>
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Name<\/TH>
\n		Description<\/TH>
\n<\/TR>
\n<\/THEAD>
\n
Walkthrough<\/TD>
\n		At least one walktrough is performed on this software unit. In a walkthrough, the developer explains his code to others and asks for comments.<\/TD>
\n<\/TR>
\n
Inverse Peer Review<\/TD>
\n		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.<\/TD>
\n<\/TR>
\n
Formal Inspection<\/TD>
\n		A formal inspection is performed on this software unit. The procedure for a formal inspection must be documented and roles must be assigned.<\/TD>
\n<\/TR>
\n
Pair Programming<\/TD>
\n		This software unit is developed using pair programming.<\/TD>
\n<\/TR>
\n
Unit Test<\/TD>
\n		A unit test exists for this software unit.<\/TD>
\n<\/TR>
\n
Code Metrics Check<\/TD>
\n		An (automated) check for coding metrics is performed and evaluated. Metrics and threshold values must be documented.<\/TD>
\n<\/TR>
\n
Coding Guidelines Check<\/TD>
\n		An (automated) check for compliance to coding guidelines is performed and evaluated. Coding guidelines must be documented.<\/TD>
\n<\/TR>
\n<\/TBODY>
\n<\/TABLE>
\n

Verification Attributes<\/SPAN><\/H4>
\nThe following custom fields must be filled out before verification can be finshed and the work item can be closed:
\n
\n
\n
\n
\n
\n
\n
\n
Attribute Name<\/TH>
\n		Type<\/TH>
\n		Description<\/TH>
\n<\/TR>
\n<\/THEAD>
\n
Reviewer<\/STRONG><\/TD>
\n		Text<\/TD>
\n		Person(s) to perform, performing or have performed a review.<\/TD>
\n<\/TR>
\n
Review summary<\/STRONG><\/TD>
\n		Text<\/TD>
\n		Short summary of the review. Attachments should be used for additional information.<\/TD>
\n<\/TR>
\n
Last review date<\/STRONG><\/TD>
\n		Date<\/TD>
\n		Hidden field automatically set when review has been finished. Intended to be used for sorting and statistical analysis.<\/TD>
\n<\/TR>
\n<\/TBODY>
\n<\/TABLE>
\n

Verification Checklist<\/SPAN><\/H4>
\nThe following checklist must be filled out before verification can be finshed and the work item can be closed:
\n
\n
\n
\n
\n
\n
\n
Checklist entry<\/TH>
\n		Description<\/TH>
\n<\/TR>
\n<\/THEAD>
\n
Acceptance criteria met<\/STRONG><\/TD>
\n		see Work Item Attributes (as required by IEC 62304:2006<\/SPAN>->5.5.3\/5.5.4)<\/TD>
\n<\/TR>
\n
Documented process has been used<\/STRONG><\/TD>
\n		Documented development or maintenance process has been used for implementation. (as required by IEC 62304:2006<\/SPAN>->6.3.1).<\/TD>
\n<\/TR>
\n<\/TBODY>
\n<\/TABLE>
\n

Possible Resolutions<\/SPAN><\/H4>
\nThe following table shows the possible resolution values when the work item is closed:
\n
\n
\n
\n
\n
\n
\n
\n
Resolution Name<\/TH>
\n		Description<\/TH>
\n<\/TR>
\n<\/THEAD>
\n
Implemented<\/STRONG><\/TD>
\n		The software unit has been implemented.<\/TD>
\n<\/TR>
\n
Obsolete<\/STRONG><\/TD>
\n		The software unit has become obsolete and is no longer needed.<\/TD>
\n<\/TR>
\n
Discarded<\/STRONG><\/TD>
\n		The work item entry has been discarded. No further attention is needed.<\/TD>
\n<\/TR>
\n<\/TBODY>
\n<\/TABLE>
\nFor more information about Polarion’s MedPack visit our Extension Portal using following link:<\/p>\n

http:\/\/extensions.polarion.com\/extensions\/31-polarion-alm-medpack-iec-62304<\/A>. I hope you liked this article and you will visit our Blog again when there is another Morris Medical Monday <\/B>article<\/p>\n


\n

FREE WHITEPAPER<\/P>
\n

\"Whitepaper:<\/A><\/P>
\n

Achieve Software Development Agility in Complex, Regulated Environments<\/A><\/P>
\n <\/p>\n","protected":false},"excerpt":{"rendered":"

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 Polario…<\/p>\n","protected":false},"author":63333,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spanish_translation":"","french_translation":"","german_translation":"","italian_translation":"","polish_translation":"","japanese_translation":"","chinese_translation":"","footnotes":""},"categories":[1],"tags":[],"industry":[],"product":[],"coauthors":[],"class_list":["post-892","post","type-post","status-publish","format-standard","hentry","category-news"],"_links":{"self":[{"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/posts\/892","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/users\/63333"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/comments?post=892"}],"version-history":[{"count":1,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/posts\/892\/revisions"}],"predecessor-version":[{"id":893,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/posts\/892\/revisions\/893"}],"wp:attachment":[{"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/media?parent=892"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/categories?post=892"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/tags?post=892"},{"taxonomy":"industry","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/industry?post=892"},{"taxonomy":"product","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/product?post=892"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/coauthors?post=892"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}