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.

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. 

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.

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. 

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. 

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.