This section is about software process, a.k.a. software engineering. It was not called Engineering because software "engineering" still has a way to go before it becomes a true engineering discipline. It is troubling that this state of the practice has been cited for three decades in the literature (e.g. Hoare, 1975; Moore, 1998; Kitchenham and Budgen, 2002; Humphrey 2005 - see Reading List for references).
The problem is that software engineering has no formalized empirical underpinnings (Moore, 1998, p. 3). While practice standards for software engineering do exist, they are drawn from experience and observation (Kitchenham and Budgen 2002), and not constrained by a body of scientific and engineering principles as are practice standards in other fields of engineering. It seems we are still working on the foundation: a commonly-accepted body of knowledge. In fact, Moore describes the body of work in software engineering standards as "dis-integrated, capriciously different in detail, overlapping and occasionally contradictory" (p. 4).
We may have come further than when Moore's roadmap to software engineering standards was published in 1998, but we are not there yet. Kitchenham and Budgen state that empirical techniques "are still far from being incorporated into mainstream practice, even for academic research projects" (2002). This is a problem for any organization that is planning to implement a particular standard. How can they rationalize their choice to adopt a particular standard, and explain their choice if they need to show that they were not negligent in creating a product that is safe and fit for its intended use?
Even though the decision to follow particular standards may be difficult to make, there are several reasons why standards should be used (Moore, 1998, p. 8):
If these are not reason enough, it should be noted that standards are sometimes considered in procurement decisions (ibid p. 7).
This ongoing work attempts to show the current state of software process and practice.