AUTHOR
Stanislaw Szejko (Poland)
ABSTRACT
There is a wide discussion in the community of software users, information system stakeholders as well as researchers, project managers, and developers, on the reasons of software project failures. The failures are typically seen as failing to meet the requirements, over budgeting, exceeding development time or maintenance costs. Infoethics [5] adds violation of the rights of developers, system stakeholders and society.
Preventing the project failures is typically sought in the domain of software development methods and tools, in project management, in requirements engineering, in quality assurance and risk coping strategies. New or modified software development lifecycles are introduced, exploiting quality control [6] , reusability [3] , risk management, or stakeholder identification [1] , as well as maintenance procedures improved [5] .
Software Development Impact Statement (SoDIS) makes a way of addressing the problem of compliance with ethics. The goal of the SoDIS process is to identify significant ways in which the completion of individual tasks may negatively affect stakeholders and to identify additional project tasks or modifications needed to prevent any anticipated problems [2] . This is done in several steps
- extending the domain of stakeholders identification to all individuals and institutions that are related to the project,
- making the related impact analysis according to the tasks of the project preliminary plan,
- incorporating new tasks and modifications that can be used as a means to mediate or avoid the identified concerns into the software project management plan, and auditing them later.
However, a software project means in fact two synergetic efforts: the customer’s process and the supplier’s one. The customer (the buyer) is interested in ordering and getting what he needs, so the main activities of his project include detailing the requirements, validating the sub-products and checking if the product meets the requirements. The supplier is the contractor, or developer, who responds to the buyer for a specific capability [4] . And as the customer and the buyer co-operate in the project but they have their own missions, goals, shareholders, employees and environments, some questions arise:
- is it feasible for the customer to formulate detailed tasks for the developer? what does he know about developer’s stakeholders, the applied technology, software process organisation (the project preliminary plan can be prepared even before the developer is known)? and why should the buyer think of the supplier’s shareholders?
- and vice – versa: why should a project manager (developer’s side) bother about customer’s stakeholders whose requirements are not in the contract? who is going to pay for that? isn’t it against his own share- and stakeholders? can we make him responsible for all ‘future usages’ of the software, intended or not, especially for those that harm customer’s environment or society?
The paper suggests that incorporating ethics into the software process could be viewed as follows:
- impact analysis covering customer’s (buyer’s) stakeholders should be done on the customer’s side and result as in extension of the specified requirements as in new and modified tasks required in the customer’s process, and the project modified plan accordingly;
- tasks and checkpoints that mutually link and interface the two processes from the ethical point of view should be defined (similarly like requirements validation or product evaluation do today); for example, if a feasibility report is delivered by an external company that could be interested in its results itself, a task of independent evaluation of the proposed solutions could be added;
- ethics should be assured in software development process, consisting probably of supplying requirements analysis with impact analysis carried for developer’s stakeholders, planning and adjusting the development process, as well as controlling and verifying the ethics policy in the development process.
The scheme treats impact statement activities as decomposed between the customer’s and the supplier’s processes. This way of incorporating ethics into the software development process renounces a bit idealistic assumption that impact analysis can be done on one side aiming all partners, and its results executed on the other side, once more aiming all partners.
It is very interesting if assuring ethics can follow the ideas and solutions that have been already developed for software quality assurance. For example, it is quite typical to have (developer’s side) an independent Software Quality Assurance Group that adapts and introduces standards, measures and controls quality in order to improve the company software process. How about ethics, shall we strive for Software Ethics Assurance teams?