Transcript RESOURCE MEASUREMENT: PRODUCTIVITY, TEAMS AND TOOLS

RESOURCE MEASUREMENT:
PRODUCTIVITY, TEAMS AND
TOOLS
The meaning of productivity
• In Economics, productivity is defined in straightforward
way:
“The rate of output per unit of input used especially in
measuring capital growth, and in assessing the effective
use of labour, materials and equipment”
• Often in software engineering productivity is defined as
size per effort (the productivity equation).
• Size usually measured as lines of code (can be any size
measure) and effort is measured in person days or
person months
Problems arise from the
productivity equation
• How to measure effort?
• Days can be of different lengths and all efforts may not be included.
• Only views output in terms of size – the value of output is ignored
• Other concerns – by considering output solely in terms of the
number of components produced – this view treats software
development to be much like any traditional manufacturing process
• Example automobile manufacture - the primary focus of the
implementation process is replication: building many copies of the
same item.
• But, there is usually little or no replication in software development
Productivity of what?
• We should therefore distinguish the productivity of the process from
the productivity of the resources (people).
• In order not to get the negative effects to be expected when
measuring people, we should rely on a goal-driven approach to
measurement, and make clear the likely benefits to all concerned.
• Measurement will refer to personal productivity during a given
process while working on a particular product.
• Table 11.2 shows some examples of typical processes and products
we should consider when measuring the productivity of certain
typical resources
• Table 11.2 also highlights several possible limitations of the
productivity equation (only the four first examples apply).
• Reuse poses problems when calculating productivity (see Example
11.1)
Measuring productivity
• Problem with LOC as a size measure
–
–
–
–
variations in the definition of size.
variation in expressiveness of different languages
variation in programmers’ programming styles
must count comments and reused code separately
Measuring productivity
• As a result some researchers have
proposed that we measure programmer
productivity as
number _ of _ function _ po int s _ implemente d
person _ months
Measuring productivity
• If function points really do capture functionality,
then this measure is attractive for several
reasons
– The FP-based measure more accurately reflects the value of
output
– Can be used to assess the productivity of softwaredevelopment staff at any stage in the life cycle
– Can measure progress – by comparing completed function
points with incomplete ones
• Many managers refuse to use FP because they
find lines of code to be more tangible and
function points are difficult to calculate
– “Translate” FP counts to LOC counts
– Refer Table 11.4
Measuring productivity
• The notion of productivity incorporates the
concept of output of some kind.
– Example for specifiers, designers, and
programmers, the nature of output is quite
clear
– We can measure reviewer productivity in
terms of number ## of reviewed per person
month
– We can measure inspector by calculating the
number of modules inspected per person mo
Measuring productivity
• BUT for other personnel, like project
managers, test teams etc. it is not clear
what the output is and then measuring
productivity may not possible.
Teams, tools, and methods
• Several types of resources have been
touted as productivity enhancers: team
structure, tools and methods.
Team structure
• Team structure has been regarded as a key factor in
determining team productivity
• “Complexity” of team structure leads to low staff
“productivity” and poor output quality
• Complexity communication among team members –
complexity caused by the number of individuals involved
or the method of communications required among
members of a project.
• Rook draws an analogy between the benefits of certain
structural attributes of software products and that of
development and management teams, see Table 11.6.
Team structure
• Model of team structure communication can be
represented as a graph
– Node correspond to individual in the team
– Arcs corresponds to a possible direct (work-related)
communications path between two individuals
– Refer to figure 11.2.
• Several relevant measure
–
–
–
–
Size – number of node
Communication density – arc-to-node ratio
Communication level – tree impurity measure
Individual communication level – degree of the corresponding
node
– Average individual communication level – average node degree
Personal Experience
• Experience is a key contributor to productivity
• Difficult to measure and record experience in a
meaningful way
• Distinguish experience of individuals from
experience of the team
• Consider experience with the project, the
environment, the tools, the methods and the
languages
• Use a simple ordinal measure
Personal Experience
• An ordinal measure of personnel experience could be:
1.No previous experience
2.Familiarity but no working experience
3.Working experience on a single project (< 21 h)
4.Working experience on several projects (21-100 h)
5.Thoroughly experienced
• For team experience - taking the median of the
experience measure of the individuals on the team
• Measure may be misleading if the experience is out of
date – define a companion measure to capture
information about up-to-date training
Personal Experience
• Experience of a team working together on
a project can enhance or deflate
productivity dramatically
– Some teams stay together from project to project –
building up a team spirit
– Other teams – do not function well – productivity lags –
lack of enthusiasm and communication
• Personnel attribute also affect productivity
and product
– Age, level and type of education, intelligence, gender,
marital status and more
Method and tools
• Can increase productivity dramatically
• Rated method and tools use as binary
nominal scale: used or not used
• Since effort is a key component of
productivity, effort-estimation models need
to measure tool and method use in more
sophisticated way.