3.6 Calculating ProductivityProduct

3.6 Calculating Productivity
Productivity is generally measured as the labor hours required to do a unit of work.
It is such a simple concept that people tend to think of productivity as a simple
calculation. Although the calculation is simple, using the right data and properly
interpreting these data is not so easy. Proper productivity calculations must consider, for example, the unique conditions of each job and the quality of the resulting product. If you estimate the size of a new job and then use some global
productivity factor to determine the total hours required, you will generally get a
misleading result. It would be analogous to always allowing for the average
driving time when you go to the airport. With that method, you will miss a lot of
flights around rush hour and do a lot of waiting the rest of the time.
When calculating productivity, divide the size of the product produced by the
hours spent producing it. This gives the volume of product produced per hour. For
programming, for example, if you developed a 600-LOC program in 60 hours,
your productivity would be 10 LOC per hour. Although this may seem simple
enough, you face many choices for picking these size and hours measures. For
example, various combinations of the numbers used in the LOC accounting
example in Table 3.2 (see p. 44) are shown in Table 3.3. There is some basis for
3.6 Calculating Productivity 47
arguing that any one of these six numbers should be used to measure development
productivity. Assuming that you spent a total of 60 hours developing this program,
the various productivity options could differ by factors of two or more times. This
variation is caused solely by the choice you make for using the size measures. That
is why comparisons of productivity numbers between organizations or even
among individuals are rarely useful and why each developer must choose his or
her own method and use it consistently.
For most new or major enhancement projects, added plus modified product is
probably most appropriate for calculating productivity. For small modifications
to large programs, however, the issue is much more complex. The reason is that
the productivity for software modification is often much lower than for new development (Flaherty 1985). By gathering data on the time spent, the sizes of the
changes, the size of the base program, and the fraction of the base program modified, you will likely find that small changes in large programs take much more
time than either new development or large-percentage modifications of existing
programs. Study your own data and see what categories provide the best correlation with development effort. Again, the methods discussed in this book will help
you to arrive at appropriate productivity figures.
3.7 Size Counters
Although it is relatively easy to count the sizes of small programs, manually counting even small programs can be time-consuming and error-prone. For large programs, however, manual counting is impractical, making automated size counters
essential.
Counters can be designed to count the number of almost any product element
as long as the definition for that element is precise and specific. For example, a
48 Chapter 3 Measuring Software Size
TABLE 3.3 VARIATIONS IN LOC PRODUCTIVITY
Size Productivity
Productivity Option LOC LOC/Hour
Added (350+100+50) 500 8.33
Added + Modified (500+100) 600 10.00
Added + Modified + Deleted (600+200) 800 13.33
Added + Modified + Reused (600+600) 1200 20.00
Added + Modified + Deleted + Reused (1,200+200) 1400 23.33
Total Finished Product 900 15.00
LOC counter could count physical lines or logical lines. Although automatically
counting database elements can be a bit more complex, if the object model is
accessible, you can usually count selected sets of database elements.
Physical LOC Counters
The simplest type of size counter counts physical LOC. Here, you count all text
lines except comments and blank lines. A text line that has both comments and
source code is counted as one LOC.
Logical LOC Counters
Logical LOC counters work much like physical counters except that line-counter
stepping is more complex. My Object Pascal logical line counter had 939 LOC
and took me about 50 hours to develop. Don’t try to develop a logical line counter
unless you have plenty of time to do it. Although people can endlessly debate the
best way to count LOC, the details are not that important. The key is to be precise
and consistent. In my Object Pascal and C++ programs, I counted every logical
program statement. Although some may argue that counting begin and end statements is not a good idea, this is a matter of personal preference. If you could show,
however, that the time required to develop a program had a higher correlation with
LOC when begin-end pairs were counted than when they were not, that would be
a good reason to use them. This would also be the proper way to resolve almost
any size counting question.
Presently, there is no compelling evidence to support any one counting
method over any other. With good data, however, a study of the various alternatives could quickly show which, if any, would be best for your work. It may show,
as is likely, that many different approaches produce roughly equivalent results.
In that case, the selection is arbitrary. The fact that it is arbitrary, however, does
not mean that everyone should do it differently. If all of the projects in an organization used the same counting standard, they could afford to develop a single highquality automated counter for everyone to use. They would also have a much
larger volume of data to use in planning and quality analysis.
Counting Program Elements
It is often desirable to measure the sizes of various parts of large programs. For
example, if you intended to reuse some newly developed classes or procedures,
you would like to know how large each one is. As you will see in Chapter 5, such
counts can also help with size estimating.
3.7 Size Counters 49
To maintain separate counts for each class or procedure, you must determine
where each one starts and ends. Because the way to do this depends on the programming language, there is no general guideline. The counter I built for Object
Pascal recognized the keywords procedure, function, constructor, and destructor as the beginning of procedures. I found the endpoints by counting begin-end
pairs. With a little study, you can determine the indicators for the beginning and
ending points of the methods, procedures, classes, functions, or other elements for
the language you use. You can then use this definition to scan the program text and
start and stop the size counter at the appropriate points.
Using Coding Standards and Physical LOC Counters
One simple way to count logical LOC is to use a coding standard and count physical LOC, omitting comments and blanks. The idea is to write the source code with
a separate physical text line for every countable line. Then, when you count physical lines, you are also counting logical lines. To use this method, you must carefully follow a coding standard like the example shown in Table 3.4. If, at the same
50 Chapter 3 Measuring Software Size
TABLE 3.4 EXAMPLE C++ CODING STANDARD
Purpose: To guide the development of C++ programs
Program Headers Begin all programs with a descriptive header.
Header Format /*************************************************************************/
/* Program Assignment: the program number */
/* Name: your name */
/* Date: the date program development started */
/* Description: a short description of the program */
/* function */
/*************************************************************************/
Listing Contents Provide a summary of the listing contents.
Contents Example /*************************************************************************/
/* Listing Contents: */
/* Reuse instructions */
/* Modification instructions */
/* Compilation instructions */
/* Includes */
/* Class declarations: */
/* CData */
/* ASet */
/* Source code in c:classesCData.cpp: */
/* CData */
/* CData() */
/* Empty() */
/*************************************************************************/
3.7 Size Counters 51
Reuse Instructions • Describe how the program is used. Provide the declaration
format, parameter values and types, and parameter limits.
• Provide warnings of illegal values, overflow conditions, or other
conditions that could potentially result in improper operation.
Reuse Example /*************************************************************************/
/* Reuse Instructions */
/* int PrintLine(char *line_of_character) */
/* Purpose: to print string, ‘line_of_character’, on one print line */
/* Limitations: the maximum line length is LINE_LENGTH */
/* Return: 0 if printer not ready to print, else 1 */
/*************************************************************************/
Identifiers Use descriptive names for all variables, function names,
constants, and other identifiers. Avoid abbreviations or single
letter variables.
Identifier Example int number_of_students; /* This is GOOD */
float x4, j, ftave; /* These are BAD */
Comments • Document the code so that the reader can understand its
operation.
• Comments should explain both the purpose and behavior of the
code.
• Comment variable declarations to indicate their purpose.
Good Comment If (record_count > limit) /* have all the records been processed? */
Bad Comment if(record_count > limit) /* check if record_count is greater than limit */
Major Sections Precede major program sections by a block comment that
describes the processing that is done in the next section.
Example /*************************************************************************/
/* This program section will examine the contents of the array */
/* “grades” and will calculate the average grade for the class. */
/*************************************************************************/
Blank Spaces • Write programs with sufficient spacing so that they

Kết quả (Việt) 1:

3,6 tính năng suấtNăng suất thường đo bằng giờ lao động cần thiết để làm một đơn vị của công việc.Nó là như vậy đơn giản một khái niệm mà mọi người có xu hướng suy nghĩ của năng suất là một đơn giảntính toán. Mặc dù tính toán đơn giản, bằng cách sử dụng dữ liệu phù hợp và đúng cáchgiải thích những dữ liệu này không phải là dễ dàng như vậy. Thích hợp năng suất tính toán phải xem xét, ví dụ, các điều kiện duy nhất của mỗi công việc và chất lượng của các sản phẩm kết quả. Nếu bạn ước tính kích thước của một công việc mới và sau đó sử dụng một số toàn cầunăng suất yếu tố để xác định tổng số giờ yêu cầu, bạn thường sẽ nhận được mộtkết quả gây hiểu nhầm. Nó sẽ là tương tự như luôn luôn cho phép cho mức trung bìnhlái xe thời gian khi bạn đi đến sân bay. Với phương pháp đó, bạn sẽ bỏ lỡ rất nhiềuchuyến bay xung quanh thành phố giờ cao điểm và làm rất nhiều chờ đợi phần còn lại của thời gian.Khi tính năng suất, phân chia kích thước của sản phẩm được sản xuất bởi cácgiờ chi tiêu sản xuất nó. Điều này cho phép khối lượng sản phẩm được sản xuất cho giờ. Cholập trình, ví dụ, nếu bạn phát triển một chương trình 600-Lộc trong 60 giờ,năng suất của bạn sẽ là LOC 10 cho giờ. Mặc dù điều này có vẻ đơn giảnđủ, bạn phải đối mặt với nhiều sự lựa chọn để chọn các biện pháp kích thước và giờ. ChoVí dụ, các kết hợp khác nhau của những con số được sử dụng trong kế toán LộcVí dụ trong bảng 3.2 (xem trang 44) được hiển thị trong bảng 3.3. Có một số cơ sở cho3,6 tính năng suất 47tranh cãi rằng bất kỳ một trong những con số sáu nên được sử dụng để đo phát triểnnăng suất. Giả sử rằng bạn đã dành tổng cộng 60 giờ phát triển chương trình này,Các tùy chọn khác nhau của năng suất có thể khác nhau do các yếu tố của hai hay nhiều lần. Điều nàybiến thể được gây ra bởi sự lựa chọn bạn thực hiện cho việc sử dụng các biện pháp kích thước. Rằnglà lý do tại sao các so sánh năng suất số giữa các tổ chức hoặc thậm chítrong số các cá nhân hiếm khi hữu ích và lý do tại sao mỗi nhà phát triển phải lựa chọn của mình hoặcCô sở hữu phương pháp và sử dụng nó một cách nhất quán.Đối với hầu hết các dự án mới hoặc chính nâng cao, bổ sung, cộng với sửa đổi sản phẩm làcó lẽ đặt thích hợp cho việc tính toán năng suất. Để sửa đổi nhỏđể chương trình lớn, Tuy nhiên, vấn đề là phức tạp hơn. Lý do lànăng suất cho sửa đổi phần mềm thường là nhiều hơn cho phát triển mới (Flaherty 1985). Bởi thu thập dữ liệu về thời gian chi tiêu, các kích thước của cácthay đổi, kích thước của chương trình cơ bản, và các phần của chương trình cơ bản lần, có thể bạn sẽ tìm thấy rằng nhỏ thay đổi trong chương trình lớn có nhiều hơn nữathời gian hơn phát triển mới hoặc sửa đổi tỷ lệ phần trăm lớn hiện cóchương trình. Nghiên cứu dữ liệu của bạn và xem những gì thể loại cung cấp sự tương quan tốt nhất với nỗ lực phát triển. Một lần nữa, các phương pháp thảo luận trong cuốn sách này sẽ giúpbạn để đi đến con số thích hợp năng suất.3.7 đồng hồ đo kích thướcMặc dù nó là tương đối dễ dàng để đếm các kích thước của chương trình nhỏ, theo cách thủ công đếm thậm chí nhỏ chương trình có thể tốn thời gian và dễ bị lỗi. Đối với chương trình lớn, Tuy nhiên, hướng dẫn sử dụng đếm là không thực tế, làm cho đồng hồ tự động kích thướcessential.Counters can be designed to count the number of almost any product elementas long as the definition for that element is precise and specific. For example, a48 Chapter 3 Measuring Software SizeTABLE 3.3 VARIATIONS IN LOC PRODUCTIVITYSize ProductivityProductivity Option LOC LOC/HourAdded (350+100+50) 500 8.33Added + Modified (500+100) 600 10.00Added + Modified + Deleted (600+200) 800 13.33Added + Modified + Reused (600+600) 1200 20.00Added + Modified + Deleted + Reused (1,200+200) 1400 23.33Total Finished Product 900 15.00LOC counter could count physical lines or logical lines. Although automaticallycounting database elements can be a bit more complex, if the object model isaccessible, you can usually count selected sets of database elements.Physical LOC CountersThe simplest type of size counter counts physical LOC. Here, you count all textlines except comments and blank lines. A text line that has both comments andsource code is counted as one LOC.Logical LOC CountersLogical LOC counters work much like physical counters except that line-counterstepping is more complex. My Object Pascal logical line counter had 939 LOCand took me about 50 hours to develop. Don’t try to develop a logical line counterunless you have plenty of time to do it. Although people can endlessly debate thebest way to count LOC, the details are not that important. The key is to be preciseand consistent. In my Object Pascal and C++ programs, I counted every logicalprogram statement. Although some may argue that counting begin and end statements is not a good idea, this is a matter of personal preference. If you could show,however, that the time required to develop a program had a higher correlation withLOC when begin-end pairs were counted than when they were not, that would bea good reason to use them. This would also be the proper way to resolve almostany size counting question.Presently, there is no compelling evidence to support any one countingmethod over any other. With good data, however, a study of the various alternatives could quickly show which, if any, would be best for your work. It may show,as is likely, that many different approaches produce roughly equivalent results.In that case, the selection is arbitrary. The fact that it is arbitrary, however, doesnot mean that everyone should do it differently. If all of the projects in an organization used the same counting standard, they could afford to develop a single highquality automated counter for everyone to use. They would also have a muchlarger volume of data to use in planning and quality analysis.Counting Program ElementsIt is often desirable to measure the sizes of various parts of large programs. Forexample, if you intended to reuse some newly developed classes or procedures,you would like to know how large each one is. As you will see in Chapter 5, suchcounts can also help with size estimating.3.7 Size Counters 49
To maintain separate counts for each class or procedure, you must determine
where each one starts and ends. Because the way to do this depends on the programming language, there is no general guideline. The counter I built for Object
Pascal recognized the keywords procedure, function, constructor, and destructor as the beginning of procedures. I found the endpoints by counting begin-end
pairs. With a little study, you can determine the indicators for the beginning and
ending points of the methods, procedures, classes, functions, or other elements for
the language you use. You can then use this definition to scan the program text and
start and stop the size counter at the appropriate points.
Using Coding Standards and Physical LOC Counters
One simple way to count logical LOC is to use a coding standard and count physical LOC, omitting comments and blanks. The idea is to write the source code with
a separate physical text line for every countable line. Then, when you count physical lines, you are also counting logical lines. To use this method, you must carefully follow a coding standard like the example shown in Table 3.4. If, at the same
50 Chapter 3 Measuring Software Size
TABLE 3.4 EXAMPLE C++ CODING STANDARD
Purpose: To guide the development of C++ programs
Program Headers Begin all programs with a descriptive header.
Header Format /*************************************************************************/
/* Program Assignment: the program number */
/* Name: your name */
/* Date: the date program development started */
/* Description: a short description of the program */
/* function */
/*************************************************************************/
Listing Contents Provide a summary of the listing contents.
Contents Example /*************************************************************************/
/* Listing Contents: */
/* Reuse instructions */
/* Modification instructions */
/* Compilation instructions */
/* Includes */
/* Class declarations: */
/* CData */
/* ASet */
/* Source code in c:classesCData.cpp: */
/* CData */
/* CData() */
/* Empty() */
/*************************************************************************/
3.7 Size Counters 51
Reuse Instructions • Describe how the program is used. Provide the declaration
format, parameter values and types, and parameter limits.
• Provide warnings of illegal values, overflow conditions, or other
conditions that could potentially result in improper operation.
Reuse Example /*************************************************************************/
/* Reuse Instructions */
/* int PrintLine(char *line_of_character) */
/* Purpose: to print string, ‘line_of_character’, on one print line */
/* Limitations: the maximum line length is LINE_LENGTH */
/* Return: 0 if printer not ready to print, else 1 */
/*************************************************************************/
Identifiers Use descriptive names for all variables, function names,
constants, and other identifiers. Avoid abbreviations or single
letter variables.
Identifier Example int number_of_students; /* This is GOOD */
float x4, j, ftave; /* These are BAD */
Comments • Document the code so that the reader can understand its
operation.
• Comments should explain both the purpose and behavior of the
code.
• Comment variable declarations to indicate their purpose.
Good Comment If (record_count > limit) /* have all the records been processed? */
Bad Comment if(record_count > limit) /* check if record_count is greater than limit */
Major Sections Precede major program sections by a block comment that
describes the processing that is done in the next section.
Example /*************************************************************************/
/* This program section will examine the contents of the array */
/* “grades” and will calculate the average grade for the class. */
/*************************************************************************/
Blank Spaces • Write programs with sufficient spacing so that they