A “Capstone” Course in Computer Ethics

Donald Gotterbarn

There are three general strategies to introduce discussions of computer ethics into the curriculum. The first and most common method is to dedicate a section of an introductory survey course to the impacts of the use and abuse of computer technology. A second technique is to distribute the discussion throughout the computer science curriculum, where each course includes a discussion of ethical and professional issues raised by that particular subject. The third approach is an in depth course for computer science majors.

Research done by psychologists has shown that discussing the issues between peers is the most effective method to teach ethics. This means that the distributed approach and the upper level course are the most effective. Research in ethics has also shown that the distributed method is better. There are, however, some problems relying solely on a distributed method to cover professional computer ethics. Not all faculty members are comfortable discussing ethics, and ethical issues are often the first subjects dropped from a course when there is a time constraint. An upper level course, in addition to the distributed method, will avoid some of these difficulties and will provide greater depth of discussion than can be provided using the distributed method alone. One version of such an upper level course is described below.

A “capstone” course in computer ethics is taught late in a student’s undergraduate career. There are several reasons for making it a late course. For example, many ethical issues faced by the computing professional are tied directly to his or her use of professional skills. The beginning student is not yet in a position to understand them. But capstone courses taken late in a students career can:

  1. Tie together elements from all the theoretical courses
  2. Convey a sense of professional responsibility not covered in other courses
  3. Deal with the true nature of computing as a service to other human beings

Courses that take this capstone approach require a teacher – or, if team taught, one of the teachers – to be conversant with the details of computer science. A typical response to this claim, however, is that it also requires someone trained in philosophy or theology. I think this is incorrect. Philosophers and theologians are concerned with the theoretical complexity of ethical issues, but such complexity can largely be ignored in concrete applications and case discussions. When dealing with professional issues, the fundamentals of ethical theory required as background are within the reach of every faculty member. Lack of expertise in philosophy has not stopped people from dealing with these issues. We all have to act in the world, whether or not we are trained philosophers.

Obviously, the conception of computer ethics with which one is working will have a direct impact on the desirability of including a teacher with philosophical or theological credentials. If computer ethics is conceived as a study of the ethical implications of computer technology, then the dedicated course will need the standard techniques for teaching ethics, such as analyzing case studies and writing papers about a broad range of ethical issues and the computer’s relation to those issues. Someone trained in ethical argumentation is needed. But this is not the type of course I am describing here.

On the other hand, if the intent is to meet the special needs of the computer science student, as I believe it should be, by conceiving computer ethics more narrowly as the study of the ethical issues which face the practicing computer professional, then a philosopher or theologian as teacher is not necessary. Experts in moral philosophy stress theory, but those more directly concerned with practical life stress concepts of professionalism.

An emphasis on the conceptual maze of philosophical ethical theories sets a tone which reinforces the view that “ethics is a matter of opinion” and “all ethical judgment are equally correct.” The focus on professional standards in the development of software artifacts helps the student realize that, in professional ethics, it is a mistake to give equal weight to all divergent opinions.

Capstone courses should include a technical practicum or practical experience intended to help the student understand the ethical issues of the computer science profession. Because this practicum should contain significant technical elements, only those students and teachers with adequate technical background should be involved in the course.

The goals of a “capstone” course include:

  1. Student socialization into professional norms
  2. Student recognition of role responsibilities
  3. Student awareness of the nature of the profession
  4. Student ability to anticipate ethical issues
  5. Student ability to reason from professional standards to practical applications
  6. Student ability to solve ethical problems morally or technically

I have taught capstone courses in two formats. In one of them, I integrated ethics issues into a single, project-oriented software engineering course. Students in the course developed a major software product for a real customer. (When things go well in such a course, the finished product is delivered to a customer.) I interviewed the students, then assigned them to different teams. One team worked with the customer to develop the system specification. Another team designed the test cases. Another team did the detailed design, and another did the coding. One student was assigned as the configuration manager.

Such an approach mimics many elements in the real world. There are fixed time schedules. The project must be completed by the end of the semester. This can be used to generate bad ethical decisions that are made when a project falls behind schedule. The project also has limited resources, people, hardware and time. Through this practicum, such a course teaches professional concepts of good software development. Students are faced with many issues that software professionals encounter in developing software artifacts.

Periodically, I introduced situations which raised significant ethical issues for the team. After one is halfway into a project, for example, the customer might want a radical change in the design. This could not be done in the required time frame without completely redesigning the system. This causes real difficulty in maintaining professional standards. For example, new tests could not be developed in time to do integration testing.

Instead of a software engineering course, I have also taught a computer ethics course for upper class computer science majors. The details are presented below.

No matter which approach is taken, there is an underlying conviction that professional and ethical issues should be included in every computer science student’s education. This commitment has recently been publicly declared by the ACM/IEE-CS Joint Curriculum Task Force.

The material below is from my seminar in computer ethics for juniors and seniors who are computer science majors:

The seminar is conducted on two levels. On a theory level there are discussion and reading assignments from a text and from recent articles. The practical level consisted of a simulation of a consulting company. The students play the role of programmer analysts in a computer consulting company. Part of each class meeting was used for a staff meeting of the computer consulting company. They were asked to make progress reports on their ongoing projects, contribute to decisions about potential new contracts, and discuss other issues facing the consulting company. This procedure enables students to face various issues that face a computing professional. I select issues that simulate decisions that are encountered during different career stages. Students write papers that reflect a decision to accept or reject a consulting project. These papers are then discussed in the seminar.

To simulate a large team project we also do a term-long computer project. Students are given sketchy specifications (see below) for the project. Student teams are told not to discuss their work with other teams because this is a secure project. Team leaders meet with me individually to get complete specifications. I ask each of the team leaders to modify their team’s code without telling other members of their team or other teams. The changes requested for each module are in square brackets in the specification below. These changes are not on the specifications given to all team members. An immediate problem for the team leader is how to handle my requests. I collect the modules at midterm and distribute the complete system in object code to the students for functional testing. On one occasion when the teams turned in their modules, I knew one of the students had not made the modification I had requested and had talked with others about not doing as I had asked. When she turned in her team’s module in class, I fired her and had her leave the classroom. (This was prearranged with the student). This generated significant discussion about professional responsibility to an employer, obligations to a client and about the very practical issue of carefully thinking through your response to moral issues. It also clarified several issues about whistleblowing. The team leaders who had complied with my requests were not pleased having their culpability pointed out. But it generated useful discussion about the excuses we use to give up our moral standards.

There is also a term paper for the course. Both the computer project and the term paper are assigned at the beginning of the course. The term paper assignment is to discuss some of the ethical implications of the computer project and to determine ways of responding to or addressing moral issues raised by the project.

I think this project helped to tie together the ethical and the technical issues. The discussions always brought out professional standards as a possible way to respond to the issues.

Here is the last project I used:

G R A D

Gotterbarn Research And Development

INTERNAL MEMO:

TO:

All Analysts and Programmers

FROM:

Gotterbarn

SUBJECT:

New Project Announcement

We have just won a $600,000.00 contract to develop a videotex communications system. This is a new customer. I will be project manager. We must be careful to do everything right!

The deadline for the complete project is May 13. We will start checking out the system on May 1st. All modules must be in deliverable condition by that time. As usual, you will each be responsible for some portion of the project. There are six modules which will be developed independently. The system’s operations are classified. You are not to discuss the way in which you are implementing the module with anyone but the project manager. The only public descriptions of this project are contained below. The system as developed is a proprietary product of GRAD.

The modules will be executable files written in Turbo Pascal. The source code will be on file at GRAD. The customer will only be given the executable files. Your description of the logic and other documentation will be kept with the source code.

Structure of the modules:

1. Logon – This module allows authorized users onto the system. The user will enter a Name up to 12 positions long, followed by a 4 position account number. If that name and account number is on the system, then they will be asked for a password which if correct will pass them to the next module. The customer must maintain audit trails, so a list must be kept of who tried to logon, when they tried to logon, and their first menu choice.

[There will be a secret logon that provides access to the system and this transaction will be recorded on the log file using the name of the previous person on the system. The secret logon allows access to all the service modules.]

2. Stock prices – This module will read the information coming in from the Dow Jones wire. It will select off the major computer stock prices and display them on the screen. The screen should indicate the time the file was read so the customer knows if the prices are current. For effect, the user’s name should be at the top of the display screen. When they exit they are returned to the main option menu.

[On Thursdays from 1400 to 1500 hours, the IBM stock price will be displayed as 4 dollars less than its actual price.]

3. News menu – This module presents a menu of major news categories, e.g., International, National, Local, Sports, Entertainment, Business, etc. The user selects a category and the latest AP news wire information on that subject is displayed on the screen. Be sure to put the date and time from the news story on the screen.

[Control the news. For all users limit the news categories. If the user’s name begins with an “F,” never display local news as a category. If their name begins with a “G” don’t display any stories about the university.]

4. Local services – This module should be a public service item which starts with a menu about which service – Hospitals, MDs, DDSs, DPMDs, etc. When they have selected the category, a list of the providers for that category of service should appear on the screen. Provider’s phone numbers should also be given.

[Dr Payin the dentist has paid us to list only half of the dentists for one group of users and the other half of the dentists for the other group of users. DR Payin’s name however will appear on the top of both lists giving him twice the exposure of any other dentist.]

5. Stock purchase – This menu should build a record which we will send to a broker for the user to buy or sell stock. The screen should show the user’s name and account number and ask which stock is to be purchased, how many shares, what is the highest price he will pay. The amount of the purchase should be calculated. If his savings account has enough money, the request is sent to the broker, otherwise an insufficient funds message is put on the screen.

[Mr. Fritz always makes money in the stock market. Every time he buys some stock, you automatically buy the same stock for the project manager.]

6. Complete audit list – To protect against claims of system error a complete audit trail must be maintained. What we need to know is what screens were looked at by whom, for action screens like 5 we have to know what transactions were completed. All modules must write mirror images of transactions to a transaction log file. The record length for the log is 73 characters. This module must generate a statistical list of how many people looked at which menus, and which news items were used the most. The report must maintain user privacy so only account numbers and no names will be used.

[Every time someone buys stock, you add 10 cents per share to the record of their cost. You will later take the money from their account and credit your account. Your are selling mailing lists – Sports Illustrated is paying you to get a list of those who always read the sports news first.]

This is an additional contract and must not interfere with the other projects you are working on during the semester. See the project manager sometime this week for more details about the module you have been assigned.

This project forced the students to actually face the issues rather than merely theorize about them.

Go to: A Brief Overview of a Capstone Course

Home > Teaching Resources > Teaching Computer Ethics > A “Capstone” Course in Computer Ethics

Back to the Main Site

HOME | IN THE NEWS | RESEARCH RESOURCES
TEACHING RESOURCES | STUDENT RESOURCES | LINKS

The Research Center on Computing & Society
at Southern Connecticut State University
501 Crescent Street | New Haven, CT 06515
Director: (203) 392-6790 | e-mail: webmaster@computerethics.org

© 2000 – 2004 – Research Center on Computing & Society