Configuration Management in practice

[drm71]

I've not worked as a proper developer for more than 20 years, and even then I would hesitate to describe myself as a "proper developer" so am looking to get some practical information regarding Configuration Management as per 62304 standard.
I am used to thinking about a SW version and a file or list of all source code repos and external libraries or packages that are included in building that version (so I guess you should also include things like the versions of the compilers and other tools, though I've rarely seen this).
And things like requirements, are these mostly covered as part of product level design control or are there schemes for this if managed entirely within a dev tool etc
Are there typical things that are "missed" or forgotten that should be considered, identified as config items and how is this usually documented

so yeah, any *practical* refs, tips, descriptions or info would be very useful, I might have to do an audit and I was thinking configuration management is a good topic, but then I realised my own understanding of this was ... incomplete

 

[yodon]

I always like to frame it up as: capture everything that is needed so that I can move everything over to another system and completely rebuild the exact same binaries (allowing for things like date/time stamp differences, of course).

I've seen cases where there are local libraries that get sucked in but weren't under CM.

You didn't mention change control, but that's a big part. In a configuration status accounting audit, I get a code diff between versions and then confirm that all changes were authorized and only authorized changes were implemented. Look "up" from the code to the change authorizations and "down" from change authorizations into code. We use checkin comments and/or the tools integration to tie changes to authorization.

 

[drm71]

thanks, yes change control is important, but I was also thinking even more practical when you say "get code diffs" for example, is that something developers typically export out to a document or most development environments have this as some digital record. And in the case of things that developers say "we do this within XXXdevelopmentIDEXX" is that typically noted in an SOP or SWDP or is there a need for an export of this to a document (that can be viewed and reviewed by an auditor "On paper" rather than relying on an auditor being able to dig into a SW developers IDE environment


so what practical form (single document, a list, a set of files indexed in a document, a set of refs identified in a SOP) would you typically use to
"capture everything that is needed so that I can move everything over to another system and completely rebuild the exact same binaries"

is more what I am after

and as an aside, is there any need/use for routines where someone would test this, i.e. "OK here's our configuration, go away and build the same software somewhere else and prove its complete".

 

[Ronen E]

Caveat: I don't come from a particular MD SW background, nor I am a SW developer. I come from the physical devices development and regulatory compliance world, and I have some background in coding in modern IDEs. My replies below are more hi-level / first principles-based.

is there a need for an export of this to a document (that can be viewed and reviewed by an auditor "On paper" rather than relying on an auditor being able to dig into a SW developers IDE environment

From an auditing perspective, I don't see anything very wrong with an auditor not familiar with the particular IDE environment in use asking: "Please show me where it's documented; show me the control trail (including managed permissions); and explain why you have confidence that all of this will still be here next week or in 5 years, unchanged unless duly authorized."

"capture everything that is needed so that I can move everything over to another system and completely rebuild the exact same binaries"

Isn't that the device specification? Equivalent with production drawings and manufacturing equipment specifications for physical devices.

is there any need/use for routines where someone would test this, i.e. "OK here's our configuration, go away and build the same software somewhere else and prove its complete".

If portability is a design input requirement, that would be part of design verification of every new product revision.

 

[drm71]

Thanks, I think I recall that the FDA specifies a kind of software bill of materials (SBOM) now that I remember it

yeah I don't mean portability I mean a process for something like "configuration replication", which I suppose would be a kind of verification that your claimed set of configuration items, including required tools and settings is actually complete.
I mean I can say I included this set of source code files, these external libraries/packages, and compiled with this set of build instructions on this tool, and here you can see I ended up with a software which we verified and validated.

but how can you prove that your information isn't missing some key package or setting or something like this if it's not separately verified?At least building your software again with the ConfigItems might be a good sanity check

 

[yodon]

when you say "get code diffs" for example, is that something developers typically export out to a document or most development environments have this as some digital record.

No, it's just to facilitate the configurations status accounting audit. Nobody requires the record be kept. And noted that when I mention a configuration status accounting audit, that's an internal thing. I've yet to see any ISO auditor or FDA inspector dig into software CM.

Regarding the comment @Ronen E made, were an auditor / inspector to actually ask to drill down, I would start with the change authorization and then show how that's linked to the code changes. Exposing a complete code diff might be showing too much. (Not that we couldn't defend everything, just that it would possibly get the audit / inspection off track). If they wanted the opposing view (code changes back to change authorization, I would pick specific code modules.

so what practical form (single document, a list, a set of files indexed in a document, a set of refs identified in a SOP) would you typically use to
"capture everything that is needed so that I can move everything over to another system and completely rebuild the exact same binaries"

I don't know if you can abstract that up to an SOP. We snapshot everything in the version tracking repository and reference all the configuration items in a Version Description Document.

and as an aside, is there any need/use for routines where someone would test this, i.e. "OK here's our configuration, go away and build the same software somewhere else and prove its complete".

Is it a good idea to do this periodically? Yes, IMO. Do people regularly do it? Probably not. For me, it's a health-check. Did we get everything properly under configuration control.

Isn't that the device specification? Equivalent with production drawings and manufacturing equipment specifications for physical devices.

And one for Ronen: close, but this is physically capturing the "manufacturing equipment" (e.g., IDEs & build scripts). It would be like moving all the manufacturing equipment to another site

Thanks, I think I recall that the FDA specifies a kind of software bill of materials (SBOM) now that I remember it

That's a cybersecurity thing and focuses really only on SOUP.

 

[Tidge]

Are there typical things that are "missed" or forgotten that should be considered, identified as config items and how is this usually documented

I emphasize that configuration management should allow for the "three Rs": Rebuild, Replace, Repair (or Rewrite, for software). It has been typical in my experience that the configuration management plan/process keeps track of (i.e. archives with unique versions) the source code and libraries.

The compiler is supposed to have been archived in its own tool repository; I've seen issues where the development team wasn't using an archived version of the tool, and more commonly that they are using some ancient version of a compiler that "doesn't work on modern OS" (e.g. a 32-bit application).

The only other subtle things that I've tried to make sure gets documented are things like "compiler flags" or framework settings that can lead to slight differences in builds upon recompiling. There are different ways to achieve this, if folks can't archive specific build scripts or lock down/specify the build framework sometimes hints can be added as notes to the text version of release notes and/or software specification documents.

 

[drm71]

Thanks for the great feedback as always!