In software development, the fundamental purpose of software metrics is to manage the needs. Use metrics to improve the software process. People are unable to manage things that cannot be measured. In the history of software development, we can realize that the software crisis faced by large software in the late 1960s reflects the importance of management in software development. For management personnel: There is no management of the visibility of the software process; there is no appropriate metric or appropriate criterion to seek, assessment, and decisions, and unable to manage excellent management. We say that the methodology of software engineering is mainly provided in terms of visibility. But only the improvement of methodology does not make it become engineering disciplines. This requires measuring. Metrics are comparable objects available for decision making. Measure known things are for tracking and evaluation. For unknown things, the metric is used for prediction. This topic will discuss some basic issues of software metrics. However, it should be recognized that the results of software metrics are very preliminary, and a lot of work may be required to truly practical use, but its practical achievements will have an unbeatable impact on software's high quality and high-speed development. Then, one, what is a metrology? In the economic sector, the metrics determine the increase in price and payment; in the radar system, the metrics allow us to detect the aircraft through the cloud layer; in the medical system, the metrics make it able to diagnose certain special diseases; in the weather prediction system, metrics It is the basis of weather forecasting; there is no measurement, and the development of technology cannot be carried out. The formal definition of metrics is: Metrics refer to the world in the real world, specify a number or symbol to an entity,
To describe them in this way, they are described in terms of clear rules.
Therefore, the metrics are concerned about obtaining information about entity attributes. An entity can be a real thing, such as a person or a room; or an event, such as a trip; or a test phase of the software project. The attribute is the characteristics or characteristics of the entities we have focused, such as the height of blood pressure (humans), time (test phases), range or color (room), spending (travel), etc. Therefore, saying that "metric" or "metrics" statement is incomplete; "Measure matter properties" should be said. The "measurement room" said that it is blurred; we can say a measure of its length, range, and temperature. Also say "metric temperature" is also blurred, it should be said: We measures a certain specific geographical location and temperature in a particular case. ===> 2
2. Engineering disciplines require metric software projects to have models and theoretical support methods.
For example, we apply Ohm's law when designing circuits. This law describes the relationship between resistance, current, and voltage in the circuit. However, these theories have exceeded the scope of scientific methods in general, and the most basic things in this category are metrics. In addition to the development of a theoretical process, we use metrics and apply them. Therefore, when designing a specific current and resistance, we know how much voltage needs.
If there is no measure, we are hard to imagine that the law of electronics, machinery, and ordinary engineering can be developed. But in fact, the metrics in the mainstream of software engineering are ignored.
The current situation is:
■ When we are designing and developing software products, we have failed to develop an active goal. For example: We guarantee that we will make user interface friendship, reliable, easy to maintain; do not use metrics to specify their specific meaning. Gilb has said: The so-called fuzzy target theorem is that there is no clear target that will not explicitly reach its goal.
■ We failed to perform effective metrics for each different part of the actual cost of the software project. For example, usually we don't know, and how much time is spent in the design phase compared to the test phase.
■ We have not tried to make the products we develop products are qualified. Therefore, we have failed to use terminology (such as using the possibility of failure in a period of time), the product is installed into a new environment, etc.) The product has a high reliability to the potential user.
■ We always try to convince yourself using another new innovative development technology and method for software development
In fact, our work in software measures is very small, and the work in metrics is also separated from the metrics in general scientific sense. We often see such words: "Software costs have 80% of the maintenance." Or "Software has 55 bugs in each thousand lines.". But these words did not tell us how the results were produced, how the test is designed, executed, and the measure is that entity, and what is wrong with the wrong frame. Without these things, we can't objectively perform repeated measuring and reproducible results in our own environment to obtain real comparisons with industry standards. Therefore, it is due to the problem of unsuitable problems due to lack of strict metric. In addition to conventional performance of computer hardware, the metrics of the complexity of the algorithm have always been an important part of computer science. However, this metric method only applies to the applet, and it is powerless to large, complex software. This belongs to the scope of software engineering. If we don't recognize the metrics, the software crisis will still exist in subsequent years.
Third, the scope of software measurement research
Now we already know that software engineering needs metrics. How to perform metrics is obvious. First we must figure out that "Software Measure" is a term that contains a lot of completely different activities. It mainly includes:
Fees and workload estimation models and metrics
Production rate metrics and standards
Quality control and guarantee
data collection
Quality model and metrics
Reliability model
Performance evaluation and model
Algorithm / computational complexity metrics
Structure and complexity metrics
GQM Method (Goal / Question / Metric)
Other
In this topic, we will briefly introduce the above aspects to make readers a general understanding of the methods and techniques currently being used. The order of these aspects is not arbitrary. It reflects the order of the most basic things that are high-level, high goals to their dependence when software metrics
