So it is today. Schedule disaster, functional misfits, and system bugs all arise because the left hand doesn’t know what the right hand is doing. As work （）, the several teams slowly change the functions, sizes, and speeds of their own programs, and they explicitly or implicitly （） their assumptions about the inputs available and the uses to be made of the outputs. For example, the implementer of a program-overlaying function may run into problems and reduce speed relying on statistics that show how （） this function will arise in application programs. Meanwhile, back at the ranch, his neighbor may be designing a major part of the supervisor so that it critically depends upon the speed of this function. This change in speed itself becomes a major specification change, and it needs to be proclaimed abroad and weighed from a system point of view. How, then, shall teams （） with one another In as many ways as possible. Informally. Good telephone service and a clear definition of intergroup dependencies will encourage the hundreds of calls upon which common interpretation of written documents depends. Meetings. Regular project meetings, with one team after another giving technical riefings, are （）. Hundreds of minor misunderstandings get smoked out this way. Workbook. A formal project workbook must be started at the beginning.
As work （）, the several teams slowly change the functions, sizes, and speeds of their own programs
A．starts
B．proceeds
C．stops
D．speeds
