Software Engineering Ethics

advertisement

USC

C S E

University of Southern California

Center for Software Engineering

Software Engineering Ethics

Barry Boehm

Fall 2015

Presented by Jim Alstad

© USC-CSSE 2015/12/02 1

USC

C S E

University of Southern California

Center for Software Engineering

Outline

• Definitions and context

– Power to do public harm or good

– ACM/IEEE Software Engineering Code of Ethics

• Principles and examples

– Rawls ’ Theory of Justice

– Relation to stakeholder win-win

– Case study: Mercy Hospital

• Integrating ethics into daily software engineering practices

– VBSE/MBASE/Win Win Spiral Model

© USC-CSSE 2015/12/02 2

USC

C S E

University of Southern California

Center for Software Engineering

Definition of “ Ethics ”

-Webster, 1993

The discipline dealing with what is good and bad

– And with moral duty and obligation

A theory, system, or set of moral principles or values

The principles of conduct governing an individual or group

– Professional ethics

© USC-CSSE 2015/12/02 3

USC

C S E

University of Southern California

Center for Software Engineering

Context

• Software engineers have increasing power to do public harm or good

– Intellectual property, privacy, confidentiality, quality of work, fairness, liability, risk disclosure, conflict of interest, unauthorized access

• Professional societies have developed codes of ethics

• Hard to integrate value-based ethics into valueneutral software engineering practices

• VBSE/MBASE/Win Win Spiral enable ethics integration

© USC-CSSE 2015/12/02 4

USC

C S E

University of Southern California

Center for Software Engineering

Power to Do Public Harm or Good – I

• Intellectual Property: use without credit; use copyrighted material

• Privacy: credit, health, personal information

• Confidentiality: competitive information, political sensitivity

• Quality of work: many dimensions; see table

© USC-CSSE 2015/12/02 5

USC

C S E

University of Southern California

Center for Software Engineering

Example: Confidentiality

• Government agency hires company to support SW procurement

– Provides data under nondisclosure agreement

• Employee and company consultant prepare cost estimate

– Employee: “ I don ’ t see how anyone can do all this for $8M ”

• Consultant provides $8M target cost to some bidders

• Government agency angry with company for leak

– Whose fault? How could it be avoided?

© USC-CSSE 2015/12/02 6

USC

C S E

University of Southern California

Center for Software Engineering

Quality Concerns Vary by Stakeholders Role

**Critical

*Significant

0 Insignificant or indirect

Stakeholder

Classes

*

**

**

** **

*

Information

Consumers

Mission critical

**

** uncrit.

**

**

Protection

Safety

Security

Privacy

Robustness

Reliability

Availability

Survivability

Quality of Service

Performance

Accuracy, Consistency

Accessibility, ease of use; difficulty of misuse

Evolvability

Interoperability

Correctness

Cost

Schedule

Reusability

2015/12/02

**

*

**

**

**

**

**

**

**

**

**

**

**

**

**

**

**

**

*

© USC-CSSE

*

*

**

*

**

**

**

**

**

**

*

*

*

*

**

**

*

**

**

*

*

*

*

*

**

*

*

**

**

**

**

**

*

7

USC

C S E

University of Southern California

Center for Software Engineering

Power to Do Public Harm or Good - II

• Fairness: equality of opportunity/treatment; fair reward system

• Liability: accountability; parity of authority and responsibility

• Risk Disclosure: safety tests, COTS capabilities; schedule slips

• Conflict of Interest: source selection; personnel or product reviews

• Unauthorized Access: reading, copying, modifying; denial of service

© USC-CSSE 2015/12/02 8

USC

C S E

University of Southern California

Center for Software Engineering

Examples: Fairness

• Enron software to schedule power outages, raise prices

– Suppose you had been asked to develop it?

• Urban fire dispatching system

– Inefficient old system caused $700M property loss

– New-system spec. includes dispatching algorithm to minimize property loss

• Any fairness issues?

© USC-CSSE 2015/12/02 9

USC

C S E

University of Southern California

Center for Software Engineering

Example: Safety Tests

• Your company is delivering a drug prescription fulfillment system

– Reusing software from a warehouse inventory system

• You are the quality assurance manager

– With company responsibility for certifying product safety

• The software has passed all the contracted tests

– But many off-nominal conditions untested

– Some have shown unsafe outcomes

– You feel more off-nominal testing is necessary

• Company president says if you don ’ t certify safety by delivery date, company may go out of business

– What should you do?

© USC-CSSE 2015/12/02 10

USC

C S E

University of Southern California

Center for Software Engineering

ACM/IEEE Software Engineering Code of Ethics

-Table of Contents

1. Products: achievable goals, realistic estimates, high quality

2. Public: safety, respect of diversity, public interest first

3. Judgment: objectivity, no bribes or conflicts of interest

4. Client and Employer: no employer-adverse interests, surface problems

5. Management: fair, ethical work rules, due process for violations

6. Profession: support profession and ethics code, don ’ t misrepresent software

7. Colleagues: credit colleagues ’ work, give colleagues a fair hearing

8. Self: improve your technical and ethical knowledge and

© USC-CSSE 11

USC

C S E

University of Southern California

Center for Software Engineering

Code of Ethics 2. Public

2.01 Disclose any software-related dangers

2.02 Approve only safe, well tested software

2.03 Only sign documents in area of competence

2.04 Cooperate on matters of public concern

2.05 Produce software that respects diversity

2.06 Be fair and truthful in all matters

2.07 Always put the public ’ s interest first

2.08 Donate professional skills to good causes

2.10 Accept responsibility for your own work

© USC-CSSE 2015/12/02 12

USC

C S E

University of Southern California

Center for Software Engineering

Code of Ethics 4. Client and

Employer

4.01 Provide services only where competent

4.02 Ensure resources are authentically approved

4.03 Only use property as authorized by the owner

4.04 Do not use illegally obtained software

4.05 Honor confidentiality of information

4.06 Raise matters of social concern

4.07 Inform when a project becomes problematic

4.08 Accept no detrimental outside work

4.09 Represent no interests adverse to your employer

© USC-CSSE 2015/12/02 13

USC

C S E

University of Southern California

Center for Software Engineering

Outline

• Definitions and context

– Power to do public harm or good

– ACM/IEEE Software Engineering Code of Ethics

• Principles and examples

– Rawls ’ Theory of Justice

– Relation to stakeholder win-win

– Case study: Mercy Hospital

• Integrating ethics into daily software engineering practices

– VBSE/MBASE/Win Win Spiral Model

– CS 577 ethics situations

2015/12/02 © USC-CSSE 14

USC

C S E

University of Southern California

Center for Software Engineering

Rawls ’ Theory of Justice (1971)

-

Following Collins et al., “ How Good Is Good Enough?

Comm.ACM, Jan. 1994

• Fair rules of conduct

• Principles of justice

• Participants and obligations

– Provider (developer)

– Buyer (acquirer)

– User(s)

– Penumbra (general public)

• Negotiate mutually satisfactory (win-win) agreements

2015/12/02 © USC-CSSE 15

USC

C S E

University of Southern California

Center for Software Engineering

Rawls ’ Theory of Justice - II

• Fair rules of conduct

– Negotiation among interested parties

– Veil of ignorance (about what affects whom)

– Rationality

• Principles

– Least Advantaged - don ’ t increase harm to them

• Harm = probability x magnitude (~risk exposure)

– Risking harm - don ’ t risk increasing harm

• Don ’ t use “ low-threat ” software in “ high-threat ” context

– Publicity test - defensible with honor before an informed public

2015/12/02

• Use for difficult cost-benefit tradeoffs

© USC-CSSE 16

USC

C S E

University of Southern California

Center for Software Engineering

Obligations of the Software Provider

To the provider To the buyer To the user To the penumbra

¨

Make a reasonable profit

¨ reasonable use warranty

¨ informed consent about testing process and potential shortcomings

¨ clear operating instructions

¨ reasonable protections from and informative responses to use and abuse

¨ provide reasonable technical support

¨ reasonable protections against physical, emotional, and economic harm from applications

¨ open about software development process and limits of correctness

2015/12/02 © USC-CSSE 17

USC

C S E

University of Southern California

Center for Software Engineering

Obligations of the Software Buyer

To the provider To the buyer To the user

negotiate in good

 provide quality faith , recognizing the importance of provider’s fair profit software appropriate to users’ needs within

learn enough about the software to make an informed decision

 facilitate adequate communication users reasonable budget constraints

 prudent introduction of automation

 informed consent to using software

To the penumbra

buy software only with reasonable safeguards for the public

 open about software capabilities and limitations

 represent user’s interests with providers

© USC-CSSE 2015/12/02 18

USC

C S E

University of Southern California

Center for Software Engineering

Obligations of the Software User

To the provider To the buyer To other users To the penumbra

 respect

 active

 willing

 conscientious effort ownership rights communication with the buyer cooperation in learning and to reduce any risks to the public using software

 good faith effort to learn and use software responsibly

 encourage reasonable expectations about software capabilities and limitations

 reasonable requests for computing power

© USC-CSSE 2015/12/02 19

USC

C S E

University of Southern California

Center for Software Engineering

Obligations of the Software Penumbra

To the provider To the buyer To other users To the penumbra

 become aware of

 advocate a

 expect only

 become aware of the capabilities and limitations of software

 advocate a suitable economic and statutory environment for quality software suitable economic and statutory environment for quality software reasonable service from users

 become aware of the capabilities and limitations of software the capabilities and limitations of software

 advocate a suitable economic and statutory environment for quality software

© USC-CSSE 2015/12/02 20

USC

C S E

University of Southern California

Center for Software Engineering

Case Study: Mercy Hospital Pharmacy System

-Collins et al., 1994

• Growing hospital

– Manual pharmacy information system reaching overload

• Spec developed for PC-based information system

– Rachel: VP, Records & Automation

– George: Chief Pharmacist

• System developed by consultants

– Hired by George

– Rachel: test procedures

– Based on mature warehouse inventory system

– Budgeted 50% more testing than other bidders

• Installation & Training discovers problems

– Helen: consultant in charge of installation & training

– Ann: skeptical nurse cross-checking computer outputs

2015/12/02 © USC-CSSE 21

USC

C S E

University of Southern California

Center for Software Engineering

Mercy Hospital Pharmacy System: Problems

• Dosage problems from data entry errors

– 10x dosage; wrong patient

• Cross-checking incomplete; not trusted by some doctors

• Heavier data-entry load

– Formalizing automated procedures

 more info. needed

– Pharmacy info > warehouse info

• Helen: Should go back to old system during cleanup

• George: - Is old system less risky?

How do we ensure cleanup will get it right?

How much will cleanup cost?

• Future practice: How to anticipate, avoid similar problems?

2015/12/02 © USC-CSSE 22

USC

C S E

University of Southern California

Center for Software Engineering

Outline

• Definitions and context

– Power to do public harm or good

– ACM/IEEE Software Engineering Code of Ethics

• Principles and examples

– Rawls ’ Theory of Justice

– Relation to stakeholder win-win

– Case study: Mercy Hospital

• Integrating ethics into daily software engineering practices

– VBSE/MBASE/Win Win Spiral Model

– CS 577 ethics situations

2015/12/02 © USC-CSSE 23

USC

C S E

University of Southern California

Center for Software Engineering

Mercy Hospital : Use of VBSE/MBASE/Win

Win Spiral

• Results chain

– Add patient safety outcome, patient stakeholder representative

– Rework-business-workflows initiative, including safety checks; add clerical-staff stakeholder

• Stakeholder Win Win

– Patient representative: safety criteria; parallel-operation phasein

– Clerical staff: prototype GUI, including safety-check support

• Business Case: includes added safety costs and benefits

• Risk Management: assess warehouse package safety, effects of workflow changes.

2015/12/02 © USC-CSSE 24

USC

C S E

University of Southern California

Center for Software Engineering

Use of VBSE/MBASE/Win Win Spiral-II

• Concurrent Engineering

– Concurrently address business workflows, GUI prototypes, COTS alternatives, feature prioritization, cost/schedule/benefits analysis, other risks

– Prepare to pass LCO, LCA, CCD, and IOC anchor point milestone reviews

• Monitoring and Control: Use Balanced

Scorecard to track progress with respect to plans; apply corrective actions as necessary

• Change as Opportunity: Look for emerging

COTS pharmacy-related fulfillment systems

2015/12/02 © USC-CSSE 25

USC

C S E

University of Southern California

Center for Software Engineering

Conclusions

• Software engineers have increasing power to do public harm or good

• Value-based codes of ethics are hard to integrate with value-neutral software engineering practices

• Rawls ’ Theory of Justice enables constructive approach for integrating ethics into daily software engineering practice

– Stakeholder win-win with least-advantaged system dependents as success-critical stakeholders

– Win Win Spiral Model/MBASE/VBSE provides dailypractice framework

2015/12/02 © USC-CSSE 26

Download