Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
28.5 The chief programmer team 351 As we shall see, some techniques exploit this principle of the division of labor. How are teams usually organized? There are two common methods of organizing teams involved in software development – functional teams and project teams. 28.3 ● The functional team In the functional team organization, all the members of the team carry out the same type of work, so that there is a team of programmers, a team of analysts, a team of testers, and so on. At any one time, the members of a team are working on different projects; the work of a single project is carried out by people from different teams. A major problem of functional teams is that the people who are working on a single project are not a cohesive team. They may even be physically separated in different offices. Close and easy communication is inhibited. Another problem of the functional team is that the person responsible for a project is not the manager or leader of the people working on his or her project. Thus he or she may not have as much control over them as they would like. 28.4 ● The project team In a project team, everyone in the team is engaged on developing the same system. The team therefore usually consists of people who carry out all the work of the development – requirements analysis, programming, testing and so on. Initially, a team of this kind consists of only a single person. As requirements engineering gets under way, the team grows to two or three people. When the project is fully under way, during coding and testing, it expands to its maximum. Towards the end of the project, members leave the team until finally it is disbanded. The project manager is usually a member of the team, and in control of the team. The drawback of a project team is that its membership waxes and wanes as the demands of the project change. Initially only one or two people may carry out analysis and architectural design. During implementation the numbers grow to full strength. Then, towards the end, when the system is being put into operation, the numbers diminish. 28.5 ● The chief programmer team The chief programmer team is a project-based organization in which specialization is implemented in an extreme form. The principles behind the chief programmer team organization are: ■ to divide the work amongst skilled specialists. ■ to structure the team in a well-defined way so that each individual’s role is clear and communication is minimized.
352 Chapter 28 ■ Teams A chief programmer team is like a surgical team in which the chief surgeon is assisted by an assistant surgeon, an anesthetist, and one or two nurses. Each team member is a highly trained specialist. In the chief programmer team the job titles are chief programmer, back-up programmer, librarian and other specialist programmers as and when necessary. The roles of the team members are as follows Chief programmer This is a highly skilled software engineer who produces the crucial parts of the system. It is usually the designer of the software who determines and specifies the architectural components of the software. The chief programmer specifies all the other components in the system and oversees the integration or system testing of the complete system. The chief programmer’s role is intended to be almost entirely a technical one. To this end, administrative affairs like reporting to management and monitoring budgets and timescales are dealt with by a project manager. This frees the chief programmer from non-technical matters. The project manager is not really part of the team and will usually deal with the administrative aspects of several teams. Back-up programmer This is a programmer whose skill is comparable to that of the chief programmer. The job is to help the chief programmer with his or her tasks and act as the chief programmer when the latter is absent for any reason. Should the chief programmer leave the organization, the back-up programmer can immediately take over. Librarian The librarian maintains the documentation associated with the project. He or she may be a secretary with some training in using a computer system. Other specialist programmers When needed, other programmers are brought into the team to develop any subsystems specified by the chief programmer. Each of these programmers is an expert in a particular software area, such as user interfacing, databases or graphics. The structure of the team is hierarchical, with the chief programmer at the top. In contrast to a network of people each of whom communicates with everyone else, the hierarchy restricts information so that it flows along far fewer paths – only up and down the hierarchy. The use of structured programming (Chapter 7) and top-down implementation and testing (Chapter 24), both of which are hierarchical, complement this scheme very neatly. There can be no doubt that the technique of the chief programmer team represents a creative application of scientific management to team programming.
- Page 324 and 325: 22.4 ● Discussion Exercises 301 A
- Page 326 and 327: CHAPTER 23 Prototyping This chapter
- Page 328 and 329: Therefore, in summary: ■ the prod
- Page 330 and 331: 23.5 Evolutionary prototyping 307 U
- Page 332 and 333: Reuse components 23.6 Rapid prototy
- Page 334 and 335: Pitfalls For users, the problems of
- Page 336 and 337: Answers to self-test questions 313
- Page 338 and 339: 24.2 ● Big-bang implementation 24
- Page 340 and 341: Tested component Figure 24.1 Top-do
- Page 342 and 343: 24.7 ● Use case driven implementa
- Page 344 and 345: ■ middle-out ■ use case based.
- Page 346 and 347: SELF-TEST QUESTION 25.1 What is the
- Page 348 and 349: sharing of software or their own re
- Page 350 and 351: Summary 327 Inappropriate patches,
- Page 352 and 353: Further reading 329 Cathedral and t
- Page 354 and 355: These are qualified by the statemen
- Page 356 and 357: 26.3 Extreme programming 333 develo
- Page 358 and 359: SELF-TEST QUESTION 26.3 Which of th
- Page 360 and 361: CHAPTER 27 This chapter explains:
- Page 362 and 363: Figure 27.1 The phases of the unifi
- Page 364 and 365: 27.5 ● Iteration 27.6 Case study
- Page 366 and 367: The transition phase Summary 343 Th
- Page 368: PART F PROJECT MANAGEMENT
- Page 371 and 372: 348 Chapter 28 ■ Teams The commun
- Page 373: 350 Chapter 28 ■ Teams Level of s
- Page 377 and 378: 354 Chapter 28 ■ Teams benefits o
- Page 379 and 380: 356 Chapter 28 ■ Teams • Furthe
- Page 381 and 382: 358 Chapter 29 ■ Software metrics
- Page 383 and 384: 360 Chapter 29 ■ Software metrics
- Page 385 and 386: 362 Chapter 29 ■ Software metrics
- Page 387 and 388: 364 Chapter 29 ■ Software metrics
- Page 389 and 390: 366 Chapter 29 ■ Software metrics
- Page 391 and 392: 368 Chapter 29 ■ Software metrics
- Page 393 and 394: CHAPTER 30 This chapter: 30.1 ● I
- Page 395 and 396: 372 Chapter 30 ■ Project manageme
- Page 397 and 398: 374 Chapter 30 ■ Project manageme
- Page 399 and 400: 376 Chapter 30 ■ Project manageme
- Page 401 and 402: 378 Chapter 30 ■ Project manageme
- Page 403 and 404: 380 Chapter 30 ■ Project manageme
- Page 405 and 406: 382 Chapter 30 ■ Project manageme
- Page 408 and 409: CHAPTER 31 This chapter: 31.1 ● I
- Page 410 and 411: 31.3 Case study - assessing verific
- Page 412 and 413: 31.5 A single development method? 3
- Page 414 and 415: Further reading 391 31.2 Draw up a
- Page 416 and 417: 32.3 ● The world of programming l
- Page 418 and 419: 32.5 ● The real world of software
- Page 420 and 421: 32.6 Control versus skill 397 Final
- Page 422 and 423: Formal methods 32.7 Future methods
28.5 The chief programmer team 351<br />
As we shall see, some techniques exploit this principle of the division of labor.<br />
How are teams usually organized? There are two common methods of organizing<br />
teams involved in software development – functional teams and project teams.<br />
28.3 ● The functional team<br />
In the functional team organization, all the members of the team carry out the same<br />
type of work, so that there is a team of programmers, a team of analysts, a team of<br />
testers, and so on. At any one time, the members of a team are working on different<br />
projects; the work of a single project is carried out by people from different teams.<br />
A major problem of functional teams is that the people who are working on a single<br />
project are not a cohesive team. They may even be physically separated in different<br />
offices. Close and easy communication is inhibited.<br />
Another problem of the functional team is that the person responsible <strong>for</strong> a project<br />
is not the manager or leader of the people working on his or her project. Thus he or<br />
she may not have as much control over them as they would like.<br />
28.4 ● The project team<br />
In a project team, everyone in the team is engaged on developing the same system.<br />
The team there<strong>for</strong>e usually consists of people who carry out all the work of the<br />
development – requirements analysis, programming, testing and so on. Initially, a<br />
team of this kind consists of only a single person. As requirements engineering gets<br />
under way, the team grows to two or three people. When the project is fully under<br />
way, during coding and testing, it expands to its maximum. Towards the end of the<br />
project, members leave the team until finally it is disbanded. The project manager is<br />
usually a member of the team, and in control of the team.<br />
The drawback of a project team is that its membership waxes and wanes as the<br />
demands of the project change. Initially only one or two people may carry out analysis<br />
and architectural design. During implementation the numbers grow to full strength.<br />
Then, towards the end, when the system is being put into operation, the numbers<br />
diminish.<br />
28.5 ● The chief programmer team<br />
The chief programmer team is a project-based organization in which specialization is<br />
implemented in an extreme <strong>for</strong>m. The principles behind the chief programmer team<br />
organization are:<br />
■ to divide the work amongst skilled specialists.<br />
■ to structure the team in a well-defined way so that each individual’s role is clear and<br />
communication is minimized.