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

Software diversity.  If the different types of software used contain different information, they should have different errors for different reasons.  If they vary in those ways, they should not fail for the same reasons which also suggests, they should not fail at the same time.

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.

Since there are at least three different versions of the system, it is more likely for errors to occur less often which is very important in a machine treating patients with cancer.  The book mentions that N-version programming is only used when it doesn’t make sense to create a system that can protect against safety-critical failures.  If it doesn’t make sense, then sure, I think this is a good approach and would be sensible.

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

Since exception handling can make it easier to deal with errors from user input or other places, it contributes to the possibility of normal operation after the exception has been handled, reducing errors and potential shutdown of the system.  This is especially important in a system with a high level of availability such as a hospital or data center where large amounts of data are constantly being updated and accessed.  If the information is unavailable due to a shutdown from an error that could have been handled with an exception, major issues could come up.

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 the system safety requirements.

1. The train should include a self-testing software that will test the onboard software including the red light sensor system and the speed limit detection.
2. The self-testing software should execute every 30 seconds.
3. If the self-testing software goes down for any reason, a warning light and sound should go off to alert the driver of reduced safety, and indicate which system detected an error.
4. If speed is going faster than limit, slow down.
5. If track is signaled with red light, do not enter, alter route.

10.6: Explain why it is reasonable to assume that the use of dependable processes will lead to the creation of dependable software.

The term dependability, in our context, relates to qualities of being available, reliable, safe, resilient and secure. If these four qualities are the basis of not only one process, but the standard for many more that are used to build a bigger program, it can be assumed that the program will be dependable altogether. A good practice of writing dependable software will contain fewer errors and be less likely to fail.

10.10: It has been suggested that the need for regulation inhibits innovation and that regulators force the use of older methods of systems development that have been used on other systems. Discuss whether or not you think this is true and the desirability of regulators imposing their views on what methods should be used.

Yes, I do think that it is true to an extent. If regulators force the use of older methods, they have more control over the functionality of a system. It is proven, has worked in the past, and is a much safer decision. By moving with newer, potentially more improved, but very much more intimidating systems, a regulator opens the door for more uncertainties. Although the innovated technique could be the better one, the security of sticking with old habits is much easier, and therefore could definitely inhibit innovation as a whole. Regulators should impose their view when necessary, but be sure to keep an open mind in regards to new processes that can greatly improve the field despite the fact that it can be worrisome.

Each of the three articles discusses difficulties in the world of software architecture. The first article talks specifically about Google and their continued choice to use a single repository for all of their code. The second is contains short Q and A discussions related to software engineering. The third discusses a combination of difficulties in the world of software as well as advancements to the field and future ways to improve the field.

One of the common topics is the quality of dependencies and their contribution to the difficulty of software management.  According to the Google article, unnecessary dependencies can lead to future breakdown of software and more complexity than is needed.  In the third article, it is stated that in most software situations, the different components of the program will interact with each other in a “nonlinear fashion, and the complexity of the whole increases much more than linearly” (Brooks 11).   In the second article, there is a question about a developer having an issue with a superior.  Whenever the developer fixes a bug, they are questioned by their superior and feel that they are not being trusted to do their job properly.  The answer is summed up by talking about not just knowing in your gut, that the code is correct, can be enough in questionable code.  Due to issues, such as dependencies, we need proof that dependencies are designed properly in order to avoid major software issues.  We cannot simply feel good about our code, without performing proper testing, and guarantee that it works as it is supposed to.  Just because someone questions our code doesn’t mean that we are inadequate, just that we need to be able to defend why we wrote what we wrote and the testing that was performed to ensure it is working in proper fashion. Google, for example, has taken this testing to a much higher level.  By designing and coding tools that can find dependencies that are not being used or are not being used in their best manner, and get rid of them.  The second article discusses using the scientific method in approaching problems.  First, start with a theorem about the problem at hand and then, create a hypothesis that is testable.  By performing these two actions prior to starting to attack the problem, the developer or engineer is able to safeguard themselves about making little mistakes such as dependency issues that can often be prevented in the first place. It was stated that  “the reality of software is not embedded in space” (Brooks 12).  As building can have blue prints and there are maps to depict the Earth, software is not nearly as able to visualize.  When a person tries to simplify a depiction of software, it is quick to recognize that our human minds want to break the relationships down into linear dependencies and relationships.  A determines B and C determines D, if A then B, if C, then D.  However, software is not that simple.

The complexity of software cannot be understated.  Especially in a company as grand as Google, major processes and systems must be in put in place to maintain quality code.  Whether one is performing some light bug fixes at a local tech company, or trying to push a new version of Google, dependencies must be of high quality and can often be tough to maintain and keep up.

1.3: What are the four important attributes that all professional software should possess? Suggest four other attributes that may sometimes be significant.

1. Acceptability – must be appropriate for it’s users, legible, practical, and conform to other applications they will use.
2. Dependability and security – users need not worry about safety of the software, risks involved in using it, the possibilities of what will happen if the software fails, etc.
3. Efficiency – the difference in two programs that perform the exact same operations but require very different amounts of memory can be huge. If a program works perfectly but is largely wasteful in terms of memory usage it is not an efficient program.
4. Maintainability – needs of the software will change over time, the application needs to have ability to be updated and adapt to user’s needs as they evolve as well.
5. Affordability – if a software is fantastic but unaffordable, what is its value?
6. Accessibility – software needs to be accessible through marketing, search optimization, people need to know about it for building it’s reputation
7. Interface quality – if the user interface/frontend look is not carefully created, could lose all credibility as people are quick to judge poor front end jobs in the modern world
8. Speed of updates – could have innovative ideas and quality updates, but if a software is not quick to push new versions, users could get frustrated and look for alternate software

1.8: Discuss whether professional engineers should be licensed in the same way as doctors or lawyers.

I don’t think we are at the point of professional engineers being licensed in the same way as doctors and lawyers. Although cyber security is a major political issue and every day our data is being accessed, used, and sold to who knows where or why, the anonymity of the internet will make it difficult to hold software engineers accountable in the same way that doctors performing an operation and working out of hospitals or clinics, or lawyers working out of physical offices and court rooms are able to be held accountable. In today’s world with technologies such as blockchain and ability to access internet remotely, it would be tough to force licensing among all “professional engineers.”

1.9: For each of the clauses in the ACM/IEEE Code of Ethics shown in Figure 1.4, propose an appropriate example that illustrates that clause

1. Public – Software engineer must act in good faith to the public around them, ethical decisions and actions are a must.
2. Client and Employer – If an engineer acts in manner that is appropriate from eyes of both client and employer, they can do a good job of keeping themselves within the scope of quality engineering
3. Product – Software engineers cannot put out poor products, it is clear to the engineer if the product is quality or not. If it is not, no need to release or try and convince public that it is.
4. Judgment – It can be easy to judge someone or a product, but it is important to stay ethical in those feelings and speak in appropriate manner.
5. Management – software is not complete upon launch, must be maintained and managed in an appropriate manner throughout its usage
6. Profession – Should act in professional manner in order to maintain the integrity of the field.
7. Colleagues – Must treat each other with respect, don’t know when you’ll be collaborating with or needing the help of those around you. Need to support each other regardless of differences.
8. Self – A software engineer cannot discontinue learning in such a developing and changing field. This would devalue their practice of profession. They also must hold themselves accountable and can’t use their skillset in an unethical way.

1.10: To help counter terrorism, many countries are planning or have developed computer systems that track large numbers of their citizens and their actions. Clearly, this has privacy implications. Discuss the ethics of working on the development of this type of system.

In terms of ethics, where is the line of how intensely tracked a person is will be alright, versus too much. There is already an ability to track large numbers of people and I think the general public is largely OK with this. However, could it reach a point where cell phone tracking is not enough. What if people put their phones down, or we feel that we need better, more reliable information? What if there is a privately or publicly funded program that incentivizes and pays people to volunteer to get ‘chips’ put in their wrists in order to better track their positions? What if cameras with facial recognition software are installed at every street corner, traffic light, lamppost, etc. and we are able to document specific locations/actions without cell phones or a chip? At a point, it can become overwhelming and offer too much power to hackers or ill intentioned people. What if terrorists hack our tracking system and can instantly locate public officials, celebrities, or even the president?

Hello,

I’m Jason Adler and I’m a senior at CofC. Looking forward to the course.