24.6. Explain why program inspections are an effective technique for discovering errors in a program. What types of error are unlikely to be discovered through inspections?

The first thing that comes to mind is that when coding, an engineer can get tunnel vision to what his code is doing. When this happens it can be difficult to step back and actually look at your system fully. This causes issues when testing your framework as you might not see a blatant error that someone new to the project would pick up on very quickly. However, with program inspections debugging can become simpler and the upkeep time required to maintain the program can also be drastically reduced. Errors that a program inspector could miss include misunderstanding the requirements need for any specific function or method to run. This of course can lead to many errors going by unnoticed if the either the documentation is poor or the inspector fails to recognize a prerequisite of what is being looked at.

23.6. Figure 23.14 shows the task durations for software project activities. Assume that a serious, unanticipated setback occurs, and instead of taking 10 days, task T5 takes 40 days. Draw up new bar charts showing how the project might be reorganized.

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 contracts may increase the likelihood that product risks will arise.

Fixed price contracts can by putting to much on the developer’s company’s plate. To have a fixed price contract mean one should have thought out the entirety of their system before commencing building. Set backs can happen here if the company starts putting the system together, and realizes they are over budget. its then up to the company to fix their issues on their own dime. Potentially loosing a substantial gain in company profits. Other issues could arise when the company needs to purchase new hardware or anything critical to producing a well working system. This could be massively hindered by the fixed price contract, and could leave engineers working in sub standard conditions. Basically when put in terms of a fixed priced contract any small issue that arises will be a greater issue when constrained by the contract.

21.4. Explain why an object-oriented approach to software development may not be suitable for real-time systems.

Object oriented approaches are not always suitable for real-time systems due to the inherent nature of breaking down the system into smaller pieces. These pieces would then need to communicate with each other which ultimately can lead to hardware usage being maxed and thus slowing down the system as a whole.

20.10 You work for a software company that has developed a system that provides information about consumers and that is used within a SoS by a number of other retail businesses. They pay you for services used. 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.

Employee’s view: From this viewpoint the company’s decisions to pull one over on the customers is highly unethical. As an employed Software Engineer for the company it would raise concerns greatly as the ACM Code of Ethics states that computer engineers should always act in the public’s best interest.

Customer’s view: This is highly unethical from the customer’s standing point. The fact that the price increase is hidden until the customer’s are billed is heavily underhanded. This is egregious and if all the updated interface does was better hide the price gouging then it would seem that is grounds for a lawsuit.

Shareholder’s view: For the shareholder’s this would probably been seen as a positive. They are less likely to care about how this affects the customer as long as they know that most people will stick to what they know and pay the increased price anyways.

19.3. Why is it impossible to infer the emergent properties of a complex system from the properties of the system components?

Emergent properties would be extremely difficult if not impossible to infer due to the nature of what they are. Emergent properties only emerge when you step back, understand all of your code individually and how it interacts with itself and the rest of the code which should be near impossible to predict every interaction of a complex system.

18.4. Define an interface specification for the Currency Converter and Check credit rating services shown in Figure 18.7

public interface currencyConverter {
/**
* @param curCurrency the user’s currently held currency.
* @param echangeCurrency the user’s desired currency to be exchanged too
* @return returns the exchange rate based on the previous two parameters.
*/
public double getExchangeRate(String currentCurrency, String echangeCurrency);

/**
*
* @param Rate the exchange rate found by the getExchangeRate method.
* @param currencyAmount The current amount of currency the user wishes to exchange.
* @return the amount of currency available to the user after conversion.
*/
public double convertCurrency(Double Rate, Double currencyAmount);
}

public interface checkCredit {
/**
*
* @param userCreditInfo Object that stores the user’s credit information
* @return returns the users credit score.
*/
public int getCredit(Object userCreditInfo);
}

17.10. Your company wishes to move from using desktop applications to accessing the same functionality remotely as services. Identify three risks that might arise and suggest how these risks may be reduced.

1. The first problem I see that could arise is that systems can never be 100% bug free, and switching to a new process can lead to an increased error rate. If this was the case a way to increase the chances of success are to implement redundant checks and balances in the system in order to help keep everything on track.
2. The second problem I see is that of safety, and structural integrity. Company and customer information could be intercepted along its path. This problem however could be solved easily, by enforcing strict security and password policies. While also utilizing encryption methods such as https.
3. The last issue could be server load, and decreased speeds based on traffic and distance from the server. If the company is fairly large and spread out to remote places in the world. One would need multiple servers running in order to produce a quality service.

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.

9.8. Briefly describe the three main types of software maintenance. Why is it sometimes difficult to distinguish between them?

Type of software maintenance:

1. Fault repairs: Coding errors are usually relatively cost effective to fix – while design errors are not as they generally involve rewriting fundamental program concepts. Requirement errors are the most expensive to fix due to the entire system needing to potentially be redesigned.
2. Environmental adaptation: This type of maintenance is required when something about the system’s environment has changed. This could be hardware, O.S., or some other software change that must be taken note of an the system must adapt to in order to keep moving forward.
3. Functionality addition: This type of maintenance is necessary when the system requirements change in response to organizational or business change. The scale of the changes required for this mode of maintenance is often much larger than the previous two modes.

It is difficult to differentiate between these 3 types of maintenance due to it not always being clear which type of problem you are dealing with.

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?

Absolutely. As a software engineer one of your duties is to produce products of the highest quality possible. This is massively helpful as to reduce the amount of time and therefore money required to maintain the code in the future.