HW4: Chapters 11 & 12

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

The common characteristic of architectural styles that are geared to support software fault tolerance is redundancy coupled with diversity. These characteristics combined give the system a high level of dependability and availability.

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

Any system that has the potential to harm a life-form should take all precautions to ensure that the system can consistently obtain an acceptable failure rate. N-Version programming accomplishes this by implementing a multi-layered system, where the layers can be designed independently, and rigorously tested to ensure all specifications are meet. This type of design entails reasonable and reliable fault tolerance mechanisms that can produce acceptable failure rates in a consistent manner. Because of this, I think it N-Versin programing is reasonable/good suggestion.

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

Needing a high level of availability corresponds to the consistency of which an entity is needed. This need may serve different purposes, but if an exception is not handled in manner that allows the system to run, its failure can have adverse affects. These effects can include danger to health, a large sum loss in revenue,  a detrimental breach in security, etc. Due to the irrevocable affects that a non-handled exception can have in a high level of availability type system, it is essential to address all exceptions.

(12.5). A train protection system automatically apples the brakes... There are two critical-saftey 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.

..., propose five possible functional system requirements for the onboard software that may be generated from the system safety requirements. 

a). Get specified speed limit, if within 'X' percentage of limit, reduce speed.
b). Send warning notifications to the conductor and other impertinent personnel.
c). Document location, time, and speed and send to management.
d). When train is within 'X' proximity of red light segment, apply emergency brakes.
e). Recalculate distance to red light segment, if within 'X' distance, perform 'b' and 'd' .

HW3: Chapter 10

(10.6)

A dependable process incorporates the characteristics of being audible, diverse, documentable, robust, redundant and standardized. Implementation that utilizes such characteristics have been proven to result in a sustainable product that is reliable and offers  an acceptable level of security and resiliency. Consequently one would conclude that the derivative product (being the software) would inherit those same characteristics. 

(10.10)

A common saying of “if it’s not broke, don’t fix it” comes to mind with this scenario. There is a proven method thats widely accepted throughout the industry. Thus, a logical thinker would not intuitively spend an exhaustive amount of their resources trying to change something that works. Because of this, regulators do  play a significant role in imposing their views and ideologies on the industry. Since regulators set the standards that constituents of the field should follow, there is a direct correlation between them (regulators) and the methods that are most likely to be used. 

However, regulations may make innovation more of challenge but does not necessarily inhibit. To me innovations is the skill of producing a product/method/procedure given certain restraints. I think for truly innovative minds, regulations are not inhibitive, but serve as challenge that highlights an individuals ingenuity. I look at regulations as hurdles that separate the ingenuity of one mind versus that of the standard or  “basic” mind. 

HW2: Responses

Software Engineering can be described as the process of modeling animate and inanimate entities by use of abstraction in order to simplify a given task(s) in such a way to make such task(s) less cumbersome and simpler to understand. The goal of this being to automate tasks commonly found in our lives or those found in large cooperations in a dependable manner. Fredrick P. Brooks, the Author of “No Silver Bullet” gives arguments to why accomplishing such goals in a reliable fashion is not an easy task and why will we not see massive leaps in techniques that will make software engineering magically less cumbersome. 

Brooks highlights many reasons why there is not a magical solution that will make software engineering less cumbersome:

• The very nature of abstraction can strip an entity of its essence if it is  oversimplified.

• The industry innately models those things that continually change which causes the      product/software to do so as well. 

• With programs and requirements continually growing and with the addition of many constituents working on a project, being able.

        to accrately visualize and model the software in a cohesive agreed upon manner is challenging. 

In the readings from “Kode Vicious” and “Google Code Repo” we read 1st hand testimony and 3rd hand accounts that highlight some of Brooks concerns that are taking place in todays industry. Although the overall tone of Brooks makes software engineering tasks seem insurmountable he believes the most effective way to de-complicate software modeling is to reuse code and build onto what has already been established.

“Kode Vicious” highlights the concern of what is truly the best way to model a problem and approach a task. We see here that what Brooks describes as the ability to visualize a process in a cohesive manner is not a straightforward process. With many “eyes” trying to tackle a problem, it comes with many ideas in what approach works best to complete that problem. We see that individuals members of a team may have an approach they think is best while other members working on the project such as upper management may have differing methodologies. This supports the idea from Brooks that the number of constituents working on a task can correlate to the complexity in how to visualize and complete a task. George Neville-Neil (author of Kode Vicious) believes that the best way to approach a task is by a method that can be found in other sciences… the Scientific Method. Through this approach one is able to document and resolve problems via a process that allows for others and oneself to accurately identify and mimic the solution. 

"Google Code Repo" explains how Google was able to accomplish its massive repository called Piper, and the plights they face and faced when designing the repository. Many of those plights where ones that Brooks highlighted as challenges in designing software, the most prominent being that of visualization. How to seemingly allow many different workers to work on a project simultaneously in a synchronized manner that does not corrupt the code. In short, how to keep everybody on the same page. Google was able to accomplish this by a method called Trunk-based development. With this approach, users work with one consistent view of the codebase where source code updates are in a way enumerated and sorted or “cherry-picked’ for the best results. With the Trunk-based approach, Google has essentially synchronized the work of thousands of their developers. They did this by creating a process of unified versioning, reusing code, and having clear visualization, a ‘best-fit” solution to software modeling that Brooks proposed in the Silver Bullet.

We see throughout these articles why software engineering can be cumbersome, but challenging does not equate to impossible. Brooks stated reasons why software modeling is challenging and he suggested methods to best accommodate for them. In Kode Vicious and Google Code Repo we get first hand accounts of those challenges, but we also receive testimony to what works and how it was accomplished, all in which supports Brooks ideologies to the approach of software engineering.