Keywords

1 Software Process Improvement

1.1 Managing the Software Process

Industry, commerce and government have come to the recognition that the application of new software methodologies and technologies have not realised the anticipated gains in productivity and quality. Organisations encounter problems of developing high quality software for their customers. O’Regan (2011) numerates these difficulties as typically concerning: budget and schedule overruns; late delivery of the software; spiralling costs; problems with the quality of the delivered software; customer complaints with regards to the functioning of the software, and staff morale.

Information systems and IT projects have been failing regularly with dire consequences financial and safety consequences. The CHAOS Reports which have been published every year since 1994 provide a snapshot of the state of the software development industry. The 2015 report studied 50,000 projects around the world, ranging from tiny enhancements to massive systems re-engineering implementations. The 2015 results indicate that there is some improvement but still a lot of work to be done around achieving successful outcomes from software development projects. Table 1 summarises the outcomes of IT projects from 2011 to 2015 using the new definition of success factors (on time, on budget with a satisfactory result). A trend from previous reports that continued in the latest survey is how smaller projects have a much higher likelihood of success than larger ones, as shown in this table.

Table 1. Percentages of IT projects outcomes (extract from The CHAOS Report 2015)
Full size table

Challenged and failed projects together account for between 78 to 83% of waste and in the cases of safety critical systems (Logothetis and Wynn 1989; Barbor and Georgiadou 2002; Dalcher 2017) the loss is not only financial but also harmful and general social loss (examples: Challenger Disaster, Cancer treatment in Bristol – radiotherapy, Taurus System). Additionally, lost opportunities through lack of access to new technologies are immeasurable for companies and society at large. Studies by many researchers such as Hirschheim and Newman (1988); Dalcher (2005); Dwivedi et al. (2015) identified the main reasons for systems and projects failures. Although failures are often attributed to technical faults and errors it has long been recognised that by far the most serious reasons for these failures and deficiencies have invariably been identified as political, social, cultural, legal and organisational settings and behaviours.

For example attitudes and practices to knowledge sharing and maturity of process have profound impact on the performance of an organisation. As described by Georgiadou et al. (2011) at the Innovative/Improving level the process is characterised by optimisability and continuous improvement. At this highest level of process maturity, knowledge sharing is institutionalised and quantitative. Improvements are achieved from continuous feedback, across teams, within and across projects and across the whole organisation. It is expected that an innovative process requires that all team members understand, embrace and practice the philosophy of knowledge sharing and processes are continuously improving and innovative ideas of all employees find fertile ground. It is expected that an innovative process requires that all team members understand, embrace and practice the philosophy of knowledge sharing and processes are continuously improving and innovative ideas of all employees find fertile ground.

1.2 The Social Dimension of Process Improvement

The field of Social Responsibility (SR) has grown significantly the last decade, both in diffusion scale and in importance. The publication of the ISO26000:2010 voluntary guide, launched in November 2010, and the ECQA Certified Social Responsibility Manager job-roleFootnote 1 created by the SOCIRES project and supported by the European Union through the Leonardo da Vinci Programme, are proofs of this. The ISO 26000:2010 standard aims to provide guidance regarding SR issues that any organisation (private and public) needs to address.

Despite the fact that there are divergences in the definitions of SR, all definitions seem to have in common the idea of businesses making a decision to commit to social and environmental issues beyond their legal obligations (Siakas et al. 2012). In practice, organisations select their approach to SR by using their own lenses, being influenced by factors at national, regional, industrial and organisational levels. This lack of a unified definition of SR impedes a cohesive empirical SR viewpoint. As a result, SR cannot be measured effectively nor can conclusive findings be pronounced (Siakas et al. 2012). To diminish these inadequacies numerous reporting and ranking instruments (see for example http://asklib.library.hbs.edu/faq/47472) have been developed aiming to compare SR activities of companies. Web sites can also be used to gain insight on how companies are valorising their SR policies (Zompras and Siakas 2014; Garre-Rubio et al. 2012).

The standard is expected to add value to existing initiatives regarding SR by providing harmonised and globally relevant guidance based on international consensus among expert representatives of main stakeholder groups (Koinig et al. 2011). That guidance can then be implemented through appropriate processes and thus becomes subject to process improvement as any other process improvement (Garre-Rubio et al. 2012). The potential benefits an organisation can gain by applying SR practices are amongst others, increased corporate reputation and minimised conflicts with primary stakeholder groups. The performance of an organisation in relation to the society it operates within and the impact it has on the environment has lately become an important indicator of its overall performance and its sustainability (Koinig et al. 2011). Linking SR and SPI processes requires a consideration of SR as a dimension in every process area in the organisation. This requires critical creation of SR-specific Key Performance Indicators (KPIs) for measuring the results of continuous improvement of the strategic performance and actions. Instead of mixing the KPIs with other business indicators, SR indicators should ideally be associated to ISO 26000 core issues and process areas.

To successfully implement SR in organisations, a synergy between organisational strategy and supporting the social rights of individuals at the same time is required, thus supporting SR issues as an integral part of an organisation’s mission and objectives. The relation between SPI and SR concerns are apparent in some areas, but a detailed examination of the interaction between SPI and SR is required for a full understanding of these. A mapping between SPI and SR based on the SPI Manifesto and the ISO 26000:2010 standard was made by Messnarz et al. (2013). Interactions in both directions were found, which suggests that SR concerns should be considered an integral part of SPI.

Creativity and innovation are the lifeblood of competitive organisations. Organisations that do not innovate and do not adapt to rapidly changing environments (economic, social, political, environmental, and technical) are less likely to be sustainable. However, some ethical constraints may stifle innovation. A dichotomy between innovation and ethics is likely to arise either when the innovation itself or its use is unethical. Farjoun (2010) and Schumacher and Wasieleski (2013) suggested that ethical control mechanisms enable long-term innovation whilst unethical innovation is exclusively short-term which suspends the ethical dimension. Ethical formalisation helps manage turbulent environments whilst unethical innovation is taken as a unique value to be implemented to the classical moral values.

1.3 Process Improvement Models and Methods

There has been an acknowledgement that the central problem is the inability to manage the software process. There have been a number of software process improvement efforts. Amongst a plethora of proprietary Software Process Improvement (SPI)’s from consulting firms, some notable software process improvement standards and models include:

  • The Capability Maturity Model Integration [CMMI], the successor to the older CMM, developed at Carnegie Mellon University (CMMI 2010);

  • The International Standards Organisation’s 9001 Specification [ISO 9001] (ISO 2016);

  • The ISO/IEC 15504 IT Process Assessment, which is also termed Software Process Improvement and Capability Determination [SPICE] (ISO 2012);

  • Six Sigma, the data driven leadership approach (Pyzdek 2003);

  • The 730-2014 IEEE Standard for Software Quality Assurance Processes, which establishes the requirements for initiating, planning, controlling, and executing the Software Quality Assurance processes of a software development or maintenance project (IEEE 2014).

Core to each of these improvement efforts is the idea of a focused and sustained effort towards building a process infrastructure of effective software engineering and management practices. The software process improvement strategy is to transform the prevailing approach to software development into something that is more focused, more repeatable, and more reliable, with regards to the quality of the product manufactured and the timeliness of delivery.

1.4 Defining Software Process Improvement

A Software Process Improvement method is defined as an integrated collection of procedures, tools, and training for the purpose of increasing product quality or development team productivity, or reducing development time (Paulish 1993). An analysis of the various SPI standards and models, as listed above, can be distilled into a generic model that presents the key activities, role and artefacts that constitute the SPI discipline. These are depicted in Fig. 1, which is a schematic representation of SPI using a use case diagram notation.

Fig. 1.
figure 1

UML use case representation of the SPI discipline

Full size image

This graphic depiction will allow for the modelling of the interactions among the elements of the SPI disciple. Using the use case methodology will permit the identification, clarification, and organisation of the SPI discipline requirements. The principal Actors that are concerned in SPI are presented in Fig. 1. In order not to clutter the diagrammatical representation of SPI and attain a degree of clarity it should be noted that the associations between actors respective use cases have not been modelled. Mostly all the identified actors would have, to a larger or lesser degree, associations/interaction with each of the use cases identified in Fig. 1.

This paper argues that ethical issues are potentially raised in each of these interactions between specific actors and respective use cases. For example, in the association between the Head of SPEG (actor) and the Identify and Document Lessons Learnt (use case). This interaction may well demand a Retrospective to be held. An Actor must respect and value alternative viewpoints and, seek, accept and offer honest criticisms of work. Failure to do so implies a neglect of an ethical duty. In Sect. 3 of the paper a number of traditional moral and ethical concepts will be presented, which can be used to identify further moral issues concerning Software Process Improvement field. Via the application of these moral concepts we will list out a number of ethical duties that participants [actors] must fulfil in order that they meet their ethical obligation regarding the SPI.

2 Theoretical Framework and Ethical Concepts

In the development and deployment of computing technology a number of social, legal and ethical issues can be invoked. Legal issues can be resolved via the use of legal doctrine, which is a framework presenting a set of rules, procedural steps, or test, through which rulings can be determined in a given legal case. In the same vein the most important ethical issues surrounding the deployment and development of computer technology can be resolved by making a rational appeal to traditional ethical principles and theories and so extend them to the use of new technologies. The US Content Subcommittee of the Impact CS Steering Committee (Huff et al. 1995) advocated a framework presenting a set of traditional moral and ethical concepts that could be used to flag potential ethical issues in a given case. In terms of personal and professional responsibility, the committee recommended the following six traditional moral and ethical concepts:

  1. 1.

    Quality of life;

  2. 2.

    Use of Power;

  3. 3.

    Risks and reliability;

  4. 4.

    Property Rights;

  5. 5.

    Privacy and

  6. 6.

    Equity and Access.

In order to become a responsible computer professional, the Impact CS Steering Committee argued that one must be able to examine the standards for the rightness and wrongness of actions. For a particular issue, for example, privacy in corporate records or risks in medical technology, it will cover many levels of social analysis (individual: race, class, gender and culture; communities and groups; organisational; institutional; and national and global). In addition, it will cover several different ethical issues and will be spread across differing implementations of the technology.

The theoretical framework developed by the US Content Subcommittee of the ImpactCS Steering Committee has been customised. It specifies the six moral and ethical concepts, listed above, that can help identify ethical issues concerning the Software Process Improvement field. The application of these six conventional and generic ethical concepts is made to SPI activities such as: Determining Business Needs; Conducting Process Improvement Assessment; the Tailoring and Creation of Processes; Deployment; etc., i.e. the use cases identified in Fig. 1, above. We added commentaries, below, which lead to a set of heuristics for ethical application and utilisation of SPI, in Sect. 4.

3 The Ethical Issues Invoked in Software Process Improvement

In order to become more responsible SPI participants in general it is imperative that all are aware of the moral and ethical concepts specified in the framework. It is only through comprehending the issues raised by the framework that business process engineers, software engineering teams, process improvement managers, et al. can achieve a better understanding of the ethical issues concerning the software process and the delivery of quality software.

3.1 Quality of Life

Huff et al. (1995) state although few promoters of new technology would introduce their product with a claim that it reduces the user’s quality of life, the concept of quality of life is rarely taken into consideration. Is faster, better, more, always an increase in quality of life for users of technology? Do designers’ and decision makers’ conceptions of quality of life correspond? More often than not these issues go unconsidered in both development and implementation of technology. These sentiments applied to SPI reveal the following ethical issue.

Software Process Improvement aims at reengineering existing processes. This may well include logistical and motivational (acceptance of change) considerations. Motivational considerations are salient because new processes affect people and data flows and may have unintended consequences. As a result, power and politics, more often than not, come into play, and thus some may offer resistance to the new process. People are inherently resistant to change, and the change facilitated SPI must be taken into consideration. Employee resistance is a crucial factor is a successful SPI, or not (Bayona et al. 2008). An estimate is required to measure how strong a reaction people have toward new reengineered processes. Reengineered processes resulting from SPI influence turnover, transfers, retraining, and changes in employee job status. Therefore, it is understandable that the introduction of reengineered processes requires special effort to educate and train the staff on new ways of conducting business. Thus in order to make the reengineering effective there is an ethical duty to measure whether the SPI project can be put into action or operation in the context of politics, power and motivational considerations (Stair and Reynolds 2011).

3.2 Use of Power

An understanding, of the ethical choices that face both the powerful and the less powerful, is an important step in becoming a responsible professional (Huff et al. 1995). With regards to the efficacy of executing SPI activities it is of vital importance that all participants are empowered with enough knowledge about the Software Process and Software Engineering concepts. This is particularly so in the case where SPI activities were new in an organisation. Thus, there is an ethical duty to encourage and support participants in their professional development. Fulfilling this moral duty would concurrently raise the team capability in Software Engineering concepts in SPI programs, which is viewed as a vital SPI critical success factor (Rocha et al. 2006).

The development and deployment of new technology is not totally constrained by physical or mathematical principles, each design decision for that technology is an exercise of power (Huff et al. 1995). Tayana Conte et al. (2011) observes that the aspect associated with individual decision making of SPI programmes shows that the decisions about SPI judgments should be taken consciously. The reasons need to be analysed, evaluated and discussed with those responsible for the SPI programme. If necessary, these decisions should also be discussed with certain collaborators before they are reported to the entire organisation. Tayana Conte et al. (2011) observes that the aspect associated with individual decision making of SPI programs shows that the decisions about SPI judgments should be taken consciously. The reasons need to be analysed, evaluated and discussed with the responsible(s) for the SPI program. If necessary, these decisions should also be discussed with certain collaborators before they are reported for the entire organisation.

An example of the abuse of power is misrepresentation. It is vitally important that in negotiations between users of the process, the management and stakeholders in the SPI exercise; and the SPI Development Team that the latter do not make claims that are misrepresentations/falsehoods regarding the cost, delivery functionality and quality of the SPI solution. Stair and Reynolds (2011) identify three forms of misrepresentation: fraudulent, negligent and innocent. If the representation has been made fraudulently or recklessly, i.e. not caring whether it is true or not, then at common law the remedy of rescission is available. This sets the contract aside as if it had never been made at all and gives the right to recover any money laid out. In terms of representation made by SPI Development Team and SPI consultants, the approach is to insist that an express term be inserted into the contract to the effect of the representation made. SPI professionals also need to be consciously aware of the fact that most people within the organisation will typically not share their expertise. Thus there is a moral obligation to avoid technical terminology and articulate clearly in terms they may understand.

A further example of the abuse of power and misrepresentation is to undertake work or provide a service that is within your professional competence; or to claim any level of competence that you do not possess. These issues concerning potential abuse of power and misrepresentation are addressed as issue of Professional Competence and Integrity in the British Computer Society [BCS] Code of Conduct and Code of Practice (BCS, Year; BCS 2011).

3.3 Risks and Reliability

Huff, et al. (1995) state that there are inevitable risks associated with technology. Choices among trade-offs in design and implementation for systems will always involve ethical dimensions, and computing professionals should be prepared for them. In order to embark on Software Process Improvement it is important that actors, for example Process Improvement Managers; Heads of Software Engineering Process Groups, and others have an ethical obligation to maintain awareness of technological developments, procedures, and standards that are relevant in the field of SPI. There are notable software process improvement standards and models, as identified above. Therefore a decision as to selection of the most appropriate and applicable model(s) is critical in order that the SPI outcome is successful. Adopting the right Software Process Improvement implementation methodology is a critical success factor (Niazi et al. 2006).

In regards to SPI it’s crucial to know that the primary drivers for process improvement are business-oriented. Processing Needs Assessment will help establish whether the scope and applicability of commencing with SPI is present or not. If not then the SPI exercise must be terminated as a result. Implementing a process for its own sake is a bad idea; a process must not be implemented just because someone else does (Ambler 2013) (Niazi et al. 2006). Thus there is an ethical duty to resist any pressure to embark on SPI if the case for doing so is weak/non-existent.

Christiansen and Johansen (2008) identify the lack of involvement amongst users of the process, the management and stakeholders in the SPI exercise as a critical success factor. Dialogue and communication between these groups and the SPI development and deployment team can help, to a degree, redress this issue. There are numerous ways to aid communication, a combination of paper and electronic means, ranging from posters, flyers and brochures; through to Twitter and/or Yammer. Linders (2011) advocates face to face communication, as a richer form of communication, which helps forge stronger bonds of trust. These can, in improvement projects, take the form of Kick-off meetings; all Employee meeting; Training and coaching; open spaces; Team meetings; One on one meeting; and Walking around (walk the talk). Therefore, there is an ethical duty to keep all affected by the SPI in the communication loop. The Right to Know and the Freedom of Expression are important ethical normative principles.

A number of studies have been completed in order that SPI critical success factors are identified (Rothman 2000; Niazi et al. 2006; Bayona et al. 2008). Huff et al. (1995) argue that since error free design is both impossible to achieve and unable to be measured, computer professionals must become familiar with the inevitable risks associated with technology. Thus it follows that, participants in the SPI development and deployment must: research; identify; add to; document; and share, what SPI critical success factors are. By being conscious of these risks the ability to achieve error free SPI implementation may still be impossible the likelihood of successful deployment may be increased.

3.4 Property Rights

Technological advances make it more and more painless for employees to appropriate and misuse their employer’s confidential information. In the software process improvement there are many forms of confidential information present. All parties concerned: the client, developers and managers of the SPI need to be aware of and respect confidential information.

In the reengineering of business processes the SPI development have a duty of confidence when they come to the knowledge of confidential information under circumstances in which it would be unfair if it were disclosed to others (Fishman 2007). In the UK, The Human Rights Act has developed the law on breach of confidence so that it now applies to private bodies as well as public ones. In the SPI, breach of confidence is a matter that should also be considered by both the SPI Development Team and the client. The client should be fully aware of the confidential nature in any of the elements of the software. Client maybe provided with source code and the specifications, including systems models, for example, schematic models for the software. The agreement should spell out the duty of confidentiality in respect of these materials, reinforcing the common law duty. If the SPI Development Team has access to the client’s information, for example, sales and marketing techniques, and other commercially sensitive information, a reciprocal duty can be placed on the them (Bainbridge 2004).

3.5 Privacy

Huff et al. (1995) state that computing professionals often design systems, which store and transmit data about individuals. Privacy expectations and demands need to be taken into account in the design of systems.

The Software Improvement Group (SIG) (2017) reports three quarters of cyber-attacks and data leaks are caused by errors during software development. Discovery and thus prevention of these mistakes lead to important effects, for example: protection against incidents and fines, visible control over security and privacy, reduced development costs, reduced test costs, and peace of mind. Therefore, in order to control software security and privacy, software must be looked at. This requires systematic reviews and the use of international standards, e.g. ISO25010/ISO29100 for measuring source code qualities and assessment of the development process.

3.6 Equity and Access

By allowing any form of bias, it can be harmful to an organisation by restricting the range of views and experiences of available. Bias, conscious or unconscious, could relate to many issues such as gender, disability whether physical or otherwise, ethnic background, religion, sexual discrimination, or age whether too young or too old. For example, there has been a considerable research comparing the approach to management, negotiation and innovation of males and females at the senior level. By utilising these possible differences and gender traits, an organisation could gain (Bauer and Tremblay 2011). Thus it is vitally important that the actors identified in Fig. 1, who are participants/stakeholders in the SPI, are of a diverse representation.

Figure 1 presents, amongst many use cases, the Support Project Team use case. One salient activity defined in this use case is conducting Retrospectives. This is a fundamental vehicle to discover, share, and pass along the learning from the SPI experience (Ambler 2013). Pivotal to holding ethical Retrospectives are certain ground rules, including:

  • Participants must respect and value alternative viewpoints and, seek, accept and offer honest criticisms of work

  • Participants must be able to exercise freedom of expression. This will include the freedom to hold opinions and to receive and impart information and ideas without judgment and/or reprisal from others.

  • Exercise the right to anonymity

  • Invited participants to engage in Retrospectives reflect a diverse representation.

Failure to hold to these ground rules implies a neglect of an ethical duty.

4 Heuristics for Ethical Use of Software Process Improvement

A set of heuristics for ethical engagement with the SPI discipline proposing that an effective SPI strategy that is underpinned with ethical consideration:

  1. 1.

    Conduct a Behavioural Feasibility Study in order to measure whether the SPI can be put into action or operation with regards to employee resistance, and politics, power and motivational considerations. Failure to conduct this is an abdication of an ethical duty demanded by the principle of Quality of Life.

  2. 2.

    Provide Educational Plans and Training Materials in order to empower SPI participants with enough knowledge about the Software Process and Software Engineering concepts. Failure to provide this is an abandonment of an ethical duty demanded by the principle of Use of Power.

  3. 3.

    Ensure that SPI professionals have a clear understanding of the professional duties concerning professional integrity and competence as spelt out in the BCS Code of Conduct and BCS Code of Practice. This is a duty spelt out by the principle of Use of Power.

  4. 4.

    Ensure that managers of the SPI project maintain knowledge of SPI at the highest level by in order to minimise the probability of failed SPI exercise. This can be achieved by, for example:

  1. a.

    Access relevant literature

  2. b.

    Attending conferences and seminars

  3. c.

    Contact with other leading practitioners

  4. d.

    Participation in appropriate learned, professional and trade bodies.

This ethical obligation to maintain awareness of technological developments, procedures, and standards that are relevant in the field of SPI is demanded from the principle of Risks and Reliability.

  1. 5.

    Conduct technical reviews or walkthroughs with the technical staff in order to verify that the requirements meet the desired business results. This obligation is required from the principle of Risks and Reliability.

  2. 6.

    Use face to face, paper and online communication to disseminate and share recognised and identified SPI critical success factors. This ethical responsibility is mandatory in accordance with the principle of Risks and Reliability.

  3. 7.

    Conduct legal audits related to the planning and control of the SPI. Failure to conduct this is an abandonment of an ethical duty demanded by the principles of Property Rights and Privacy.

  4. 8.

    Draft Contracts and Terms of Agreement: A particular focus on the Confidentiality of Information must be addressed in the formulation and drafting of Employee Contracts and in any Terms of Agreements for services rendered in the SPI between client and SPI Development Team. This duty to the protection and respect of assets is claimed by the principle of Property Rights.

  5. 9.

    Deploy international standards, e.g. ISO25010/ISO29100 for measuring source code qualities and assessment of the development process. This duty to consider software security and privacy is necessitated by the principle of Privacy Rights.

  6. 10.

    Conduct Ethical retrospectives: Managers of the SPI project to conduct ethical retrospectives. This ethical obligation to conduct retrospectives in accordance with fair representation and exercising freedom to expression and anonymity is demanded from the principle of Equity and Access.

5 Conclusion

There has been recognition that Process Improvement is an imperative for the survival of organisations especially in today’s competitive world. There is often emphasis on the legality of actions but not enough attention is given to ethical considerations. In fact some believe that ethical constraints are likely to stifle creativity and innovation.

The rationale of adopting and applying the theoretical framework developed by the US Content Subcommittee of the Impact CS Steering Committee was to identify the ethical issues that can be invoked in Software Process Improvement. In doing so the authors conclude that the importance of ethical considerations in processes reengineering can be brought to the attention of the SPI community and thus help raise the visibility of ethical SPI development and deployment.

The paper contributes to the current discourse relating to the continued sharing of SPI experience in the public and private sectors. In particular, a set of heuristics for the development and deployment of SPI has been proposed which will raise awareness of the issues and help guide SPI developers and users of the process, the management and stakeholders in the SPI.

Future work will seek to apply legal principles to the development and deployment of SPI. In addition, professional principles, as explicitly stated in professional codes of conduct and practice can also be applied to the actions of participants in the SPI.

A comparison between the ethical, professional and legal considerations may permit bad laws, and poorly drafted codes of conduct and practice, to be flagged, i.e. those legal and professional regulations that provide little or no moral guidance.