1 / 17

Study Problem Solutions

Study Problem Solutions. CSCI 6231 Mid Term. Chapter 1. 1.1: Postdelivery maintenance will cost about 3 times as much as the original develop­ment, that is, about $1,275,000.

tchan
Download Presentation

Study Problem Solutions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Study Problem Solutions CSCI 6231 Mid Term

  2. Chapter 1 1.1: Postdelivery maintenance will cost about 3 times as much as the original develop­ment, that is, about $1,275,000. 1.2: No. Temporally defined maintenance is a subset of operationally defined mainte­nance. That is, all changes to a software product constitute operational mainte­nance, but only those performed after installation constitute temporal maintenance. 1.3: Try to find a solution using off-the-shelf software (packages). If this fails, deter­mine which of the constraints (time, cost, functionality) can be relaxed, and pro­vide a solu­tion that fits the remaining constraints. If this fails, do not make promises that cannot be kept, but rather provide data such as hardware invoices and software development schedules showing the unreasonableness of the total request.

  3. Chapter 1 Continued 1.4: Acceptance criteria must be stipulated in the contract, as must a full list of deliv­er­ables. Clauses should include: software shall meet specifications, be delivered on time, within budget; all faults shall be corrected at no further charge for a period of one year, say, after acceptance of product; documentation shall be full and complete, and shall in­clude source code, specifications, design, and operating instructions; training shall be pro­vided (stipu­late type and duration). Terms of the maintenance contract should be inclu­ded. You might try to include a clause holding the developer responsible for dam­ages caused by faults in the software.

  4. Chapter 1 Continued 1.5: Late delivery: Underestimation of size of product; failure to obtain complete and accu­rate requirements; poor planning; failure to specify the product correctly; poor man­age­ment techniques; failure to detect faults early in the life cycle; ineffec­tive or badly trained per­son­nel; poor quality testing; personnel turn­over; poor documentation of the develop­ment process; poor communication between members of the development team; continual hard­ware and/or system software failures.  Project over budget: All of the above, plus unexpected price increases for hard­ware, pro­gramming tools, and so on. Product does not meet specifications: All of the above, plus poor quality specifica­tions; poor testing; poor quality assurance. Operational faults, such as injuries to sailors firing the missiles: Poor testing, and hence residual faults; poor quality docu­mentation. Inadequate documentation: Badly trained personnel; poor management.

  5. Chapter 1 Continued 1.6: $136. From Figure 1.6 of Object-Oriented Software Engi­neering, the ratio of cost of detecting and correcting a fault during postdelivery mainte­nance to the cost of detecting and correct­ing it during the analysis phase is 368 to 3 (approximately 123 to 1).

  6. Chapter 2 2.3: Because of Miller’s Law we cannot develop a software product in a single step, and there­fore we need to use stepwise refinement. 2.4: Incrementation.

  7. Chapter 2 Continued 2.8: Experience and skills of the development team; computer literacy of the client; extent to which the client seems to appreciate his or her real needs. 2.9: The product may not be what the client really needs, so construct a rapid prototype. The design may not permit future development as the corporation grows or changes the way it does business, so ensure that the design is as open-ended as is rea­sonable. There may be cost and or time overruns, so estimate carefully (see Chapter 9). The users may not be comfortable with the product, so a rapid proto­type of the user inter­face is needed; also, involve the purchasing clerks, factory supervisors, sales clerks, and so on, in the devel­opment loop. A competitor may produce off-the-shelf software before the product has been delivered — there is no ethical way to resolve this risk. A critical member of the development team may leave, so keep man­agement of the devel­opment organization abreast of major deci­sions being made, thereby making it easier to inte­grate a replace­ment into the team. The development team may not be properly man­aged, so ensure that man­agers are compe­tent and well-trained.

  8. Chapter 9 9.3: From Figure 9.2 of Object-Oriented and Classical Software Engineering, Seventh Edi­tion, UFP = 7 x 3 + 2 x 4 + 10 x 6 + 56 x 5 + 8 x 3 + 12 x 10 + 17 x 10 = 683

  9. Chapter 9 Continued 9.8: Nominal effort for this organic mode product is 3.2 x 521.05 = 190 person months (i) At $9,900 per person-month, the project costs $1,881,000. (ii) Replacing the staff with team A from Problem 9.7, the cost for the project be­comes (190 x 0.35) x 12,900 = $857,850, or a gain of $1,023,150.

  10. Chapter 9 Continued 9.9: First obtain independent COCOMO and function point estimates as a check. As­sum­ing that the predictions do not change, the next step is to discuss the product with expe­ri­enced software engineers, and ask them to come up with estimates based on their expe­ri­ence (“expert judgment by analogy”). Use their estimates to try to decide whether the COCOMO or function point estimator is more likely to be an accurate predictor of the cost of the product. If this, too, fails, use the function point esti­mate on the grounds that it is generally less damaging in the long run to overesti­mate than to under­estimate cost. Alternatively, the Delphi technique could be used to try to achieve agreement within an accepted tolerance.

  11. Chapter 9 Continued 9.7:Nominal effort (organic mode) = 3.2 x 431.05 = 126 person-months Multiplier for P1 = 1.65 Multiplier for P2 = 0.70 Multiplier for team A = 0.71 x 0.82 x 0.70 x 0.90 x 0.95 = 0.35 Multiplier for team B = 1.46 x 1.29 x 1.42 x 1.21 x 1.14 = 3.69 (i)If team A develops P1, total effort = 126 x 1.65 x 0.35 = 73 person-months. If team B develops P2, total effort = 126 x 0.70 x 3.69 = 325 person-months. Total = 398 person-months (ii)If team B develops P1, total effort = 126 x 1.65 x 3.69 = 767 person-months. If team A develops P2, total effort =126 x 0.70 x 0.35 = 31 person-months. Total = 798 person-months. (iii)Assignment (i) makes more sense, and is backed by COCOMO predic­tions.

  12. Chapter 4 4.1: Use a (modified) chief programmer team. This is a standard application area, so an ex­perienced chief programmer with a team of two reasonably competent program­mers should do a credible job.

  13. Chapter 4 Continued  4.2: The team should be organized as in Figure 4.6 of Object-Oriented Software Engineering. The difficulty of the problem requires the syn­ergistic ef­fect of group in­teraction at each level, but the scale of the problem and the need for strict controls (military project) require a hierarchy. Regulatory and budget­ary consid­erations require nontechnical management.

  14. Chapter 5 5.11: Build tool:Promotes stepwise refinement by making it easy to perform numerous com­pilations and linkages. Coding tool:Promotes stepwise refinement by making it easy to add, modify, or delete code. Configuration-control tool:Promotes stepwise refinement by making it easy to find the appropriate version of a module or artifact. Data dictionary: Promotes stepwise refinement by allowing the team to add, modify, or delete entries while the product is being developed or maintained. (E-mail: Does not hinder stepwise refinement.) Interface checker: Promotes stepwise refinement by checking interfaces when a module is added, modified, or deleted. Online documentation: Promotes stepwise refinement by allowing the documentation to be modified easily. Operating system front end: Promotes stepwise refinement by making it easy to perform numerous compilations and linkages. Pretty printer: Promotes stepwise refinement by ensuring that the code is readable even after changes have been made.

  15. Chapter 5 Continued Report generator: Promotes stepwise refinement by making it easy to add or modify reports. Screen generator: Promotes stepwise refinement by making it easy to add or modify screens. Source-level debugger: Promotes stepwise refinement by making it easier to find faults after making an addition, modification, or deletion to the software. (Spreadsheet:Does not hinder stepwise refinement.) Structure editor: Promotes stepwise refinement by making it easy to add, modify, or de­lete code. Version-control tool: Promotes stepwise refinement by making it easy to find the appro­priate version of a module or artifact. (Word processor: Does not hinder stepwise refinement.) (World Wide Web browser: Does not hinder stepwise refinement.)

  16. Chapter 6 6.2: If the organization is restructured so that 26 professionals, including five man­agers, are concerned solely with SQA, increased productivity and product quality can be expected. The costs to the company will include reorganization time (two day’s labor, approxi­mately 77 x $825 + 19 x $1,100, or about $84,500) and training time and costs for the five SQA managers (perhaps $75,000). The total cost of under $160,000 should be recouped in a year even if productivity increases by only 3%. 6.10: The proof stands.

  17. Chapter 6 Continued 6.12: An annotated flowchart is shown in Figure 6.1.

More Related