A Framework for Ethical Practices in Software Development ...info.psu.edu.sa/intranet/Library/files/THE00011.pdf · A Framework for Ethical Practices in Software Development Life

I

A Framework for Ethical Practices in Software

Development Life Cycle: A case study in the Kingdom of

Saudi Arabia

A thesis

Submitted in partial fulfillment of the requirements for the degree of

Masters of Science in Software Engineering

at the College of Computer and Information Science

at Prince Sultan University

By:

Fahdah AlAmmar

February 2016

http://www.ingentaconnect.com/content/cog/ta/2003/00000008/00000002/art00004


II

A Framework for Ethical Practices in Software

Development Life Cycle: A case study in the Kingdom of

Saudi Arabia

A thesis

Submitted in partial fulfillment of the requirements for the degree of

Masters of Science in Software Engineering

at the College of Computer and Information Science

at Prince Sultan University

By:

Fahdah AlAmmar

February 2016



III

DEDICATION

I would like to dedicate my thesis to my beloved parents, sister and brothers.

IV

ACKNOWLEDGEMENTS

First and foremost, I want to express my highest gratitude to Allah almighty for providing

me guidance, ability, knowledge and patience in completing this thesis. I would like to

express my gratitude for the opportunity to contribute to the field of Software

Engineering. I am mostly thankful to my advisor Prof. Dr. Nor Shahriza Abdul Karim

who has been supportive throughout my studies, and in the completion of this thesis. I

would also like to extend my thanks to all the professors and faculty members, who were

not only lecturers, but also mentors. I am extremely grateful to have been accompanied

by colleagues who became my friends throughout my studies; friends, who were nothing

short of supportive, helpful and motivating.

Special thanks would be addressed to my employer, SADAD Payments System, and its

management team, especially Mr. Abdulmalik Al Sheikh and Mr. Abdulaziz Alafaleg for

their continuous support and guidance. SADAD Payment System, the organization that is

not only serving the community with its services, but helping its staff in growing and

contributing to the community and the country

Most importantly, none of this would have been possible without the love and patience

of my family. My family, to whom this thesis is dedicated to, has been a constant source

of love, support and strength all these years. I would like to express my heart-felt

gratitude to them, as they have aided and encouraged me throughout this endeavor.

Last but not least, my sincere thanks and appreciation go to all my friends who supported

me during my studies, especially Arwa Albuolayan, Nahlah Almashouq and Saba

Hmdan.

V

ABSTRACT

Software engineering code of ethics (SWECOE) is an area within software engineering

that requires more research attention. SWECOE has been acknowledged as an important

area of practice that gives a huge impact on how software affects our daily life. The

degree of harm to the users as a result of using equipment with faulty software

applications highly depends on the ability of software engineers to follow the good

practices in software engineering.

There has not been much research in this area, especially those that focus on how

SWECOE is being practiced and whether there is any effective framework that

practitioners have followed. This study therefore fills the gap in research in this area. The

research’s first objective was to investigate the implementation of software engineering

code of ethics within the software development projects. The objective was achieved by

analyzing documents of policies, procedures, and projects management. This was

followed by interviews with experts and questionnaires responded to by software

engineers. The second and third objectives were to investigate which SWECOE was

perceived to be the most challenging to follow, and which was perceived to be a high risk

category. These objectives were achieved by analyzing responses to questionnaires

distributed to software engineers. The fourth objective was to propose a new

classification of the software engineering code of ethics based on the SDLC phases. This

was achieved by analyzing responses of a questionnaire distributed to software engineers,

who were asked to classify the existing SWECOE based on the SDLC phases. All the

results were collected and analyzed to achieve the last objective which was to propose a

framework of software engineering code of ethics within the software development life

cycle. A new set of SWECOE was then proposed and validated by practitioners in the

field.

The results showed no evidence to indicate the presence of any formal guidelines or

requirements on ethics in software development life cycle within the organization. There

was no indication of awareness of any existing code of ethics as provided by IEEE/ACM.

Also, the risks and challenges in practicing certain areas in the SWECOE framework

VI

were found to be not significantly different, as high risk areas were also found to be

highly challenging to observe and practice. The results can provide a guide for the

organization to prioritize the risk area concerning code of ethics. The existing SWECOE

are addressed in generic terms and need to be made clear at each phase in SDLC; a

categorization of SWECOE at each phase may clearly address the ethical issues and

concerns that may arise at each phase. This categorization can be a guide in the training

of engineers, as well as guide project managers to manage teams that are highly

professional with the delivery of quality products. So, the provision of a new

classification of the software engineering code of ethics based on the software

development life cycle phases can help software engineers better understand, apply,

control and monitor software development projects and ethical practices. A guideline and

policy checklists and tools can be designed to enhance the quality of software

development as a result of this study.

Keywords: Software Engineering, code of ethics, software development life cycle

VII

ملخص البحث

تطوير البرمجيات حياة دورة مجال في األخالقية للممارسات عمل إطار

للبحث اهتماما كبيرا التي تتطلب هندسة البرمجيات إحدى المناطق في نطاق هي البرمجيات هندسيةأخالقيات

ضرر ال درجة. لها اليومي استخدامنا من خالل حياتنا على البرمجيات تأثير على كيفية تأثير كبيرلما لها من :العلمي

هندسة الممارسات الجيدة في مجال لمتابعة مهندسي البرمجيات على قدرة يعتمد إلى حد كبير المستخدمين ىعل

.البرمجيات

ممارسة الكيفية التي يتم بها على التي تركيز في هذا المجال، وجدت األبحاث ليس هناك الكثير من الواضح أنهفمن

هذا البحث، اقترح ولذلك المهندسين.باعه من قبل تيتم ا أي إطار عملما إذا كان هناك و رمجياتهندسة الب أخالقيات

مهندس البرمجيات يمارس كيف وهو فهمحقق هذا البحث هدفه: و .البحوث في هذا المجال من الفجوةهذه ملءل

مهندسي البرمجيات ت التي تواجهالتحديا فيوالتحقيق ،تطوير البرمجياتحياة دورة في أخالقيات وقواعد السلوك

مقابالت مع تاله إجراءإدارة المشاريع. ووثائق . عن طريق تحليل سياسات اجراءاتاألخالقياتهذه وصعوبة اتباع

الممارسات األخالقيةاي والثالث وهم تحديد والهدف الثاني البرمجيات. قبل مهندسيخبراء واستبيانات تم تعبئتها من

تحقيق تمو عالية،نها ذات خطورة أيهم ينظر مهندس البرمجيات أيا تطبيقها وتحد وأكثرصعب أات يهندسة البرمج في

ومبادئ توجيهية هو اقتراح إطارالهدف الرابع و البرمجيات. أماسي دعن طريق استبيانات وزعت لمهن هذه األهداف

ن طريق توزيع استبيان على مهندسي حياة تطوير البرمجيات ع دورة من مراحل مرحلة في كلمهندسي البرمجيات ل

حياة تطوير ساس مراحل دورةأهندسة البرمجيات على في الممارسات األخالقيةبتصنيف اليقوموبرمجيات ال

البرمجيات.

في كلمهندسي البرمجيات ومبادئ توجيهية ل دالئل على وجود إطارأنه ال يوجد هي كانت أهم نتائج البحثمن إنو

ومبادئ إطارود مهندسي البرمجيات بوجو علم أ الشركة،حياة تطوير البرمجيات في دورة من مراحل مرحلة

الممارسات منعتقد مهندسو البرمجيات يفرق بين ما أنه لوحظ أنه ال يوجد مهندسي البرمجيات. كماتوجيهية ل

انها هندسو البرمجيات علىمينظر أيهمومن تطبيقه وأكثر تحديا صعبأ اانهعلى هندسة البرمجيات في األخالقية

.ذات خطورة عالية

كيففهم و ،البرمجيات تطوير حياة دورة في مرحلة في كلمهندسي البرمجيات ومبادئ توجيهية ل اقتراح إطار إن

التحديات التي في والتحقيق تطوير البرمجيات،حياة دورة في قواعد السلوكأخالقيات و برمجياتالمهندس يمارس

هندسية ألخالقيات جديد تصنيفاقتراح كما أن ،األخالقياتهذه وصعوبة اتباع البرمجياتمهندسي تواجه

،مراقبة، تطبيق فهم،على مهندسي البرمجيات يساعدهحياة تطوير البرمجيات دورة مراحل على أساس البرمجيات

العامة الثقة تحسينإلى يؤدي البرمجيات هندسية واتباع أخالقياتاعتماد أنه ا. كمالبرمجياتمهندسي ورصد

مستوى عال من من خالل ةالعام مصالحبال الوفاءب تهتمي الت لسياساتااالجراءات و اتباعخالل من والسمعة

VIII

البابينبالتفصيل في المنهجية المتبعة والنتائج في كما موضح .مستوى من السريةمع هندسة البرمجيات و ممارسات

.4و 3

IX

Table of Contents

DEDICATION ................................................................................................................................... III

ACKNOWLEDGEMENTS .................................................................................................................. IV

ABSTRACT ........................................................................................................................................ V

البحث ملخص ..................................................................................................................................... VII

LIST OF TABLES ......................................................................................................................... XI

LIST OF FIGURES ....................................................................................................................... XII

List of abbreviations ..................................................................................................................... XIII

CHAPTER 1 - INTRODUCTION .................................................................................................. 1

1.1 Background ..................................................................................................................... 1

1.2 The Research Problem ..................................................................................................... 4

1.3 Research Questions ......................................................................................................... 5

1.4 Research Objectives ........................................................................................................ 5

1.5 Research Contribution ..................................................................................................... 5

1.6 Outline of the Thesis ....................................................................................................... 6

CHAPTER 2 - LITERATURE REVIEW ....................................................................................... 7

2.1 Software Engineering and Ethics .................................................................................... 7

2.2 Software Engineering Code of Ethics ........................................................................... 10

2.3 Importance of Software Engineering Code of Ethics .................................................... 12

2.4 Related Research ........................................................................................................... 15

2.5 Summary ....................................................................................................................... 22

CHAPTER 3 – METHODOLOGY ............................................................................................... 23

3.1 Research Approach ........................................................................................................ 23

3.2 Research Design ............................................................................................................ 24

3.3 Case Study ..................................................................................................................... 25

3.4 Data Collection .............................................................................................................. 28

3.5 Data Analysis ................................................................................................................ 31

3.6 Summary ....................................................................................................................... 32

CHAPTER 4 – RESULTS AND DISCUSSION .......................................................................... 33

4.1 How Code of Ethics is Being Implemented in SADAD................................................ 33

4.1.1 Document Analysis ................................................................................................ 33

X

4.1.2 Interview Analysis ......................................................................................................... 38

4.1.3 Questionnaire Analysis .......................................................................................... 51

4.2 Identification of High Risk and Most Challenging SWECOE to Follow ...................... 53

4.2.1 High Risk and Most Challenge SWECOE to Follow ................................................ 53

4.3 SWECOE based on the SDLC Phases ........................................................................... 58

4.3.1 Questionnaire Results ........................................................................................... 59

4.3.2 New Classification of SWECOE based on the SDLC ............................................... 65

4.4 Proposed framework ...................................................................................................... 72

4.5 Validation ...................................................................................................................... 80

4.6 Summary ....................................................................................................................... 83

CHAPTER 5 – CONCLUSION ........................................................................................................... 85

5.1 Summary Findings ............................................................................................................... 85

5.2 Research contribution and recommendation ............................................................... 86

5.3 Research Limitations and Suggestion for Future Research ................................................. 87

REFERENCES .............................................................................................................................. 88

APPENDIX A- Software Engineering Code of Ethics and Professional Practice (Full Version)

PREAMBLE .................................................................................................................................. 94

APPENDIX B - Permission and Approval Letter ........................................................................... 103

Appendix C ................................................................................................................................... 104

APPENDIX D - Sample of the questionnaire ................................................................................ 106

APPENDIX E - Questionnaire Results and Analysis ...................................................................... 110

APPENDIX F – Interviews results .............................................................................................. 119

XI

LIST OF TABLES

Table 2. 1 ACM and IEEE-CS Software Engineering Code of Ethics principles ......................... 11

Table 3. 1 Interviewee Overview .................................................................................................. 29

Table 3. 2 Summary of research objectives and data collection strategies ................................... 30

Table 4. 1 Reasons why having code of ethics is important ......................................................... 40

Table 4.2 Ethical concerns on the requirement phase based on the interviews ............................ 44

Table 4.3 Ethical concerns about the design phase based on the interviews ................................ 46

Table 4.4 Ethical concerns on the coding phase based on the interviews .................................... 47

Table 4.5 Ethical concerns on the testing phase based on the interviews ..................................... 48

Table 4.6 Ethical concerns on the maintenance phase based on the interviews ........................... 50

Table 4. 7 Summary of the ethical concerns about each SDLC phase .......................................... 51

Table 4.8 Ethical concerns about each SDLC phase from the interviewees’ perspectives .......... 51

Table 4.9 Public principle clause based on the risk rating ........................................................... 54

Table 4.10 Client and employer principle clause listed based on the risk rating ......................... 55

Table 4.11 Product clause based on the risk rating along ............................................................ 56

Table 4.12 Judgment principle clause based on the risk rating .................................................... 57

Table 4.13 Questionnaire segmentation analysis .......................................................................... 58

Table 4.14 Public principle clause as aligned with the SDLC phases .......................................... 59

Table 4.15 Client and employer principle clause as aligned with the SDLC phases ................... 60

Table 4.16 Product principle clause as aligned with the SDLC phases ........................................ 62

Table 4.17 Judgment principle clause as aligned with the SDLC phases .................................... 64

Table 4.18 Case 1 .......................................................................................................................... 82

Table 4.19 Case 2 .......................................................................................................................... 82

Table 4. 20 Research objectives and Results ................................................................................. 83

XII

LIST OF FIGURES

Figure 2. 1 e-Government ethics position related to computer ethics, information ethics, cyber

ethics and other applied ethics. .................................................................................................... 18

Figure 3. 1 Research Design Diagram ........................................................................................... 25

Figure 3.2 SADAD Overview (SADAD Payment System official website) ................................ 27

Figure 4.1 Requirement Verification and Validation Guidelines – Criteria for a quality

requirement .................................................................................................................................... 35

Figure 4.2 Requirement Verification and Validation Guidelines – Guidelines for writing

requirements statements ................................................................................................................ 36

Figure 4.3 Requirement Verification and Validation Guidelines – Verifications Guidelines ....... 37

Figure 4. 4 Screen shot from Business Analysis Performance Evaluation Guidelines document . 38

Figure 4. 5 General clauses ........................................................................................................... 66

Figure 4. 6 Requirement Clauses................................................................................................... 67

Figure 4.7 Design Clauses ............................................................................................................. 68

Figure 4.8 Code Clauses ................................................................................................................ 69

Figure 4.9 Test Clauses ................................................................................................................. 70

Figure 4.10 Maintenance Clauses .................................................................................................. 71

Figure 4.11 ACM/IEEE 8 Principles ............................................................................................. 72

Figure 4.12 ACM/IEEE first four principles ................................................................................. 72

Figure 4.13 SDLC Phases.............................................................................................................. 73

Figure 4. 14 New proposed SDLC Code of Ethics Framework ....................................................... 74

XIII

List of abbreviations

SWECOE Software Engineering Code Of Ethics

SDLC Software Development Life Cycle

KSA Kingdom of Saudi Arabia

ACM Association for Computing Machinery

IEEE Institute of Electrical and Electronics Engineers

SAMA Saudi Arabian Monetary Agency

EBPP Electronic Bill Presentment and Payment

BA KPIs Business Analysis Key Performance Indicator

SLR Systematic literature review

ROA Return on Assets

ROE Return on Equity

SEEPP Software Engineering Ethics and Professional Practice

EDSD Ethical-Driven Software Development

1

CHAPTER 1 - INTRODUCTION

‘When the devils will come and visit us, they will not have big horns. It will not hurt; it does not

hurt a living being. It will just arrange to lower our levels of ethics. Just a little. And the rest will

follow...’

Albert Brooks in the movie ‘Broadcast News’

1.1 Background

With the increasing use of electronic equipment into our daily lives, software applications

have become an essential part of our lives. Whether people are aware or not, electronic

equipment has software applications controlling their functionalities. Software

applications affect our lives directly or indirectly, such as, in our work, business

transactions, transportation, education and entertainment. Software development is not an

easy task and, in fact, is a complex process involving requirement gathering, design,

implementation, and testing. This exposes software engineers to many personal

challenges within each process in the development. Software engineers can not only

influence the developing process of software in many ways, but also be influenced by it:

they could engage in unethical behavior, intentionally or unintentionally (Godfrey, 1996),

which may lead to numerous positive and negative consequences. Negatively, these can

cause personal harm, financial collapse, huge lost due to unusable software, and loss of

confidence in software and trust in the organizations that own them. Ultimately, it may

lead to serious legal implications that affect the lives of individuals and organizations at

large (Quigley, 2007).

A huge amount of software is being used on a daily basis and the situation becomes

critical when they affect users negatively. During the process of software development,

engineers face crucial ethical decisions in order to ensure minimal harm to the users. One

way to do this is to seriously consider and review some form of code of ethics software

creation (Gotterbarn, 2001).

2

There are many reasons why it is important to include ethical practices in decisions

regarding software engineering. In software development projects, technical decisions are

usually made from the aspects of technical issues with minimal consideration given to the

impact those decisions might have on the users or other stakeholders. On the contrary,

decisions made in software development projects should consider the ethical dimension

as well as the technical dimension in order to safeguard the software against potential

harm to others (Gotterbarn, 2001). Software engineers have the responsibility to the

engineering profession and society at large. They should be willing to adhere to the

professional code of ethics as part of their contribution to the development of quality

software. Professional codes of ethics do not only require doing the right thing for the

client, but it also includes doing the right thing for the society as well (Godfrey, 1996).

Software code of ethics is an area within software engineering that requires great

attention in research (Lurie & Mark, 2015; Bynun, 2008; Gottenbarn, 1999). Code of

ethics has been acknowledged as an important area of practice that tremendously impact

the quality of software and how it affects lives through the daily use of the computer and

information systems. The degree of harm to the users highly depends on the ability of

software engineers to follow and respect good practices in software engineering (Agarwal

& Garcia, 2006). While the software engineering profession have stressed on the

adherence to the professional conduct and code of ethics, not much is known on how the

code of ethics is being practiced or how adherence is enforced to ensure quality, trust,

commitment, and lack of harm that may occur at each stage of software development

projects.

The existing software engineering code of ethics, as developed by IEEE and ACM can

impose a huge challenge to practitioners. Without a proper mechanism and framework to

ensure clarity, adherence to the standard of practice among software engineers in

software projects can be highly difficult. In developing policies and frameworks, more

understanding is needed on how the elements of this code of conduct are being enforced

and perceived by developers and engineers (Lurie & Mark, 2015). Thus, many studies

should be done at various levels of software development, to understand issues, concerns

and challenges in enforcing some of these elements.

3

This study focuses on describing how the software engineering code of ethics is being

practiced in software development projects based on a case in Saudi Arabia.

Subsequently, the study also seeks to investigate the availability of a framework for

software engineering code of ethics in this context and study the challenges faced by

software engineers in adhering to the ethical principles throughout the software

development life cycle.

In addition, a new classification of the existing IEEE/ACM software engineering code of

ethics based on the software development life cycle phases is identified and proposed.

This reclassification is done for four principles out of the eight IEEE/ACM principles.

The four principles are Public, Client and Employer, Product and Judgment. This is done

to help the researcher better understand the framework, and guide project managers to

apply, control and monitor software engineers’ ethical practices with the software project

life cycle.

Adopting a software engineering code of ethics will improve the public trust and

professional image of the software product by committing that the public interest is being

met through a high standard of software engineering practices and level of confidentiality

(Gotternbarn, Miller & Rogerson, 1999). Similarly, adopting this software engineering

code of ethics can improve internal communication between colleagues as well as

management. Having organizations implement this code of practice may further attract

reliable and dedicated employees who want to be part of a reliable organization

(Association for Computer Machinery & Institute of Electrical and Electronics Engineers

[ACM /IEEE-CS]).

Due to the importance and advantages of adherence to the code of ethics, software

engineers need to be aware of and understand how to comply with these ethical

requirements. In addition to good ethics curriculum in the teaching and learning process,

a good framework is also needed for the engineers to follow effectively during the

development phase of software projects. Similarly, a classification of the software

engineering code of ethics based on the software development life cycle phases will be a

4

good tool to help software engineers to better understand and comply with the code of

ethics.

This research was conducted in an attempt to establish a preliminary framework for

guidelines and practice in software development starting with an investigation of the

current practices to understand and identify ethical concerns within software development

projects.

1.2 The Research Problem

Given the many definitions of ethics, it is clear the subject is regarded as highly important

in the engineering field, especially in software engineering. In the field of software

engineering, Quigley (2007) defines ethics as “…a code of professional standards,

containing aspects of fairness and duty to the profession and the general public.”

Researchers in software engineering have come up with various codes and guidelines to

inform educators and professional practitioners about what ethics are and, most

importantly, to uphold its value in the actual process of software products development

(Gottenbarn, 1999, 2001, 2009). The revised version of the ethical framework was

produced in collaboration between IEEE and ACM, a joint task force with the most

updated Software Engineering Code of Ethics Version 5.2 (SWECOE V 5.2)

(ACM/IEEE-CS Joint Task Force, 2014).

Despite the existence of a detailed ethical code by ACM/IEEE-CS Joint Task Force,

many practitioners remain unaware of its existence and were not able to uphold the

standards in the software development projects. On many occasions, ethical issues arise

due to the lack of awareness, and this has resulted in significant losses and damages to

the individual, organization, and society at large (Volkman, 2011, 2015; Gotterbarn &

Miller, 2009). The most common mechanism used to create awareness is through

academic curriculum as well as corporate training. However, not many academic

programs would impose on SWECOE and few corporate sectors send their developers for

training. Yet, ethical framework is highly needed in order to ensure quality software with

the development of lifecycle itself (Lurie & Mark, 2015).

5

1.3 Research Questions

In view of the motivations and definitions provided earlier, this research was conducted

using the case study method in the context of the Kingdom of Saudi Arabia to answer the

following research questions:

1. How is software engineering code of ethics practiced within the software

development life cycle?

2. Among software engineering codes of ethics established:

o Which are perceived to be the most challenging to be followed?

o Which are perceived as high risk category to be included in the software

development life cycle policy and guidelines?

3. What is the best classification of code of ethics that can be made within each phase of

the software development life cycle?

4. What is the appropriate framework of software engineering code of ethics to be

implemented within the software development life cycle?

1.4 Research Objectives

To investigate how software engineering code of ethics is being implemented within

the software development projects

To investigate which software engineering code of ethics is perceived to be the most

challenging to follow.

To investigate which software engineering code of ethics is perceived to be a high

risk category.

To propose a new classification of the software engineering code of ethics based on

the software development life cycle phases.

To propose a framework of software engineering code of ethics within the software


1.5 Research Contribution

The contribution of the research are described in the following paragraphs.

6

First, the research offers recommendations that could assist software engineers to comply

with the software engineering code of ethics in software development projects. This can

also help them to focus on the most important and challenging code of ethics, of which

the implication can be severe if overlooked or not followed. The proposed framework can

assist developers in applying software engineering code of ethics within the software

development life cycle and prioritize the code of ethics based on risks and providing a list

which contains items perceived to be the most challenging code of ethics to be followed.

Second, the research provides a new classification of the software engineering code of

ethics based on the software development life cycle phases that can help software

engineers better understand, apply, control and monitor software development projects

following ethical practices.

Third, the research results would enhance research and knowledge in software

engineering code of ethics which is really needed in the field. The framework identified

can contribute significantly into our understanding of ethical concerns among software

engineering professionals. It can assist educators and academicians in enhancing ethics

curriculum and prepare software engineering professionals entering the field. They would

understand the ethical practices and able to adhere to the professional code of conduct.

1.6 Outline of the Thesis

This research was conducted to investigate how a software engineering code of ethics is

practiced in software development project in KSA. The chapters that follow provide a full

report of the thesis and are arranged according to the following: Chapter 2 presents the

Literature Review of related works; Chapter 3 presents the Methodology, which describes

the method used to collect data to answer the research questions; Chapter 4 presents the

Results and Discussion, and the last chapter, Chapter 5 ends with the Conclusion, which

highlights the main findings, proposes a set of recommendation, provides the research

limitation, further research topics and research significance.

7

CHAPTER 2 - LITERATURE REVIEW

This chapter provides a review of the literature on software engineering ethics and related

research areas. In order to survey the literature, a systematic literature review

methodology was used as a guide. Systematic literature review (SLR) “… is a means of

identifying, evaluating and interpreting all available research relevant to a particular

research question, or topic area, or phenomenon of interest. Individual studies

contributing to a systematic review are called primary studies; a systematic review is a

form of a secondary study” (Kitchenha, 2004).

The literature review is intended to provide further understanding of the topic under study

based on published documents and past research. Preferred publications are those which

tackle both the subjects of ethics and software engineering. The review also examined

research which covers topics on computer ethics, information ethics and security,

software engineer profession, software engineering code of ethics. For this purpose,

IEEE, Google Scholar, and Science Direct digital libraries were used to as sources to

collect data that helped in answering the research questions.

2.1 Software Engineering and Ethics

The Oxford English dictionary defines engineering as the “branch of science and

technology concerned with the design, building, and use of engines, machines, and

structures,” and as “…a field of study or activity concerned with modification or

development in a particular area.”

Software, according to Merriam-Webster Dictionary, refers to “the programs that run on a

computer and perform certain functions.” Further, software engineering is defined as “a

branch of computer science that deals with the design, implementation, and maintenance

of complex computer programs,.“

http://www.oxforddictionaries.com/definition/english/design#design__2

http://www.oxforddictionaries.com/definition/english/modification#modification__2

http://www.oxforddictionaries.com/definition/english/development#development__9

8

Another definition is provided by Mills (1999) who referred to software engineering as

“the systematic design and development of software products and the management of the

software process. “ Software engineering has, as one of its primary objectives, the

production of programs that meet specifications, and are demonstrably accurate,

produced on time, and within budget (Mills, 1999).

Ethics, according to Capurro (1988), is derived from the Greek word "ethos", which

means "way of living". The definition of ethics is provided in the following paragraphs

according to different sources and areas.

Ethics, as illustrated by the Cambridge Dictionary of Philosophy, has been found to be

used alternatively with the term morality and sometimes “…it is used more narrowly to

mean the moral principles of a particular tradition, group or individual” (Deigh, 1995).

Studies of ethics have focused more on the creation of rules to distinguish between right

and wrong. Ethics in a broad sense refers to “the concern of figuring out how to have a

good life” (Vallor, n.d.). On a personal level, it is expressed as an individual’s self-

reflection and continuous strivings to become a better person. As a profession, it is

usually formulated in formal codes or standards such as medical ethics or business ethics

(Vallor, n.d.).

Kaddu (2007) defines ethics as “…a branch of philosophy that is concerned with human

conduct, more specifically the behavior of individuals in society.” Another definition by

Averweg & Erwin (2005) states ethics as “a branch of philosophy that deals with what is

considered to be right and wrong”. Yücel et at. (2009) describe ethics as “a branch of

philosophy that studies morals and values,” While Fieser and Dowden (2011) stated that

“the field of ethics (or moral philosophy) involves systematizing, defending, and

recommending concepts of right and wrong behavior.”

The general perceptions of ethics as a discipline is that it is “the study of value concepts

such as ‘good,’ ‘bad,’ ‘right,’ ‘wrong,’ ‘ought’, applied to actions in relation to group

norms and rules” (Veatch, 1977). Therefore, it deals with many issues fundamental to

decision-making.

9

The Oxford English Dictionary defines ethics as the “moral principles that govern a

person’s behavior or the conducting of an activity”. Another definition for ethics by

Gotterbarn (2001) is “any intentional action that impacts negatively or positively the lives

and values of others”. Likewise, Merriam-Webster Dictionary defines it as “an area of

study that deals with ideas about what is good and bad behavior: a branch of philosophy

dealing with what is morally right or wrong”. Similarly, Pollice (2006) defines it as the

“discipline dealing with what is good and bad and with moral duty and obligation."

Moreover, Paul and Elder (2006) define ethics as “a set of concepts and principles that

guide us in determining what behavior helps or harms sentient creatures.”

Ethics may refer to the norms that guide societal behaviour. Redstone (2014) defines

code of ethics as “…a set of guidelines that defines acceptable behavior for members of a

business or organization.” Usually the organization tailors the code of ethics to fit the

organizational need and create some mechanism to enforce it. According to Berenbach

and Broy (2009), ethics is “…how an individual or an organization ensures that all its

decisions, actions and stakeholders’ interaction conform to the individual’s or

organization’s moral and professional principles. These principles should support all

applicable laws and regulations and are the foundation for the individual’s or

organization’s culture and values. They define right from wrong.”

Brief History

In the early 1940’s during the World War Two, Norbert Wiener, a professor of the

Massachusett Institute of Technology, established Computer Ethics as a field of study

while helping to develop antiaircraft cannon. This project challenges caused Wiener and

a few colleagues to create a new branch of science, which Wiener called “cybernetics”

which refers to the science of information feedback systems (Bynum, 2000).

In software engineering, research pertaining to Code of Ethics took place in 1994, when

the International Task Force formed the Software Engineering Ethics and Professional

Practice (SEEPP). In July 1997, an initial version was shown as a published proposal to

professional societies including ACM’s SIGSOFT (Gotterbarn et al., 1997). During the

10

later part of the year, version 3 was published in IEEE-CS and ACM magazines. Version

4 was then presented to IEEE review process. In October 1998, version 5.2 was

unanimously adopted by ACM and IEEE (Gotterbarn et al., 1999).

Among the content in the preamble of the software engineering code of ethics

(SWECOE) was that: “Software engineers are those who contribute by direct

participation or by teaching, to the analysis, specification, design, development,

certification, maintenance, and testing of software systems. Prevalence of software in

society provides significant opportunities to do good or cause harm, ensure that efforts

are used to do good.” This preamble also indicates that the concept is not intended to be

applied in piecemeal (ACM/IEEE – Joint Task Force, 2014).

2.2 Software Engineering Code of Ethics

Software engineering has evolved from being just an activity of computer science to a

discipline on its own (Vallor, n.d.). A huge amount of software is used on a daily basis

and they become critical when they affect the society causing harm. During the

development of the software, engineers are faced with crucial ethical decisions in order to

ensure minimal harm to the users. In other words, they should review and consider the

ethical dimension while creating the software (Gotterbarn, 2001).

Quigley (2007) in his evaluation of software engineering as a profession defines ethics as

“a code of professional standards, containing aspects of fairness and duty to the

profession and the general public.” This will be passed on to the users as good practices.

The Association for Computing Machinery (ACM) and the IEEE Computer Society

(IEEE-CS) are known for the many activities that they have jointly undertaken through

the years. These cooperative activities include: conference sponsorship; a joint

membership agreement; joint publication of journals and conference proceedings, and

educational curricula; cooperation in Digital Library metadata exchange joint sponsorship

of awards and committees; and an accreditation board a shared speakers program.


11

At the end of 1998, ACM and the IEEE-CS jointly approved Software Engineering Code

of Ethics and Professional Practice to encourage software engineers to undertake positive

actions and to resist pressures to act unethically (ACM/IEEE-CS Joint Task Force, 2014).

This code of ethics went through an extensive review process that concluded with an

official common approval by the leadership of both organizations.

The code of ethics contains a number of clauses classified under eight principles that

software engineers need to adhere when developing software. In accordance with their

commitment to the welfare of the public, two versions of this code were released; the full

version included the detail clauses under each principle (ACM/IEEE-CS Joint Task

Force, 2014). Appendix A refers to the full version of ACM/IEEE Software Engineering

Code of Ethics. A short version of the code summarizes the goal of the concept as

provided in the following table:

Table 2. 1 ACM and IEEE-CS Software Engineering Code of Ethics principles

Principle Description

PUBLIC Software engineers shall act consistently with the public interest.

CLIENT AND

EMPLOYER

Software engineers shall act in a manner that is in the best interests of

their client and employer consistent with the public interest

PRODUCT Software engineers shall ensure that their products and related

modifications meet the highest professional standards possible

JUDGMENT Software engineers shall maintain integrity and independence in their

professional judgment.

MANAGEMEN

T

Software engineering managers and leaders shall subscribe to and

promote an ethical approach to the management of software development

and maintenance.

PROFESSION Software engineers shall advance the integrity and reputation of the

profession consistent with the public interest.

COLLEAGUES Software engineers shall be fair to and supportive of their colleagues.

SELF

Software engineers shall participate in lifelong learning regarding the

practice of their profession and shall promote an ethical approach to the

practice of the profession.

This code of ethics adopted by ACM-IEEE Joint Task Force on Software Engineering

Ethics and Professional Practice states that:

12

“Software engineers shall commit themselves to making the analysis, specification,

design development, testing, and maintenance of software a beneficial and respected

profession” (Gotterbarn et at., 1999) .

Gotterbarn and Miller (2009) studied how code can help software engineers make

complex decisions, either technical or ethical, which are better for the public, profession

and the engineer. This was done by presenting three cases, one fictional and two based on

news reports and how using this code as a decision-making aid when conflict arises.

Evans (2012) explored the IEEE Code of Conduct and issues of privacy, badware, and

net neutrality in regards of what obligations fall on the software engineer to act ethically

in their development of software.

2.3 Importance of Software Engineering Code of Ethics

This section will present the review of ethics and the importance of having SWECOE as

found in the literature.

Rogerson (2002) discussed briefly the need for having an effective code of ethics and

practice in the field of information and communication technology. The benefits of

adapting Software Engineering Code of Ethics and Professional Practice and how this

code provides clear guidance on how to make decisions related to software development

were also listed. The benefits relate to the idea that when the public are aware that the

organization is adapting to such a code of ethics, this will increase reputation and the

public trust, as they are confident that the organization is producing a high standard of

quality. Adopting this code of ethics will attract dedicated and hardworking employees as

they know that the organization is complying with high standards and aims to produce

high quality software. Moreover, adopting the Software Engineering Code of Ethics and

Professional Practice provides a clear guidance on how to make decisions related to

software development (Rogerson, 2002).

Godfrey (1996) identified the importance of software engineering code of ethics and the

reasons why ethics should be taught in software engineering courses. The paper started

by emphasizing on the wide use of equipment nowadays, and how equipment is

13

controlled by software, that went through a complex development and production

process. In the process, software engineers can influence the software in many ways, for

example, they could engage in an unethical behavior, intentionally or unintentionally, as

mentioned earlier. Software engineers have a responsibility to the engineering profession

and society and should be willing to adhere to the professional code of ethics.

Professional codes of ethics require doing the right thing for the client, and also the

society at large (Godfrey, 1996).

According to Godfrey, there should be a course in code of ethics, and proposes that it

should be taught in a five-stage process. The first stage is to establish the need for ethical

behavior. The second stage requires an understanding of ethical concepts and theories.

The third stage introduces the idea of the code of ethics. The fourth stage applies the

ethics rules and theory in different scenarios to explore all possible actions. The final

stage, present an ethical situation for students to reflect upon their critical thinking and

and offer solutions to the problem (Godfrey, 1996).

Today, people depend on software for almost everything. You would not see any car, for

example, without software for their safe operations, or a bridge built without the use of

sophisticated software to calculate the material strength and expected load, and to design

resilience. Any software failure, such as a poorly designed gas tank, can result in a

disaster, causing serious injuries to the users and sometimes even death (Vallor, n.d.).

Regardless of the purpose of the software, if the software fails to act in a trustworthy

manner this would usually lead to harm. Harm differs based on the type, size, and the

purpose of the software. Harm can be minor such as in scheduler systems. However, in

other more critical systems such as aircraft controlling application or application that

controls medical devices, the harm can be massive as it can be a matter of life or death.

This explains why such critical systems are costly as the software engineers would have

spent more time to ensure their quality compared to simpler non-critical systems such as

a television control software where the consequence of failure would merely be that we

cannot watch a desired program (Pollice, 2006).

14

Nonetheless, harm is often unintentional. For example, doctors being human would

sometimes make wrong diagnoses and treatments which lead to harm to their patients.

Likewise, software engineers may release unknowingly software that contains defects

that causes harm. So we need to limit the harm of intentional as well as unintentional

defects. We need to introduce and enforce a code of ethics (Pollice, 2006).

There is a lot of ethical concerns related to software and information technology, such as,

intellectual property of the software product, privacy of the personal data, intrusions,

fraud, and so on. In this research we are focusing on the ethical concerns that are the

responsibility of the software engineers when developing software, where misconduct

may result in delivering faulty software that will provide an unintended and undesirable

consequence (Génova et al., 2006).

Developing software varies from an easy process for a very simple small program to a

very complex process for critical systems, especially for distributed, networked and

heterogeneous systems (Génova et al., 2006). The main purpose of codes of ethics for

any profession is to avoid harm to others through professional conduct. We can

distinguish between harm because of a software failure and harm because of a software

misuse. But, again we need to consider that if the software is intentionally designed to

spy or to commit a fraud, then it is the software engineer’s (designer) responsibility to be

fully accountable (Génova et al., 2006). One of the ethical concepts that will reduce such

harm is that software engineers should take full responsibility for their work and act upon

it. Pollice (2006) mentioned aptly that “if we are going to trust software, we must trust

the people who build it.”

A code of ethics gives an indication of the organizational culture to the employees as well

as the public (Landers, 2014). The code serves as the organization’s ethics and should be

integral to its communications strategy. It also serves as an annual assessment tool for

continuous improvement (Collins, 2012).

15

2.4 Related Research

Several studies were found related to ethics and technology in the literature. For example,

Shakib and Layton (2014) studied the interaction between ethics and technology. At first

glance, there appears to be no interaction between ethics and technology. However, there

is an influence on technology from ethics, from the profession and public perspectives. In

addition, Agarwal and Garcia (2006) concurred that some research that has been done in

the area of computer ethics mainly focused on how computer technology should be used.

Among the popular research works are those covering the concept of integrity,

confidentiality, intellectual property, and privacy along with an explanation for each,

such as Bynum (2008), Thomson and Schmoldt (2001) and Taherdoost et al. (2011).

The authors established that every person should understand that there are right and

wrong way to do things and the person should do the right things, even when he or she

does not like it. However, there is no absolute general agreement on what is considered

right or wrong. Ethics can help software engineers to avoid wrong actions and respond to

misconduct by showing what decisions the engineer can take, and allowing them to

differentiate between good and bad software applications. From an ethical perspective,

technology improvement should protect human values while enhancing computer

software (Shakib and Layton, 2014).

A study of ethics helps in improving the education of engineers in providing guidelines

for decision making during the development process. Collins (2012) identified six

reasons why computer ethics should be studied. They are as listed:

We should study computer ethics because doing so will make us behave like

responsible professionals.

We should study computer ethics because doing so will teach us how to avoid

computer abuse and catastrophes.

We should study computer ethics because the advance of computing technology

will continue to create temporary policy vacuums.

We should study computer ethics because the use of computing permanently

transforms certain ethical issues to the degree that their alterations require

independent study.

16

We should study computer ethics because the use of computing technology

creates, and will continue to create, novel ethical issues that require special study.

We should study computer ethics because the set of novel and transformed issues

is large enough and coherent enough to define a new field.

The code of ethics was developed due to increasing ambiguity of issues related to ethical

concerns, and used to minimize this ambiguity by creating guidelines to apply when

making decisions (Collins, 2012).

Taherdoost et al.,(2011) proposed an educational plan for computer ethics and

information security as they were concerned that computer technology may raise some

unethical issues with the current life style, especially with the number and type of

computer applications that have dramatically increased each year as well as their impact.

After defining computer ethics as “…the analysis of the nature and social impact of

computer technology and the corresponding formulation and justification of policies for

the ethical use of such a technology” and explaining the importance of teaching code of

ethics to students, they suggested a list of applicable topics that can be part of the

computer ethics course such as computer crime, privacy, intellectual property, accuracy,

accessibility, morality, and awareness (Taherdoost et al., 2011).

Dodig-Crnkovic and Feldt (2009) discussed the significance of teaching professional,

social and ethical issues in Software Engineering in a Swedish context and practice. The

objective of including ethics is to increase the ability of future professionals to identify

and address ethical problems, to accept different ethical perspectives, and allow for

ethical variety. A course on Ethics would help develop the skills of rational thinking by

studying examples of teaching materials from other universities and how the participants

can discover important factors that may influence their professional judgment and

decision making.

Moreover, Rodeno et al., proposed a 30-hour course on Computer Ethics at the European

Computer Science Universities. The aim of the course is to teach students the basis for

ethical decision-making and methodology for computing matters, with the final objective

of having the students do well in their jobs as a service to society. This would meet the

17

professional associations’ requirement, as part of their accreditation as a computer

scientist (Rodeño et al., n.d.).

Maner (1996) argued that computer ethics is an academic filed in its own right with

unique ethical issues that would not have existed if computer technology had not been

invented. Thus, it is a field worth further study. Bynum (2008) explored the historical

information about computer ethics which consisted of mainly the foundation of computer

and information ethics and their respective definitions. Different topics in computer

ethics were discussed such as computer crime and computer security which are obvious

and crucial topics of concern in the field of computer ethics. The authors identified that

the problem is not just related to the physical security of the hardware, but rather a logical

security, which is divided into five aspects:

1. Privacy and confidentiality

2. Integrity — assuring that data and programs are not modified without proper

authority

3. Unimpaired service

4. Consistency — ensuring that the data and behavior we see today will be the same

tomorrow

5. Controlling access to resource

Agarwal and Garcia (2006) explored the history of computer ethics and it has grown over

the years as a discipline. They concurred that ethics is a dynamic and complex field of

study, which cover both social as well as personal policies for the ethical use of

technology. Therefore, it was maintained that computer ethics is “the analysis of nature

and social impact of computer technology and the corresponding formulation and

justification of policies for the ethical use of technology” (Agarwal & Garcia, 2006). This

research can, therefore, lead to further needed research in order to establish a deeper and

common understanding of ethics.

Ramadhan et al. (2011) brought the topic of e-Government ethics by defining and

formulating the issues of e- Government ethics, and explaining three types of applied

18

ethics which are computer ethics, information ethics and cyber ethics. This was done by

by first providing a definition of ethics followed by a discussion on issues associated with

it. The researchers proposed the position of e-Government ethics in relation to other

applied ethics, as shown in Figure 2.1.

Figure 2. 1 e-Government ethics position related to computer ethics, information ethics, cyber ethics and other applied ethics.

Al-A’ali (2008) studied the ethical behavior of Muslim IT professionals in an attempt to

stop unethical practices such as, software intellectual property violation and software

privacy. The study examined the principles of computer ethics presented by the ACM

code of conduct from an Islamic point of view by several relevant verses from the Holy

Quran and Hadiths of Prophet Mohammed (peace be upon him).

Likewise, Hameed et al. (2010) focused their investigation mainly on adopting an

enhanced version of software engineering principle based on Islamic ethical values to

help Muslim software engineers to understand ethics and implement them in their work.

As a result, a web-based database mode for Islamic ethics was developed.

Volkman (2015) studied the nature of computer ethics arguing that computer ethics

beyond simple compliance will have to be diverse and sensitive to the starting places of

various audiences. Earlier, Aljyu et al. (2010) examined the awareness of computer

ethics and security of undergraduate computer science students at the University of

19

Technology Malaysia and International Islamic University of Malaysia. The finding

indicated that there are satisfactory levels of awareness and male students reported a

higher level of violations than female. The findings indicated that female students are

more aware of ethics while using computer than male students.

Taherdoost et al. (2013) studied different conceptions and frameworks of computer ethics

from different perspectives. This review of many models and scenarios of computer

ethics indicates the need for this important topic for the current technology development.

In addition, previous studies show the need for computer ethics courses in educational

systems. As the future of education becomes more technology-driven and technology-

dependent, further studies are necessary for analyzing and anticipating the impact of such

trends. Scholarly research and empirical evidence of computer ethics behavior and the

effectiveness of various computer ethics policies and instructions are needed to enrich

and add to the existing body of research.

Heersmink et al., (2011) created the first bibliometric mapping analysis of computer and

information ethics. The map gives an overview and shows the relations between

information technology and ethical concepts. Moor (1985), on the other hand, discussed

what makes the computer different from other technology and how this influences ethical

consideration.

Thomson and Schmoldt (2001) examined the current ethical issues of software

development in relation to privacy, accuracy, property, accessibility, and effects on

quality of life. In their discussion, the authors stated that using an ethical approach to

software development may lead to the significantly increased likelihood of system

success. They also argued that in any system design methodology, the engineer should

not only focus on how the system and information should be used, but also on how the

system should not be used (Thomson and Schmoldt, 2001).

In the field of software engineering, massive research was conducted in the early and late

1990’s led by Gotterbarn and his team and jointly sponsored by ACM and IEEE

20

(Gotterbarn et al., 1997, 1998, 1999). The purpose was to identify a set of code of ethics

to be used not only as a guideline for professionals in the field, but also to educate them.

The ACM/IEEE code of ethics was established with eight principles, as follows:

1.1 Contribute to society and human well-being

1.2 Avoid harm to others

1.3 Be honest and trustworthy

1.4 Be fair and do not discriminate

1.5 Honor property rights including copyrights and patent

1.6 Give proper credit to intellectual property

1.7 Respect the privacy of others

1.8 Honor confidentiality

Research as reviewed above, have become the catalyst to more research in the field of

Software Engineering code of ethics. The establishment of the Software Engineering

Code of Ethics (SWECOE) has become the backbone in research and practice in this area

and the foundation for the establishment of an ethical framework for professionalism.

Lurie and Mark (2015) proposed an ethical framework for software engineers by

proposing an approach to fundamental tasks of the practitioners: to deal with challenges,

non-successes and failures in software development projects. This is called ethical-driven

software development. The researchers also stated that following an ethical approach

would lead to better engineers. For example, as there are different solutions for a

problem, an ethical framework will provide a guideline within the software development

process that will help the engineer to evaluate the advantages and disadvantages of each

solution (Lurie & Mark, 2015).

The ethical framework is an Ethical-Driven Software Development (EDSD) which is

inherently connected to the day-to-day activities of the software engineer in developing a

software. The proposed ethical framework is a set of yes/no ethical questions related to

each software development phase that each stakeholder must be aware before each phase.

The EDSD Yes or No Questionnaire is given in the following list:

Initiation phase

1. Are there criteria for adjusting the organization to examine the initiation?

2. Are there criteria for approval of product initiation, which should be particularly

demanding in fields where the organization or developer is not an expert?

21

3. Are there criteria to which the supplier accordingly agrees to offer a product that is

being developed for a new field?

4. Is the supplier knowledgeable enough about the resources with which s/he must work?

5. Is there a mechanism to ensure that supplier agreement pertaining to the project at hand

was obtained only after determining whether the organization or developer has the ability

to carry out the project?

6. Has it been determined who would make decisions on behalf of the client?

7. Has it been determined who would approve the budgetary flexibility for project

management?

8. Has it been determined who would be the authority who deals with the abnormalities in

the scope of work?

Requirements phase

1. Has it been determined who would define the requirements?

2. Are there mechanisms in place to determine the path of action when one or more of the

functional requirements cannot be achieved is discovered?

3. Are there mechanisms in place to determine the path of action when the customer is

demanding?

4. Is there a procedure in place to define the course of action if, during the planning

requirements phases, it is discovered that fulfilling the customer’s demand will lead to

negative consequences and possibly contradictory and illegal outcomes?

5. Is there a mechanism in place to prioritize requirements?

Design phase

1. Are conditions set to determine the level of commitment to developing a reuse

approach?

2. Are conditions set to determine the level of commitment to the development of all

standards methodology—for example, Design Pattern in object-oriented analysis and

design (OOAD)?

3. Would it be easy to fit in the design diagrams?

4. Do you think you should use more design diagrams?

5. Can someone who is not an expert fit in the diagrams?

6. Are the diagrams clear enough?

7. Is there sufficient attention to details?

8. Is the level of detail sufficient?

Development phase

1. Are conditions set to select the encoding language?

2. Are conditions in place for integrating young and less experienced developers?

3. Are conditions in place for integrating the advanced capabilities of the code

management? What are the timings and environmental parameters

4. Is it easy to orientate the code you wrote?

5. Do the comments have sufficient clarity?

6. Is the code compatible with the design diagrams?

Testing and verification phase

22

1. Has the level of allowed errors been determined before there is a transfer of the

product to acceptance testing been set?

2. Is a mechanism that distinguishes between a quality product and

a correct product in place?

3. Is a mechanism that determines whether the required tests were performed in place?

4. Is there a set of mandatory tests?

5. Are the metrics for determining the level of required tester training defined?

(Lurie and Mark, 2015)

2.5 Summary

The main reason for choosing this research topic is that there is limited research in the

area of software engineering code of ethics practices within software development

projects. The relevant research reviewed was mainly in the area of computer ethics and

information security ethics rather than software engineering ethics. Moreover, the

available research on software engineering ethics mainly describes the importance of

ethics in the field of software engineering, and why and how ethics should be added to

software engineering curriculum.

This research found out for the first time that ACM and the IEEE-CS jointly approved

Software Engineering Code of Ethics and Professional Practice, and this factor provided

strong support to the purpose of the research as it was not part of my study. The study

fills the gap in research in this area, especially on how ethics is being practiced within

software development projects.

23

CHAPTER 3 – METHODOLOGY

In this chapter, the research approach is explained in detail. The case and unit analysis are

described and defined. The research instruments are described along with the methods

used to answer the research questions and fulfill the research objectives. The chapter

concludes with a presentation of the research analysis.

3.1 Research Approach

This research is categorized as an exploratory case study. This means that this research is

qualitative in nature. A case study research is an exploratory investigation of a particular

existing phenomenon within its real life environment using various sources of evidence

(Runeson et al., 2012).

According to Baxter and Jack (2008), “..qualitative case study methodology provides

tools for researchers to study complex phenomena within their contexts. When the

approach is applied correctly, it becomes a valuable method for health science research to

develop theory, evaluate programs, and develop interventions” (Baxter & Jack, 2008).

Runesan et al. (2012) stated that case study research strategy is commonly used in areas

such as psychology, sociology, social work, etc., not only to increase knowledge but also

to improve education or social care. Moreover, software engineering research usually has

similar high-level objectives which are to understand how and why software engineering

should be undertaken to improve the software engineering process and the software

product (Runeson et al., 2012).

In software engineering, the term case study is used parallel with terms like observational

study and field study (Runeson et al., 2012). Runeson & Host (2009) defines case study as

“… a strategy for doing research that involves an empirical investigation of a particular

contemporary phenomenon within its context using multiple sources of evidence.”

24

Likewise, Yin defined case study as “… an empirical inquiry that investigates a

contemporary phenomenon within its real-life context, especially when the boundaries

between the phenomenon and its context are not clearly evident” (Yin, 2003). Runeson et

al. (2012) defined case study in software engineering as “an empirical enquiry that draws

on multiple sources of evidence to investigate one instance (or a small number of

instances) of a contemporary software engineering phenomenon within its real-life

context, especially when the boundary between phenomenon and context cannot be

clearly specified.”

This research is, therefore, following an exploratory case study research approach, as

defined earlier, to explore, study and analyze how software code of ethics is being

applied throughout the software development life cycle.

3.2 Research Design

In this research, we investigated how ethics is being practiced within software

development projects. In addition, this research was also carried out to understand how

the ethical clauses are used and understood, and the degree of challenge and risk as

perceived by the engineers and developers on the first four principles of the Code of

Ethics and Professional Practice by ACM and the IEEE-CS. Finally, this research also

seeks to propose a new classification for the four principles of the code of ethics based on

the software development life cycle phases.

This study used different data collection techniques to research as suggested by Yin

(2013). Both qualitative and quantitative data collection analyses are used in order to

achieve the research objectives. Qualitative data collection techniques such as in-depth

interviews can provide rich and in-depth information about the experiences of individuals

(DiCicco-Bloom & Crabtree, 2006).

The research methodology that was used in this research followed the case research

design suggested by Yin (2013), as discussed earlier. The design started with problem

identification, followed by a literature review of relevant studies, and data collection

using questionnaire, interviews and document analysis. After that, the results were

25

analyzed using content analysis and analyses, in order to answer the research questions

and achieve the research objectives. Based on the framework derived from the findings, a

scenario-based session was conducted to validate the framework. Figure 3.1 shows the

research approach followed in this study.

Figure 3. 1 Research Design Diagram

3.3 Case Study

The case study is based on the SADAD Payment system. The business nature of SADAD

is that it hosts many software projects and employs more than 100 software engineers.

The company builds critical systems that provide important services to the customers.

Many projects under this category will go through the common SDLC (Software

Development Life Cycle) and waterfall techniques. All these projects involve the

development of application systems that undergo constant changes to adapt new

technologies (such as Oracle upgrades), information update (i.e., address issues), fixes,

and constant changes in customer requirements, etc. Therefore, this company is seen as a

good fit for the case studied in this research. Moreover, having the researcher as one of

the company employees provided the advantage by having an easy access to the

organization’s information in order to collect data and complete the research.

26

SADAD was launched on October 3, 2004 by the Saudi Arabian Monetary Agency

(SAMA). It acts as an Electronic Bill Presentment and Payment (EBPP) system for the

Saudi nation by streamlining bill payment transactions of end customers through all

banking channels in KSA. This EBPP system intricately links banks in Saudi Arabia with

a respectful number of medium to large sized billers such as government agencies and

private businesses (SADAD Payment System official website). Before SADAD was

created, in order for an end-user to pay his bill, he would need to visit the biller branches

or make payments through specific banks. Nearly 60 to 70 per cent of bills were paid

through bank branches in cash. This was costing the banks more than the profits they

were making (AL-Adwan et al., 2013).

Before SADAD, some major billers attempted to enhance its customer service by

enabling their customers to use their bank channels to pay bills from any banks in KSA.

This required a connection within banks. Similarly, each bank will connect separately

with each biller. Then, SAMA introduced SADAD to facilitate the payments by having a

single platform that links different billers and banks to enable customers to use the banks’

respective electronic channels (AL-Adwan et al., 2013). Figure 3.2 provides an overview

of how the organization functions in relation to its customers.

SADAD’s vision is “One solution for all payments.” Similarly, SADAD’s mission is “To

develop new payment products and services to lead the financial services sector towards

high levels of service, for individuals, business and government sectors. This will be

achieved through the development and operation of an efficient and secure infrastructure

based on national and international standards and in accordance with industry recognized

best practice” (SADAD Payment System official website).

27

Figure 3.2 SADAD Overview (SADAD Payment System official website)

A number of research has been conducted using SADAD as a case study. One research

by AL-Adwan et al. (2013) studied the impact of having an electronic bill payment on

banks’ profitability. The research focused on SADAD’s Electronic Bill Presentment and

Payment system’s impact with reference to banks’ profitability by focusing mainly on

Return on Assets (ROA) and Return on Equity (ROE). The study presented three

different arguments on the relation between technology and profitability: the first group

believes that there is a link between technology and profitability, the second group argues

that there is no link between technology and profitability, while the third group believes

that there is a link between profitability and technology with reference to network impact.

The study was conducted by presenting an empirical study of the Saudi e-payment

system. By looking into these six pillars: Convenience, Different Choice, Cost reduction,

Security and Accessibility, the statistical analysis of ROA and ROE showed the

significant role of e-payment in enhancing banks profitability.

Another research by Al Sudairi et al. provided a thorough description of SADAD, the

purpose of SADAD, and listed the advantages of using SADAD for banks, billers and

end users.

In the current study, after SADAD was selected as the focus of the case study, contact

was established with the organization in order to acquire permission to conduct the field

work. Appendix B shows the permission and approval letter received to conduct the

research in the organization, subject to confidentiality.

28

Field visits to the research site started with the analysis of documents on policies,

procedures, and projects management. This is followed by interviews with experts and

questionnaires filled by software engineers. Interviews were conducted with software

development project team members who are working on different software development

projects and holding various positions. This was carried out to investigate how Software

engineering code of ethics is being implemented within the software development

projects, and to help in developing the proposed framework of the software engineering

code of ethics.

Likewise, the questionnaires were distributed to software engineers with various years of

experience. The purpose is to answer the research questions by continuing to understand

how the code of ethics under investigation can be categorized based on the SDLC phases,

and to understand each ethical clause level of challenge and risk perceived by the

participants.

After analyzing all results, a SWECOE framework was proposed. This proposed

framework was evaluated by practitioners in the field. Following this, a scenario-based

simulation was conducted to validate some elements in the framework. A session was

conducted with three practitioners to validate the framework using actual cases of two of

SADAD projects. These cases become the scenario for simulation. The simulation was

developed and conducted to test the situation with and without the placement of the

proposed SWECOE in the research framework. The factors tested in the simulation were

cost and time. The simulation was further verified by practitioners in the field during the

session.

3.4 Data Collection

Three types of data collection methods were used in order to achieve the research

objectives using the case study approach (Lethbridge et al., 2005; Merriam, 1998). In

order to meet the research objective which is to investigate how Software engineering

code of ethics is being implemented within the software development projects in

SADAD, SADAD documents, policies, procedures and project documentations, were

procured and analyzed.

29

In addition, unstructured preliminary interviews were conducted with three of SADAD

software engineers with minimum seven years of experience in software development.

Table 3.1 provides the overview of the interviewee profile. The interview questions are

provided in Appendix C.

After conducting and analyzing the interviews, the results of the analysis were later used

to refine the questionnaires before distribution to software engineers. The questions went

through several validation processes from two engineers until it was agreed that the final

version was clear and addressed the research objectives. Google drive was used to

administer the questionnaire. Appendix D provides the sample questionnaire used. As a

result of the survey administration, 17 responses were received from engineers with

different years of experience. This number was considered sufficient for analysis as the

result and discussion were qualitative. The responses allowed the researcher to establish a

Table 3. 1 Interviewee Overview

Interviewee Years of

experience Role

Role description

1-

6 years Quality control

manager

product verification

1 year Quality assurance

manager

To make sure that all the SDLC processes

meet the agreed standards

2- 7 years

Business Analyst

& service change

manager

As a change manager, we facilitate the

changes of SADAD system which is the

EBPP. There are 3 types of changes: new

business for biller or bank, enhancement of

current feature of fixes to our system.

As BA, we collect the requirements for

these changes, to elicit the requirement,

validate the requirement and then

document them, get the approval from the

stakeholder and then go through again the

change management process.

3- 10 years

Software

development

manager

30

sound knowledge on the categorization of code of ethics based on their background and

experiences.

Table 3.2 below shows the summary of research objectives and data collection strategies.

As outlined by Yin (2003) and Lethbridge et al. (2005), a case study research method

allows for multiple data collection points, based on the purpose and nature of the research

questions. Different research questions may require different techniques in data

collection. The evidence was later compiled to match the overall objectives of the

research.

Table 3. 2 Summary of research objectives and data collection strategies

# Research objectives

Description of the method

1.

To investigate how Software

engineering code of ethics is being

implemented within the software

development projects

A case study by analyzing how code of ethics is

being practiced on a well-known financial company

in Saudi Arabia (SADAD).

Reading and analyzing policies, procedures and

projects documents.

Interview software engineers

2. To investigate which software

engineering code of ethics is perceived

to be the most challenging to follow.





Distribute questionnaire

3. To investigate which software

engineering code of ethics is perceived

to be of a high risk.




Reading and analyzing policies, procedures and

projects documents.



4.

To propose a classification of the

software engineering code of ethics

based on the software development

life cycle phases.


5. To propose a framework of software

engineering code of ethics within the

Analysis of evidence from all data collection

techniques

31

software development life cycle. Scenario-based simulation conducted with

practitioners to validate the framework

3.5 Data Analysis

Data analysis was conducted using qualitative technique of content analysis suggested by

Yin (2003) and Huberman et al., (2002) and descriptive analysis based on rating in scale

and count. The data was analyzed using purposefulness technique by gathering evidence

that helped answer the research questions. No relationship analysis was established

between constructs or variables as this was not part of the research objective. For

qualitative data gathered from interviews the tools used for the analysis was Excel

spreadsheet where data was tabulated in tables through logical coding that relates to the

research problem. An example of how data is tabulated is provided in Appendix F. The

coding helped in classifying the responses and establishing patterns, which further

allowed answering the research questions. The results are presented in Chapter 5, in a

manner that shows how each finding is mapped to the responses. Common analysis tool

like NVivo or Atlasti for analyzing text are not used because the text amount was

considered manageable by using only Excel.

Other types of analysis involved descriptive statistical analysis using counts and averages

to describe the frequency of the respondents’ responses. This is also followed by the

assignment of rating and weight score in the analysis.

Based on the literature review and the results of the analyses of the interviews and

survey, a draft of a framework was developed. The framework provided an overview of

how the software code of ethics could be used and made available at each phase of the

SDLC. This framework is only meant as a guide for the development of better quality

software and research guidelines.

A session with three practitioners to validate the framework using actual cases of two of

SADAD projects was conducted. Based on the scenario of the actual event, a simulation

is developed and conducted to test the situation with and without SWECOE, as proposed

32

in the study framework. The factors tested in the validation were cost and time. The

scenarios were verified by the practitioners during the session.

3.6 Summary

The research followed the case study research approach, as defined earlier, by analyzing

the documents of software development projects of one company, which is SADAD.

Unstructured interviews were conducted with experienced software engineers who were

working on different software development projects and holding various different

positions to study and analyze how software code of ethics was being applied throughout

the software development life cycle. In addition, questionnaires were distributed to

software engineers with different years of experience to investigate which software

engineering code of ethics was perceived to be the most challenging to follow and which

was perceived to be of a high risk category. Consequently, a framework of software

engineering code of ethics was proposed based on the SDLC phases. Finally, a scenario-

based session was conducted with practitioners to validate some elements in the

framework.

33

CHAPTER 4 – RESULTS AND DISCUSSION

This section presents the results of the study, and fulfills the objectives of this research.

These are identified as follow: to investigate how Software engineering code of ethics is

being implemented within the software development projects, to investigate which

software engineering code of ethics are perceived to be the most challenging to follow, to

investigate which software engineering code of ethics are perceived to be of a high risk

category, to identify an appropriate classification of the software engineering code of

ethics based on the software development life cycle phases, and to propose a framework

of software engineering code of ethics within the software development life cycle.

The results presented in this section are organized according to several subsections: how

code of ethics is being implemented, identification of high risk and most challenging to

follow SWECOE, SWECOE classified based on the SDLC phases, and a proposed code

of ethics framework at each SDLC. In each of these sections, evidence is provided

through a combination analysis using the case study approach with multiple sources of

evidence. They are document analysis, interviews, and questionnaires; followed by

scenario-based session conducted with practitioners in the field to validate the

framework.

4.1 How Code of Ethics is Being Implemented in SADAD

In order to investigate how Software engineering code of ethics is being implemented

within the software development projects (objective 1) in the case study, SADAD’s

project documents, policies and procedures were retrieved and analyzed. In addition, a set

of interviews were conducted with software engineers who worked in software

development projects in SADAD, and questionnaires were distributed to 17 software

engineers.

4.1.1 Document Analysis

In this section, SADAD documents were collected and analyzed for evidence of any

statements that request practitioners (employees, engineers, concerned stakeholders) to

observe any forms of code of conduct or address any matters pertaining to ethics or

34

ethical concern in software development. This resulted in the analysis of two relevant

documents, namely Requirement Verification and Validation Guidelines (RVVG), and

Business Analysis Performance Evaluation Guidelines (BAPEG).

Based on the analysis of the two documents, it was observed that software engineering

code of ethics was not documented explicitly as a separate code of ethics guidelines or

policy requirements. Many were written as part of other guidelines within development

process requirements.

The two sections describe the documents that were analyzed in the research, and indicate

how and in what manner they are being used and addressed in the company.

a. Requirement Verifications and Validation Guidelines

This document provides guidelines for verifying and validating stakeholder requirements.

This document is primarily intended for the business analysis team in order to help them

write verified and valid requirements free of common defects. Moreover, this document

is intended for other stakeholders concerned with verifying requirements in order to

understand the criteria for valid and verifiable requirement.

We found a number of criteria listed in the document referring to a quality requirement,

such as: clear, complete, valid, verifiable, consistent, solution independent and testable.

In the following Figure 4.1, a section from the document is presented that shows a list of

the criteria for a quality requirement followed by a description for each. For example,

complete requirement which means the document has no missing information, has a

documented priority and risk level, has no undocumented assumptions, etc.

35

Figure 4.1 Requirement Verification and Validation Guidelines – Criteria for a quality requirement

36

In another section in the document, a list of guidelines for how to write the requirements

is given in Figure 4.2, for example, avoid ambiguity by using complete sentences.

Figure 4.2 Requirement Verification and Validation Guidelines – Guidelines for writing requirements

statements

In addition, a criteria on how to validate a requirement is described in the document as

well. This is as shown below in Figure 4.3.

37

Figure 4.3 Requirement Verification and Validation Guidelines – Verifications Guidelines

b. Business Analysis Performance Evaluation Guidelines

The purpose of this document is to establish the guidelines for defining, documenting,

collecting and analyzing performance measurements for business analysts. This

38

document is intended for the business analysis team, service creation management and

appropriate management at SADAD to help them understand the guiding principles used

in defining the BA KPIs.

This document provides a number of business analysis goals such as: satisfy the end user,

provides a quality software requirements, meet stakeholders’ expectations in regards to

timely delivery of requirements, improve the efficiency of business analysis processes,

and how to measure them. For example, for “provide quality software requirement goal”,

it can be measured by defect density which is the number and severity of defects found in

the requirements artifacts. Figure 4.4 is a screenshot of the procedure.

Based on the analysis of documents in the case study, it was found that some policies,

procedures, and guidelines are available to guide software engineers in their projects.

However, there is no separate document that directly addresses the ethical concern that

would serve as a guideline for the software engineers. There is also no evidence of code

of ethics guideline at the overall organizational level.

4.1.2 Interview Analysis

Figure 4. 4 Screen shot from Business Analysis Performance Evaluation Guidelines document

39

This section seeks to provide more input and evidence on the use of code of ethics in

projects according to the employees. Accordingly, three in-depth unstructured interviews

were conducted with software engineers in SADAD, who have more than 7 years of

experience each. They were: a Business Analyst, a Software developer, and a tester.

Questions were asked relating to the practice of ethics throughout software development

projects. The following results are organized according to (a) ethical concerns and

importance, and (b) how ethics is observed with each SDLC.

a. Ethical Concerns and Importance

The interviews showed that, employees are, in general aware of the importance of having

a clear code of ethics in the workplace as a guidance for various security reasons. Many

of the interviewees have long years of experience in developing software at various

phases. Based on their perspectives, several areas can be highlighted as reasons for the

importance of having a code of ethics. These are categorized as follows:

Protection from harm for the organization and the users

Respondents indicate that having a code of ethics in place can provide the

necessary protection for the organization and the people. By having the Code of

Ethics, the guidelines can be enforced and followed and misconduct can be

avoided.

Increase productivity

Other evidence from the point of view of the respondents indicates that a clear

code of ethics can increase organizational productivity.

Professionalism

Professionalism is highly important in providing respect and establishing a sound

reputation for any profession. A good developer can only be established through a

reputation of having a good integrity in the development process. Having the

Code of Ethics clearly written and followed can enhance this outlook and benefit

the workers and the organization.

40

Avoid troubles

Having a Code of Ethics and complying with it helps in preventing the software

engineer from being in trouble such as breaching confidentiality, integrity, and so

on.

Maintaining integrity

To maintain integrity in development is to follow a set of ethical conducts. The

only evidence to good integrity is to have a clear code of conduct at various levels

and different phases in the development.

Ensure quality

The overall quality of a good software development will require the degree of

observation of ethical conducts, for example, the issue of writing a strong code

versus a weak code and the time required to complete. There must be a clear

boundary between cost saving practices and maintaining safe and secure

applications.

Increase company morale

One of the participants believes that having a clear code of ethics, with clear

consequences of misconduct and the benefits of following code of ethics will

increase the organization’s morale.

Table 4.1 below provides the reasons as evidence for the importance of having a clear

Code of Ethics policy and guidelines, as analyzed. The sample responses are provided to

illustrate the reasons, respectively.

Table 4. 1 Reasons why having code of ethics is important

Reasons Participant Can you tell me how ethic is important in your

work?

Protection P1 Because, what I see it protects everyone, its protects

41

the organization. It protects the people, so it’s like one

of the very important aspects that everyone has to take it

in his consideration, while he is working in any

company and this organization is one of these examples.

Productivity

P1

I believe if we have a clear ethics, if we have a clear

standard about these ethics, everything will be fine, and

maybe the productivity of the organization will be

better.

Increase

company

morale

P1

They have to consider those factors because this will

increase the morale of the team if we do not have a clear

standard and we do not know what are the consequences

if you do not have them and what’s the benefits if you

have them and what are the impacts if you do not have

them; I think is going to be better for us.

Professionalis

m

P2

Of course ethics is connected to professionalism, so the

more you apply work ethics the more you are considered

as a professional person and your conduct is appreciated

by others.

Avoiding

troubles and

Maintain

integrity

P2

Also, by applying ethics I guess you’re supporting

yourself and preventing yourself from being in

trouble; trouble that can go into confidentiality,

integrity whatever that can be a bad experience for

yourself.

Quality P3

In my view, I think ethics is something very important;

the reason behind it is if we do not have ethics in

anything, there is not any quality that is going to be

delivered right.

Those findings are in line with Rogerson (2002) who stated that when the public are

aware that the organization is adopting a code of ethics, this will increase their reputation

and the public trust as they will be confident that the organization will produce quality

software in their best interest by complying with high standards of quality. Similarly,

adopting a code of ethics will attract dedicated and hardworking employees as they know

that the organization is complying with high standards and aims to produce high quality

software. Moreover, the Software Engineering Code of Ethics and Professional Practice

provides a clear guidance on how to make decisions related to software development

(Rogerson, 2002).

42

b. How Ethics is observed within Each SDLC Phase

The earlier analysis indicates that there is no evidence that a clear guideline for ethics

exists at the institutional level. However, it is also generally agreed that having a clear

guideline for observing ethics is highly important for reasons such as protecting the

organization and users from harm, increasing productivity, avoiding trouble, maintaining

professionalism, ensuring quality, and maintaining integrity. In this section, respondents

are asked how software code of ethics is practiced within each SDLC phase. In response

to this question, the respondents raised several ethical concerns in each of the SDLC

phase: requirement, design, code, testing and maintenance. These ethical concerns

resulted in further analysis to provide the framework for a code of ethics in software

engineering practices. The following sections describe how ethics is observed throughout

the software development projects in SADAD based on the analysis of the interview

results.

Requirement phase

The first phase of the SDLC is the requirement phase which is the process of establishing

the customer requirements and system constraints (Sommerville, 2004). Wiegers and

Beattly (2013) define requirement as “a statement of a customer need or objective, or of a

condition or capability that a product must possess to satisfy such a need or objective.”

This phase is considered critical because, depending on how the information is gathered,

whether it is correct or ambiguous, the end product will depend on this information. The

quality and the success of the software development project will highly depend on the

information gathered at this phase (Polga, 2008).

Accordingly, the requirement phase is perceived by one of the interviewees to be the

most difficult phases of the SDLC phases. The analysis of the interviews indicates that

several ethical concerns need to be addressed. Table 4.2 summarizes the ethical concerns

of the requirement phase, from the perspectives of the employees interviewed. The

ethical concerns are categorized, as follows:

Vague requirement

43

The first step in this phase is requirements elicitation, in which the business analyst will

play his important role in getting all the important information to feed into the stages that

follow (Polga, 2008). In some situation, stakeholders (i.e., clients or sponsors, users) are

not able to express what they need and require time to understand their requirements. It is

challenging for the Business Analyst to understand the requirements without the proper

methodology and the right knowledge and skills. Under these circumstances, there can be

situations where insufficient requirements are provided leading the project to be highly at

risk of failure.

Conflict of interest

The first refers to the compromising of quality due to constraints. If the software

development is done by a third party (i.e., vendor), conflict of interest is likely to occur.

For example, problems or requirements may have either several solutions, an easy

solution or a hard solution. The software engineer will be facing the issue of choosing

either the best solution or the easy solution. If he chooses the easy solution, due to some

constraints such as time and resource availability, he may be compromising the quality of

the software.

The second refers to compromising constraints (i.e., quality, time and cost) by promising

unachievable stakeholder request. The requirement phase is the first phase in the SDLC

that requires a huge interaction with the stakeholders to understand their needs and

expectations. Usually, the stakeholders do not have much knowledge of the software

development projects and their constraints. So they might ask for something that is not

achievable, which may lead the software engineers to violate their ethical principles to

meet those requirements.

Software engineers misrepresenting the actual cost, time or complexity

Sometime software engineers do not estimate an accurate effort; they tend to

overestimate in order to meet the targets.

Table 4.2 provides the evidence from the systematic analysis of the interviews, following

the categories reported above.

44

Table 4.2 Ethical concerns on the requirement phase based on the interviews

Ethical concerns Participant Requirement phase

Conflict of

interest

P1

I think requirement is the start point and the most

difficult part; at this stage there is the customer (I’m

giving you this from my experience) now when I start

the interaction with the customer, the ethical issues

might come at this stage; the customer may ask for

things beyond the expectation and in order to achieve

them and get the customer satisfaction, you might

exceed or you might violate your ethical issues in

order to achieve this. So I think this is very important

point, it has to be addressed very well at this level.

P2

Ok, first thing is when you receive requirements for

example, as a third party, some requirements might be

difficult to develop and some might be easy to

develop so ethically you should not go with what’s

easy to develop but rather what’s best for the

stakeholder asking you for this requirement, so you

apply ethics of knowing the best for your customer

and doing it even if it’s not the best solution for

yourself as a third party.

As I said, ethically you should support the best for the

requester and not the easy solution, rather any

different solution you might think of. Or you know

that this not satisfy him but you do not say it. So you

should make him aware of what he asking for and

what he is receiving.

Software

engineer

misrepresenting

the actual cost,

time or

complexity

P2

From a change management perspective also, the

ethics that you should apply is when you facilitate this

change; I would say the time consumed; whenever a

request come the requester doesn’t know the

complexity of this so you can say it’s very complex. It

will take me a month or you can say it’s very easy

that it going to take me a week. So again. ethically

you should support this.

Vague P3

Ethical practice sometimes it will be or it’s hard for

BA to dig further into what exactly the client needs.

45

requirement

Generally and it’s been identified that there are 50%

who know what they need and the other 50% who do

not know what they need. They want something like

that they just will give comparison there; the BA

should go much deeper not just as project point of

view. If I know that this requirement going to be

easier tougher it should not be that way. He should

separate that and he should be collecting everything

not what I like.

Design phase

Similarly, the design phase which is the second phase in the software development

project, includes the definition of the solution of the problem specified by the

requirements (Jalote, 1997). Software design may refer to either "all the activities

involved in conceptualizing, framing, implementing, commissioning, and ultimately

modifying complex systems" or "the activity following requirements specification and

before programming, as ... [in] a stylized software engineering process” (Freeman &

Hart, 2004).

The analysis of the interviews indicates that there are several ethical concerns in the

design phase that need to be addressed. Table 4.3 provides a summary of the ethical

concerns about the design phase based on the interviews. These ethical concerns are

categorized as follows:

Compromising quality to meet time, cost or available resources

Each problem may have different design solution with different complexity so it is the

responsibility of the designer to choose the one that best fit the stakeholder needs and not

the easiest solution. In our case, it is much more complex since the SDLC is done by a

third party, which the team would most likely think that what is best for them as a third

party rather than what is best for the stakeholders. For example, if there is a limitation of

some specialized resources or time, or a regulation and there is need to comply to a

specific deadline, the design should be driven from the best solution rather than the

46

hardship of the situation. Given this important point, the developer must always be able

to meet cost and time constraints of the customer’s budget. This may mean that the

developer and customer could work out a compromise in order to achieve the most

ethical solution possible.

Designing weak codes

Software is developed to solve problems, and each problem has several solutions. As one

of the participants said, “…the software engineer may design weak code which is prone

to hacking.”

Table 4.3 Ethical concerns about the design phase based on the interviews

Ethical concerns Participant Design

Designing weak

code P2

For the design, I would say that you can say, its

depends on the company, for example, you can

design a code that is prone to hacking, let say weak.

Compromising

quality to meet

time, cost or

because of the

available resources

P3

If you see that a problem can have many designed

solutions. From requirement, it will come to

architecture then design and all that. Again, from a

design point of view, it has something with man

days right so you will design and complexity

generally what happens from the bottom up the

manager is there and his going to tell you that there

is a limited recourse of JAVA resource, something

like that. I feel that the design should not be bound

to something like that. it should be dependent and

directly it affects us. It should provide more ethical

value not something driven from circumstances and

situations. All that it should come from what is the

best approach to do that.

Coding phase

47

The Coding phase involves translating the design of the system into a code using a

programming language (Jalote, 1997). The analysis of the interviews indicates that there

are several ethical concerns about the implementation phase that need to be addressed.

Table 4.4 provides a summary of the ethical concerns about the coding phase based on

the interviews. These ethical concerns are categorized as follows:

Developing weak code

The developer can develop two kinds of codes which both fulfill the requirements; one

can be prone to hacking (weak) and the other one is a strong code.

Not complying to best practices and policies

Depending on the organization and the criticality of the code, there may be a set of

guidelines or policies the developer has to comply with. Some of them are quality

standards and some of them are security standards. The developer should be aware of

them and comply with them. Ethically, if they are not followed, the circumstances may

be fatal.

Table 4.4 Ethical concerns on the coding phase based on the interviews

Ethical concerns Participant Code

Not complying to

best practices and

policies

P2

There is a strong code and a weak code; sometimes

writing a weak code or not following the best

practices for coding may make it simple and easy to

change. However, ethically you should not; you

should go with tried coding practices.

Developing weak

code

P3

From development point of view, as I said I gave you

one example; about fixing a bug. Here, from an ethical

point of view, what I feel is fixing the bug (I’m going

further) that can be a bug that fix the problem and

there can be bug that postpone the problem. That there

are way as sometime we cannot cover it up

completely, we just have bugs not been fixed

completely we give it the production, we going to

48

solve this and we know that this will be opened again

in a while. Just because the pressure is on I think this

the one and I feel software development should be

separate from that concern. I just give you an

example; it can be many.

Testing phase

The testing phase is the process of validating and verifying that the software is working

as expected and meeting its requirements (John, n.d.). According to Williams (2006),

“software testing is the process of analyzing a software item to detect the differences

between existing and required conditions (that is, bugs) and to evaluate the features of the

software item.”

The analysis of the interviews indicates that there are several ethical concerns about the

testing phase that need to be addressed. Table 4.5 provides a summary of the ethical

concerns about the testing phase based on the interviews. These ethical concerns are

categorized as follows:

Releasing software with defects to meet the scheduled time

Sometimes, the testers release software with some issues, deficiencies, or of low quality

usually due to meet a deadline. As one of the interviewees mentioned about one incident

that occurred, “...they released software with some issues knowing that it will cause a lot

of issues in production but they released it to meet the planned time.”

Certifying/passing release with defects without knowing its exact effects

Some defects in the software are acceptable. However, the problem is that if those defects

are major, they will consequently have major effects on the users and the public.

Table 4.5 Ethical concerns on the testing phase based on the interviews

49

Ethical concerns Participant Test

Releasing software

with defects to meet

the scheduled time

P3

Now the ethical might be between the team for

example between the testing and the

development. When I was managing the testing

team, I was facing a lot of issues between the

development and testing, Sometimes, we, in

some words sometimes we do not accept the

way they are developing the system so a lot of

clashes introduced and some classes can

introduce some ethical issues and some time we

disregard their work. We disregard the quality of

the work they deliver, so we consider they do

not work as what they supposed to do, do you

get my point? So, it does reach to the level.

Certifying/ passing

release with bugs

without knowing its

exact effects

P2

Testing again is testing for scenarios and, for

example, if you are aware of the SDLC,

sometimes when you find a bug or a gap, there is

certain stuff that you can pass them and say that

this bug is fine and can pass the release. Again,

when you pass this release, ethically you should

know that it will not cause any issues with your

client, with SADAD, with different client billers

or banks. Saying this is minor, Let’s pass it,

however, you know that no, actually this is a

major one.

P3

Testing point of view it goes there like as I go it

can be same as reporting the bug. There are

pressures on and then there is a blocker blog,

then it’s been fixed to become a functional bug.

In their consciousness, they have to report

whatever. They should not assume or presume

this will not happen, they should think it from

production point of view like software developer

give this bug and they have to assist this as a

production point of view. Like what would

happen and if they have. And SADAD specially

what I feel is like if they have an environmental

problems, they may compromise a bit, They will

50

assume that this recourse will access this

database and then problem will not going to

come, they just compromise that. I think from an

ethical point for view, there should be zero

compromise.

Maintenance phase

Finally, the maintenance phase is the process of modifying software or software

component after delivery (Reifer, 2011). The analysis of the interviews indicates that

there are several ethical concerns about the maintenance phase that need to be addressed.

Table 4.6 provides a summary of the ethical concerns about the maintenance phase based

on the interviews. These ethical concerns are categorized as follows:

Compromising the environment

Sometimes, software engineers compromise the environment by not validating and

testing the environment configuration and they assume that the same configuration is

applicable for new releases.

Table 4.6 Ethical concerns on the maintenance phase based on the interviews

Ethical

concerns

Participant Maintenance

Compromising

the

environment

P3

Compromising the environment by not validating the

configurations and they deploy this package. And

sometimes they assume that same configuration will

affect this package. Again, they assume of whatever

activities may take.

Table 4.7 summarizes the ethical concerns about each SDLC phase based on the

interviews.

51

Table 4. 7 Summary of the ethical concerns about each SDLC phase

SDLC Phase Ethical concern

Requirements

Conflict of interest

Vague requirement

Software engineers misrepresenting the actual cost, time or complexity

Design

Designing weak code

Compromising quality to meet time, cost or available resources

Coding Not complying to best practices and policies

Developing weak code

Testing Releasing software with defects to meet the scheduled time

Passing release with minor bugs without knowing its exact effects

Maintenance Compromising the environment

4.1.3 Questionnaire Analysis

Questionnaires were distributed to software engineers to investigate the ethical concerns

of each SDLC phase. 17 responses were received from participants with different years of

experience as shown in Table 4.13 and their perspectives vary as shown below in Table

4.8. In this part, the respondents were asked open-ended question to indicate the ethical

concerns at each phase in the process. Appendix D and Appendix E provide the

questionnaire sample and Questionnaire results and data analysis, respectively. Table 4.8

presents the respondents’ answers to the question: “In your point of view, please provide

the most common issues of ethics that you believe need to be addressed at each SDLC

phase.”

Table 4.8 Ethical concerns about each SDLC phase from the interviewees’ perspectives

52

SDLC Phase Ethical concern

Requirements

Technical/solution knowledge

Compliance with rule and regulation

Not to build the requirement based on personal needs or support of a

certain technology

Honesty in meeting customer needs

Training customers as they learn their needs because customers may not

know their needs well - it is unethical to build requirements knowing the

customer is uneducated in describing their needs

Maintain the integrity of data, being sensitive to outdated or flawed

occurrences.

Ensuring proper security, privacy and that these are part of requirements

from start.

Identify clearly requirement from the end user perspective

Design

easy vs right way of design

Not to create the design based on personal needs or support of a certain

technology

Follow the correct design standards, to use incorrect design templates and

to not verify design has properly designed the requirements.

Not engage in deceptive financial practices such as bribery, double billing,

or other improper financial practices.

Ensuring proper security, privacy and that these are part of design from the

start.

Coding

Crack codes

Non-compliance with the company policies

Not to create harmful code

Following the correct coding standards

Verifying you have coded the design and trace code back through design

to the requirements.

Ensure an appropriate method is used for any project, current or proposed.

Not cutting corners

using a standard code

Testing

Not to jump certain cases to save time and reduce cost

Following correct standards

Performing traceability

Not doing a quick and dirty job

Not passing software when it is known to be faulty

Accept no outside work detrimental to the work they perform for their

53

primary employer.

Providing adequate testing.

Maintenance

Too much work around

Creating issues that were not part of the main release

Not engage in deceptive financial practices such as bribery, double billing,

or other improper financial practices.

Treat all forms of software maintenance with the same professionalism as

new development.

Providing long term maintenance.

Troubleshooting any issue

4.2 Identification of High Risk and Most Challenging SWECOE to Follow

At the end of 1998, ACM and the IEEE-CS jointly approved Software Engineering Code

of Ethics and Professional Practice to encourage software engineers to undertake positive

actions and to resist pressures to act unethically.

This Code of Ethics contains eight principles that software engineers need to adhere to in

order to develop software. The focus of this research is on the first four principles, and

they are Public, Client and Employer, Product and Judgment. As part of this research is

to investigate which of the software engineering codes of ethics are perceived to be the

most challenging to follow and which perceived to be a high risk category, a structured

and non-structured questionnaire was distributed to software engineers. The participants

were asked to rate a 7 point Likert-scale (1 as least challenging to follow and 7 as most

challenging to follow) for each clause pertaining to the degree of “challenging to follow”.

Likewise, on the risk of each clause, 1 as perceived with low risk and 7 as a high risk

code of ethics. 15 responses were received, and the average of each clause is reported in

the following sections.

4.2.1 High Risk and Most Challenge SWECOE to Follow

This section presents the results of the investigation of how software engineers perceived

ACM/IEEE SWECOE risk rating for each clause of the four principles, After getting the

average score for each clause rated by the questionnaire participants, the researcher

54

prioritized the list based from the perceived high risk to the low risk. In addition to the

software engineers’ perceptions of the most challenging ACM/IEEE SWECOE, each

clause of the four principles is also reported with the average score for each clause rated

by the participants.

Principle 1 – Public

Public is the first principle of ACM/IEEE SWECOE and refers to how software

engineers should act consistently according to the public interest. Table 4.9 presents the

Public principle clause listed from the high perceived risk to the low risk after calculating

the average score for each clause.

Table 4.9 Public principle clause based on the risk rating

Clause Risk

(1-7)

Challenge

(1-7)

1.3 Approve software only if they have a well-founded belief that it

is safe, meets specifications, passes appropriate tests, and does not

diminish quality of life, privacy or harm the environment. The

ultimate effect of the work should be to the public good.

5.4 4.8

1.1 Accept full responsibility for their own work. 4.93 4.7

1.4 Disclose to appropriate persons or authorities any actual or

potential danger to the user, the public, or the environment, that they

reasonably believe to be associated with software or related

documents.

4.8 4.2

1.6 Be fair and avoid deception in all statements, particularly public

ones, concerning software or related documents, methods and tools. 4.2 4.3

1.2 Moderate the interests of the software engineer, the employer,

the client and the users with the public good. 4.1 4.5

1.5 Cooperate with efforts to address matters of grave public

concern caused by software, its installation, maintenance, support or

documentation.

4.1 4.1

1.7 Consider issues of physical disabilities, allocation of resources,

economic disadvantage and other factors that can diminish access to

the benefits of software.

4 4.2

1.8 Be encouraged to volunteer professional skills to good causes

and contribute to public education concerning the discipline. 2.6 3.2

55

Principle 2 – Client and Employer

Client and employer is the second principle of CM/IEEE SWECOE and refers to how

software engineers should act in a manner that is in the best interest of their client and

employer, consistent with the public interest.

Table 4.10 presents the client and employer principle clause from the perceived high risk

to the low risk after calculating the average score for each clause.

Table 4.10 Client and employer principle clause listed based on the risk rating

Clause Risk

(1-7)

Challenge

(1-7)

2.05. Keep private any confidential information gained in

professional work, where such confidentiality is consistent with the

public interest and consistent with the law.

5.2 4.7

2.2 Not knowingly use software that is obtained or retained either

illegally or unethically. 5 4.5

2.06. Identify, document, collect evidence and report to the client or

the employer promptly if, in their opinion, a project is likely to fail,

to prove too expensive, to violate intellectual property law, or

otherwise to be problematic.

5 4.4

2.09. Promote no interest adverse to their employer or client, unless a

higher ethical concern is being compromised; in that case, inform the

employer or another appropriate authority of the ethical concern.

4.4 3.6

2.3 Use the property of a client or employer only in ways properly

authorized, and with the client's or employer's knowledge and

consent.

4 3

2.4 Ensure that any document upon which they rely has been

approved, when required, by someone authorized to approve it. 4 3.7

2.07. Identify, document, and report significant issues of social

concern, of which they are aware, in software or related documents,

to the employer or the client.

4 4.5

2.08. Accept no outside work detrimental to the work they perform

for their primary employer. 4 3.6

2.1 Provide service in their areas of competence, being honest and

forthright about any limitations of their experience and education. 3 3.6

56

Principle 3 – Product

Product is the third principle of CM/IEEE SWECOE, which refers to how software

engineers should ensure that their products and related modifications meet the highest

professional standards possible.

Table 4.11 presents the product principle clause from the perceived high risk to the low

risk perceived after calculating the average score for each clause.

Table 4.11 Product clause based on the risk rating along

Clause Risk(1-

7)

Challenge

(1-7)

3.10. Ensure adequate testing, debugging, and review of software

and related documents on which they work. 5 4

3.12. Work to develop software and related documents that respect

the privacy of those who will be affected by that software. 4.8 4.3

3.2 Ensure proper and achievable goals and objectives for any

project on which they work or propose. 4.6 4.8

3.14. Maintain the integrity of data, being sensitive to outdated or

flawed occurrences. 4.6 4

3.1 Strive for high quality, acceptable cost and a reasonable

schedule, ensuring significant tradeoffs are clear to and accepted

by the employer and the client, and are available for consideration

by the user and the public.

4.5 5.2

3.4 Ensure that they are qualified for any project on which they

work or propose to work by an appropriate combination of

education and training, and experience.

4.5 4.4

3.7 Strive to fully understand the specifications for software on

which they work. 4.5 4.6

57

3.08. Ensure that specifications for software with which they work

have been well documented, satisfy the users’ requirements and

have the appropriate approvals.

4.4 5.2

3.13. Be careful to use only accurate data derived by ethical and

lawful means, and use it only in ways properly authorized. 4.4 4

3.09. Ensure realistic quantitative estimates of cost, scheduling,

personnel, quality and outcomes on any project on which they

work or propose to work and provide an uncertainty assessment of

these estimates.

4.3 4.7

3.3 Identify, define and address ethical, economic, cultural, legal

and environmental issues related to work projects. 4.2 4.3

3.11. Ensure adequate documentation, including significant

problems discovered and solutions adopted, for any project on

which they work.

4.2 4.4

3.6 Work to follow professional standards, when available, that

are most appropriate for the task at hand, departing from these

only when ethically or technically justified.

4 3.9

3.5 Ensure an appropriate method is used for any project on which

they work or propose to work. 3.6 4

3.15 Treat all forms of software maintenance as new development

with the same professionalism. 3.6 3.5

Principle 4 – Judgment

Judgment is the fourth principle of CM/IEEE SWECOE, which refers to how software

engineers should maintain integrity and independence in their professional judgment.

Table 4.12 presents the judgment principle clause from the perceived high risk to the low

risk after calculating the average score for each clause.

Table 4.12 Judgment principle clause based on the risk rating

Clause Risk Challenge

58

(1-

7)

(1-7)

4.6 Refuse to participate, as members or advisors, in a private,

governmental or professional body concerned with software related

issues, in which they, their employers or their clients have

undisclosed potential conflicts of interest.

5 4.4

4.5 Disclose to all concerned parties those conflicts of interest that

cannot reasonably be avoided or escaped. 4.6 3.9

4.4 Not engage in deceptive financial practices such as bribery,

double billing, or other improper financial practices. 4 3

4.3 Maintain professional objectivity with respect to any software or

related documents they are asked to evaluate. 3.7 3.7

4.2 Only endorse documents either prepared under their supervision

or within their areas of competence and with which they are in

agreement.

3.5 3

4.1 Temper all technical judgments by the need to support and

maintain human values. 2.8 3

4.3 SWECOE based on the SDLC Phases

Another objective of this research is to propose a new classification for the first four

principles of the existing ACM/IEEE SWECOE. They are: Public, Client and Employer,

Product, and Judgment; to re-classify it based on the SDLC phase by distributing a

questionnaire to software engineers and asking them to check the phases that they

perceived are part of the clause.

17 responses were received engineers with different years of experience which should be

considered in the results. So the methodology in the questionnaire analysis gave weight

for each score based on years of experience.

The participants were divided into three segments based on their years of experience and

a weight is given for each segment (as shown in the Table 4.13) to create the score.

Table 4.13 Questionnaire segmentation analysis

Years of experience Weight Count Score

59

0-4 1 12 12

5- 9 2 3 6

10 and more 3 2 6

Total 17 24

After adding the weight scores, the total is 24; so whenever a clause score reach half or

above the score which is 12 and above (24/2), this clause will be considered to be in this

phase. The results are explained in the following sections.

4.3.1 Questionnaire Results

Principle 1 – Public

For the first principle the results are shown in Table 4.14.

Table 4.14 Public principle clause as aligned with the SDLC phases

Clause Requirement Design Code Test Maintenance

1.1 Accept full responsibility for

their own work. √ √ √ √ √

1.2 Moderate the interests of the

software engineer, the employer,

the client and the users with the

public good.

√ √

1.3 Approve software only if they

have a well-founded belief that it is

safe, meets specifications, passes

appropriate tests, and does not

diminish quality of life, privacy or

harm the environment. The ultimate

effect of the work should be to the

public good.

√

1.4 Disclose to appropriate persons

or authorities any actual or potential

danger to the user, the public, or the

environment, that they reasonably

√ √

60

believe to be associated with the

software or related documents.

1.5 Cooperate with effort to address

matters of grave public concern

caused by software, its installation,

maintenance, support or

documentation.

√ √

1.6 Be fair and avoid deception in

all statements, particularly public

ones, concerning software or

related documents, methods and

tools.

√ √ √

1.7 Consider issues of physical

disabilities, allocation of resources,

economic disadvantage and other

factors that can diminish access to

the benefits of software.

√

1.8 Be encouraged to volunteer

professional skills to good causes

and contribute to public education

concerning the discipline.

√ √ √ √

Principle 2 – Client and Employer

For the client and employer principle the results are shown in Table 4.15.

Table 4.15 Client and employer principle clause as aligned with the SDLC phases


2.1 Provide service in their area of

competence, being honest and

forthright about any limitations of

their experience and education.

√ √ √ √ √

61

2.2 Not knowingly use software

that is obtained or retained either

illegally or unethically.

√ √

2.3 Use the property of a client or

employer only in ways properly

authorized, and with the client's or

employer's knowledge and consent.

√ √ √ √ √

2.4 Ensure that any document upon

which they rely has been approved,

when required, by someone

authorized to approve it.

√ √ √ √ √

2.05. Keep private any confidential

information gained in their

professional work, where such

confidentiality is consistent with

the public interest and consistent

with the law.

√ √ √ √

2.06. Identify document, collect

evidence and report to the client or

the employer promptly if, in their

opinion, a project is likely to fail,

prove too expensive, to violate

intellectual property law, or


√ √

2.07. Identify, document, and report

significant issues of social concern,

of which they are aware, in

software or related documents, to

the employer or the client.

√ √ √ √

2.08. Accept no outside work

detrimental to the work they

perform for their primary employer.

√ √ √ √

2.09. Promote no interest adverse to

their employer or client, unless a

√ √ √ √

62

higher ethical concern is being

compromised; in that case, inform

the employer or another appropriate

authority of the ethical concern.

Principle 3 – Product

For product principle, the results are shown in Table 4.16.

Table 4.16 Product principle clause as aligned with the SDLC phases


3.1 Strive for high quality,

acceptable cost and a reasonable

schedule, ensuring significant

tradeoffs are clear to and accepted

by the employer and the client, and

are available for consideration by

the user and the public.

√ √ √ √ √

3.2 Ensure proper and achievable

goals and objectives for any project

on which they work or propose.

√ √

3.3 Identify, define and address

ethical, economic, cultural, legal

and environmental issues related to

work projects.

√ √ √

3.4 Ensure that they are qualified

for any project on which they work

or propose to work by an

appropriate combination of

education and training, and

experience.

√ √ √ √ √

3.5 Ensure an appropriate method is

used for any project on which they

√ √ √ √

63

work or propose to work.

3.6 Work to follow professional

standards, when available, that are

most appropriate for the task at

hand, departing from these only

when ethically or technically

justified.

√ √ √ √ √

3.7 Strive to fully understand the

specifications for software on

which they work.

√ √ √ √

3.08. Ensure that specifications for

software on which they work have

been well documented, satisfy the

users’ requirements and have the

appropriate approvals.

√ √ √

3.09. Ensure realistic quantitative

estimates of cost, scheduling,

personnel, quality and outcomes on

any project on which they work or

propose to work and provide an

uncertainty assessment of these

estimates.

√ √

3.10. Ensure adequate testing,

debugging, and review of software

and related documents on which

they work.

√

3.11. Ensure adequate

documentation, including

significant problems discovered and

solutions adopted, for any project

on which they work.

√ √ √ √

3.12. Work to develop software and

related documents that respect the

privacy of those who will be

√ √

64

affected by that software.

3.13. Be careful to use only

accurate data derived by ethical and

lawful means, and use it only in

ways properly authorized.

√ √ √

3.14. Maintain the integrity of data,

being sensitive to outdated or

flawed occurrences.

√ √ √

3.15 Treat all forms of software

maintenance with the same

professionalism as new

development.

√

Principle 4 – Judgment

For the judgment principle, the results are shown in Table 4.17.

Table 4.17 Judgment principle clause as aligned with the SDLC phases


4.1 Temper all technical judgments

by the need to support and maintain

human values.

√ √ √ √

4.2 Only endorse documents either

prepared under their supervision or

within their areas of competence

and with which they are in

agreement.

√ √ √ √ √

4.3 Maintain professional

objectivity with respect to any

software or related documents they

are asked to evaluate.

√ √ √

65

4.4 Not engage in deceptive

financial practices such as bribery,

double billing, or other improper

financial practices.

√ √ √ √ √

4.5 Disclose to all concerned parties

those conflicts of interest that

cannot reasonably be avoided or

escaped.

√ √ √ √

4.6 Refuse to participate, as

members or advisors, in a private,

governmental or professional body

concerned with software related

issues, in which they, their

employers or their clients have

undisclosed potential conflicts of

interest.

√ √ √ √

4.3.2 New Classification of SWECOE based on the SDLC

In this section a reclassification of the existing ACM/IEEE code of ethics is proposed

based on the SLDC phases as perceived by the respondents, with the consideration of the

weight based on years of experience. Below are the results for each phase.

General clauses

General clauses are clauses that are found applicable for all SDLC phases. It is identified

as the general clause if the clause score for each phase is 12 or above. This means that the

weight of the clause is not heavier in any phase in the SDLC.

66

Figure 4. 5 General clauses

Requirement phase

Based on the results, the applicable clauses to requirement phase are given in Figure 4.6

where the clause score is 12 or above.

•1.1 Accept full responsibility for their own work.

Public

•2.1 Provide service in their areas of competence, being honest and forthright about any limitations of their experience and education.

•2.3 Use the property of a client or employer only in ways properly authorized, and with the client's or employer's knowledge and consent.

•2.4 Ensure that any document upon which they rely has been approved, when required, by someone authorized to approve it.

Client and employer

•3.1 Strive for high quality, acceptable cost and a reasonable schedule, ensuring significant tradeoffs are clear to and accepted by the employer and the client, and are available for consideration by the user and the public.

•3.4 Ensure that they are qualified for any project on which they work or propose to work by an appropriate combination of education and training, and experience.

•3.6 Work to follow professional standards, when available, that are most appropriate for the task at hand, departing from these only when ethically or technically justified.

Product

•4.2 Only endorse documents either prepared under their supervision or within their areas of competence and with which they are in agreement.

•4.4 Not engaging in deceptive financial practices such as bribery, double billing, or other improper financial practices.

Judgment

67

Figure 4. 6 Requirement Clauses

•1.2 Moderate the interests of the software engineer, the employer, the client and the users with the public good.

•1.4 Disclose to appropriate persons or authorities any actual or potential danger to the user, the public, or the environment, that they reasonably believe to be associated with software or related documents.

•1.5 Cooperate with effort to address matters of grave public concern caused by software, its installation, maintenance, support or documentation.

•1.6 Be fair and avoid deception in all statements, particularly public ones, concerning software or related documents, methods and tools.

•1.7 Consider issues of physical disabilities, allocation of resources, economic disadvantage and other factors that can diminish access to the benefits of software.

•1.8 Be encouraged to volunteer professional skills to good causes and contribute to public education concerning the discipline.

Public

•2.05. Keep private any confidential information gained in their professional work, where such confidentiality is consistent with the public interest and consistent with the law.

•2.06. Identify, document, collect evidence and report to the client or the employer promptly if, in their opinion, a project is likely to fail, to prove too expensive, to violate intellectual property law, or otherwise to be problematic.

•2.07. Identify, document, and report significant issues of social concern, of which they are aware, in software or related documents, to the employer or the client.

•2.08. Accept no outside work detrimental to the work they perform for their primary employer.

•2.09. Promote no interest adverse to their employer or client, unless a higher ethical concern is being compromised; in that case, inform the employer or another appropriate authority of the ethical concern.

Client and employer

•3.2 Ensure proper and achievable goals and objectives for any project which they are working on or propose. to work on.

•3.3 Identify, define and address ethical, economic, cultural, legal and environmental issues related to work projects.

•3.5 Ensure an appropriate method is used for any project which they are working on or propose. to work on.

•3.08. Ensure that specifications for software which they are working on or propose., their work have been well documented, satisfy the users’ requirements and have the appropriate approvals.

•3.09. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes on any project which they are working on or propose.to work on, and provide an uncertainty assessment of these estimates.

•3.11. Ensure adequate documentation, including significant problems discovered and solutions adopted, for any project which they are working on or propose. to work on..

•3.13. Be careful to use only accurate data derived by ethical and lawful means, and use it only in ways properly authorized.

•3.14. Maintain the integrity of data, being sensitive to outdated or flawed occurrences.

Product

•4.1 Temper all technical judgments by the need to support and maintain human values.

•4.3 Maintain professional objectivity with respect to any software or related documents they are asked to evaluate.

•4.5 Disclose to all concerned parties those conflicts of interest that cannot reasonably be avoided or escaped.

•4.6 Refuse to participate, as members or advisors, in a private, governmental or professional body concerned with software related issues, in which they, their employers or their clients have undisclosed potential conflicts of interest.

Judgment

68

Design phase

Based on the results, Figure 4.7 shows the applicable clauses to design phase where the

clause score is 12 or above, as shown in.

Figure 4.7 Design Clauses




Public





Client and employer


•3.5 Ensure an appropriate method is used for any project which they are working on or propose. to work on.

•3.7 Strive to fully understand the specifications for software which they are working on or propose. to work on.

•3.09. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes on any project which they are working on or propose to work on and provide an uncertainty assessment of these estimates.

•3.11. Ensure adequate documentation, including significant problems discovered and solutions adopted, for any project which they are working on or propose to work on..

•3.12. Work to develop software and related documents that respect the privacy of those who will be affected by that software.



Product





Judgment

69

Code phase

Based on the results, Figure 4.8 shows the applicable clauses to code phase where the

clause score is 12 or above.

Figure 4.8 Code Clauses



Public

•2.2 Not knowingly use software that is obtained or retained either illegally or unethically.




Client and employer

•3.5 Ensure an appropriate method is used for any project which they are working on or propose to work on.

•3.7 Strive to fully understand the specifications for software which they are working on or propose to work on.

Product

Judgment

70

Test Phase

Based on the results, Figure 4.9 shows the applicable clauses to Test phase where the

clause score is 12 or above.

Figure 4.9 Test Clauses

•1.3 Approve software only if they have a well-founded belief that it is safe, meets specifications, passes appropriate tests, and does not diminish quality of life, privacy or harm the environment. The ultimate effect of the work should be to the public good.


Public


•2.06. Identify, document, collect evidence and report to the client or the employer promptly if, in their opinion, a project is likely to fail, prove too expensive, violate intellectual property law, or otherwise to be problematic.



Client and employer

•.3.2 Ensure proper and achievable goals and objectives for any project which they are working on or propose. to work on.

•3.4 Ensure that they are qualified for any project which they are working on or propose to work on.

•3.7 Strive to fully understand the specifications for software which they are working on or propose to work on.

•3.08. Ensure that specifications for software which they are working on have been well documented, satisfy the users’ requirements and have the appropriate approvals.

•3.10. Ensure adequate testing, debugging, and review of software and related documents which they are working on.

•3.11. Ensure adequate documentation, including significant problems discovered and solutions adopted, for any project which they are working on.

•3.12. Work to develop software and related documents that respect the privacy of those who will be affected by that software.

•3.13. Be careful touse only accurate data derived by ethical and lawful means, and use it only in ways properly authorized.


Product





Judgment

71

Maintenance Phase

Based on the results, Figure 4.10 shows the applicable clauses to maintenance phase

where the clause score is 12 or above.

Figure 4.10 Maintenance Clauses

•1.4 Disclose to appropriate persons or authorities any actual or potential danger to the user, the public, or the environment, that they reasonably believe to be associated with software or related documents.

•1.5 Cooperate in efforts to address matters of grave public concern caused by software, its installation, maintenance, support or documentation.



Public

•2.2 Not knowingly use software that is obtained or retained either illegally or unethically.




Client and employer


•3.7 Strive to fully understand the specifications for software on which they work.

•3.08. Ensure that specifications for software on which they work have been well documented, satisfy the users’ requirements and have the appropriate approvals.

•3.11. Ensure adequate documentation, including significant problems discovered and solutions adopted, for any project on which they work.



•3.15 Treat all forms of software maintenance with the same professionalism as new development.

Product





Judgment

72

4.4 Proposed framework

The existing ACM/IEEE SWECOE is based on eight principles as shown in Figure 4.11.

Figure 4.11 ACM/IEEE 8 Principles

Our focus in this research is on the first four principles, which are public, client and

employer, product, and judgement as shown in Figure 4.12

Figure 4.12 ACM/IEEE first four principles

ACM/IEEE

SWECOE principles

Public

Client and

Employer

Self

College

Product

Judgment

Management

Profession

ACM/IEEE SWECOE principles

Public

Client and Employer

Product

Judgment

73

From the case study and after analyzing the results of the document analysis, interviews,

and questionnaire results, we found that there is no indication of awareness of the

existing code of ethics as provided by IEEE/ACM. Moreover, there is no evidence to

indicate the presence of any formal guidelines or requirements on ethics in software

development in the organization. To make it easy for the software engineers and after

investigating how software engineering code of ethics is being practiced throughout the

SDLC, a new framework is proposed based on the SDLC phases. This will provide

recommendations that will further assist software engineers to comply with the software

engineering code of ethics within the software development projects.

The new classification of the existing IEEE/ACM code of ethics is proposed based on the

SDLC phases shown in Figure 4.13

Figure 4.13 SDLC Phases

ACM/IEEE SWECOE

Requirement

Design

Code Test

Maintenance

74

To make it easier for the software engineers, a new re-classification of the existing

ACM/IEEE SWECOE based on the SDLC phases and after adding the participants’ input

from the questionnaire, a new framework is proposed, as shown in Figure 4.14.

Figure 4. 14 New proposed SDLC Code of Ethics Framework

The proposed framework is based on the SDLC phases and listed from high risk clause to

low risk clause as shown in Table 4.15.

E.g.

1.Accept full

responsibility for their

own work.

2.Strive for high

quality, acceptable cost

and a reasonable

schedule, ensuring

significant tradeoffs are

clear to and accepted by

the employer and the

client, and are available

for consideration by the

user and the public.

3.Work to follow

professional standards,

when available, that are

most appropriate for the

task at hand, departing

from these only when

ethically or technically

justified.

E.g.

1.Ensure adequate

documentation,

including significant

problems discovered

and solutions adopted,

for any project on

which they work.

2.Moderate the interests

of the software

engineer, the employer,

the client and the users

with the public good.

3.Identify, document,

and report significant

issues of social concern,

of which they are

aware, in software or

related documents, to

the employer or the

client.

E.g.

1.Ensure proper and

achievable goals and

objectives for any

project on which they

work or propose.

2.Disclose to all

concerned parties those

conflicts of interest that

cannot reasonably be

avoided or escaped.

3.Maintain the integrity

of data, being sensitive

to outdated or flawed

occurrences

4. Identify, define and

address ethical,

economic, cultural,

legal and environmental

issues related to work

projects.

E.g.

1.Not knowingly use

software that is

obtained or retained

either illegally or

unethically.

2.Strive to fully

understand the

specifications for

software on which

they work.

3.Follow the correct

coding standards

4.Verify you have

coded the design and

traced code back

through design to the

requirements.

E.g.

1.Approve software

only if they have a

well-founded belief

that it is safe, meets

specifications, passes

appropriate tests, and

does not diminish

quality of life,

privacy or harm the

environment. The

ultimate effect of the

work should be to

the public good.

2. Ensure adequate

testing, debugging,

and review of

software and related

documents on which

they work.

E.g.

1.Disclose to

appropriate persons

or authorities any

actual or potential

danger to the user,

the public, or the

environment, that

they reasonably

believe to be

associated with

software or related

documents.

2. Fully understand

the specifications for

software on which

they work.

ACM/IEEE Code of Ethics

Software Development Process (SDLC)

Categorization of code of ethics

COE to be followed in SDLC

75

Table 4.15 Proposed Framework

SDLC

Phase Ethical concern

Genera

l

1. Accept full responsibility for their own work.

2. Strive for high quality, acceptable cost and a reasonable schedule, ensuring

significant tradeoffs are clear to and accepted by the employer and the client, and

are available for consideration by the user and the public.

3. Ensure that they are qualified for any project on which they work or propose to

work by an appropriate combination of education and training, and experience.

4. Use the property of a client or employer only in ways properly authorized, and

with the client's or employer's knowledge and consent.

5. Work to follow professional standards, when available, that are most appropriate

for the task at hand, departing from these only when ethically or technically

justified.

6. Not engage in deceptive financial practices such as bribery, double billing, or other

improper financial practices. Ensure that any document upon which they rely has

been approved, when required, by someone authorized to approve it.

7. Only endorse documents either prepared under their supervision or within their

areas of competence and with which they are in agreement.

8. Provide service in their areas of competence, being honest and forthright about any

limitations of their experience and education.

Requir

ement

1. Keep private any confidential information gained in their professional work, where

such confidentiality is consistent with the public interest and consistent with the

law.

2. Identify, document, collect evidence and report to the client or the employer

promptly if, in their opinion, a project is likely to fail, to prove too expensive, to

violate intellectual property law, or otherwise to be problematic.

3. Refuse to participate, as members or advisors, in a private, governmental or

professional body concerned with software related issues, in which they, their

employers or their clients have undisclosed potential conflicts of interest.

4. Disclose to appropriate persons or authorities any actual or potential danger to the

user, the public, or the environment, that they reasonably believe to be associated

with software or related documents.

5. Ensure proper and achievable goals and objectives for any project on which they

work or propose.

6. Disclose to all concerned parties those conflicts of interest that cannot reasonably

76

be avoided or escaped.

7. Maintain the integrity of data, being sensitive to outdated or flawed occurrences.

8. Promote no interest adverse to their employer or client, unless a higher ethical

concern is being compromised; in that case, inform the employer or another

appropriate authority of the ethical concern.

9. Be careful to use only accurate data derived by ethical and lawful means, and use

it only in ways properly authorized.

10. Ensure that specifications for software on which they work have been well

documented, satisfy the users’ requirements and have the appropriate approvals.

11. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and

outcomes on any project on which they work or propose to work and provide an

uncertainty assessment of these estimates.

12. Identify, define and address ethical, economic, cultural, legal and environmental

issues related to work projects.

13. Ensure adequate documentation, including significant problems discovered and

solutions adopted, for any project on which they work.

14. Moderate the interests of the software engineer, the employer, the client and the

users with the public good.

15. Cooperate with effort to address matters of grave public concern caused by

software, its installation, maintenance, support or documentation.

16. Be fair and avoid deception in all statements, particularly public ones, concerning

software Consider issues of physical disabilities, allocation of resources, economic

disadvantage and other factors that can diminish access to the benefits of software.

17. Identify, document, and report significant issues of social concern, of which they

are aware, in software or related documents, to the employer or the client.

18. Maintain professional objectivity with respect to any software or related

documents they are asked to evaluate.

19. Ensure an appropriate method is used for any project on which they work or

propose to work.

20. Temper all technical judgments by the need to support and maintain human values.

21. Accept no outside work detrimental to the work they perform for their primary

employer. Be encouraged to volunteer professional skills to good causes and

contribute to public education concerning the discipline.

22. Technical/solution knowledge

23. Compliance with rule and regulation

24. Not to build the requirement based on personal needs or support of a certain

technology

25. Honesty in meeting customer needs

26. Training customers as they learn their needs because customers may not know

their needs well - it is unethical to build requirements knowing the customer is

uneducated in describing their needs


28. Ensuring proper security, privacy and that these are part of requirements from the

start.

29. To identify clearly the requirement from end user perspective

77

Design





software or related documents, methods and tools.




5. Strive to fully understand the specifications for software on which they work.









9. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and






propose to work.



13. Moderate the interests of the software engineer, the employer, the client and the





employer.



17. Be encouraged to volunteer professional skills to good causes and contribute to

public education concerning the discipline.


19. Work to develop software and related documents that respect the privacy of those

who will be affected by that software.

20. Easy vs right way of design

21. Not to create the design based on personal needs or support of a certain technology

22. Follow the correct design standards, to use incorrect design templates and to not

verify design has properly designed the requirements.

78


improper financial practices.

24. Ensuring proper security, privacy and that these are part of designs from start.

Codin

g



law.

2. Not knowingly use software that is obtained or retained either illegally or

unethically.






employer.

6. The interests of the software engineer, the employer, the client and the users with

the public good.


propose to work.



9. Crack codes

10. Non-compliance with the company policies

11. Not to create harmful code

12. Follow the correct coding standards

13. Verify you have coded the design and traced code back through design to the

requirements.

14. Not cutting corners.

15. Use a standard code.

Testin

g

1. Approve software only if they have a well-founded belief that it is safe, meets

specifications, passes appropriate tests, and does not diminish quality of life,

privacy or harm the environment. The ultimate effect of the work should be to the

public good.



law.




4. Identify, document, collect evidence and report to the client or the employer

promptly if, in their opinion, a project is likely to fail, prove too expensive, violate

intellectual property law, or otherwise to be problematic.

5. Ensure adequate testing, debugging, and review of software and related documents

79

on which they work.

6. Work to develop software and related documents that respect the privacy of those

















15. Ensure that they are qualified for any project on which they work or propose to

work by an appropriate




18. Not to jump certain cases to save time and reduce cost

19. Follow correct standards

20. Perform traceability

21. Not to do a quick and dirty job

22. Pass software when it is known to be faulty


employer.

24. Providing adequate testing.

Mainte

nance



law.

2. Not knowingly use software that is obtained or retained either illegally or

unethically.




4. Disclose to appropriate persons or authorities any actual or potential danger to the

user, the public, or the environment, that they reasonably believe to be associated

with software or related documents.

80











10. Fully understand the specifications for software on which they work.



12. Cooperate with effort to address matters of grave public concern caused by

software, its installation, maintenance, support or documentation.


employer.



15. Treat all forms of software maintenance as new development with the same

professionalism.






19. Creating issues that were not part of the main release



21. Treat all forms of software maintenance with the same professionalism as new

development.

22. Providing long-term maintenance.

23. Troubleshooting any issue

4.5 Validation

One of the main purposes of having software engineering code of ethics is to help

software engineers to make decisions throughout the SDLC phases (Collins, 2009).

In this section, the framework will be evaluated by software developers or practitioners

for suitability and appropriateness. In this regards, a scenario-based session was

conducted to validate the framework. A session was conducted with three practitioners to

81

validate the framework using actual cases of the most recent project in SADAD. The

exercise is developed and conducted to test the situation with and without the placement

SWECOE proposed in the study framework. The factors used to test in the simulation are

cost and time. The scenarios was verified by the practitioners during the session. The

numbers used below in Tables 4.19 and 4.20 are not the real numbers, which were

replaced due to confidentiality reasons.

Project Case 1

SADAD always enhances its system by fixing some issues, introducing new services, or

fulfilling clients’ requirements. One of those releases was a software solution that

SADAD developed to cover four main requirements: fixing a problem, introducing a

new channel, adding a new service, and finally fulfilling a client’s request which was to

add the ID number in the payment notification message. This requirement was requested

by a major client who wanted SADAD to share confidential information (customer ID)

with the client so they can do the validation at their end rather than on SADAD side. This

project went through requirement, design, coding, and testing. In the final stages of

testing, a presentation was given to top management to explain the purpose of the release

and the status. However, the top management rejected this release and did not allow using

it since it included sharing confidential information with the client. Consequently, the

fourth requirement was de-scoped from the project after it was designed, implemented,

and tested. This requirement was de-scoped as expressed by the practitioner because

“this case contains confidential information that SADAD should not share without

permission, so this case is no longer valid.” This project included unneeded cost for the

de-scoped requirement, which can be avoided from the beginning. This project cost

SADAD money and time as shown below in Table 4.18.

Using the same release and after applying the proposed SWECOE, the fourth requirement

related to adding the Customer ID to the payment notification message SADAD sent to

the client, will not be scoped from the beginning, from the requirement phase. It would

be rejected as there is a clause stating “Keep private any confidential information gained

in their professional work, where such confidentiality is consistent with the public

82

interest and consistent with the law.” So by having SWECOE, SADAD could save 9% of

the total project cost.

Table 4.18 Case 1

Project 1 Without code of ethics With code of ethics

Cost (man-days) 104 man-days to deliver this

project.

95 man-days to develop this

project

Time 93 days to deliver this

project.

84 days to deliver this

project.

Project Case 2

Taking another project, SADAD is developing a huge project to rebuild and re-architect

the current system by fully migrating to an Event Driven and Service-Oriented

Architecture. This project is outsourced and needs to include all the features in the

current system. So, the current system documentation is a prerequisite. This project faces

huge delays and costing SADAD money, time, and missing opportunities. The main

reason of this delay is the documentations. As the SADAD current system does not have

a low level design, high level design and other software documentations that are needed.

The details are shown in Table 4.20.

On the other hand, with the use of this framework for ethical practices during the SDLC,

all software documentation will be available. One of the clauses states that: “Ensure

adequate documentation, including significant problems discovered and solutions

adopted, for any project on which they work.” And another clause “Ensure that any

document upon which they rely has been approved, when required, by someone

authorized to approve it.” So by having SWECOE, SADAD could save 9% of the total

project cost.

Table 4.19 Case 2

Project 2 Without code of ethics With code of ethics

Cost (man-days) 4027 man-days to deliver

the project

3675 man-days to develop

this project

Time 316 days to deliver this 228 84 days to deliver this

83

project. project.

4.6 Summary

The research met all of its objectives, as shown in Table 4.21, along with the results.

Table 4. 20 Research objectives and Results

Research objectives Results

To investigate how Software

engineering code of ethics is

being implemented within the

software development projects

The results show that there is no indication of awareness

in the existing code of ethics as provided by IEEE/ACM.

Along with the investigation on how code of ethics is

being implemented thought the SDLC. There is no

evidence to indicate the presence of any formal

guidelines or requirements on ethics in software having

SWECOE

To investigate which software


perceived to be the most

challenging to follow.

From the questionnaire analysis, the risk and challenges

in practicing certain areas in the SWECOE framework

are found to be not significantly different, as high risk

areas are also found to highly challenging to observe and

practice. The results can provide a guide for the

organization to prioritize the risk area concerning code

of ethics.

To investigate which software


perceived as a high risk.

To propose a classification of the

software engineering code of

ethics based on the software

development life cycle phases.

The existing SWECOE are addressed in generic term

and need to be made aware at each phase in SDLC, a

categorization of SWECODE at each phase can clearly

address the ethical issues and concern that may arise at

each phase. Categorization of SWECOE can guide in

training of engineers and guide project managers to

clearly manage teams who are highly professionals with

delivery of quality products. So providing a new

classification of the software engineering code of ethics

based on the software development life cycle phases can

help software engineers better understand, apply, control

and monitor software development project ethical

practices. A guideline and policy checklists and tools

To propose a framework of

software engineering code of

ethics within the software


84

can be designed to enhance the quality of software

development as a result of this study.

85

CHAPTER 5 – CONCLUSION

This section will include a summary of the research; highlighting the main findings,

proposing set of recommendation, the research limitation, and further research topics, and

research significant.

5.1 Summary Findings

In order to complete this research, the SADAD Payment system was chosen to be the

case in this research. This research has achieved its first objective, which is investigating

how Software engineering code of ethics is being implemented within the software

development projects. This is achieved by a document analysis of policies, procedures,

and projects management, and followed by interviews with experts from software

development projects. team members who were working on different software

development projects and holding various positions and questionnaires filled by software

engineers, as described in the methodology and the results in Chapters 3 and 4. The main

results showed no evidence to indicate the presence of any formal guidelines or

requirements on ethics in software having SWECOE. Moreover, there is no indication of

awareness of the existing code of ethics as provided by IEEE/ACM.

The second and third objectives were to investigate which SWECOE is perceived to be

the most challenging to follow, and which SWECOE is perceived to be in a high-risk

category. These objectives were achieved by questionnaires distributed to software

engineers as described in the methodology and the results in Chapters 3 and 4. The result

showed that risk and challenges in certain areas in the SWECOE framework were not

significantly different, as high risk areas were also found too challenging to observe and

practice. The results can provide a guide for the organization to prioritize the risk areas

concerning code of ethics.

The fourth objective, to propose a new classification of the software engineering code of

ethics based on the SDLC phases, was achieved by distributing questionnaires to

software engineers and asking them to classify the existing SWECOE based on the SDLC

phases. In order to achieve the last objective which is to propose a framework of

86

software engineering code of ethics within the software development life cycle, all the

results were collected and analyzed. Then a new SWECOE were proposed and validated

by practitioners within a simulation session. This was described in Chapters 3 and 4. The

results were showed that the existing SWECOE were addressed in generic terms and

needed to be made aware at each phase in SDLC. A categorization of SWECOE at each

phase can assist in clearly addressing the ethical issues and concern that may arise at each

phase. The categorization of SWECOE can guide in the training of engineers and guide

project managers to clearly manage teams who are highly professionals with the delivery

of quality products. So, providing a new classification of the software engineering code

of ethics based on the software development life cycle phases can help software

engineers better understand, apply, control and monitor the ethical practices of software

development projects. A guideline and policy checklists and tools can be designed to

enhance the quality of software development as a result of this study.

5.2 Research contribution and recommendation

The contribution of the research are: First, the research offers recommendations that

could assist software engineers to comply with the software engineering code of ethics in

software development projects. As the existing SWECOE are addressed in generic term

and need to be made aware at each phase in SDLC, the categorization of SWECOE based

on SDLC phases can help software engineers better understand, apply, control and

monitors software development projects ethical practices. The research found clear

indication of improvement to projects that take into consideration code of ethics at each

phase. Critical issues in software development could have been avoided with the

implementation of relevant code of ethics at each phase in SDLC. Gotternbarn’s (1999,

2001, 2005, 2010) works in Software Engineering code of ethics continue to contribute

significantly to the field of education in software engineering. However, this work

provides a mechanism for application in the actual practice of software development as

part of the actual practical framework that can be followed.

Secondly, in another contribution, this research identified different classification of the

existing code of ethics in the form of ranking in risk and challenges. This finding can

87

provide a guide for the organization ease of prioritizing the risk area concerning code of

ethics. Given the many areas and clauses in the code of ethics it is not easy to identify

which one to prioritize, unless a systematic approach is done to identify and classify them

, through a proper research. This can also help them to focus on the most important and

challenging code of ethics, of which the implication can be severe if overlooked or not

followed. The proposed framework can assist developers in applying software

engineering code of ethics within the software development life cycle and prioritize the

code of ethics based on risks and providing a list which contains items perceived to be the

most challenging code of ethics to be followed.

Thirdly, this research results would enhance research and knowledge in software

engineering code of ethics, which is really needed in the field. While many research

contributes to enhancing each area in the software engineering code of ethics such as

management, public, product, etc., this research tried to refocus to the actual practice of

software development and look for means to implement the concept of ethics in the actual

development process. The framework identified can contribute significantly into our

understanding of ethical concerns among software engineering professionals. This is due

to the fact that many software engineers are either forgotten the areas of ethics during

their academic programs or not at all being exposed to any of them. It can also assist

educators and academicians in enhancing ethics curriculum and prepare software

engineering professionals entering the field.

5.3 Research Limitations and Suggestion for Future Research

Although the research has reached its aims, there were some limitations. This research is

limited to one case (one organization) and a small number of contributors. However,

adding more cases and expanding the number of contributors could results in more

reliable results for generalization. Likewise, due to the small sample of contributors, the

research concentrated on only four principles from the existing SWECOE. By including

the other four principles, this would potentially give a full and complete picture of

SWECOE. Future research is suggested to be expanded into the remaining four principles

and with the use of more robust methodology for validation of the results.

88

REFERENCES

Abdawi, A. (2014) Systematic Review.

ACM/IEEE-CS Joint Task Force (2014), “Software engineering code of ethics and

professional practice”, available at: www.acm.org/about/se-code (accessed 29

July 2014).

ACM/IEEE-CS Joint Task Force (2014), “ACM and IEEE-CS Cooperative Activities”,

available at: http://www.acm.org/acm-ieeecs-coop (accessed 31 December 2015).

Agarwal, S., & Garcia, M. (2006, July). What to Teach About Computer Ethics. In

Information Technology Based Higher Education and Training, 2006. ITHET'06.

7th International Conference on (pp. 86-93). IEEE.

Al-A'ali, M. (2008). Computer ethics for the computer professional from an Islamic point

of view. Journal of Information, Communication and Ethics in Society, 6(1), 28-

45.

AL-Adwan, M., AL-Zyood, M., & Ishfaq, M. (2013). The Impact of Electronic Payment

on Saudi Banks Profitability: Case Study of SADAD Payment System.

International Journal of Research and Reviews in Applied Science, 14-1.

Aliyu, M., Lasisi, N., Diyar, D., & Zeki, A. M. (2010, December). Computer security and

ethics awareness among IIUM students: An empirical study. In Information and

Communication Technology for the Muslim World (ICT4M), 2010 International

Conference on (pp. A52-A56). IEEE.

Alsudairi, M. A., & Vasista, T. Successful Implementation Of Electronic Bill Payment

and Presentment System–A Sadad Case Study. Imtcj, 1.

Averweg, U., & Erwin, G. (2005). Towards a Code of Cyberethics for a Municipality in

South Africa, Proceedings of the Fifth International Conference on Electronic

Business, Hong Kong, December 5-9, 2005, pp. 522 - 527

Baxter, P., & Jack, S. (2008). Qualitative case study methodology: Study design and

implementation for novice researchers. The qualitative report, 13(4), 544-559.

Berenbach, B., & Broy, M. (2009). Professional and ethical dilemmas in software

engineering. Computer, 74-80

http://www.acm.org/about/se-code

http://www.acm.org/acm-ieeecs-coop

89

Bynum, T. (2008). Computer and information ethics.

Bynum, T. W. (2000). A very short history of computer ethics. APA Newsletters on

Philosophy and Computers, 99(2).

Capurro, R. (1988). Information Ethos And Information Ethics-Ideas To Take

Responsible Action in the Field of Information. Nachrichten Fur Dokumentation,

39(1), 1-4.

Collins, D. (2009). Essentials of business ethics: Creating an organization of high

integrity and superior performance (Vol. 47). John Wiley & Sons.

Collins, D. (2012). Defending the Code: Using ethics to improve organizational

performance

Deigh, J. (1995). In Robert Audi (ed), The Cambridge Dictionary of Philosophy.

DiCicco‐Bloom, B., & Crabtree, B. F. (2006). The qualitative research interview.

Medical education, 40(4), 314-321.

Dodig-Crnkovic, G., & Feldt, R. (2009). Professional and Ethical Issues of Software

Engineering Curricula. 2010.

Evans, S. (2012, May). Ethics in Software Engineering, Net Neutrality and Badware-

What obligations rest on software engineers to act ethically in their profession? In

Proceedings of the 2012 4th IEEE Software Engineering Colloquium (SE).

Fieser, J., & Dowden, B. (2011). Internet encyclopedia of philosophy.

Freeman, P., & Hart, D. (2004). A science of design for software-intensive systems.

Communications of the ACM, 47(8), 19-21.

Gable, G. G. (1994). Integrating case study and survey research methods: an example in

information systems. European journal of information systems, 3(2), 112-126.

Génova, G., González, M. R., & Fraga, A. (2006). Ethical Responsibility of the Software

Engineer. In PhiSE.

Godfrey, R. (1996, January). The complete software engineering professional-doing the

right thing as well as doing it right: Five steps on the road to an ethics curriculum.

In Software Engineering: Education and Practice, 1996. Proceedings.

International Conference (pp. 26-32). IEEE.

90

Gotterbarn, D., & Miller, K. W. (2009). The public is the priority: Making decisions

using the software engineering code of ethics. Computer, (6), 66-73.

Gotterbarn, D. (2001). Software Engineering Ethics. Encyclopedia of Software

Engineering.

Gotterbarn, D., Miller, K., & Rogerson, S. (1997). “Software Engineering Code Ethics”,

Communications of the ACM 40, 11 (Nov. 1997), pp. 110-118.

Gotterbarn, D., Miller, K., & Rogerson, S. (1999). Computer society and ACM approve

software engineering code of ethics. Computer, 32(10), 84-88.

Hameed, S., Al-Khateeb, K., & Mutaz, Z. (2010, May). Software Engineer Islamic

Ethics: An interactive web-based model. In Computer and Communication

Engineering (ICCCE), 2010 International Conference on (pp. 1-7). IEEE.

Heersmink, R., van den Hoven, J., van Eck, N. J., & van den Berg, J. (2011).

Bibliometric mapping of computer and information ethics. Ethics and information

technology, 13(3), 241-249.

Huberman, A. M., & Miles, M. B. (2002). The qualitative researcher’s companion.

Thousand Oaks.

IEEE-CS/ACM Joint Task Force (Version 5.2). Software Engneering Ethics and

Professional Practices.

Jalote, P. (1997). An integrated approach to software engineering. Springer Science &

Business Media.

John E. Software Testing Fundamentals—Concepts, Roles, and Terminology

Kaddu, S. B. (2007). Information Ethics: a student’s perspective. International Review of

Information Ethics, 7(9), 1-6.

Kitchenham, B. (2004). Procedures for performing systematic reviews. Keele, UK, Keele

University, 33(2004), 1-26.

Landers, J.(2014) The Purpose of a Professional Code of Ethics[Online]Available at:

http://www.ehow.com/facts_7470742_purpose-professional-code-ethics.html

http://www.ehow.com/facts_7470742_purpose-professional-code-ethics.html

91

Lethbridge, T. C., Sim, S. E., & Singer, J. (2005). Studying software engineers: Data

collection techniques for software field studies. Empirical software engineering,

10(3), 311-341.

Lurie, Y., & Mark, S. (2015). Professional Ethics of Software Engineers: An Ethical

Framework. Science and engineering ethics, 1-18.

Maner, W. (1996). Unique ethical problems in information technology. Science and

Engineering Ethics, 2(2), 137-154.

Merriam, S. B. (1998). Qualitative Research and Case Study Applications in Education.

Revised and Expanded from" Case Study Research in Education.". Jossey-Bass

Publishers, 350 Sansome St, San Francisco, CA 94104.

Mills, H. D. (1999). The management of software engineering, Part I: Principles of

software engineering. IBM Systems Journal, 38(2.3), 289-295.

Moor, J. H. (1985). What is computer ethics? Metaphilosophy, 16(4), 266-275.

Paul, R., & Elder, L. (2006). The Thinker's Guide to Understanding the Foundations of

Ethical Reasoning. Foundation Critical Thinking.

Pollice, G. (2006). Ethics and Software Development.

Polga, M. (2008) Requirements Engineering Explained

Quigley, M. (Ed.). (2007). Encyclopedia of information ethics and security. IGI Global.

Ramadhan, A., Sensuse, D. I., & Arymurthy, A. M. (2011). E-government ethics: A

synergy of computer ethics, information ethics, and cyber ethics. e-Government,

2(8).

Redstone, A. (2014) What is the Purpose of a Code of Ethics? Available at:

http://www.ehow.com/facts_5490008_purpose-code-ethics.html

Reifer, D. J. (2011). Software Maintenance Success Recipes. CRC Press.

Rogerson, S. (2002). The software engineering code of ethics and professional practice:

a case for being proactive. In Proceedings-International Computer Software &

Applications Conference (pp. 344-345).

http://www.ehow.com/facts_5490008_purpose-code-ethics.html

92

Rodeño, M. J., Fontrodona, J., & Gutiérrez, J. A. Computer Ethics: A Syllabus For

Teaching Ethics In Computer Science.

Runeson, P., & Höst, M. (2009). Guidelines for conducting and reporting case study

research in software engineering. Empirical software engineering, 14(2), 131-164.

Runeson, P., Host, M., Rainer, A., & Regnell, B. (2012). Case study research in software

engineering: Guidelines and examples. John Wiley & Sons.

SADAD Payment System official website: [Online]. Available at:

http://www.sadad.com/English/history/Pages/Overview.aspx

Shakib, J., & Layton, D. (2014, May). Interaction between ethics and technology. In

Ethics in Science, Technology and Engineering, 2014 IEEE International

Symposium on (pp. 1-5). IEEE.

Schell, C. (1992). The value of the case study as a research strategy. Manchester Business

School, 2.

Software Engineering Code of Ethics (5.2) [Online]. Available at:

http://www.acm.org/about/se-code , ACM/IEEE-CS retrieved 21st February,

2014.

Sommerville, I. (2004). Software Engineering. International computer science series.

Taherdoost, H., Sahibuddin, S., Namayandeh, M., & Jalaliyoon, N. (2011). Propose an

educational plan for computer ethics and information security. Procedia-Social

and Behavioral Sciences, 28, 815-819.

Taherdoost, H., Sahibuddin, S., Namayandeh, M., & Jalaliyoon, N. (2013, December).

Computer and Information Security Ethics--Models. In Advanced Computer

Science Applications and Technologies (ACSAT), 2013 International Conference

on (pp. 145-149). IEEE.

Thomson, A. J., & Schmoldt, D. L. (2001). Ethics in computer software design and

development. Computers and Electronics in Agriculture, 30(1), 85-102.

Vallor, S. An Introduction to Software Engineering Ethics. Retrieved from

http://www.scu.edu/ethics/practicing/focusareas/technology/resources/Students.p

df

http://www.sadad.com/English/history/Pages/Overview.aspx

http://www.acm.org/about/se-code

93

Veatch, R.M., 1977. Case Studies in Medical Ethics. Cambridge: Harvard University

Press,

Volkman, R. (2015). Computer ethics beyond mere compliance. Journal of Information,

Communication and Ethics in Society, 13(3/4), 176-189.

Wiegers, K., & Beatty, J. (2013). Software requirements. Pearson Education.

Williams, L. (2006). Testing overview and black-box testing techniques. URL:

http://agile. csc. ncsu. edu/SEMaterials/BlackBox. pdf (accessed: 05/08/2008).

Yücel, R., Elibol, H., & Dağdelen, O. (2009). Globalization and international marketing

ethics problems. International Research Journal of Finance and Economics, 26,

93-104.

Yin, R. K. (2003). Case study research design and methods third edition. Applied social

research methods series, 5.

94

APPENDIX A- Software Engineering Code of Ethics and Professional

Practice (Full Version)

PREAMBLE

Computers have a central and growing role in commerce, industry, government,

medicine, education, entertainment and society at large. Software engineers are those

who contribute by direct participation or by teaching, to the analysis, specification,

design, development, certification, maintenance and testing of software systems. Because

of their roles in developing software systems, software engineers have significant

opportunities to do good or cause harm, to enable others to do good or cause harm, or to

influence others to do good or cause harm. To ensure, as much as possible, that their

efforts will be used for good, software engineers must commit themselves to making

software engineering a beneficial and respected profession. In accordance with that

commitment, software engineers shall adhere to the following Code of Ethics and

Professional Practice.

The Code contains eight Principles related to the behavior of and decisions made by

professional software engineers, including practitioners, educators, managers, supervisors

and policy makers, as well as trainees and students of the profession. The Principles

identify the ethically responsible relationships in which individuals, groups, and

organizations participate and the primary obligations within these relationships. The

Clauses of each Principle are illustrations of some of the obligations included in these

relationships. These obligations are founded in the software engineer’s humanity, in

special care owed to people affected by the work of software engineers, and the unique

elements of the practice of software engineering. The Code prescribes these as

obligations of anyone claiming to be or aspiring to be a software engineer.

It is not intended that the individual parts of the Code be used in isolation to justify errors

of omission or commission. The list of Principles and Clauses is not exhaustive. The

Clauses should not be read as separating the acceptable from the unacceptable in

professional conduct in all practical situations. The Code is not a simple ethical algorithm

that generates ethical decisions. In some situations standards may be in tension with each

other or with standards from other sources. These situations require the software engineer

to use ethical judgment to act in a manner which is most consistent with the spirit of the

Code of Ethics and Professional Practice, given the circumstances.

Ethical tensions can best be addressed by thoughtful consideration of fundamental

principles, rather than blind reliance on detailed regulations. These Principles should

influence software engineers to consider broadly who is affected by their work; to

95

examine if they and their colleagues are treating other human beings with due respect; to

consider how the public, if reasonably well informed, would view their decisions; to

analyze how the least empowered will be affected by their decisions; and to consider

whether their acts would be judged worthy of the ideal professional working as a

software engineer. In all these judgments concern for the health, safety and welfare of the

public is primary; that is, the "Public Interest" is central to this Code.

The dynamic and demanding context of software engineering requires a code that is

adaptable and relevant to new situations as they occur. However, even in this generality,

the Code provides support for software engineers and managers of software engineers

who need to take positive action in a specific case by documenting the ethical stance of

the profession. The Code provides an ethical foundation to which individuals within

teams and the team as a whole can appeal. The Code helps to define those actions that are

ethically improper to request of a software engineer or teams of software engineers.

The Code is not simply for adjudicating the nature of questionable acts; it also has an

important educational function. As this Code expresses the consensus of the profession

on ethical issues, it is a means to educate both the public and aspiring professionals about

the ethical obligations of all software engineers.

PRINCIPLES

Principle 1: PUBLIC

Software engineers shall act consistently with the public interest. In particular,

software engineers shall, as appropriate:

1.01. Accept full responsibility for their own work.

1.02. Moderate the interests of the software engineer, the employer, the client and the


1.03. Approve software only if they have a well-founded belief that it is safe, meets

specifications, passes appropriate tests, and does not diminish quality of life, diminish

privacy or harm the environment. The ultimate effect of the work should be to the public

good.

1.04. Disclose to appropriate persons or authorities any actual or potential danger to the

user, the public, or the environment, that they reasonably believe to be associated with

software or related documents.

96

1.05. Cooperate in efforts to address matters of grave public concern caused by software,

its installation, maintenance, support or documentation.

1.06. Be fair and avoid deception in all statements, particularly public ones, concerning


1.07. Consider issues of physical disabilities, allocation of resources, economic

disadvantage and other factors that can diminish access to the benefits of software.

1.08. Be encouraged to volunteer professional skills to good causes and contribute to


Principle 2: CLIENT AND EMPLOYER

Software engineers shall act in a manner that is in the best interests of their client and

employer, consistent with the public interest. In particular, software engineers shall, as

appropriate:

2.01. Provide service in their areas of competence, being honest and forthright about any

limitations of their experience and education.

2.02. Not knowingly use software that is obtained or retained either illegally or

unethically.

2.03. Use the property of a client or employer only in ways properly authorized, and with

the client's or employer's knowledge and consent.

2.04. Ensure that any document upon which they rely has been approved, when required,

by someone authorized to approve it.

2.05. Keep private any confidential information gained in their professional work, where

such confidentiality is consistent with the public interest and consistent with the law.

2.06. Identify, document, collect evidence and report to the client or the employer

promptly if, in their opinion, a project is likely to fail, to prove too expensive, to violate

intellectual property law, or otherwise to be problematic.

2.07. Identify, document, and report significant issues of social concern, of which they


2.08. Accept no outside work detrimental to the work they perform for their primary

employer.

97

2.09. Promote no interest adverse to their employer or client, unless a higher ethical

concern is being compromised; in that case, inform the employer or another appropriate

authority of the ethical concern.

Principle 3: PRODUCT

Software engineers shall ensure that their products and related modifications meet

the highest professional standards possible. In particular, software engineers shall,

as appropriate:

3.01. Strive for high quality, acceptable cost and a reasonable schedule, ensuring

significant tradeoffs are clear to and accepted by the employer and the client, and are

available for consideration by the user and the public.

3.02. Ensure proper and achievable goals and objectives for any project on which they

work or propose.

3.03. Identify, define and address ethical, economic, cultural, legal and environmental


3.04. Ensure that they are qualified for any project on which they work or propose to

work by an appropriate combination of education and training, and experience.

3.05. Ensure an appropriate method is used for any project on which they work or

propose to work.

3.06. Work to follow professional standards, when available, that are most appropriate for

the task at hand, departing from these only when ethically or technically justified.

3.07. Strive to fully understand the specifications for software on which they work.

3.08. Ensure that specifications for software on which they work have been well


3.09. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and



3.10. Ensure adequate testing, debugging, and review of software and related documents

on which they work.

98

3.11. Ensure adequate documentation, including significant problems discovered and


3.12. Work to develop software and related documents that respect the privacy of those


3.13. Be careful to use only accurate data derived by ethical and lawful means, and use it

only in ways properly authorized.

3.14. Maintain the integrity of data, being sensitive to outdated or flawed occurrences.

3.15 Treat all forms of software maintenance with the same professionalism as new

development.

Principle 4: JUDGMENT

Software engineers shall maintain integrity and independence in their professional

judgment. In particular, software engineers shall, as appropriate:

4.01. Temper all technical judgments by the need to support and maintain human values.

4.02 Only endorse documents either prepared under their supervision or within their areas

of competence and with which they are in agreement.

4.03. Maintain professional objectivity with respect to any software or related documents

they are asked to evaluate.

4.04. Not engage in deceptive financial practices such as bribery, double billing, or other


4.05. Disclose to all concerned parties those conflicts of interest that cannot reasonably


4.06. Refuse to participate, as members or advisors, in a private, governmental or

professional body concerned with software related issues, in which they, their employers

or their clients have undisclosed potential conflicts of interest.

Principle 5: MANAGEMENT

Software engineering managers and leaders shall subscribe to and promote an

ethical approach to the management of software development and maintenance . In

particular, those managing or leading software engineers shall, as appropriate:

99

5.01 Ensure good management for any project on which they work, including effective

procedures for promotion of quality and reduction of risk.

5.02. Ensure that software engineers are informed of standards before being held to them.

5.03. Ensure that software engineers know the employer's policies and procedures for

protecting passwords, files and information that is confidential to the employer or

confidential to others.

5.04. Assign work only after taking into account appropriate contributions of education

and experience tempered with a desire to further that education and experience.

5.05. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and

outcomes on any project on which they work or propose to work, and provide an


5.06. Attract potential software engineers only by full and accurate description of the

conditions of employment.

5.07. Offer fair and just remuneration.

5.08. Not unjustly prevent someone from taking a position for which that person is

suitably qualified.

5.09. Ensure that there is a fair agreement concerning ownership of any software,

processes, research, writing, or other intellectual property to which a software engineer

has contributed.

5.10. Provide for due process in hearing charges of violation of an employer's policy or of

this Code.

5.11. Not ask a software engineer to do anything inconsistent with this Code.

5.12. Not punish anyone for expressing ethical concerns about a project.

Principle 6: PROFESSION

Software engineers shall advance the integrity and reputation of the profession

consistent with the public interest. In particular, software engineers shall, as

appropriate:

6.01. Help develop an organizational environment favorable to acting ethically.

100

6.02. Promote public knowledge of software engineering.

6.03. Extend software engineering knowledge by appropriate participation in professional

organizations, meetings and publications.

6.04. Support, as members of a profession, other software engineers striving to follow

this Code.

6.05. Not promote their own interest at the expense of the profession, client or employer.

6.06. Obey all laws governing their work, unless, in exceptional circumstances, such

compliance is inconsistent with the public interest.

6.07. Be accurate in stating the characteristics of software on which they work, avoiding

not only false claims but also claims that might reasonably be supposed to be speculative,

vacuous, deceptive, misleading, or doubtful.

6.08. Take responsibility for detecting, correcting, and reporting errors in software and

associated documents on which they work.

6.09. Ensure that clients, employers, and supervisors know of the software engineer's

commitment to this Code of ethics, and the subsequent ramifications of such

commitment.

6.10. Avoid associations with businesses and organizations which are in conflict with this

code.

6.11. Recognize that violations of this Code are inconsistent with being a professional

software engineer.

6.12. Express concerns to the people involved when significant violations of this Code

are detected unless this is impossible, counter-productive, or dangerous.

6.13. Report significant violations of this Code to appropriate authorities when it is clear

that consultation with people involved in these significant violations is impossible,

counter-productive or dangerous.

Principle 7: COLLEAGUES

Software engineers shall be fair to and supportive of their colleagues. In particular,

software engineers shall, as appropriate:

101

7.01. Encourage colleagues to adhere to this Code.

7.02. Assist colleagues in professional development.

7.03. Credit fully the work of others and refrain from taking undue credit.

7.04. Review the work of others in an objective, candid, and properly-documented way.

7.05. Give a fair hearing to the opinions, concerns, or complaints of a colleague.

7.06. Assist colleagues in being fully aware of current standard work practices including

policies and procedures for protecting passwords, files and other confidential

information, and security measures in general.

7.07. Not unfairly intervene in the career of any colleague; however, concern for the

employer, the client or public interest may compel software engineers, in good faith, to

question the competence of a colleague.

7.08. In situations outside of their own areas of competence, call upon the opinions of

other professionals who have competence in that area.

Principle 8: SELF

Software engineers shall participate in lifelong learning regarding the practice of

their profession and shall promote an ethical approach to the practice of the

profession. In particular, software engineers shall continually endeavor to:

8.01. Further their knowledge of developments in the analysis, specification, design,

development, maintenance and testing of software and related documents, together with

the management of the development process.

8.02. Improve their ability to create safe, reliable, and useful quality software at

reasonable cost and within a reasonable time.

8.03. Improve their ability to produce accurate, informative, and well-written

documentation.

8.04. Improve their understanding of the software and related documents on which they

work and of the environment in which they will be used.

8.05. Improve their knowledge of relevant standards and the law governing the software

and related documents on which they work.

102

8.06 Improve their knowledge of this Code, its interpretation, and its application to their

work.

8.07 Not give unfair treatment to anyone because of any irrelevant prejudices.

8.08. Not influence others to undertake any action that involves a breach of this Code.

8.09. Recognize that personal violations of this Code are inconsistent with being a

professional software engineer.


103

APPENDIX B - Permission and Approval Letter

104

Appendix C - Interviews questions

1. Can you introduce yourself please?

Company:

Department:

Role:

2. Can you tell me how ethic is important in your work? Why? Implication?

_____________________________________________________________________

_____________________________________________________________________

3. In what manner ethics is being practice?

_____________________________________________________________________

_____________________________________________________________________

4. How about software engineering code of ethic?

a. Based on the SDLC what are the ethical concerns?

Requirement:

__________________________________________________________________

__________________________________________________________________

Design:

__________________________________________________________________

__________________________________________________________________

Coding:

__________________________________________________________________

__________________________________________________________________

Testing:

__________________________________________________________________

__________________________________________________________________

Deploy:

__________________________________________________________________

__________________________________________________________________

Maintenance:

__________________________________________________________________

__________________________________________________________________

105

b. Which are perceived to be the most challenging to be followed?

_______________________________________________________________

_______________________________________________________________

c. Which are perceived as important?

_______________________________________________________________

_______________________________________________________________

d. How they are imposed?

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

e. How do you make sure that code of ethics is being implemented within the

SDLC?

_______________________________________________________________

_______________________________________________________________

5. Is there any incident were there was a misconduct?

a. How did you know about it?

_______________________________________________________________

_______________________________________________________________

b. What kind of action did you take?

_______________________________________________________________

_______________________________________________________________

6. Do you want to make any suggestion on how to best practice software engineering

code of ethics in projects?

106

APPENDIX D - Sample of the questionnaire

Dear colleague,

This survey is used meant for research purposes only, as part of the requirement in the

completion of my Master of Science in Software Engineering at Prince Sultan University.

Any information collected from this survey will be treated with strictest confidentiality,

and will be destroyed once the research is completed.

As a software engineer please kindly take some time (Not more than 15 minutes) to

answer the questionnaire below on the topic of ethics in the field of software engineering.

Years of experience: _________________________________

Position: __________________________________________

Software Engineering Code of Ethics and Professional Practice (Version 5.2) has been

developed by the ACM/IEEE-CS Joint Task Force on Software Engineering Ethics and

Professional Practices and jointly approved by the ACM and the IEEE-CS as the standard

for teaching and practicing software engineering.

In the table below there are some ethical clauses from Software Engineering Code of

Ethics and Professional Practice (Version 5.2) by ACM and the IEEE-CS. For each

statement or clause, we would like you to please:

1. Chose the SDLC phase that each clause most likely will occur or relevant to by

checking (√) in the relevant column. (i.e. choose requirement, or/and design,

or/and code, or/and test)

2. Rate each software engineering code of ethics clauses BASED ON THEIR

PERCEIVED CHALLENGES to be followed by rating on the scale of 1 to 7,

where 1 is least challenging and 7 as highly challenging.

3. Rate each software engineering code of ethics clauses BASED ON THEIR

PERCEIVED RISK by rating on the scale of 1 to 7, where 1 is very low risk,

and 7 is very high risk.

IEEE/ACM Software Engineering Code of Ethics Requiremen

t

Design Code Test Maintenanc

e

Importanc

e

(1-7)

Challeng

e

(1-7)

1- PUBLIC - Software engineers shall act consistently with the public interest. In particular, software engineers shall, as appropriate:

107

1.1 Accept full responsibility for their own work.

1.2 Moderate the interests of the software engineer,

the employer, the client and the users with the public

good.

1.3 Approve software only if they have a well-

founded belief that it is safe, meets specifications,

passes appropriate tests, and does not diminish quality

of life, diminish privacy or harm the environment.

The ultimate effect of the work should be to the

public good.

1.4 Disclose to appropriate persons or authorities any

actual or potential danger to the user, the public, or

the environment, that they reasonably believe to be

associated with software or related documents.

1.5 Cooperate in efforts to address matters of grave

public concern caused by software, its installation,

maintenance, support or documentation.

1.6 Be fair and avoid deception in all statements,

particularly public ones, concerning software or

related documents, methods and tools.

1.7 Consider issues of physical disabilities, allocation

of resources, economic disadvantage and other factors

that can diminish access to the benefits of software.

1.8 Be encouraged to volunteer professional skills to

good causes and contribute to public education


2- CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best interests of their client and employer,

consistent with the public interest. In particular, software engineers shall, as appropriate:

2.1 Provide service in their areas of competence,

being honest and forthright about any limitations of

their experience and education.

2.2 Not knowingly use software that is obtained or

retained either illegally or unethically.

2.3 Use the property of a client or employer only in

ways properly authorized, and with the client's or

employer's knowledge and consent.

2.4 Ensure that any document upon which they rely

has been approved, when required, by someone

authorized to approve it.

2.05. Keep private any confidential information

gained in their professional work, where such

confidentiality is consistent with the public interest

and consistent with the law.

2.06. Identify, document, collect evidence and report

to the client or the employer promptly if, in their

opinion, a project is likely to fail, to prove too

expensive, to violate intellectual property law, or


2.07. Identify, document, and report significant issues

of social concern, of which they are aware, in

software or related documents, to the employer or the

client.

2.08. Accept no outside work detrimental to the work

108

they perform for their primary employer.

2.09. Promote no interest adverse to their employer or

client, unless a higher ethical concern is being

compromised; in that case, inform the employer or

another appropriate authority of the ethical concern

3- PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards

possible. In particular, software engineers shall, as appropriate:

3.1 Strive for high quality, acceptable cost and a

reasonable schedule, ensuring significant tradeoffs are

clear to and accepted by the employer and the client,

and are available for consideration by the user and the

public.

3.2 Ensure proper and achievable goals and objectives

for any project on which they work or propose.

3.3 Identify, define and address ethical, economic,

cultural, legal and environmental issues related to

work projects.

3.4 Ensure that they are qualified for any project on

which they work or propose to work by an

appropriate combination of education and training,

and experience.

3.5 Ensure an appropriate method is used for any

project on which they work or propose to work.

3.6 Work to follow professional standards, when

available, that are most appropriate for the task at

hand, departing from these only when ethically or

technically justified.

3.7 Strive to fully understand the specifications for

software on which they work.

3.08. Ensure that specifications for software on which

they work have been well documented, satisfy the

users’ requirements and have the appropriate

approvals.

3.09. Ensure realistic quantitative estimates of cost,

scheduling, personnel, quality and outcomes on any

project on which they work or propose to work and

provide an uncertainty assessment of these estimates.

3.10. Ensure adequate testing, debugging, and review

of software and related documents on which they

work.

3.11. Ensure adequate documentation, including

significant problems discovered and solutions

adopted, for any project on which they work.

3.12. Work to develop software and related

documents that respect the privacy of those who will

be affected by that software.

3.13. Be careful to use only accurate data derived by

ethical and lawful means, and use it only in ways

properly authorized.

3.14. Maintain the integrity of data, being sensitive to

outdated or flawed occurrences.

3.15 Treat all forms of software maintenance with the

same professionalism as new development.

109

4- JUDGMENT - Software engineers shall maintain integrity and independence in their professional judgment. In particular, software

engineers shall, as appropriate:

4.1 Temper all technical judgments by the need to

support and maintain human values.

4.2 Only endorse documents either prepared under

their supervision or within their areas of competence

and with which they are in agreement.

4.3 Maintain professional objectivity with respect to

any software or related documents they are asked to

evaluate.

4.4 Not engage in deceptive financial practices such

as bribery, double billing, or other improper financial

practices.

4.5 Disclose to all concerned parties those conflicts of

interest that cannot reasonably be avoided or escaped.

4.6 Refuse to participate, as members or advisors, in a

private, governmental or professional body concerned

with software related issues, in which they, their

employers or their clients have undisclosed potential

conflicts of interest.

In your point of view, please provide the most common issues of ethic that you believe

need to be addressed at each of the following phase:

1. Requirement

2. Design

3. Code

4. Test

5. Maintenance

110

APPENDIX E - Questionnaire Results and Analysis

111

Years of experience Weight Count

0-4 1 12 12

5- 9 2 3 6

10 and more 3 2 6

Total 17 24

24/2 = 12

Principle 1

Results After the weight

Requirement Design Code Test Maintenance Challenge Risk

1.1 Accept full responsibility for their own work. 22 23 21 18 15 4.7 4.93

1.2 Moderate the interests of the software

engineer, the employer, the client and the users

with the public good.

16 14 2 6 4 4.5 4.1

1.3 Approve software only if they have a well-

founded belief that it is safe, meets specifications,

passes appropriate tests, and does not diminish

7 8 11 14 5 4.8 5.4

112

quality of life, diminish privacy or harm the

environment. The ultimate effect of the work

should be to the public good.

1.4 Disclose to appropriate persons or authorities

any actual or potential danger to the user, the

public, or the environment, that they reasonably

believe to be associated with software or related

documents.

15 10 8 10 12 4.2 4.8

1.5 Cooperate in efforts to address matters of

grave public concern caused by software, its

installation, maintenance, support or

documentation.

12 3 9 8 16 4.1 4.1

1.6 Be fair and avoid deception in all statements,

particularly public ones, concerning software or

related documents, methods and tools.

15 18 8 8 12 4.3 4.2

1.7 Consider issues of physical disabilities,

allocation of resources, economic disadvantage

and other factors that can diminish access to the

benefits of software.

19 11 3 5 10 4.2 4

1.8 Be encouraged to volunteer professional skills

to good causes and contribute to public education


16 18 14 11 13 3.2 2.6

Principle 2



2.1 Provide service in their areas of competence,

being honest and forthright about any limitations

of their experience and education.

13 15 13 14 16 3.6 3

2.2 Not knowingly use software that is obtained or

retained either illegally or unethically.

9 8 18 10 12 4.5 5

2.3 Use the property of a client or employer only

in ways properly authorized, and with the client's

or employer's knowledge and consent.

22 21 19 20 15 3 4

2.4 Ensure that any document upon which they

rely has been approved, when required, by

someone authorized to approve it.

19 15 13 14 13 3.7 4

2.05. Keep private any confidential information

gained in their professional work, where such

confidentiality is consistent with the public

interest and consistent with the law.

21 11 14 13 16 4.7 5.2

2.06. Identify, document, collect evidence and

report to the client or the employer promptly if, in

18 11 7 15 5 4.4 5

113

their opinion, a project is likely to fail, to prove too

expensive, to violate intellectual property law, or


2.07. Identify, document, and report significant

issues of social concern, of which they are aware,

in software or related documents, to the

employer or the client.

21 14 5 15 12 4.5 4

2.08. Accept no outside work detrimental to the

work they perform for their primary employer.

18 14 12 11 16 3.6 4

2.09. Promote no interest adverse to their

employer or client, unless a higher ethical concern

is being compromised; in that case, inform the

employer or another appropriate authority of the

ethical concern.

13 13 12 13 10 3.6 4.4

Principle 3



3.1 Strive for high

quality,

acceptable cost

and a reasonable

schedule,

ensuring

significant

tradeoffs are clear

to and accepted

by the employer

and the client,

and are available

for consideration

by the user and

the public.

21 18 18 19 15 5.2 4.5

3.2 Ensure proper

and achievable

goals and

objectives for any

project on which

they work or

propose.

20 11 10 14 10 4.8 4.6

3.3 Identify,

define and

address ethical,

economic,

24 14 9 10 12 4.3 4.2

114

cultural, legal and

environmental

issues related to

work projects.

3.4 Ensure that

they are qualified

for any project on

which they work

or propose to

work by an

appropriate

combination of

education and

training, and

experience.

19 15 13 14 15 4.4 4.5

3.5 Ensure an

appropriate

method is used

for any project on

which they work

or propose to

work.

18 17 15 15 8 4 3.6

3.6 Work to

follow

professional

standards, when

available, that are

most appropriate

for the task at

hand, departing

from these only

when ethically or

technically

justified.

20 21 20 20 14 3.9 4

3.7 Strive to fully understand the specifications for software on which they work.

11 14 15 16 14 4.6 4.5

3.08. Ensure that specifications for software on which they work have been well documented, satisfy the users’ requirements and

11 9 7 13 12 5.2 4.4

115

have the appropriate approvals.

3.09. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes on any project on which they work or propose to work and provide an uncertainty assessment of these estimates.

21

12 10 10 9 4.7 4.3

3.10. Ensure adequate testing, debugging, and review of software and related documents on which they work.

4 8

8 22 1 4 5

3.11. Ensure adequate documentation, including significant problems discovered and solutions adopted, for any project on which they work.

10 12 11 15 13 4.4 4.2

3.12. Work to develop software and related documents that respect the privacy of those who will be affected by that software.

11 13 10 14 6 4.3 4.8

3.13. Be careful to use only accurate data derived by ethical and lawful means, and use it only in ways properly

14 10 9 17 14 4 4.4

116

authorized.

3.14. Maintain the integrity of data, being sensitive to outdated or flawed occurrences.

13 10 7 15 17 4 4.6

3.15 Treat all forms of software maintenance with the same professionalism as new development.

5 7 4 5 21 3.5 3.6

Principle 4

Results after the weight Requirement Design Code Test Maintenance Challenge Risk

4.1 Temper all technical judgments by

the need to support and maintain

human values.

20 12 9 12 15 3 2.8

4.2 Only endorse documents either

prepared under their supervision or

within their areas of competence and

with which they are in agreement.

19 20 15 16 12 3 3.5

4.3 Maintain professional objectivity

with respect to any software or related


15 11 9 16 14 3.7 3.7

4.4 Not engage in deceptive financial

practices such as bribery, double

billing, or other improper financial

practices.

22 18 17 17 18 3 4

4.5 Disclose to all concerned parties

those conflicts of interest that cannot

reasonably be avoided or escaped.

23 13 11 13 17 3.9 4.6

4.6 Refuse to participate, as members

or advisors, in a private, governmental

or professional body concerned with

software related issues, in which they,

their employers or their clients have

undisclosed potential conflicts of

interest.

22 13 8 14 13 4.4 5

In your point of view, please provide the most common issues of ethic that you believe need to be addressed at each of the following phase:

Requirement Design Code Test maintenance

1. - technical/solution knowledge - easy vs right way of - crack codes - the coverage -to much work

117

- compliance with rule and

regulation

design

-

- Non-

compliance

with the

company

policies

around

2. Separating the stakeholder needs from developer righteousness

3.

To be honest, Im not sure that I fully understood the questions, they were quit hard to analyze and answer.

However, I believe that keeping integrity, high quality, security, and achieving the business need on its optimum

figure, with respect to the agreed budget and timelines should be maintained throughout the software life cycle to

avoid any ethical issues. And the same applies for the below phases!

4.

5.

6. Not to bulid the requirement

based on personal needs or

support of a certain technology

Not to create the

design based on

personal needs or

support of a certain

technology

Not to create

harmful code

Not to jump

certain cases to

save time and

reduce cost

Creating issues

that were not

part of the main

release

7.

8. Honesty in meeting customer needs Training customers as they learn their needs because customers may not well know their needs - it is unethical to build requirements knowing the customer is uneducated in describing their needs

It is unethical to not follow the correct design standards, to use incorrect design templates and to not verify design has properly designed the requirements.

It is unethical to not follow the correct coding standards It is unethical to not verify you have coded the design and traced code back through design to the requirements.

It is unethical to not follow correct standards it is unethical to not perform traceability It is unethical to do a quick and dirty job It is unethical to pass software when it is known to be faulty

9.


Not engage in deceptive financial practices such as bribery, double billing, or other improper financial practices. *

Ensure an appropriate method is used for any project on which they work or propose to work.

Accept no outside work detrimental to the work they perform for their primary employer.

Not engage in deceptive financial practices such as bribery, double billing, or other improper financial practices. &

118

Treat all forms of software maintenance with the same professionalism as new development.

11. Ensuring proper security, privacy and that these are part of requirements from start.

Ensuring proper security, privacy and that these are part of designs from start.

Not cutting corners

Providing adequate testing.

Providing long term maintenance.

12.

13. we have to identify clearly requirement from end user perspective

using a stander code

troubleshooting any issue

14.

15.

119

APPENDIX F – Interviews results

Response Can you tell me how ethic is

important in your work? Obj 3

In what manner ethics is being practice?

Obj 1

1-

Multiple things ethics is very

important; because, what I see its

protects everyone, its protect the

organization its protect the people, so

it’s like one of the very important

aspect that everyone has to take it in

his consideration while he is working

in any company and this organization

is one of these example; so I believe if

we have a clear ethics if we have a

clear standard about these ethics

everything will be find, and maybe the

productivity of the organization will

be better.

Ok, as you know I’m working under (Company X )and there we have

standard as company x employees we have to have an ethics standard so

every year we have a refresh training we call it , where we have to go

through multiple ethics check points ; so as x employee we have to be

compliance with these ethics such as confidentiality, data , conflict of interest,

bribery. All these should be taken into consideration as part of our

refreshment training.

So how can I see the ethics impacting my job the alignment let take an

example when do the quality assurance within my function I have to make

sure all procedures are clear have the type or classification its confidential can

to be exposed so this can be consider part of the ethics another one can be

related to the people how they communicated with each other so we have

multiple layers I see it in this way we have:

Processes

People

The system itself the organization

So the processes should clear understand for each resource each document has

its own classification ethically you cannot expose it to any one unless it’s

clear for you whether you can or you cannot.

So for the people: we have multiple aspects; I have to make sure that the

people doesn’t have conflict of interest between SADAD and HP you have to

make sure that they are treated very well they do not have disregards or

disrespect or dignity issues all these aspect as a QA should be in

consideration. So I have to say one issue I found one incident so my job is to

escalate this to the committee and to resolve this so this ethical issue be

resolved because my understanding this will have impact on the moral of the

team so we have to resolve it directly is this for the people.

Now for the organization it all across the organization because every you

know when HP or SADAD has contract with HP so they have to make sure

that there no conflict of interest there’s no any gaps there is no any finding

that affect the ethical things so this is in general.

2- Off course; ethics is connected to

professionalism so the more you apply

work ethics the more you are

considered as a professional person

and your conduct is appreciated by

others. Also by applying ethics I

guess your supporting yourself and

preventing yourself from being in

troubles; troubles that can go into

confidentiality, integrity whatever that

can be a bad experience for yourself.

Ok, first thing is when you receive requirements for example; as a third party

some requirements might be difficult to develop and some might be easy to

develop so ethically you should not go with what’s easy to develop but rather

what’s best for the stakeholder asking you for this requirement, so you apply

ethics of knowing the best for your customer and doing it even if it’s not the

best solution for yourself as a third party.

From a change management perspective also the ethics that you should apply

is when you facilitate this change; I would say the time consumed; whenever a

request come the requester doesn’t know the complexity of this so you can say

it’s very complex its will take me a month or you can say it’s a very easy that

it going to take me a week. So again ethically you should support this.

3-

In my view I think ethics is something

very important; the reason behind is if

we do not have ethics in anything

First of all we keep up the moral value it’s not work alone , so we just say that

there are some soft skills that we need to develop and after that we need to

understand what particular thing will disturbed others. This are the things are

120

Based on the SDLC what are the ethical concerns? Obj1

Response Requirement Design Code Test

1- I think requirement is the start point and

the most difficult part; at this stage there

is the customer (I’m giving you this is

form my experience) now when start the

interaction with the customer the ethical

issues might come at this stage; the

Design or the technical team

including design development

testing I think the level will be there

but not the same as the requirement

ok, now the ethical might be

between the team for example

there is no any quality that is going to

be delivered right.

Suppose if we have a team mate and

then if there are not delivering okay, if

they do not have this ethical

consciousness in their mind that they

do not like suppose we have bugs and

all that whatever QA reports it been

there it’s there that software

development from our site they will

know something proactively that there

is a bug exists something like that, this

is we can not dig in further but it

applies like thing about it and ethical

value to it.

Overall it’s very important as I see a

stone in software development.

going to encompass the complete value. As a practice what we do it during

meeting monthly meetings we do collaborate and we do speak up and we

come up with a variable messing in the slide we give our input.

Response

How about software engineering code of ethic?

1 to be honest with you I do not have wariness about it; if there is something called software engineering ethics I

know about the generic ethical issue as I mentioned the refresh training we have a generic staff for all the

organization not for a specific district we have the bribery ethics you shouldn’t do it we have the conflict of interest

we have dignity we have all this stuff covered in the refresher training and all HP employee comply to this training

2 I never read it.

3

Software engineering code of ethics heard about it but not going very deep about it.

It’s there we know it in our head and everyone knows about it as a policy as a process. But specifically we do not

have that.

It’s a very good at least I feel it’s there it has to be practice. Yes, it’s better to have it as a SDLC we want to match

this with an SDC itself. When we talk about SDLC we are talking about different perspectives.

121

customer my ask for things let say

beyond the expectation and in order to

achieve them and get the customer

satisfaction you might exceed or you

might violate your ethical issues in order

to achieve this.so I think this is very

important point is has to be addressed

very well at this level so this is for

requirement.

between the testing and the

development when I was managing

the testing team I was facing a lot of

issues between the development and

testing sometimes we .. some words

sometimes we do not accept the way

they are developing the system so a

lot of clashes introduced and some

classes can introduce some ethical

issues and some time we disregard

there work we disregard the quality

of the work they deliver, so we

consider them they do not work as

what they supposed to do, do you

got my point so its doses reach to the

level.

2-

As I said ethically you should support

the best for the requester and not the

easy solution rather any different

solution you might think of. Or you

know that this not satisfy him but you do

not say It.; so you should make him

aware of what he asking for and wheat

he is receiving.

For the design I would say that you

can say; it’s depends on the

company for example you can

design a code that it’s prone to

hacking let say weak. There is a

strong code and a weak code;

sometimes writing a weak code of

not following the best practices for

coding may make it simple and easy

to change. However, ethically you

should not; you should go with dried

coding practices.

3-

If we going to collect a requirement

generally we will see what is there and

what’s is need and they will contact the

Clint then they will had the CAD and

something like that, for me this my;

ethical practice sometimes it will be or

it’s hard for BA to dig further into what

exactly the client needs in generally and

If you see that a problem can have

many designed solutions. From

requirement it will come to

architecture then design and all that.

Again from design point of view it

has something with man days right

so you will design and complexity

generally what happens form the

From

development

point of view as I

said I gave you

one example;

about fixing a

bugs. Here form

ethical point of

Testing point

of view it

goes there

like as I go it

can be same

as reporting

the bug, there

are pressure

122

it’s been identified that there are 50%

knows what they need and the other

50% they do not know what they need.

They what something like that they just

will give comparison there ; the BA

should go much deeper not just as

project point of view if I know that this

requirement going to be easier tougher it

should not be that way he should

separate that and he should be collecting

everything not what I like.

bottom up the manager is there and

his going to tell you that there is a

limited recourse of JAVA resource

something like that I feel that the

design should not be bind to

something like that is should be

dependent and directly its affects us.

It’s should come more ethical value

not something driven form

circumstances and situations all that

it should come from what it’s the

best approach to do that

view what I feel

is fixing the bug

(I’m going

further) that can

be a bug that fix

the problem and

there can be bug

the postpone the

problem that there

are way as

sometime we

cannot cover it up

completely we

just have bugs not

are been fixed

completely we

give it the

production we

going to solve this

and we know that

this will be

opened again in a

while. Just

because the

pressure is on I

think this the one

and I feel

software

development

should be spate

form that concern.

I just give you an

example it can be

many.

on and then

there is a

blocker blog

we fixed it

then it’s

become a

functional

bug in their

consciousness

they had to

report

whatever,

they should

not keep it to

them self like

I assume or

presume that

this will not

happen that

not a very

good practice,

they should

think it from

production

point of view,

like they just

think it the

software

developer

give this bug

and they have

to assist this

and they

should think it

from a

production

point of view

123

like what

would happen

and if they

have and

SADAD

specially what

I feel is like if

they have an

environmental

problems they

compromise a

bit they will

assume that

this recourse

will accesses

this database

and then

problem will

not going to

come they not

to be blame

but they just

compromise

that. I think

from an

ethical point

for view they

should be

zero

compromise.

Respon

se

Which are perceived to be the

most challenging to be followed?

Which are

perceived as

important?

How they are imposed?

1-

The hardest is resolving conflict of

interests; this is the hardest part for

me I see is conflict of interest

between teams.

Ok, what the code of

ethics you are

referring to? I think

people respect and

As I mentioned we try not to force them; but in the

documentation yes we enforce them in the policies and the

procedures; all documents should be clear. For the other part

no we do not have something like that SADAD have ethics

124

the dignity, it’s very

important to build a

healthy environment

for bribery we do not have like code of ethics for respect. So

I think it’s the right time for us to start thinking of this

specially the quality team of the steering committee for the

organization. They have to consider those factor because this

is will increase the moral of the team if we do not have a

clear standard and we do not know what are the

consequences if you do not have them and what’s the benefits

if you have them and what’s are the impacts if you do not

have them; I think is going to be better for us.

2- It’s depends everyone on his area

so to me I might say facilitating the

requirement between the requester

and the designer because

sometimes the designer might not

understand the business need for it.

And go and just tell you do not do

this or do not implement this. So

you have to be a mediator between

the designer and the requester.

I would say

certifying the release

which is from testing

perspective.

From requirement perspective whenever your requirements

does not meet the requester or the stakeholder needs we call

it a gap and we have according to our KPIs or performance

indicators the number of gaps in each release so whenever

these are identified its makes bad performance so we make

sure no one finds a gaps In our requirements.

The BA process tell you whenever you write a requirement

you have to check for its completeness there is certain things

you have to check for to make sure that there is no gap into

your requirements. So we have a procedure for this.

3-

The toughest thing to adapt. I feel

the compromising of the time line

because it across all the SDLC.

Like because the timeline is there

and the pressure is there I think the

quality will be the toughest one.

This is should not be there is

should

I will go with the

same

I feel with my personal opinion just educating them

periodically and sometime in my experience we see such

behaviors like unethical behavior form employees and

something like that. I’m not saying that its really bad but,

maybe this person doesn’t have that knowledge, so we need

to educate them that it’s not the way its supposed to be and

then it will be good to have a processes and tell them the

benefit we got of it’s the point is that they do not see that at

benefit at their level they look into the organization level so

bringing it to the personal level saying that if you applied it

will help you.

Respon

se

Is there any incident were there was a misconduct? How did you know

about it? What kind of action did you

take?

1-

As I mentioned yes, we had some incidents and we

resolved them.

People disrespect and regard Conflict of interest and the

quality of the services.

Let take one by one; for the people disrespect and dignity I

already escalated to the higher management and they

already resolved it. Not SADAD to HP.

AND FOR conflict of interest until know sometimes it’s

From experience; and I

was part of it.

When we have those issues we

communicate it to the customers.

And they expose it to the partner.

125

not do you want me to give an example? Like sometime

the Service Design team asks HP recourse to verify HP

resource because we have SADAD 2 and we have HP

local team Service Creation so SD sometimes request for

HP local team to verify SADAD 2 jobs or delivers so

because the SC and SADDA 2 HP resource this will cause

a conflict of interest we always faces this we try to

decrease it but it’s not easy and the request come from the

customer so its causes conflict of interest.

2- Yes, actually as I said from business people they do not; ,

they just tell you what they required when they write the

CAD they do not make sure that this satisfies their need.

So sometimes for time sake and the easiest way they put

the solution and they just go through it with business

without telling them what the risk is or what goanna is

happen.

Through reviewing the

CAD, when I review

the CAD I noticed that

there is no risk impact

analysis done.

It was reported to management; I

reported to my manager that this

CAD doesn’t have risk impact

analysis and the BA team had to

complete it.

3-

Not misconduct but, mistakes. Yes, mistakes do happened.

Respon

se

How do you make sure that code of ethics is being

implemented within the SDLC Do you want to make any suggestion on how to best

practice software engineering code of ethics in projects?

1-

There is no clear check that it’s told you. We have code of

ethics implemented within our processes. As I mentioned

the yearly training; but the yearly training doesn’t give you

an indicator; we haven’t done an assessment before

I think as I mentioned in order to come up to a healthy

environment I think every organization should have a code

of ethic, standard and policy. And this policy.

2- From KPI, and if the release is deployed and the biller or the

bank find a bug, it’s identified then. Also through reviews;

before the release the CAD we send it for reviews from

technical reviews from stakeholder reviews from partners so

they can identify the gaps before we deploy the release.

3-

It’s like proactive its reactive actually after the problem is

identified

Yes, as I told you by having at the organization level then at

the department level and as part of software development

policy we mention ethical behavior and all that.

Documents

A Framework for Ethical Practices in Software Development ...info.psu.edu.sa/intranet/Library/files/THE00011.pdf · A Framework for Ethical Practices in Software Development Life