2004计算机软件工程考研串讲之五

作者名：不详　来源：网友提供 06年6月8日

1）进化式原型开发
基本思路是：先给出一个系统的最初实现，让用户去使用和评价，不断进行细化和改善，经过多次这样的反复过程后形成最终的完善的系统。
2）抛弃式原型开发
基本思路是：原型的根本作用是弄清楚需求和为风险评估提供补充信息。通过评估后，原型被抛弃，重新规划和实施系统的开发。
质量保证的概念
什么是质量保证？ISO/IEC 12207:1995指出：它是为了提供足够的信任证据，证明组织有关的各类实体有能力满足质量要求所进行的有计划、有组织的活动。
质量保证的目的是
内部质量保证：在组织内部向管理者提供信任保证；
外部质量保证：向顾客或第三方认证提供信任保证；
软件质量保证过程
ISO/IEC 12207:1995指出：软件质量保证过程（SQA）是恰当保证为项目生存周期中的软件产品和过程符合规定需求和已制定计划提供足够保证的过程。
软件质量保证过程包括4方面的活动：
过程实施
产品质量保证
过程质量保证
质量保证体系的质量保证

软件质量保证体系
软件的质量保证活动，是涉及各个部门的部门间的活动。
为顺利开展质量保证活动，必须事先明确部门间的质量保证业务，确立部门间的联合与协作的机构，这个机构就是质量保证体系。
必须明确反馈途径。
必须明确各部门的职责。
必须确定保证系统运行的方法、工具、有关文档资料，以及系统管理的规程和标准。

必须明确决定是否可向下一阶段进展的评价项目和评价准则。
必须不断地总结系统管理的经验教训，能够修改系统。
软件质量保证规程和技术准则
规定在项目的哪个阶段进行评审及如何评审；
规定在项目的哪个阶段应当产生哪些报告和计划；
规定产品各方面测试应达到的水平；

规定在每次评审和测试中发现的错误如何修正；
描述希望得到的质量度量；
说明各种软件人员的职责，规定为了达到质量目标他们必须进行哪些活动；
建立
在各阶段中执行质量评价的质量评价和质量检查系统
有效运用质量信息的质量信息系统，并使其运行。
CMM 2级 KPA SQA 介绍
CMM 2级SQA关键过程域包括 4 个目标和 17 项关键实践。4 个目标分别是：
目标1 软件质量保证活动是有计划的。
目标2 软件产品和活动遵循适用的标准、规程和需求的情况得到客观的验证。
目标3 受影响的组和个人得到软件质量保证活动和结果的通知。
目标4 高级管理者处理在软件项目内部不能解决的不符合问题。

仅当这 4 个目标都已经达到才能说已经满足关键过程域 SQA 的要求。
这些目标的实现依赖于 8 项活动的实施，并需要其他方面的关键实践来支持。
8 项执行活动是：
AC1 按归档化规程为软件项目制定软件质量 保证计划（SQAP）。
AC2 按计划进行 SQA 组的活动。
AC3 参与制定软件开发计划、标准和规程。
AC4 评审软件工程活动。

AC5 审核指定的软件工作产品。
AC6 定期向软件工程组报告其活动结果。
AC7 按归档化规程处理评审和审核中发现的偏差并建立文档。
AC8 必要时 SQA 组和顾客的 SQA 组一起评审自己的活动与发现。

其他关键实践
执行约定
组织应制定实施 SQA 的方针并要求项目遵守。
对于全部项目，SQA 功能到位；
SQA 有向高级管理者报告的渠道；
高级管理者定期评审 SQA 活动和结果。
执行能力
有 4 个关键实践，说明为有效地实施 SQA 所必需具备的保证条件。

存在负责协调和实施项目的SQA组。
为进行 SQA 活动提供足够的资源和资金。
对 SQA 组的成员进行为完成 SQA 活动所必需的培训。
对软件项目成员进行有关 SQA 组的任务、职责、权利和价值等的定向培训。
测量和分析
必须测量 SQA 过程实施的状况，以便分析和确定 SQA 活动的成本和进度状态。
SQA 活动里程碑完成情况与计划比较。

SQA 所完成的工作、花费的工作量和消耗的资金与计划比较。
产品审核和活动评审的次数与计划比较。
验证实施
有 3 项关键实践，对 SQA 活动进行不同层次的验证。
高级管理者定期参与评审 SQA 活动。
项目经理定期地，而且事件驱动地参与评审 SQA 的活动。
独立于 SQA 组的专家定期评审项目 SQA 组的活动和软件工作产品。

软件配置管理
ISO 9000-3:1997 的定义：配置管理是一个管理学科，它对配置项（包括软件项）的开发和支持生存周期给以技术上和管理上的指导。配置管理的应用取决于项目的规模、复杂程度和风险的大小。
W.Babich的解释：软件配置管理能够协调软件的开发，使混乱减少到最小。软件配置管理是一种标识、组织和控制修改的技术，目的是最有效地提高生产率。

GB/T 11457:1995《软件工程术语》定义：
表示和确定系统中配置项的过程，在系统整个生存周期内控制这些配置项的投放和变更，记录并报告配置的状态和变更要求，验证配置项的完整性和正确性。
对下列工作进行技术和行动指导与监督的一套规范。
对配置项的功能特性和物理特性进行标识和文档编制工作。
控制这些特性的变更情况。

记录并报告对这些变更进行的处理和实现的状态。
软件配置管理的任务
制定软件配置管理计划
确定配置标识的规则
实施变更控制
报告配置状态
进行配置审核
进行版本管理和发行管理
制定配置管理计划
在软件工程项目制定开发计划时，应使开发计划中包括配置管理计划。
在配置管理计划中规定
配置标识的规则
如何建立项目数据库
如何将软件配置项置于配置管理之下
配置管理人员的职责和配置管理活动
采用什么样的配置管理工具、技术和方法。
软件配置项
按照ISO 9000-3的说明，软件配置项可以是：
与合同、过程、计划和产品有关的文档和数据；
源代码、目标代码和可执行代码；
相关产品，包括软件工具、库内的可复用软件、外购软件及用户提供的软件。
随着软件工程过程的进展，软件配置项(SCI) 数目快速增加。
软件配置标识
在实现软件配置管理时，把软件配置项(SCI)组织成配置对象，在项目数据库中用一个单一的名字来组织它们。
一个配置对象有一个名字和一组属性，并通过某些联系“连接”到其它对象。
每个对象与其它对象的联系用箭头表示。箭头指明了一种构造关系。
双向箭头则表明一种相互关系。

对象标识：
（名字、描述、资源、实现）
对象的名字明确地标识对象。
对象描述包括：SCI类型（如文档、程序、数据）、项目标识、变更和／或版本信息。
资源包括由对象产生的、处理的、引用的或其它需要的一些实体。
基本对象的实现是指向文本单元的指针，复合对象的实现为NULL。
变更控制
变更控制包括建立控制点和建立报告与审查制度。
首先用户提交书面的变更请求，详细申明变更的理由、变更方案、变更的影响范围等。
然后由变更控制机构确定控制变更的机制、评价其技术价值、潜在的副作用、对其它配置对象和系统功能的综合影响以及项目的开销、并把评价的结果以变更报告的形式提交给变更控制负责人。

对每个批准了的变更产生一个工程变更顺序（ECO），描述进行的变更、必须考虑的约束、评审和审计的准则等。
被变更对象从项目数据库中检出 (check out)，对其做出变更并实施适当的质量保证活动。然后再把对象检入 (check in) 到数据库中并使用适当的版本控制机制建立软件的下一版本。
变更必须经过某种正式的变更评价过程，以估计变更需要的成本和它对软件系统其它部分的影响。

如果变更的代价较小且对软件系统其它部分没有影响，或影响很小，通常应批准这个变更。
如果变更的代价较高，或者影响较大，必须权衡利弊，决定是否变更。
如果同意这种变更，需要进一步确定由谁支付变更所需的费用。如果是用户要求的变更，则用户应支付这笔费用；否则，必须完成某种成本／效益分析，以确定是否值得做这种变更。
这种变更报告和审查制度，对变更控制来说起了一个安全保证作用。
配置状态报告
为了清楚、及时地记载软件配置的变化，需要对开发的过程做出系统的记录，以反映开发活动的历史情况。这就是配置状态登录的任务。
登录主要根据变更控制小组会议的记录，并产生配置状态报告。
对于每一项变更，记录：发生了什么？为什么会发生？对谁做的？什么时侯发生的？会有什么影响？

配置状态报告可以放在一个联机数据库中，软件开发与维护人员可以对它进行查询或修改。此外在软件配置报告中新登录的变更应当及时通知给管理人员和软件工程师。
配置状态报告对于大型软件开发项目的成功起着至关重要的作用。避免了可能出现的不一致和冲突。
配置审核
软件的完整性，是指开发后期的软件产品能够正确地反映用户要求。
软件配置审核的目的就是要
证实整个软件生存期中各项产品在技术上和管理上的完整性。
确保所有文档的内容变动不超出当初确定的软件要求范围。使得软件配置具有良好的可跟踪性。
配置审核是掌握配置情况、进行审批的依据。
基线 (Baseline)
基线是软件生存周期中各开发阶段末尾的特定点，又称里程碑。
由正式的技术评审而得到的软件配置项协议和软件配置的正式文本才能成为基线。
基线的作用是把各阶段工作的划分更加明确化，以便于检验和肯定阶段成果。
一旦一个SCI成为基线，就把它存放到项目数据库中。

版本控制和发行管理
版本控制是软件配置管理的基础，它管理并保护开发者的软件资源。
版本控制管理在软件工程过程中建立起配置对象的不同版本并可以把一些属性结合到各个软件版本上。
通过描述所希望的属性集合来确定（或构造）所想要的配置。
使用演变图来表示系统的不同版本。

版本管理的主要任务
集中管理档案，安全授权机制 版本管理将开发组的档案集中地存放在服务器上，经系统管理员授权给各个用户。用户通过检入(check in)和检出(check out) 的方式访问服务器上的文件，未经授权的用户无法访问服务器上的文件。
软件版本升级管理 每次检入时在服务器上都会生成新的版本。同一应用的不同版本可以像树枝一样向上增长。

加锁功能 目的是在文件更新时保护文件，避免不同用户更改同一文件时发生冲突。某一文件一旦被检入，锁即被解除，该文件可被其它用户使用。在更新一个文件之前锁定它，避免变更没有锁定的项目源文件。
软件组织的软件配置管理过程
软件企业实施配置管理分为两个层次。
定义组织级的标准软件配置管理过程
规程：配置管理计划制定规程、变更管理规程、配置审核规程。
模板或表单：配置管理计划模板、变更请求表、配置审核检查表、配置审核不符合报告表。
准则：规程剪裁准则、配置库结构准则、

配置说明与报告准则、配置管理培训准则、软件配置管理工具选择与使用准则。
项目级软件配置过程
定义过程

依据组织的标准软件配置管理过程并参考用户及项目的特点，策划项目级配置管理过程，取得项目配置计划。
实施过程
确定项目软件配置管理人员职责；
选用或开发适用的配置管理工具；
对项目人员进行有关规程、模板使用及工具的培训；
按照配置管理计划开展配置管理工作。
CMM 2级 SCM KPA
软件配置管理是软件项目管理中必不可少的一个环节。软件配置管理作为一个关键过程域，其目的在于建立和维护在项目的整个生存周期中软件项目产品的完整性。
软件配置管理的关键过程域有 4 个目标和 19 个关键实践。4 个目标分别是：
目标1 软件配置管理活动是有计划的。
目标2 选定的软件工作产品是已标识的、受控的和可利用的。

目标3 对已标识的软件工作产品的变更加以控制。
目标4 受影响的组和人员都应得知软件基线的状态和内容。
仅当这 4 个目标都已经达到才能说已经满足关键过程域 SCM 的要求。
这些目标的实现依赖于 10 项活动的实施，并需要其他方面的关键实践来支持。
10 项执行活动是：

AC1 按照归档化规程为每一个软件项目制定软件配置管理计划。
AC2 以归档化和经批准的软件配置管理计划作为开展软件配置管理活动的基础。
AC3 建立配置管理库作为软件基线仓库。
AC4 对置于配置管理下的软件工作产品作出标识。
AC5 按归档化规程启动、记录、评审、批准和跟踪对所有配置项或单元的变更请求和问题报告。

AC6 按归档化规程控制基线的变更。
AC7 根据归档化规程由软件基线仓库中生成产品，并控制这些产品的发行。
AC8 根据归档化规程记录配置项或单元的状态。
AC9 编制记载软件配置管理活动和软件基线内容的标准报告，并使受影响的组和人员可以使用它。
软件配置控制委员会会议记录
变更请求的摘要和状态

问题报告的摘要和状态（包括问题解决情况）
软件基线变更的摘要
配置项或配置单元的修改历史
软件基线状态
软件基线审核结果
AC10 根据归档化规程进行软件基线审核。
目标和活动的对应关系见下表。

其他关键实践：
执行约定
项目应遵循软件配置管理的书面的组织方针。包括：
明确指派每个项目的 SCM 职责；

在项目的整个生存周期内实施 SCM；
对可交付的软件产品、指定的内部软件工作产品和指定在项目内部使用的支持工具（如编译器）都实施 SCM；
项目要设立一个基线库，用以存放配置项、配置单元和相关 SCM 记录；
定期审核软件基线和 SCM 活动。
执行能力
要设或组建一个有权管理项目软件基线的机构。其职责有：

审定软件基线的建立和配置项或配置单元的标识；
代表项目经理和所有可能受到软件基线变更影响的小组的利益；
评审和审定软件基线的变更；
评定由软件基线库获取产品的生成。
要设置一个负责协调和实施项目配置管理的小组，即 SCM 组。其职责有：
项目软件基线库的生成和管理；

SCM计划、标准和规程的制定、维护和分发；
标识在SCM控制之下的软件工作产品；
管理软件基线库的存取；
更新软件基线；
记录SCM活动；
生成和分发SCM报告。
为开展软件配置管理各项活动提供足够的资源和资金。

对 SCM 组人员进行实施软件配置管理的目标、规程和方法诸方面的培训。
对软件工程组和与软件相关的其他组成员进行有关软件配置管理活动的培训。
测量和分析
要进行测量，并将测量结果用于确定软件配置管理活动的成本和进度安排。
单位时间内处理的变更请求数；
软件配置管理活动的里程碑完成情况与计划比较；

软件配置管理活动中完成的工作、花费的工作量和消耗的资金与计划比较。
验证实施
高级管理者定期参与软件配置管理活动的评审。
项目经理定期地，并要在出现特定事件时参与软件配置管理活动的评审。
SCM组定期审核软件基线是否符合文档。
软件质量保证组（SQA）评审和审核有关SCM的活动和工作产品并报告结果
第八章 软件工程管理
软件工程管理的对象是软件工程项目。涉及的范围覆盖了整个软件工程过程。
为使软件项目开发获得成功，关键问题是必须对软件的项目范围、可能风险、需要资源 (人、硬件／软件)、要实现的任务、经历的里程碑、花费工作量 (成本)、进度安排等做到心中有数。
软件工程管理可以提供这些信息。
软件生产率和质量的度量
生产率与质量的度量是以投入工作量为依据的软件开发过程的度量和软件产品质量的度量。
面向规模的度量
面向功能的度量
软件质量的度量
软件度量分为两类：直接度量与间接度量。
软件过程的直接度量包括所投入的成本和工作量。

软件产品的直接度量包括产生的代码行数（LOC）、执行速度、存储量大小、在某种时间周期中报告的差错数。软件产品的间接度量包括功能性、复杂性、效率、可靠性、可维护性和许多其他质量特性。
软件生产率度量的焦点集中在软件工程过程的输出；软件质量度量则指明了软件适应明确和不明确的用户要求到什么程度；技术度量的焦点则集中在软件的某些特性（如逻辑复杂性、模块化程度）上而不是软件开发的全过程。
面向规模的度量
面向规模的度量是对软件和软件开发过程的直接度量。
可以建立一个面向规模的数据表格来记录项目的某些信息。该表格列出了在过去几年完成的每一个软件开发项目和关于这些项目的相应面向规模的数据。
需要注意的是，在表格中记载的工作量和成本是整个软件工程的活动（分析、设计、编码和测试），而不仅仅是编码活动。

对于每一个项目，可以根据表格中列出的基本数据计算简单的面向规模的生产率和质量的度量。
生产率 ＝ KLOC／PM（人月）
质量 ＝ 错误数／KLOC
成本 ＝ 元／LOC
文档 ＝ 文档页数／KLOC
面向功能的度量
面向功能的软件度量是对软件和软件开发过程的间接度量。
面向功能度量主要考虑程序的“功能性”和“实用性”，而不是对 LOC计数。
该度量是一种叫做功能点方法的生产率度量法，利用软件信息域中的一些计数和软件复杂性估计的经验关系式而导出功能点 FP。
面向功能的数据表格
功能点计算
确定五个信息域的特征，并在表格中相应位置给出计数。
用户输入数：各个用户的面向不同应用的输入数据。
用户输出数：各个用户输出包括报告，屏幕信息，错误信息等。在报告中的各个数据项不应再分别计数。
用户查询数：每次联机的询问 / 响应均应计数。

文件数：每一个逻辑主文件都应计数。
外部接口数：与系统中其他设备通过外部接口读写信息次数均应计数。
一旦收集到上述数据，就可以计算出与每一个计数相关的复杂性值。
一个信息域是简单的、平均的还是复杂的，由使用功能点方法的机构自行确定，从而计算出加权计数。
计算功能点，使用如下的关系式：

FP ＝ 总计数×(0.65＋0.01×SUM(Fi))
总计数是所有加权计数项的和；
SUM(Fi) 是求和函数: Fi（i＝1..14）是复杂性校正值，应通过逐一回答如下提问来确定。
F1 系统是否需要可靠的备份和恢复？
F2 是否需要数据通信？
F3 是否有分布式处理的功能？
F4 是否性能成为关键？
F5 系统是否运行在现有的高度实用化的
操作环境中？

F6 系统是否需要联机数据项？
F7 联机数据项是否需要建立多重窗口显示
和操作，以处理输入处理。
F8 主文件是否联机更新？
F9 输入、输出、文件、查询是否复杂？
F10 内部处理过程是否复杂？
F11 程序代码是否可复用？
F12 设计中是否包括了转移和安装？
F13 系统是否设计成可以重复安装在不同
机构中?
F14 系统是否设计成易修改和易使用？

复杂性校正值 Fi 的取值 0..5：
= 0 没有影响 = 1 偶然的
= 2 适中的 = 3 普通的
= 4 重要的 = 5 极重要的

一旦计算出功能点，就可仿照LOC的方式度量软件的生产率、质量和其它属性：
生产率 ＝ FP／PM（人月）
质量 ＝ 错误数／FP
成本 ＝ 元／FP
文档 ＝ 文档页数／FP

功能点度量是为信息系统应用而设计的。
特征点度量（Feature Points）可以用于系统和工程软件应用。特征点度量适合于算法复杂性高的应用。而实时处理、过程控制、嵌入式软件应用的算法复杂性都偏高，因此适合于特征点度量。
为了计算特征点，可以象功能点计算那样对信息域值进行计数和加权。但特征点度量还要对一个新的软件特征 “算法” 进行计数。

算法定义为“特定计算机程序中所包含的一个界定的计算问题。” 如转置矩阵、处理中断都是算法问题。
计算特征点可使用一个计算表格。对于每一个度量参数只使用一个权值，并且使用
FP＝总计数×(0.65＋0.01×SUM(Fi))
来计算总的特征点值。

特征点度量计算表格
软件质量的度量
质量度量贯穿于软件工程的全过程中以及软件交付用户使用之后。
在软件交付之前得到的度量可作为判断设计和测试质量好坏的依据。这一类度量包括程序复杂性、有效的模块性和总的程序规模。
在软件交付之后的度量则把注意力集中于还未发现的差错数和系统的可维护性方面。
使用得最广泛软件质量的事后度量包括正确性、可维护性、完整性和可使用性。

正确性：一个程序必须正确地运行，并为它的用户提供某些输出。正确性要求软件执行所要求的功能。正确性的度量是每千代码行(KLOC)的差错数，其中将差错定义为已被证实是不符合需求的缺陷。
可维护性：软件维护比其它的软件工程活动需要更多的工作量。还没有一种方法可以直接度量可维护性，必须采取间接度量。
一种简单的面向时间的度量: 平均变更等待时间MTTC。这个时间包括分析变更要求、

设计适当修改、实现变更并测试、把变更发送给所有用户。一个可维护的程序与不可维护的程序相比，应有较低的MTTC。
完整性：完整性度量一个系统抗拒对它的安全性攻击（事故的和人为的）的能力。程序、数据和文档都会遭到攻击。
度量完整性，需要定义两个附加的属 性：危险性和安全性。危险性是特定类型的攻击将在一给定时间内发生的概率，安全性是排除特定类型攻击的概率。

一个系统的完整性可定义为
完整性＝∑(1－危险性×(1－安全性))
可使用性：如果程序不具有用户友好性，即使它所执行的功能很有价值也常常会失败。用户友好性可依据以下四个特征进行度量：
学习所需的体力上的和智力上的技能；
为达到适度有效使用系统所需时间；
软件使用时在生产率方面的净增值；
用户角度对系统的主观评价。
程序复杂性度量
程序复杂性主要指模块内程序的复杂性。它直接关联到软件开发费用的多少，开发周期的长短和软件内部错误的多少。
程序复杂性度量的参数主要有：
规模 程序指令条数或源程序行数；
难度 与程序操作数和操作符有关的度量；
结构 与程序分支数有关的度量；
智能度 算法的难易程度。
代码行度量法
源代码行数度量法基于两个前提：
程序复杂性随着程序规模的增加不均衡地增长；
控制程序规模的方法最好是采用分而治之的办法。将一个大程序分解成若干个简单的可理解的程序段。

方法的基本考虑是统计一个程序模块的源代码行数目，并以源代码行数做为程序复杂性的度量。
设每行代码的出错率为每100行源程序中可能有的错误数目。
Thayer曾指出，程序出错率的估算范围是从0.04％～7％之间，即每100行源程序中可能存在0.04～7个错误。他还指出，每行代码的出错率与源程序行数之间不存在简单的线性关系。

Lipow 指出，对于小程序，每行代码出错率为1.3％～1.8％；对于大程序，每行代码的出错率增加到2.7％～3.2％之间，这只是考虑了程序的可执行部分，没有包括程序中的说明部分。
Lipow 及其他研究者得出一个结论：对于少于100个语句的小程序，源代码行数与出错率是线性相关的。随着程序的增大，出错率以非线性方式增长。
McCabe度量法
McCabe度量法，又称环路复杂性度量，是一种基于程序控制流的复杂性度量方法。
它基于一个程序模块的程序图中环路的个数，因此计算它先要画出程序图。
程序图是退化的程序流程图。流程图中每个处理都退化成一个结点，流线变成连接不同结点的有向弧。
程序图仅描述程序内部的控制流程，完全不表现对数据的具体操作。

计算环路复杂性的方法：在一个有向图G中，环路的个数由以下公式给出： V(G)＝m－n＋2 其中，V(G)是有向图G中环路个数，m是图G中弧数，n是图G中结点数。
Myers建议，对于复合判定，如 (A＝0) ∩(C＝D)∪(X＝‘A') 算做三个判定。

环路复杂度取决于程序控制结构的复杂度。当程序的分支数或循环数增加时其复杂度也增加。环路复杂度与程序中覆盖的路径条数有关。
McCabe环路复杂度隐含前提是：错误与程序的判定加上例行子程序的调用数目成正比。
McCabe建议，对于复杂度超过10的程序，应分成几个小程序，以减少程序中的错误。
Walsh用实例证实了在McCabe复杂度为10的附近，存在出错率的间断跃变。
Halstead的软件科学
Halstead软件科学研究确定软件开发中的一些定量规律, 它采用以下一组基本度量值。
程序长度(预测的Halstead长度)
令n1表示程序中不同运算符 (包括保留字) 的个数，令n2表示程序中不同运算对象的个数，令 H 表示“程序长度”，则有
H = n1?log2 n1+n2 ? log2n2
这里，H是程序长度的预测值，它不等于程序中语句个数。

在定义中，运算符包括：
算术运算符 赋值符(=或:=)
逻辑运算符 分界符(，或；或
关系运算符 括号运算符
子程序调用符 数组操作符
循环操作符等。
特别地，成对的运算符，例如
{…}、if (…) …else、for (…)、switch (…)、
do…while (…) 、while (…)、(…)
等都当做单一运算符。

运算对象包括变量名和常数。
实际的Halstead长度 设N1为程序中实际出现的运算符总个数，N2为程序中实际出现的运算对象总个数，N为实际的Halstead长度，则有
N = N1 + N2
程序的词汇表 Halstead定义程序的词汇表为不同的运算符种类数n1和不同的运算对象种类数n2的总和。若令n为程序的词汇表，则有
n = n1+n2

程序量
程序量 V 可用下式得到
V = N ? log2n
它表明了程序在词汇上的复杂性。
程序的潜在错误 Halstead度量可以用来预测程序中的错误。预测公式为
B = (N1+N2)?log2(n1+n2) / 3000
B为该程序的错误数。它表明程序中可能存在的差错 B 应与程序量V成正比。
面向对象软件的度量
面向对象分析阶段关于产品的度量：

系统设计阶段关于产品的度量：

对象设计阶段关于产品的度量：

测试阶段关于产品的度量：

与面向对象软件开发过程有关的度量可用于定义工作过程，检查工作过程的进展情况以决定如何改进工作过程。
一般来讲，分析和设计所花的时间是程序编码时间的两倍，而测试所花的时间也是如此。

关于过程的度量：
软件成本和工作量估算
软件成本与工作量估算在两个方面使用了LOC 和 FP 数据：
把LOC和FP数据当做一个估算变量，用于量度软件每一个元素的规模。
LOC和FP数据作为从过去项目中收集到的基线数据，与其它估算变量联合使用, 进行成本和工作量的估算。
1) 分解技术
用 LOC 做为估算变量时，必须进行功能分解, 且需要达到很详细的程度。而估算 FP 时需要的数据是宏观的量，当把 FP 当做估算变量时不需分解得很详细。
LOC 是直接估算的, 而 FP 是通过估计输入、输出、数据文件、查询和外部接口的数目，以及 14 种复杂性校正值间接地确定的。
项目计划人员可对每一个分解的功能提出一个有代表性的估算值范围。

利用历史数据或凭实际经验 (当其它的方法失效时)，对每个功能分别按最佳的、可能的、悲观的三种情况给出LOC或FP估计值。记作a、m、b。接着计算LOC或FP的期望值 E。 E = (a＋4m＋b)／6
所有子功能的总估算变量值除以相应于该估算变量的平均生产率度量得到项目的总工作量。
例如，若假定总的FP估算值是310，基于过去项目的平均FP生产率是5.5FP／PM，则项目的总工作量 = 310／5.5 ＝ 56 PM

例如，对于一个为CAD应用而开发的软件包。首先确定使用LOC做为估算变量。然后根据系统规格说明, 确定软件范围并进行功能分解。经过专家估算，得到如下页的估算表。
从历史的基线数据求出生产率度量，即行／PM和元／行。而在表中的成本 = LOC的期望值 E与元／行相乘，工作量 = 用LOC 的期望值 E与行／PM相除。
因此可得，该项目总成本的估算值为 657,000元，总工作量的估算值为145人月（PM）。

2) 软件开发成本估算方法
计算软件开发项目总成本要考虑 3 种因素：
包括维护在内的硬件和软件费用；
差旅费和培训费用；
工作成本（支付给员工的费用）。
对于绝大多数项目，主要的成本是工作成本。工作成本不仅仅是发给软件工程人员的工资，还要按开发人员的人数分担组织机构正常运作的经常性管理费用。通常这种费用是开发人员工资的两倍左右。

组织机构的经常性管理费用包括：
办公场所、供热和照明费用；
会计、秘书、清洁工以及技师等辅助人员的费用；
网络和通信费用；
图书馆和娱乐设施等公共设施的费用；
退休金、医疗保险等社会保障和员工福利的费用。
软件成本计算的目的是要精确地、客观地预测软件承包商的开发成本。

成本计算出来之后，就要做项目报价。项目报价需要考虑机构因素、经济和政治因素、商业因素等。因此除项目经理外，项目报价需要机构的资深管理人员参加。
影响项目报价的因素有：
市场机遇；
成本估算的不确定性；
合同条款；
需求易变性；
经济状况。

下面讨论的软件开发成本主要是指软件开发过程中所花费的工作量及相应的代价。它不包括原材料和能源的消耗，主要是人的劳动的消耗。
软件的开发成本是以一次性开发过程所花费的代价来计算的。
软件开发成本的估算，应以整个软件开发全过程所花费的代价作为依据。
要进行一系列的估算处理。主要靠分解和类推。
(1) 自顶向下的估算方法
这种方法的主要思想是从项目的整体出发，进行类推。
估算人员根据以前已完成项目所消耗的总成本（或总工作量），推算将要开发的软件的总成本（或总工作量），然后按比例将它分配到各开发任务单元中去，再来检验它是否能满足要求。