Clemson University

COURSE TITLE-CPSC 3300 Colwell Quiz

Chapter 2:

1)Why was the dual-die approach a potential design mistake?

2. "What constitutes success for this project?" Why is this question important, and what was the answer for the P6?
3. Why did meeting in a storage room help?
4. Why should you keep a record of the "roads not taken"?
5. Explain the acronym DFA. What did the DFA tool do?  
6. Why can't all teams be compared equally?
7. Should you overpromise or overdeliver? What is Colwell's advice?
8. Colwell applies this promise/deliver choice to a microprocessor design task. Does a similar choice apply to predicting schedules for software projects? Explain.

9. How long are typical companies' roadmaps (i.e., planning horizons)?

10. Explain why software vendors look "sideways or backwards".
11. What is likely to happen if management treats team members as "field- replaceable units"?
12. Explain the effect of geographic distance on "us-versus-them" conflicts.
13. Isn't cubicle floorplanning too much micro-management? Explain how it helped to do this kind of planning in the early part of the P6 project. (pp. 39- 40)
14. Explain how Colwell solved the coding standard conflict.  [I think he confuses the functions of Unix commands "indent" and "lint". Both are mentioned in the P6 coding standards document.]

programmers for the P6 project were told to format similar to:

 indent -npro -nip -nfc1 -cli0.5 -c0 -i8

by the way, GNU advises using indent with these options: indent -nbad -bap -nbc -bbo -bl -bli2 -bls -ncdb -nce -cp1 \

-cs -di2 -ndj -nfc1 -nfca -hnl -i2 -ip5 -lp -pcs -psl -nsc -nsob from 1991: