• Linux Administrator
• 1st / 2nd Level Support
• ASIO Intelligence Analysts
• IT Support Analysts,...
• Data Warehouse Developer / ...

Building ethics into quality assurance

Craig McDonald, Information Age

18/08/2005 12:09:40

Producing good quality systems using good quality processes ought to lead to beneficial outcomes all round and praise for the developers. Blame is deserved for systems failures resulting from carelessness, ignorance, complacency or other irresponsible attitudes.

Praise and blame are hallmarks of ethical judgments, but in systems development they are usually discussed in terms of quality, not ethics.

Perhaps explicitly building ethical principles into quality assurance is a way of both practically implementing aspects of the ACS Code of Ethics and also giving some stronger foundation to quality assurance. We will look at this idea by first considering quality assurance, then ethics and finally, looking at an implementation

First, quality assurance. The quality of the systems we build is determined by the impacts they have on people, organisations and society. "Fitness for Use" is the classic measure of product quality. Conformance with good development practice is the classic measure of process quality. There are standards that can be applied to both the processes and products of systems development.

Quality assured work is "evidence-based". That is, there is evidence that quality of the work has been explicitly defined and measured. Both the process and the product have quality attributes and measurements of these attributes have been recorded. The product itself is testable and the process auditable.

It is said that "if you can't measure it, you can't manage it". But of course not all quality attributes are quantitative. Some of the most important qualities have to do with perceptions and values. Take the quality "fits well with the strategic direction of the organisation"; while this quality attribute cannot be measured, it can be argued for (or against).

A sometimes missed aspect of QA is that "quality" always relates to something specific - there is no such thing as "general" quality. It is always a specific product or process that has "quality" and this quality is ascertained by examining it. Yes, general ideas about what to measure (correctness, modifiability, testability, usability, reliability, efficiency, integrity, reusability, interoperability, etc.) can be useful guides but each product and process needs its own quality criteria.

This proposition leads to the idea that every single product and process needs to have embedded in it the means to assess its own quality. Imagine for instance each object in an object-oriented system having not only its own data and services, but also its own methods of evaluating itself.

Now, turning to ethics, there seem to be three main kinds of discussion about ethics and ICT. The first tackles particular issues, like workplace surveillance or copying software, and examines the ethical principles that might apply to them. Laws are framed from this kind of discussion, so it is critically important.

The second looks at specific events, real or made up. Particular situations throw up unusual ethical aspects and dilemmas that highlight the complexities of ethics. For example, the set of ACS ethics cases reveal the complexities and contradictions that are inherent in ethical considerations of the particular situations we all find ourselves in sometimes (go to http://www.acs.org.au and search for Code).

The final kind of ethical discussion starts from first principles and sees issues and events as applications of ethical principle. For example, if the principle of 'the greatest good for the greatest number' were to be applied to a situation, how would we measure "good", can we add it, how could we balance the good to one person against that to another, etc. Despite such problems, the first principles approach has given us a valuable practical tool for ethical evaluation - stakeholder analysis.

There are different kinds of stakeholders. Those that can terminate the project (financiers and clients) are most obvious. The stake they hold has sometimes been likened to a garden stake - sharp ended and potentially lethal! The next stakeholder is like a gambler who is part of the game, who knows the rules and whose stake is a pile of chips to bet with. Unions, insurance companies, regulators and so on are in this category.

Then there are the victims; they are the ones who are impacted by systems in which they have no say. And lastly the voiceless stakeholders - the society at large, the economy and the environment.

So, it seems that the effects of our systems on our stakeholders is a core idea behind both ethics and quality. Systems developers are at the sharp end of these issues because their work has significant and widespread impacts on others. It is an ethical as well as a quality stance to care about the effects of our actions and to take responsibility for them.

Of course there are limits to what we can be responsible for, especially in complex technical and organisational settings. But if each of us embedded the responsibility idea into our actions the overall quality of systems would improve.

One way to embed both quality and ethics into our systems is to explicitly recognise exactly who will be impacted by the process we are involved in and the product we will deliver. At the University of Canberra we are trying to embed this recognition in our computing education by having students specify quality criteria for each development process and deliverable they engage with. Figure 1 shows the home page of our Project Management Support System (PMSS).

PMSS is used to support our systems development and project management units. It has the usual project facilities for planning and monitoring development, tracking issues and risks, organising meetings and for communication and configuration management.

The system also contains a set of templates for typical project documents. These templates are organised by stakeholder type. The interests and responsibilities of these stakeholders are the key to developers doing work that is both good quality and ethical.

At the start of a project, typical stakeholders include the following: a) The project team itself, which is responsible for the professional conduct of the project and for meeting the needs of the team members; b) The redevelopers, those who have to understand and change the system in the future; c) The system/business owner, who as an investor expects to benefit from the returns the system brings; d) The system's immediate users, who interact directly with the system and who have to adapt to the changes it brings; e) The systems manager responsible for the operations of the technology including security, backups, etc; f) The business manager, who administers the departments in which the system has been implemented.

Of course, as each project is unique, the range of stakeholders diverges rapidly from the typical case. But lessons learned from typical cases transfer easily to new situations.

To implement quality/ethics (QE) in the PMSS, each template has a set of QE criteria built in as the final section of the document. The idea is that every process and every product should have its specific QE criteria made explicit. Figure 2 shows an example of this section from a Process Design Manual.

The Process Design Manual may be created for a business manager and staff to control the workflow for a particular process or work area. The very existence of this template in the PMSS raises the awareness of the student developer that she has to actually consider the workflow and work environment of the people that surround their technical designs. Once the student developer recognises that the business manager and staff deserve explicit consideration, the scene is set for responsible and quality design work.

Yes, the PMSS is set in an educational context. But if asked, could you demonstrate that the last process you undertook was quality and ethically assured? Will the last document you delivered have beneficial impact or was it just an expected response to a clause in your service level agreement?

Quality and ethics go hand in hand. Every time we question the quality or ethics of a process or product we improve the system of which it is a part and we improve our own personal capability to do the right thing. These improvements are not trivial.

Craig McDonald is Associate Professor of Information Systems, University of Canberra