郑州大学软件项目估计重点

第一章

1. 准确的软件项目估计需要知道下列参数：

主要交付产品的规模，如规格说明、源代码、手册；需求变更频率；Bug 或缺陷的可能数量；

开发所需开展的活动；开发成本、进度约束等。

2. 影响估计结果的属性：

项目需求变更的频率；开发团队在此项目方面的经验；项目开发过程或方法；开发过程中要进行的活动；增量的从技术，迭代次数，冲刺的次数；使用的秉承语言；是否使用已有的软件模块；项目使用的开发工具套件；项目使用的开发工具套件；办公环境或人类工效因素；分散在多个地点的团队的地里间隔；客户或执行官给开发团队的进度压力；合同中关于开发成本，期限，软件缺陷及特征等条款。

3. 软件项目估计的关键因素：技术，人员，过程，环境

4：软件项目估计的步骤（10个）：

1. 分析需求：没有对项目需求的正确理解就无法进行项目级的软件项目估计。因此，在估计开始之前，区级人员有必要发掘并了解用户的需求。

2. 区级规模：任何形式的估计和所有商品化软件项目估计工具需要知道主要软件交付产品的规模才能完成估计。

3. 识别应执行的活动：这里的活动特指待估计项目要做的工作，如：需求分析，内部设计，外部设计，编码，文档编写。。。。。

4. 估计软件的潜在缺陷和缺陷清除方法：缺陷估计包括对需求缺陷，设计缺陷，用户文档编写的缺陷，以及Bad-fix 缺陷估计。

5. 估计人员需求：每个软件教辅产品均有一个称之为分配范围的属性，即一个人可完成的工作量。

6. 依据能力和经验调整假设：软件人员的能力不同，需要根据人员的实际经验和技能水平进行调整。

7. 估计工作量和进度：这两种估计通常以迭代的方式进行。

8. 估计开发成本：开发成本的估计在估计的后期进行，是一项比较复杂的工作。

9. 估计维护和改进的成本：软件通常会持续使用多年，维护和改进成本的估计是一个特殊的课题

10. 将估计的结果提交客户并使客户接受估计的结果：

第二章（空）

第三章

1. 软件项目估计的6种方法：

（1）手工软件估计方法： ◇ 利用经验法则的手工项目级估计； ◇ 利用比率和百分比的手工阶段级估计； ◇ 利用WBS （Work Breakdown

Structure ，工作分解结构）的手工活动级估计。 （2）自动软件估计方法： ◇ 自动项目级估计（宏观估计）： ◇

自动阶段级估计（宏观估计）： ◇ 自动活动级或任务级估计（微观估计）。

2. 手工软件估计方法简介 利用简单的经验法则对软件项目进行手工估计是软件项目估计最古老的形式。尽管其结果远远不够准确，但至今仍在广泛使用。 优点：易于操作。

3. 自动软件估计方法简介 前两种自动估计方法与对应的手工估计方法很相似，只是更快速，更容易操作。能得到整个软件项目的人员、工作量、进

度的总体估计结果的自动估计叫做宏观估计。

4. 宏观估计工具：宏观估计工具支持两种层次：①项目级估计；②基于内置的、分配给每个阶段的比率或百分比 的假设所进行的阶段级估计。 虽然这些宏观估计工具具有和手工估计相同的特性，但很多工具还提供了许多手工估计方法所 不具备的更有价值的特性。如前面所述，自动软件估计工具的知识库中存储了成百上千个软件项目的数据。利用知识库中的信息，自动估计工具可以根据影响软件项目结果的主要因素对初步估计结果进行调整。调整主要 包括： ◇ 人员经验水平的调整： ◇ 软件开发过程的调整； ◇ 特定编程语言的调整； ◇ 软件应用程序规模的调整； ◇ 工作习惯和加班时间的调整。

宏观估计工具的缺点是，估计的粒度通常过大，不足以支持所有重要的软件开发活动。 基于活动的微观估计有如下优点： ◇ 数据粒度小，所以估计结果可作为合同和预算的依据： ◇如果估计有错误，则错误只局限于活动内部，而不是项目级的： ◇ 需要时可增加新的或额外的活动； ◇ 项目中没有执行的活动可以剪裁；◇ 技术文档编写人员等专业人员的影响是显而易见的； ◇ 因为考虑了所有活动，所以估计的有效性更容易判断； ◇ 微观估计最适用于敏捷方法。

5. 估计中应包含的活动：1. 项目级测量：项目是满足一系列相互关联的业务和技术需求的软件的实现。 2. 阶段级测量：阶段是按时间顺序排列的一段时期，在这段时期中，项目团队的大部分工作量用于完成一个主要里程碑，或完成一个主要交付产品。◇ 需求阶段； ◇ 风险分析阶段； ◇ 设计和规格说明阶段： ◆ 编码阶段； ◇ 集成和测试阶段： ◇ 安装阶段； ◇ 维护阶段。3. 活动级测量：活动是完成一个主要里程碑或一个主要交付产品所需的工作总称。典型软件项目的测试阶段中通常包括如下6 种独立的活动： ◇ 新功能测试； ◇ 回归测试： ◇ 部件测试； ◇ 集成测试； ◇ 压力测试； ◇ 系统测试。 4. 任务级测量：任务指完成给定的活动所要采取的一系列步骤或必须做的各种工作。单元测试活动为例， 通常包括4 项任务： ◇ 测试用例设计： ◇ 测试用例运行或执行； ◇ 对发现的问题进行缺陷修复； ◇ 修复确认和重新测试。

第五章

软件项目估计的来源

1、通常软件项目的历史成本数据只包含了所完成的50%左右的工作。

忽略的因素：早期的需求、无偿加班、专业人员工作、用户所做的技术工作、项目管理、差旅成本。。。。

2、估计工具和公司已有的历史数据进行比较时，估计工具的结果成本更高，周期更长。但是错误一方往往是历史数据，（历史数据不完整）

3、导致软件历史数据错误的主要有3个原因：

没有包含所执行的左右活动

没有包含项目中所有类型的人员

没有包括无偿加班

4、成本跟踪系统通常不考虑一下因素

a) 成本系统初始化之前做过的工作，如确定需求

b) 技术文档编写人员、数据库管理员或质量保证人员等非编程人员的工作 c) 项目管理工作，特别是二线经理或者高层经理所做的工作

d) 用户参与测试或者编写用户文档时所做的工作

5%-10%系统之前的工作，15-30未包括的人员的工作、无偿加班5-15

5、弥补估计工具对历史数据不准确的问题：

a) 不接纳数据不完整的项目

b) 通过对项目组成员的访谈来完善所缺失的数据

c) 构建基于活动的软件项目估计工具

避免使用粒度过粗的历史数据，项目级不用（细化到任务级和活动级）、阶段级不用（含有贯穿不同阶段的）

6、准确度在的范围内自动方法的百分比远远高于手动方法，而且两种方式的错误方向也是相反的。当估计工具不准确时，自动估计工具通常是倾向于保守、而手工估计则倾向于乐观。保守估计是安全的。

7、软件估计错误的种类：

a) 度量错误

i. LOC 度量，主要问题在于:软件中总工作量中大部分并不与源代码直

接相关。LOC 度量的生产率随着编程语言的级别的提高而明显下降。

ii. 常见错误估计：

1. 利用粒度过粗的、不足以反应活动的历史数据进行估计是很危险

的

2. 用于多种编程语言的测量或估计时，LOC 度量本身就是有缺陷

的、危险的。

功能的度量具有测量和估计多种编程语言的经济生产率的能力，避

免LOC 度量造成的误差。

b) 规模错误

i. 大系统所需的执行的活动要比小程序多

ii. 大系统的成本构成与小程序不同

不仅大系统执行的活动多各种活动所需的工作量随着软件项目规模的增加而发生明显的变化。

项目经理缺乏大型项目估计的经验和知识

c) 高层管理人员错误

i. 最严重的是企业政策或者企业高管人员及客户方高管有权随意否决

有效的估计。

ii. 项目经理初步估计是准确的，但是结果超出了进行审批的高层能接

受的进度和成本。

d) 规模估计错误

i. 包括源代码行数、屏幕数、培训教材、用户文档页数等。规模估计

错误仅限于项目组内部。

e) 活动选择错误

i. 在估计时忽略了必要的活动。比如用户文档编写

ii. 软件工具开发商和编程语言开发商基于不同活动之间的比较结果进

行广告宣传也会出现活动选择错误。

f) 分配范围错误

g)

h)

i)

j)

k)

l) i. 对人员所能承担的工作量的估计出现了偏差，导致人员超负荷工作。 分配时技能按照自然度量又能按照综合度量进行分配范围估计成为现代软件项目估计工具标准功能。 生产率错误 i. 在一段时间范围内一个人所能完成的工作量。 蔓延的用户需求 i. 正式的需求阶段结束后没有再对计划外需求的增长速率的估计值进行调整。 ii. 功能点的附加用途之一就是直接测量蔓延的用户需求。 关键路径的错误 i. 没有识别出这个活动网络中的关键路径 常见的错误是与调试和测试有关。有问题的项目中早期阶段的曲线通常有极大的欺骗性。 人员筹备错误 i. 到位的人员和安排的不平衡 技术调整错误 i. 调整估计的结果使之适应各种工具、语言、方法方面的错误。 特殊情况

i. 无规律。。。比如 天气啊、自然灾害啊人员离职啊。。。

软件估计工具的盲区将一直存在，最新的软件技术和估计工具所采用的算法之间将会一直存在缺口。

8、估计错误的影响范围

i. 包含度量错误是，偏差范围可能会超过100%

ii. 包括规模错误，偏差达到一个数量级，即超过1000%

iii. 包括高管错误，进度偏差50%，成本100%

iv. 任务选择错误，一个数量级

v. 范围分配错误，100%

vi. 生产率偏差，与实际生产率和预计生产率差异有关

vii. 用户需求蔓延，与计划外的功能数有关。

viii. 关键路径错误，25%进度滞后和35成本超支

ix. 人员筹备错误，不具有普遍性

x. 技术调整错误，150%

9、初步估计方法

软件项目估计必须在能获取足够的软件项目信息以保证其准确性之前就要进行。

1）根据经验法则进行手工估计（不够准确，使用基于功能的的经验法则）

2）用商品化估计工具的近似模式进行初步估计。

六 手工软件估算方法

1. 基于LOC 度量的经验法则

介绍：

给定各种规模软件项目编码生产率的基本假设，然后根据比率或百分比来估计测试、设计、质量保证、项目管理等其他工作的生产率

前提条件：

存在某些有过程编程语言，而且编程人员使用这些语言来编写代码。过程变成语言包括C 、Fortran 等

2. 基于比率和百分比的经验法则

步骤：

首先将项目作为一个整体进行估计，然后将总工作量按一定比率和百分比分配给所有阶段或活动

结论：使用过于简单的比率和百分比进行软件项目估计是非常危险的实践，除非估计人员有来自相同规模、相同种类、相同编程语言、并使用相同重用资源的项目经验比率。

3. 基于功能点度量的经验法则

● 功能点（软件5种外部属性加权后总和）：

外部属性：

应用程序的输入类型、应用程序的输出类型、用户查询的类型、应用程序维护的逻辑文件类型、与其他软件的接口类型

● 功能点规模估计经验法则

1) 需求分析之前用功能点进行规模估计

粗略的规模估计方法：

a) 根据待估计项目范围、种类、类型情况，分别确定范围、种类、

类型值

b) 将3个值相加

c) 求和的2.35次幂

2) 用类推法进行规模估计

选择一个或多个类似项目，以这些项目测量规模为依据，估计新项

目规模

3) 估计源代码规模

法则1

⏹ 一个功能点 = 320行基本汇编语句

⏹ 一个功能点 = 213行宏汇编语句

⏹ 一个功能点 = 128 行C 语句

⏹ 一个功能点 = 53 行C++

⏹ 一个功能点 = 50 行java

回火：直接将源代码量装换成功能点数（15个功能点分界线）

为保证回火项目，应用源代码逻辑语句行数

4) 估计纸质交付产品规模

法则2：软件计划、规格说明和手册的规模估计

软件项目相关的纸质文档总页数，约等于功能点数的1.15次幂

5) 估计蔓延的用户需求的规模

法则3：蔓延的用户需求的规模估计

从设计阶段到编码阶段，蔓延的用户需求以平均每月2%的速率增

长。在软件应用的开发周期中，软件应用程序平均增长至少15%

6) 估计测试用例数

法则4：测试用例数估计

生成的测试用例约等于功能点的1.2次幂

7) 估计软件潜在缺陷数

法则5：软件潜在缺陷数估计

新开发的软件项目的潜在缺陷数约等于功能点的1.25次幂

8) 估计软件缺陷清除率

法则6：测试过程中软件缺陷清除率估计

每一次软件测试将发现并清除目前存在的30%的错误

法则7：正式审查的软件缺陷清除率估计

每一次正式设计评审将发现并清除65%的Bug

每一次正式代码评审将发现并清除60%的Bug

法则8：发布后的缺陷修复率估计

维护编程而宁愿的缺陷修复率为10个Bug/人月

● 进度、资源、成本的经验法则

1) 分配范围和生产率的基本原理

分配范围（A 范围）：摸个软件项目中一个人所承担的工作量

生产率（P 速率）：指在一小时、一周、一个月或一年等标准的时间

周期内，一个人所能完成的工作量

2) 估计软件进度

法则9：软件进度估计

以月为单位的开发进度约等于功能点数的0.4次幂

3) 估计软件人员数

法则10：软件开发人员数估计

开发应用程序所需的人员数约等于功能点数除以150

法则11：软件维护人员数估计

修改应用程序所需的维护人员数约等于功能点数除以750

4) 估计软件开发工作量

法则12：软件开发工作量估计

以人月为单位的工作量约等于软件开发进度乘以人员数

● 基于活动的成本分析经验法则

基于活动的测量能法相生产率不同的根本原因，不同行业、不同类型软件生产率差异是由于软件所采用的活动模式或活动的集合不同。将软件项目分解到活动级后会发现，不同规模和类型的软件项目通常有固定模式

4. 总结和结论

本章介绍的主要估计经验法则和推导法则均以功能点度量为基础，功能点度量比老的LOC 度量的用途更广泛，但简单的经验法则是无法取代正式评估方法。经验法则及推导法则的误差很大，不够准确，不能用于重要的商业用途。利用工作表细化到活动级甚至任务级的手工估计方法比简单的经验法则

更准确，但估计工作量非常大。

第七章：采用敏捷或其它新方法的手工估计

1. 功能点度量：特点：1与所开发的软件类型无关；2. 可用于测量软件生存周期的每一项活动，如：需求、分析、设计、编码、测试等；3. 可用“功能点数/人月”或“工时/功能点”等测量生产率；4. 与编程语言无关。

2. 敏捷软件开发 ，经验法则：程序平均规模约为500个功能点或25000行java 语句；

初期约两周的策划、组织。平均5次迭代，周期两周，规模100个功能点或5000行java 语句；

进度周期相当短：从开始到交付的以月为单位的进度周期=功能点数的0.33次幂. 例:500个功能点的项目进度周期为5000.33=7.7月;

敏捷团队由5人组成:2对编程人员(协调工作), 一名客户代表.

3. CBD---基于可重用的组件库来 构建应用程序，经验法则：

程序平均规模约为5000个功能点或250000行java 语句；

可重用的组件的平均规模为200个功能点或10000行java 语句；

可重用组件实现应用程序60%的功能，定制代码实现40%的功能；

从开始到交付的总进度周期=功能点数的0.36次幂；

4. DSDM(动态系统开发方法) ：原则1：用户必须持续参与 原则2：必须授予DSDM 团队制定决策的权利 原则3：注重产品的经常交付 The focus is on frequent product delivery 原则4：满足业务用户用途是接受交付品的主要依据 原则5：迭代和增量式开发对得到正确的业务解决方案是必不可少的 原则6：开发过程的所有变化可逆 原则7：在高层次上制定需求的基线 原则8：测试自始至终贯穿于开发周期之中 原则9：所有项目涉众间的通力合作是不可获缺的

经验法则：程序平均规模约为1500个功能点或75000行java 语句； 典型项目用4周时间进行可行性和业务研究，然后进行10次迭代或发布，每次迭代周期2周，迭代规模约为150个功能点或7500行java 语句，最后用1个月时间集成、系统测试、验收测试和部署；从开始到交付的以月为单位的进度周期=功能点数的 0.33次幂; 团队由10名软件人员和至少1名客户代表组成; 分配范围:125个功能点/人; 平均生产率12个功能点/人月; 潜在缺陷:4个/功能点;Bad-fix 引入率：3%；由于要进行频繁的评审和测试，因此缺陷清除率90%。

5. ERP——Enterprise Resource Planning 企业资源计划系统，是指建立在信息技术基础上，以系统化的管理思想，为企业决策层及员工提供决策运行手段的管理平台。ERP 系统集中信息技术与先进的管理思想於一身，成为现代企业的运行模式，反映时代对企业合理调配资源，最大化地创造社会财富的要求，成为企业在信息时代生存、发展的基石。 经验法则：

如果ERP 用户自己开发常用的ERP 功能，每功能点1000美元。如果使用ERP 软件, 每功能点可节省5美元；全面部署需16个月. （自行开发周期=功能点数的0.4次幂。因此非常缓慢。例150,0000.4=117月=10年） 每名用户需5天培训；初始缺陷数每功能点设为6个。Bad-fix 引入率：7%。因此，在ERP 投入使用的最初的几年中，次要缺陷是重要问题。ERP 另严重问题：

（大型软件的缺陷分布不均衡，所以）“易错模块”：约50%存在于5%的模块中。 最昂贵、麻烦最多。需持续维护和更新：每50000个功能点配备1名专职人员负责报告缺陷和安装修复后版本。

6. 极限编程(xp)---敏捷方法的另一变体

特征：

将简化设计作为主要目标；

计划基于个体特征，非整个系统；

在编码前设计测试用例；

经验法则：XP 软件的平均规模约300个功能点或约15000行java 语句（基本都

一周策划，4次迭代，每两周发布新版本，最后用一周时间进行最终的测试、部署和用户培训；

周期短：从开始到交付的以月为单位的进度周期=功能点数的0.25次幂. 例:500个功能点的项目进度周期为5000.25=4个月;

分配范围：每人100个功能点;

潜在缺陷:每功能点3个;

部署后, 安排一名兼职人员维护;

7. 国际外包：经验法则:

全球性通货膨胀.(最长期)

另外:容易国际诉讼. 所以, 需对外包伙伴进行评价.(见课本)

合同中务必规定质量和缺陷清除率的指标.

安全保密措施:标示出具强竞争力、有产权或行业秘密的算法的系统和程序, 制定保护策略.

8. OO开发 初步经验法则：

平均规模约2500个功能点或约125，000行java 语句；

若使用UML 来设计，预计每个功能点0.5页.

设计错误约功能点0.25个.

周期：从开始到交付的以月为单位的进度周期=功能点数的0.35次幂. 例:2500个功能点需15.5个月.

分配范围：每人200个功能点;

平均生产率:18个功能点/人月.

潜在缺陷:每功能点4.5个, 清除率92%.

部署后, 每2500个功能点安排1名人员维护.

第8章 基于最少数据的自动估计

一般将软件估计活动的基本步骤分为3个阶段

1，记录项目信息；

（1）安全级别，可选项

（2）项目名称，用于将一个项目的估计同其他项目估计区别开来

（3）估计编号，用于区分早期的估计与后续的估计

（4）用于诉讼的估计一定要记录估计工具的名称

（5）项目描述，可选项，用于当大公司有大量的类似工作时，对不同项目加以区分

（6）NAIC 代码，可选项

（7）大部分商品化软件估计工具会自动从计算机中提取当前日期

（8）项目开始日期

（9）软件项目的期望交付日期

1.1软件分类法：定义项目的性质、范围、种类和类型

2，主要工作产品的初步规模估计；

2.1用户提供的软件项目规模估计；

2.2 自动近似规模估计法

规模估计通常是通过一系列步骤顺序完成的。第一步是采用功能点、源代码语句、用例点、对象点、故事点或其他度量作为主要度量，确定应用程序的总规模。下一步估计各种工作产品和可交付产品的规模。

基于功能点的规模估计：结果只能给出大致的范围，而不是准确的功能点数。

基于功能点重构的规模估计：基于模式匹配的思想。适用于准备使用功能点度量，但确定需求又为时过早，因而无法进行准确的功能点计算的项目。

类推规模估计法：实用，最准确。浏览类似项目的目录，从中寻找与待估计项目最相似的项目作为规模分析的基础。

3，初步软件项目估计。

一旦确定了软件项目的项目数据，以及成本、间接费率、用户提供的规模数据等信息，就积累了进行粗略的初步项目估计所需的足够的信息。

在软件项目估计工具中输入了基本的参数后，就可以很容易的进行初步估计了。增加或改变输入参数所带来的影响会实时的反映在估计结果中。

第9章 软件交付产品规模估计

在需求不完整时即可进行软件应用程序规模估计和项目估计的方法主要包括 1，模式匹配，即以类似项目的；历史数据为基础，估计新项目的规模和成本 2，使用需求增长平均速率的历史数据来估计从初次估计到项目结束时可能的需求增长量

3，利用各种数学或同级方法，基于不完整的需求估计软件的最终规模 4，使用武断的经验法则在初始估计中增加未来需求的“偶然”值

5，在某个时间点固化需求以限制需求的增长。并将增加的需求全部推迟到后续版本中实现，这样就可以单独对这些增加的需求进行成本估计

6，仅当确定了所有特征和需求时，才进行正式估计，即将项目推迟到后期软件需求最终确定后再进行。

项目规模估计，复杂度中重要的6种

圈复杂度（圈复杂度用来衡量一个模块判定结构的复杂程度）

代码复杂度（开发和维护人员主观判断他们编写的代码是否复杂）

数据复杂度（指与实体相关的属性的数量）

基本复杂度（删除多余路径，对应用程序的图进行简化后，从圈复杂度中导出） 功能点复杂度（指计算软件项目最终的功能点总数所需的调整因子的集合） 问题复杂度（指人们解决各种问题时，对问题的难易的主观判断）

较常用的规模估计度量

（1）3D 功能点，用于实时环境的功能点计算

（2）从物理LOC 回火。回火是将应用程序的规模从源代码行数转换为近似的功能点的方法

（3）从逻辑语句行数回火。从源代码规模到功能点数的数学转换既可以使用物理代码行数，也可以使用逻辑语句行数。

（4）复杂度度量。复杂度是个很重要的概念，会影响应用程序的规模、缺陷、进度和成本

（5）故事点，源于敏捷开发和XP 中的需求收集方法，采用用户故事的形式文档化需求

功能点度量的优点：

（1）功能点具有一致性，与编程语言无关

（2）功能点适用于全生存周期分析

（3）功能点适用于软件重用分析

（4）功能点适用于OO 经济研究

（5）许多软件项目估计工具支持功能点

（6）功能点可以转换成多种语言的逻辑代码语句行数

缺点：（1）只有通过认证的功能点专家才能进行准确的计算

（2）功能点计算费时且昂贵

（3）自动功能点计算的准确性还是未知的

（4）规模在15个功能点以下的项目的功能点计算结果是没有规律性的

（5）没有准确的规则可以将功能点变体转换为IFPUG 功能点

（6）许多功能点变体没有回火转换规则

第13章 软件需求评估

1、基于活动的估计有两方面的有点：

1) 不会无意中一楼关键活动

2) 即使出现估计错误，也只是局限在某项特定的活动中，而不会影响整个

活动集

2、目前广泛使用的集中缺陷预防技术包括

✧ 用于获取用户需求的JAD

✧ 用户关注质量问题的QFD

✧ 应用程序的关键特征的原型

✧ 为每个需求编写测试用的XP

3、软件需求主要包括下列属性：

✧ 执行者

✧ 正式方法

✧ 需求工具

✧ 缺陷预防

✧ 缺陷清除

✧ 需求缺陷

✧

4、软件需求中的错误种类包括以下几种

✧ 需求遗漏类错误

✧ 二义性错误

✧ 定义错误

✧ 矛盾的需求

5、软件需求过程中应获取的7项主要内容

✧ 应用程序产生的输出

✧ 应用程序产生的输入

✧ 应用程序必须维护的逻辑文件

✧ 应用程序逻辑文件中的实体，执行者和关系；

✧ 应用程序中的查询类型

✧ 应用程序和其他系统之间的接口

✧ 应用程序中必须提供的算法

6、在估计软件需求，进度，工作量，成本和质量时，必须同时考虑正面因素和负面因素

正面因素：

✧ 很高的客户经验水平

✧ 很高的人员经验水平

✧ JAD

✧ 原型

✧ QFD

✧ 用例

✧ 需求审查

✧ 可重用的需求（模式或框架）

✧ 来自类似项目的需求

✧ 来自竞争对手项目的需求

✧ 搞笑的需求表示法

负面因素：

✧ 缺乏经验的客户

✧ 缺乏经验的开发团队

✧ 有许多新特征的新类型软件

✧ 每月超过3%的去求蔓延

✧ 低效的或随意的需求收集过程

✧ 应用程序的任何不封都没有使用原型

✧ 没有做需求评审或审查

✧ 没有可重用的需求

7、影响软件需求的4中主要因子

✧ 是否使用了原型

✧ 是否使用了JAD

✧ 是否使用了正式需求审查

✧ 室友有熟悉这种类型应用程序的有经验的开发人员

第14章 软件原型估计

1、 软件原型一词实际上包含了集中相互独立的形式，主要有：

✧ 可抛弃原型（在使用完后不再需要，被抛弃掉）

✧ 时间盒原型（项目周期中的一个月或六周等特定的时间周期来开发原

型，以保证期可行性及可实现性）

✧ 演化原型（用户生成最终产品）

2、 影响软件原型的正面因素

✧ 建立原型所用的编程语言是高级语言

✧ 建立原型所用的编程语言方面的经验

✧ 原型所属的应用程序或问题领域方面的经验

✧ 来自类似项目或商品化软件中的可重用组件

✧ 采用XP 等方法，在建立原型之前设计测试用例

3、 影响软件原型的负面因素：

✧ 客户无法确认他们需要原型中的那些特征

✧ 不合适的开发工具

✧ 建立原型所用的编程语言是低级语言

✧ 不合适的计算能力或响应时间

✧ 各种经验的缺乏

✧ 没有可重用的组件

✧ 缺乏正式测试和准确的测试用例

4、 确定影响原型建立的调整因子时，应考虑下列问题：

✧ 开发人员在应用程序方面的经验

✧ 开发人员在工具盒方法方面的经验

✧ 开发人员的编程语言经验

✧ 开发人员的硬件经验

✧ 用户在这种类型的应用程序方面的经验

✧ 需求阶段用户的参与程度

✧ 程序调试工具

✧ 对开发平台的熟悉程度

✧ 开发硬件的稳定性

✧ 开发环境的相应时间

✧ 开发中的计算机支持

✧ 工作站环境

第15章

1. 规格说明和设计覆盖了很多设计形式，包括：

1）粗略的、初步的规格说明

2）详细的、最终的规格说明

3）客户可见、可用的外部规格说明

4）表示应用程序控制流和结构的内部规格说明

5）应用程序所产生、使用或修改的信息的数据规格说明

6）期望的响应时间和吞吐量的性能规格说明

7）各种防止黑客入侵和非法使用的保护措施的安全性规格说明

2. 不同形式的规格说明表示法（软件设计方法），包括：

常规流程图、自然语言文本、控制流图、数据结构图、DeMarco 结构化英语、E-R 图、活动图、用例、SADT 图等。

3. 很多软件设计和规格说明方法才去的常用估计策略就是使用更常见的设计方法的模版，然而，模版并不是理想的解决方法，原因如下：

a) 大量的软件项目使用多种或混合的设计方法，而不只是使用某种“单纯

“的方法。许多项目刚启动时，设计人员使用UML 等某种OO 设计方法，但后来发现者这些方法的学习曲线比较陡峭，就改用Yourdon 结构化设计方法对学习曲线加以调整。

b) 大量的软件项目使用专用的或定制的规格和索命方法，这些方法没有任

何公布的数据支撑。虽然专用方法也可以使用模版，但其模版必须由估计工具的用户自己来创建，估计工具开发商是不会提供模版的，因为他们可能根本不知道这些专用方法的存在。

4. 不同种类和类型的软件，其规格说明和设计中的标称值和默认值不同，主要表现在：1）民用软件项目与军用软件项目的差异；2）系统软件与MIS 项目的差异；3）新应用程序一对已有软件的改进之间的差异。

5. 民用系统软件项目的两种设计方法：1）常规的结构化设计方法。2）UML

6. 正面设计调整因子：有限状态机、UML 、Petri 网等处理控制流和状态转移的设计方法会产生正面影响。

7. 对软件设计过程产生负面影响的因素包括：

a) 不采用正式设计审查

b) 用自然语言作为描述设计的主要方式

c) 采用图形化的设计方法，而没有用自动化工具

d) 没有对规格说明实施正式的配置控制

e) 没有进行正式设计审查

f) 用原型取代规格说明

g) UML 等OO 设计方法的非常陡峭的学习曲线

8. 影响软件规格说明的正面和负面因子主要包括：

a) 项目组织结构

b) 开发人员在应用程序方面的经验

c) 开发人员在分析设计方面的经验

d) 开发人员的硬件经验

e) 通过设计评审清除缺陷的经验

f) 用户在这种类型的应用程序方面的经验

g) 设计评审中用户的参与程度

h) 设计自动化环境

i) 工具集成

j) 项目文档库

k) 对开发平台的熟悉程度

l) 开发硬件的稳定性

m) 工作站环境

第16章

1. 通过正式审查能估计的数据点：

a) 应用程序中的缺陷数

b) 正式审查的缺陷清除率

c) 修复缺陷时带来新错误的Bad-fix 引入率

d) 软件交付时仍存在的潜在缺陷数

e) 潜在缺陷的严重等级

f) 软件发布后用户发现的缺陷率

g) 软件发布后修复潜在缺陷的维护成本

2. 审查是指一组受过培训的参加者按计划对规格说明等软件产品逐页进行检查的正式步鄹。

3. 审查过程的参与人员包括：

a) 作者：被审查产品的制作者

b) 主持人：负责保证审查按规程进行

c) 记录人：负责记录识别出的问题

d) 阅读人：负责解释每个章节

e) 一名或多名评审员：负责进行审查

f) 一名或多名观察员：学习如何进行审查

4. 审查的条件：

a) 每次审查会议前必须有充裕的准备时间

b) 记录审查准备和审查会议的工作量

c) 必须记录发现的缺陷

d) 不能将缺陷数据用于对个人的评价或惩罚

5. 已证实下列审查是有效的：体系结构审查、需求审查、设计审查、数据库设计审查、QFD 图审查、代码审查、测试计划审查、测试用例审查、用户文档审查、Web 页审查

6. 与软件设计审查有关的一些调整因子包括：

a) 项目目标

b) 问题复杂度

c) 数据复杂度

d) 开发人员在应用程序方面的经验

e) 开发人员的分析设计经验

f) 测试前清除缺陷的经验

g) 用户的软件项目经验

h) 用户在这种类型的应用程序方面的经验

i) 需求阶段用户的参与程度

j) 设计评审中用户的参与程度

第十七章 软件编程或编码估计

全新的编程语言不断产生，用几种编程语言编写大型应用程序，且大量的重用代码等种种原因使得对代码进行估计或测量是不容易的，这也是功能点度量产生的原因。

团队经验是最主要的正面影响因子，对软件生成率的负面影响第一位是Bug 和错误，紧随其后的是蔓延的用户需求。

项目组包括多名编程人员时，编程人员之间就会出现工作配合和合作方面的问题，增加了配合和合作有关的复杂度和缺陷率。

编码是唯一一种可以使用老的ＬＯＣ度量而又不会导致太多错误和数据失真的软件开发活动，逻辑源代码语句行数作为生产力数据的基础，也可以用功能点来表示同样的信息。

１２种因素：

１. 可重用性：为了保证代码重用的有效性，重用代码必须是经过验证的、接近零缺陷的。

２. 经验：编程人员使用他们熟悉的编程语言开发熟悉类型的应用程序是，出错的可能性会很小，而且很有可能手头上会有可重用的组件。

３. ＢＵＧ或错误：ｃ和汇编的缺陷率比较高。清除缺陷所需的工作量和成本是编程中的主要成本

４. 无偿加班：长时间的、大量的无偿加班是软件业一种正常的文化现象，它弱化了工作量和编码成本之间的联系。

５. 需求蔓延：破坏应用程序的控制流结构；增加应用程序的圈复杂度和基本复杂度；增加代码中的缺陷数；降低缺陷清除率；影响长期的维护

６. 代码结构和复杂度：圈复杂度和基本复杂度测量代码的分支数和控制流，编程生产力会随着复杂度的增加而下降

７. 计划外干扰对编程的影响：编程人员同时负责开发和维护是最常见最具破坏性的干扰之一，当开发和维护并行时，根据缺陷报告的情况不同，维护工作是随机的、无计划的。

８. 应用程序规模：编程分配范围的决定因素包括技能水平和完成项目的进度压力，编程人员增加，组件或模块的接口数量也会随之增加，接口中会有更多的Ｂｕｇ

９. 办公空间和人类功效因素

１０. 工具

１１. 编程语言：不同的语言实现同样的功能时，源代码的规模差异很大

１２. 进度压力：项目经理、公司的高层管理者或客户施加给编程人员的紧张但又不切实际的进度压力

第18章软件代码审查估计

18.1代码审查的文献

18.2代码审查的有有效性

1、正式代码审查发现深层次BUG 的效率是已知测试方法的两倍，缺陷清除率

高达85%，且回报率高。但由于成本昂贵，主要应用于可靠性安全性要求高的软件项目。

2、正式代码审查与不太正式的结构化走查核代码评审的不同：

新手第一次参加代码审查前，应先接受培训

审查组由主持人、记录人、一名或多名审查员以及作者组成。

谨慎的安排准备、审查会议、后续活动的日程和时间

保存发现的缺陷数、准备工作的时数、被审查工作产品的规模等准确数

3、随着审查经验丰富，参与者会在以下方面受益

编程人员自己编写的代码BUG 数减少

审查员和参加者的准备工作效率提高，审查会议时间缩短

18.3代码审查估计的一些考虑因素

1、设计和代码审查有很大差异，主要包括：

准备时间差异很大

3---8名人员参加会议

审查因个人因素推迟或取消

审查活动断断续续，每次不超过2小时

审查只能穿插在别的工作中

2、正式审查对后续活动的影响

审查可消除至少65%的潜在错误，测试更快速，成本更低

审查使规格说明更规范，提高缺陷清除率

减少维护成本

采用正式审查的项目通常获得更高的客户满意度

第19章 软件配置控制与变更管理估计

1. 总的来说，软件变更管理时需要对以下各项不确定因素单独进行估计： 工作产品集（需求，规格说明，代码，文档，测试，Bug 等） 每个工作产品的变更速率

对提交的变更进行评价的方法及批准或否决变更的方法

是否有正式的变更控制委员会

保存，记录各种工作产品变更的方法

是否进行配置审核

所用的应用程序构建工具和版本控制工具

新版本的建立频率

2 变更管理估计活动的特点：

不是每个软件项目都使用正式变更管理方法法

敏捷项目经常使用非正式变更控制方法

不是每个软件项目都有变更控制委员会

设立了变更控制委员会的项目的规模和人员的差异很大

设立了变更控制委员会的项目的会议是间歇性召开的

不是每一个项目都采用了自动变更控制

自动变更控制工具的性能差异很大

3 现代的变更管理工具通常称为配置控制工具，必须有能力管理下列软件交付产品和工作产品的变更：

需求

项目计划

项目估计

合同

设计

源代码

用户文档

图示和图形

测试文档

缺陷报告

第20章 软件测试估计

1 软件测试估计典型的步骤是：先估计项目的缺陷数，然后估计项目的评审，审查，测试的数量，应估计每一步的缺陷清除率，还要估计每项缺陷清除活动的准备，实施和缺陷修复的工作量和成本

2 进行准确估计的一个关键因素是测量评审，审查和测试的缺陷清除率。 测

量缺陷清除率甚至无需知道代码行数，功能点数，对象点数和其他度量结果，这是所有软件测量中最简单，也最有意义的一种

3 测试按比较宽的分类分为如下3种形式：

根据输入验证应用程序的输出有效性的通用测试

针对诸如性能或能力等特定类型问题的专用测试

用户或客户参与的评价软件易用性的测试

通用测试可用于几乎所有类型的软件，用于消除分支错误，循环错误，错误输出等一般性错误

专用测试的适用范围比较窄，用于消除诸如仅在全负载时才会出现的或可能引起性能降低的特定类型的错误

用户参与的测试主要是消除易用性问题，以及验证是否实现了所有需求

4 通用软件测试

1 子程序测试 ：几乎都是由开发人员自发进行，而且很不正式，它是防止算法错误的关键性一步，通常不会列入测试计划中

2 单元测试： 最低级别的测试，通常由负责模块编码的程序人员自己进行，而且要设计专门的测试用例

3 新功能测试：属于回归测试的一种，目的在于验证软件中增加的新功能，通常由专业测试人员执行。它是防止模块间接口错误及应用程序中数据交换错误的关键活动

4 回归测试：

5 集成测试

5 专用软件测试：

1. 压力或能力测试：

2. 性能测试

3. 病毒及流氓插件防护测试

4. 安全性测试

5. 平台测试

6. 第三方测试

6 用户或客户参与的测试

可用性测试

现场测试

实验室测试

客户验收测试

净室统计测试

7 最常用的测试包括：

子程序测试

单元测试

新功能测试

回归测试

集成测试

系统测试

8 影响软件的主要缺陷类型：

遗漏型错误

指令性错误

清晰性或二义性错误

速度错误

能力错误

9 正式的估计需要分析下属3种活动：

测试准备

测试执行

缺陷修复

10 影响测试性能的因素

被测应用程序中的Bug 或缺陷数

应用程序所选择的测试阶段数

与圈复杂度和基本复杂度有关的应用程序结构

测试人员使用的测试工具

测试人员的培训和经验

测试前是否进行了代码审查

项目进度中分配给测试的时间

每个测试阶段发现的缺陷数

将缺陷提交缺陷修复人员的方法

测试或缺陷修复过程中可能出现的干扰

第21章

对软件项目成本影响最大的5项活动按工作量的排序依次是：

1. 发现和修复Bug ，

2. 生成纸质文档，

3. 会议和交流

4. 编码

5. 项目管理

敏捷项目中，影响成本的关键因素依次如下：

1. 发现和修复Bug ，

2. 会议和交流

3. 编码

4. 编写纸质文档

5. 项目管理

软件文档估计得步骤通常如下：

1. 确定应用程序需生成的文档集

2. 确定每个文档的规模

3. 确定生成每个基本文档的工作量

4. 确定每个文档由新需求所引起的变更速率

5. 确定每个文档的潜在缺陷率

6. 确定需求变更带来的附加工作量

7. 确定修复文档缺陷的附加工作量

8. 确定文档的复制和发布等成本

第22章节

软件项目经理的角色和职责可分为三类

1. 人事管理角色

2. 部门管理角色

3. 特定项目的管理角色

人事管理职责包括：

1. 面试应聘者

2. 依据人力资源指导原则确定员工的职位和福利

3. 进行人事考核

4. 批准培训或教育申请

5. 需要时进行奖励

6. 需要时处理纪律事宜

7. 必要时中止劳动合同兵解雇员工

8. 参与各种人力资源规划

9. 根据士气调查结果提供指导

部门管理职责包括：

1. 参与年度或半年的预算制定

2. 管理办公空间或与办公室有关的事宜

3. 批准出差计划

4. 申请或批准配备计算机及其他设备

5. 参加专业学习

项目管理职责包括：

1. 与项目客户协调

2. 与负责项目资源和状态的高层管理者协调

3. 与大型项目的其他经理协调

4. 选择项目使用的技术和工具

5. 进行规模估计

6. 成本估计

7. 进度估计

8. 质量估计

9. 里程碑估计

10. 跟踪

11. 进展报告

12. 测量