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.