Eight principles of software engineering

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.

3.2 Software Engineering

3.2.1 What Is Software Engineering?

So far, we have used the term software engineering and relied on each reader’s intuitive feel for what software engineering is. We have discussed and given examples of activities that are part of software engineering. We have characterized attributes of both simple and complex software products and software projects. We have cited examples of software project and product failures. We have provided glimpses of what may be needed to succeed. Software engineering has many aspects, and we have hitherto delayed any formal definition because we wanted readers to take in the wide scope of this discipline. It is a young field, still evolving and growing, that has its origin in computer science and programming. Thus it is difficult to define, and its definition will also continue to evolve.

The term software engineering was first introduced in a 1968 North Atlantic Treaty Organization (NATO) conference held in Germany. During the late 1960s, the computing field was starting to face a software “crisis.” Computer hardware had made great leaps in computing power and storage capacity. This ushered in an era that saw the beginning of developing large and complex software that required a large number of programmers. The first wave involved system-level software such as operating systems, file systems, and access methods. With the recognition of the huge potential of business automation, large and complex business applications software also started to emerge shortly afterward. Early experiences with writing programs proved to be insufficient for these large, complex projects. As a result, many software projects were delayed, and some were never completed. Others were completed but experienced excessive budget overruns. The final software product often demonstrated unsatisfactory quality and performance. The users of these software systems were often subjected to incomprehensible manuals that were written by programmers who never met the users. These software releases needed continual support and maintenance that the original programmers were not trained to handle. The attendees of the 1968 NATO conference recognized the need for a discipline much like the other engineering disciplines and thus formalized the concept of software engineering. In the past 30 years, great strides and improvements have been made in the software industry and in academia. But many more improvements are still needed for software engineering.

3.2.2 Definitions of Software Engineering

One of the earlier definitions of software engineering may be attributed to David Parnas, who stated that software engineering is a multiperson construction of multiversion software ( Hoffman and Weiss, 2001 ). This definition certainly brings out some of the aspects of software engineering that have been discussed, for example, increasing developers means more lines of communication needed (see Section 2.1.3 ).

Ian Sommerville (2010) states that “software engineering is an engineering discipline whose focus is the cost-effective development of high-quality software systems.” He further explains that software is “abstract and intangible” and defines software engineering as “an engineering discipline that is concerned with all aspects of software production from the early stages of system specification to maintaining the system after it has gone into use.” This definition certainly captures the software life cycle from inception to product sunset.

Shari Pfleeger (2009) uses the relationship between chemistry and chemical engineering as an analogy to discuss the relationship between computing and software engineering. She states that in computing we can focus on the “computers and programming languages themselves or we can view them as tools to be used in designing and implementing a solution to a problem. Software engineering takes the latter view.” According to her view, software engineering is the application of computing tools to solving problems.

The Software Engineering 2004 Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering published by the Association of Computing Machinery (ACM) and IEEE Computer Society recognizes the broad scope of the field and highlights three definitions from different sources:

· From F. L. Bauer: “The establishment and use of sound engineering principles (methods) in order to obtain economically software that is reliable and works on real machines.”

· From CMU/SEI-90-TR-003: “Software engineering is that form of engineering that applies the principles of computer science and mathematics to achieving cost-effective solutions to software problems.”

· From IEEE std 610-1990: “The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.”

The Curriculum Guidelines goes on to further state,

Software engineering is about creating high-quality software in a systematic, controlled, and efficient manner. Consequently, there are important emphases on analysis and evaluation, specification, design, and evolution of software. In addition, there are issues related to management and quality, to novelty and creativity, to standards, to individual skills, and to teamwork and professional practice that play a vital role in software engineering.

It is clear that capturing software engineering in a single sentence is very difficult due to its breadth and its short history. In the rest of this text we will cover many of these fundamental components of software engineering.

3.2.3 Relevancy of Software Engineering and Software

Given that the field of software engineering is so broad and that today’s software is intricately involved in our daily lives, it is impossible to ignore the significance of software. Our financial systems are managed by banking systems, our transportation is managed by various devices that contain embedded software, our household appliances and cars all contain embedded software, our health care is dependent on sophisticated medical systems, our manufacturing is run with large enterprise resource processing systems, and even our food supply is managed by distribution and warehouse software systems.

With our world depending so heavily on software, it is only natural that software engineering, which includes the development and support of these software systems, is gaining the attention of the software industry, academia, and the government. At the writing of the 4th edition of this book in 2016, there are twenty-three ABET accredited software engineering undergraduate programs. Many more are in the process of preparing for their accreditations in software engineering.

Software engineering A broad field that touches upon all aspects of developing and supporting a software system: * Technical and business processes * Specific methodologies and techniques * Product characteristics and metrics * People, skills, and teamwork * Tools and training * Project coordination and management

As software usage grows, so has its value. According to a 2002 Research Triangle Institute (RTI) report prepared for the U.S. National Institute of Standards and Technology, software has become an “intrinsic part of all the U.S. businesses today.” It goes on to state that the total sales of software reached approximately $180 billion in 2000.

The increased value of software has also brought its share of problems, as millions of dollars of software are stolen each year, mostly in the form of illegally copied material. Software is an intellectual property. As such, it has value and needs to be protected. Many different types of violations of intellectual properties are cited in a 2004 U.S. Justice Department’s Task Force Report on Intellectual Property. Counterfeit software is listed as a prime example of some of the intellectual property prosecutions conducted by the Justice Department. According to this same report, the department is making the enforcement of criminal intellectual property laws a high priority and has developed a specially trained team of prosecutors to focus on intellectual property crimes.

3.3 Software Engineering Profession and Ethics
The traditional engineering professions, such as civil or electrical engineering, has a designation of Professional Engineer (PE) in the United States. This title is earned, and it is certified by the local state government. The certification involves work experience, training, and examinations. In many other countries, the traditional engineers are also certified. In 1998, the Texas Board of Professional Engineers adopted software engineering as a distinct discipline under which an engineering license may be issued. This effort is still relatively new, and the first examination was given in 2013.

3.3.1 Software Engineering Code of Ethics
Today, software is a valuable intellectual property, and software engineering is moving toward a more disciplined profession. Software plays a key role in all dimensions of our lives. As professionals, software engineers must conduct their practices at some level of professionalism to minimally ensure that their work results in no harm to society. The IEEE-CS/ACM Version 5.2 joint task force report has recommended eight principles for ethics and professional practices in software engineering:

1. Software engineers shall act consistently with the public interest.

2. Software engineers shall act in a manner that is in the best interests of their client and employer, consistent with the public interest.

3. Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.

4. Software engineers shall maintain integrity and independence in their professional judgment.

5. Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.

6. Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.

7. Software engineers shall be fair to and supportive of their colleagues.

8. Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

Under each of these general principles, there are several sub-elements that further explain the principles. For example, the second principle of this code, which deals with client and employer, has nine more explanatory subprinciples regarding the duties of software engineers:

1. Provide service in their areas of competence, being honest and forthright about any limitations of their experience and education.

2. Not knowingly use software that is obtained or retained either illegally or unethically.

3. Use the property of a client or employer only in ways properly authorized, and with the client’s or employer’s knowledge and consent.

4. Ensure that any document upon which they rely has been approved, when required, by someone authorized to approve it.

5. Keep private any confidential information gained in their professional work, where such confidentiality is consistent with the public interest and consistent with the law.

6. Identify, document, collect evidence, and report to the client or the employer promptly if, in their opinion, a project is likely to fail, to prove too expensive, to violate intellectual property law, or otherwise to be problematic.

7. Identify, document, and report significant issues of social concern, of which they are aware, in software or related documents, to the employer or the client.

8. Accept no outside work detrimental to the work they perform for their primary employer.

9. Promise no interest adverse to their employer or client, unless a higher ethical concern is being compromised; in that case, inform the employer or another appropriate authority of the ethical concern.

Copyright © 1999 by the Association for Computing Machinery, Inc. and the Institute for Electrical and Electronics Engineers, Inc.

Software engineering, to be judged as a professional engineering practice, must include the code and regulations that its members must uphold. Thus software engineering also includes directions for its members’ knowledge acquisition and directions for its members’ behavioral practices. This is particularly difficult because there are no government regulations and codes for software engineering similar to those for civil or chemical engineering. As mentioned earlier, there are laws for protecting intellectual properties, and software engineers can look to those for guidance. The fact that there has been a task force effort on defining the code of conduct for software engineers already indicates that significant progress has been made in software engineering toward professionalism.

3.3.2 Professional Behavior
Following the code of ethics recommended in the eight principles is certainly a good start. However, there are so many details in these eight principles. One of the authors of this book has utilized a simpler moral and ethical guide in the years of practicing software development, support, and management in the software industry. These values were heavily influenced by the earlier IBM corporate values:

· Respect others and strive for fairness.

· Perform to one’s best capability.

· Follow the law.

These seem to be simplistic guidelines, but they in fact provide a basis for a broad scope of the actions and judgments for professionals in software engineering. It is impossible to list all the potential places where a software engineer must behave ethically. However, there are plenty of opportunities where these simple guidelines would apply, including the following examples:

· Handling information privacy

· Handling quality issues and problem resolutions

· Handling project estimation and project coordination

· Handling reuse and intellectual property

· Handling security

In all of these situations, software engineers would be well served if they would stop and consider the issue of respecting others and fairness, of performing to their best ability, and of abiding by the law prior to making a judgment or taking an action.

There are several websites that provide further information on ethics and the issues surrounding this topic. The Software Engineering Ethics Research Institute at the East Tennessee State University site maintained by Donald Gotterbarn is a current example. Gotterbarn also chaired the Executive Committee of the IEEE-CS/ACM Joint Task Force that developed the Software Engineering Code of Ethics and Professional Practices.

The questions dealing with code of conduct and ethical behavior eventually lead to a discussion of concepts related to terms such as good and bad or virtue and evil. Philosophical discourse on this topic is beyond the scope of this textbook, but there are many good books that deal with this subject.

Michael Quinn (2014) provides a good introduction to ethical theories and the application of those theories to information technology. Ethics as a topic has certainly been studied and analyzed by philosophers for thousands of years. For those interested in more in-depth philosophical writings by some of the leading thinkers in this area, such as Bertrand Russell, Sir David Ross, G. E. Moore, and A. C. Ewing, see the readings in ethical theory gathered by Sellars and Hospers (1952) .

3.4 Principles of Software Engineering
Many students of software engineering as well as practicing software engineers have asked if there are natural laws or principles in software engineering similar to those we find in other disciplines—for example, something equivalent to laws of motion or laws of thermodynamics. We in software engineering do not have a set of laws. We do have several sets of proposed principles of software engineering . These principles have evolved through numerous years of past experience and many are well accepted. Because software engineering is still young and still developing, the existing principles will continue to be modified and new ones added. In this section we will introduce some of them.

Principles of software engineering The rules and assumptions in software engineering derived from extensive observations.

3.4.1 Davis’s Early Principles of Software Engineering
Alan Davis (1994) is one of the earlier authorities to bring forward a set of principles that underlie software engineering. His article on the 15 principles of software engineering actually includes 30 principles. He later published a book titled 201 Principles of Software Development. Here we will introduce only the 15 “most important principles” as Davis saw them.

1. Make quality number 1: It is shortsightedness to deliver a product that is of poor quality. Quality has many definitions and means different things to different constituents. For example, to the developer, it may mean “elegant design,” and to the customers it may mean “good response time.” In any case, quality must be viewed as the first requirement.

2. High-quality software is possible: Large software systems can be built with good quality, although it may carry a high price.

3. Give products to customers early: It is very difficult to completely understand and capture the users’ needs during the requirements phase; thus it is more effective to give the users a prototype of the product and let them play with it. Gather the feedback and then go into full-scale development of the product.

4. Determine the problem before writing the requirements: Before the software engineers rush to offer the solution, ensure that the problem is well understood. Then explore the potential solution and various alternatives.

5. Evaluate design alternatives: After the requirements are understood and agreed on, explore a variety of design architecture and related algorithms. Ensure that the selected design and algorithms are the best match to satisfy the goals of the requirement.

6. Use an appropriate process model: Since there is no universal process model that applies to all projects, each project must select a process that best fits the project based on parameters such as corporate culture, project circumstances, user expectations and requirements volatility, and resource experiences.

7. Use different languages for different phases: No one single language is optimal for all phases of software development. Therefore select the best methodology and language for the different phases of software development. The difficulty in transition from one phase to another is not necessarily solved by using a single language across all phases.

8. Minimize intellectual distance: It is easier to create the solution if the distance between the real-world problem and the computerized solution to that problem is minimized. That is, the software solution structure needs to be as close as possible to the real-world problem structure.

9. Put technique before tools: Before using the tool, the technique needs to be well understood. Otherwise, the tool just rushes us into performing the wrong thing faster.

10. Get it right before you make it faster: It is essential to make the software execute correctly first and then work on improving it. Do not worry about optimization for either execution speed or code during initial coding.

11. Inspect code: Inspection as first proposed by IBM’s Mike Fagan is a much better way to find errors than testing. Some early data in inspections showed a reduction of 50% to 90% of the time-to-test.

12. Good management is more important than good technology: A good manager can produce extraordinary results even with limited resources. Even the best technology cannot compensate for terrible management because it cannot motivate the people as good mangers can.

13. People are the key to success: Software is a labor-intensive profession, and people with experience, talent, and appropriate drive are the key. The right people can overcome many of the shortcomings in process, methodology, or tools. There is no substitute for quality people.

14. Follow with care: Be careful in adopting tools, process, methodology, and so on. Do not follow just because someone else is doing it or using it. Run some experiments before making a major commitment.

15. Take responsibility: If you developed the system, then you should take responsibility to do it right. Blaming the failure or the problem on others, on the schedule, or on the process is irresponsible.