Anomalies Documentation

[QuinnM]

Hi,
We are developing Software and are having discussion on when to document anomalies. Is below correct?
During R&D testing of the software unit - anomalies do not need to be documented.
During R&D integration of the software unit - anomalies need to be documented.
During testing of the software system - anomalies need to be documented.

If anomalies need to be documented for the testing of the software unit, where is this required in 62304?

 

[shimonv]

I have not seen an industry practice for documenting anomalies at the unit level and I am not aware of such a requirement in the IEC 62304. Unit development, testing, and code review are low-level R&D activities. Adding and managing anomalies at this level is stifling in my opinion.

 

[QuinnM]

I have not seen an industry practice for documenting anomalies at the unit level and I am not aware of such a requirement in the IEC 62304. Unit development, testing, and code review are low-level R&D activities. Adding and managing anomalies at this level is stifling in my opinion.

Thanks Shimonv

 

[Tidge]

I have found that in practice, for developing medical device software, there are two distinct phases of anomaly tracking:

1) During development (anomalies are part of the project)

2) Upon release and while on-market (anomalies are part of the product)

It is mandatory, per regulators, to have anomaly tracking during (2). Anomaly tracking also plays into the Software Maintenance and Software Problem Resolution processes of 62304.

The anomaly tracking that occurs during development is more of a sliding scale. Many developers implement formal anomaly tracking during system testing because attempts to resolve anomalies can obviously, directly, have an impact on previously executed testing... and a rigorous anomaly-handling process can direct work and provide the safeguards necessary to avoid repeating work. Implementing a slightly(*1) more rigorous anomaly-handling process earlier in development can reap the same benefits, it is up to the software developer manager (and her development plan) to decide how much undirected and wasted effort she will tolerate prior to system testing.

Typically, unresolved anomalies from (1) become the baseline for the anomalies list in (2)... which is a contributing factor why many managers don't like to start tracking anomalies too early... but this is is sort of like "see no evil, speak no evil, hear no evil".

(*1) During development, prior to system testing, there is IMO no need to bring "medical device risk management" into anomaly handling... anomalies (at unit level, for example) could just be (1) document issue (2) identify area of software to be modified (3) description of change made (4) verification that issue is resolved. In order to satisfy the release/on-market anomalies for medical device software, there will have to be a formally documented risk assessment.

 

[Bev D]

Tidge has correctly identified what should be done. The more documentation - and review and learning - of software anomalies, the fewer future anomalies. The more we know, the less we get wrong…But my real reason for responding here is to warn, whine or rant about the use of the term ‘anomaly’ instead of defect or even bug. The definition of word anomaly actually opens the door to ambiguous occurrences or events that are maybe not so bad or that are ‘one offs that won’t happen again or that aren’t very serious…The more we use new, different or unique words for established things the more we open the door to thinking we are different or special or better. We isolate ourselves from others and fail to learn from other disciplines, because “we are different” (If I only had a dollar for every time I heard that!). And the more likely we are to believe our own arrogant mindset that we can do no wrong. I have struggled with breaking this Hubris with every software group I’ve dealt with in the last 40 years. One only has to look at the software debacle that was the MCAS software for the Boeing 737 Max.

 

[Miner]

But my real reason for responding here is to warn, whine or rant about the use of the term ‘anomaly’ instead of defect or even bug. The definition of word anomaly actually opens the door to ambiguous occurrences or events …

The word anomaly was introduced by lawyers for the very reason that it was vague. They felt that words like defect, defective or bug were an admission of guilt and actively strove to suppress their use.

 

[Bev D]

Yes. I remember that training from my automotive days. It’s a shame that so many lack critical thinking skills. And we must slur our language so as to allow for any interpretation that anyone wants to make. It has made for a great political cudgel driving us to the next dark age of ignorance. Just my opinion of course