AUTHOR
ABSTRACT
In addressing professional ethics in computing much has been said about the ethics of software project management (Rogerson) and about ethical issues in the development of software (Rogerson & Gotterbarn). In spite of this work, there remains a significant gap in the coverage of ethical issues in software development. Software developers have focused on the possible sequences of steps in the development of software. They have defined frameworks, patterns, and specified different life cycles. One can say that software project management monitors and negotiates working through these frameworks and code and design is primarily about the details of the process. The choice of software development model, however, has significant and overlooked ethical impacts which are at least as important to address as the way one works through or manages the chosen process.
I first briefly define some common process models and their particular roles in software development. The choice of process model is one of those remaining decisions in software development which are characterized as a purely technical decision. The claim is that the choice of development process is guided (mandated) by the kind of software being developed and the environment in which it is developed. Text books provide checklists for the developer to review in determining which model is best for a particular project. The deciding questions include: Is there a clear set of requirements? Are the requirements likely to change? Has the developer done this type of project before? Can the customer afford a long development process? What is our budget? What are the political ramifications of the modification of the software?
When choosing a development methodology the only hint that ethics may be involved in the decision occurs when the software is labelled as ‘safety-critical’. If the software to be developed can clearly and obviously be labelled as safety-critical then the software requirements may be more precisely specified and testing will be specialized, and torte and liability issues for the developer will also be identified. But even for these safety-critical projects the ethical issues of the choice of development process are not examined from an ethical standpoint.
The answer to these questions and the choice of a model can have a long term effect. Whole software organizations have been built around the choice of a process model. This extends the choice of a model beyond a particular project to all projects developed by that organization. For example, in the 1990’s NASA adopted a development model they called “Faster, Better, Cheaper” (FBC) It was to be their model for software development for all projects through 2005.
Using specific recent software development examples -NASA Space Missions, the Columbia disaster, and US experience with electronic vote counting machines – several types of social and ethical impacts of these methodologies are identified.
A major contributing factor to these problems in process choice can be seen by the narrow scope of those stakeholders considered during process choice. Currently, the choice of a framework and the elements of a framework are directed toward what happens within the framework and how it is addressed by and effects the developer and the customer. It is paradoxical that these tools- designed to reduce risk- are grounded in the same narrow stakeholder focus which has been documented as a major cause of project failure.
This paper has three major points. First is the claim that the choice of software process model does not address significant ethical issues. Specific examples are used to support this claim and show identify some of those issues. Second, two current attempts to address these kinds of risk are not satisfactory. The first unsatisfactory approach is UCITA, a proposed law in the USA which transfers the risk by legislation to the user. The developer is not held legally responsible for software errors and negative impacts of the software even if the problems were a direct result of the development methodology. The other unsatisfactory approach is a process called SoDIS. This process looks at software development details but does not address the issues of process choice. It merely asks “Has a development methodology been picked?” This is especially interesting since the SoDIS process is designed to broaden the scope of stakeholders considered in software development. It does not, however, address the failure to broaden the scope of stakeholders considered in the choice of development process. Third, although the primary goal of the paper is to bring the ethical problems of process choice into focus, potential strategies to address these issues will be discussed.