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

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.

Security – In making these applications accessible remotely, there is an added risk of exposure.  There’s an increased chance they can be hacked and sensitive information can be stolen, changed, or leaked. By increasing the budget for security prior to the launch of the remote accessibility, and focusing on ensuring that the application environment is fully secure, this risk can be reduced.

Data Consistency – Since the data will be accessible from anywhere, there needs to be an added level of protection against data discrepancies.  If two people are trying to access the same information at the same time, there need to be systems in place to handle these types of situations.  For example, if a person uses an ATM to withdraw money from their account versus many people drawing money from a company debit card at the same time from their online access, systems need to be able to handle all situations that could arise.  By changing the original system requirements, and updating them to handle this added difficulty, the team can ensure that the added complexity of the application is accounted for.

Increased Difficulty to Access – In order to access the system, a user will have to use the internet, a local area network, or the cloud in some way.  If the user has any issues accessing this requirement, they will also not be able to access the remote application.  To reduce this risk, a team could have active discussions about the best way to accept remote accessibility to their application.  Maybe they could have multiple ways of access, like separate identical databases on the cloud, or physical storages on PC’s in addition to the internet.  By consciously discussing this upfront, this risk may be reduced.

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?

Bug fixing: There are different types of bugs, and some of them or more impactful than others.  It is important to keep up with their maintenance before a product fails in a big way.

Adapting software to new environment’s: Often times, there are changes to a system, whether related to hardware or software, or other necessary components.  It is necessary to modify the system to handle these changes.

Putting new or changed requirements into effect: When requirements change, systems and their code have to be updated to meet the new requirements. Maybe a company wants new features for their software, the requirements are edited, and the development team must put those changes into place however they are able to.

There is definitely overlap between these three types of maintenance. Especially when discussing the second two, maintaining software to adapt to new requirements is engulfed by adapting software to a new environment in a sense. When changes are made, whether due to new requirements or new OS functionality or new hardware integration, bugs are inevitable and have to be maintained along the way. Since there is so much commonality and relation between the three types, they can be difficult to tell apart.

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?

This is a personal question and can be answered based on different scenarios.  I think it is often up to the software engineer to hold themselves accountable for developing code that can be easily maintained.  Although it is not explicitly requested by the employer, it is something to strive for without a doubt.  However, to better explain let’s talk about two cases.

Case 1) Software engineer is working for a small company whose budget is limited.  The number one priority for each project is how fast the project can be completed.

Case 2) Software engineer is working for a large company with a widely known and recognized name.  The number one priority for each project is to uphold the quality of the brand.

In which case should a software engineer be more careful and responsible in regards to developing code that can be easily maintained? Although it was not explicitly requested in either case, the engineer in case 2 is much more inclined to develop more polished, clean, well-documented, and easy-to-maintain code than the engineer in case 1, and for the right reasons. If speed of completion is a top priority and money is tight, the so-called “bells and whistles” become a little less important and need to take a backseat. In any case, a software engineer does have a professional responsibility to develop easy-to-maintain code, however, it is important that they recognize their situation and which ones may demand a bit more attention and detail.