170 likes | 192 Vues
This text discusses post-delivery maintenance costs, software solutions, acceptance criteria in contracts, project management challenges, and project estimation techniques in the field of software engineering.
E N D
Study Problem Solutions CSCI 6231 Mid Term
Chapter 1 1.1: Postdelivery maintenance will cost about 3 times as much as the original development, that is, about $1,275,000. 1.2: No. Temporally defined maintenance is a subset of operationally defined maintenance. That is, all changes to a software product constitute operational maintenance, 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, determine which of the constraints (time, cost, functionality) can be relaxed, and provide a solution 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.
Chapter 1 Continued 1.4: Acceptance criteria must be stipulated in the contract, as must a full list of deliverables. 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 include source code, specifications, design, and operating instructions; training shall be provided (stipulate type and duration). Terms of the maintenance contract should be included. You might try to include a clause holding the developer responsible for damages caused by faults in the software.
Chapter 1 Continued 1.5: Late delivery: Underestimation of size of product; failure to obtain complete and accurate requirements; poor planning; failure to specify the product correctly; poor management techniques; failure to detect faults early in the life cycle; ineffective or badly trained personnel; poor quality testing; personnel turnover; poor documentation of the development process; poor communication between members of the development team; continual hardware and/or system software failures. Project over budget: All of the above, plus unexpected price increases for hardware, programming tools, and so on. Product does not meet specifications: All of the above, plus poor quality specifications; poor testing; poor quality assurance. Operational faults, such as injuries to sailors firing the missiles: Poor testing, and hence residual faults; poor quality documentation. Inadequate documentation: Badly trained personnel; poor management.
Chapter 1 Continued 1.6: $136. From Figure 1.6 of Object-Oriented Software Engineering, the ratio of cost of detecting and correcting a fault during postdelivery maintenance to the cost of detecting and correcting it during the analysis phase is 368 to 3 (approximately 123 to 1).
Chapter 2 2.3: Because of Miller’s Law we cannot develop a software product in a single step, and therefore we need to use stepwise refinement. 2.4: Incrementation.
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 reasonable. 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 prototype of the user interface is needed; also, involve the purchasing clerks, factory supervisors, sales clerks, and so on, in the development 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 management of the development organization abreast of major decisions being made, thereby making it easier to integrate a replacement into the team. The development team may not be properly managed, so ensure that managers are competent and well-trained.
Chapter 9 9.3: From Figure 9.2 of Object-Oriented and Classical Software Engineering, Seventh Edition, UFP = 7 x 3 + 2 x 4 + 10 x 6 + 56 x 5 + 8 x 3 + 12 x 10 + 17 x 10 = 683
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 becomes (190 x 0.35) x 12,900 = $857,850, or a gain of $1,023,150.
Chapter 9 Continued 9.9: First obtain independent COCOMO and function point estimates as a check. Assuming that the predictions do not change, the next step is to discuss the product with experienced software engineers, and ask them to come up with estimates based on their experience (“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 estimate on the grounds that it is generally less damaging in the long run to overestimate than to underestimate cost. Alternatively, the Delphi technique could be used to try to achieve agreement within an accepted tolerance.
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 predictions.
Chapter 4 4.1: Use a (modified) chief programmer team. This is a standard application area, so an experienced chief programmer with a team of two reasonably competent programmers should do a credible job.
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 synergistic effect of group interaction at each level, but the scale of the problem and the need for strict controls (military project) require a hierarchy. Regulatory and budgetary considerations require nontechnical management.
Chapter 5 5.11: Build tool:Promotes stepwise refinement by making it easy to perform numerous compilations 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.
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 delete code. Version-control tool: Promotes stepwise refinement by making it easy to find the appropriate version of a module or artifact. (Word processor: Does not hinder stepwise refinement.) (World Wide Web browser: Does not hinder stepwise refinement.)
Chapter 6 6.2: If the organization is restructured so that 26 professionals, including five managers, 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, approximately 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.
Chapter 6 Continued 6.12: An annotated flowchart is shown in Figure 6.1.