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.
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.
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:
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:
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.
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:
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.