Explanations should take around 40 words. Some slack will be given to 50 or 60 word explanations (however, don't press your luck too many times on this); explanations a page or more long will lose five points.

1. You, as manager of a software development project, are currently developing an estimate of the cost of the testing phase of the project. As soon as you finish the test-phase cost estimate, your test-phase manager tells you they're changing all testing from functional to structural. Explain the changes, if any, you make to your cost estimate for the test phase.

   ---

   A shift from functional to structural testing requires more attention to the internal details of the system, which means an increase in the cost to test the system. In addition, structural testing tends to slight the external behavior of the system under test, which means it may be desirable to add or increase increase the size of the acceptance testing done.

   ---

2. A CoCoMo cost driver attribute is a multiplicative fudge-factor rated on a scale of 1 (very low) to 5 (very high), with a different fudge factor associated with each rating. What would you expect the relation between the very low and very high fudge factors to be for the product complexity cost driver attribute? Explain. What would you expect the relation between the very low and very high fudge factors to be for the programmer capability cost driver attribute? Explain.

   ---

   A very low rating for product complexity indicates a simple product, while a very high rating indicates a complex product. Because simple products usually cost less to build than do complex products, the fudge factor for very low product complexity should be smaller than the fudge factor for very high product complexity.

   A very low rating for programmer capability indicates programmers may have difficulty performing the task at hand, while a very high rating indicates the programmers should be able to perform the task at hand. Because competent programmers cost less to do a job than do incompetent programmers, the fudge factor for very low programmer capability should be larger than the fudge factor for very high programmer capability.

   ---

3. Explain how the cohesion and coupling estimates for a system design could be used to adjust the cost estimates for the phases following design.

   ---

   A system with low cohesion should increase the costs of implementing the system. Low cohesion indicates that otherwise separate functions are packed together into the same module, making the module harder to implement. A system with high cohesion devotes one function per module, which increases the number of modules but makes each module simpler, and, as long as the numbers aren't excessive, simplicity wins out over size. A similar argument can be made for the influence of cohesion on testing.

   A system with high coupling should increase the costs of testing the system. High coupling indicates that a module cannot easily be considered on its own, but must be lumped together with the other modules to which it is coupled. This makes unit and module-level testing harder and less definitive than it would be if the modules had low coupling. A similar argument can be made for the influence of coupling on implementation, but, with the exception of unit testing, the influence of coupling is not as strong as it is in testing.

   ---

4. A couple of your colleagues were telling you that they were able to accurately estimate the cost of the monitor and control portion of their software development project using a linear model. What can you conclude about the structure of their software development process? Explain.

   ---

   It is most likely that their software development process structure was linear, similar to the structure of the software development process used in the project for this course. Other structures - such as a waterfall or a spiral model - incorporate feedback and other forms of interaction between the phases, which makes a linear model a less accurate cost estimator for these structures.

   ---

This page last modified on 30 April 2001.