Royce's top 10 principles for modern software management

CHAPTER 3: Engineering of Software

OBJECTIVES

· Understand the rationale behind the need to establish a discipline in software engineering.

· Analyze the main causes of software project failures.

· Give an example of software product failures.

· Understand the term software engineering as it was introduced at the 1968 NATO conference.

· Define the concepts of software engineering and professionalism.

· Review the software engineering code of ethics.

· Discuss the sets of principles and foundations of software engineering put forward by Alan Davis, Walker Royce, and Anthony Wasserman.

3.1 Examples and Characteristics of Software Failures

There are many differences between a one-person programming effort and a large software system effort, as discussed in Chapters 1 and 2 . The degree of complexities between these two approaches have caused many project managers and software engineers to realize the need to bring more discipline into the field. Another strong motivation to establish the software engineering discipline is the number of failures in software projects and defects encountered in the software products. This section will explore some of these failures.

3.1.1 Project Failures

A quick search on the Internet today for software project failures will quickly result in pages of examples. The CHAOS report, published in 1995 by the Standish Group, suggests that many of the mistakes in software projects are not well investigated and that the same mistakes continue to be repeated. Their research included large, medium, and small companies across most of the major industries—banking, manufacturing, retail, state and local government, health, and so on. Using a sample size of 365 respondents, researchers found that only about 16% of the software projects were completed on time and on budget, with all the features and functions as initially specified. The report goes on to profile the success and failure factors. The four most important reasons for project success are the following:

1. User involvement

2. Executive management support

3. Clear requirement statements

4. Proper planning

These four factors form 52.4% of the responses to the question of contributors to project success. A software project has a dramatically higher chance of success if these four factors are performed properly. As the article “They Write the Right Stuff” written by Fishman (1997) and published in Fast Company (2005) indicates, factors such as clear requirements and user involvement are also among the reasons attributed to the success between NASA and Lockheed Martin Corporation in developing the space shuttle software.

The CHAOS report also listed the three top failure factors for software projects. The study defined “challenged” projects as those that are completed and operational but over budget or over the time estimate, or those lacking some functional features from the original specification. The top three reasons of failure for these challenged projects are as follows:

1. Lack of user input

2. Incomplete requirements and specifications

3. Changing requirements and specifications

These reasons form approximately 37% of the survey participants’ responses for software projects that are classified as “challenged.”

The following reasons are cited for failure of the projects that are impaired and ultimately cancelled:

1. Incomplete requirements

2. Lack of user involvement

3. Lack of resources

These three factors form about 36% of the responses for reasons for the ultimate cancellations of software projects.

The CHAOS report looked further into two cancelled software projects and two successful projects. The two cancelled projects were the California DMV’s driver’s license and registration applications and American Airlines’ car rental and hotel reservation system. Both projects had little user involvement and unclear requirements. The American Airlines project was a joint enterprise with Budget Rent-A-Car, Marriot Corporation, and Hilton Hotels, thus involving many people, which increased the project complexity.

The two successful projects were the Hyatt Hotels’ reservation system and the Banco Itamarati’s banking system. The Hyatt Hotels’ reservation system had both user involvement and clear requirements. The Banco Itamarati project did not have clear requirement statements, but it did have heavy user involvement. In his book, Assessment and Control of Software Risks, Capers Jones (1994) also lists “creeping user requirements” as the top risk factor for management information systems.

It is not surprising that user involvement and user requirements are listed as top reasons for both software project successes and failures. Without understanding what is to be developed, there is very little chance of success for any project. Software projects are especially difficult to specify because many aspects of the work involved are nontangible. Requirements elicitation, analysis, and specification activities form a key component of software engineering. Requirements engineering activities are introduced in Chapter 6 .

3.1.2 Software Product Failures

Software project failures include many types of problems, such as cost or schedule overruns. Software product failure is one of the types of project failure. Jones (2008) has also studied software product failures and the origins of those bugs. He illustrates the distribution of software product errors by different origins. The average percentages of bugs by different origins are as follows:

· Requirements errors: 12.50%

· Design errors: 24.17%

· Code errors: 38.33%

· Documentation errors: 13.33%

· Bad-fix errors: 11.67%

These numbers, by themselves, would indicate that more errors are caused by coding. But it hides the cost issue behind problem-fixes. An error introduced during the requirements phase may propagate into design and coding. It may not be discovered until after the product’s release. Furthermore, one requirement error may turn into several design and coding problems. Thus, fixing a requirement error that escaped into design or code is generally more expensive than fixing a coding error. Therefore, even though the percentage of errors originated from the requirements phase is only 12.5%, the cost of fixing those problems is usually the most expensive. It would seem that more problem-preventive activities should be applied to the requirements phase of software development than some of the later phases. Requirements specification can be quickly tested with a hand-drawn prototype presented to the client and users. This would confirm and validate the requirements to the development team. Unfortunately, requirements gathering and specification is often hurried through without conversations with the client and users.

Both requirements specification and design specification are not directly executable. A prototype may be built to test them. However, for the most part, requirement and design are detected through reviews and formal inspections. The more often these errors are found prior to coding, the less impact they will have on coding, testing, and on user guide development and other documentation activities.

3.1.3 Coordination and Other Concerns

Many software project failures are blamed on bad code, but the causes are often not rooted in programming efforts or the software alone. Rather, as a recent Associated Press report stated, “As systems grow more complicated, failures instead have far less technical explanations: bad management, communications or training.” They cite multiple examples. In 2004, a southern California system that controls communications between commercial jets and air traffic controllers malfunctioned due to a lack of proper software maintenance.

To reduce risks, many corporations are moving toward buying established enterprise software products such as SAP, Oracle, and PeopleSoft. (PeopleSoft was acquired by Oracle in 2004.) Some are engaged in using consultants and in outsourcing the implementation of these large, complex enterprise resource management systems. The problems surrounding these types of projects are usually not the software product themselves. These large endeavors involve complex factors:

· Executive commitments and leadership

· Thorough planning of both business and technical processes

· Skilled and experienced consultants

· Relentless management focus and monitoring of the project

· Willingness to change and make adjustments when required

In a March 2004 U.S. General Accounting Office (GAO) report to the Committee on Armed Services of the U.S. Senate, three basic management strategies were cited as key to ensuring the delivery of high-quality software on time and within budget:

1. Focused attention on the software development environment(s)

2. Disciplined development processes

3. Methodical usage of metrics to gauge cost, schedule, and performance targets

These three characteristics were demonstrated in leading companies visited by the U.S. Department of Defense (DOD).

The DOD is an acquisition office, and its focus is on acquisition process. Thus the DOD must properly train its personnel on managing the acquisition of needed software. It is vital for the DOD acquisition managers to be able to recognize signs of successful software organizations from which they source their software. They must be able to differentiate those that are practicing good software engineering from those that are not.