Software Development and Engineering Blog


HW28: Chapter 25

Sam Word | 21 Nov 2017

HW27: Chapter 24

Sam Word | 16 Nov 2017

HW19: Team Progress II

Sam Word | 14 Nov 2017

HW25: Chapter 23

Sam Word | 09 Nov 2017

HW24: Chapter 22

Sam Word | 06 Nov 2017

HW22: Chapter 21

Sam Word | 02 Nov 2017

HW19: Team Progress I

Sam Word | 31 Oct 2017

HW21: Chapter 20

Sam Word | 26 Oct 2017

HW20: Chapter 19

Sam Word | 24 Oct 2017

HW18: Chapter 18

Sam Word | 18 Oct 2017

HW17-B: Chapter 17

Sam Word | 11 Oct 2017

HW17-A: Chapter 16

Sam Word | 08 Oct 2017

HW16: Chapter 9

Sam Word | 05 Oct 2017

HW15: Chapter 15

Sam Word | 02 Oct 2017

HW14: Testing Reflections

Sam Word | 28 Sep 2017

HW13: Chapter 8

Sam Word | 28 Sep 2017

HW12: Mythical Man Month

Sam Word | 26 Sep 2017

HW11: Chapter 6

Sam Word | 21 Sep 2017

HW10: Chapter 5

Sam Word | 13 Sep 2017

HW9: Reflections

Sam Word | 12 Sep 2017

HW8: Chapter 2

Sam Word | 12 Sep 2017

HW7: Reflections

Sam Word | 07 Sep 2017

HW6: Chapter 4

Sam Word | 07 Sep 2017

HW5: Reflections

Sam Word | 05 Sep 2017

HW4: Chapters 11 & 12

Sam Word | 30 Aug 2017

HW3: Chapter 10

Sam Word | 28 Aug 2017

HW2: Responses

Sam Word | 27 Aug 2017

HW1: Chapter 1

Sam Word | 24 Aug 2017

HW0: Introduction

Sam Word | 23 Aug 2017

HW4: Chapters 11 & 12


30 Aug 2017

11.4

What is the common characteristic of all architectural styles that are geared to supporting software fault tolerance?

Redundancy and Diversity are the most common characteristics among architectural systems that support fault tolerance. The idea is that if one of the systems in place to prevent system failure fails, then there will be at least one other, slightly different protection in place to keep the system running.

11.7

It has been suggested that the control software for a radiation therapy machine, used to treat patients with cancer, should be implemented using N-version programming. Comment on whether or not you think this is a good suggestion.

N-version programming will likely be the safest implementation of software to control a radiation therapy machine. Similar to the software systems that control aircraft and nuclear reactors, if the software for a radiation therapy machine were to fail, lives could be lost. Although I believe that N-version programming is a good way to implement software for a radiation therapy machine, relying on software alone in a system that can easily kill a person is a terrible idea. A radiation therapy machine must have hardware safety checks in addition to software safety checks. For instance, a software issue in the Therac-25 radiation therapy machine was directly related to the deaths of more than one person. The software issue present in the Therac-25 was also found in the Therac-20, an older model, but the Therac-20 never caused any physical injury. This was because the Therac-20 had hardware safety checks so that when a signal for a massive dose of radiation was sent from the software to the hardware, certain fuses and breakers would be tripped, preventing a patient from receiving a potentially fatal radiation overdose.

11.9

Explain why you should explicitly handle all exceptions in a system that is intended to have a high level of availability.

As the number of unhandled exceptions increase, the probability that one of those unhandled exceptions will be encountered during runtime increases. Availability is defined as the probability that a system, at a point in time, will be operational and able to deliver the requested services. This means that if the probability of encountering an unchecked exception is high, so is the probability that a system will not be operational at a given time. Therefore, in order to have a highly available system, all exceptions must be explicitly handled.

12.5

A train protection system automatically applies the brakes of a train if the speed limit for a segment of track is exceeded, or if the train enters a track segment that is currently signaled with a red light (i.e., the segment should not be entered). There are two critical-safety requirements for this train protection system:
  • The train shall not enter a segment of track that is signaled with a red light.
  • The train shall not exceed the specified speed limit for a section of track.
Assuming that the signal status and the speed limit for the track segment are transmitted to on-board software on the train before it enters the track segment, propose five possible functional system requirements for the onboard software that may be generated from its system safety requirements.
  1. If the speed limit of the upcoming segment of track is lower than the current speed of the train and the signal is green, gradually apply the brakes until the new speed limit is reached.
  2. If the speed limit of the upcoming segment of track is higher than the current speed of the train and the signal is green, gradually accelerate until the new speed limit is reached.
  3. If the upcoming segment of track is signaled with a red light, begin applying the brakes so that the train can safely stop at the signal.
  4. If the signal status changes from red to green while slowing down to approach the signal and the train is currently moving faster than the upcoming speed limit, continue gradually slowing down to match the speed limit of the upcoming speed limit.
  5. If the signal status changes from red to green while slowing down to approach the signal and the train is currently moving slower than the upcoming speed limit, gradually speed up to match the speed limit of the upcoming speed limit.