Software Engineering for Students-

4th Edition
Chapter 4
Software Management-
Team-working
Lecturer : Eng-Moha Ali
[email protected]

Somaville University
2023
 Chapter Objectives
• The principles behind team working
• How functional teams and project teams
operate
• How the chief programmer team
operates.
• Summary of chapter

2
4.1. Introduction
• Software developers seldom work alone.
More commonly, several developers share an
office, working on different projects or
collaborating on larger projects.
• The process of establishing requirements
usually involves significant face-to-face
meetings.
• So software development is essentially a
social activity.
• This chapter is about structures that are
formally set up to organize a team or groupof
software developers. 3
4.1. Introduction
• We begin by analyzing some of the
problems of group work. We go on
to explain
• techniques for software team
organization – functional teams,
project teams, chief programmer
teams and OO teams.

4
 4.2. The principles of teams
• Two major aspects of team activity are:
1. The communication between the
people in the team
2. Deciding who does what work.
a. Define the job description
b. Allocate for each person
c . Organize the documents
d. Submit or send to whom it may
concerns
5
4.2.1 The
communication
• When two or more people are working on
problem
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.
6
4.2.1.The communication
problem
• 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. 7
4.2.2. The division
of •labor
The second major question in team
organization is deciding how to break
down the large task into smaller tasks so
that several people can carry them out.
• Developers carry out a whole variety of
tasks, some of which, like design, are
challenging and others, like keying
corrections or filing listings, are less
demanding.
• One way of dividing the work of software
development amongst a set of people is
to expect everyone to do a mix of tasks.. 8
4.2.2. The division of
labor
• Another approach is to separate out
tasks that require different degrees of
skill so that, for example, one person
does all the design and another all the
keying in of test data.
• This principle of the division of labor
has long been recognized

9
4.2.2. The division of
labor

Figure 5.1 Skill requirements at each stage of a project

10
4.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.
11
4.3. The functional 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.12
 4.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.
13
 4.4. The project team
• 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.

.
14
 4.4. The project team
• 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.

15
 4.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:-
1. To divide the work amongst skilled
specialists.
2. To structure the team in a well-defined
way so that each individual’s role is clear
and communication is minimized.
16
4.5.1. Chief
•programmer
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 17
4.5.1.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.. 18
 4.3.2. Chief programmer
• 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.
19
 4.3.3. 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. 20
4.4.4.Librarian
• The librarian maintains the
documentation associated with
the project by giving training
courses for applying computerized
system.
• An example , he or she may be a
secretary with some training in
using a computer system.

21
 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.

22
 Other specialist
•
programmers
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. 23
Other specialist programmers
• There can be no doubt that the technique of
the chief programmer team represents a
creative application of scientific
management to team programming.
• The benefits of the chief programmer team
to the organization are thus:-
1. Improved programmer productivity
because
• less time is spent in communication.
• Each programmer is carrying out specialized
work at which they are highly skilled.
24
 Other specialist programmers
2. Improved software quality because
a.The team is organized around a highly
skilled programmer
b. The interfaces between software
components are clearer
c. fewer bugs arise from communication
problems because there are fewer
programmers
3. Meeting deadlines more reliably because
a. There is greater visibility of the project through
the high technical involvement of the chief
programmer. 25
 4.6. The object-oriented
team
• Object-oriented development tries to
achieve two objectives:
1. Reuse of existing components from either
the standard library or the in-house library
2. The creation of new reusable
components for the in-house library.
• Thus, organizations using the object-
oriented paradigm have found it desirable
to divide their personnel into teams of
application programmers on the one hand,
and teams of class or component
programmers on the other. 26
4.7. Discussion
• The chief programmer team is hierarchical
and tree-structured. Its organizational
structure tends to produce software that has
a matching structure.
• This may be completely appropriate for
certain types of software. Indeed, much
software is hierarchical in structure.
• Generalizing, it can be hypothesized that
teams tend to produce software whose
structure matches their own structure.
Suppose, for example, that some software is
designed by a committee, acting
democratically. 27
4.7. Discussion
• What would the structure of the software look
like? Perhaps it would be complex, with many
interactions (reflecting the many interactions
between its designers) or perhaps it would
display haphazard structure, without the
single clear vision provided by a charismatic
leader.
• But for certain types of software – for
example, expert systems – these structures
might be completely appropriate. Thus it may
be that different forms of organization are
appropriate for different types of software
project.
28
 Chapter Summary
 The principles behind the chief
programmer team organization are:-
1. To divide the work amongst skilled
specialists.
2. To structure the team in a well-defined
way so that each individual’s role is
clear and communication is minimized.
 An objected-oriented team tries to
develop reusable software for the
current and future projects.
29
 Chapter Summary
• The project manager is usually a member
of the team, and in control of the team.
• A project team develops a single project
while a functional team does specialized
work for a number of projects.
• The team therefore usually consists of
people who carry out all the work of the
development requirements analysis,
programming, testing and so on.
• In a project team, everyone in the team is
engaged on developing the same system.
30
 Chapter Summary
• The chief programmer team is a project-
based organization in which specialization
is implemented in an extreme form.
• The chief programmer team is
hierarchical and tree-structured.
• The benefits of the chief programmer
team to the organization
1. Improved programmer productivity
2. Improved software quality
3. Meeting deadlines more reliably
31
Chapter Summary
• A major problem of functional teams is
that the people who are working on a
single project are not a cohesive team.
• In the functional team organization, all
the members of the team carry out the
same type of work.
• The librarian maintains the
documentation associated with the
project by giving training course for
applying computerized system.

32
Chapter 4 complete

33