《Software Size Measurement: A Framework for Counting Source Statements》
1、（P13）
the following SEI reports:
- Software Effort & Schedule Measurement: A Framework for Counting Staff-Hours and Reporting Schedule Information (CMU/SEI-92-TR-21)
- Software Quality Measurement: A Framework for Counting Problems and Defects (CMU/SEI-92-TR-22)
- Software Measures and the Capability Maturity Model (CMU/SEI-92-TR-25)
- Software Measurement Concepts for Acquisition Program Managers (CMU/SEI-92-TR-11)
- A Concept Study for a National Software Engineering Database (CMU/SEI-92-TR-23)
- Software Measurement for DoD Systems: Recommendations for Initial Core Measures (CMU/SEI-92-TR-19)
2、（P13）
Like the reports listed above, this one contains guidelines and advice from software professionals. It is not a standard, and it should not be viewed as such. Nevertheless, the framework and methods it presents give a solid basis for constructing and communicating clear definitions for two important measures that can help us plan, manage, and improve our software projects and processes.
3、（P13）
We hope that the materials we have assembled will give you a solid foundation for making your size measures repeatable, internally consistent, and clearly understood by others. We also hope that some of you will take the ideas illustrated in this report and apply them to other measures, for no single set of measures can ever encompass all that we need to know about software products and processes.
4、（P19）
Abstract. This report presents guidelines for defining, recording, and reporting two frequently used measures of software size—physical source lines and logical source statements. We propose a general framework for constructing size definitions and use it to derive operational methods for reducing misunderstandings in measurement results. We show how the methods can be applied to
address the information needs of different users while maintaining a common definition of software size.
This report presents methods for reducing misunderstandings and inconsistencies when recording and reporting measures of software size.
5、（P20）
Our objective is to provide operational methods that will help organizations obtain clear and consistent reports of software size.
The goal of our methods is to reduce ambiguities and misunderstandings in reported measures of size.
To remove these ambiguities, we have developed a framework that helps us describe software size measurements in ways that are both complete and explicitly communicated. We have applied this framework to construct examples of specifications for collecting and reporting two measures of source code size—physical lines and logical source statements.
Good definitions and good specifications require attention to detail.
6、（P23）
The measurement framework we propose in this report makes extensive use of checklists. These checklists provide operational methods for constructing and communicating clearly understood definitions of software size measures (our primary objective).
Before defining any measure, we should always ask “Why do we want the information we propose to collect, and how will we use it?” The answers to these questions become our measurement objectives, and each objective will have its own coverage requirements and information needs. Checklists like those in this report give us a means for addressing and defining the rules that we follow to meet these needs.
In developing our framework and checklists, we have been guided by two principal criteria:
• Communication: If someone uses our methods to define a measure or describe a measurement result, will others know precisely what has been measured and what has been included and excluded?
• Repeatability: Would someone else be able to repeat the measurement and get the same result?
7、（P24）
These criteria and steps have led us to four kinds of instruments for defining, recording, and reporting software size measurements—definition checklists, supplemental rules forms, data recording forms, and reporting forms.
8、（P25）
The methods we propose for constructing size definitions start with a checklist. The checklist identifies the principal attributes of our target size measure. Principal attributes are characteristics important to the different people who will use the measurement results. Examples of attributes of familiar objects include properties such as length, weight, height, volume, density, color, source language, location, origin, destination, function performed, author, and status. For each attribute of our target measure, we identify the values that the attribute can take on. In each case, these values should be both exhaustive (complete) and mutually exclusive (nonoverlapping).
With this in mind, we have found it useful to provide blank lines in checklists so that organizations can add other attribute values to meet local needs.
9、（P27）
Although these examples represent consensus views, readers should keep in mind that there are no universal “best” choices when completing a definition checklist. Instead, each choice should be made so as to serve an organization’s overall measurement needs. This almost always involves tradeoffs between the benefits to be gained (based on how the measurement results will be used) and the difficulties associated with applying the definition to collect data from real software projects.
2.2. Supplemental Rules Forms
Sometimes definition checklists cannot explain all the rules and practices that must be made explicit to avoid ambiguities and misunderstandings. In these instances, we recommend constructing specialized forms to spell out the additional rules. There are three instances where we have found this ecessary:
- When defining rules for distinguishing among different statement types while countingphysical source lines.
- When defining the delimiters and rules used to identify beginnings and endings ofdifferent kinds of logical source statements.
- When describing procedures used to find and identify dead code, so that only operative software is included in system size.
10、（P31）
To help maintain this consistency, we have used the term source statements to refer to both
physical source lines and logical source statements.
11、（P33）
The checklist in Figure 3-2 uses nine attributes to describe and bound the kinds of software statements included in a measure of source code size. The attributes are: Statement type, How produced, Origin, Usage, Delivery, Functionality, Replications, Development status, and Language .
12、（P41）
Our discussions follow the order in which the topics appear in the checklist. The sequence
is:
- Statement type
- How produced
- Origin
- Usage
- Delivery
- Functionality
- Replications
- Development status
- Language
- Clarifications (general)
- Clarifications for specific languages
（P49）
4.2.4 拷贝或无任何变化的重用
拷贝的行和语句是指那些逐字地从别处的源代码拿来，并作为主源代码（master source code）的一部分，生成新的产品。这一分类仅适用于拷贝自已存在（或重用）的语句，对于拷贝自主源代码（master source code）并用于生产新产品的语句被划分并计数在“复制”（Replications）属性下的“copies of master statements physically repeated in the master code.”。
既然“拷贝”是指语句而不是模块，那么该词就不和“移走的”或“修改的”不冲突。如果一些语句是移走的或者其它的是修改的，那么，只有剩余的未做任何改变的语句被归类为拷贝。移走的和修改的语句被记录在它们自己的类别里。
4.2.5 修改的
修改是针对预先存在的语句（pre-existing statements），它们被用在新产品、新build或新的release中。通过除自动转换外的某种行为，被我们修改并保留下来的预先存在的语句，被计为修改的代码。
修改的语句不包括被移走的语句，也不包括作为修改过程的一部分被新增的语句。
修改的语句也不包括被移动位置的语句。例如，如果我们将七行代码从模块底部移到模块顶部，我们将其计数为七行拷贝语句。
一些组织通过以下做法试图简化被修改代码行的识别和计数：如果一个模块被修改了，那么如有X%或更多的行被修改，将其计为新代码，否则为修改的代码。X可以取25、30或50。
4.2.6 移除的
移除的是指，当代码被拷贝或修改后用于新的或修订的产品过程中，被从先前代码中移除的部分。
严格的讲，移除的语句不属于软件规模定义的范畴，因为移除的代码根本不是产品的一部分。为了和IEEE 1045-1992保持一致，我们才提到它。
虽然，本框架没有提到删除的（deleted），但要重申删除的等于修改的加移除的。deleted = modified + removed
4.7.1
主源代码语句（master source statements）是指，当修订时，需要对其进行修改的源代码语句。
12、（P115）
6.3. Physical Source Lines
Physical source statements are source lines of code: one physical line equals one statement. The delimiter—or, more precisely, the terminator—for physical source statements is usually a special character or character pair such as newline or carriage return--line feed. When dealing with source code files, the particular delimiter used depends on the operating system. It is not a characteristic of the language.