What if ... Source code part of the SDS (Software Design Specification)

sagai

Quite Involved in Discussions
#1
Hi Covers,

do you think the source code can be defined as part of the Software Design Specification for a MD contains SW?

Thank you in advance, Regards
Sz.
 
Elsmar Forum Sponsor

yodon

Staff member
Super Moderator
#2
Would you submit a finished device as the product specification? Sure would make verification easy! ;-)

Seriously, no, I can't see that as defensible - or logical. The design documentation should be the bridge between the specification and implementation. Design documentation (state diagrams, algorithms, architectural breakdown, etc.) should give the reader the rationale for why the code was implemented as it was and support those trying to maintain the code.
 

sagai

Quite Involved in Discussions
#3
I hoped you reply :)

SDS is SDS as the terminology at FDA, I guess architecture is out of the SDS scope, I mean System architecture.

All the developers (at least the ones I know) creating the SDS after having the source code, so why would we torture them with something which is not natural to their normal behaviour?
At the beginning they have a very draft SDS and at the end of the coding effort together with the code, the SDS granulated into the same level.
So if it is the natural way, than why we have to follow a direction which is artificial and does not mirror the reality?

Moreover the code is code, it is a specification, regardless it is a different one for compiler, or for the processor. The running bits in the processor is the medical device, I tend to believe that, not the code.

br
Sz.
 

yodon

Staff member
Super Moderator
#4
You raise some interesting points.

The design documents should be useful to the developers. If not, then there's something wrong. Either the information being captured is not useful or the development process itself is broken. I would agree that creating design documents after the code is implemented is probably of little value. The best way I've found to figure out what's needed in a software design document is to have developers maintain someone else's code. Anytime they say "why did they do that" or "why did they do it that way" is a clear indication of where design documentation is needed.

Saying, though, that code is a specification is a very slippery slope. Say you have a requirement to process something in 1 second; however, the code implements it in 2 seconds. If you say the code is the specification then how do you resolve the conflict?
 

sagai

Quite Involved in Discussions
#5
I would clarify first, of course the reason of this insane idea is not to avoid verification.

The practise (correct anyone me, I would be glad to have different feedback) I have seen is developers coding based on the System level requirements and the design specification finalised actually after the completion of the coding effort. (it is basically against the regulation -IEC62304 and FDA design control guidance- as far as I concern)

I am playing with an idea to define the code as part of the SDS, allow in that way to reflect the practice in the defined SDLC, and as an extension of this approach create a Coding Guideline that allow the developer to systematically document the formal SDS content in the code, it would let to extract the SDS from the code at the end of the coding effort, including architecture of the classes.

I would not avoid the planning of the architecture, that would be a separate higher level document, as actually required.

What would be the weak point of this approach from the regulatory prospective?

thnx, br
Sz.

ps.:
I still consider code as a specification, however your point stopped me a bit, it is not important for this subject, I excluded :)
 

yodon

Staff member
Super Moderator
#6
Is the "reverse-engineered" design info actually ever used? If not, why do it?

If someone were to dig deep, I don't think they would agree that the approach you describe is in line with state of the art SDLC practices. To me, it's a pretty clear progression: requirements --> design --> code (in however many iterations). No problem supplementing design info with reverse-engineered data (info gleaned from code) but to replace the design step entirely with reverse-engineered data may be difficult to defend.

Here's an example. System requirements specify the software is to perform a certain calculation. In design, you would define the algorithm and appropriate stakeholders approve. When coding, you implement the algorithm. If you skip the design step, you are effectively saying that whatever the developer creates is what it's going to be. Yes, you can reverse engineer the design but it was never approved. If you then realize it's a bad algorithm, you have to re-write the code.
 

sagai

Quite Involved in Discussions
#7
I would like to reopen this topic.

What criticism should be expected if I would declare the source code as a Software Design Specification?
... other topic but what if the unit test code is considered as a specification for the source code?

Many thanks!
 

yodon

Staff member
Super Moderator
#8
Sorry for the delay, been extremely busy.

Maybe look at it this way: would you tell a builder to construct a house for you and then expect it to be built to the size, number of rooms, layout, etc. that you expect? The code is a design output, for sure, but it's not the design in terms of the interim step taking specification to implementation.

If you're looking to reverse-engineer the source to create design documents, then there are tools for that (e.g., doxygen <-- not a product endorsement, no relation with the product / company, etc.).

Criticism could range from not following state-of-the-art practices to being non-compliant (skipping a required design activity).

Can't either see where you're going with unit test code as specifications. If you follow the paradigm of requirements (specifications) --> design --> implementation, and using eh 'v' model (where unit test is the lowest level of testing), how have you specified what to design? If your unit test is incorrect, how do you know what's correct?
 

sagai

Quite Involved in Discussions
#9
Well, I truly pleased and appreciate your feedbacks, it helps a lot really and I still count on them.

I do not think, the "V" model is the only one that can be utilised for software development in order to create a medical device. Correct me, but in QSR nothing says that (except one makes me headache, is the design change definition).
More importantly, I do not think that anything says in the QSR that design input shall be reviewed and approved prior design and development evolves.

I referred to SDS as it referred to in CDRH 337.

The question in my head is the following.

If the nature of the design and development activity is that whatever test specification is reviewed, agreed and approved with the developer who was the one created the code, and this whatever level (system/integration/unit) test specification exactly reflects to the software behaviour (it should actually, otherwise the test would not fulfil its role), than WHY should be create another one documents for specification, which obviously will be a fake specification due to it will be created based on the test specification, or parallel with that?

Well, yes, it does not start from nothing, so there is a conceptual document and related stakeholders to control, the one is developed is the one that will be okay at the end.

Many thanks.
 

c.mitch

Quite Involved in Discussions
#10
I do not think, the "V" model is the only one that can be utilised for software development in order to create a medical device. Correct me, but in QSR nothing says that
Right.

WHY should be create another one documents for specification, which obviously will be a fake specification due to it will be created based on the test specification, or parallel with that
To be honest, I've never seen an SRS written from scratch. I experienced many cases but never the canonical theoretical V cycle.
The best case I 've experienced:
1st the developpers code something, it works! great! Let's do something we can sell!
2nd you or a guy do the risk analysis, write the SRS
3rd developers are not reluctant to write and update a SDS, they modify the code to stick to specifications and risk mitigations
4th you or a guy writes the tests. They pass after a few iterations of bug fixes.

The worst case:
1st The developers code the whole thing. They didn't document anything and won't (they hate word processors, they think documentation is a loss of time, what the fork()!)
2nd You or another guy spend hard times doing the reverse engineering and writing SRS, SDS and tests. You play the role of fireman and do a risk analysis.
3rd At last, an "official" tests phase is organised, to ensure that risks are mitigated and what you wrote is what the software does.

So, no, I woudn't submit the software code to any agency. Design docs are made to give a broad view of the software. Reviewers won't analyse the code or I underestimate the time they can afford to a design file.

And I think I'm stuck to the R (like Realistic) cycle. Unless you're a tyranic project manager (a bad management for software development), developers code and you run behind them to ensure that what they do is what is required and that it is well documented.

Last word. Though borderline, this is only tolerable for software of low level of concern. Fortunately for high level of concern, I've only seen companies which can spend enough cash to do it the right way.

And I think I should buy a hat like yours. Perhaps developers would listen to me when I say their project lacks documentation!
Regards.
 
Thread starter Similar threads Forum Replies Date
M Source code and explanation for computer simulation in camera calibration, HELP Calibration and Metrology Software and Hardware 2
J Can someone give a hint about FMEA about software source code FMEA and Control Plans 7
J Starting a Weibull Analysis: Source on how to perform Weibull Reliability Analysis - Predictions, Testing and Standards 2
A IEC 60601 11.2.2.1 Risk of Fire in an Oxygen Rich Environment, Source of Ignition IEC 60601 - Medical Electrical Equipment Safety Standards Series 0
B IEC 60601 Cl. 8.4.3 - ME EQUIPMENT intended to be connected to a power source by a plug / Plug discharge IEC 60601 - Medical Electrical Equipment Safety Standards Series 3
L IEC 62368-1 / Electrical Energy Source vs. Power Source? CE Marking (Conformité Européene) / CB Scheme 2
F Electrical Metrology (Source/Generation and Measurement) General Measurement Device and Calibration Topics 1
R Supplier related drawings and verification of process requirements - Source Inspection AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 3
R Supplier Controls we can place on Single-Source Suppliers ISO 13485:2016 - Medical Device Quality Management Systems 2
N Time source for paper-based documentation (research nurses) US Food and Drug Administration (FDA) 1
C Looking for source of silicone contamination in ISO Class 8 Cleanroom Other Medical Device Related Standards 2
Ron Rompen Source needed for Spline Form gauge (GO and NOGO members) General Measurement Device and Calibration Topics 3
PastorBee13 Source for the blades for Reef Snap Gages General Measurement Device and Calibration Topics 2
S Source of QMS templates including templates for design verification/design validation Document Control Systems, Procedures, Forms and Templates 2
Ed Panek Sensitive Supplier Issue - Single source supplier ISO 13485:2016 - Medical Device Quality Management Systems 6
H Gamma Irradiation - dose audit and source replenishment Other Medical Device Related Standards 13
I Uncalibrated source to calibrated meter, then compare to UUT General Measurement Device and Calibration Topics 4
T Definition Sole source VS. Single Source - Definitions Definitions, Acronyms, Abbreviations and Interpretations Listed Alphabetically 2
P Datron/Wavetek 4808 Option 70 Wideband Source - User and Service Manuals needed General Measurement Device and Calibration Topics 2
Q Source of practice to Evaluate Risks? (ISO 9001:2015) ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 1
M Contacting a "Must Use" (aka Sole Source) Supplier's Registrar Supplier Quality Assurance and other Supplier Issues 6
E Source for The Enforcement Regulations in English - Article 228-20 Japan Medical Device Regulations 8
R FAI (First Article Inspection) on source-controlled parts AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 5
E PMDA Act, Nov 2014 revisions - source in English? Japan Medical Device Regulations 3
A Reference Source for Polarity Symbol Other ISO and International Standards and European Regulations 1
J Legal source to purchase a copy of the 9001:2015 Draft ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
Crusader Calibration Source not ISO 17025 accredited ISO 17025 related Discussions 6
D Product Testing Source - Specific testing on an electronic parking brake IATF 16949 - Automotive Quality Systems Standard 1
K Ideas for an Open Source Calibration Database Software Calibration and Metrology Software and Hardware 3
R What can I expect in a Government Source Inspection? Quality Manager and Management Related Issues 13
A How to understand the source of variability and "stream-to-stream variation" Six Sigma 8
B Convenient source for finding a listing of changes to BS EN ISO standards Various Other Specifications, Standards, and related Requirements 5
M KANO Model - Changing the source Quality Tools, Improvement and Analysis 2
G Six Sigma Case Studies - Does anyone have a good source for LSS case studies? Six Sigma 8
S Source of Online or Home Based HACCP - FSSC22K Training Food Safety - ISO 22000, HACCP (21 CFR 120) 2
H Source for Compiling and Maintaining an EHS Legal Register Miscellaneous Environmental Standards and EMS Related Discussions 4
C Nuclear Industry--Unqualified Source Material CMTR Requirements Various Other Specifications, Standards, and related Requirements 1
N Boeing Portal - ASAP for Source Inspection Customer and Company Specific Requirements 4
W Seeking a Freelance Mechanical Inspector - Source Inspection in Bangalore, India AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 1
W X-ray based NDT Test Equip. Mfger. seeking CE Mark - Must X-Ray Source be included? CE Marking (Conformité Européene) / CB Scheme 5
G Source of a Clear Fixture Block on a x-y Video Microscope - Rafaelco? Inspection, Prints (Drawings), Testing, Sampling and Related Topics 3
M TS 16949 7.4.1.3 - Difference between Approved Source and Customer Designated Source IATF 16949 - Automotive Quality Systems Standard 2
P Source Inspection vs. Right of Access clause in a Purchase Order - Differences AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 16
N Outside source to provide Basic Measurement Training - Louisville, KY Training - Internal, External, Online and Distance Learning 1
M Incoming Source of Variation & Source of Variation in Process Flow Chart IATF 16949 - Automotive Quality Systems Standard 3
E Faro Laser Tracker Calibration Source Needed General Measurement Device and Calibration Topics 5
S Separate Medical Device 12V Power Source - What inspection and testing is required? IEC 60601 - Medical Electrical Equipment Safety Standards Series 1
K Open Source Software - OpenOffice vs. LibreOffice After Work and Weekend Discussion Topics 1
Marc Google Wave going Open Source After Work and Weekend Discussion Topics 1
A Second Source for a similar Medical Device 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3

Similar threads

Top Bottom