Proiect
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Proiect as PDF for free.
More details
- Words: 2,432
- Pages: 12
UNIVERSITATE “POLITEHNICA” TIMISOARA
Facultatea de Automatica si Calculatoare
FUNCTION-ORIENTED METRICS
Student: Vasile CHINDRIS, An IV – CTI
Indrumator: As. Ing. Carmen HOLOTESCU
CUPRINS 1. What are Software metrics? 2. Function Oriented Metrics. 1. Function-point method. 2. Conversion of Function-point to SLOC 3. Characteristic-point method 4. Cyclomatic Complexity 3. Trends in Software Metrics
1. What are Software metrics? Effective management of any process requires quantification, measurement, and modeling. Software metrics provide a quantitative basis for the development and validation of models of the software development process. Metrics can be used to improve software productivity and quality. Unfortunately, the current state of software metrics is confused. Many metrics have been invented. Most of these have been defined and then tested only in a limited environment, if at all. In some cases, remarkable successes have been reported in the initial application or validation of these metrics. However, subsequent attempts to test or use the metrics in other situations have yielded very different results. One part of the problem is that we have failed to identify a commonly accepted set of software properties to be measured. As a result, the same metric has been used to measure very different software properties. Moreover, we have virtually no theoretical models and a multitude of metrics, only a few of which have enjoyed any widespread use or acceptance. Basically, software metrics are no more than some numbers that you get from your project when you consider it from a certain perspective. The hard part is to interpret these numbers and to decide what is good, what is wrong and what is acceptable. Ordinarily, these measurements of the software process and product are studied and developed for use in modeling the software development process. These metrics and models are then used to estimate/predict product costs and schedules and to measure productivity and product quality. Information gained from the metrics and the model can then be used in the management and control of the development process, leading, one hopes, to improve results. Good metrics should facilitate the development of models that are capable of predicting process or product parameters, not just describing them. Thus, ideal metrics should be : – simple, precisely definable—so that it is clear how the metric can be evaluated; – objective, to the greatest extent possible; – easily obtainable (i.e., at reasonable cost); – valid—the metric should measure what it is intended to measure; and – robust—relatively insensitive to (intuitively) insignificant changes in the process or product.
2) Function Oriented Metrics. Function Oriented Metrics consists in estimating of the complexity of the functions implemented by the SW product to be developed. There are 2 categories of metrics: – Functional points oriented metrics – Feature points oriented metrics There are some specific estimation methods based on these metrics: – Function-Point Method – Conversion of Function Points in SLOC – Characteristic-Point Method – Proxy-Based Method
2.1) Function Point Method The function-point method, invented by Albrecht at IBM in 1979, is probably the most popular method for estimating the size of commercial software applications. Albrecht identified five basic functions that occur frequently in commercial software development and categorized them according to their relative development complexities. [Albrecht] The definitions of these five basic functions are as follows: [Jones] 1) Inputs: – Inputs are screens or forms through which human users of an application or other programs add new data or update existing data. – If an input screen is too large for a single normal display (usually 80 columns by 25 lines) and flows over onto a second screen, the set counts as one input. – Inputs that require unique processing are what should be considered. 2) Outputs: – Outputs are screens or reports that the application produces for human use or for other programs. – Note that outputs requiring separate processing are the units to count; – For example, in a payroll application, an output function that created, say, 100 checks would still count as one output.
3) Inquiries: – Inquiries are screens that allow users to interrogate an application and ask for assistance or information, such as Help screens. 4) Data files: – Data files are logical collections of records that the application modifies or updates. A file can be, for example: – A flat file such as a tape file, – One leg of a hierarchical database such as IMS, – One table within a relational database, – One path through a CODASYL network database. 5) Interfaces: – Interfaces are files shared with other applications and include: – Incoming or outgoing tape files, – Shared databases, – Parameter lists. To make a function-point estimate: – Review the requirements and count the numbers of each type of function the program will likely need. – Enter these numbers in the Basic Counts area in Table 1 and multiply them by the Weights area to produce the total numbers of function points in each category. – Add the obtained values. – The obtained number is “Unadjusted Total” of functional points of the SW you have estimated. Basic Counts
Function Type
Weights
Inputs
x4
Outputs
x5
Inquiries
x4
Logical Files
x 10
Interfaces
x7
Unadjusted total Table 1
Total
Jones, in his definitive text on this subject, suggests that this unadjusted functionpoint total be adjusted by the influence factors shown, (with an example), in Table 2. The influence factors values are selected from 0 to 5, depending on the degree to which you judge that the particular factor falls between very simple to very complex or very low to very high, and so on. Because there are 14 factors in Table 2 and their values can each range from 0 to 5, the total Sum of the influence factors then ranges from 0 to 70. The formula to calculate the Complexity multiplier is: Complexity multiplier=0.65+0.01*(Sum_of_the_influence_factors) From the above formula, it can be seen that the total Complexity multiplier varies from 0.65 (when Sum=0) to 1.35 (when Sum=70), or from minus to plus 35 percent. To finalize the size estimation in this new conditions: – Estimate the impact of each influence factor by values from 0 to 5. – Add the assigned values for this factors and obtain the Sum_of_influence_factors. – Calculate the Complexity Multiplier based on the formula: Complexity Multiplier=0.65+0.01*(Sum_of_influence_factors) – Multiply the Unadjusted Total of functional points with the Complexity Multiplier in order to obtain the Function points number for the estimated SW. Nr. crt
Factor
Influence 0 = non influence 1 = little influence 2 = moderate influence 3 = average influence 4 = significant influence 5 = strong influence
1.
Data communications
2
2.
Distributed functions
0
3.
Performance objectives
3
4.
Heavily used configuration
3
5.
Transaction rate
4
6.
On line data entry
4
7.
End-user efficiency
3
8.
On line update
2
9.
Complex processing
3
10.
Reusability
2
11.
Installation ease
3
12.
Operational ease
4
13.
Multiple sites
5
14.
Facilitate change
3
Sum of influence factors
41
Complexity Multiplier = 0.65+0.01*(Sum_of_influence_factors)
1.06
Function Points = Complexity Multiplier * Unadjusted Function Points
135*1.06 = 143
Table 2 An Example [Hu95] (Table 3): A count of an applications requirement statement might yield a total of: – 8 inputs, – 12 outputs, – 4 inquiries, – 2 logical files, – 1 interface. Based on proposed estimation algorithm, multiply these numbers by the weights to give the values in the total column. The 8 inputs, for example, are multiplied by a weight of 4, giving a total of 32 (Table 3). The Unadjusted total of function-point would then be 135. The influence factors you selected from Table 2 are used to calculate the function point adjustment (Complexity Multiplier) of 1.06. When you multiply the unadjusted function-point total of 135 by this factor, you get a total of 143 function points.
Basic Counts
Function Type
Weights
Total
8
Inputs
8x4
32
12
Outputs
12 x 5
60
4
Inquiries
4x4
16
2
Logical Files
2 x 10
20
1
Interfaces
1x7
7
Unadjusted total Table 3
135
2.2) Conversion of Function Points to SLOC It is sometimes necessary to convert from SLOC to function points, or vice-versa. Several software cost models, such as Stage 2 of COCOMO II, allow the user to input function points (or a variant of a function point), though they must convert function points to SLOC because the model’s algorithms are based on SLOC. The opposite situation occurs in the CHECKPOINT® model where SLOC inputs must be converted to function points. This conversion process is sometimes called “backfiring.” To help in this conversion process, sets of SLOC to function point ratios have been developed. Table 4 shows ratios for various languages based on research by Jones and Reifer. Jones specifies language levels that show the number of equivalent assembly language SLOC generated by one SLOC of the specified language. Jones further states that language levels are useful for converting size from one language to another, and for assessing relative language productivity Although the relationship between language level and productivity is not linear.
Language
Jones
Jones
Reifer
Language Level
SLOC/FP
SLOC/FP
Assembler
1
320
400
COBOL
3
107
100
Fortran
3
107
105
Ada (1983)
4.5
71
72
PROLOG
5
64
64
Pascal
3.5
91
70
PL/1
4
80
65
Table 4 While function point to SLOC conversion ratios are useful, and often sometimes necessary, they should be used with caution. Table 4 illustrates that: – While the two researchers agree on the ratios for some languages such as Ada, they differ on the ratios for other programming languages such as Pascal and PL/1. – For the COBOL language, research by Henderson showed that the conversion ratios are inconsistent both within and between databases. For example: – For two databases maintained at the Air Force Standard Systems Center, Henderson found that for a military data base of 26 COBOL programs, the average SLOC to function point ratio was 14:1, – While for a database of 31 commercial COBOL programs, the average SLOC to function point ratio was 165:1. – Furthermore, there was considerable variance for these ratios within the databases. Therefore, for some languages it appears that backfiring should not be used, and for cost estimation, it is probably best to use a model for which the algorithms are based on the user’s size measure (i.e., calibrated parametric sizing models). 2.3) Characteristic-point Method The metrics based on characteristic points was proposed by C.A. Jones [C.A. Jones, “A short History of Function Point Method and Feature Points Software Productivity” Research, Inc., Burlington, MA, June, 1986]. The method is not very much different from function-point method. In fact there are three differences: – Function-points are substituted with characteristic points – The associated weights has different values – A new parameter is added: algorithms with weight 3 The method’s steps: – Estimate the counter associated to the characteristic point and calculate the Total (Table 5.). There are versions of method in which weights differs function of program complexity (simple, average, complex). The determined Total can be adjusted in a similar manner as in functional point method: Establish the weights of the 14 influence factors; – Calculate the value of the complexity adjustment factor (SIF) as sum of the 14 influence factors
–
Calculate the value of the AdjustedTotal : AdjustedTotal =Total*(0.65 + 0.01*SIF)
Characteristic Type
Basic Counts
Weights
External Inputs
4
External Outputs
5
External Inquiries
4
Internal Files
7
External Interfaces
7
Algorithms
3
Total
Total Table 5
2.4) Cyclomatic Complexity Given any computer program, we can draw its control flow graph, G, wherein each node corresponds to a block of sequential code and each arc corresponds to a branch or decision point in the program. The cyclomatic complexity of such a graph can be computed by a simple formula from graph theory, as v(G) = e − n + 2, where e is the number of edges, and n is the number of nodes in the graph. McCabe proposed that v(G) can be used as a measure of program complexity and, hence, as a guide to program development and testing. For structured programs, v(G) can be computed without reference to the program flow graph by using only the number of decision points in the program text [McCabe76]. McCabe’s cyclomatic complexity metric has been related to programming effort, debugging performance, and maintenance effort. The studies by Curtis and Woodfield referenced earlier also report results for this metric [Curtis79b, Woodfield81, Harrison-82]. Myers noted that McCabe’s cyclomatic complexity measure, v(G), provides a measure of program complexity but fails to differentiate the complexity of some rather simple cases involving single conditions (as opposed to multiple conditions) in conditional statements. As an improvement to the original formula, Myers suggests extending v(G) to v ′(G) = [l:u], where l and u are lower and upper bounds, respectively, for the complexity. This formula gives more satisfactory results for the cases noted by
Myers [Myers77]. Stetter proposed that the program flow graph be expanded to include data declarations and data references, thus allowing the graph to depict the program complexity more completely. If H is the new program flow graph, it will generally contain multiple entry and exit nodes. A function f (H) can be computed as a measure of the flow complexity of program H. The deficiencies noted by Myers are also eliminated by f (H) [Stetter84].
3. Trends in Software Metrics Current trends in the software metrics area are encouraging. Metrics are being applied more widely, with good results in many cases. The limitations of existing models have been recognized, and people are becoming more realistic in their expectations of what these models can provide. There is a growing awareness that metrics programs pay off, but not without some investment of both time and resources. As the benefits of software metrics programs become more evident, the establishment of such a program will become essential for software development organizations to remain competitive in this area. Finally, although there are still a large number of metrics in use or under active investigation, a smaller set of metrics is emerging as having more practical utility in the measurement of the software development process. An economical set of metrics capturing the essential characteristics of software may yet emerge from this smaller, more useful set. Software engineering is still a very young discipline. There are encouraging signs that we are beginning to understand some of the basic parameters that are most influential in the processes of software production.
Bibliography: 1.
http://www.sei.cmu.edu/publications/documents/cms/cm.012.ht ml
2. http://www.google.ro/url?sa=t&source=web&ct=res&cd=1&url=http%3A%2F%2 Fwww.csie.mcu.edu.tw%2F~hsong%2Fse%2Fse_04metrics.ppt&ei=bIn9Sc6FG4 OS_Qa3n5yiBA&usg=AFQjCNHGGZAMn_0DMkBqhdFz391AbKARnw&sig2 =qGmpLYW1J8vbqTbyUM_9_w 3. http://www.google.com/url?sa=t&source=web&ct=res&cd=1&url=http%3A%2F %2Fwww.engineerszone.org%2Fstdymat%2Fcs%2F5%2520sem%2520cs%2520s e%2Funit2_b.pdf&ei=BYr9SZrsDdqOsAbKifG4BA&usg=AFQjCNFB04GjtEI8nASeTXK pg0vbDwTydg&sig2=YuK-klAEJx5mgDrVGuqoKg (www.engineerszone.org) 4. Vladimir Cretu, curs MPS pentru anul IV Calculatoare, capitolul 4, “Function oriented metrics”.
Facultatea de Automatica si Calculatoare
FUNCTION-ORIENTED METRICS
Student: Vasile CHINDRIS, An IV – CTI
Indrumator: As. Ing. Carmen HOLOTESCU
CUPRINS 1. What are Software metrics? 2. Function Oriented Metrics. 1. Function-point method. 2. Conversion of Function-point to SLOC 3. Characteristic-point method 4. Cyclomatic Complexity 3. Trends in Software Metrics
1. What are Software metrics? Effective management of any process requires quantification, measurement, and modeling. Software metrics provide a quantitative basis for the development and validation of models of the software development process. Metrics can be used to improve software productivity and quality. Unfortunately, the current state of software metrics is confused. Many metrics have been invented. Most of these have been defined and then tested only in a limited environment, if at all. In some cases, remarkable successes have been reported in the initial application or validation of these metrics. However, subsequent attempts to test or use the metrics in other situations have yielded very different results. One part of the problem is that we have failed to identify a commonly accepted set of software properties to be measured. As a result, the same metric has been used to measure very different software properties. Moreover, we have virtually no theoretical models and a multitude of metrics, only a few of which have enjoyed any widespread use or acceptance. Basically, software metrics are no more than some numbers that you get from your project when you consider it from a certain perspective. The hard part is to interpret these numbers and to decide what is good, what is wrong and what is acceptable. Ordinarily, these measurements of the software process and product are studied and developed for use in modeling the software development process. These metrics and models are then used to estimate/predict product costs and schedules and to measure productivity and product quality. Information gained from the metrics and the model can then be used in the management and control of the development process, leading, one hopes, to improve results. Good metrics should facilitate the development of models that are capable of predicting process or product parameters, not just describing them. Thus, ideal metrics should be : – simple, precisely definable—so that it is clear how the metric can be evaluated; – objective, to the greatest extent possible; – easily obtainable (i.e., at reasonable cost); – valid—the metric should measure what it is intended to measure; and – robust—relatively insensitive to (intuitively) insignificant changes in the process or product.
2) Function Oriented Metrics. Function Oriented Metrics consists in estimating of the complexity of the functions implemented by the SW product to be developed. There are 2 categories of metrics: – Functional points oriented metrics – Feature points oriented metrics There are some specific estimation methods based on these metrics: – Function-Point Method – Conversion of Function Points in SLOC – Characteristic-Point Method – Proxy-Based Method
2.1) Function Point Method The function-point method, invented by Albrecht at IBM in 1979, is probably the most popular method for estimating the size of commercial software applications. Albrecht identified five basic functions that occur frequently in commercial software development and categorized them according to their relative development complexities. [Albrecht] The definitions of these five basic functions are as follows: [Jones] 1) Inputs: – Inputs are screens or forms through which human users of an application or other programs add new data or update existing data. – If an input screen is too large for a single normal display (usually 80 columns by 25 lines) and flows over onto a second screen, the set counts as one input. – Inputs that require unique processing are what should be considered. 2) Outputs: – Outputs are screens or reports that the application produces for human use or for other programs. – Note that outputs requiring separate processing are the units to count; – For example, in a payroll application, an output function that created, say, 100 checks would still count as one output.
3) Inquiries: – Inquiries are screens that allow users to interrogate an application and ask for assistance or information, such as Help screens. 4) Data files: – Data files are logical collections of records that the application modifies or updates. A file can be, for example: – A flat file such as a tape file, – One leg of a hierarchical database such as IMS, – One table within a relational database, – One path through a CODASYL network database. 5) Interfaces: – Interfaces are files shared with other applications and include: – Incoming or outgoing tape files, – Shared databases, – Parameter lists. To make a function-point estimate: – Review the requirements and count the numbers of each type of function the program will likely need. – Enter these numbers in the Basic Counts area in Table 1 and multiply them by the Weights area to produce the total numbers of function points in each category. – Add the obtained values. – The obtained number is “Unadjusted Total” of functional points of the SW you have estimated. Basic Counts
Function Type
Weights
Inputs
x4
Outputs
x5
Inquiries
x4
Logical Files
x 10
Interfaces
x7
Unadjusted total Table 1
Total
Jones, in his definitive text on this subject, suggests that this unadjusted functionpoint total be adjusted by the influence factors shown, (with an example), in Table 2. The influence factors values are selected from 0 to 5, depending on the degree to which you judge that the particular factor falls between very simple to very complex or very low to very high, and so on. Because there are 14 factors in Table 2 and their values can each range from 0 to 5, the total Sum of the influence factors then ranges from 0 to 70. The formula to calculate the Complexity multiplier is: Complexity multiplier=0.65+0.01*(Sum_of_the_influence_factors) From the above formula, it can be seen that the total Complexity multiplier varies from 0.65 (when Sum=0) to 1.35 (when Sum=70), or from minus to plus 35 percent. To finalize the size estimation in this new conditions: – Estimate the impact of each influence factor by values from 0 to 5. – Add the assigned values for this factors and obtain the Sum_of_influence_factors. – Calculate the Complexity Multiplier based on the formula: Complexity Multiplier=0.65+0.01*(Sum_of_influence_factors) – Multiply the Unadjusted Total of functional points with the Complexity Multiplier in order to obtain the Function points number for the estimated SW. Nr. crt
Factor
Influence 0 = non influence 1 = little influence 2 = moderate influence 3 = average influence 4 = significant influence 5 = strong influence
1.
Data communications
2
2.
Distributed functions
0
3.
Performance objectives
3
4.
Heavily used configuration
3
5.
Transaction rate
4
6.
On line data entry
4
7.
End-user efficiency
3
8.
On line update
2
9.
Complex processing
3
10.
Reusability
2
11.
Installation ease
3
12.
Operational ease
4
13.
Multiple sites
5
14.
Facilitate change
3
Sum of influence factors
41
Complexity Multiplier = 0.65+0.01*(Sum_of_influence_factors)
1.06
Function Points = Complexity Multiplier * Unadjusted Function Points
135*1.06 = 143
Table 2 An Example [Hu95] (Table 3): A count of an applications requirement statement might yield a total of: – 8 inputs, – 12 outputs, – 4 inquiries, – 2 logical files, – 1 interface. Based on proposed estimation algorithm, multiply these numbers by the weights to give the values in the total column. The 8 inputs, for example, are multiplied by a weight of 4, giving a total of 32 (Table 3). The Unadjusted total of function-point would then be 135. The influence factors you selected from Table 2 are used to calculate the function point adjustment (Complexity Multiplier) of 1.06. When you multiply the unadjusted function-point total of 135 by this factor, you get a total of 143 function points.
Basic Counts
Function Type
Weights
Total
8
Inputs
8x4
32
12
Outputs
12 x 5
60
4
Inquiries
4x4
16
2
Logical Files
2 x 10
20
1
Interfaces
1x7
7
Unadjusted total Table 3
135
2.2) Conversion of Function Points to SLOC It is sometimes necessary to convert from SLOC to function points, or vice-versa. Several software cost models, such as Stage 2 of COCOMO II, allow the user to input function points (or a variant of a function point), though they must convert function points to SLOC because the model’s algorithms are based on SLOC. The opposite situation occurs in the CHECKPOINT® model where SLOC inputs must be converted to function points. This conversion process is sometimes called “backfiring.” To help in this conversion process, sets of SLOC to function point ratios have been developed. Table 4 shows ratios for various languages based on research by Jones and Reifer. Jones specifies language levels that show the number of equivalent assembly language SLOC generated by one SLOC of the specified language. Jones further states that language levels are useful for converting size from one language to another, and for assessing relative language productivity Although the relationship between language level and productivity is not linear.
Language
Jones
Jones
Reifer
Language Level
SLOC/FP
SLOC/FP
Assembler
1
320
400
COBOL
3
107
100
Fortran
3
107
105
Ada (1983)
4.5
71
72
PROLOG
5
64
64
Pascal
3.5
91
70
PL/1
4
80
65
Table 4 While function point to SLOC conversion ratios are useful, and often sometimes necessary, they should be used with caution. Table 4 illustrates that: – While the two researchers agree on the ratios for some languages such as Ada, they differ on the ratios for other programming languages such as Pascal and PL/1. – For the COBOL language, research by Henderson showed that the conversion ratios are inconsistent both within and between databases. For example: – For two databases maintained at the Air Force Standard Systems Center, Henderson found that for a military data base of 26 COBOL programs, the average SLOC to function point ratio was 14:1, – While for a database of 31 commercial COBOL programs, the average SLOC to function point ratio was 165:1. – Furthermore, there was considerable variance for these ratios within the databases. Therefore, for some languages it appears that backfiring should not be used, and for cost estimation, it is probably best to use a model for which the algorithms are based on the user’s size measure (i.e., calibrated parametric sizing models). 2.3) Characteristic-point Method The metrics based on characteristic points was proposed by C.A. Jones [C.A. Jones, “A short History of Function Point Method and Feature Points Software Productivity” Research, Inc., Burlington, MA, June, 1986]. The method is not very much different from function-point method. In fact there are three differences: – Function-points are substituted with characteristic points – The associated weights has different values – A new parameter is added: algorithms with weight 3 The method’s steps: – Estimate the counter associated to the characteristic point and calculate the Total (Table 5.). There are versions of method in which weights differs function of program complexity (simple, average, complex). The determined Total can be adjusted in a similar manner as in functional point method: Establish the weights of the 14 influence factors; – Calculate the value of the complexity adjustment factor (SIF) as sum of the 14 influence factors
–
Calculate the value of the AdjustedTotal : AdjustedTotal =Total*(0.65 + 0.01*SIF)
Characteristic Type
Basic Counts
Weights
External Inputs
4
External Outputs
5
External Inquiries
4
Internal Files
7
External Interfaces
7
Algorithms
3
Total
Total Table 5
2.4) Cyclomatic Complexity Given any computer program, we can draw its control flow graph, G, wherein each node corresponds to a block of sequential code and each arc corresponds to a branch or decision point in the program. The cyclomatic complexity of such a graph can be computed by a simple formula from graph theory, as v(G) = e − n + 2, where e is the number of edges, and n is the number of nodes in the graph. McCabe proposed that v(G) can be used as a measure of program complexity and, hence, as a guide to program development and testing. For structured programs, v(G) can be computed without reference to the program flow graph by using only the number of decision points in the program text [McCabe76]. McCabe’s cyclomatic complexity metric has been related to programming effort, debugging performance, and maintenance effort. The studies by Curtis and Woodfield referenced earlier also report results for this metric [Curtis79b, Woodfield81, Harrison-82]. Myers noted that McCabe’s cyclomatic complexity measure, v(G), provides a measure of program complexity but fails to differentiate the complexity of some rather simple cases involving single conditions (as opposed to multiple conditions) in conditional statements. As an improvement to the original formula, Myers suggests extending v(G) to v ′(G) = [l:u], where l and u are lower and upper bounds, respectively, for the complexity. This formula gives more satisfactory results for the cases noted by
Myers [Myers77]. Stetter proposed that the program flow graph be expanded to include data declarations and data references, thus allowing the graph to depict the program complexity more completely. If H is the new program flow graph, it will generally contain multiple entry and exit nodes. A function f (H) can be computed as a measure of the flow complexity of program H. The deficiencies noted by Myers are also eliminated by f (H) [Stetter84].
3. Trends in Software Metrics Current trends in the software metrics area are encouraging. Metrics are being applied more widely, with good results in many cases. The limitations of existing models have been recognized, and people are becoming more realistic in their expectations of what these models can provide. There is a growing awareness that metrics programs pay off, but not without some investment of both time and resources. As the benefits of software metrics programs become more evident, the establishment of such a program will become essential for software development organizations to remain competitive in this area. Finally, although there are still a large number of metrics in use or under active investigation, a smaller set of metrics is emerging as having more practical utility in the measurement of the software development process. An economical set of metrics capturing the essential characteristics of software may yet emerge from this smaller, more useful set. Software engineering is still a very young discipline. There are encouraging signs that we are beginning to understand some of the basic parameters that are most influential in the processes of software production.
Bibliography: 1.
http://www.sei.cmu.edu/publications/documents/cms/cm.012.ht ml
2. http://www.google.ro/url?sa=t&source=web&ct=res&cd=1&url=http%3A%2F%2 Fwww.csie.mcu.edu.tw%2F~hsong%2Fse%2Fse_04metrics.ppt&ei=bIn9Sc6FG4 OS_Qa3n5yiBA&usg=AFQjCNHGGZAMn_0DMkBqhdFz391AbKARnw&sig2 =qGmpLYW1J8vbqTbyUM_9_w 3. http://www.google.com/url?sa=t&source=web&ct=res&cd=1&url=http%3A%2F %2Fwww.engineerszone.org%2Fstdymat%2Fcs%2F5%2520sem%2520cs%2520s e%2Funit2_b.pdf&ei=BYr9SZrsDdqOsAbKifG4BA&usg=AFQjCNFB04GjtEI8nASeTXK pg0vbDwTydg&sig2=YuK-klAEJx5mgDrVGuqoKg (www.engineerszone.org) 4. Vladimir Cretu, curs MPS pentru anul IV Calculatoare, capitolul 4, “Function oriented metrics”.
