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. Documentation - documentation is the most important factor that needs to be taken into account if a large software system is going to be released. Documentation needs to be readable, explain in detail how the software works together, and should be available for the parties that need to read it (maybe the public, maybe not sometimes?). Without clear documentation, it is hard to figure out any problems that may arise when the software is released. There should just always be documentation, plain and simple.
  2. Fixing previous version errors - a release of software could be the primary release (Version 1) or it could be a later release. Later releases need to ensure that they fix whatever problems, faults, or bugs the previous release version was troubled with.
  3. Dependencies need to be checked - if the dependencies for the new version have been updated or removed entirely, then it is important to be aware of that and make sure the new version runs smoothly.
  4. Hardware - likewise, if new, advanced hardware has come out since the last version, the new release of the software has to be compatible with this hardware and has to be built to run on it, otherwise possible users of the software will find it obsolete since it does not run on their fancy new hardware.
  5. Marketing - new releases must be marketed to the public and newer, better, and with more to them than that of the previous version. There needs to be a reason that the product should be bought instead of users just hanging on to their previous version. Marketing is a great way of convincing customers that it would suit them to buy the newer version instead of sticking with the out-of-date one. If no one is interested in buying the new software, then what was the point of making it?

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 ensure that fresh eyes read over code that could have defects in it. Sometimes it is hard to find errors in your own code if you have spent hours and hours writing it - it really helps to get a second opinion, especially if it is in the context of a program inspection, where the team members know what the code needs to do and there is a moderator who can ensure that criticism is appropriate and unbiased. When programming for a team, it is fair that the team will get to review each others code before the code is put to use - this enables everyone to be a part of the work, and everyone is culpable for any failures. 

I think errors that are unlikely to be discovered through inspections would not be in the functionality of the code itself, but maybe in how that component works with others when the program as a whole is run. This is hard to check until the team's release of the code has been combined with other working parts of the software. But ensuring that the code works as expected in a small capacity will go a long way in getting it to work effectively with the software as a whole.

HW26: Chapter 23

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

HW25: Team Progress II

Team International is making great progress. We met last Monday night to change the look of our HTML page, which will now look like the photo below. We added some lines to the script to make the text color for "Pass" or "Fail" to be green or red, respectively. We have also added in our remaining test cases so we now have 25 total. The next step in the project is to inject faults into the source code and see how it affects our test cases. 

I also plan on making some kind of Pass/Fail count that is displayed either as a pie chart or a bar graph, which I think would make a nice visual. 

Some interesting things we have noticed about Celestia's math library is that they define Pi to a certain precision, which means we have had to recalculate our expected values based on that Pi definition. Celestia also uses exponential notation for numbers that are higher than __e+05, but only for certain methods, such as the circleArea(), sphereArea(), and radToDeg() methods that we have been testing. They do not seem to use it for the square() and cube() methods, which I think it interesting. Also, the square() method fails for large numbers, and we will be looking more closely at why it does this when we do our fault injection phase (and try to fix the failings!). 

I have been looking at Team TBD's code for their HTML and CSS because it seems more advanced than what we have and better organized. So that will be something Team International works on for the next deliverable as well.

Other than that, we are still all working really well together, no complaints! We have a good time when we work together, with lots of joking around and eating and working out problems as one. It's been a great experience this semester and I am very happy to be part of this team.

This is the new look for our html page, which looks cleaner and a bit more cohesive with our Wiki page on Github.

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.

Fixed-price contracts are attractive to potential software development clients because it guarantees them a predetermined budget and also allows for all the risk to be taken up by the contractor. Fixed-price contracts mean that the contractor takes on any extra costs that could incur because of changes in requirements or technology that affect the timeline for the project's completion. While this may be a benefit for the customer, who will have more power to change their mind and project requirements, it is much more likely that product risks will arise because of bad communication, changes in plans, and off-schedule development. And all of these problems will be up to the contractor to take care of, which does not seem like a smart business plan.

The Daitan Group is a software development company and they have a really nice explanation of what a fixed-price contract is and why it is not a practice that they use. They discuss in their blog that they prefer to use Agile development because it "is about recognizing the reality that both market requirements and engineering estimates will change over the life of a project". This system of working incrementally and making payments for steps in the development process benefit both customer and contractor.