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

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 software- development 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 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 ( 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.