HW28: Chapter 25

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

1. Technical quality of the system - If there are already issues with the current release, a quick update should be made to alleviate these issues.
2. Platform Changes - A new version of the system may need to be released when a new operating system is released.
3. Competition - A similar system may be released by a different company with new features that could pull users away from your system.
4. Marketing requirements - Those who market the system may have promised a release date that the engineers have to adhere to.
5. Customer change proposals - customers may request and pay for specific changes they expect to released by a certain date.

HW27: Chapter 24

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 involve running through a list of common errors and looking for them in a system. They are performed by a developer who did not work on the code being inspected. This gives a fresh perspective which will be more likely to find errors. However, program inspections would not be as effective if the developer is using a specific library or algorithm that the inspector may not have as much experience with.

HW26: Team Progress II

Today we present our testing framework for Tanaguru with 25 completed test cases. The main problem with our last version is that the script was static. This means that information about the test cases and the drivers required to run them was hard-coded into our bash script. This was deemed to be problematic since it would be difficult to add test cases in the future. If someone later down the line wanted to add a test case, they would also have to modify our script. Now the script is dynamic. This means that the script is "dumb" and has no information about the test cases or the drivers. Now it is simpler to add test cases. The test cases are added as text files in the correct template. If a new driver is needed, it can be dropped in the drivers folder. This has no effect on the script.

This simple change in our project put some aspects of open source development into perspective. What if someone else wanted to use our framework? If the framework was static, it would require knowledge of bash and our script to add test cases. Now it simply requires the developer to copy the test case template.

HW25: Chapter 23

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

There will be unforeseen setbacks in the development of any software. With a fixed contract, developers might try to cut corners elsewhere to stay within budget in response to issues during development. Fixed price contracts create risk by fixing the budget and resources.

HW22: Chapter 21

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

In a real time system, information will change often. Object oriented programming involves communication of data between objects. In a real time system, the data could be changed during these interactions leading to inconsistencies in the system. It makes more sense to use a process oriented approach.

x

HW19: Team Progress 1

We completed the first iteration of our script with five test cases. Dr. Bowring pointed out that the main problem with our script is that it is too "smart." This means that script has too much hard coded information in it regarding the driver used and the number of test cases. This needs to be changed so that the test cases and drivers can be modified without making any changes to the script. Next we will need to create 20 more test cases. This will not only involve creating more test cases but also selecting new methods to test in Tanguru and the drivers that run them.

HW21: Chapter 20

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.

I believe it is highly immoral to modify the system to coerce more money out of users, especially without notice. It is understandable to change a business model and raise prices. Markets change and software developers should change with the markets too. After all, they're in the industry to make money. If this is done, the users need to know far ahead of the changes. This needs to communicated clearly. Some users may feel using the system is worth paying more money. Others may not and will need time to migrate their data to another system. Making these changes without notice would reflect poorly on the developers and hurt their image in the long run.

HW20: Chapter 19

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

Emergent properties cannot be inferred because they do not exist until there is interaction between the components of the system. Emergent properties include things like security, reliability, and repair ability. These properties cannot be observed until after the components of the complex system interact with each other. 

HW18: Chapter 18

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

Currency Converter:

Operation: convertCeurrency
Inputs:  inputCurrencyType, outputCurrencyType, inputCurrencyAmount
Outputs: exchangeRate, inputCurrencyValue, outputCurrencyValue, fees
Exceptions: Invalid Currency Exception, Invalid Amount Exception

Operation: exchangeRate
Inputs:  inputCurrencyType, outputCurrencyType, inputCurrencyAmount
Outputs: exchangeRate, outputCurrencyAmount
Exceptions: Invalid Currency Exception, Invalid Amount Exception

Operation: currency
Inputs:  inputCurrencyAmount, outputCurrencyType
Outputs: outputCurrencyAmount
Exceptions: Invalid Currency Exception, Invalid Amount Exception


Check Credit:

Operation: creditCheck
Inputs:  ssn, name, birthdate
Outputs: creditScore
Exceptions: Invalid SSN Exception, Invalid Name Exception, Invalid Birthdate Exception

HW17-B: Chapter 17

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. Security: Accessing data remotely opens up your data to all kinds of attacks that were not possible on desktop applications. To combat these attacks, the company needs to make sure they keep their security systems up to date. Employees need to be educated against social engineering attacks as well.

1. Failure Management: Service based systems need to be constantly connected to the internet to accessed remotely. If this connection is interrupted, data will not be able to accessed. The company needs to make sure that connection problems are resolved as quickly as possible.

1. Performance: making the system a service adds another layer of complexity to the system because the data now has to be loaded over an internet connection. The system should be as efficient as possible to make sure that the system performs well enough for the users.

HW17-A: Chatper 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?

1. Fault repairs: Involves simple bug fixes in the software.
2. Environmental adaptation: Involves changing the system so it runs in new environments alongside new software.
3. Functionality addition: Involves adding new features to the system

These can be difficult to distinguish because they are all different forms of making the code better.

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? 

Developers should always try make their code as maintainable as possible. Most good coding habits involve making code well documented and easy to understand. Code should also be thoroughly tested. These practices make the code more maintainable.

HW15: Chapter15

15.10) The reuse of software raises a number of copyright and intellectual property issues. If a customer pays the software contractor to develop a system, who has the right to reuse the developed code? Does the software contractor have the right to use that code as a basis for a generic component? What payment mechanisms might be used to reimburse providers of reusable components? Discuss these issues and other ethical issues associated with the reuse of software.

- To me, the issue of who has the right to reuse the developed code depends on the agreement between the developer and the customer. If the the customer is paying for the code, I believe they have the right to reuse it. If they are paying for the developer's time, I think they have the right to use the system, not reuse the code. I don't like the idea as reusing someone's code as a generic component. If the code is easily accessible, such as on github or stack overflow, it can be used by anyone who sees it.