3 ms·

For those wondering, there is the original handbook [1] available online today. Also an interesting paper on the process improvement lessons learned applying mu

For those wondering, there is the original handbook [1] available online today. Also an interesting paper on the process improvement lessons learned applying much of what was expressed in the handbook [2]. I believe the paper is of more immediate TL;DR use today for those who do not have the time to digest the handbook and internalize the lessons to draw from it. [1] https://everythingcomputerscience.com/books/nasa-manage.pdf https://everythingcomputerscience.com/books/nasa-manage.pdf [2] http://www.cs.umd.edu/projects/SoftEng/ESEG/papers/83.88.pdf http://www.cs.umd.edu/projects/SoftEng/ESEG/papers/83.88.pdf

timoth3y 5y ago
That's the one! Thank you for posting the link and the lessons learned. That looks like a great article. In the 90s it took a (very friendly) FOIA request, a $5 processing fee, and three weeks to get my hands on that handbook.
bdavis__ 5y ago
curious if anyone tracks software engineering metrics like this anymore? defects identified, defect fixed vs. time
- Jtsummers 5y ago
  Yes. However, it's mostly in "maintenance" programming. Particularly in the way that DOD and safety critical systems are maintained. It's both a reasonable and unreasonable concept. It's unreasonable because it tries to turn programming into factory work, in fact you may even see them set up workflows predicated on an assembly line concept. This kind of works, and why it's kind of reasonable, when the work is sufficiently well-understood. It's very common in these systems to have a very detailed specification. Often the defects are deviations from the specifications that got through because of the manner in which these were classically tested (primarily integration tests, often manual, necessarily restricting the scope of the testing regimen). Other defects are realizations that the specification itself has an issue (happens), often the result of a dependence on a prose format for the specification which doesn't lend itself well to formal analysis. It also tends to, well, become wordy. 1000 page specs are not unheard of even for relatively small systems, you can imagine there may be quite a few pieces of conflicting information in there.

timoth3y 5y ago

That's the one! Thank you for posting the link and the lessons learned. That looks like a great article. In the 90s it took a (very friendly) FOIA request, a $5 processing fee, and three weeks to get my hands on that handbook.

bdavis__ 5y ago

curious if anyone tracks software engineering metrics like this anymore? defects identified, defect fixed vs. time

Jtsummers 5y ago
Yes. However, it's mostly in "maintenance" programming. Particularly in the way that DOD and safety critical systems are maintained. It's both a reasonable and unreasonable concept. It's unreasonable because it tries to turn programming into factory work, in fact you may even see them set up workflows predicated on an assembly line concept. This kind of works, and why it's kind of reasonable, when the work is sufficiently well-understood. It's very common in these systems to have a very detailed specification. Often the defects are deviations from the specifications that got through because of the manner in which these were classically tested (primarily integration tests, often manual, necessarily restricting the scope of the testing regimen). Other defects are realizations that the specification itself has an issue (happens), often the result of a dependence on a prose format for the specification which doesn't lend itself well to formal analysis. It also tends to, well, become wordy. 1000 page specs are not unheard of even for relatively small systems, you can imagine there may be quite a few pieces of conflicting information in there.