Posts

Showing posts from November, 2019

HW27:Chapter 25

25.10. Describe five factors that engineers should take into account during the process of building a release of a large software system. Competition - Having an understanding of where the competition is in their release process and what features they may be looking to implement could have a significant impact on how and when to release a software system. If a competitor releases a similar product with more functionality before you, it will have an impact on how your release is received. Marketing Requirements - Similar to the considerations for competition, marketing has an impact on how and when something is released. If consumers desire specific features and the current software is unable to deliver these it may be prudent to delay the release, depending on the competition's ability to deliver their product. Platform - The platform the users are likely to use the software on is important to the release. For example, if the software was designed for release on Windows, but...

HW26:Chapter 24

24.6. Explain why program inspections are an effective technique for discovering errors in a program. what types of errors are unlikely to be discovered through inspections? Program inspections are essentially peer reviews of code that take place during development. Teams collaborate and walk through code line-by-line in search of bugs, exceptions, erroneous conditions, in house compliance issues, as well as things the team deems worthy to discuss. They are considered good practice because they bring together a diverse set of engineers to review the code and it can also help create a company culture that understands the importance of acknowledging errors and moving forward to improving. Sommerville states that during program inspections, there is broad use of checklists to help guide the process. These checklists are typically language-based and cover a wide range of common errors found in the past. This could lead to a reliance on such lists and overlook some more technical issue...

HW25:Team Progress II

Team Progress II The team has started significant work on the final paper and poster. We have a rough draft of each that will require some editing but by and large the bulk of the work is finished. That isn't to say there isn't work to do still. In the past week, we worked on polishing and commenting on the script to clarify how it operates and why it operates in a specific manner. The time I've been spending on bash has been surprisingly enjoyable. I enjoy its simplicity and its power at manipulating files and text. The script was also modified to compile all of the driver files at once to speed up the testing process. This may not be ideal if the user was going to create new test files as they would need to modify the current script to compile properly. Previously the script would handle any additional drivers but the way it was accomplishing this caused the script to run significantly longer. Another thing that needed some work was the HTML document we have displayi...

HW24: Chapter 23

Image
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. The picture above is a Gantt chart with the task T5  taking 40 days instead of 10.  After reviewing the data, there doesn't seem to be a way to improve upon the current ordering. With only T10 being directly dependent on T5 but also dependent on T9 and therefore T6 which in turn is dependent on T3 and T4, the change of T5 from 10 to 40 has no negative impact. This all assumes that there were adequate personnel for each task as they became available and that T5 started at day 1 originally.

HW23: Chapter 22

22.6. Fixed-price contracts, where the contractor bids a fixed price to complete 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 primary way this type of contract could increase risk arises because if the contractor is motivated primarily by profits they may find certain risks more acceptable to increase their profit margin. This is due to the fact that often the methods to mitigate risks come at increased cost thereby decreasing the profit made by the contractor. For example, if the project manager identifies a deficiency in the number of personnel with a certain skillset the plan to mitigate this risk may be to hire another engineer with similar skills. The contractor may see this risk, but also know that hiring an additional engineer comes at a significant cost and decreases the profit of the p...