Describe five factors that engineers should take into account during the process of building a release of a large software system:
Building large software systems is a time intensive process that requires detailed planning. Factors that engineers need to consider are the basic fundamentals an engineer or software manger would take when designing software. They would need to follow some of the processes identified in plan-driven development. The engineer first would need to develop a conceptual design for the software system. Secondly, a risk analysis would need to be taken, followed by contingency plans to deal with those risks. To be able to act promptly incase of a contingency plan needs to be exercised, the engineer needs to establish procedures that monitors their risk. Last but not least, the engineer need to address organizational issues such as staff that will handle coding and clerical duties.
Saturday, December 10, 2016
HW27: Chapter 24
Explain why program inspections are an effective technique for discovering errors in a program. What types of errors are unlikely to be discovered through inspections?
Inspections are a fundamental need for any product that is made for public use, the same applies to program code. Inspections in programming allows errors to be found that would not necessarily be found at compile time. These types of errors are logical errors. Types of logical errors can be arithmetical or interpretative. Since these type of errors may not cause faults in a program at run or compile time, it can make them hard to find. The most effective way to find logical errors is not by automated processes but by manually probing through the code. Routine inspections provide this type of manual probing.
Inspections are a fundamental need for any product that is made for public use, the same applies to program code. Inspections in programming allows errors to be found that would not necessarily be found at compile time. These types of errors are logical errors. Types of logical errors can be arithmetical or interpretative. Since these type of errors may not cause faults in a program at run or compile time, it can make them hard to find. The most effective way to find logical errors is not by automated processes but by manually probing through the code. Routine inspections provide this type of manual probing.
Tuesday, November 15, 2016
HW25: Team Progress II
After our last project was banned (PokemonGo map), we were able to find another project that was not at risk of being banned or blocked. We choose todo a League of Legends application that provides a slew of testable methods. Since we already had our test driver setup and running for the Pokemon map application, we reused the framework from that project to test methods in the League of Legends application. We have successfully identified and tested 20 methods within the League of Legends application. Also, we have scripted the results of the methods to generate in a webpage as specified. Now, we are awaiting for feedback to any changes that may need to be made to our test driver and any other portions of our project.
HW24: Chapter 22
(22.6). Fixed-price contracts,where the contractor bids a fixed price to complete a system development, may be used to move project risk from client to contractor. If anything goes wrong, the contractor has to pay. Suggest how the use of such contacts may increase the likelihood that product risks will arise.
Fixed-price contracts may increase product risks in many different ways. The objective of the contractor bidding on a job is to bid at a price that will allow for him to make a profit while delivering a specified product. Often bidders have to be competitive in time and price, as-in who can deliver the product for the lowest contract price in a specified amount of time. This leads to contractors promising completion time frames for projects that may not necessarily be obtainable. To compensate, the contractor produces a rushed product that may not fulfill all of the clients requirements and may lack in the area of security. This is a result of not having sufficient amount of time to fully test and debug the project.
Fixed-price contracts may increase product risks in many different ways. The objective of the contractor bidding on a job is to bid at a price that will allow for him to make a profit while delivering a specified product. Often bidders have to be competitive in time and price, as-in who can deliver the product for the lowest contract price in a specified amount of time. This leads to contractors promising completion time frames for projects that may not necessarily be obtainable. To compensate, the contractor produces a rushed product that may not fulfill all of the clients requirements and may lack in the area of security. This is a result of not having sufficient amount of time to fully test and debug the project.
HW22: Chapter 17
(17.10) Your company wishes to move from using desktop applications to accessing the same functionally remotely as services. Identify three risks that might arise and suggest how risks may be reduced.
This type of switchover models a client-server type of architecture which requires client-side functionality and server interaction. The type of risks with this type of architecture include server overload, control of data transfer rates/speeds, and server failure resulting in data loss. To reduce the risk of server overload, web technologies such as AJAX and HTML5 can be implemented. They provide better efficiency when it comes to webpage presentation and local computation. To aid in data transfer rates and speeds, data can be compressed then transferred. This reduces the size of the file and may reduce the load on the network. To prevent a situation where there is a complete data loss due to a server malfunction, the company can regularly schedule data backups to external sources other than on the hosted server.
Wednesday, November 2, 2016
HW21: Chapter 20
(20.10) Discuss the ethics of changing the system interfaces without notice to coerce users into paying higher charges. Consider this question from the point of view of the company's employees, customers, and shareholders.
Changing a system interface without notice to coerce its users into paying higher chargers is unethical and violates the basic principles of the ACM. Namely, it violates the Judgment, Profession, and Client and Employer principles. Together they emphasize that professionals of the field should act in a manner that promotes the reputation and integrity of the industry and produce products that are in the best interest of client. The idea coercing a client for the gain of profit can be detrimental to the reputation of the industry. It can lead to mistrust with the public and most importantly result in unwanted legal attention and repercussions.
Changing a system interface without notice to coerce its users into paying higher chargers is unethical and violates the basic principles of the ACM. Namely, it violates the Judgment, Profession, and Client and Employer principles. Together they emphasize that professionals of the field should act in a manner that promotes the reputation and integrity of the industry and produce products that are in the best interest of client. The idea coercing a client for the gain of profit can be detrimental to the reputation of the industry. It can lead to mistrust with the public and most importantly result in unwanted legal attention and repercussions.
Thursday, October 27, 2016
HW20: Chapter 19
(19.3) Why is it impossible to infer the emergent properties of a complex system from the properties of its components?
A system, especially one that is complex, is composed of many intricate parts known as components, that can be composed of trivial properties on broad level. But its specific purpose as an complete unit is non-trival from a birds-eye perspective. It is equivalent to disassembling a machine designed for a specific purpose down to its nuts, bolts, and screws (and whatever is leftover), then asking someone what is the purpose of those screws. The person can identify the nuts, screws, and other individual items (which we will call properties of the components), and infer its purpose, but in no sense will that person be able to determine what the overall functionality of the parts as a complete unit.Monday, October 24, 2016
HW19: Team Progress I
Our team was working on an open source project based on the popular Pokemon game. The app itself allows users to generate the location and the duration of Pokemon in areas that they designated. The users would see the spawn locations on a map where they could further specify other credentials such the type of Pokemon they wish to generate on the map. After a few days of work and many dependencies and file configurations later we were able get the app to successively run. The next task was to identify test cases and test them within a driver. While working on this phase we noticed that the base of our project had been pulled from public use. After researching the issue we found that the developers had blocked scanning apps such as the PokemonGo Map from accessing its servers thus rendering the app useable. We are now searching for another open source project, one that will not be at risk of being banned or blocked.
Wednesday, October 12, 2016
HW18: Chapter 18
(18.4) Define an interface specification for the Currency Converter and Check credit rating services shown in Figure 18.7.
HW17: Chapter 16
(16.9) Design the interfaces of components that might be used in a system for an emergency control room. You should design interfaces for a call-logging component that records calls made, and a vehicle discovery component that, given a post code (zip code) and an incident type, finds the nearest suitable vehicle to be dispatched to the incident.
Sunday, October 2, 2016
HW16: Chapter 9
(9.8) Briefly describe the three main types of software maintenance. Why is it sometimes difficult to distinguish between them?
Fault repairs are the result of coding and or design errors. This type of maintenance corrects bugs and vulnerabilities in different components of a program.
Environmental adaptation is a type of maintenance needed when components of the a programs support system is modified. These support components are those such as the operating system and system hardware.
Functional addition is the type of maintenance that adds new features to a system in order to support new requirements and buisness needs.
Fault repairs are the result of coding and or design errors. This type of maintenance corrects bugs and vulnerabilities in different components of a program.
Environmental adaptation is a type of maintenance needed when components of the a programs support system is modified. These support components are those such as the operating system and system hardware.
Functional addition is the type of maintenance that adds new features to a system in order to support new requirements and buisness needs.
The three types of software maintenance are fault repairs, environmental adaptation, and functionality addition. It is difficult to distinguish between them because interpretation into what one of the types encompasses can overlap and be integrated into one of the other two maintenance types when functionality is added.
(9.10) Do software engineers have a professional responsibility to develop code that can be easily maintained even if their employer does not explicitly request it?
Maintainability refers to the specifications that increase readability, availability, and reliability. Designing maintainable software with readable code is an ethical responsibility for programmers that must be upheld because it can negatively affect readability and reliability. Software engineering as an industry is progressively growing and being incorporated into critical systems that society has become reliant on. Writing readable code in these type systems (critical systems) greatly aid in availability and reliability. Having readable code aids in easier troubleshooting and code updates. If a fault presents itself during runtime of program, and its code is unreadable, programmers may struggle to correct bug in a timely manner, thus decreasing the systems availability. Also if code is hard to decompose, its statements can be misinterpreted, so when code is updated it may have unwanted side affects in other areas in the program.
Thursday, September 29, 2016
HW15: Chapter 15
(15.10). The rights to intellectual property is a key factor that drives the software industry. When software companies and developers sustainability is reliant upon growth and innovation, having rights to their code becomes a delimiting factor. This is why it is crucial that a company or developer outline specifically either through copyright laws, patents or contracts between them and the client, what themselves or the client rights are in regards to any product, service, or code provided. By doing so eradicates a decent percentage of questions and concerns about who or how ones product can be used. Proceeding in this manner allows for clear definition of how the product, service or code can be monetized and outline any matters regarding capitalization. This is the most ethical approach to intellectual and copyright issues because it provides a detailed agreement between both parties. It also provides security incase of breach of contract. Altogether, by legally stipulating applicability for services, products or code is the most responsible course of action that both parties can take to minimize the violation of ethical issues as it relates to software use and reuse.
Tuesday, September 27, 2016
HW14: Testing Reflections
Regardless of skill level, a programmers goal is to write bug-less code on the first attempt. Is this possible… more than likely not. One may argue that more seasoned programmers should eventually master such a skill, but realistically, even the best programers will have 1 - 3 bugs per 100 lines of code. This statistic emphasis why testing is the most important part of coding.
Validation drives reliability, and the best way to achieve reliability is via testing. Unreliable code is useless and costly, so it is best to eradicate them. Although this is not completely possible we can take measures to drastically decrease the amount faults found in a program. We first start identifying the true purpose of testing. Testing is not a procedure to conclude that a program works, it can only concretely shows us that a program does not work. The laws of probability show us that as testing increases, the probability of finding faults increases. Hence, more testing decreases the chances of showing that a program works.Thus, the purpose of testing has to objectives:
1). to achieve an acceptable a level of reliability.
2). to show that a program has faults.
We then debunk the fallacy that testing and debugging are interchangeable roles. As mentioned previously, the purpose of testing is show reliability and that a program has faults. However, the purpose of debugging to correct bugs that caused a faults in the program.
Last, but not least, we organize how we build test cases and ensure that test cases are testing the specified requirements of the system. It is best to implement test cases in a layered form composed of Unit, Component and Integration test layers. Unit testing is the process of testing small chunks of code at a time. This allows for functional specifications to be tested. Component testing is the testing of one or more aggregated units with subroutines. This shows if the implemented structure does not match the intended design structure. Integration testing is the process of identifying if faults arise from aggregation of components into larger components. System testing is the process of identifying faults that arise from interactions between all the layers of the system. This also includes testing to ensure non-functional requirements are satisfied.
HW13: Chapter 8
(8.7): The ReportTesting system sends a report request to the WeatherStation every hour. The WeatherStation acknowledges the request and sends returns the report to The ReportTesting system. The ReportTesting system sends the report to the DataAnalyzer. The DataAnalyzer separates ground and air data into a ground report and air report. The ground report contains the maximum, minimum and average ground temperatures along with a time-stamp. The air report contains the maximum, minimum and average are temperatures along with a time-stamp. The Comparator sends a report requests to SatComms. SatComms sends the report the to the Comparator (the Comparator has a SatComms have identical reports). The DataAnalyzer sends the ground report to GroundAnalyzer and sends the air report to the AirAnalyzer. The DataAnalyzer, AirAnalyzer,and Comparator reports are sent to the BoolReport. The BoolReport compares the maximum, minimum and average ground temperatures in ground report to the Comparator report. The BoolReport report is compares the time-stamp and maximum, minimum and average air temperatures in the air report to the time-stamp and maximum, minimum and average air temperatures in ground report Comparator report. If any time-stamp or temperature from the ground and air report do not match the corresponding values in the Comparator report , the BoolReports sends a Fail message to the ReportTesting system, else it sends True.
(8.10): Testing a system until the budget is exceeded is a poor practice. This approach cannot promise a reliable system because there may not be a dedicated plan to ensure that requirements of the system are adequately tested. This is not an ethical approach to designing a system because it shorts the customer. Upon delivery the system, it still may have unidentified security vulnerabilities as well as missing requirements that cause the system to fail in a non-graceful manner.
Wednesday, September 21, 2016
HW12: Mythical Man Month
Programming and all its related tasks are cumbersome. What is even more difficult is finding practical time limits to complete these tasks. There are many factors that play into why, but the biggest just may be the programmers themselves. The industry breeds dreamy designers who yearn to create and design the next best thing that promises to change the world. As great as their aspirations may be, there are realistic constraints that impede upon the completion process (known was scheduling).
Frederick Brooks in “The Mythical Man-month” identifies many of the constraints programmers work against, starting with the programmer. The first and a common mistake novice as well as seasoned programmers make is being overly ambitious. Hype from the thoughts of seeing conceptual ideas come to life, clouds the mind of realistic development expectations as it relates to completion time. Ambitions mask the plain sight intricacies of development, rendering the developer with incomplete and inconsistent ideas which become apparent during implementation.
Who would ever think that being overly ambitious could hinder the completion of a project? Just as baffling would be the idea that by adding more personnel to a project would even further the hinderance of a project. As Brooks explains, more man power does not equate to quicker turn-around-time. Thus, there is not a positive correlation between man power and completion time. This is due to the many perplexities that arise when an high magnitude of programmers work cohesively. One perplexity being that it adds the need for high levels of communication among all members of the project. This in itself is a difficult task to manage, especially when trying to maintain design integrity with intruding ideologies from members attempting to place their own “touch” onto their component of the project. So it is here that we find adding more personnel to a project lengthens scheduling time as opposed to shortening it.
The most unaccounted aspect of the scheduling process is testing. Eager to get the project up and running, programmers more than often drastically underestimate the time needed to properly test their project. According to Brooks, many programmers allocate less than one-half the time actually needed for testing. This false scheduling strains other crucial parts of the project such as costs and design quality. Projects generally have budgets and time constraints, and when those time constraints are exceeded, it yields a hasty design, inefficient testing, and can causes a project to eclipse the budget. Naturally one would think to add more time the schedule, but testing usually occurs in the last phase of the project, and at this point the due date is rapidly approaching.
Brooks suggests that employing a smaller skilled group of programmers work more affectively than having an army of programmers. To achieve a proficient level of production, there must be a balanced ratio between functionality, simplicity, and design integrity. As this is a science continually growing, new ideologies will arise in how-to best obtain the balanced ratio. One way may be the surgical approach, where subtasks are divvied onto a supporting cast of developers, allowing a minimum number of programmers to design and implement the core of the project. But until then, it seems best to keep programmer group sizes to a minimum.
Tuesday, September 20, 2016
HW11: Chapter 6
(6.4) Draw diagrams showing conceptual view and a process view...
- A ticket machine used by passengers at a railway system.
- A computer-controlled video conferencing system that allows video, audio and computer data to be visible to several participants at the same time.
- A robot floor-cleaner that is intended to clean relatively clear spaces... cleaner must be able to sense walls and other obstructions.
Wednesday, September 14, 2016
HW10: Chapter 5
(5.3): ... Using an activity diagram, model the process context... that shows the activities involved in planning a party and the system elements that might be used at each stage. |
(5.5): Develop a sequence diagram showing the interactions involved when a student registers for a course in a university... |
(5.7): Based on your experience with a bank ATM, draw an activity diagram that models the data processing involved when a customer withdraws cash from the machine. |
(5.8): Draw a sequence diagram fro the same system. Explain why you might want to develop both activity and sequence diagrams when modeling the behavior of a system. A Sequence diagram shows in better detail the interactions between actors and the objects in a system. This also includes interactions between differing objects. An Activity diagram better shows the individual activities involved in a system. Together, Sequence and Activity diagrams give the designer and potentially the client a clearer perspective of how the system is structured. |
Monday, September 12, 2016
HW9: Reflections
Software design and programming are inherently becoming critical parts of our lives. We have witnessed a steady progression of technological advances in our everyday products that at one-time, had no association to such. Because of this steady progression, we have to ask ourselves what technologies do we have today, that may be radically changed in the near tomorrow. From the “ 9 predictions for the future of programing”, there are 3 distinct trends I see that will continually advance.
“Smartphones will do everything but phone calls”… ? Practically, yes; the advancement of mobile devices is at the pinnacle at what we consider rapid advancement. Just a little over 25 years ago pagers (aka beepers) were the standard for mobile devices, and its main functionality was no more than receiving limited lines of text. Compared to today, our mobile devices can receive and deliver virtually an unlimited amount of messages, access the world wide web, snap and record pictures/videos, download applications, act as a GPS, be used an accelerometer, video conferencing, and finally take and place phone calls. This steady line of innovative features packed in small electronic box will continue to grow. The basic feature of making a phone call will not evade the smartphone, but will continue to see a slew of new technologies embedded into it.
Data collection has become a necessity for a lot of applications, businesses, state and federal institutions. The more the data we have, the easier it becomes for us analyze and understand the world around us. It is not by accident that data centers are emerging around every corner. We as society understand with the useful collection of information about our surroundings, we will be better equipped to handle tasks in a safe and efficient manner. Collected data that can be used in a relational type database can improve in how we live and go about our daily lives. Such databases can easily identify current and potential problems, virtually store unlimited information, and identify trends that we may have otherwise overlooked. Information is power, and the more power we have, the less complicated our everyday lives become. Thus, databases will continue to soar and become an intermediary feature that sets apart one technology from the other.
It is no secret technology is all around us. As so, it only makes sense to try to understand it. I believe one who understands his environment is one who will have a significant better chance of thriving. Likewise, our legislators and educators seem to have embraced this approach. We are now seeing programming courses being offered and taught to our youth. Wether offered as apart of a school curriculum, elective or via summer camps, there is a heightened effort to acquaint our youth with programming concepts and technologies. As a result, at some point the majority of the population will have some type of programming experience. Unfortunately this does not equate to the majority of the population writing “real code”. Programming can be stressful, aggravating, and time-consuming. With technology continually advancing, it will require coders to be self-teachable. All of this combined, I only see a small portion of the population willing to take on these challenges.
The trends outlined here will continue to grow. It benefits both the end-users and the industry. Within time the advancements will become self-evident, however, for these trends to continually trend upward, there has to be a steady base of talented individuals willing to take on the associated challenges. Wisely enough we are preparing for that by familiarizing the youth to the different realms of programming.
HW8: Chapter 2
(2.1) Suggest the most appropriate generic software process model hat might be used as a basis for managing the development of the following systems...
A system to control antilock braking in a car:
Waterfall model; an antilock braking control system is a critical embedded software system that intertwines software with hardware that is apart of a broader system. These aspects makes it crucial for it to be modeled by the Waterfall process.
A virtual reality system to support software maintenance:
Waterfall model; this system will require regular maintenance and updates. The Waterfall model highlights maintenance as its longest life-cycle phase, thus making it an ideal software process for this system.
Waterfall model; this system will require regular maintenance and updates. The Waterfall model highlights maintenance as its longest life-cycle phase, thus making it an ideal software process for this system.
A university accounting system that replaces an existing system:
Integration and configuration; this approach relies on the reuse of some components from a predecessor. With an intricate university accounting system, there are more than likely multiple components from the predecessor system that will be recycled and reused in the newer system. Also, this system is a stand alone application with a very defined role. Having these features makes it a primary candidate for the Integration and Configuration process.
Integration and configuration; this approach relies on the reuse of some components from a predecessor. With an intricate university accounting system, there are more than likely multiple components from the predecessor system that will be recycled and reused in the newer system. Also, this system is a stand alone application with a very defined role. Having these features makes it a primary candidate for the Integration and Configuration process.
An interactive travel planning system that helps users plan journeys with the lowest environmental impact:
Incremental; this type of system will depend heavily upon its users. As such, the developers will need to consistently get feedback from users while developing the system. The Incremenatal approach will allow for this because of it allows user input at every relative stage of the process. Thus, designers can make changes as needed without a large amount of back tracking.
Incremental; this type of system will depend heavily upon its users. As such, the developers will need to consistently get feedback from users while developing the system. The Incremenatal approach will allow for this because of it allows user input at every relative stage of the process. Thus, designers can make changes as needed without a large amount of back tracking.
Wednesday, September 7, 2016
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.
Tuesday, September 6, 2016
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
Monday, September 5, 2016
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.
Wednesday, August 31, 2016
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:
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' .
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.
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' .
Monday, August 29, 2016
HW3: Chapter 10
(10.6)
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.
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.
“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.
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.
Friday, August 26, 2016
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.
HW1: Chapter 1
(1.3) What are the four important attributes that all professional software should possess? Suggest four other attributes that may sometimes be significant.
All professional software should encompass the attributes of dependability, maintainability, acceptability, and efficiency. Other attributes that have proven to be important are acceptable levels of security, good documentation, availability and compatibility.
(1.8) Discuss whether professional engineers should be licensed in the same way as doctors or lawyers?
Licensing professional engineers should be dependent upon the area of application. Those engineers who design products that have the potential to directly harm or negatively affect the well-being of the user(s) should have some type of certification deeming them fit to design said product. These types of products may be found in the healthcare or finical industries.
(1.9) For each of the clauses in the ACM/IEEE Code of Ethics, propose an appropriate example that illustrates that clause.
Public: A developers designs their product(s) to satisfy a need(s) of its users and community.
Client and Employer: The developer does not use propriety information for purposed of self-benefit not to intentionally harm the client or employer.
Product: The Developer takes all necessary precautions to ensure all standard have been meet before releasing the product.
Judgement: The Developer cites and references any original code that is not theirs.
Management: A development team leader manages and directs his team in manner that does not defy any regulations or the proper practice of producing a sustainable product.
Profession: A developer promotes and works in fashion that aims to advance and grow the profession in an ethical manner that is acceptable by users and other members of the field
Colleagues: A developer is patient with his colleagues and makes honest attempts to give an assisting hand when needed.
Self: A developer continues to grow their skill-set by learning and mastering new and unfamiliar technologies with the intention of solving communal problems or improving technologies that already exists.
(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.
Developing such a system requires a detailed plan that outlines specifically how and when the program is used and monitored. This is needed to ensure that the government or any of its developers or users are not violating or abusing the powers of the program by infringing on the basic privacy rights of its citizens. The objective of the government is to provide safety and security to its citizens and this may be accomplished by a monitoring program. However, it is impertinent that the developers/users of his system have a strong ethic compass and that they act responsibly and in concordance with the guidelines detailed in an "use plan". If one was not to act in a way that satisfied set guidelines it could very well negatively affect citizens by making them feel violated and restrained.
Subscribe to:
Posts (Atom)