Practical definition of IEC62304 Software Items and Software Units

I

icare2much

#1
In IEC62304, it is left to the manufacturer to provide the definition and granularity of Software Items and Software Units.

Can anyone offer guidance or share industry experience in the practical definition of a software unit? I am guessing there are at least three important factors, maybe more. I am working with various engineering groups in our organization and we are attempting to define what a software unit is to us.

I imagine that one might be whether the software is releasable as one of many software components in a system - as a configuration entity that is independently releasable.

A second might be based on architecture; a truly logical separation of functions.

A third might be based on effort or management of the program; how the work is subdivided between resource pools (e.g. outside resources contracted to perform portions of the development). This could also be be based on internal effort - project management concerns may choose to further decompose "large" efforts into smaller manageable pieces.

Are there others? Is there any industry guidance for this activity?
 
Elsmar Forum Sponsor

yodon

Staff member
Super Moderator
#2
Re: Software Units

I've been in multiple industries and have yet to see a standard definition. The terms subsystem, component, and module are most often used differently. The best advice is to define them internally based on what your sw team is comfortable with and stick with it. Here's how we define things and this is what I have most often seen:

System - a collection of semi-independently releasable programs packaged together as a deliverable. Typically has a 'public' release identification.

Subsystem - semi-independently releasable programs (there may be some interface dependencies that may drive concurrent releases). This is where integration testing occurs. Typically only defined for larger systems.

Component - decomposition of a subsystem to logically partition along functionality / feature boundaries. This level is where I've seen the most differing uses / definitions. This is typically an architectural concern and may or may not have any bearing on physical structure. For example, a system may have a GUI which may be implemented across functional boundary lines. Alternatively, the system may have a database and all the access/update activities are isolated here.

Units - individual files. These are compiled together to create any upper-level aggregations. CM systems will manage revision numbers for individual files. Unit testing, code inspection, etc. is done here.

If your system is really big, it may make sense to inject additional, intermediate levels to allow for focused discussion.

I hope that helps. Again, your best bet is to have the sw guys define what they're used to. As long as you're consistent and you can tell, from anything released to a customer, the individual file revs comprising it, you should be ok.
 

sagai

Quite Involved in Discussions
#3
Re: Software Units

it's easily can drive anyone to craziness, for ClassII and III (B/C) the unit level documented verification is mandantory.
I have no idea how it can be achieved in the reality in case declaration of conformity with this standard.
 
I

icare2much

#4
:read:Im trying to read IEC62304 definitions very, very carefully! I read under the definition of a software item that "it is left to the manufacturer to provide the definition and granularity of Software Items and Software Units" and under software Unit that it is an "item that is not subdivided into other items".

I interpret this to mean that the manufacturer may choose whether an item may be subdivided further into units... then - if you carry it to an extreme - why not classify a system as being composed of a single software unit?

I was originally thinking a unit was at the file level since source control starts there and the note under the Definiton of software unit says that "software units can be used for the purpose of software configuration management..". But then I looked hard at it and it says "can" and not "shall". And considering the huge variance in size, content, and content complexity of files, it seems like there must be a better way.

Yodon, do you think it is realistic to treat files as units? We do some complex FPGA development here but many files are very small (and there are thousands!) and the overhead if they were considered units is daunting.

Sagai, your concern is why I'm asking!! How is everyone doing it? Whats the "typical" definition of a unit? Based on a file? Size? Functionality? THere must be a happy medium! I wish I could start a poll - but I'm not even sure what the categories should be.

Anyone else feel like giving us your :2cents:?
 

sagai

Quite Involved in Discussions
#5
Re: Software Units

I had the horrible recognition, estimating its consequences, that your unit definition is right. :frust:
:thanx:
 

yodon

Staff member
Super Moderator
#6
:Yodon, do you think it is realistic to treat files as units? We do some complex FPGA development here but many files are very small (and there are thousands!) and the overhead if they were considered units is daunting.
I think you've hit analysis paralysis. Take a deep breath and a step back. Look at the problem from the perspective of what the intent is: software management. When you develop a system, you do so from the file level up. Standard practice (and requirements) are to know what, exactly, comprises the thing you release. All configuration management systems work at the file level. So at the most granular level, yes, it's realistic (and done all the time) to treat files as units.

Let me ask, at this point, why this is a point of consternation for you? Yes, there may be thousands of files but you need to know the version of each one that goes into the final product. This is not done by hand but through the use of CM tools. So whether there's 10s or 1000s of files is inconsequential.

You can build up "aggregates" slicing and dicing the files into whatever makes sense - IF IT HELPS YOU MANAGE YOUR BUSINESS.

You ask why not consider the whole system a unit. To what means? If to minimize unit testing, then you're missing the point about that level of testing.

Maybe let us know a little more about your concerns of labeling something a unit and we can work through it.
 
I

icare2much

#7
Maybe let us know a little more about your concerns of labeling something a unit
Ugh. :eek: Sometimes simple questions make one look at the problem from a different point of view. I thought a little about why I was so concerned and I was on the track that each unit required a separate test procedure - and thinking that each test procedure is a document that must be reviewed and approved the thought of all the reviews was pushing me over the edge. So I asked myself - does each unit require a separate procedure?

So I re-read 62304.. "The MANUFACTURER shall establish strategies, methods and procedures for verifying each SOFTWARE UNIT." and it dawned on me that it doesn't specify that there is a one-to-one relationship - just that each software unit must be verified.

Well, that handles at least the verification aspect. I still need to think of how each "file" unit will be assigned a safety class and how we will depict that. And maybe there are other things that I need to think about too... maybe tomorrow.


 

sagai

Quite Involved in Discussions
#8
each unit required a separate test procedure
Let use the terminology Test Protocol instead of test procedure, it helps you later reading FDA Guidances and others in this subject :read:

So I asked myself - does each unit require a separate procedure?
doesn't specify that there is a one-to-one relationship - just that each software unit must be verified.
Not necessary, from the practical prospective yes (because likely different developer develops these code files and they are the ones creating that level of automatic test scripts ), but yes, you can collect into on higher level an aggregation, but aware, each code change likely requires the change in those scripts, so this aggregated test protocol may suffer constant change in this case. Not to mention this protocol is under 21CFR820.30(i) and as a consequence of it under 21CFR820.40 respectively.

how each "file" unit will be assigned a safety class and how we will depict that.
You use the process defined in 14971 as part of your Software Development Lifecycle. When there is a mitigation, you has to have a requirement which defines the way you mitigat your risk into the acceptable level. This requirement can be in you System Requirement Spec. level, or depends on complexity of the SW, it can be in a separate Safety Related Specification file.
Okay, no the tricky part, how you depict is.
Actually, you shall identify the mitigation related requirements in the code level, ensuring the traceability, so yes, you shall include as a remark/header/etc. in the CODE.

I know ... :mg:
ignorance is a bliss, but gradually you also will consider to visit frequently anonymous QA psychological recreation team in your neighborhood. :biglaugh:

Are you sure, your device is Class II?

br
Sz.



br.
 
Thread starter Similar threads Forum Replies Date
Bev D Essential References for Practical Quality Engineering Misc. Quality Assurance and Business Systems Related Topics 0
S Practical Implementation of ISO 14971 ISO 14971 - Medical Device Risk Management 6
A What are Practical data center best practices IEC 27001 - Information Security Management Systems (ISMS) 1
N Best practices for capturing audit objective evidence in a practical manner? Internal Auditing 3
B Practical ideas for information labelling in healthcare environment IEC 27001 - Information Security Management Systems (ISMS) 2
M Getting into biotech QA from aerospace - Is it practical? Career and Occupation Discussions 2
Q Practical guide to scan for Risks in all QMS systems without missing any ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 16
Sidney Vianna Blockchain Technology - Any examples of practical application? The Reading Room 21
Q Practical Way to raise NCR's in an Assembly Workshop ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 8
C Practical use of Heat Input calculation for Manual MIG Welding Manufacturing and Related Processes 4
M Practical Methods using Sampling by Variables Inspection, Prints (Drawings), Testing, Sampling and Related Topics 2
R Looking for Practical Advice in Managing Measurement Uncertainties Measurement Uncertainty (MU) 3
WEAVER Is GR&R really practical for a Measurescope? Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 12
A 6 Sigma: Could you share some practical examples of 6 Sigma Projects in your company? Six Sigma 3
A Exploding the Myths Surrounding ISO 9000: A Practical Implementation Guide Book, Video, Blog and Web Site Reviews and Recommendations 28
L oPRP or CCP? Practical example Food Safety - ISO 22000, HACCP (21 CFR 120) 2
L Working closer and better with Suppliers - Practical ideas to improve? Supplier Quality Assurance and other Supplier Issues 8
R Suggestions for a practical way to manage Contract Review Contract Review Process 5
O Practical 8-D or similar Problem Solving worksheet or form Excel .xls Spreadsheet Templates and Tools 5
M Need practical guide on TS 16949 Clause 7.6 Requirement IATF 16949 - Automotive Quality Systems Standard 1
M Practical Guidance on TS 16949 Clause 7.5.3 - Product Status Identification IATF 16949 - Automotive Quality Systems Standard 3
P Random Sampling at Receiving Inspection: A Practical Implementation needed Inspection, Prints (Drawings), Testing, Sampling and Related Topics 13
C Practical Examples of completed ISO 19011:2011 Audit Reports General Auditing Discussions 5
T Practical Problem Solving - Does anyone have a practical problem solving template? Document Control Systems, Procedures, Forms and Templates 6
S Practical Data Collection Process Recommendations? Design and Development of Products and Processes 6
S OPRP or HACCP Plan - Opinions and Practical Example Wanted Food Safety - ISO 22000, HACCP (21 CFR 120) 17
S Validation of Production Process - Practical Example ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
F Toyota A3 Practical Problem Solving (PPS) Document Needed Nonconformance and Corrective Action 1
L Corrective Action Request Assessment and Prioritisation Criteria - Practical Examples Nonconformance and Corrective Action 14
Q Father Of The Practical CMM, James Coggin (RIP) Coffee Break and Water Cooler Discussions 1
A Definition Modify, Magnify, Minify, and Substitute - Seeking practical ways of differentiation Definitions, Acronyms, Abbreviations and Interpretations Listed Alphabetically 17
L Please share some practical SPC exercises for training purpose Statistical Analysis Tools, Techniques and SPC 4
M Practical Reasons Behind The ISO 13485/QSR Regulations ISO 13485:2016 - Medical Device Quality Management Systems 6
L Employee motivation and empowerment - Please some practical methods IATF 16949 - Automotive Quality Systems Standard 20
G Practical Screw Thread Information & Tolerances General Measurement Device and Calibration Topics 98
R Practical Problem Solving for Management Development Quality Tools, Improvement and Analysis 3
D Internal Auditing ? A Practical Approach General Auditing Discussions 4
Anerol C Definition Rework vs. Repair - What's the practical difference? Definitions, Acronyms, Abbreviations and Interpretations Listed Alphabetically 43
ScottK How far is it practical to take a Process FMEA? FMEA and Control Plans 14
L Practical Ideas for TS 6.2.2.4 - Personel are aware of the relevance and importance.. Training - Internal, External, Online and Distance Learning 5
M Stakeholder Analysis - Practical success stories wanted ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5
J Q Leading and Lagging Indicators - Difference (practical) ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 8
Z Design and Development Planning - Is It Sufficient and Practical or Not Design and Development of Products and Processes 0
C Interpretation and Practical Application of ISO 17025 - Development of a System ISO 17025 related Discussions 81
G Practical examples of VOC and CTQ flowdown Six Sigma 8
D What practical measures can be taken to improve customer satisfaction? Customer and Company Specific Requirements 21
Govind Here is a Practical Test for QMS Effectiveness ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5
I ISO 13485 Practical Internal Audit Checklist - Standard vs. Process Based Internal Auditing 26
S I need help creating a practical preventive action process ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 18
J Auditing to ISO 9001:2000 - What is the Process Model in PRACTICAL terms General Auditing Discussions 17

Similar threads

Top Bottom