cycles. So many defects are discovered that, by the end of the project, the "change control board" or "feature team" may meet as often as every day to prioritize defect corrections. Because of the vast number of defects, the software has to be released with many known (albeit low priority) defects. In the worst case, the software might never reach a level of quality good enough to be released. Alternatively, major defects discovered late in the project can cause the software to be redesigned and rewritten during testing. Since no one planned to rewrite the software during testing, the project deviates so far from its plans that it essentially runs without any planning or control. Defect tracking isn?t set up until late in the project. Some reported defects go unfixed simply because they are forgotten, and the product is released with known defects that could have been fixed easily. Components developed by different developers are not integrated with each other until the end of the project. By the time the components are integrated, the interfaces between components have gotten out of synch, and much work must be done to bring them back into alignment. Source code revision control isn?t established until late in the project, after developers have begun to lose work by accidentally overwriting the master copies of their own or each other?s source code files. Because the project is having schedule trouble, developers are asked to reestimate their remaining work as often as once a week or more,