ITS 321: Legal and Ethical Issues in Information Technology

Lesson 6: Software Development

Objectives:

Chapter 7 discusses concepts related to software development, including some ethical issues. Objectives important to this lesson:

  1. Why high quality software is needed
  2. Ethical issues balancing development time, cost, and quality
  3. Common liability claims related to software
  4. Software development methods
  5. Capability Maturity Model Integration
  6. Safety-critical systems
Concepts:

Chapter 7 begins with a discussion of a software failure in a medical device. The device could deliver a dose of radiation that was much higher than that intended by the operator due an error that caused the software not to recognize the current state of the hardware. This illustrates that there are times when software can have an effect on human lives.

The text spends a few pages talking about quality in software and some reasons for defects existing. It is true that analysts may make errors in determining what users need from a new program. It is equally true that users typically make mistakes in what they ask for. Put those two ideas together and you get the need for successive prototypes which are shown to the user group not for acceptance as much as for corrections to the design. The aircraft example in the chapter introduction also points out the need to revise software requirements based on updates to hardware. Another type of change that makes software design a moving target is legislative change. Laws change while long projects are conducted, which means that the projects have to change as well to be compliant.

It is still necessary to avoid defects in software for the reasons given in the text: accuracy, safety, fiscal responsibility, and profitability. The text mentions cutting corners in development to meet a deadline. This should not occur but it can be inevitable as time pressure to complete a project increases. It is good to remember a truism about software design that applies to other fields as well. The customer wants it done quickly, done well, and done inexpensively. Too bad: tell them to pick two, they can't have all three.

  Fast Good Cheap
Fast and Good Yes Yes It will take more staff and overtime to do this.
Fast and Cheap Yes This will create less error checking, less accuracy, and lower quality overall. Yes
Good and Cheap This means insufficient staff, more time to code and test, and a longer project. Yes Yes

Some of the experiences of an animator trying to work on a small budget may be illustrative. Take a look at Lucas Martell's blog site about his short film, Pigeon: Impossible. He explains several issues relating to IP rights, production, and trying to make dollar as an independent film maker. Plus he has links to his film and to many other good ones.

Liability

Moving ahead to page 287, the text discusses various sorts of liability that can be associated with software. Product liability exists when a company's product does not perform as it should. Typically, this means that it does not meet the manufacturer's claims. In terms of software, this could mean that it does not fulfill the requirements of a contract for its creation and implementation.

Strict liability exists when a defendant's product is defective or unreasonably dangerous and the defect caused an injury to a person. The text points out that this kind of suit does not require proof of carelessness, negligence, or malice on the part of the defendant. The text lists three classic defense arguments in this kind of case:

  • supervening event defense - something happened to the product after it left the manufacturer, and that event caused the defect that caused the injury
  • government contractor defense - that the software (or product) met the requirements of the contract that authorized its creation, and that the government was advised of any known defects
  • statute of limitations defense - that the time period since the injury occurred is greater than the time window within which a liability suit must be brought

Negligence is another charge that might be brought. It accuses the defendant of acting without the care that a reasonable person would show in a similar situation. With regard to software creation, negligence may refer to one or more defects that should have been found and corrected by a reasonable developer. Defense arguments offered by the text:

  • legal justification for the defendant's actions
  • contributory negligence - that the plaintiff acted in a way that added to or caused the injury

Warranty is a guarantee of something, in this case a guarantee that software will perform as described or as the user desires. An implied warranty of merchantability exists for any product that is sold, based on the fact that the merchant is presenting it for sale. Review the bulleted list on page 289 of standards that apply to this implied warranty.

The text reminds us that a warranty need not be implied: it can be oral (spoken), written, or inferred (customer believes there is a warranty based on the seller's actions or behavior). A written warranty will state what is guaranteed, which may limit the liability of the seller unless a court chooses to disregard the limitation as unreasonable. The text discussed breach of warranty and misrepresentation back in chapter 2. It discusses these topics again here.

Software Development

People who have studied programming for any time at all are usually exposed to software development methods. The text, unsurprisingly, endorses the idea of using a structured method that includes quality management. Regular procedures to develop and check computer code lead to better code and fewer errors.

The text lists several methods of software testing that may be used in a development process:

  • black-box testing - testing done by someone who has no knowledge of the way a program actually works; typically done by a user instead of a programmer
  • white-box testing - testing done by someone who understands how the logic of the program works; testing of this sort must be done be development staff
  • static testing - testing a program with a set of data that should produce a predicted result
  • integration testing - testing units or modules of the program together as one integrated unit to find any problems that might exist in the linkages between modules
  • system testing - testing the entire system once it has been assembled from all its parts
  • user acceptance testing - testing by end users who are empowered to approve or disapprove the product

The father we go in this chapter, the more I am confused about why this chapter is in this book. The topics are important to anyone writing software, but they do not pertain to the topic of this book or this course. Every year there are another dozen authorities who claim to have found the holy grail of developing software. Funny, they all seem to do the same thing with different terms. This is enough of this topic for this lesson.