What did I say about not getting into details?... There's the joke that the great thing about standards is there are so many to choose from. In this case, code users may be variously motivated by ISO9001 or CMMI or in our case NQA-1 which does its level best to treat software as a plant component like a pump or valve or spool of cable regardless of how much software resembles none of those things. Never underestimate the tenuous logic of a committee of mechanical engineers, I guess. Regardless, if you have to chart a course through overlapping or conflicting standards, it's reasonable to start with a set that is a close philosophical match for your organization and try to logically pick and choose the best aspects of the other standards, then distill that down to something you can understand, explain, and implement. Again, you know you won't satisfy everyone but you're not just making it up as you go along and you have a consistent high-level narrative of what problems you're trying to address. You make it clear you did your research and are taking the problem seriously; people can argue over the details but you can show you address the core issues in a systematic way and there's a path from procedures back to the plans they implement. There's some logical consistency to it and it's up to the stakeholders (in this case us) to judge whether the differences and details are significant enough to argue about. Most of these standards are just different ways of getting to the same place and maybe more important than the details is that staff have a process they understand and can follow and they can demonatrate that they adhere to. This stuff is picky and tedious but ultimately is meant to keep people out of trouble and to avoid known and avoidable problems. What we are getting out of this is more exposure to different risk philosophies - we're required to meet NQA-1 but not everyone is and we know that spec and Procurement-centic approach is not a great fit for safety analysis software (software FMEA? Are you mad bro?...)

As we walk through their process, looking at a few specific error reports and feature requests we can see reasonable consistent practice that makes sense and is familiar. There's a strong emphasis on configuration management so systems are known, processes are repeatable, and you can reason about the system state. Testing is comprehensive and improving and there's clear indication the code is becoming more robust with every release and that trends ard being watched. Here we're looking at a mature code that's been under active development since the early 80s. Parts of the code predate QA requirements so there are known issues where certain parts of the code are more fragile than others and much more care is taken when modifying them to avoid breaking some of the less robust code. It's not great but it's the nature of a large code that evolved over a long period; there's no easy solution and there are always resource constraints. But what we see is that risks are understood and managed and practice follows philosophy and the QA regime is a tedious net positive. People know what they're doing and why and there's enough self reflection and peer review to keep everyone honest. All things considered they're doing about as well as could be expected. We might be able to see some gaps but we also see there are constraints we don't have that. In the main what they are doing makes sense and is reasonable even if it's not exactly what we'd do. Mostly it's a different path to about the same place and their practice is not too different from our own. Like I said, our goal in this visit is to understand not to verify compliance and we're waking away with the sense that they know what they're doing, their practice is mostly consistent and makes sense.