ETHICAL ISSUES

There is always a lot of pressure during the requirements portion of the software devel- opment process. Every software project manager wants his or her project to produce a high-quality system that is completed on time and within budget. Every commonly used approach to software development depends on obtaining a number of correct requirements

TABLE 3.8 Decision Table for the State Diagram Shown in Figure 3.9

Current State Input New State

1 B 2 2 if temp < = 250 3 3 R 4 4 if temp > = 300 5 5 H 5 5 if temp > = 300 7 5 if temp > = 400 9 5 anything else 6 6 if temp < = 250 5

7 anything but temp > = 400 8

7 if temp > = 400 9

8 P 9

8 S 1

FIGURE 3.10 Some Petri nets with none of their transitions enabled.

FIGURE 3.11 Some Petri nets with all their transitions enabled.

that comprise at least a relatively large subset of the final requirements. Without this, the software development is certain to be inefficient at best.

What does this mean for the requirements-gathering process? It is tempting to rush through requirements (and the later design process) in order to begin coding the software. In iterative approaches, this can be acceptable, provided that few of the requirements are actually incorrect. It is less satisfactory for software development that is based on the clas- sical waterfall method. In short, incomplete requirements are acceptable as long as there is a general understanding that the requirements are incomplete, and that they can be made relatively complete with reasonable expenditures of effort.

What is clearly not acceptable is presenting a set of requirements as being correct when they are known to be incorrect. The incorrectness can arise from any of the following:

• Some computations are theoretically impossible.

• Some interactions with different subsystems are inconsistent within the software itself.

• Some interactions are inconsistent with software systems with which the software is intended to be interoperable.

• There may be impossible performance demands on the software’s execution time or space requirements.

These types of errors in system requirements are a serious matter. Consider the problem of determining a user’s password from its encrypted version. On the Linux and UNIX operating systems, only an encrypted version of the user’s password is stored in a password file. The algorithm for encrypting the password uses what are called “one-way functions.” Such functions do not have inverses and, therefore, the password cannot be recovered from the encrypted version. When a user attempts to log on, he or she is prompted for a pass- word. The purported password is run through the one-way function for encryption and the result is matched against the previously encrypted version in the password file. If the two encrypted password versions agree, the user is allowed to log on. Otherwise, the login fails and the potential user is notified of that failure. On modern Linux and UNIX systems, the password file is not readable by ordinary users and, thus, the passwords are theoretically completely secure. Clearly, a requirement to recover a user’s password from the encrypted version in a Linux or UNIX password file is theoretically impossible.

(Technically, the conclusion of the previous paragraph is not correct. A user with essentially unlimited time and unrestricted access could try all one character passwords, then all two character passwords, and so on until he or she either discovered the pass- word or died of old age. A word to the wise: use long passwords with embedded non- alphabetical characters and few recognizable names, dates, or initials as part of your password.)

As another example, consider the problem of developing software for an emergency tele- phone system that will be used to track the phone numbers and addresses when emergency

calls are made. The 911 telephone system in the United States is a typical example. In every area code, there is a maximum of 107 _{possible seven-digit telephone numbers. It is easy to}

trace the signal of a caller to the emergency telephone service. Indeed, such calls are never terminated, even if the calling party hangs up or is disconnected.

Determining the location of the telephone is another matter. Here is a description of the process for landlines that I encountered when reactivating a landline to a condominium in a resort community that had no obvious street addresses. Matching an address to a tele- phone number is effectively a sequential search, and this is not feasible if the system is to respond within proper time limits. Thus the matching of telephone numbers to addresses is generally done one time, before 911 emergency telephone service is installed. In fact, this information has been available for many years in what is known as a “cross directory.” The preexistence of such a cross directory, or creation of one if it does not exist already, should be part of the requirements for an emergency telephone system. Otherwise, the require- ments are not feasible because of the time needed to search the pairs of telephone numbers and addresses.

For cell phones, smart or otherwise, the position is usually found by triangulation, somewhat similar to the way that a GPS functions.

Preventing internal software incompatibility is the responsibility of the project team, and no incompatibility problems should be set by the requirements team. An example of this type of problem is requiring two different components of the system to write to memory buffers at the same location without control. Using the address of the start of a printer’s buffer queue for storage of intermediate results in a desktop calculator program on a personal computer is an example of this problem.

External compatibility problems with interoperable software are much harder to detect. The user of COTS software often has to know which ports are being written to or which names are used for binding socket descriptors to locations. A typical example of this unwanted interference between software subsystems might be an existing system that runs on a Linux version and assumed that all relevant files were on the /usr file system. This can cause problems for another software application that used some of the same files and expected that the common files would be on the /var or /usr2 file systems.

A recent examination of the computer listings in the help wanted section of the

Washington Post showed several jobs in the area of COTS. Industry is beginning to rec- ognize the importance of avoiding such conflicts. Of course, an in-depth knowledge of both the COTS product and the software’s application domain are necessary before one can predict with any confidence that no such conflicts occur. Clearly there are ethical con- siderations in assessing the appropriateness of COTS products as solutions to a system’s requirements.

The IEEE Code of Ethics, IEEE Policy Number 7.8, is very informative in this regard. It is posted at the website http://www.ieee.org/about/corporate/governance/p7-8.html.

For completeness, this code is listed next. Note the guidelines for taking responsibil- ity when making technical decisions described in item 1 and the need for constant retraining described in item 6.

We, the members of the IEEE, in recognition of the importance of technologies in affecting the quality of life throughout the world, and in accepting a personal obligation to our profession, its members and the communities we serve, do hereby commit ourselves to the highest ethical and professional conduct and agree:

1. to accept responsibility in making engineering decisions consistent with the safety, health, and welfare of the public, and to disclose promptly factors that might endanger the public or the environment;

2. to avoid real or perceived conflicts of interest whenever possible, and to dis- close them to affected parties when they exist;

3. to be honest and realistic in stating claims or estimates based on available data; 4. to reject bribery in all its forms;

5. to improve the understanding of technology, its appropriate application, and potential consequences;

6. to maintain and improve our technical competence and to undertake techno- logical tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations;

7. to seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors, and to credit promptly the contributions of others;

8. to treat fairly all persons regardless of such factors as race, religion, gender, disability, age, or national origin;

9. to avoid injuring others, their property, reputation, or employment by false or malicious action;

10. to assist colleagues and co-workers in their professional development and to support them in following this code of ethics.

The rest of this section is the author’s personal opinion of the ethical issues involved with the software requirements process.

What should you do if you are involved with the requirements-gathering team and the requirements include one of the potentially fatal flaws? The first step is to check your analysis and make sure that you have not made a mistake. Do not rely too much on hazy recollections of meetings or on courses dimly recalled from college. Being human, students and professors make mistakes. (So, too, do authors of software engineering books, but at least there is the possibility of errors being caught by one or more techni- cal reviewers, as well as by an editor. Authors of books are human, as are some editors and reviewers.)

If you have not made a mistake, consider discussing your concerns informally with a trusted coworker. Be careful about this, because you do not want your ideas presented to someone else as their own. Keep your own detailed notes about the perceived problem.

Perhaps a more direct approach is to make an appointment with your manager to explain the problem and your analysis. Remember that managers hate unpleasant surprises. Do not spring your objection on him or her during the middle of a meeting or during a review with the client or your manager’s upper level management.

What should you do if your manager does not seem to be willing to accept your analy- sis? Go through the technical reasons with him or her again, allowing for the possibility that you were wrong or that you did not explain it well. Pursue the point, perhaps in future public or private meetings, until one of three things happens:

1. The manager does not agree with your analysis.

2. The manager agrees with your analysis and will ask the requirements team to fix the problem.

3. The manager seems to be ignoring the problem, allowing a potentially serious prob- lem to occur.

In the first scenario, you have to consider the possibility that your analysis is wrong, even though you cannot see why. You need to keep a good relationship with this man- ager, even though he or she probably has some reservations about your judgment. Keep your technical skills up to date and begin to consider the possibility of taking another job.

In the second scenario, continue to be prepared. A bonus or promotion may be in your future.

In the third scenario, there is a serious ethical dilemma. In an operational environment in which human lives are at stake, such as in a computerized monitoring system in a hos- pital, control of a railroad, or almost anything in a nuclear power plant, there really is no choice: you must take all necessary actions to prevent what could be a disaster.

The choice is almost as clear if a major financial disaster would occur as a result of using software that is implemented to meet these erroneous requirements. You cannot argue that affecting an unknown person or corporation financially is not sufficient grounds for not adhering to the highest level of personal professional conduct.

In essence, the only way to justify taking little or no further action is to claim that the project is a throwaway research prototype with no possibility of becoming operational. If this is not the case, then you must do what Watts Humphrey (1989) recommends in his classic book Managing the Software Process when an experienced project manager is asked to complete a project with insufficient resources or within too short a time period: resign.

Of course, you must do more. The customer must be made aware of the problem. Unfortunately, whistle-blowers rarely have successful, remunerative careers. Be sure that you are right before taking any drastic action.

Ethical problems will be discussed further in Chapter 6 on software testing.