A Framework for Ethical Practices in Software Development Life Cycle: A case study in the Kingdom of Saudi Arabia

Size: px
Start display at page:

Download "A Framework for Ethical Practices in Software Development Life Cycle: A case study in the Kingdom of Saudi Arabia"

Transcription

1 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 I

2 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 II

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

4 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. IV

5 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 V

6 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 VI

7 ملخص البحث إطار عمل للممارسات األخالقية في مجال دورة حياة تطوير البرمجيات ع ىل أخالقيات هندسية البرمجيات هي إحدى المناطق في نطاق هندسة البرمجيات التي تتطلب اهتماما كبيرا للبحث العلمي: لما لها من تأثير كبير على كيفية تأثير البرمجيات على حياتنا من خالل استخدامنا اليومي لها. درجة الضرر المستخدمين يعتمد إلى حد كبير على قدرة مهندسي البرمجيات لمتابعة الممارسات الجيدة في مجال هندسة البرمجيات. في فمن الواضح أنه ليس هناك الكثير من األبحاث وجدت في هذا المجال التي تركيز على الكيفية التي يتم بها ممارسة أخالقيات هندسة البرمجيات وما إذا كان هناك أي إطار عمل يتم اتباعه من قبل المهندسين. ولذلك اقترح هذا البحث لملء هذه الفجوة من البحوث في هذا المجال. وحقق هذا البحث هدفه: وهو فهم كيف يمارس مهندس البرمجيات أخالقيات وقواعد السلوك في دورة حياة تطوير البرمجيات والتحقيق في التحديات التي تواجه مهندسي البرمجيات وصعوبة اتباع هذه األخالقيات. عن طريق تحليل سياسات اجراءات ووثائق إدارة المشاريع. تاله إجراء مقابالت مع خبراء واستبيانات تم تعبئتها من قبل مهندسي البرمجيات. والهدف الثاني والثالث وهم تحديد اي الممارسات األخالقية هندسة البرمجيات أصعب وأكثر تحديا تطبيقها وأيهم ينظر مهندس البرمجيات أنها ذات خطورة عالية وتم تحقيق هذه األهداف عن طريق استبيانات وزعت لمهندسي البرمجيات. أما الهدف الرابع وهو اقتراح إطار ومبادئ توجيهية لمهندسي البرمجيات في كل مرحلة من مراحل دورة حياة تطوير البرمجيات عن طريق توزيع استبيان على مهندسي البرمجيات ليقوموا بتصنيف الممارسات األخالقية في هندسة البرمجيات على أساس مراحل دورة حياة تطوير البرمجيات. وإن من أهم نتائج البحث كانت هي أنه ال يوجد دالئل على وجود إطار ومبادئ توجيهية لمهندسي البرمجيات في كل مرحلة من مراحل دورة حياة تطوير البرمجيات في الشركة أو علم مهندسي البرمجيات بوجود إطار ومبادئ توجيهية لمهندسي البرمجيات. كما أنه لوحظ أنه ال يوجد فرق بين ما يعتقد مهندسو البرمجيات من الممارسات األخالقية في هندسة البرمجيات على انها أصعب وأكثر تحديا تطبيقه ومن أيهم ينظر مهندسو البرمجيات على انها ذات خطورة عالية. إن اقتراح إطار ومبادئ توجيهية لمهندسي البرمجيات في كل مرحلة في دورة حياة تطوير البرمجيات وفهم كيف يمارس مهندس البرمجيات أخالقيات وقواعد السلوك في دورة حياة تطوير البرمجيات والتحقيق في التحديات التي تواجه مهندسي البرمجيات وصعوبة اتباع هذه األخالقيات كما أن اقتراح تصنيف جديد ألخالقيات هندسية البرمجيات على أساس مراحل دورة حياة تطوير البرمجيات يساعده مهندسي البرمجيات على فهم تطبيق مراقبة ورصد مهندسي البرمجيات. كما أنه اعتماد واتباع أخالقيات هندسية البرمجيات يؤدي إلى تحسين الثقة العامة والسمعة من خالل اتباع االجراءات والسياسات التي تهتم بالوفاء بالمصالح العامة من خالل مستوى عال من VII

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

9 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 Background The Research Problem Research Questions Research Objectives Research Contribution Outline of the Thesis... 6 CHAPTER 2 - LITERATURE REVIEW Software Engineering and Ethics Software Engineering Code of Ethics Importance of Software Engineering Code of Ethics Related Research Summary CHAPTER 3 METHODOLOGY Research Approach Research Design Case Study Data Collection Data Analysis Summary CHAPTER 4 RESULTS AND DISCUSSION How Code of Ethics is Being Implemented in SADAD Document Analysis IX

10 4.1.2 Interview Analysis Questionnaire Analysis Identification of High Risk and Most Challenging SWECOE to Follow High Risk and Most Challenge SWECOE to Follow SWECOE based on the SDLC Phases Questionnaire Results New Classification of SWECOE based on the SDLC Proposed framework Validation Summary CHAPTER 5 CONCLUSION Summary Findings Research contribution and recommendation Research Limitations and Suggestion for Future Research REFERENCES APPENDIX A- Software Engineering Code of Ethics and Professional Practice (Full Version) PREAMBLE APPENDIX B - Permission and Approval Letter Appendix C APPENDIX D - Sample of the questionnaire APPENDIX E - Questionnaire Results and Analysis APPENDIX F Interviews results X

11 LIST OF TABLES Table 2. 1 ACM and IEEE-CS Software Engineering Code of Ethics principles Table 3. 1 Interviewee Overview Table 3. 2 Summary of research objectives and data collection strategies Table 4. 1 Reasons why having code of ethics is important Table 4.2 Ethical concerns on the requirement phase based on the interviews Table 4.3 Ethical concerns about the design phase based on the interviews Table 4.4 Ethical concerns on the coding phase based on the interviews Table 4.5 Ethical concerns on the testing phase based on the interviews Table 4.6 Ethical concerns on the maintenance phase based on the interviews Table 4. 7 Summary of the ethical concerns about each SDLC phase Table 4.8 Ethical concerns about each SDLC phase from the interviewees perspectives Table 4.9 Public principle clause based on the risk rating Table 4.10 Client and employer principle clause listed based on the risk rating Table 4.11 Product clause based on the risk rating along Table 4.12 Judgment principle clause based on the risk rating Table 4.13 Questionnaire segmentation analysis Table 4.14 Public principle clause as aligned with the SDLC phases Table 4.15 Client and employer principle clause as aligned with the SDLC phases Table 4.16 Product principle clause as aligned with the SDLC phases Table 4.17 Judgment principle clause as aligned with the SDLC phases Table 4.18 Case Table 4.19 Case Table Research objectives and Results XI

12 LIST OF FIGURES Figure 2. 1 e-government ethics position related to computer ethics, information ethics, cyber ethics and other applied ethics Figure 3. 1 Research Design Diagram Figure 3.2 SADAD Overview (SADAD Payment System official website) Figure 4.1 Requirement Verification and Validation Guidelines Criteria for a quality requirement Figure 4.2 Requirement Verification and Validation Guidelines Guidelines for writing requirements statements Figure 4.3 Requirement Verification and Validation Guidelines Verifications Guidelines Figure 4. 4 Screen shot from Business Analysis Performance Evaluation Guidelines document. 38 Figure 4. 5 General clauses Figure 4. 6 Requirement Clauses Figure 4.7 Design Clauses Figure 4.8 Code Clauses Figure 4.9 Test Clauses Figure 4.10 Maintenance Clauses Figure 4.11 ACM/IEEE 8 Principles Figure 4.12 ACM/IEEE first four principles Figure 4.13 SDLC Phases Figure New proposed SDLC Code of Ethics Framework XII

13 List of abbreviations SWECOE SDLC KSA ACM IEEE SAMA EBPP BA KPIs SLR ROA ROE SEEPP EDSD Software Engineering Code Of Ethics Software Development Life Cycle Kingdom of Saudi Arabia Association for Computing Machinery Institute of Electrical and Electronics Engineers Saudi Arabian Monetary Agency Electronic Bill Presentment and Payment Business Analysis Key Performance Indicator Systematic literature review Return on Assets Return on Equity Software Engineering Ethics and Professional Practice Ethical-Driven Software Development XIII

14 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). 1

15 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. 2

16 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 3

17 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). 4

18 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 development life cycle. 1.5 Research Contribution The contribution of the research are described in the following paragraphs. 5

19 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. 6

20 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,. 7

21 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 selfreflection 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. 8

22 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 9

23 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. (ACM/IEEE-CS Joint Task Force, 2014). 10

24 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 PUBLIC CLIENT AND EMPLOYER PRODUCT JUDGMENT MANAGEMEN T PROFESSION COLLEAGUES SELF Description Software engineers shall act consistently with the public interest. Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest Software engineers shall ensure that their products and related modifications meet the highest professional standards possible Software engineers shall maintain integrity and independence in their professional judgment. Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance. Software engineers shall advance the integrity and reputation of the profession consistent with the public interest. Software engineers shall be fair to and supportive of their colleagues. 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: 11

25 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 12

26 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). 13

27 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). 14

28 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. 15

29 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 16

30 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 17

31 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 18

32 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 technologydependent, 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 19

33 (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? 20

34 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 21

35 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. 22

36 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. 23

37 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 24

38 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. 25

39 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). 26

40 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. 27

41 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. 28

42 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. 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 years Software development manager 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 29

43 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. A case study by analyzing how code of ethics is being practiced on a well-known financial company in Saudi Arabia (SADAD). Interview software engineers Distribute questionnaire 3. To investigate which software engineering code of ethics is perceived to be of a high risk. 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 Distribute questionnaire To propose a classification of the 4. 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 Distribute questionnaire Analysis of evidence from all data collection techniques 30

44 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 31

45 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 scenariobased session was conducted with practitioners to validate some elements in the framework. 32

46 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 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 33

47 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. 34

48 Figure 4.1 Requirement Verification and Validation Guidelines Criteria for a quality requirement 35

49 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

50 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 37

51 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. Figure 4. 4 Screen shot from Business Analysis Performance Evaluation Guidelines document 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 Interview Analysis 38

52 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. 39

53 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 40

54 Productivity Increase company morale Professionalis m Avoiding troubles and Maintain integrity Quality P1 P1 P2 P2 P3 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. 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. 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. 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. 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. 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). 41

55 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 42

56 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. 43

57 Table 4.2 Ethical concerns on the requirement phase based on the interviews Ethical concerns Conflict of interest Participant Requirement phase P1 P2 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. 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. Software engineer misrepresenting the actual cost, time or complexity Vague P2 P3 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. 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. Ethical practice sometimes it will be or it s hard for BA to dig further into what exactly the client needs. 44

58 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 45

59 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 Compromising quality to meet time, cost or because of the available resources P2 P3 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. 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 46

60 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 Developing weak code P2 P3 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. 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 47

61 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 48

62 Ethical concerns Participant Test Releasing software with defects to meet the scheduled time Certifying/ passing release with bugs without knowing its exact effects P3 P2 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. 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. 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 49

63 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. 50

64 Table 4. 7 Summary of the ethical concerns about each SDLC phase SDLC Phase Requirements Ethical concern 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 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 51

65 SDLC Phase Requirements Design Ethical concern 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 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 52

66 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 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 53

67 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. 1.1 Accept full responsibility for their own work 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.6 Be fair and avoid deception in all statements, particularly public ones, concerning software or related documents, methods and tools Moderate the interests of the software engineer, the employer, the client and the users with the public good Cooperate with efforts to address matters of grave public concern caused by software, its installation, maintenance, support or documentation. 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

68 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 Keep private any confidential information gained in professional work, where such confidentiality is consistent with the public interest and consistent with the law. 2.2 Not knowingly use software that is obtained or retained either illegally or unethically 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 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. 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 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 Accept no outside work detrimental to the work they perform for their primary employer. 2.1 Provide service in their areas of competence, being honest and forthright about any limitations of their experience and education. Risk (1-7) Challenge (1-7)

69 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) Ensure adequate testing, debugging, and review of software and related documents on which they work Work to develop software and related documents that respect the privacy of those who will be affected by that software. 3.2 Ensure proper and achievable goals and objectives for any project on which they work or propose Maintain the integrity of data, being sensitive to outdated or flawed occurrences. 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.7 Strive to fully understand the specifications for software on which they work

70 3.08. Ensure that specifications for software with which they work have been well documented, satisfy the users requirements and have the appropriate approvals Be careful to use only accurate data derived by ethical and lawful means, and use it only in ways properly authorized 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.3 Identify, define and address ethical, economic, cultural, legal and environmental issues related to work projects Ensure adequate documentation, including significant problems discovered and solutions adopted, for any project on which they 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.5 Ensure an appropriate method is used for any project on which they work or propose to work Treat all forms of software maintenance as new development with the same professionalism 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 57

71 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.5 Disclose to all concerned parties those conflicts of interest that cannot reasonably be avoided or escaped. 4.4 Not engage in deceptive financial practices such as bribery, double billing, or other improper financial practices. 4.3 Maintain professional objectivity with respect to any software or related documents they are asked to evaluate. 4.2 Only endorse documents either prepared under their supervision or within their areas of competence and with which they are in agreement. 4.1 Temper all technical judgments by the need to support and maintain human values. (1-7) (1-7) 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 58

72 and more Total 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 Questionnaire Results Principle 1 Public For the first principle the results are shown in Table Table 4.14 Public principle clause as aligned with the SDLC phases Clause 1.1 Accept full responsibility for their own work. Requirement Design Code Test Maintenance 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 59

73 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 Table 4.15 Client and employer principle clause as aligned with the SDLC phases Clause 2.1 Provide service in their area of competence, being honest and forthright about any limitations of their experience and education. Requirement Design Code Test Maintenance 60

74 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 Keep private any confidential information gained in their professional work, where such confidentiality is consistent with the public interest and consistent with the law 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 otherwise to be problematic 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 Accept no outside work detrimental to the work they perform for their primary employer Promote no interest adverse to their employer or client, unless a 61

75 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 Table 4.16 Product principle clause as aligned with the SDLC phases Clause 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. Requirement Design Code Test Maintenance 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 62

76 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 Ensure that specifications for software on which they work have been well documented, satisfy the users requirements and have the appropriate approvals 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 Ensure adequate testing, debugging, and review of software and related documents on which they work Ensure adequate documentation, including significant problems discovered and solutions adopted, for any project on which they work Work to develop software and related documents that respect the privacy of those who will be 63

77 affected by that software Be careful to use only accurate data derived by ethical and lawful means, and use it only in ways properly authorized Maintain the integrity of data, being sensitive to outdated or flawed occurrences 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 Table 4.17 Judgment principle clause as aligned with the SDLC phases Clause 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. Requirement Design Code Test Maintenance 64

78 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 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. 65

79 Public 1.1 Accept full responsibility for their own work. Client and employer 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. Product 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. Judgment 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. 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. 66

80 Public 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. Client and employer Keep private any confidential information gained in their professional work, where such confidentiality is consistent with the public interest and consistent with the law 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 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 Accept no outside work detrimental to the work they perform for their primary employer 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. Product 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 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 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 Ensure adequate documentation, including significant problems discovered and solutions adopted, for any project which they are working on or propose. to work on Be careful to use only accurate data derived by ethical and lawful means, and use it only in ways properly authorized Maintain the integrity of data, being sensitive to outdated or flawed occurrences. Judgment 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. Figure 4. 6 Requirement Clauses 67

81 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. Public 1.2 Moderate the interests of the software engineer, the employer, the client and the users with the public good. 1.6 Be fair and avoid deception in all statements, particularly public ones, concerning software or related documents, methods and tools. 1.8 Be encouraged to volunteer professional skills to good causes and contribute to public education concerning the discipline. Client and employer 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 Accept no outside work detrimental to the work they perform for their primary employer 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 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. Product 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.7 Strive to fully understand the specifications for software which they are working on or propose. to work on 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 Ensure adequate documentation, including significant problems discovered and solutions adopted, for any project which they are working on or propose to work on Work to develop software and related documents that respect the privacy of those who will be affected by that software Be careful to use only accurate data derived by ethical and lawful means, and use it only in ways properly authorized Maintain the integrity of data, being sensitive to outdated or flawed occurrences. Judgment 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. Figure 4.7 Design Clauses 68

82 Code phase Based on the results, Figure 4.8 shows the applicable clauses to code phase where the clause score is 12 or above. Public 1.2 Moderate the interests of the software engineer, the employer, the client and the users with the public good. 1.8 Be encouraged to volunteer professional skills to good causes and contribute to public education concerning the discipline. Client and employer 2.2 Not knowingly use software that is obtained or retained either illegally or unethically Keep private any confidential information gained in their professional work, where such confidentiality is consistent with the public interest and consistent with the law Accept no outside work detrimental to the work they perform for their primary employer 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. Product 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. Judgment Figure 4.8 Code Clauses 69

83 Test Phase Based on the results, Figure 4.9 shows the applicable clauses to Test phase where the clause score is 12 or above. Public 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.8 Be encouraged to volunteer professional skills to good causes and contribute to public education concerning the discipline. Client and employer Keep private any confidential information gained in their professional work, where such confidentiality is consistent with the public interest and consistent with the law 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 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 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. Product.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 Ensure that specifications for software which they are working on have been well documented, satisfy the users requirements and have the appropriate approvals Ensure adequate testing, debugging, and review of software and related documents which they are working on Ensure adequate documentation, including significant problems discovered and solutions adopted, for any project which they are working on Work to develop software and related documents that respect the privacy of those who will be affected by that software Be careful touse only accurate data derived by ethical and lawful means, and use it only in ways properly authorized Maintain the integrity of data, being sensitive to outdated or flawed occurrences. Judgment 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. Figure 4.9 Test Clauses 70

84 Maintenance Phase Based on the results, Figure 4.10 shows the applicable clauses to maintenance phase where the clause score is 12 or above. Public 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.8 Be encouraged to volunteer professional skills to good causes and contribute to public education concerning the discipline. Client and employer 2.2 Not knowingly use software that is obtained or retained either illegally or unethically Keep private any confidential information gained in their professional work, where such confidentiality is consistent with the public interest and consistent with the law 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 Accept no outside work detrimental to the work they perform for their primary employer. Product 3.3 Identify, define and address ethical, economic, cultural, legal and environmental issues related to work projects. 3.7 Strive to fully understand the specifications for software on which they work Ensure that specifications for software on which they work have been well documented, satisfy the users requirements and have the appropriate approvals Ensure adequate documentation, including significant problems discovered and solutions adopted, for any project on which they work Be careful to use only accurate data derived by ethical and lawful means, and use it only in ways properly authorized Maintain the integrity of data, being sensitive to outdated or flawed occurrences Treat all forms of software maintenance with the same professionalism as new development. Judgment 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. Figure 4.10 Maintenance Clauses 71

85 4.4 Proposed framework The existing ACM/IEEE SWECOE is based on eight principles as shown in Figure Professio n Public Client and Employer Manage ment ACM/IEE E SWECOE principles Self Judgmen t College Product 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 Public Judgment ACM/IEEE SWECOE principles Client and Employer Product Figure 4.12 ACM/IEEE first four principles 72

86 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 Requirement Maintenance Design ACM/IEEE SWECOE Test Code Figure 4.13 SDLC Phases 73

87 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 Categorization of code of ethics ACM/IEEE Code of Ethics 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 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.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.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. COE to be followed in SDLC Software Development Process (SDLC) Figure 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

88 Table 4.15 Proposed Framework SDLC Phase Genera l Requir ement Ethical concern 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. 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 75

89 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 27. Maintain the integrity of data, being sensitive to outdated or flawed occurrences. 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 76

90 Design 1. 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. 2. Be fair and avoid deception in all statements, particularly public ones, concerning software or related documents, methods and tools. 3. Disclose to all concerned parties those conflicts of interest that cannot reasonably be avoided or escaped. 4. Maintain the integrity of data, being sensitive to outdated or flawed occurrences. 5. Strive to fully understand the specifications for software on which they work. 6. Be careful to use only accurate data derived by ethical and lawful means, and use it only in ways properly authorized. 7. 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. 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. 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. 10. Identify, define and address ethical, economic, cultural, legal and environmental issues related to work projects. 11. Ensure an appropriate method is used for any project on which they work or propose to work. 12. Ensure adequate documentation, including significant problems discovered and solutions adopted, for any project on which they work. 13. Moderate the interests of the software engineer, the employer, the client and the users with the public good. 14. 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. 15. Accept no outside work detrimental to the work they perform for their primary employer. 16. Maintain professional objectivity with respect to any software or related documents they are asked to evaluate. 17. Be encouraged to volunteer professional skills to good causes and contribute to public education concerning the discipline. 18. Temper all technical judgments by the need to support and maintain human values. 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. 77

91 23. Not engage in deceptive financial practices such as bribery, double billing, or other improper financial practices. 24. Ensuring proper security, privacy and that these are part of designs from start. Codin g 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. Not knowingly use software that is obtained or retained either illegally or unethically. 3. Strive to fully understand the specifications for software on which they work. 4. 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. 5. Accept no outside work detrimental to the work they perform for their primary employer. 6. The interests of the software engineer, the employer, the client and the users with the public good. 7. Ensure an appropriate method is used for any project on which they work or propose to work. 8. Be encouraged to volunteer professional skills to good causes and contribute to public education concerning the discipline. 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. 2. Keep private any confidential information gained in their professional work, where such confidentiality is consistent with the public interest and consistent with the law. 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. 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 78

92 on which they work. 6. Work to develop software and related documents that respect the privacy of those who will be affected by that software. 7. Disclose to all concerned parties those conflicts of interest that cannot reasonably be avoided or escaped. 8. Maintain the integrity of data, being sensitive to outdated or flawed occurrences. 9. Strive to fully understand the specifications for software on which they work. 10. 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. 11. Ensure that specifications for software on which they work have been well documented, satisfy the users requirements and have the appropriate approvals. 12. Be careful to use only accurate data derived by ethical and lawful means, and use it only in ways properly authorized. 13. Ensure adequate documentation, including significant problems discovered and solutions adopted, for any project on which they work. 14. 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. 15. Ensure that they are qualified for any project on which they work or propose to work by an appropriate 16. Maintain professional objectivity with respect to any software or related documents they are asked to evaluate. 17. Temper all technical judgments by the need to support and maintain human values. 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 23. Accept no outside work detrimental to the work they perform for their primary employer. 24. Providing adequate testing. Mainte nance 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. Not knowingly use software that is obtained or retained either illegally or unethically. 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. 79

93 5. Disclose to all concerned parties those conflicts of interest that cannot reasonably be avoided or escaped. 6. Ensure that specifications for software on which they work have been well documented, satisfy the users requirements and have the appropriate approvals. 7. Be careful to use only accurate data derived by ethical and lawful means, and use it only in ways properly authorized. 8. Be fair and avoid deception in all statements, particularly public ones, concerning software or related documents, methods and tools. 9. Identify, define and address ethical, economic, cultural, legal and environmental issues related to work projects. 10. Fully understand the specifications for software on which they work. 11. Ensure adequate documentation, including significant problems discovered and solutions adopted, for any project on which they work. 12. Cooperate with effort to address matters of grave public concern caused by software, its installation, maintenance, support or documentation. 13. Accept no outside work detrimental to the work they perform for their primary employer. 14. Maintain professional objectivity with respect to any software or related documents they are asked to evaluate. 15. Treat all forms of software maintenance as new development with the same professionalism. 16. Be encouraged to volunteer professional skills to good causes and contribute to public education concerning the discipline. 17. Temper all technical judgments by the need to support and maintain human values. 18. 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. 19. Creating issues that were not part of the main release 20. Not engage in deceptive financial practices such as bribery, double billing, or other improper financial practices. 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 80

94 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 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 81

95 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) Time 104 man-days to deliver this project. 93 days to deliver this project. 95 man-days to develop 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 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 days to deliver this 82

96 project. project. 4.6 Summary The research met all of its objectives, as shown in Table 4.21, along with the results. Table Research objectives and Results 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 as a high risk. To propose a 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 development life cycle. Results 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 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. 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 83

97 can be designed to enhance the quality of software development as a result of this study. 84

98 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 85

99 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 86

100 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. 87

101 REFERENCES Abdawi, A. (2014) Systematic Review. ACM/IEEE-CS Joint Task Force (2014), Software engineering code of ethics and professional practice, available at: (accessed 29 July 2014). ACM/IEEE-CS Joint Task Force (2014), ACM and IEEE-CS Cooperative Activities, available at: (accessed 31 December 2015). Agarwal, S., & Garcia, M. (2006, July). What to Teach About Computer Ethics. In Information Technology Based Higher Education and Training, ITHET'06. 7th International Conference on (pp ). 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), 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, 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 Baxter, P., & Jack, S. (2008). Qualitative case study methodology: Study design and implementation for novice researchers. The qualitative report, 13(4), Berenbach, B., & Broy, M. (2009). Professional and ethical dilemmas in software engineering. Computer,

102 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), Dodig-Crnkovic, G., & Feldt, R. (2009). Professional and Ethical Issues of Software Engineering Curricula 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 th 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), Gable, G. G. (1994). Integrating case study and survey research methods: an example in information systems. European journal of information systems, 3(2), 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, Proceedings. International Conference (pp ). IEEE. 89

103 Gotterbarn, D., & Miller, K. W. (2009). The public is the priority: Making decisions using the software engineering code of ethics. Computer, (6), 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 Gotterbarn, D., Miller, K., & Rogerson, S. (1999). Computer society and ACM approve software engineering code of ethics. Computer, 32(10), 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), 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), Landers, J.(2014) The Purpose of a Professional Code of Ethics[Online]Available at: 90

104 Lethbridge, T. C., Sim, S. E., & Singer, J. (2005). Studying software engineers: Data collection techniques for software field studies. Empirical software engineering, 10(3), Lurie, Y., & Mark, S. (2015). Professional Ethics of Software Engineers: An Ethical Framework. Science and engineering ethics, Maner, W. (1996). Unique ethical problems in information technology. Science and Engineering Ethics, 2(2), 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 Mills, H. D. (1999). The management of software engineering, Part I: Principles of software engineering. IBM Systems Journal, 38(2.3), Moor, J. H. (1985). What is computer ethics? Metaphilosophy, 16(4), 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: 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 ). 91

105 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), 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: 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: ACM/IEEE-CS retrieved 21st February, 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, 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 ). IEEE. Thomson, A. J., & Schmoldt, D. L. (2001). Ethics in computer software design and development. Computers and Electronics in Agriculture, 30(1), Vallor, S. An Introduction to Software Engineering Ethics. Retrieved from df 92

106 Veatch, R.M., 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), Wiegers, K., & Beatty, J. (2013). Software requirements. Pearson Education. Williams, L. (2006). Testing overview and black-box testing techniques. URL: 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, Yin, R. K. (2003). Case study research design and methods third edition. Applied social research methods series, 5. 93

107 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 94

108 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: Accept full responsibility for their own work Moderate the interests of the software engineer, the employer, the client and the users with the public good 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 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. 95

109 1.05. Cooperate in efforts to address matters of grave public concern caused by software, its installation, maintenance, support or documentation Be fair and avoid deception in all statements, particularly public ones, concerning software or related documents, methods and tools Consider issues of physical disabilities, allocation of resources, economic disadvantage and other factors that can diminish access to the benefits of software Be encouraged to volunteer professional skills to good causes and contribute to public education concerning the discipline. 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: Provide service in their areas of competence, being honest and forthright about any limitations of their experience and education Not knowingly use software that is obtained or retained either illegally or unethically Use the property of a client or employer only in ways properly authorized, and with the client's or employer's knowledge and consent Ensure that any document upon which they rely has been approved, when required, by someone authorized to approve it Keep private any confidential information gained in their professional work, where such confidentiality is consistent with the public interest and consistent with the law 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 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 Accept no outside work detrimental to the work they perform for their primary employer. 96

110 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: 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 Ensure proper and achievable goals and objectives for any project on which they work or propose Identify, define and address ethical, economic, cultural, legal and environmental issues related to work projects 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 Ensure an appropriate method is used for any project on which they work or propose to work 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 Strive to fully understand the specifications for software on which they work Ensure that specifications for software on which they work have been well documented, satisfy the users requirements and have the appropriate approvals 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 Ensure adequate testing, debugging, and review of software and related documents on which they work. 97

111 3.11. Ensure adequate documentation, including significant problems discovered and solutions adopted, for any project on which they work Work to develop software and related documents that respect the privacy of those who will be affected by that software Be careful to use only accurate data derived by ethical and lawful means, and use it only in ways properly authorized Maintain the integrity of data, being sensitive to outdated or flawed occurrences 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: Temper all technical judgments by the need to support and maintain human values Only endorse documents either prepared under their supervision or within their areas of competence and with which they are in agreement Maintain professional objectivity with respect to any software or related documents they are asked to evaluate Not engage in deceptive financial practices such as bribery, double billing, or other improper financial practices Disclose to all concerned parties those conflicts of interest that cannot reasonably be avoided or escaped 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: 98

112 5.01 Ensure good management for any project on which they work, including effective procedures for promotion of quality and reduction of risk Ensure that software engineers are informed of standards before being held to them 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 Assign work only after taking into account appropriate contributions of education and experience tempered with a desire to further that education and experience 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 Attract potential software engineers only by full and accurate description of the conditions of employment Offer fair and just remuneration Not unjustly prevent someone from taking a position for which that person is suitably qualified 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 Provide for due process in hearing charges of violation of an employer's policy or of this Code Not ask a software engineer to do anything inconsistent with this Code 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: Help develop an organizational environment favorable to acting ethically. 99

113 6.02. Promote public knowledge of software engineering Extend software engineering knowledge by appropriate participation in professional organizations, meetings and publications Support, as members of a profession, other software engineers striving to follow this Code Not promote their own interest at the expense of the profession, client or employer Obey all laws governing their work, unless, in exceptional circumstances, such compliance is inconsistent with the public interest 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 Take responsibility for detecting, correcting, and reporting errors in software and associated documents on which they work 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 Avoid associations with businesses and organizations which are in conflict with this code Recognize that violations of this Code are inconsistent with being a professional software engineer Express concerns to the people involved when significant violations of this Code are detected unless this is impossible, counter-productive, or dangerous 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: 100

114 7.01. Encourage colleagues to adhere to this Code Assist colleagues in professional development Credit fully the work of others and refrain from taking undue credit Review the work of others in an objective, candid, and properly-documented way Give a fair hearing to the opinions, concerns, or complaints of a colleague 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 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 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: 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 Improve their ability to create safe, reliable, and useful quality software at reasonable cost and within a reasonable time Improve their ability to produce accurate, informative, and well-written documentation Improve their understanding of the software and related documents on which they work and of the environment in which they will be used Improve their knowledge of relevant standards and the law governing the software and related documents on which they work. 101

115 8.06 Improve their knowledge of this Code, its interpretation, and its application to their work Not give unfair treatment to anyone because of any irrelevant prejudices Not influence others to undertake any action that involves a breach of this Code Recognize that personal violations of this Code are inconsistent with being a professional software engineer. (ACM/IEEE-CS Joint Task Force, 2014). 102

116 APPENDIX B - Permission and Approval Letter 103

117 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: 104

118 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? 105

119 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) 1- PUBLIC - Software engineers shall act consistently with the public interest. In particular, software engineers shall, as appropriate: Challeng e (1-7) 106

120 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 wellfounded 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 concerning the discipline. 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 Keep private any confidential information gained in their professional work, where such confidentiality is consistent with the public interest and consistent with the law 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 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 Accept no outside work detrimental to the work 107

121 they perform for their primary employer 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 Ensure that specifications for software on which they work have been well documented, satisfy the users requirements and have the appropriate approvals 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 Ensure adequate testing, debugging, and review of software and related documents on which they work Ensure adequate documentation, including significant problems discovered and solutions adopted, for any project on which they work Work to develop software and related documents that respect the privacy of those who will be affected by that software Be careful to use only accurate data derived by ethical and lawful means, and use it only in ways properly authorized Maintain the integrity of data, being sensitive to outdated or flawed occurrences Treat all forms of software maintenance with the same professionalism as new development. 108

122 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 109

123 APPENDIX E - Questionnaire Results and Analysis 110

124 Years of experience Weight Count 24/2 = and more Total Principle 1 Results After the weight Requirement Design Code Test Maintenance Challenge Risk 1.1 Accept full responsibility for their own work 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 wellfounded belief that it is safe, meets specifications, passes appropriate tests, and does not diminish

ΗΜΥ 317 Τεχνολογία Υπολογισμού

ΗΜΥ 317 Τεχνολογία Υπολογισμού ΗΜΥ 317 Τεχνολογία Υπολογισμού Εαρινό Εξάμηνο 2008 ΙΑΛΕΞΗ 13: Κανόνες Ηθικής ΧΑΡΗΣ ΘΕΟΧΑΡΙ ΗΣ Λέκτορας ΗΜΜΥ (ttheocharides@ucy.ac.cy) [Προσαρμογή από Ian Sommerville, Software Engineering, 8 th Edition]

More information

IF2261 Software Engineering. Introduction. What is software? What is software? What is software? Failure Curve. Software Applications Type

IF2261 Software Engineering. Introduction. What is software? What is software? What is software? Failure Curve. Software Applications Type IF2261 Software Engineering Introduction Program Studi Teknik Informatika STEI ITB What is software? Definitions: Computer programs, procedures, and possibly associated documentation and data pertaining

More information

Introduction. Getting started with software engineering. Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 1

Introduction. Getting started with software engineering. Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 1 Introduction Getting started with software engineering Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 1 Objectives To introduce software engineering and to explain its importance

More information

An Introduction to Software Engineering

An Introduction to Software Engineering An Introduction to Software Engineering Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 1 Objectives To introduce software engineering and to explain its importance To set out the

More information

An Introduction to Software Engineering. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 1

An Introduction to Software Engineering. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 1 An Introduction to Software Engineering Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 1 Objectives To introduce software engineering and to explain its importance To set out the

More information

Software Engineering. What is SE, Anyway? Based on Software Engineering, 7 th Edition by Ian Sommerville

Software Engineering. What is SE, Anyway? Based on Software Engineering, 7 th Edition by Ian Sommerville Software Engineering What is SE, Anyway? Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To introduce software engineering and to explain its importance To set out the answers

More information

An Introduction to Software Engineering

An Introduction to Software Engineering An Introduction to Software Engineering ACSC 383 Software Engineering Efthyvoulos C. Kyriacou (PhD) Assoc. Prof. Computer Science and Engineering Department Resources : Ian Sommervile Software engineering,

More information

Your continued feedback on this newsletter is most welcome. Please send your comments and suggestions to info@swqual.com.

Your continued feedback on this newsletter is most welcome. Please send your comments and suggestions to info@swqual.com. An e-newsletter published by Software Quality Consulting, Inc. February 2009, Vol. 6 No. 2 [Text-only Version] Welcome to Food for Thought, an e-newsletter from Software Quality Consulting. I've created

More information

Factors Influencing the Adoption of Biometric Authentication in Mobile Government Security

Factors Influencing the Adoption of Biometric Authentication in Mobile Government Security Factors Influencing the Adoption of Biometric Authentication in Mobile Government Security Thamer Omar Alhussain Bachelor of Computing, Master of ICT School of Information and Communication Technology

More information

HIM 2008. Master s Degree. Standards and Interpretations for Accreditation of Master s Degree Programs in Health Information Management

HIM 2008. Master s Degree. Standards and Interpretations for Accreditation of Master s Degree Programs in Health Information Management HIM 2008 Master s Degree Standards and Interpretations for Accreditation of Master s Degree Programs in Health Information Management Who We Are The Commission on Accreditation for Health Informatics and

More information

National Commission for Academic Accreditation & Assessment. Handbook for Quality Assurance and Accreditation in Saudi Arabia PART 1

National Commission for Academic Accreditation & Assessment. Handbook for Quality Assurance and Accreditation in Saudi Arabia PART 1 National Commission for Academic Accreditation & Assessment Handbook for Quality Assurance and Accreditation in Saudi Arabia PART 1 THE SYSTEM FOR QUALITY ASSURANCE AND ACCREDITATION Ver. 2.0 THE SYSTEM

More information

National Commission for Academic Accreditation & Assessment. Standards for Quality Assurance and Accreditation of Higher Education Programs

National Commission for Academic Accreditation & Assessment. Standards for Quality Assurance and Accreditation of Higher Education Programs National Commission for Academic Accreditation & Assessment Standards for Quality Assurance and Accreditation of Higher Education Programs November 2009 Standards for Quality Assurance and Accreditation

More information

Introduction to Software Engineering

Introduction to Software Engineering What is Software Engineering Introduction to Software Engineering Prof. Lyle N. Long lnl@psu.edu http://www.personal.psu.edu/lnl Sources of Material What is software? Software Engineering, 7 th Edition,

More information

Software Engineering Ethics and Professional Conduct SWENET OSE3 Module July 2003

Software Engineering Ethics and Professional Conduct SWENET OSE3 Module July 2003 Software Engineering Ethics and Professional Conduct SWENET OSE3 Module July 2003 Developed with support from the National Science Foundation OSE3-1 Overview Ethics and Professional Conduct Software Engineering

More information

Family Educational Rights and Privacy Act: Initial Act was 1974 Amended 9 times As first enacted, FERPA provided parents with the right to inspect

Family Educational Rights and Privacy Act: Initial Act was 1974 Amended 9 times As first enacted, FERPA provided parents with the right to inspect Family Educational Rights and Privacy Act: Initial Act was 1974 Amended 9 times As first enacted, FERPA provided parents with the right to inspect and review "any and all official records, files, and data

More information

AACSB Assurance of Learning Standards: An Interpretation AACSB White Paper No. 3 issued by:

AACSB Assurance of Learning Standards: An Interpretation AACSB White Paper No. 3 issued by: AACSB Assurance of Learning Standards: An Interpretation AACSB White Paper No. 3 issued by: AACSB International Accreditation Coordinating Committee AACSB International Accreditation Quality Committee

More information

Initial Professional Development - Professional Values, Ethics, and Attitudes (Revised)

Initial Professional Development - Professional Values, Ethics, and Attitudes (Revised) IFAC Board Exposure Draft July 2012 Comments due: October 11, 2012 Proposed International Education Standard (IES) 4 Initial Professional Development - Professional Values, Ethics, and Attitudes (Revised)

More information

Lecture 2. Anis Koubaa

Lecture 2. Anis Koubaa Chapter 1- Introduction Lecture 2 Anis Koubaa Slides from textbook Software Engineering, Ninth Edition by Sommerville (c) Pearson Education 1 - Addison-Wesley, 2011 22-Jun-12 Software engineering ethics

More information

Case Report from Audit Firm Inspection Results

Case Report from Audit Firm Inspection Results Case Report from Audit Firm Inspection Results August 2012 Certified Public Accountants and Auditing Oversight Board Table of Contents Introduction 1 Quality Control System 1. Management Systems 3 2. Professional

More information

Professional Development for Engagement Partners Responsible for Audits of Financial Statements (Revised)

Professional Development for Engagement Partners Responsible for Audits of Financial Statements (Revised) IFAC Board Exposure Draft August 2012 Comments due: December 11, 2012 Proposed International Education Standard (IES) 8 Professional Development for Engagement Partners Responsible for Audits of Financial

More information

A DEFINITION OF THE PUBLIC INTEREST 1

A DEFINITION OF THE PUBLIC INTEREST 1 IFAC POLICY POSITION 5 June 2012 A DEFINITION OF THE PUBLIC INTEREST 1 IFAC defines the public interest as the net benefits derived for, and procedural rigor employed on behalf of, all society in relation

More information

Software Engineering Code of Ethics and Professional Practice

Software Engineering Code of Ethics and Professional Practice Page 1 of 9 Certified Software Development Professional Resources Certification Home Is Certification For You? The Certification Process Requirements Preparation and Study Application Exam Sites Continuing

More information

Chapter 1- Introduction. Lecture 1

Chapter 1- Introduction. Lecture 1 Chapter 1- Introduction Lecture 1 Topics covered Professional software development What is meant by software engineering. Software engineering ethics A brief introduction to ethical issues that affect

More information

Instructional Technology Capstone Project Standards and Guidelines

Instructional Technology Capstone Project Standards and Guidelines Instructional Technology Capstone Project Standards and Guidelines The Committee recognizes the fact that each EdD program is likely to articulate some requirements that are unique. What follows are a

More information

COLLEGE OF BUSINESS AND TECHNOLOGY PERFORMANCE EVALUATION GUIDELINES

COLLEGE OF BUSINESS AND TECHNOLOGY PERFORMANCE EVALUATION GUIDELINES COLLEGE OF BUSINESS AND TECHNOLOGY PERFORMANCE EVALUATION GUIDELINES Preamble The College of Business and Technology (CBT) faculty believe that a fair and systematic performance evaluation system is a

More information

IPP Learning Outcomes Report. Faculty member completing template: Greg Kim Ju, Marya Endriga (Date: 1/17/12)

IPP Learning Outcomes Report. Faculty member completing template: Greg Kim Ju, Marya Endriga (Date: 1/17/12) Page 1 IPP Learning Outcomes Report Program: Department: Psychology MA (General) Psychology Number of students enrolled in the program in Fall, 2011: 48 (Appendix A) Faculty member completing template:

More information

Health Informatics 2010. Master s Degree. Standards and Interpretations for Accreditation of Master s Degree Programs in Health Informatics

Health Informatics 2010. Master s Degree. Standards and Interpretations for Accreditation of Master s Degree Programs in Health Informatics Health Informatics 2010 Master s Degree Standards and Interpretations for Accreditation of Master s Degree Programs in Health Informatics Who We Are The Commission on Accreditation for Health Informatics

More information

Professional Competence for Engagement Partners Responsible for Audits of Financial Statements (Revised)

Professional Competence for Engagement Partners Responsible for Audits of Financial Statements (Revised) IFAC Board Exposure Draft December 2013 Comments due: April 17, 2014 Proposed International Education Standard (IES) 8 Professional Competence for Engagement Partners Responsible for Audits of Financial

More information

*Performance Expectations, Elements and Indicators

*Performance Expectations, Elements and Indicators C o m m o n C o r e o f L e a d i n g : Connecticut School Leadership Standards *Performance Expectations, Elements and Indicators *For further information, visit: http://www.sde.ct.gov/sde/cwp/view.asp?a=2641&q=333900

More information

National Commission for Academic Accreditation & Assessment. Standards for Quality Assurance and Accreditation of Higher Education Institutions

National Commission for Academic Accreditation & Assessment. Standards for Quality Assurance and Accreditation of Higher Education Institutions National Commission for Academic Accreditation & Assessment Standards for Quality Assurance and Accreditation of Higher Education Institutions November 2009 Standards for Institutional Accreditation in

More information

THE INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS

THE INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS THE INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS We, the members of the IEEE, in recognition of the importance of our technologies in affecting the quality of life throughout the world, and in accepting

More information

Don Gotterbarn, Keith Miller, and Simon Rogerson

Don Gotterbarn, Keith Miller, and Simon Rogerson Don Gotterbarn, Keith Miller, and Simon Rogerson Software Engineering Code of Ethics is Approved The exhaustive efforts of the ACM and IEEE CS has resulted in the adoption of a code of professional practices

More information

Toronto School of Theology Guidelines for the Preparation and Ethics Review of Doctor of Ministry Thesis Projects Involving Human Subjects

Toronto School of Theology Guidelines for the Preparation and Ethics Review of Doctor of Ministry Thesis Projects Involving Human Subjects Toronto School of Theology Guidelines for the Preparation and Ethics Review of Doctor of Ministry Thesis Projects Involving Human Subjects The Doctor of Ministry Program at the Toronto School of Theology

More information

Chapter 1 Introduction

Chapter 1 Introduction Chapter 1 Introduction Chapter 1 Introduction Slide 1 Topics covered Professional software development What is meant by software engineering. Addendum to Sommerville s FAQs Software engineering ethics

More information

Competencies for Early Childhood Professionals Area VIII: Teacher Qualifications and Professional Development

Competencies for Early Childhood Professionals Area VIII: Teacher Qualifications and Professional Development Competencies for Early Childhood Professionals Area VIII: Teacher Qualifications and Professional Development Rationale: Professional development in early childhood education contributes to continuous

More information

SE 367 Software Engineering Basics of Software Engineering

SE 367 Software Engineering Basics of Software Engineering Slide 1 SE 367 Software Engineering Basics of Software Engineering Slide 2 Introduction Getting started with software engineering Objectives To introduce software engineering and to explain its importance

More information

Digital Industries Apprenticeship: Occupational Brief. Software Tester. March 2016

Digital Industries Apprenticeship: Occupational Brief. Software Tester. March 2016 Digital Industries Apprenticeship: Occupational Brief Software Tester March 2016 1 Digital Industries Apprenticeships: Occupational Brief Level 4 Software Tester Apprenticeship Minimum Standards and Grading

More information

An organizational ethics management program The context of an organization s whistle-blowing program

An organizational ethics management program The context of an organization s whistle-blowing program An organizational ethics management program The context of an organization s whistle-blowing program Willem A Landman CEO, Ethics Institute of South Africa (EthicSA) Extraordinary Professor of Philosophy,

More information

Federal Bureau of Investigation s Integrity and Compliance Program

Federal Bureau of Investigation s Integrity and Compliance Program Evaluation and Inspection Division Federal Bureau of Investigation s Integrity and Compliance Program November 2011 I-2012-001 EXECUTIVE DIGEST In June 2007, the Federal Bureau of Investigation (FBI) established

More information

PROFESSIONALISM AND CODES OF ETHICS

PROFESSIONALISM AND CODES OF ETHICS PROFESSIONALISM AND CODES OF ETHICS OVERVIEW Is your discipline part of a profession? What is the role of a professional organization? What are ethical codes? CONTRASTING DEFINITIONS Job: Something one

More information

AUSTRALIAN CLINICAL PSYCHOLOGY ASSOCIATION CODE OF PROFESSIONAL ETHICS

AUSTRALIAN CLINICAL PSYCHOLOGY ASSOCIATION CODE OF PROFESSIONAL ETHICS AUSTRALIAN CLINICAL PSYCHOLOGY ASSOCIATION CODE OF PROFESSIONAL ETHICS Purpose This Code of Professional Ethics provides principles and guidelines that should be observed by all members of the Australian

More information

PRINCIPLES AND STANDARDS OF ETHICAL SUPPLY MANAGEMENT CONDUCT WITH GUIDELINES

PRINCIPLES AND STANDARDS OF ETHICAL SUPPLY MANAGEMENT CONDUCT WITH GUIDELINES PRINCIPLES AND STANDARDS OF ETHICAL SUPPLY MANAGEMENT CONDUCT WITH GUIDELINES Published by: Institute for Supply Management, Inc. Thomas Derry, Chief Executive Officer 2014 Institute for Supply Management

More information

PHILOSOPHY OF EDUCATION AND TEACHING COURSE OUTLINE

PHILOSOPHY OF EDUCATION AND TEACHING COURSE OUTLINE PHILOSOPHY OF EDUCATION AND TEACHING COURSE OUTLINE Course Description This course is designed for students aspiring to be educators as well as those interested in education as a field of study in and

More information

Narayanan & Vallor 2014.

Narayanan & Vallor 2014. 1 'Without a sense of professional ethics, individuals might justify to themselves conduct that would be much more difficult to justify in front of others.' Narayanan & Vallor 2014. Computer Ethics (English)

More information

Project Portfolio Management (PPM) Services

Project Portfolio Management (PPM) Services Project Portfolio (PPM) Services Research Report 1 Project Portfolio (PPM) Services Research Report Thought Leadership Series: The Case for Workforce Mobility By Andy Jordan, PMP, ProjectsAtWork Research

More information

ETHICAL CONDUCT AND PROFESSIONAL PRACTICE: PRINCIPLES AND STANDARDS FOR MEMBERS OF THE BRITISH COLUMBIA ASSOCIATION OF SCHOOL PSYCHOLOGISTS

ETHICAL CONDUCT AND PROFESSIONAL PRACTICE: PRINCIPLES AND STANDARDS FOR MEMBERS OF THE BRITISH COLUMBIA ASSOCIATION OF SCHOOL PSYCHOLOGISTS ETHICAL CONDUCT AND PROFESSIONAL PRACTICE: PRINCIPLES AND STANDARDS FOR MEMBERS OF THE BRITISH COLUMBIA ASSOCIATION OF SCHOOL PSYCHOLOGISTS March 2010 Preamble Ethical Principles define the ethical responsibility

More information

Social Survey Methods and Data Collection

Social Survey Methods and Data Collection Social Survey Social Survey Methods and Data Collection Zarina Ali June 2007 Concept of Survey & Social Survey A "survey" can be anything from a short paper- and-pencil feedback form to an intensive one-on

More information

NATIONAL AUDIT OFFICE OF MALAWI AUDITING STANDARDS

NATIONAL AUDIT OFFICE OF MALAWI AUDITING STANDARDS NATIONAL AUDIT OFFICE OF MALAWI AUDITING STANDARDS Foreword I am pleased to issue the Malawi National Audit Office Auditing Standards. The Auditing Standards have been developed under the auspices of the

More information

Code of Ethics December 2013

Code of Ethics December 2013 Code of Ethics December 2013 Ethical Principles The following ethical principles form the basis of the Audiology Australia Code of Conduct: Respect the rights, needs, well-being and autonomy of people

More information

Assurance of Learning Assessment Process

Assurance of Learning Assessment Process Assurance of Learning Assessment Process (AACSB Assurance of Learning Standards: An Interpretation, Accessed 12/01/2011, )

More information

INTERNAL AUDIT CHARTER

INTERNAL AUDIT CHARTER INTERNAL AUDIT CHARTER 1000.00 Mission 1000.01 The mission of the Office of Internal Audit is to be an integral part of the governance of the University by providing independent, objective assurance that

More information

Internal Quality Assurance Arrangements

Internal Quality Assurance Arrangements National Commission for Academic Accreditation & Assessment Handbook for Quality Assurance and Accreditation in Saudi Arabia PART 2 Internal Quality Assurance Arrangements Version 2.0 Internal Quality

More information

STATEMENT OF ETHICAL PRACTICE

STATEMENT OF ETHICAL PRACTICE STATEMENT OF ETHICAL PRACTICE Preamble Records and information management (RIM) is the branch of the information professions primarily concerned with the efficient and systematic control of the creation,

More information

The Arab Society for Forensic Sciences and Forensic Medicine (ASFSFM): Bringing together regional and international expertise

The Arab Society for Forensic Sciences and Forensic Medicine (ASFSFM): Bringing together regional and international expertise Arab Journal of Forensic Sciences and Forensic Medicine 2014; Volume 1 Issue (0), 17-21 17 Naif Arab University for Security Sciences Arab Journal of Forensic Sciences and Forensic Medicine www.nauss.edu.sa

More information

Texas State University University Library Strategic Plan 2012 2017

Texas State University University Library Strategic Plan 2012 2017 Texas State University University Library Strategic Plan 2012 2017 Mission The University Library advances the teaching and research mission of the University and supports students, faculty, and other

More information

DESTINATION ATTRACTIVENESS AS A FUNCTION OF SUPPLY AND DEMAND INTERACTION DOCTOR OF PHILOSOPHY

DESTINATION ATTRACTIVENESS AS A FUNCTION OF SUPPLY AND DEMAND INTERACTION DOCTOR OF PHILOSOPHY DESTINATION ATTRACTIVENESS AS A FUNCTION OF SUPPLY AND DEMAND INTERACTION by Sandro Formica Dissertation submitted to the Faculty of the Virginia Polytechnic Institute and State University in partial fulfillment

More information

PASTA Abstract. Process for Attack S imulation & Threat Assessment Abstract. VerSprite, LLC Copyright 2013

PASTA Abstract. Process for Attack S imulation & Threat Assessment Abstract. VerSprite, LLC Copyright 2013 2013 PASTA Abstract Process for Attack S imulation & Threat Assessment Abstract VerSprite, LLC Copyright 2013 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

More information

DEPARTMENT OF MARKETING COLLEGE OF BUSINESS ADMINSTRATION POLICY ON REAPPOINTMENT, TENURE, AND PROMOTION (RTP)

DEPARTMENT OF MARKETING COLLEGE OF BUSINESS ADMINSTRATION POLICY ON REAPPOINTMENT, TENURE, AND PROMOTION (RTP) Approved by Academic Affairs May 2010 DEPARTMENT OF MARKETING COLLEGE OF BUSINESS ADMINSTRATION POLICY ON REAPPOINTMENT, TENURE, AND PROMOTION (RTP) I. DEPARTMENT OF MARKETING RTP POLICY A. Preamble B.

More information

PUBLIC ACCOUNTANTS COUNCIL HANDBOOK

PUBLIC ACCOUNTANTS COUNCIL HANDBOOK PUBLIC ACCOUNTANTS COUNCIL HANDBOOK Adopted by the Public Accountants Council for the Province of Ontario: April 17, 2006 PART I: PROFESSIONAL COMPETENCY REQUIREMENTS FOR PUBLIC ACCOUNTING PART II: PRACTICAL

More information

Proposed Code of Ethical Principles for Professional Valuers

Proposed Code of Ethical Principles for Professional Valuers INTERNATIONAL VALUATION STANDARDS COUNCIL Second Exposure Draft Proposed Code of Ethical Principles for Professional Valuers Comments to be received by 31 August 2011 Copyright 2011 International Valuation

More information

GENERATION SAFE 360 SELF ASSESSMENT: PRINTABLE VERSION. Page 1

GENERATION SAFE 360 SELF ASSESSMENT: PRINTABLE VERSION. Page 1 Page 1 Contents 1. Introduction 2. How to use the 360 Self Assessment 3. Links to documents and resources 4. Acknowledgements 5. 360 Self Assessment 6. Report Sheet Introduction The development and expansion

More information

Copyright 2004.Pamela Cole. All rights reserved.

Copyright 2004.Pamela Cole. All rights reserved. Key concepts for working with the Role Behavior Analysis The Role Behavior Analysis (RBA), the companion instrument to the Personal Profile System (PPS), uses specific DiSC behavioral statements for defining,

More information

THE TEN-STEP METHOD OF DECISIONMAKING

THE TEN-STEP METHOD OF DECISIONMAKING Page 1 of 13 THE TEN-STEP METHOD OF DECISIONMAKING BACKGROUND Developed by Jon Pekel and Doug Wallace, the Ten Step Method of Decisionmaking has five features that make it practically useful in today's

More information

Chapter 1- Introduction. Lecture 1

Chapter 1- Introduction. Lecture 1 Chapter 1- Introduction Lecture 1 Topics covered Professional software development What is meant by software engineering. Software engineering ethics A brief introduction to ethical issues that affect

More information

MENTOR HANDBOOK MLS Online Programs Weber State University

MENTOR HANDBOOK MLS Online Programs Weber State University MENTOR HANDBOOK MLS Online Programs Weber State University Mentoring is the art of helping and empowering others to shape their learning behaviours. The concept of mentoring has a long history, one that

More information

Ethics Self Assessment. How to use the self assessment

Ethics Self Assessment. How to use the self assessment Ethics Self Assessment How to use the self assessment Members and credentialed nonmembers of the American Health Information Management Association agree, as a condition of membership and certification,

More information

Council on Social Work Education. Curriculum Policy Statement for Baccalaureate Degree Programs in Social Work Education

Council on Social Work Education. Curriculum Policy Statement for Baccalaureate Degree Programs in Social Work Education Council on Social Work Education Curriculum Policy Statement for Baccalaureate Degree Programs in Social Work Education B1.0 SCOPE AND INTENT OF THE CURRICULUM POLICY STATEMENT B1.1 This document sets

More information

Doctorate of Philosophy (PhD) Regulations School of Education (Proposed)

Doctorate of Philosophy (PhD) Regulations School of Education (Proposed) Doctorate of Philosophy (PhD) Regulations School of Education (Proposed) 1. Preliminary The Doctorate of Philosophy (PhD) under the School of Education Program Regulations (herein after called the PhD

More information

ISLAMIC AFFAIRS & CHARTABLE ACTIVITIES DEPARTMENT GOVERNMENT OF DUBAI

ISLAMIC AFFAIRS & CHARTABLE ACTIVITIES DEPARTMENT GOVERNMENT OF DUBAI ISLAMIC AFFAIRS & CHARTABLE ACTIVITIES DEPARTMENT GOVERNMENT OF DUBAI Rules for Licenses of Religious and Charitable Societies and Organization Of their Activities in the Emirate of Dubai IN THE NAME OF

More information

Introduction. Getting started with software engineering. Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 1

Introduction. Getting started with software engineering. Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 1 Introduction Getting started with software engineering Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 1 Why? the Therac-25 Failure 1985-1987 Therac-25 Radiation Treatment Machine

More information

SCA 114 -Standard on Cost Auditing Using the Work of Cost Auditor s Expert

SCA 114 -Standard on Cost Auditing Using the Work of Cost Auditor s Expert Name of Clause SCA 114 -Standard on Cost Auditing Using the Work of Cost Auditor s Expert Contents Cost Auditing and Assurance Standards Board Paragraph Number Introduction 1 Objective 2 Scope 3 Definitions

More information

DESCRIPTOR OF THE STUDY FIELD OF ACOUNTING CHAPTER I GENERAL PROVISIONS

DESCRIPTOR OF THE STUDY FIELD OF ACOUNTING CHAPTER I GENERAL PROVISIONS DESCRIPTOR OF THE STUDY FIELD OF ACOUNTING CHAPTER I GENERAL PROVISIONS 1. The Descriptor of the study field of Accounting (hereinafter referred to as the Descriptor ) shall govern the special requirements

More information

The Goals Grid: A Tool for Clarifying Goals and Objectives

The Goals Grid: A Tool for Clarifying Goals and Objectives The Goals Grid: A Tool for Clarifying Goals and Objectives Fred Nickols 2010 This article originally appeared in Performance & Instruction in 1992 bearing the unwieldy title of "Objectives, Systems, Patterns,

More information

OT AUSTRALIA. Australian Association of Occupational Therapists. Code of Ethics

OT AUSTRALIA. Australian Association of Occupational Therapists. Code of Ethics Introductory Statement The ethos of the occupational therapy profession and its practice requires its members to discharge their duties and responsibilities, at all times, in a manner which professionally,

More information

About Early Education

About Early Education Code of Ethics About Early Education Early Education is the leading independent national charity supporting families and the professional development of practitioners working in the maintained, private,

More information

Internal Audit Report Assessment of the Design of the Office of the Auditor General s Quality Management System

Internal Audit Report Assessment of the Design of the Office of the Auditor General s Quality Management System Internal Audit Report Assessment of the Design of the Office of the Auditor General s Quality Management System Office of the Auditor General of Canada Bureau du vérificateur général du Canada 16 October

More information

Criteria for the Accreditation of. MBM Programmes

Criteria for the Accreditation of. MBM Programmes Criteria for the Accreditation of MBM Programmes 1 2 1 INTRODUCTION Framework & Eligibility 1.1 This document sets out the criteria for MBM (Masters in Business & Management) programme accreditation. While

More information

Continuing Professional Education Provided By. Leo R. Moretti, CPA, CGMA lmoretti@yksmcpa.com 401-654-5055

Continuing Professional Education Provided By. Leo R. Moretti, CPA, CGMA lmoretti@yksmcpa.com 401-654-5055 Continuing Professional Education Provided By Leo R. Moretti, CPA, CGMA lmoretti@yksmcpa.com 401-654-5055 Ethics General Session Updated January 2013 LEO R. MORETTI, CPA, CGMA lmoretti@yksmcpa.com 401-654-5055

More information

The British Academy of Management. Website and Social Media Policy

The British Academy of Management. Website and Social Media Policy The British Academy of Management s Website and Social Media Policy The creation of management knowledge through research and its dissemination through teaching and application The British Academy of Management

More information

Legal and Ethical Aspects. IT 4823 Information Security Administration. Cybercrime / Computer Crime. Law Enforcement Challenges.

Legal and Ethical Aspects. IT 4823 Information Security Administration. Cybercrime / Computer Crime. Law Enforcement Challenges. IT 4823 Information Security Administration Legal and Ethical Considerations March 24 Legal and Ethical Aspects Topics include: cybercrime and computer crime intellectual property issues privacy ethical

More information

BS Computer Science (2013 2014)

BS Computer Science (2013 2014) BS Computer Science (2013 2014) Program Information Point of Contact Venkat Gudivada (gudivada@marshall.edu) Support for University and College Missions Marshall University is a multi campus public university

More information

Crosswalk of the New Colorado Principal Standards (proposed by State Council on Educator Effectiveness) with the

Crosswalk of the New Colorado Principal Standards (proposed by State Council on Educator Effectiveness) with the Crosswalk of the New Colorado Principal Standards (proposed by State Council on Educator Effectiveness) with the Equivalent in the Performance Based Principal Licensure Standards (current principal standards)

More information

Professional Portfolio Guide

Professional Portfolio Guide Quality Assurance Competency Enhancement Professional Portfolio Guide Engaging in Competency Enhancement www.coptont.org Protecting the Public TABLE OF CONTENTS QA COMPETENCY ENHANCEMENT OVERVIEW... 1

More information

Data quality and metadata

Data quality and metadata Chapter IX. Data quality and metadata This draft is based on the text adopted by the UN Statistical Commission for purposes of international recommendations for industrial and distributive trade statistics.

More information

GUIDELINES FOR RESPONSIBLE USE OF IDENTITY MANAGEMENT SYSTEMS

GUIDELINES FOR RESPONSIBLE USE OF IDENTITY MANAGEMENT SYSTEMS GUIDELINES FOR RESPONSIBLE USE OF IDENTITY MANAGEMENT SYSTEMS When used appropriately, identity management systems provide safety and security where they are needed. When used improperly, identity management

More information

QUALITY ASSURANCE POLICY

QUALITY ASSURANCE POLICY QUALITY ASSURANCE POLICY ACADEMIC DEVELOPMENT & QUALITY ASSURANCE OFFICE ALPHA UNIVERSITY COLLEGE 1. BACKGROUND The Strategic Plan of 2003-2005 E.C of Alpha University s defines the direction Alpha University

More information

BARLOWORLD GROUP ETHICS AND COMPLIANCE FRAMEWORK

BARLOWORLD GROUP ETHICS AND COMPLIANCE FRAMEWORK BARLOWORLD GROUP ETHICS AND COMPLIANCE FRAMEWORK APPROVAL AND OWNERSHIP Owner Title Date Hilary Wilton Group Ethics and Compliance Champion Approved By Title Date Group Risk and Sustainability Committee

More information

Corporate Reputation Management. and Stakeholder Engagement: A Case Study of Five Top. Australian Companies

Corporate Reputation Management. and Stakeholder Engagement: A Case Study of Five Top. Australian Companies Corporate Reputation Management and Stakeholder Engagement: A Case Study of Five Top Australian Companies A thesis submitted in fulfilment of the requirements for the degree of Doctor of Philosophy in

More information

Methods Commission CLUB DE LA SECURITE DE L INFORMATION FRANÇAIS. 30, rue Pierre Semard, 75009 PARIS

Methods Commission CLUB DE LA SECURITE DE L INFORMATION FRANÇAIS. 30, rue Pierre Semard, 75009 PARIS MEHARI 2007 Overview Methods Commission Mehari is a trademark registered by the Clusif CLUB DE LA SECURITE DE L INFORMATION FRANÇAIS 30, rue Pierre Semard, 75009 PARIS Tél.: +33 153 25 08 80 - Fax: +33

More information

Master List, Student Competencies (Learning Outcomes), Goal Areas 1-10 and WSU Intensive Courses/Additional Graduation Requirements

Master List, Student Competencies (Learning Outcomes), Goal Areas 1-10 and WSU Intensive Courses/Additional Graduation Requirements Master List, Student Competencies (Learning Outcomes), Goal Areas 1-10 and WSU Intensive Courses/Additional Graduation Requirements (compiled from current WSU undergraduate catalog at http://catalog.winona.edu/preview_program.php?catoid=7&poid=884)

More information

Naif Arab University for Security Sciences (NAUSS): Pursuing excellence in security science education and research

Naif Arab University for Security Sciences (NAUSS): Pursuing excellence in security science education and research Arab Journal of Forensic Sciences and Forensic Medicine 2014; Volume 1 Issue (0), 5-11 5 Naif Arab University for Security Sciences Arab Journal of Forensic Sciences and Forensic Medicine www.nauss.edu.sa

More information

Approaches to Developing and Maintaining Professional Values, Ethics, and Attitudes

Approaches to Developing and Maintaining Professional Values, Ethics, and Attitudes International Accounting Education Standards Board IEPS 1 October 2007 International Education Practice Statement 1 Approaches to Developing and Maintaining Professional Values, Ethics, and Attitudes International

More information

[PROJECT PROPOSAL EVALUATION MANUAL]

[PROJECT PROPOSAL EVALUATION MANUAL] CROATIAN SCIENCE FOUNDATION [PROJECT PROPOSAL EVALUATION MANUAL] The Board of the Croatian Science Foundation determined the content of the Project proposal evaluation manual at its 8th session held on

More information

National Occupational Standards. National Occupational Standards for Youth Work

National Occupational Standards. National Occupational Standards for Youth Work National Occupational Standards National Occupational Standards for Youth Work Contents Introduction 5 Section 1 S1.1.1 Enable young people to use their learning to enhance their future development 6 S1.1.2

More information

STANDARDS FOR PROFESSIONAL PRACTICE FOR MEMBERS OF THE BRITISH COLUMBIA ASSOCIATION OF SCHOOL PSYCHOLOGISTS PREFACE

STANDARDS FOR PROFESSIONAL PRACTICE FOR MEMBERS OF THE BRITISH COLUMBIA ASSOCIATION OF SCHOOL PSYCHOLOGISTS PREFACE STANDARDS FOR PROFESSIONAL PRACTICE FOR MEMBERS OF THE BRITISH COLUMBIA ASSOCIATION OF SCHOOL PSYCHOLOGISTS PREFACE The Standards for Professional Practice for Members of the British Columbia Association

More information

Hazard Identification, Risk Assessment and Control Procedure

Hazard Identification, Risk Assessment and Control Procedure Hazard Identification, Risk Assessment and Control Procedure 1. Purpose To ensure that there is a formal process for hazard identification, risk assessment and control to effectively manage workplace and

More information

By: Meera AlShaikh 100074

By: Meera AlShaikh 100074 Masters in Project Management Perceptions of the Influence of Project Portfolio Management on Individual Projects المنفرده المشاريع على المشاريع محفظة إدارة تأثير مدى حول التصورات By: Meera AlShaikh 100074

More information

National Standards. Council for Standards in Human Service Education. http://www.cshse.org 2013 (2010, 1980, 2005, 2009)

National Standards. Council for Standards in Human Service Education. http://www.cshse.org 2013 (2010, 1980, 2005, 2009) Council for Standards in Human Service Education National Standards ASSOCIATE DEGREE IN HUMAN SERVICES http://www.cshse.org 2013 (2010, 1980, 2005, 2009) I. GENERAL PROGRAM CHARACTERISTICS A. Institutional

More information

Doing the right thing the PwC way

Doing the right thing the PwC way www.pwc.com/ethics Doing the right thing the PwC way Code of conduct Acting professionally. Doing business with integrity. Upholding our clients reputations as well as our own. Treating people and the

More information

DEPARTMENT OF MANAGEMENT/HRM POLICY ON REAPPOINTMENT, TENURE, AND PROMOTION (RTP) BASED ON COLLEGE OF BUSINESS ADMINISTRATION POLICY ON RTP

DEPARTMENT OF MANAGEMENT/HRM POLICY ON REAPPOINTMENT, TENURE, AND PROMOTION (RTP) BASED ON COLLEGE OF BUSINESS ADMINISTRATION POLICY ON RTP Approved by Academic Affairs May 2010 DEPARTMENT OF MANAGEMENT/HRM POLICY ON REAPPOINTMENT, TENURE, AND PROMOTION (RTP) BASED ON COLLEGE OF BUSINESS ADMINISTRATION POLICY ON RTP TABLE OF CONTENTS I. COLLEGE

More information