You know something about something when you can measure what you say and put numbers on it; But when you can’t measure it, when you can’t put numbers on it, your understanding of it is poor.

The above statement points to the fact that when you want a quantifiable result, you need to measure it first, and then you have the measurement. This is as true for things as it is for software project management. A good software project management needs to be measured and measured in many aspects in order to better present a more satisfactory result.

In the following article, you will learn about software metrics in software project management.

I. Purpose of measurement

1, the quotes

Lord Kelvin once said: ① When you can measure what you say and put it in numbers, you know something about it; ② But when you cannot measure it, when you cannot express it in numbers, your understanding of it is poor and unsatisfactory; ③ It may be the beginning of knowledge, but you are far from entering the realm of science in thought.

This sentence shows that if you want to get a quantifiable result, you need to measure it first. After you have the measurement result, you can measure it. In other words, measurement is the basis of measurement.

2. Purpose of measurement

Measurement is done to understand the technical process of product development and the product itself.

  • The purpose of measuring the development process is to improve the process;

  • The purpose of measuring products is to improve the quality of products.

3. The Role of metrics

  • The purpose of measurement is to manage quantitatively and effectively.

Two, measurement, measurement and index distinction

1, the quotes

Let’s say we have two people, A and B, and we both know that A is taller than B. But I don’t know how much higher is A than B?

This time must pass measure height ability to know specific value.

Therefore, the height values of A and B are the measured values.

After measurement, A’s height is 189cm, B’s height is 170cm.

It is concluded that A is 19cm taller than B.

So, A is 19cm higher than B is the metric.

2. The difference between measurement, measurement and indicators

(1) Measure — provides a quantitative indication of the scope, quantity, dimension, capacity or size of an attribute of a product or process.

(2) Metrics — A quantitative measure of the degree to which a system, component, or process has a given property.

(3) Indicators — Software engineers collect measurements and develop metrics so that “indicators” can be obtained; A metric is a measure or combination of measures that provides a deeper understanding of the software process, software project, or product itself.

3. Think about the questions

Q: Indicate which of the following statements are measurements, measures and indicators.

There are four software teams working together on a large project, but each team must conduct technical reviews,

By examining the number of errors found per person per hour, managers found that the two groups using a more formal review method detected 40 percent more errors per person per hour than the other two groups.

Answer:

The number of errors found per person per hour is measured, and the more formal evaluation method is a metric, where the number of errors found per person per hour is 40% higher.

Assuming all other parameters are equal, this gives the manager an indicator that a formal review method provides a greater return on the investment of time than any other review method, and he may recommend that all teams adopt the formal review method.

The conclusion is that measurement is the basis of measurement, and measurement is to get the index, and their relationship is: measurement -> measurement -> index.

Process measurement and project measurement

Software process measurement is mainly used for strategic purposes, while software project measurement is tactical.

1, processes,

(1) Process measurement

  • Measurement of errors prior to software release;
  • Measurement of defects delivered to and reported by end users;
  • Measurement of work products delivered (productivity);
  • A measure of the amount of work expended;
  • A measure of time spent;
  • A measure of consistency with schedule.

(2) Process indicators

  • Enable the software engineering organization to gain insight into the efficacy of an existing process (e.g. templates, software engineering tasks, work products, and milestones);

  • Enabling managers and developers to evaluate what works and what doesn’t;

  • Process Metrics are collected across all projects and over long periods of time to obtain Metrics that improve software processes.

2, project

(1) Project measurement

  • The first application of measurement for most software projects occurs during estimation;
  • Metrics gathered from past projects can be used as a basis for estimating the effort and time of current software projects;
  • Measures of effort and time spent can be compared with estimates, and project managers use these data to monitor and control the progress of the project.

(2) Purpose of project measurement

  • Can guide necessary schedule adjustments to minimize development time by avoiding delays and minimizing problems and risks;

  • Project metrics assess quality on an as-is basis and modify technical methods to improve quality as necessary.

(3) Project indicators

  • Assess the status of ongoing projects;
  • Tracking potential risks;
  • Identify problems before they take a toll;
  • Adjust workflow or tasks;
  • Assess the project team’s ability to control the quality of software engineering work products.

Fourth, the way of measurement

1. Measurement in the physical world

(1) Direct measurement — for example, measuring the length of a bolt;

(2) Indirect measurement — for example, using defective rate to measure the quality of bolts produced.

2. Software measurement

Software measurements, like physical measurements, fall into two categories.

(1) Direct measurement

Process – Direct measurement of software engineering processes includes cost and effort invested;

Product – Direct measurements of software products include lines of code (LOC) generated, execution speed, memory size, and the number of errors reported during a certain time period.

(2) Indirect measurement

Product – Indirect measures of software products include functionality, complexity, efficiency, reliability, maintainability, and many other quality characteristics.

5. Scale – oriented measurement

1, define,

(1) Scale-oriented measurement is the direct measurement of software and software development process;

(2) A scale-oriented data table can be created to record some information about the project.

2. Calculation of useful metrics — illustrated by examples

project LOC The workload The cost of Document pages error defects personnel
Alpha 12100 24 168 365 134 29 3
Beta 27200 62 440 1224 321 86 5
Gamma 20200 43 314 1050 256 64 6

Q: This table lists every software development project completed in the past few years and the corresponding scale-oriented data about those projects. So, ① what useful information can be obtained from this table? ② Which of the three projects has the highest software quality? ③ Which project has the highest productivity? ④ Which project has the highest unit cost?

Note: LOC stands for Line Of Code, indicating the number Of lines Of Code; A PM is a Person Month.

It is important to note that the effort and cost recorded in the table are total software engineering activities (analysis, design, coding, and testing), not just coding activities;

For each project, simple scale oriented measures such as productivity and quality can be calculated based on the basic data listed in the table.

A: From the table you can calculate the following useful metrics for all projects:

Productivity = KLOC/PM(person-month); (proportional to)

Mass = number of errors/KLOC; (proportional to)

Quality = number of defects /KLOC; (inversely proportional)

Cost = yuan/LOC; (proportional to)

Documents = Pages of documents/KLOC. (proportional to)

6. Feature-oriented metrics

1, define,

(1) Function-oriented software measurement is the indirect measurement of software and software development process;

(2) Function-oriented measures mainly consider the “functionality” and “utility” of the program, rather than the LOC count;

(3) This measure is a productivity measure called function point method, which derives function point FP by using some counts and empirical relations of software complexity estimation in software information domain.

2. Calculation of function point measurement

(1) Legend

Need to know the following formula:

①FP= x (0.65+0.01 σ Fi); ③ X = x (0.65+0.01 σ Fi);

② “0.65+0.01 x σ Fi” : complexity adjustment factor.

Note:

  • FP stands for Function Points;

  • The total value is the sum of all weighted counting terms; Related to five information fields, namely input, output, query, file, interface, and need to consider the weighting factor;

  • Fi is a complexity correction value and requires 14 questions to be answered. See point (3) below for details

(2) Five information domains

  • User input: Each user input is the input data for different applications.
  • User output: Each user output is application-oriented output, including reports, screen information, and error information. Data items in a report should no longer be counted separately;
  • User query number: query is an online interactive operation, each different query to be counted;
  • File count: Each logical master file should be counted. A logical master file is a logical set of data, which can be part of a large database or a single file.
  • Number of external interfaces: Counts the number of reads and writes through external interfaces with other devices.

(3) Calibration value Fi for complexity

  1. Does the system require reliable backup and recovery?
  2. Do you need data communication?
  3. Is there distributed processing capability?
  4. Is performance the key?
  5. Is the system running in an existing highly practical operating environment?
  6. Does the system require online data items?
  7. Do online data items require multiple window displays and operations to handle input processing?
  8. Are main files updated online?
  9. Are inputs, outputs, files, queries complex?
  10. Is the internal process complex?
  11. Is the program code reusable?
  12. Are transfers and installations included in the design?
  13. Is the system designed to be repeatedly installed in different mechanisms?
  14. Is the system designed to be easy to modify and use?

(4) About calculation

① Once the above data is collected, the complexity value associated with each count can be calculated;

(2) Whether an information domain is simple, average (medium) or complex is determined by the mechanism using the function point method to calculate the weighted count;

③ To calculate function points, use the following calculation formula:

FP= total value ×[0.65+0.01 × ∑(Fi)], total value is the sum of all weighted counting terms;

(4) Fi (I = 1.. 14) are complexity correction values, which should be determined by answering each of the 14 questions, see point (3) for details;

③④ Points of attention:

  • The value of Fi ranges from 0 to 5:0, indicating no impact. 1 means small effect; 2 indicates mild; 3 indicates a medium level. 4 represents significant; 5 means significant;

  • Sigma Fi is a summation function.

(5) Once function points are calculated, productivity, quality and other attributes of software can be measured in the manner of LOC by the following formula:

Productivity = FP/PM (person-month); (proportional to)

Mass = number of errors/FP; (proportional to)

Quality = number of defects /FP; (inversely proportional)

Cost = yuan/FP; (proportional to)

Documents = number of pages of documents/FP; (proportional to)

(5) Software measurement based on FP

  • Errors per FP — quality

    Defects per FP — Quality

  • Cost per FP ($per FP) – cost

  • Pages of Documentation per FP — documents

  • FP per person-month — Productivity

(6) Think more

The relation between function point FP and the total value, the minimum value is () x total value, the maximum value is () x total value.

If the total complexity adjustment value of the 14 questions is 42 and the total value is assumed to be 100, then the function point FP value is ___.

Resolution:

  • The minimum value is 0.65x total value and the maximum value is 1.35x total value.

  • Function point FP = total value ×[0.65+0.01 × ∑(Fi)] = 100 x (0.65 +0.01 x 42) = 100 x 1.07 = 107

3. Extended function point metrics — feature points

(1) Basic knowledge

(1) Extended function point is also called feature point measure, which is another function point measure;

(2) Function point measurement is mainly used in business information system applications at first;

③ Emphasize data dimension and exclude functional dimension and behavior (control) dimension;

④ Therefore, function point measurement is not suitable for many engineering and embedded systems (which emphasize function and control).

(2) Feature points

The superset of function point measurement is suitable for applications with high algorithm complexity, mainly used in systems and engineering software applications, such as real-time systems, process control software and embedded software applications.

(3) Calculation of feature points

It can be seen from the figure above:

① A new software feature is added on the basis of the FP information field value calculation, that is, algorithm — a defined computing problem contained in a specific computer program;

② In the calculation of feature points, the weight is fixed, while in the original calculation of function points, the weight has three values: simple, average and complex.

PS: Weight is the weighting factor

4. Reconcile the different measures

Q: If I know the number of LOCs, is it possible to estimate the number of function points (FP)?

A: The relationship between lines of code and function points depends on the programming language and design quality used to implement the software.

So what is the average number of lines of code required to build a function point for different programming languages?

As shown below:

See here, do you have some understanding of the function point?

Ask yourself, if developing an information system requires 56,000 lines of VB code and 3000 lines of SQL code, what is the function point (FP) of the system?


56000 L O C 47 L O C / F P + 3000 L O C 40 L O C / F P material 1192 + 75 = 1267 a \frac{56000 LOC}{47 LOC/FP}+\frac{3000 LOC}{40 LOC/FP} ≈ 1192+75 = 1267

Seven, software quality measurement

1. Measurement of software quality

Quality measurement runs through the whole process of software engineering and after software is delivered to users.

(1) Pre-delivery measurement

  • Metrics obtained prior to software delivery can be used to judge the quality of design and testing;
  • Such measures include program complexity, effective modularity, and total program size.

(2) Post-delivery measurement

  • Measurement after software delivery focuses on the number of undetected defects and the maintainability of the system;

2. Measurement indicators of software quality

In order to achieve real-time quality assessment, engineers must use technical measurements to objectively assess quality rather than a subjective approach. Four objective measures are listed below:

(1) Correctness (most important)

  • A program must run correctly and provide some output to its users;
  • Correctness requires the software to perform the required function;
  • The most common measurement of correctness is Defects per KLOC, defined as “where the results of the validation do not match the requirements.”

Think about:

Q: Is it better to have as many defects as possible or as few as possible?

A: The higher the number of defects, the lower the software quality; So the number of defects should be as small as possible.

(2) Maintainability

  • Maintainability refers to the ease with which a program can be modified in the event of an error. Maintenance takes more work than other activities and cannot be measured directly.

  • Time oriented:

    A simple time-oriented metric, called MTTC (Average Change time), can be used as a measure of maintainability;

    This time includes analyzing change requirements, designing appropriate changes, implementing and testing the changes, and sending the changes to all users.

  • Cost-oriented:

    There is also a cost-oriented maintainability measure called damage, which refers to the cost of fixing a bug after the software is released to end users.

Think about:

Q1: The lower the MTTC, the better or worse the maintainability?

A1: MTTC is the average change time, the less the change time, the better the software quality; Therefore, the lower the MTTC, the better the maintainability.

Q2: Is it possible to increase corruption as the number of defects per thousand lines of code decreases?

A2: Damage is the cost of encountering a defect.

Here’s an example:

Suppose in a software, encountered 50 defects, these 50 defects are very small, very subtle problems, can be fixed quickly, then the cost is not very high;

Or in another software, encounter 5 defects, these 5 defects are 5 very significant bug problems, need a lot of time to repair, then the cost will be very high, that is, the damage degree increased;

Therefore, a low defect count does not necessarily mean a low cost, which means that as the number of defects per thousand lines of code decreases, the damage is likely to increase.

(3) Completeness

  • Integrity is to measure the ability of a system to resist attacks in terms of security.
  • All three components of the software, programs, data and documents, were attacked;
  • To measure integrity, two additional attributes need to be defined: hazard and security;
  • Hazard is the probability that a particular type of attack will occur at a given time;
  • Security is the probability of excluding a particular type of attack;
  • The integrity of a system can be defined as the integrity = ∑ [1- hazard ×(1- security)] where the risk and security of each attack are accumulated.

Think about:

Q: If an attack is 70% dangerous and 40% secure, what is its integrity?

A: integrity = ∑ [1 – x (1 -) safety risk] = 1 – (1 -) 0.4 0.7 = 1-0.7 x0.6 = 1-0.42 = 0.58

Imagine a system with integrity of 0.58. Does it qualify?

The answer, of course, is no. How can a piece of software fail to pass even the basic 60%?

(4) Availability

If a program is not “user-friendly,” it will often fail, even if the function it performs is valuable. Usability quantifies “user friendliness” and measures it based on four characteristics:

  • The physical and intellectual skills needed to learn the system;
  • The time required to achieve moderately effective use of the system;
  • A net increase in productivity measured when software is used moderately efficiently by someone;
  • Subjective evaluation of the system from the user’s perspective (which can be obtained through the question questionnaire).

Eight, DRE

1. Full name of DRE

DRE stands for Defect Removal Efficiency.

2. Two ways to measure DRE

(1) the DRE = E/(E + D)

  • DRE is a measure of the ability to filter defects in quality assurance and control activities.
  • E is the number of errors discovered before the software is delivered to the end user, and D is the number of defects discovered after the software is delivered.

(2)
D R E i = E i / ( E i + E i + 1 ) DRE_i =E_i/(E_i+E_{i+1} )

  • DRE can also be used in a project to assess a team’s ability to detect errors before they are passed on to the next activity or task. In this case, we define DRE as:

namely . D R E i = E i / ( E i + E i + 1 ) Namely, DRE_i = E_i/E_ (E_i + {I + 1})
  • EiE_iEi is the number of errors found in software engineering activity I. Ei+1E_{I +1}Ei+1 is the number of errors found in software engineering activity I +1 that originate from errors that were not found in software engineering activity I.
  • EiE_iEi can be understood as the former activity and Ei+1E_{I +1}Ei+1 can be understood as the latter activity.

3, Think more

The software team delivers the software to the end user. In the first month of use, users found eight defects. Prior to delivery, the software team found 72 errors during formal reviews and all testing tasks. Then, the total defect elimination efficiency formula of the project is DRE=E/ (+), and the final result is ____ (written as a decimal point).

Resolution:

  • The formula of total defect elimination efficiency of the project is DRE=E/(E+D);

  • The final result is DRE = 72 / (72 + 8) = 0.9.

Ix. Concluding remarks

So much for software metrics in software project management!

If you have any questions or the article is wrong, please leave a message in the comment area or send a private message to me

  • Pay attention to the public number Monday lab, the first time to pay attention to technical dry goods, more selected columns with you unlock ~

  • If this article is useful to you, be sure to like it and follow it