Measurement is commonplace in the engineering world. Software engineering, however, is far from developing a widely accepted standard measurement with results free from subjective factors. There are disagreements about what to measure and how to evaluate the results obtained from the measurements. Software metrics enable one of the most fundamental activities in the project management process: planning. From this, it is possible to identify the amount of effort, cost, and activities that will be necessary to carry out the project. From a measurement perspective, software metrics can be divided into two categories: direct and indirect measures. We can consider as direct measures of the software engineering process the cost and effort applied to the development and maintenance of the software and the product, the number of lines of code produced, and the total number of defects recorded during a given period of time. However, the quality and functionality of the software, or its maintainability, are more difficult to evaluate and can only be measured indirectly. We can also divide software metrics, from an application perspective, into two categories: productivity and quality metrics. Productivity metrics focus on the output of the software engineering process. Quality metrics indicate how well the software meets the requirements defined by the user. Direct Measures: Cost, Effort, Lines of Code, Execution Speed, Memory, Number of Errors, Cyclomatic Complexity. Indirect Measures: Functionality, Quality, Complexity, Efficiency, Reliability, Maintainability. For a better understanding of software metrics, we need to understand some information: Measure: a quantitative indication of the extent, quantity, dimension, capacity, or size of the product or process. Measurement: the act of determining a measure. Indicator: A metric or combination of metrics that provides understanding of the software process, a project, or the product. Software measurements can be organized into other classes, which will be defined below: Productivity metrics, based on the output of the software development process with the objective of evaluating the process itself; Quality metrics, which allow indicating the level of responsiveness of the software to the explicit and implicit requirements of the client, in relation to what is defined by quality management; Technical metrics, which include aspects such as functionality, modularity, maintainability, etc. From another perspective, it is possible to define a new classification of measurements: Size-oriented metrics, based on direct measurements of Software Engineering; Function-oriented metrics, which offer indirect measures; People-oriented metrics, which give indications about how people develop computer programs. Size-Oriented Metrics The most familiar software metric is the line count. This metric may seem simple, but there is disagreement about what constitutes a line of code. The line count should not include comment lines and blank lines, as this does not affect its functionality. It is strongly linked to the programming language used, making it impossible to use historical data for projects that do not use the same language. A set of quality and productivity metrics can be developed with this technique. Function-Oriented Metrics Instead of counting lines of code, the function-oriented metric focuses on the functionality of the software. In 1979, Allan Albrecht introduced an evaluation technique known as Function Point. Based on the user's business perspective, it is independent of the programming language used and any technology in general. It does not allow for the calculation of development effort, but it generates a variable that can allow for its calculation. It helps the end user improve the examination and evaluation of projects. Its objectives are: To measure what was requested and received by the user; To provide a measurement metric to support productivity and quality analysis; To provide a way to estimate the size of the software; To provide a normalization factor for software comparison. Reasons for measuring software: To indicate the quality of the product; To evaluate the productivity of those who develop the product; To determine the benefits derived from new software engineering methods and tools; To form a basis for estimates; To seek opportunities for refactoring; To help justify the acquisition of new tools or additional training. Measurement is common in the world of engineering. But for software engineering, there is still a long way to go before there is a widely accepted standard measurement with results free from subjective factors. Undoubtedly, the most significant increase in productivity will be achieved when we manage to establish a meaningful system of metrics for software development results and effectively use it.