tailieunhanh - Software Engineering For Students: A Programming Approach Part 38

Software Engineering For Students: A Programming Approach Part 38. This fully revised version of Doug Bell's Software Engineering: A Programming Approach continues to use the successful formula of the previous editions. The author's approach is to present the main principles, techniques and tools used in software engineering, one by one, chapter by chapter. This book is a unique introduction to software engineering for all students of computer science and its related disciplines. It is also ideal for practitioners wishing to remain current with new developments in the area | 348 Chapter 28 Teams The communication problem When two or more people are working on a piece of software they obviously have to liaise with each other. At the very least they have to communicate component specifications -component names component functions parameter types and so on. Often such interfaces are complex perhaps involving detailed file layouts. Always there are queries because of the difficulty of specifying interfaces precisely. During the lifetime of a project someone always leaves is ill or goes on holiday. Someone has to sort out the work in their absence. New people join the team and have to be helped to understand what the software is for what has been done and why the structure is as it is. They may need to learn about the standards and procedures being used on the project or even learn a new programming language. This induction of a new person takes up the time of those who remain. All this adds up to a great deal of time spent in communication that would not be necessary if only a single person were developing the software. Adding two people to a team of four does not increase the communication overhead by half - it more than doubles it. Clearly as more and more people are added to a team the time taken in liaising can completely swamp a project. Compare the activity of picking potatoes. Imagine a large field with a relatively small number of people. They can each get on with the job without getting in each other s way. If we increase the number of people the work will get done proportionately quickly at least until there are so many people that they are tripping each other up. The graph of potatoes picked against people employed looks like Figure . If we now turn to the task of having a baby we realize that increasing the number of people will do nothing to the timescale - it remains nine months. The graph is shown in Figure . Software development comes somewhere between these two extremes. Initially if we increase the number of .