25.10: Describe five factors that engineers should take into account during the process of building a release of a large software system.

1. Documentation – is the system documented properly and clearly?
2. Quality – is the quality acceptable? if problems arise can they be reported easily and patches issued?
3. Competition – timing is very important as there are probably competitors with similar products, need to be quick to the market with bugs fixed quickly when needed
4. Marketing – new releases need to be marketed properly and quality needs to reflect the product that was marketed
5. Customer Change Proposal – customer will want the changes to have been made and released upon the agreed on date/time, were these changes met properly?

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?

Program inspections are an effective technique because of a few reasons. First, it is difficult for the person writing the code to see their own errors. After having looked at the code for so long, errors are easily overlooked. By having a fresh set of eyes look at the code, seemingly working code can have errors found quickly. Also, program inspections are an affordable way to discover errors. The code doesn’t necessarily need to be run, and individual classes or methods can be reviewed apart from the full program.

Errors that are unlikely to be discovered are probably related to full program interaction rather than individual classes. Although the code looks good in classes/methods when viewed separately, when they are all put together and compiled and ran, errors can show up.

We’ve updated our test cases to include all 25 test cases. We are happy with our progress thus far as a team. We’ve nearly completed our poster and presentation and need to work on practicing the presentation as well as completing the final document.  All in all, we are very satisfied with our current state and hope to finish strong as the end of the semester nears.

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.

The contractor won’t want to pay for something that goes wrong, but they have to. This could cause them to use a less detailed product and push less than perfect code, although a working product, so that they can save money in labor for the time when something might go wrong.  If they limit their own expenses upfront, they can have a budget for when things go wrong later.

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

Object oriented adds an extra layer of complexity thats not necessarily suitable for real time systems. Also, since it can take extra time to call all of the different methods and instantiate different objects, the overall timing of the program/software can suffer.

I feel good about our team progress as of Deliverable #3. Our bash script and drivers seem to be working properly. Our html is generated and is readable.  We need to continue to improve the output detail and formatting, but in general, are in a good place with the project. The teamwork has been comforting, as each of our team members seem to be more than capable and doing their own part where and when needed. Overall, very satisfied with the project and progress thus far.

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

This is a poor move from all points of view.  From the company’s employees, it may look to them as an attempt to pull a fast one, so to speak, on the users and they may lose faith and trust in the company. From the point of view of the customers, they are now having to pay a higher charge without being notified which is simply unjust. For the shareholders, they will be disappointed in such a move, which can clearly cause issue with both the users, the company’s employees, and all other retail businesses that are using the system as well. It is a major mistake that could cause more backlash than may have been anticipated at the time of launching the changes to the system.

The only way that I can see this could be defendable, is if there are terms of the system that is being changed. If there is a contract that discusses the changes that are allowed to be made, and the scope of the this specific software company, they may be able to make these changes. If this is the case, and there is a document, in writing, that allows for these changes to be made, then there is no issues at hand.

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

The emergent properties are defined as “properties of the system as a whole…[and] cannot be attributed to any specific part of the system. Rather they only emerge once the system components have been integrated” (Sommerville 545).

Because these properties are a result of multiple components and only emerge once functional integration has happened between those components, it is impossible to tell that they will occur from the properties of the individual components alone.  It is rather an issue that “emerges” later from that integration.

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

 Currency Converter

Operation: convert(), exchangeRate()

Input: typeIn(String), typeOut(String), amountIn(double)

Output: amountOut(double), rate(double)

Exception: incorrect typeIn, incorrect typeOut, incorrect amountIn

Check Credit Rating

Operation: checkCredit()

Input: ssNum(integer)

Output: creditScore(integer)

Exception: incorrect ssNum