Novice-Expert Pair Coaching (NEPC) is an approach to synchronously teach programming online. A computer programming educator (the expert) and an individual without prior programming experience (the novice) team up while students observe as the novice learns to code. We call NEPC a 'do-aloud,' technique, as the novice verbalizes while carrying out the expert's instructions. This approach was developed to teach Python to rising 8th and 9th grade girls using Zoom. The novice assertively asked clarifying questions, experimented with newly-learned knowledge, and confirmed her new understandings. By being public learners, the novice modeled active learning, and the expert improved his teaching after learning of ambiguity and gaps in his instructions.

This session is intended as a fun and highly interactive way for college and high school teachers to increase their familiarity with the ACM Code of Ethics and Professional Conduct. Using a quiz show format, participants will be asked to provide solutions to knotty (and sometimes humorous) ethical challenges. This will be followed by think-pair-share (so that everyone gets involved), and then a presentation of the relevant sections of the ACM Code of Ethics and Professional Conduct. Members of the ACM's Committee on Professional Ethics will be on hand to collect feedback and questions about the Code, for use by the Code 2018 task force, and for the "Ask an Ethicist" feature at http://ethics.acm.org.

We consider machines that have the ability to masquerade as human in the context of Floridi's information ethics and artificial evil. We analyse a variety of different robots and contexts and the ethical implications for the development of such robots. We demonstrate numerous concerns that arise due to the ambiguity introduced by masquerading machines, suggesting a need for careful consideration regarding the development of masquerading robots.

We report on some initial findings of an investigation into current practices in, and the need for, information/computer ethics curricula at the graduate level. We give some results and analysis from a survey of faculty and graduate students at four diverse U.S. institutions. Faculty and students agree that students will face professional ethical challenges after graduation, but assessment of students' preparedness for these challenges differs widely across the surveyed institutions. A clear majority of faculty and students expressed support for an elective graduate-level ethics course, and roughly half supported a required graduate-level ethics course.

Summary form only given. The Poynter Center for the Study of Ethics and American Institutions held a workshop on 3-4 March 2010 on the topic of "Ethical Guidance for Research and Application of Pervasive and Autonomous Information Technology." (PAIT) The workshop of about 40 people was supported by the National Science Foundation (grant number SES-0848097)[1]. Ken Pimple of the Poynter Center was the director of the workshop, and Brian Schrag, also of the Center, was the codirector. During the meeting, Ken suggested a set of principles that could be used to better understand PAIT. Keith Miller was one of the participants interested in working on principles. However, Keith thought that establishing principles for computing artifacts in general (not just PAIT) was necessary before more specific principles for PAIT could be established. To that end, Keith starting writing what he hoped would be a short document, entitled "Moral Responsibility for Computing Artifacts." Early on, he asked Deborah Johnson, Chuck Huff and Joe Herkert (all of whom attended PAIT) for their opinions on the first drafts. Not long after the PAIT workshop, Keith sent a draft of what he joking called the "manifesto" (a joke that referenced the Manifesto for Agile Software Development [1]) to Ken. For several months, the number of people adding suggestions to various drafts of the document grew. By May 2010, in addition to Chuck, Deborah, Joe, Ken and Keith, the group included Colin Allen, Helen Nissenbaum, Noel Sharkey and Wendell Wallach (all of whom attended PAIT) and Jim Moor. On 30 May 2010, Keith sent out Version 19 of the document to the entire list of PAIT attendees, and on 28 July 2010 Keith sent out Version 22 to 77 people, many of whom had not attended PAIT. The plan is to allow the document to evolve as more and more people are invited to comment on the document, and to "sign on." The first version tried to set out "principles" for moral responsibility for computing artifacts, and included two principles. The next version talked about "rules" instead of principles, and there were three rules. The current version (Version 27) includes five rules [3]. In addition to the rules and their explanation, the document includes "meta-rules" about how the document can change. The document is designed to be a continuing work-in-progress, under the control of people willing to sign on to the document. The process uses a "coordinator” who is in charge of receiving suggestions for changes, combining these suggestions into new versions, and sending the versions out to the people currently "signed on." In order to simplify citations to the document, the "signers" are now called "The Ad Hoc Committee on Responsible Computing." By the nature of their work, academics in general and philosophers in particular do not always emphasize things on which they agree. This document started as an attempt to contravene that trend, at least for a moment, in order to make a statement about moral responsibility for computing artifacts. Because The Rules are not exactly a code of ethics, there are questions about their authority. The Rules are not a wiki, but they are a collaborative, Web-based project. The issue of responsibility is central to The Rules, but that concept is controversial in general, and it is particularly controversial with respect to computing. In this panel, the participants will discuss these aspects of The Rules, and its effect so far on the signers and others.

In this paper we use Levels of Abstraction and an object-oriented model of trust to analyze quantum computing and cloud computing to identify important ethical concerns. The method of Levels of Abstraction aids in identifying broad social concerns of both methods of computation. Both methods of computation have the potential to deeply impact societal trust of computing.

This paper uses examples of realistic, ethically-charged decisions that computing professionals face, and explore how the the software engineering code of ethics is useful in making wise and creative decisions. We illustrate the ethical impacts of choice of software process model, architecture, and design patterns using real world examples including examples from Grady Booch. We practice some of the ethics training techniques that have successfully been used by some corporations in the computer-related industries.

Julian Dibbell reported a "rape in cyberspace" in 1993. In this paper we use the case to explore the moral nature of actions in virtual environments. We emphasize the themes of harm and responsibility and conclude with some tentative lessons learned, and extend the analysis to virtual sex.

Computer ethics courses differ from technical courses in the manner in which they are taught and assessed. A common assignment in a computer ethics course is to write an essay that addresses a technical dilemma. Computer science faculty typically do not have training or experience in grading essays. The purpose of this paper is to present a scoring rubric that has been successfully used to grade and track students' knowledge development as they progress through a computer ethics course. Although this paper focuses upon a specific rubric, general principles will be emphasized to show how scoring rubrics can be used across different courses.

Open source software is making a large impact on many aspects of society including the business community, the computing industry, the entertainment industry and higher education. The computer science education community has been quiet about issues of open source versus closed source and the role of open source code in the advancement of information technology. A survey of recent issues of SIGCSE Bulletin and SIGCSE conference proceedings shows little attention to the role open source software should play in computer science education. We are here to raise the question: "What are the social and ethical responsibilities of computer science faculty regarding open source software?"One set of issues concerns the use of open source software in teaching and the use of open source development models in the teaching of software development. Some basic questions that arise include "Should analysis of open source (and possible contributions to it) be the subject of class assignments?" and "Should open source software development models be taught?"A second set of issues concerns the use of open source software in support of teaching (e.g., using Linux as your standard platform). Some basic questions that arise include "Should we use open source software to support teaching?" and "Are these faculty ethically obligated to make contributions to the open source software base?"In this panel we will identify many of the parties involved in the ethical and social issues surrounding the use of open source in teaching and in the support of teaching, and we will identify the rights and responsibilities we, as faculty, have to the various parties. This panel will initiate a discussion that will identify additional parties and our further professional obligations.

The paper turns the concept of input distributions on its head to exploit inverse input distributions. Although such distributions are not always true mathematical inverses, they do capture an intuitive property: inputs that have high frequencies in the original distribution will have low frequencies in the inverse distribution, and vice versa. We can use the inverse distribution in several different quality checks during development. We provide a fault based (fault injection) method to determine minimum time to failure and mean time to failure for software systems under normal operational and non normal operational conditions (meaning rare but legal events). In our calculations, we consider how various programmer faults, design errors, and incoming hardware failures are expected to impact the observability of the software system.

Assertions that are placed at each statement in a program can automatically monitor the internal computations of a program execution. However, the advantages of universal assertions come at a cost. A program with such extensive internal instrumentation will be slower than the same program without the instrumentation. Some of the assertions may be redundant. The task of instrumenting the code with correct assertions at each location is burdensome, and there is no guarantee that the assertions themselves will be correct. We advocate a middle ground between no assertions at all (the most common practice) and the theoretical ideal of assertions at every location. Our compromise is to place assertions only at locations where traditional testing is unlikely to uncover software faults. One type of testability measurement, sensitivity analysis, identifies locations where testing is unlikely to be effective.>

The authors present a software engineering technique called sensitivity analysis that aims at producing software that is less likely to hide faults. When sensitivity analysis indicates that faults are not likely to hide from testing, they can more comfortably rely on the results of testing. Sensitivity analysis has been automated, and preliminary results from the automated analysis suggest that the technique will have significant advantages for the development, validation, and regulation of medical devices.>

Software testability is the tendency of code to reveal existing faults during random testing. This paper proposes to take software testability predictions into account throughout the development process. These predictions can be made from formal specifications, design documents, and the code itself. The insight provided by software testability is valuable during design, coding, testing and quality assurance. The authors believe that software testability analysis can play a crucial role in quantifying the likelihood that faults are not hiding, after the testing does not result in any failures for the current version.>

Abstract ‘Propagation, infection, and execution analysis’ (termed PIE) is used for predicting where faults can more easily hide in software. To make such predictions, programs are dynamically executed with test cases, and information concerning the test cases is collected into a histogram, each bin of which represents a single test case. The score in a bin predicts the likelihood that the test case will reveal a fault through the production of a failure (if a fault exists in the set of program locations that the test case executes). Preliminary experiments using program mutations suggest that the histogram technique presented in this paper can rank test cases according to their fault revealing ability.

Formulas for estimating the probability of failure when testing reveals no errors are introduced. These formulas incorporate random testing results, information about the input distribution; and prior assumptions about the probability of failure of the software. The formulas are not restricted to equally likely input distributions, and the probability of failure estimate can be adjusted when assumptions about the input distribution change. The formulas are based on a discrete sample space statistical model of software and include Bayesian prior assumptions. Reusable software and software in life-critical applications are particularly appropriate candidates for this type of analysis.>

No abstract available.

The principles of data abstraction facilitate maintenance and enhance software reliability. However, FORTRAN includes features that undermine data abstraction. A FORTRAN preprocessor called FAD enforces data abstraction when reusing FORTRAN-callable subprograms. Using FAD, reusable software is organized as the implementation of abstract data types (ADTs). FAD users access the reusable software by declarations and subprogram invocations based on the ADTs. The FAD preprocessor translates ADT references into FORTRAN code and prohibits inappropriate manipulation of ADT instances. With the FAD system, ADT implementations can be changed without changing FORTRAN code that uses the ADTs. A maintenance strategy using FAD facilitates detailed control of reusable software.>

Data abstraction is an effective tool in the design of complex systems, and the representation independence it provides is a key factor in the maintenance and adaptation of software systems. This paper describes a system development methodology based on the development of hierarchies of abstract data types (ADT's). The methodology preserves a high degree of representation independence throughout both the design and implementation of complex systems. The methodology is illustrated with examples from the design and implementation of a Vision Research Programming System. These examples include ADT specifications, ADT interface specifications, and partial implementation code for the system in two different programming languages, Ada1 and Fortran.