HW7: Reflections

     Software engineers need to design resilient and dependable systems. Designing software is a multilayered process that encompasses user and system requirements..These requirements can be classified as functional and non-functional. One of the first hurdles for software designers to overcome is identifying what the functional and non-functional requires of the system are. Functional requirements are those specifications in which the system shall do, and non-functional requirements are those that define how the system works. 

    There a few ways to identify these requirements but using UML’s is an effective approach.  By using UML’s it helps the designer to graphically model parts of the system that is comprehensive to the client/user and to the programmers. Other Methods that help decompose a system to identify functional and non-functional requirements is by using Test-driven development (TTD) approach.  This approach provides the working specifications of functional code. It also produces quality code which incorporates exception cases that allow for increased resilience, which in-turn can increase dependability. Software designers must plan courses of action incase of software or hardware failure to ensure a dependable system. Thus implementing UML’s aid in accomplishing software design requirements that produce resilient and dependable systems that plan for failure. 

HW6: Chapter 4

(4.5) Using the technique suggested here, where natural language descriptions are presented in a standard format, write plausible user requirements for the following functions: 

 • The gas pump system shall be unattended.

• The gas pump system shall have a credit card reader (The pump system must have a card reader to ensure the system is functional when unattended),

• The gas pump system shall ask for a specified amount of fuel after customer swipes their card.

• The gas pump shall debit the customer account after fuel is delivered (Customers account should be charged after the  system verifies the fuel has been delivered to avoid a scenario where the system charges the customers account, but has less fuel available to deliver than the customers specified amount).

• The cash-dispensing machine shall be a bank ATM.

• The internet banking system should allow customers to transfer funds between accounts hosted by the bank.

(4.6) Suggest how an engineer responsible for drawing up a system requirements specification might keep track of the relationships between functional and non-functional requirements.

 Requirement specification is defined as the process of formally documenting the requirements of the software, user and system. An engineer can track of their functional and non-functional requirement relationships by using an appropriate Unified Modeling Language such as use cases. 

(4.7) Using your knowledge of how an ATM is used, develop a set of use cases that could serve as a basis for understanding  the requirements for an ATM system

ACTOR: USER

ACTOR: BANK_SYS.

• USER (inserts card) —> enter pin —> enter withdraw amount
• USER (inserts card) —> enter pin —> choose deposit account
• BANK_SYS —> validate pin
• BANK_SYS—> validate withdraw/deposit specified amount
• BANK_SYS —> verify pin —> dispense/retrieve specified amount

HW5: Reflections

 
Software engineering without question can be a long and complicated process. With having to account for so many features, it can turn into a downward whirlwind if the process is not managed appropriately. Those features that need to be accounted for but not limited to are security, safety, and an adaptive design. When these features are ignored or improperly  managed there are adverse effects, thus raising the need for strict regulations on safety-critical systems.

 
The most noticeable of effects that can be seen with safety-critical systems are commonly found in the medical field, when safety and security features are handled irresponsibly. Irresponsible designed medical software is dangerous in safety-critical systems because it has the potential to affect masses of people. With the “Therac -25”, “2010 Radiation Follies”, and related articles, we see how the lack of strict regulations allowed for a continuous production of intolerable risky software (systems that can threaten human life). They highlight the need to have in place strict regulations that impose routine hazard analysis. It also highlights the need for manufactures to have well documented user manuals for their safety-critical devices, and for those institutions that utilize such devices, to employ certified technicians. By these steps alone it minimizes the denial of accountability. We see in the related articles that because there was lack of detailed operation procedures from manufactures, and unregulated device operation standards, it allowed for both the manufacturing and medical industries to avoid taking accountability for any detrimental effects that originated from their product or practice. 

  
    Improper software design is not limited to just affecting the safety of those devices found in the medical industry, it expands into compromising the security of our everyday infrastructure. That infrastructure being anything with a computer in it that we depend on to perform common  routines that allows for us to sustain our quality of living… such as transportation. Vehicles are becoming more dependent upon computers that monitor and control many functions of the car. When these computer controlled systems are designed in a way that does not adhere to standard security design guidelines, it compromises its user and those around. We saw that due to poor software security measures in “FBI Auto Warning” and related articles, malicious software could be loaded into a vehicles onboard computer system, granting access and control to outside parties who could manipulate actions and functions of the car.  

 
     Adaptive design is another safety and security feature that should not be ignored when designing software systems. Adaptive design relates to the ability for the software to be used that is conducive to its specification, comprehensive to its users, and incorporates flexibility. This can otherwise be described as sociotechnical resilience. In the FBIs long quest to upgrade their outdated relational database system, the lack of sociotechnical resilience characteristics in the Sentinel system caused expensive delays for the agency. Because it did not incorporate some of the basic principals of sociotechnical resilience, its designers were always playing “catch-up”. Not always being user-friendly and incorporating basics features, and having to consistently update and include new features made the Sentinel project a long and unpleasurable process.

     
    Adhering to safety-critical, secure and adaptive software guidelines is becoming more crucial as technology advances. We need to protect our infrastructure by enforcing strict regulations on intolerable risk systems and those that can massively jeopardize the quality of life. We see that irresponsible software design has extensive range that can negatively affect the individual or conglomerates such as the FBI. It would serve us best to implement and follow design principals that promote sociotechnical resiliency. 

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. 

HW0: Introduction

My name is Bernard Casey (better known as "Casey" ), I was born and raised primarily throughout the depths of South Carolina in a house hold of 8, where resources may have been limited at times, but there was never a shortage in love and support. 

My childhood happiness was fueled by the eagerness to fulfill curiosities of the world around me. At that time my world consisted of video games and athletics. Athletics I understood and eventually mastered, but the electronic world was another entity in its own. I wanted to understand the intricate details of how and why electronics and video games worked. Then came the TV show "Battle Bots" in my youth (in which I referred to as the "World Wrestling Federation of Robot Mayhem") where engineers would build and design robots that would essentially attempt to destroy one another. 

At that point I did not just want to understand electronics and gaming, I wanted to create them.  That curiosity and urge lead me to where I am today, a senior in the Computer Science Program at the College of Charleston.