1. 7/1/02CSC309 Miller1 How Good is Good Enough? Collins, Robert, Keith Miller, Bethany J. Spielman, and Phillip Wherry. Communications of the ACM January 1994, vol. 37, no 1.

2. 4/9/01CSC309 Miller2 How Good is Good Enough? Significant software when first released will contain errors. Software that matches specifications perfectly can contain errors if specifications are not perfect. Software that matches specifications perfectly and has perfect specifications can be used erroneously by users. So what we are really talking about is when to release software and how to protect against the inevitable errors.

3. 4/7/01CSC309 Miller3 Sample Case At Mercy Hospital, Rachel, the vice president in charge of records and automation, and George, the chief pharmacist, agree that computerization has the potential for increasing the efficiency of the pharmacy. Rachel and George then seem to do everything right. They produce a specifications document which they get approved. They hire consultants to design and implement the system and provide them with specifi- cations for testing procedures. They hire Helen as the consultant to install the system and train the doctors, nurses, and pharmacists who will use the system. Problems that arise include two near mishaps, com- plaints concerning too much typing, and disagreement from doctors with computer generated advice.

4. 4/7/01CSC309 Miller4 More Details The old system had problems and it was in part with the thought that the new system would be safer, that the new system was developed and installed. The system did not identify the source of changes to the data base so that when problems arose it was not clear if they were system or operator errors. Part of the new system was built on a large warehouse inventory program that had been in use for almost five years. The amount of typing involved sort of grew and caught everyone by surprise. Ann Frederick, a nurse and vocal critic, caught both problems.

5. 3/9/09CSC309 Miller5 Rawlsian Approach We observe that participants of society interact with one another in cooperation and conflict. "They cooperate since they can achieve a better life together than they could alone, they contend since they are personally affected by how the benefits of their cooperation are distributed."

6. 9/27/08CSC309 Miller6 Rawlsian Approach Rawls proposes that the social contract be created in a negotiation session conducted by members of society in which the participants do not know how any alternatives will affect their own positions. They must evaluate scenarios in which they could become the most or least favored party.

7. 4/7/01CSC309 Miller7 Software Process Principal Actors 1. Software provider 2. Software buyer 3. Software user 4. Penumbra (Anyone else who could be affected by the software).

8. 4/7/01CSC309 Miller8 Principles If we apply a Rawlsian negotiation scheme to our software problem, we would probably arrive at the following principles. 1. Least Advantaged. Don't increase harm to the least advantaged. 2. Risking Harm. Don't risk increasing harm in already risky situations. 3. Publicity Test. Use publicity test for difficult cost benefit trade-offs. [Make only those decisions you can defend with honor before an informed public.]

9. 4/7/01CSC309 Miller9 Analysis 1. Identify the players. 2. Review the three Rawlsian principles. For the least advantaged sometimes you can use the focus of criticism/concern as representative. Most of the time you simply select someone to be advocate. Risking harm Publicity test. Can everybody make the case that the software is safe? 3. Analyze responsibilities of the players and identify actions each player could take to advance the three Rawlsian principles.

10. 4/7/01CSC309 Miller10 Software is not a typical product 1. Software errors can remain after extensive testing. 2. It is difficult/impossible to construct uniform software standards which could be subject to regulation and inspection. 3. Software affects an increasingly large number of people. 4. Anybody can produce software. 5. Software threats tend to be dispersed. Because the dangers of software cannot be controlled well, there are additional ethical responsibilities to minimize risk.

11. 4/7/01CSC309 Miller11 Guidelines From "How Good is Good Enough" 1. Providers have an ethical responsibility to do a thorough, careful job when writing their bids or contracts. 2. Do not increase harm to the people most vulnerable or increase risk in an already risky situation. 3. Software developers and buyers have a responsibility to be open and honest about capabilities, safety, and limitations of the software in communication with customers, employees, others who are affected by it, and the public, where appropriate.

12. 4/7/01CSC309 Miller12 Guidelines Cont. From "How Good is Good Enough" 4. Developers and buyers have an obligation to properly train users. Buyers and users have a responsibility to understand the limitations of the software and its proper operation. 5. Developers and buyers should include users in the planning and testing stages to improve safe functioning of the system.

13. 9/25/08CSC309 Miller13 Software Flaws Cost the Country a Bundle --25 & 27 June 2002 National Institute of Standards and Technology(NIST) Study "buggy software" costs the US $59.9 billion annually, with the lion's share of the burden falling on consumers. Better testing could reduce the cost by as much as 1/3, or $22 billion. (Interesting math)

14. 7/8/02CSC309 Miller14 Quote of the Week (from CIO Magazine, July 1, 2002) Kevin Turner,CIO of Walmart, says,"I'd really like to see our technology vendors step up and help us with these [security] vulnerabilities because the money that we are pouring into security right now is being pulled away from development and strategic things that we could be investing in. A lot of the vulnerabilities that we deal with are preventable and could be avoided if the technology vendors would do the due diligence to tighten up [the security configuration of] their products."