A Software Development Solution


David H. Gleason
Information Ethics, Inc.


This paper will address issues of software engineering and systems development and the relationship between quality, risk and ethics.

For small to medium-sized software projects, basic project management (PM) principles and attention to subsumption ethics can significantly reduce the risk of project failure. Software project management that applies stakeholder impact analysis (SIA) within the framework of the IEEE/ACM Software Engineering Code of Ethics and Professional Practice (SECode) further reduces risk and, indeed, results in better software. A tool is soon becoming available to apply both basic project management techniques and ethical impact analysis to software development projects.

This paper will use three case studies to demonstrate the effectiveness of these techniques. It will suggest how PM practices and SIA can help mitigate problems. It will further suggest that the SIA soon to be available in the Software Development Impact Statement (SoDIS) Project Auditor, under development by Don Gotterbarn and Simon Rogerson, might have changed the two project failures into exemplars. It will show how the technique was used successfully in the third project

A. Software Success and Failure
In order to succeed at the most basic level, software must meet operational objectives and be timely and affordable. To excel, software must also have a net positive effect on stakeholders. The following three case studies will be used to illustrate the value of PM and SIA.

  1. A dotcom startup transitioning from its original operating software to a web-based application hired a prominent firm to develop the system. Basic project management practices were not followed, and the project a) ran almost four times its original budget of $850K; b) was almost a year late; c) required multiple reworks of the original software to keep it operating and d) resulted in subsumed objects that were so faulty as to make maintenance cost prohibitive.
  2. Another dotcom startup that followed basic PM principles, but did no stakeholder analysis, failed to correctly predict the cost of website development. The project went three times over its original budget of $150K, although the outcome was highly functional.
  3. A helpdesk and IT Inventory application that followed both PM principles and SIA was developed in two person-days that exceeded expectations.

B. Ethical Impact analysis

  1. Stakeholder Impact Analysis

    Project stakeholders can be broadly defined to include those directly and indirectly affected by both the project and its products. Ideally, the impact of subsumed objects in software development should be assessed for each stakeholder. This method ensures that the subsumed objects in the product will not adversely affect stakeholders. The method requires PM techniques, broad stakeholder identification, application of ethical principles and attention to subsumption ethics.

  2. Subsumption Ethics

    Subsumption ethics is the process by which decisions become incorporated into the operation of information technology (IT) systems, and subsequently forgotten. IT systems, by nature, repeat operations over and over. If those operations have unethical impacts, the system will continue to execute them anyway. Unlike a human operator, there is no point in the cycle where the machine pauses to ask, “Should I do this?”

The first axiom of subsumption ethics states that “information systems subsume design, policy and implementation decisions in programming code and content. Code segments and content become ‘subsumed objects.’ While it is demonstrable that systems are built from subsumed components, it is less easy to show exactly how decisions are subsumed. This axiom posits that the decisions themselves, including many subtle factors, are incorporated into systems operation.”

C. Enhanced Project Management
Most software development failures occur at the basic PM level, resulting in low-quality subsumed objects. At this level code of ethics questions are not meaningful. Only if a project already has basic PM will the SECode questions be of utmost value.

Moreover, there is great value to be gained by applying basic PM questions within the framework of stakeholder analysis and WBS/Project outline. Users can be asked questions as simple as: do you have a budget? Are your specifications clear? Do the developers have experience in the technologies being used? Is there a project plan? At the same time, they will be guided through stakeholder analysis, a process which never occurs to most developers.

Finally, a basic project management question set in conjunction with SIA is extremely appealing to a wide range of users and developers. From a marketing perspective, it enables broad distribution of development tools with the code of ethics already built-in. Once users are familiar with the basic functionality, they can move naturally to using the code, with a low barrier to entry.

D. Tools
Don Gotterbarn and Simon Rogerson have enhanced their work on SoDIS to include a software tool for project auditing. This tool both addresses basic questions and also provides a framework for SIA based on the SECode.

On paper, SoDIS is the result of careful analysis of software development activities on identified stakeholders. It applies a set of ethical questions derived from the SECode to work breakdown structures (project task outlines) and stakeholders. By exploring the impact of each task in software development to relevant stakeholders, SoDIS seeks at minimum to avoid reworking software after its completion. At its best, the SoDIS process, can help produce exemplary software.

The SoDIS software under development has three modes: Feasibility analysis; Requirements Analysis and Detailed Analysis. Feasibility Analysis applies basic PM principles to software under consideration. Requirements Analysis identifies major project risks. Detailed analysis applies the SECode principles to each task in the WBS for relevant stakeholders.

When all three modes are used, the failures of both the first and second case studies above can be avoided. Ultimately, this approach can produce better software.