彼岸无爱-一年级下册教学计划

13.1 估算软件规模
13.2 工作量估算
13.3 进度计划
13.4 人员组织
13.5 质量保证
13.6 软件配置管理
13.7 能力成熟度模型

在经历了若干个大型软件工程项目的 失败之后，人们才逐渐认识
到软件项目管理的重要性和特殊性。事实上，这些项目的失败并不是
由于从事软件开发工作的软件工程师无能，正相反，他们之中的绝大
多数是当时杰出的技术专家。这些工 程项目的失败主要是因为管理不
善。
所谓管理就是通过计划、组织和控制等一系列活动，合理 地配置
和使用各种资源，以达到既定目标的过程。
软件项目管理先于任何技术活动之前开始， 并且贯穿于软件的整
个生命周期之中。软件项目管理过程从一组项目计划活动开始，而制
定计划 的基础是工作量估算和完成期限估算。为了估算项目的工作量
和完成期限，首先需要估算软件的规模。
13.1 估算软件规模
13.1.1 代码行技术

代码行技术是 比较简单的定量估算软件规模的方法。这种方法依
据以往开发类似产品的经验和历史数据，估计实现一个 功能所需要的
源程序行数。当有以往开发类似产品的历史数据可供参考时，用这种
方法估计出的 数值还是比较准确的。把实现每个功能所需要的源程序
行数累加起来，就可得到实现整个软件所需要的源 程序行数。
代码行技术的主要优点是，代码是所有软件开发项目都有的“产
品”，而且很容易 计算代码行数。代码行技术的缺点是：源程序仅是
软件配置的一个成分，用它的规模代表整个软件的规模 似乎不太合理；

用不同语言实现同一个软件所需要的代码行数并不相同；这种 方法不
适用于非过程语言。为了克服代码行技术的缺点，人们又提出了功能
点技术。
13.1.2 功能点技术
功能点技术依据对软件信息域特性和软件复杂性的评估结果，估
算软件规模。这种方法用功能点（FP）为单位度量软件规模。
1. 信息域特性
功能点技术定义了信息域的5个特性，分别是输入项数(Inp)、输出
项数(Out)、查询数(In q)、主文件数(Maf)和外部接口数(Inf)。下面讲述
这5个特性的含义。
2. 估算功能点的步骤
举例：用3个步骤，可估算出一个软件的功能点数（即软件规模）。
（1）计算未调整的功能点数UFP
(2) 计算技术复杂性因子TCF
（3）计算功能点数FP
13.2 工作量估算
软件估算模型使用由经验导出的 公式来预测软件开发工作量，工
作量是软件规模（KLOC或FP）的函数，工作量的单位通常是人月（ pm)。
支持大多数估算模型的经验数据，都是从有限个项目的样本集中总结
出来的，因此，没 有一个估算模型可以适用于所有类型的软件和开发
环境。
注：简要介绍：静态单变量模型、动态多变量模型、COCOMO2
模型
13.3 进度计划
不论从事哪种技术性项目，实际情况都是，在实现一个大目标之
前往往必须完成数以 百计的小任务（也称为作业）。这些任务中有一
些是处于“关键路径”（回顾之前相关知识）之外的，其 完成时间如
果没有严重拖后，就不会影响整个项目的完成时间；其他任务则处于
关键路径之中， 如果这些“关键任务”的进度拖后，则整个项目的完
成日期就会拖后，管理人员应该高度关注关键任务的 进展情况。
一个有效的软件过程应该定义一个适用于当前项目的任务集合。
一个任务集合包括 一组软件工程工作任务、里程碑和可交付的产品。

为一个项目所定义的任务集合，必须包 括为获得高质量的软件产品而
应该完成的所有任务，但是同时又不能让项目组承担不必要的工作。 项目管理者的目标是定义全部项目任务，识别出关键任务，跟踪
关键任务的进展状况，以保证能及时 发现拖延进度的情况。为达到上
述目标，管理者必须制定一个足够详细的进度表，以便监督项目进度并控制整个项目。
13.3.1 估算开发时间
估算出完成给定项目所需的总工作量之后，接下来需要回答的问
题就是： 用多长时间才能完 成该项目的开发工作？对于一个估计工
作量为20人月的项目，可能想出下列几种进度表：
1个人用20个月完成该项目；
4个人用5个月完成该项目；
20个人用1个月完成该项目。
但是，这些进度表并不现实，实际上软件开发时间与从事开发 工
作的人数之间并不是简单的反比关系。
通常，成本估算模型也同时提供了估算开发时间T的方程。
重点：研究项目组规模与项目组总生产率的关系。
举例：说明项目组规模与生产率的关系。
13.3.2 Gantt图
首先通过一个非常简单的例子引出这种工具。
例：假设有一座陈旧的矩形木板房需要重新油漆。这项工作必须
分3步完成： 首先刮掉旧漆， 然后刷上新漆，最后清除溅在窗户上的
油漆。假设一共分配了15名工人去完成这项工作，然而工具却很 有限：
只有5把刮旧漆用的刮板，5把刷漆用的刷子，5把清除溅在窗户上的油
漆用的小刮刀 。怎样安排才能使工作进行得更有效呢?
一种做法是首先刮掉四面墙壁上的旧漆，然后给每面墙壁都刷 上
新漆，最后清除溅在每个窗户上的油漆。显然这是效率最低的做法，
因为总共有15名工人， 然而每种工具却只有5件，这样安排工作在任何
时候都有10名工人闲着没活干。
这时：同学 们可能已经想到，应该采用“流水作业法”，也就是
说，首先由5名工人用刮板刮掉第1面墙上的旧漆( 这时其余10名工人休
息)，当第1面墙刮净后，另外5名工人立即用刷子给这面墙刷新漆(与此

同时拿刮板的5名工人转去刮第2面墙上的旧漆)，一旦刮旧漆的工人转
到第3面墙而 且刷新漆的工人转到第2面墙以后，余下的5名工人立即拿
起刮刀去清除溅在第1面墙窗户上的油漆，… …。这样安排每个工人都
有活干，因此能够在较短的时间内完成任务。

假设木板房 的第2、4两面墙的长度比第1、3两面墙的长度长一倍，
此外，不同工作需要用的时间长短也不同，刷 新漆最费时间，其次是
刮旧漆，清理(即清除溅在窗户上的油漆)需要的时间最少。
可以使用Gantt图描绘上述流水作业过程： 在时间为零时开始刮
第1面墙上的旧漆，两小 时后刮旧漆的工人转去刮第2面墙，同时另5
名工人开始给第1面墙刷新漆，每当给一面墙刷完新漆之后 ，第3组的5
名工人立即清除溅在这面墙窗户上的漆。
13.3.3 工程网络
Gantt图能很形象地描绘任务分解情况，以及每个子任务(作业)的
开始时间和结束时间，因此是进 度计划和进度管理的有力工具。它具
有直观简明和容易掌握、容易绘制的优点，但是Gantt图也有3 个主要
缺点：
(1) 不能显式地描绘各项作业彼此间的依赖关系；
(2) 进度计划的关键部分不明确，难于判定哪些部分应当是主攻
和主控的对象；
(3) 计划中有潜力的部分及潜力的大小不明确，往往造成潜力的
浪费。
13.3.4 估算工程进度
举例：在前面例子的基础之上，利用工程网络估算工程进度。
补充：计算最迟时刻LET使用下述3条规则：
(1) 考虑离开该事件的所有作业；
(2) 从每个作业的结束事件的最迟时刻中减去该作业的持续时
间；
(3) 选取上述差数中的最小值作为该事件的最迟时刻LET。
13.3.5 关键路径
强调： 关键路径上的事件(关键事件)必须准时发生，组成关键路
径的作业(关键作业)的实际持续时间不能超 过估计的持续时间，否则

工程就不能准时结束。
工程项目的管理人员应该密切 注视关键作业的进展情况，如果关
键事件出现的时间比预计的时间晚，则会使最终完成项目的时间拖后；
如果希望缩短工期，只有往关键作业中增加资源才会有效果。
13.3.6 机动时间 < br>不在关键路径上的作业有一定程度的机动余地——实际开始时间
可以比预定时间晚一些，或者实际 持续时间可以比预定的持续时间长
一些，而并不影响工程的结束时间。一个作业可以有的全部机动时间< br>等于它的结束事件的最迟时刻减去它的开始事件的最早时刻，再减去
这个作业的持续时间：
机动时间=(LET)结束-(EET)开始-持续时间
13.4 人员组织
软 件项目成功的关键是有高素质的软件开发人员。然而大多数软
件的规模都很大，单个软件开发人员无法在 给定期限内完成开发工作，
因此，必须把多名软件开发人员合理地组织起来，使他们有效地分工
协作共同完成开发工作。
为了成功地完成软件开发工作，项目组成员必须以一种有意义且
有效的方式彼此交互和通信。如何组织项目组是一个重要的管理问题，
管理者应该合理地组织项目组， 使项目组有较高生产率，能够按预定
的进度计划完成所承担的工作。经验表明，项目组组织得越好，其生
产率越高，而且产品质量也越好。
现有的软件项目组的组织方式很多，通常，组织软件开发人 员的
方法，取决于所承担的项目的特点、以往的组织经验以及管理者的看
法和喜好。
下面介绍3种典型的组织方式：民主制程序员组、主程序员组、现
代程序员组。比较以上三种组织方式的 特点。
13.5 质量保证
13.5.1 软件质量

概软件质量 就是“软件与明确地和隐含地定义的需求相一致的程
度”。更具体地说，软件质量是软件与明确地叙述的 功能和性能需求、
文档中明确描述的开发标准以及任何专业开发的软件产品都应该具有
的隐含特 征相一致的程度。

注：上述定义强调了下述的3个要点：
（1） 软件需求是度量软件质量的基础，与需求不一致就是质量
不高。
（2） 指定的开发标准定义 了一组指导软件开发的准则，如果没
有遵守这些准则，几乎肯定会导致软件质量不高。
（3） 通常，有一组没有显式描述的隐含需求（例如，软件应该
是容易维护的）。如果软件满足明确描述的需求 ，但却不满足隐含的
需求，那么软件的质量仍然是值得怀疑的。
13.5.2 软件质量保证措施
软件质量保证（software quality assurance,SQA）的措施主要有： 基
于非执行的测试（也称为复审或评审），基于执行 的测试（即以前讲
过的软件测试）和程序正确性证明。复审主要用来保证在编码之前各
阶段产生 的文档的质量；基于执行的测试需要在程序编写出来之后进
行，它是保证软件质量的最后一道防线；程序 正确性证明使用数学方
法严格验证程序是否与对它的说明完全一致。
重点：审查
审查过程包括下述5个基本步骤：
（1） 综述。由负责编写文档的一名成员向审查组综述该文档。
在综述会结束时把文档分发给每位与会者。
（2） 准备。评审员仔细阅读文档。最好列出在审查中发现的错
误的类型，并按发生频率把错 误类型分级，以辅助审查工作。这些列
表有助于评审员们把注意力集中到最常发生错误的区域。
（3） 审查。评审组仔细走查整个文档。和走查一样，这一步的
目的也是发现文档中的错误， 而不是改正它们。通常每次审查会不超
过90分钟。审查组组长应该在一天之内写出一份关于审查的报告 。
（4） 返工。文档的作者负责解决在审查报告中列出的所有错误
及问题。
（5） 跟踪。组长必须确保所提出的每个问题都得到了圆满的解
决（要么修正了文档，要么澄 清了被误认为是错误的条目）。必须仔
细检查对文档所做的每个修正，以确保没有引入新的错误。如果在 审
查过程中返工量超过5%，则应该由审查组再对文档全面地审查一遍。
审查组由4人组成。 组长既是审查组的管理人员又是技术负责人。

审查组必须包括负责当前阶段开发工作的项 目组代表和负责下一阶段
开发工作的项目组代表，此外，还应该包括一名SQA小组的代表。
审查是检测软件错误的一种好方法，利用审查可以在软件过程的
早期阶段发现并改正错误，也就是说，能 在修正错误的代价变得很昂
贵之前就发现并改正错误。因此，审查是一种经济有效的错误检测方
法。
4. 程序正确性证明
测试可以暴露程序中的错误，因此是保证软件可靠性的重要手段 ；
但是，测试只能证明程序中有错误，并不能证明程序中没有错误。因
此，对于保证软件可靠性 来说，测试是一种不完善的技术，人们自然
希望研究出完善的正确性证明技术。
正确性证明 的基本思想是证明程序能完成预定的功能。因此，应
该提供对程序功能的严格数学说明，然后根据程序代 码证明程序确实
能实现它的功能说明。
介绍证明的基本思想：如果在程序的若干个点上，设计 者可以提
出关于程序变量及它们的关系的断言，那么在每一点上的断言都应该
永远是真的。假设 在程序的P1,P2,…，Pn等点上的断言分别是
a(1),a(2)，…，a(n)，其中a(1) 必须是关于程序输入的断言，a(n)必须是
关于程序输出的断言。为了证明在点Pi和Pi+1之间的 程序语句是正确
的，必须证明执行这些语句之后将使断言a(i)变成a(i+1)。如果对程序
内所有相邻点都能完成上述证明过程，则证明了输入断言加上程序可
以导出输出断言。如果输入断言和 输出断言是正确的，而且程序确实
是可以终止的(不包含死循环)，则上述过程就证明了程序的正确性。
补充：目前已经研究出证明PASCAL和LISP程序正确性的程序系
统，正在对这些系统进 行评价和改进。现在这些系统还只能对较小的
程序进行评价，毫无疑问还需要做许多工作，这样的系统才 能实际用
于大型程序的正确性证明。
13.6 软件配置管理
软件配置管理是在软件的整个生命期内管理变化的一组活动。具
体地说，这组活动用来： ①标识变化； ②控制变化； ③确保适当
地实现了变化； ④向需要知道这类信息的人报告变化。 < /p>

软件配置管理不同于软件维护。维护是在软件交付给用户使用后
才发生的，而配置 管理是在软件项目启动时就开始，并且一直持续到
软件退役后才终止的一组跟踪和控制活动。
软件配置管理的目标是，使变化更正确且更容易被适应，在必须
变化时减少所需花费的工作量。
13.6.1 软件配置
1. 软件配置项
软件过程的输出信息可以分为3类： ①计算机程序（源代码和可
执行程序）； ②描述计算机程序的文档（供技术人员或用户使用）；
③数据（程序内包含的或在程序外的）。 上述这些项组成了在软件过
程中产生的全部信息，我 们把它们统称为软件配置，而这些项就是软
件配置项。
2. 基线
基线是一个软件 配置管理概念，它有助于我们在不严重妨碍合理
变化的前提下来控制变化。IEEE把基线定义为： 已 经通过了正式复
审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有
通过正式的 变化控制过程才能改变它。
简而言之，基线就是通过了正式复审的软件配置项。
13.6.2 软件配置管理过程
软件配置管理是软件质量保证的重要一环，它的主要任务 是控制
变化，同时也负责各个软件配置项和软件各种版本的标识、软件配置
审计以及对软件配置 发生的任何变化的报告。
具体来说，软件配置管理主要有5项任务： 标识、版本控制、变
化控制、配置审计和报告。
13.7 能力成熟度模型（重点）
能力成熟度模型（capability maturity model，CMM)，是用于评价软< br>件机构的软件过程能力成熟度的模型。最初，建立此模型的目的主要
是，为大型软件项目的招投标 活动提供一种全面而客观的评审依据，
发展到后来，此模型又同时被应用于许多软件机构内部的过程改进 活
动中。
能力成熟度模型的基本思想是，由于问题是由我们管理软件过程
的方法不当 引起的，所以新软件技术的运用并不会自动提高软件的生

产率和质量。能力成熟度模型有 助于软件开发机构建立一个有规律的、
成熟的软件过程。改进后的软件过程将开发出质量更好的软件，使 更
多的软件项目免受时间和费用超支之苦。
CMM把软件过程从无序到有序的进化过程分成5 个阶段，并把这
些阶段排序，形成5个逐层提高的等级。这5个成熟度等级定义了一个
有序的尺 度，用以测量软件机构的软件过程成熟度和评价其软件过程
能力，这些等级还能帮助软件机构把应做的改 进工作排出优先次序。
注：成熟度从“1级”到“5级”，反映出一个软件机构为了达到
从一 个无序的、混乱的软件过程进化到一种有序的、有纪律的且成熟
的软件过程的目的，必须经历的过程改进 活动的途径。每一个成熟度
级别都是该软件机构沿着改进其过程的途径前进途中的一个台阶，后
一个成熟度级别是前一个级别的软件过程的进化目标。
CMM的每个成熟度级别中都包含一组过程改进 的目标，满足这些
目标后一个机构的软件过程就从当前级别进化到下一个成熟
度级别。
下面介绍这5个级别的特点。
1. 初始级
软 件过程的特征是无序的，有时甚至是混乱的。几乎没有什么过
程是经过定义的（即没有一个定型的过程模 型），项目能否成功完全
取决于开发人员的个人能力。
2. 可重复级
软件机构建 立了基本的项目管理过程(过程模型),可跟踪成本、进
度、功能和质量。已经建立起必要的过程规范， 对新项目的策划和管
理过程是基于以前类似项目的实践经验，使得有类似应用经验的软件
项目能 够再次取得成功。
3. 已定义级
软件机构已经定义了完整的软件过程（过程模型），软件 过程已
经文档化和标准化。所有项目组都使用文档化的、经过批准的过程来
开发和维护软件。这 一级包含了第2级的全部特征。在第3级成熟度的
软件机构中，有一个固定的过程小组从事软件过程工程 活动。当需要
时，过程小组可以利用过程模型进行过程例化活动，从而获得一个针

对某个特定的软件项目的过程实例，并投入过程运作而开展有效的软
件项目工程实践。
4. 已管理级
软件机构对软件过程（过程模型和过程实例）和软件产品都建立
了定量的质量目标， 所有项目的重要的过程活动都是可度量的。该软
件机构收集了过程度量和产品度量的方法并加以运用，可 以定量地了
解和控制软件过程和软件产品，并为评定项目的过程质量和产品质量
奠定了基础。这 一级包含了第3级的全部特征。
处于4级成熟度的软件机构的过程能力可以概括为，软件过程是可度量的，软件过程在可度量的范围内运行。这一级的过程能力允许软
件机构在定量的范围内预测过程 和产品质量趋势，在发生偏离时可以
及时采取措施予以纠正，并且可以预期软件产品是高质量的。
5. 优化级
软件机构集中精力持续不断地改进软件过程。这一级的软件机构
是一个 以防止出现缺陷为目标的机构，它有能力识别软件过程要素的
薄弱环节，并有足够的手段改进它们。在这 样的机构中，可以获得关
于软件过程有效性的统计数据，利用这些数据可以对新技术进行成本
效 益分析，并可以优化出在软件工程实践中能够采用的最佳新技术。
这一级包含了第4级的全部特征。 < br>这一级的软件机构可以通过对过程实例性能的分析和确定产生某
一缺陷的原因，来防止再次出现这 种类型的缺陷；通过对任何一个过
程实例的分析所获得的经验教训都可以成为该软件机构优化其过程模< br>型的有效依据，从而使其他项目的过程实例得到优化。这样的软件机
构可以通过从过程实施中获得 的定量的反馈信息，在采用新思想和新
技术的同时测试它们，以不断地改进和优化软件过程。
处于5级成熟度的软件机构的过程能力可以概括为，软件过程是可
优化的。这一级的软件机构能够持续不 断地改进其过程能力，既对现
行的过程实例不断地改进和优化，又借助于所采用的新技术和新方法
来实现未来的过程改进。
补充：一些统计数字表明，提高一个完整的成熟度等级大约需要
花 18个月到3年的时间，但是从第1级上升到第2级有时要花3年甚至5

年时间。这说明 要向一个迄今仍处于混乱的和被动的行动方式的软件
机构灌输系统化的方式，将多么困难。