Considered ethical dimension refers to the risk that the developed software products may bring negative impacts on software users, including an entire society. The problem is how to manage that risk.
Risk management process has become the routine subprocess in software development. Its main goal is to prevent software team from the risk that the product under development fails because the term and budget are exhausted. This process is started from the very beginning of software product development. The risk management process will be described briefly in the paper. Its aim is to identify risks and risk factors (elements) that may cause the particular risk is materialized. Probability of each risk element and its possible impact on a product development are assessed. Then plan of mitigating or even avoiding the identified risk is work out. The risk management process is established and the required methods and infrastructure are provided.
There are developed several solutions also in agile methodologies how to manage risk. The problem is what kind of risk and its factors are concerned and managed and what is the aim of such activities. Another approach says how to incorporate ethics in the software process, like SoDIS, for example.
The problem is how to extend the risk management to consider the threats referred to direct and, especially, indirect software users. Indirect software users are affected by a software product, possibly also an expert system, developed for public or business organization. If threats and inconveniences caused by informatization are to be reduced or eliminated, it is necessary to raise the awareness of these threats and to emphasize them in the developers’ community and in the entire society. Some practices introduced by informatization of the public sector seem initially advantageous but they may bring completely undesired side effects.
The experimental risk management system has been developed. The category of guests has been introduced among that system users. They are allowed to introduce the risk factors from their point of view and to extend this way the initially developed list of risk sources. In general, there is a risk that users may be unsatisfied with the product under development. But this statement is too general. Examples of risk elements will be described in the paper. Software developers should be early informed what kind of wasted efforts may result from the developed software system for indirect users. For example, there is a risk that indirect users may complain the software system because they are forced to fulfil a lot of documents or to visit the organisation several times to have their affairs fixed.
One more although indirect source of risk identification is a software product assessment. Software users may be allowed to indicate weak points of the assessed software version and to formulate software improvements from their point of view.
Then all risk factors are analysed and managed. As usually, not all categories of risk sources are available to the guests.
[Agile Manifesto, 2001] Manifesto for Agile Software Development, coauthors: K. Beck, A. Cocburn, M. Fowler, J. Highsmith, R. C. Martin, and others, http://agilemanifesto.org/, Agile Alliance February 2001.
[Ambler, from 2003] Ambler S.: Active Stakeholder Participation, http://www.agilemodeling.com/essays/.
[Begier, 2002a] Begier B., Quality of Goals – A Key to the Human-Oriented Technology, Australian Journal of Information Systems, vol. 9, Number 2, May 2002, pp. 148-154.
[Begier, 2002b] Begier B., Evaluating software quality to regard public interest, Proceedings of the Sixth International Conference “The Transformation of Organisations in the Information Age: Social and Ethical Implications” ETHICOMP 2002, November 13-15, 2002, ISBN 972-8397-44-5, Lisbon (Portugal), pp. 39-52.
[Begier, 2007] Begier B., Involving Users to Improve the Level of Their Satisfaction from a Software Product Designed for Public Organization. In: Technologies for Business Information Systems, Springer Verlag, Dordrecht (Netherlands) 2007, ISBN 978-1-4020-5633-8, s. 365-377.
[Begier, 2009] Begier B., Users’ Involvement May Help Respect Social and Ethical Values and Improve Software Quality, Information Systems Frontiers, Springer US, 2009.
[Friedman, 1997] Friedman B., Human Values and the Design of Computer Technology, Cambridge, Cambridge University Press 1997.
[Gotterbarn, 1999] Gotterbarn D., How the New Software Engineering Code of Ethics Affects You, IEEE Software, November/December 1999, pp. 58-64.
[Gotterbarn, 2001] Gotterbarn D., Enhancing Risks Analysis Using Software Development Impact Statements. In: 26th Annual NASA Goddard Software Engineering Workshop, Greenbelt MD (USA) 2001, pp. 43.
[Highsmith, 2004], Highsmith J., Agile Project Management, Boston, Addison-Wesley 2004.
[Kujala, 2008] Kujala S., Effective user involvement in product development by improving the analysis of user needs, Behaviour & Information Technology, vol. 27, 2008, No. 6, pp. 457-473.
[Martin & Martin, 2007] Martin R. C., Martin M.: Agile Principles, Patterns, and Practices in C#, Indianapolis: Pearson Education and Prentice Hall, 2007.
[Rogerson & Gotterbarn, 1998] Rogerson S., Gotterbarn D., The Ethics of Software Project Management. In: Ethics and information technology, ed. G. Collste, Delhi, India, New Academic Publishers 1998, pp. 137-154.
[Rogerson, 2003] Rogerson S., The ethics of software development project management. In: Computing Ethics and Professional Responsibility (eds. T. W. Bynum & S. Rogerson), London, Blackwell 2003, pp. 94-101.
[SoEnCode] Software Engineering Code of Ethics and Professional Practice, v. 5.2, IEEE & CS/ACM, 1999, http://www.acm.org/serving/se/code.htm (access: 2000-2006).
[Szejko, 2002] Szejko St., Incorporating Ethics into the Software Process, Proceedings of the Sixth International Conference “The Transformation of Organisations in the Information Age: Social and Ethical Implications” ETHICOMP 2002, 13-15 November 2002, Lisbon, Portugal, pp. 271-279.
[Tiwana i Keil, 2006] Tiwana A., Keil M., Functionality Risk In Information Systems Development: An Empirical Investigation, IEEE Transactions on Engineering Management, vol. 53 (2006), No. 3, pp. 412-425.