On February 7th, NASA shared it's initial findings from the Boeing Starliner orbital flight test investigation.The copy used by NASA in the press release is damning to Boeing's software engineering process.

Boeing, NASA, and U.S. Army personnel work around the Boeing CST-100 Starliner spacecraft shortly after it landed in White Sands, New Mexico, Sunday, Dec. 22, 2019. Photo Credit: (NASA/Bill Ingalls)

The press release lays out three major issues that occurred and states that the investigation made the following determinations:

1. An error with the Mission Elapsed Timer (MET), which incorrectly polled time from the Atlas V booster nearly 11 hours prior to launch.
   
2. A software issue within the Service Module (SM) Disposal Sequence, which incorrectly translated the SM disposal sequence into the SM Integrated Propulsion Controller (IPC).
    
3. An Intermittent Space-to-Ground (S/G) forward link issue, which impeded the Flight Control team’s ability to command and control the vehicle.

 Regarding numbers 1 and 2 above:

• Breakdowns in the design and code phase inserted the original defects.
   
• Additionally, breakdowns in the test and verification phase failed to identify the defects preflight despite their detectability.

There's not really much that I can add to that. It would appear that despite having a process for software engineering, "breakdowns" in that process rendered it ineffective in this case.  If I were to hazard a guess, I imagine that at Boeing, the software engineering process is well documented and robust. And, most importantly, it may prevent software development from getting done in a manner that is compatible with project schedules.

As a milestone or deadline looms in the near distance, project teams may end up "just click through the step" on a code review. Or, perhaps a verification/QA step got the same treatment. At the end of the day, the paradoxical situation of (a) there being evidence that the process was followed and (b) the process was completely ineffective is what is observed.

I could be wrong in the above analysis - there could be another factor - e.g. the code review simply didn't catch the problem, or the use case that made the defect detectable wasn't in the validation steps. However, the scenario outlined in the previous paragraph is a situation that I have encountered going back to the first years of the 21st century.

In those days, the "ISO Audit" was where auditors came in to the office and verified that the company follows standards and practices. One day, during a prep for an ISO audit at a major engineering firm where I was a "contractor", one of the firm's full employees gave me the following guidance:

"If they ask about the process, simply say 'there is a process' and direct them to me. The most important part is that we have a process". 

Indeed.