How Good is Good Enough?

Document Sample
How Good is Good Enough? Powered By Docstoc
					  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.

7/1/02                CSC309 Miller         1
          How Good is Good Enough?
Significant software when first released will contain

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
 4/9/01                CSC309 Miller                    2
                  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/7/01                 CSC309 Miller                 3
                  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
 4/7/01                CSC309 Miller                   4
          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

3/9/09              CSC309 Miller            5
          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.

9/27/08           CSC309 Miller            6
 Software Process Principal Actors

1. Software provider

2. Software buyer

3. Software user

4. Penumbra (Anyone else who could be
affected by the software).

 4/7/01                CSC309 Miller    7
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

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.]
 4/7/01                 CSC309 Miller                 8
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.
 4/7/01                    CSC309 Miller              9
    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

3. Software affects an increasingly large number of

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.
 4/7/01                 CSC309 Miller                 10
            From "How Good is Good Enough"

1. Providers have an ethical responsibility to do a
thorough, careful job when writing their bids or

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.
 4/7/01                 CSC309 Miller                 11
             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.

4/7/01                CSC309 Miller                   12
Software Flaws Cost the Country a
          --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)

9/25/08                   CSC309 Miller               13
              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."

 7/8/02                  CSC309 Miller                  14

Shared By: