[yshrestha]

Agreed. The standards are designed to be impervious to time and the implementations used. This has the unfortunate consequence of being quite abstract and difficult to grasp at first.

For example "configuration management" was meaningless the first time I read it but really just translates to "version control"

I think having an open source example will really help the concepts make sense to engineers implementing this for the first time.

[ska]

Configuration management is more than version control, it's how you control your entire deployment, VC is one part.

VC can be a huge part of this if you are software only, but it also helps sometimes to remember that these standards were written with hardware in mind.

Another thing that can help with understanding is to start from what they are trying to achieve (talking to someone experienced here helps) and work backwards.

For example, the idea that if I pull a version of your release software off a machine at a hospital, you should be able to demonstrate to me that you know exactly how it was produced and ended up there. The source code, the build machines, the packaging, etc. You should be able to tell me what other version exist and where they are. If I need you to notify everyone with a particular configuration of an important update you can do that.

Stuff like this leads you to the configuration management language pretty naturally.

[yshrestha]

Good point. My cognitive bias towards SaMDs is standing out here. I am going to borrow your example of what a "configuration" is, if you don't mind.

[ska]

You are of course welcome to!