This section explains the principles behind team working, how functional and project teams operate and finally how the chief programmer team operates.
Software developers rarely work alone. Rather, they share an office working on different projects and collaborating on larger projects. In the section on “Teams”, we begin by analyzing some of the problems of group work and later explain the techniques for the software team organization: the functional teams, project teams, chief programmer teams and object oriented teams.
Team activities are concerned with:
1) The communication among people in the team
2) Who does what
The above two activities are now discussed.
When two or more people work on a piece of software, they definitely need to cooperate and collaborate. They have to communicate component specifications – component names, component functions, parameter types and so on. Often interfaces are complex, involving detailed file layouts. Also there are queries because of the difficulty of specifying the interfaces accurately.
During the lifetime of a project, a team member leaves, or becomes ill or goes on holiday. Another team member has to sort out the project in their absence. When new
people join the team, they have to be helped to understand what the software is for, what has been done and why the structure is as it is. They take up the time of those who remain while the new team members have to further familiarize themselves with the standards and procedures being used in the project or even learn a new programming language.
Therefore, as more and more people are added to a team, the time taken for prospective communication may never be attained and so they completely hamper the project.
The second major issue in team organization is deciding how to break down a large task among team members. Designers carry out a variety of tasks for instance, designing is very challenging while tasks for instance, keying corrections or filing listings are less demanding. One approach of dividing the software development task among a group of people is to expect that each person does a mix of tasks. Another approach to divide up the task such that the person skilled in designing gets the whole design task while another person skilled in keying corrections gets that task.
Fig. 5.1: Skill Requirements at Each Stage of a Project
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, members of a team are working on different projects. The work of a project is carried out by the people from different teams.
A major problem of functional teams is that people who are working together on a single project are not a cohesive team. They may even be separated working in different offices. Close and easy communication is not possible.
Another problem of functional teams is that the person responsible for a project is not the manager or leader of the people working on his or her project. Therefore, s/ he may not have as much control over them as they would like.
In a project team, everyone is involved in developing at the same time. The team usually consists of people who carry out all of the development work for instance, requirements analysis, programming, testing etc. Initially this kind of team consists of only one person. As requirements engineering gets carried out, the team grows to two or three until it reaches its full bloom during coding and testing. Towards the end of the project, members leave the team until finally the project is completed and the team abandons. The project manager is usually the member of the team and in control of the team.
The drawback of the project team is that it grows stronger and weaker according to the demands of the project. Initially one or two people work on analysis and architectural design. During implementation the numbers reach the maximum. Towards the end, when the system is being put into operation, the numbers minimize.
The principles behind chief programmer team organization are to:
1) divide the work among skilled specialists
2) structure the team in a well-defined way so that each individual’s work is clear and minimum communication occurs.
In the chief programmer team, each member is a highly trained specialist. In this team, the job titles are chief programmer, backup programmer, librarian and other specialist programmers as and when necessary.
The roles of these team members are as follows:
A chief programmer is a highly skilled software engineer who develops the crucial parts of the system. He is actually the designer of the software who specifies all the architectural components of the software. He not only specifies these components but also supervises the integration and testing of the whole system.
A backup programmer’s skill is comparable to the chief programmer. His job is to help the chief programmer with his tasks and act as the chief programmer when he is absent for any reason. In case the chief programmer leaves the team, the backup programmer can easily take over.
A librarian is someone who maintains and manages the documentation associated with the system. S/he usually has some training with a computer system.
As and when necessary, other specialist programmers are brought into the team to work on subsystems as specified by the chief programmer. Each of these programmers are specialized in a particular software area such as, databases, interfacing and graphics.
Thus, the benefits of the chief programmer team to the organization are:
1) much better programmer productivity because
2) improved software quality because
3) meeting deadlines successfully because
Note: Anyone who is a good programmer but does not want to go into management can become a chief programmer.
Object-oriented development tries to achieve two objectives:
1) reuse of existing components from the standard library or in-house (within the organization) library
2) creation of new, reusable components for the in-house library
Thus, organizations oriented towards the object-oriented paradigm divide their personnel into application programmers on one hand, and class or component developers on the other.
The benefits of an object-oriented paradigm can only be realized with the combined efforts of identifying reusable software components and organizing such components within an accessible library. A domain-specific class library becomes a valuable asset of the organization. This is because research has shown that large organizations are able to reduce the amount of new code on their large projects by a factor of 50% through the use of such libraries.
As a result, application programmers can be thought of consumers; they develop application-specific classes but always seek to reuse existing library components. They also have a responsibility to identify useful abstractions that can be migrated from the applications to the library.
Class programmers (or component developers) are thought of as producers; they produce reusable components of general use to the organization. Their job is to polish, generalize, reorganize and enhance library classes. In fact, producing reusable components is more difficult than writing components for a specific project.