First, I reject the premise that software is poor quality when compared to other engineering disciplines. Software is immensely more complicated than any other field of engineering ever imagined. The space shuttle, commonly referred to as the most complex machine ever built, has around 2.5 million parts. The Linux kernel alone has over 16 million source lines of code. It's an order of magnitude more complex than the SPACE SHUTTLE!. And even given that difference in complexity, disasters and problems occur still in the physical engineering world.
I think the reason why people have a perception that software is bad, is because, perversely, most of the time, it's really good. It's so magical that I can, with a device in my pocket, call up the latest sporting results for a game happening on the other side of the planet with only a few seconds delay, and perhaps even see video footage of it happening - all this enabled, it should be clear, by millions and millions of lines of software - that I can't even conceive of all the things that went right to get that far if the youtube app crashes for some unforeseen reason. The magic stopped, ergo software is crap.
The document then goes on to attempt to define a process for developing software. What is lists is a bit laughable:
1. Planning: Produce a plan to do the work. 2. Development: Perform the work. a. Define the requirements (see 4.2.2) b. Design the program c. Review the design and fix all defects d. Code the program e. Review the code and fix all defects f. Build or compile and fix all defects g. Test the program and fix all defects 3. Postmortem.
Anyone who's ever done software development, will tell you that the order for these is something like:
2b, 2a, 2b, 2d, 2c, oh - someone's asking for sizings, better do some 1 - 2d, 2c, 2d, 2b, 2a, 2d...
Trying to develop software in a process-oriented fashion is doomed to failure, because developing software is the act of creating processes for a computer to execute. If it were possible to define a software development process, we could get someone to write it up in C, or Python, or whatever, and then just kick back and let the computer do the development for us! Heck, if we take the extra time to code in PV and EV calculations, it'll have a working progress bar too!
[|||||||||||||__________] Coding... (50%)
That being said, these elements of the "process" are useful as a taxonomy for the kinds of activities that must be performed as part of software development, and if you fail to do any of them, you will likely produce inferior quality software. But listing them in a regimented fashion, or trying to follow them as a "process", simply does not work.
But in the end there's an awful lot of waffle in what amounts to a pretty impenetrable document. There's got to be a better way to codify what we actually do when we develop good software. Not what we think we do, or wish we did, or claim we do to sound impressive.
Edit: grammar.