[calebm]

I wrote (non-critical) software for the A400M. I don't think that standards like DO-178B necessarily lead to higher quality code; my experience was that 80-90% of time was spent doing documentation, testing, and in general, trying to prove that the software was going to work right, leaving the engineers with very little time to write the actual software...

[Jtsummers]

What processes did you and your coworkers use for writing up your requirements, design, test procedures, etc. (Basically, the DO-178B/C artifacts.) IME, too many times groups use Word and Excel, and collaborate via email. Version control is, "I think CM has received my latest revision". Using better tools (requirements management software) would eliminate a lot of this overhead. At a former employer we were moving to DOORS on all new projects. They were able to spend much more time on development and analysis and less time on documenting and checking documentation because the process was smoother. They weren't editing 1k page documents, they were editing a collaborative document backed by a database, not unlike a wiki. I could edit one section, and you could edit another at the same time. No risk of merge conflicts, no risk of your update replacing mine.

[crististm]

DOORS is just a glorified database with a text editor and schema for tracking change requirements. I found it lacking even at this.

[Jtsummers]

Not saying it was great, but it was a hell of a lot better than Word + Excel. Probably a lot of better tools out there, but it's been a while since I've needed to use them so I'm no longer familiar with what's available.

What made it better:

Concurrent editing. Only one person at a time was modifying any section, but two or more sections could be edited by a group of people.

Version control baked in. VC is awesome, reducing friction means that it actually gets used. Checking in/out sections was just part of the process.

Automatic traceability matrices. These are not easy to make by hand. That way is error prone and tedious. It's also hard to verify. With DOORS we were able to generate these automatically. Verifying them was relatively painless because we weren't flipping through several 1k page documents to make sure things actually matched, we could easily skip to only the applicable parts of any document. The main error that it didn't reduce was when a requirement didn't get linked to every test case or design feature that it should've been linked to.

Again, probably better tools out there than DOORS (at the time, or hopefully by now). But it's a lot better than what most offices do with either post hoc document generation or ad hoc generation with Word + Excel.

[sliverstorm]

in general, trying to prove that the software was going to work right, leaving the engineers with very little time to write the actual software...

Sure sounds like the way it should be to me. Maybe it needs to be made easier to prove your software is correct, but to me it seems like for systems like airplanes, code that cannot be proven correct is worthless.

Considering most programmers are said to produce 6 lines of good code a day, maybe it's not even actually slower in the end if the formal verification process filters out every other line you would have written that day.

[calebm]

It's not a bad thing to put in quality assurance measures in place. It's a bad thing, though, if so much time is spent on QA, that there you are rushing to write the actual code. Rushed coding does not produce quality.