"Software Unit (62304)" vs "Software Unit (developer)"

[drm71]

in the standard, it defines "Items" and "Units" but I was recently reminded (and always forget) that what the standard means as "Unit" is not the same as what a developer might consider a Unit, i.e. a developer Unit really is the smallest chunk of code, whereas the standard "Unit" is typically bigger and would not correspond directly to the same level. Is there any supporting standard or guideline or reference that really gets into this? I find it a very odd choice of terminology to use "Item" if the intention was not to match what a developer might actually use. What is the motivation or background to this?

And can someone give some good practical examples on how these concepts "look" in an MDSW regulated environment, from both a design standpoint, from a linkage to risks, requirements, testing and traceability.

 

[Tidge]

Practically: Software units are the lowest level at which blame(*1) will be assigned when things go wrong and where fixes will be implemented to make corrections. Ideally, work done at the unit level will require only a limited and well-established amount of effort to verify what the unit was work was supposed to do, as well as what other functionality outside the unit the work may have impacted.

(*1) The flip side of assigning blame is recognizing where controls are implemented, which speaks to the question about the links to risks and requirements.

Software Unit is defined in 62304, so programmers/engineers/bloggers don't get to redefine it when trying to adhere to the standard. The development team does get to apply some critical thinking about what they consider a "software item" and a "software unit", but only in terms of decomposition... in other words, "unit testing" can't be avoided (if required) just by claiming "we don't have any software units, only software items".

 

[drm71]

Thanks this is nice and not far from what I was understanding

I guess I still get confused when I talk to developers and they often use the word unit to mean individual functions or at least really down to the smallest code chunks they work with, in practice this is too finely detailed for what you describe above that’s why I’m curious why they used the word unit instead of sub unit (or something else ) that’s bee explicitly “not what you might normally call a unit”

Or maybe I’m not making any sense ?

 

[Tidge]

62304 considered three levels, because it doesn't need any more to motivate development and testing based on risk. The three levels are: units (smallest working pieces with individual responsibilities), integrated units (discrete units that have to work together in specified ways), and the system (all units, fully integrated to meet system needs).

There can be a side conversation about best development practices (without considering medical device risk), but from a 62304 perspective if the developers are working on "sub-units" that don't have requirements, they are probably wasting time. If those sub-units have requirements, then they are just "units". I don't think it is much different than if a mechanical engineer wants to make a fuss about the difference between "assemblies" and "sub-assemblies".

 

[drm71]

Ha thanks for your patience I really just don’t know how to get my question out correctly

I understand what you say so maybe I’m just misunderstanding but outside med tech in general development “unit” means something else doesn’t it ? At least developers I talk to seem often confused by this

To put it another way let’s pretend the standard used the word “line of code” to actually mean multiple lines of code as part of a single source code file or function or class
It would be weird to try to tell developers that line of code means something else in the standard to how they use the term

I mean a sub assembly and an assembly are different and that’s why different names but unit and unit are the same words but not the same scale

I just find it a bit odd and so so several of my client developers

 

[Tidge]

I just find it a bit odd and so so several of my client developers

This is a common attitude among folks who see themselves as wizards... they scoff at a convention because they don't want to abide it.

Software engineering is NOT a field that has been around particularly long. If you want an example of an engineering field that has been around longer than software but only for a few hundred years to compare software development with, look at the field of threaded fasteners. I doubt the folks who individually cut threaded fasteners during the first 50 years such tools were available had immediate consensus on everything. Crack open something like a machinery handbook and take a leisurely stroll through just how much "standardization" exists in that field, and report back if you feel that the software development process for medical devices requires that much detail.

 

[drm71]

I guess I just wasn’t able to get across my question well but thanks for trying

I’ve experienced some of what you say but usually it’s possible to map most of what they do to be something compliant

But my question is nothing to do with this it’s purely the semantic point that developers use the word unit and have done so as long as I’ve worked so 25 years more or less.

I’m just trying to understand why use the word unit in the standard when the standards meaning of unit is generally NOT the same idea of a unit that a developer would immediately describe

It’s more of a curiosity but since they chose that word they must have considered this

Ironically my old boss who just retired is one of the main contributors to the standard so I was mostly asking here in case he thought I was asking a stupid question but now I’m suitably inspired to actually ask him

 

[Tidge]

I’m just trying to understand why use the word unit in the standard when the standards meaning of unit is generally NOT the same idea of a unit that a developer would immediately describe

I disagree, as does the standard, and does a lot of literature (see Roger Pressman for example).

I have observed enough variability in "software developers" that I wouldn't trust them with something like a standard. Get two of them in a room to review coding practices (or heaven help us) configuration management policies and we'd get more than two "standards".