Wednesday, November 29, 2017

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.

Thursday, November 2, 2017

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.