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.
分享到:
相关推荐
这就是为什么“Source统计工具Counting”能够成为开发者和项目管理者手中利器的原因。 Source统计工具Counting是一款专门设计用于分析编程源代码的实用工具。它具备多种功能,其中最核心的能力在于统计源代码中不同...
These practices are a compilation of acceptable proce- dures for cycle-counting methods employed in fatigue analysis. This standard does not intend to recommend a particular method.
论文Attentional Neural Fields for Crowd Counting,侵删
- **Counting the Bits and Blocks of a Word**: Methods for counting the number of set bits and blocks in a word. - **Words as Bitsets**: Treating words as sets of bits for efficient data ...
这篇文章的标题是《Multi-Source Multi-Scale Counting in Extremely Dense Crowd Images》,其主要内容是介绍了一种在极密集的人群图像中利用多重信息源和多尺度分析来计算人数估计的方法。这一技术在计算机视觉...
Matlab Hill代码目录 问题 一家报纸编辑正在研究过去几年中有关H1B(H-1B,H-1B1,E-3)签证申请处理的移民数据趋势,试图确定获得批准的H1B签证数量最多的职业和州。 她从美国劳工部及其部门获得了统计数据。...
cd Car_counting_MobileNetSSD .\env\Scripts\activate.bat pip install -r requirements.txt 运行脚本 不保存已处理的素材: python car_counting.py -v test_video.mp4 保存已处理的素材: python car_...
The use of function points, as a measure of the functional size of software, has grown in the past decade from a few interested organizations to an impressive list of organizations worldwide. ...
《3D人员计数实施指南》是针对使用毫米波雷达技术进行三维人体计数的软件实现文档,由德州仪器(Texas Instruments)发布。本指南详细介绍了如何设置演示系统,以及利用SDK组件进行3D人员计数的具体步骤。...
此代码是来自 Alceu Costa 的原始实现的 Box-Counting Fractal Dimension 计算的另一种实现https://www.mathworks.com/matlabcentral/fileexchange/30329-hausdorff--box-counting--fractal-dimension 。 它比原始...
- **Counting the Bits and Blocks of a Word**: Methods for counting the number of set bits or specific patterns. - **Words as Bit Sets**: Representing and manipulating sets using binary words. - **...
This topic discusses algorithms for counting the number of set bits or blocks within a word. These are fundamental operations in many computing tasks. #### 1.9 Words as Bitsets Here, the concept of ...
21.5 A USER INTERFACE FOR UNDOING AND REDOING 711 21.6 DISCUSSION 712 21.7 BIBLIOGRAPHICAL NOTES 715 EXERCISES 715 Chapter 22: How to find the classes 719 22.1 STUDYING A REQUIREMENTS DOCUMENT 720 ...
The maximum row size for the used table type, not counting BLOBs, is 65535 向mysql的表插件一个字段 类型为text时,或修改一个字段类型为text时,报出上面的错误。其实我对这个错误的原因理解也不是很深,给...
A project model for the FreeBSD Project Niklas Saers Copyright © 2002-2005 Niklas Saers [ Split HTML / Single HTML ] Table of Contents Foreword 1 Overview 2 Definitions 2.1. Activity 2.2. Process ...
代码挺短,短加引号
A New Software Paradigm Java's Architectural Support for Network-Mobility The Applet: An Example of Network-Mobile Java The Resources Page Part Two: Java Internals 5 The Java Virtual Machine What ...
, as a measure of the functional size of software, has grown in the past decade from a few interested organizations to an impressive list of organizations worldwide. The IFPUG function point ...
There were also a lot of interesting problems in the book that the author goes through, including counting paths, etc.