Software Unit definition -

[TomQA]

Hi,

I am working on the Software Architecture Document and I am having a bit of a struggle to identify Software Units. IEC 62304 defines the Software Unit as a Software item “not subdivided into other items”. According to the standard, it is up to the manufacturer to decide the granularity of items and therefore also the criterion for divisibility, making the definition somewhat arbitrary, and to be able to justify this strategy.
Our Software is composed of the following "layers" :
- Executable (.exe) -> 2 Items
- Assembly (.dll) -> 6 items
- Package / Namespace (logical group of classes) -> 40+ items
- Classes -> 200+

We would like to define the Software items present at the Assembly level (libraries .dll) as our Software Units, in accordance with IEC 62304.
However, do you think it is justifiable to use the the ".dll" software components as our Software Units ? Have you seen this done previously in the past ?
Or should we go lower in the granularity?
I hope I made myself clear as I am really struggling to define these Software Units, which is a very important task as the regulatory/documentary burden highly depends on this !

Thank you very much

 

[HB1966]

hi there Tom, your "regulatory" burden depends firstly on the safety class of the software system (C by default, B or A). Your system might be subdived to software items, which can be rationalized to another safety class.

Architecture = system or component
Software system = integrated collection of software items
Software item = any identifiable part of a computer program
Softwere unit = item that is not subdived into other items

The executable and dlls contain the executble code of your packages which include your classes. I would first assess at a conceptual level the individual packages and their functional domains and the relation to their classes.

Your name tells me you are QA responsible, don't you have a software architect that did the design? Or do you need to do a retrospective architecture / design?

 

[TomQA]

Hi HB !

hi there Tom, your "regulatory" burden depends firstly on the safety class of the software system (C by default, B or A). Your system might be subdived to software items, which can be rationalized to another safety class.

Our software is basically composed of 5 "assembly software items" of class A and one of Class B.
By the way, does that mean in the SDS we only need to give the detailed specifications of the the Class B software Item ?

Your name tells me you are QA responsible, don't you have a software architect that did the design? Or do you need to do a retrospective architecture / design?

Yes someone else did the design but it feels like we've gone too deep in the complexity of the SAD so we are trying to "simplify it" !

 

[Tidge]

I always tell software development teams trying to decide "what is a software unit?" that they should consider the finest grain of software element where they will eventually assign fault (and suggest fixes, etc.)

That is, if a software engineer is going to say "the defect originates in the DLL" and leaves it at that, the DLL is a software unit.