软件项目管理
软件系统的开发涉及一系列的步骤、活动、产品和人员，需要综合考虑成本、进度和质量等因素，应采用项目的形式对它进行有效的管理。自上世纪八十年代末以来，来自学术界和工业界的软件工程研究者和实践者开始认识到管理在软件项目开发过程中的重要性。相关研究表明，70%的软件项目由于管理不善导致难以控制进度、成本和质量，三分之一左右的软件项目在时间和成本上超出额定限度125%以上[7]。进一步的研究发现：管理是影响软件项目成功实施的全局性因素，而技术仅仅是局部因素[1]。此外，如果软件开发组织不能对软件项目进行有效管理，就难以充分发挥软件开发方法和工具的潜力，也无法高效率地开发出高质量的软件产品。历史上由于管理不善而导致软件项目失败的例子比比皆是，如美国国税局的税收现代化系统、美国银行的MasterNet系统等[2]，给客户和软件开发组织带来巨大的损失。
不同于其它的工程项目，软件项目有其特殊性和复杂性，具体表现在：首先软件产品是一种无形的逻辑产品，难以估算和度量这类产品的成本和质量等属性；其次软件需求通常难以确定且具有易变性的特点，因而难以控制软件项目的开发进度、成本和生产率；第三，软件系统内在的逻辑复杂性往往导致难以控制和预见软件系统的质量以及软件开发过程中的风险。因此，对软件项目进行管理必须充分依据软件系统以及软件开发的特点。
在信息化时代，软件在信息系统中扮演着越来越重要的角色。随着软件系统规模的增大和复杂性的提高，管理在软件项目开发中将扮演着更为重要的角色，发挥着关键性的作用。尽管由于软件项目和开发组织的多样性和特殊性，不同的开发组织往往会采用不同的方法和策略来对软件项目进行管理。但是，软件项目管理仍然有其一般性的任务、策略和模式。尤其是人们在大量的软件工程实践中积累了许多软件项目管理经验，它们将对软件项目的有效管理起着重要的指导作用。
1 软件项目管理概述
软件项目开发的任务是要按照给定的进度、成本和质量，开发出满足用户要求的软件产品。为了支持这一任务的实现，软件工程在提出一系列的方法、技术和工具来支持软件系统工程化开发的同时，强调管理在软件项目开发中的重要性。
所谓的软件项目管理是指为了使软件项目按照预定的成本、进度和质量等要求顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。从整体上看，软件项目管理主要关注以下三方面的对象：人员、产品和过程（见图 1）。
- 人员
一般地，一个软件项目的开发是由许多承担不同任务的人员来完成。这些人员对软件系统开发的关注视点和工作内容不尽相同，在软件项目中所扮演的角色（如项目经理、需求分析人员、设计人员、程序员、测试人员、用户等等）也不一样。但是，他们所从事的工作往往是相互关联的，并且服务于一个共同的目标，即成功地开发出满足用户需求的软件系统。它们相互合作构成了一个团队。比如，需求分析人员的工作成果（即软件需求规格说明书）将作为指导软件设计人员进行软件设计的基础和依据，而测试人员进行软件测试的对象是程序员所开发的源程序代码。因此，如何确定软件项目所需的人员和角色，为他们分配合适的任务，组建一个好的团队，促进不同人员之间的交流、沟通和合作，提高团队成员的开发效率和质量，是软件项目管理需要考虑的关键问题之一。
- 过程
软件项目开发的需要一组良定义的步骤和活动（如计划、需求、分析、设计、实现、测试等），以指导软件开发人员按照成本和进度等要求有序的开展工作。这些活动的实施直接关系到软件项目的产品、成本、进度和质量。由于软件项目组成员知识、技能和经验的差别，应用的特殊性等，不同的软件项目往往会采用不同的过程来指导软件系统的开发。因此，软件项目的管理必须对开发过程进行有效的管理，包括：明确过程活动，定义和改进过程，估算它们的工作量和成本，制定计划，跟踪过程，风险控制等等。
- 产品
软件项目开发会产生大量具有不同抽象层次的软件产品（包括各种文档和程序）。例如软件需求规格说明书、软件设计规格说明书、源程序代码、可执行代码、测试用例等等。这些软件产品相互关联。为了确保软件产品的质量，获得正确的版本，了解和控制产品的变更，在软件项目开发过程中必须对这些软件产品进行有效的管理，包括：明确有哪些产品，如何保证它们的质量，如何控制它们的变化等等。
图 1. 软件项目管理的对象
软件项目管理的上述三方面对象是密切相关的。软件项目中的各种产品归根结底是由人员通过执行各种软件开发活动和实施软件过程而得到的。针对上述三方面的管理对象，表 1列举了软件项目管理的主要内容。
表 1. 软件项目管理的主要内容
| 管理对象 | 人员 | 过程 | 产品 |
|
管理内容 |
团队建设和管理 | 软件过程定义和改进 | 软件质量管理 |
| 软件项目计划 | 软件配置管理 | ||
| 软件项目跟踪和控制 | 软件需求管理 | ||
| 风险管理 | |||
n 团队建设和管理
软件项目团队建设和管理的任务是要明确团体的结构，分配项目组人员的角色和任务，加强人员之间的交流、沟通和合作，制定和实施团队纪律，通过激励机制激发团队人员的工作激情。因此，软件项目团队建设和管理须关注以下几下方面的问题。
- 如何根据开发组织、软件项目和开发人员的特点来组建项目团队？
- 如何采取有效的措施来加强和促进人员之间的交流、沟通和合作？
- 如何提高团队的合作精神？
- 如何制定有效的纪律确保软件项目得以顺利的实施。
- 如何制定措施激励人员的积极性和热情等等。
n 软件过程定义和改进
软件项目的开发必须遵循一个良定义的软件过程。软件过程定义和改进的任务是在组织范围内明确软件开发所涉及的活动以及它们之间的关系，定义和文档化一个完整、灵活、简洁和可剪裁的，符合软件开发组织和软件项目特点的软件过程，并根据工程实践结果和软件开发组织的发展变化对软件过程不断进行改进和优化。因此，软件过程定义和改进须关注以下几下方面的问题。
- 如何根据软件开发组织和软件项目的特点选择、定义和文档化软件过程？
- 如何确保软件过程的有效性（包含必须的活动）、简洁性（舍弃无关紧要的活动）和灵活性（允许通过对它进行适当的剪裁以满足不同软件项目的开发要求）？
- 如何对软件过程不断进行改进和优化，以适应软件开发组织的发展需要等等。
n 软件项目计划
软件项目计划的任务是要根据软件项目的成本、进度等方面的要求和约束，制定和文档化软件项目的实施计划，确保软件开发计划是可行、科学、符合实际的。一般地，软件项目计划须关注以下几个方面的问题。
- 如何估算软件项目的规模、工作量和成本等？
- 如何根据软件项目的成本、进度等要求制定软件项目计划？
- 如何确保所制定的软件项目计划是科学的和合理的？
- 如何描述和文档化软件项目计划？
- 如何利用软件工具来辅助软件项目计划的制定等等。
n 软件项目的跟踪和控制
由于软件项目计划是预先制定的，许多问题可能考虑不到或考虑不周，因此很难保证软件项目的开发完全按照计划来执行。软件项目跟踪和控制的任务是要跟踪软件项目的实际执行情况，发现实际执行与计划二者之间的偏差以及软件项目存在的风险，从而提供项目实施情况的可视性，确保当软件项目开发偏离计划时能够及时调整软件项目计划。因此，对软件项目进行跟踪和控制须关注以下几个方面的问题。
- 需要对软件项目开发的哪些方面进行跟踪？
- 如何对软件项目的实施进行跟踪？
- 当软件项目的实施偏离计划时，如何调整软件项目计划？
- 当跟踪发现问题时如何进行处理？
- 如何利用软件工具的辅助来对软件项目进行跟踪和监督等等。
n 软件需求管理
需求分析是软件过程中一项极为重要同时又极为复杂的活动。软件需求通常具有难以确定和易变性的特点，而软件需求的变化将引发波动性和放大性问题。所谓波动性是指软件需求的变化会导致其它软件开发活动和软件产品的变化，如软件设计、编码和测试等。所谓放大性是指软件需求的一点变动往往会导致其他软件产品大幅度的变动。软件需求管理的任务是要获取、文档化和评审用户需求，并对用户需求的变更进行控制和管理。在软件项目开发过程中，需求管理应关注以下几个方面的问题。
- 如何获取需求？
- 如何撰写软件需求规格说明书？
- 如何对需求进行评审？
- 如何控制需求的变更？
- 如何利用软件工具的辅助来支持需求管理等等。
n 软件质量管理
软件项目管理必须自始至终关注所开发的各种软件产品的质量。软件质量保证的任务是要在软件项目开发过程中确保软件产品的质量，提供软件产品质量的可视性，知道软件产品的哪些方面存在质量问题，便于改进方法和措施，控制软件产品的质量。因此，软件质量保证应关注以下几个方面的关键问题。
- 软件产品的质量主要体现为哪些方面？
- 如何保证和控制软件产品的质量？
- 如何发现软件产品的质量问题？
- 如何利用软件工具的辅助来支持软件质量保证等等。
n 软件配置管理
软件开发过程中会产生大量的软件产品，许多软件产品会有多个不同的版本。软件配置管理的任务是要对软件开发过程中所产生的软件产品进行标识、存储、更动和发放，记录、报告其状态，验证软件产品的正确性和一致性，并对上述工作进行审计。因此，软件配置管理应关注以下关键问题的解决。
- 如何标识和描述软件产品？
- 如何对软件产品的版本进行控制？
- 如何控制软件产品的变更？
- 如何利用软件工具的辅助来支持软件配置等等。
n 软件风险管理
软件开发过程存在各种风险，这些风险的发生将对软件项目的实施产生消极的影响，甚至会导致软件项目的失败。软件风险管理的任务是要对软件过程中各种软件风险进行识别、分析、预测、评估和监控，以避免软件风险的发生或者减少软件风险发生后给软件项目开发带来的影响和冲击。因此，软件风险管理须关注以下几个方面的问题。
- 软件项目开发可能会有哪些软件风险？
- 如何在软件过程中识别各种软件风险？
- 如何客观地预测软件风险？
- 如何评估软件风险带来的影响？
- 如何避免和消除软件风险等等。
2 项目案例描述和假设
为了支持本章的案例分析和简化描述，下面对本书第一章所介绍的项目案例作进一步的解释和说明，并对该软件项目某些方面的内容进行假设。
某软件开发公司现要为某个航空机票预订服务商开发一个基于Internet的机票查询和预订管理系统，该系统的功能描述见本书x1.3节。该项目的合同额为50万元人民币。在签订合同时，用户方（即航空机票预订服务商）对该软件项目的开发提出了以下的要求。
- 项目自合同签订日（2006年6月1日）起，在半年后（即2006年12月1日）交付使用。
- 软件系统的需求以开发方和用户方双方共同签字认可的软件需求规格说明书为基准。
- 项目交付时，开发方应向用户方提交以下的产品：可运行的目标软件系统、用户使用手册、系统安装手册。
- 在软件交付使用的头一个月，开发商应提供全天24小时的服务，以纠正试运行期间发现的问题以及提高系统的性能。
为了开发该软件项目，软件开发公司成立了以小王为项目负责人的软件开发小组，其成员包括：小刘、老赵、小陈和小吴。
为了简化本章后面的案例分析，下面对该软件项目以及软件项目组作以下的假设。
- 该软件开发公司历史上曾经成功地开发过类似的软件项目。
- 该软件开发公司记录和积累了以往开发类似软件项目的实际数据，包括：成本、工作量、进度、人员费用的支出等等。
- 项目组的成员均有丰富的软件开发经验，尤其是项目组的老赵曾经负责过类似项目的需求分析和概要设计。
本章的后面还将根据案例分析的需要对上述软件项目作进一步的假设。
3 软件过程定义与改进
由于时间紧迫，项目负责人小王需要马上带领项目组展开软件项目的开发工作，但是他面临着一系列问题的解决。
- 软件项目开发需要做哪些方面的工作？
- 这些工作应该按照什么样的次序开展进行？
- 这些工作完成后将产生什么样的产品？
- 按照什么样的规范来书写这些产品？
- 如何让员工知道要做哪些工作等等。
为了回答上述问题，软件项目组需要定义一个清晰、详细、完整的软件过程以指导该软件项目的实施。小王向公司的技术负责人请教，希望能够获得以往软件项目所采用的过程或者公司所制定的软件过程，以便对它们进行剪裁或改进以支持该软件项目的开发。但是，公司没有该方面的任何记录，其它软件项目也没有保存以往的软件过程。于是小王不得不自己来定义该项目的软件过程。该案例提示我们：在项目实施之初项目组需要定义和文档化一个软件过程以指导软件项目的实施。
3.1 软件过程模型
根据IEEE-STD-610的定义，过程描述了针对一个给定目标的一系列操作步骤，操作步骤说明了有哪些操作以及按照什么样的方式来执行操作。软件过程是指按照项目的进度、成本和质量限制，开发和维护满足用户需求的软件所必需的一组有序的软件开发活动集合。这里的软件开发活动是指为开发软件项目而执行的一项具有明确任务的具体工作，它既包括技术活动（如需求分析、软件设计、编码、测试等），也包括管理活动（如制订软件项目计划，软件配置等）。软件过程中的各个软件开发活动间往往是相互关联。比如，某些软件开发活动需要等到其它软件开发活动完成之后才能实施，一些软件开发活动需要依赖于其它软件开发活动的输出结果。因此，软件过程的定义需要明确过程所涉及的活动、每个活动的细节（如任务、输入和输出）以及活动之间的关系。
软件过程将软件项目开发所涉及的人员、工具、方法和步骤等有机结合在一起。软件项目的开发必须依赖于一个良定义的、可不断改进的、符合软件项目特点的软件过程。没有一个预先定义好的软件过程，软件项目在预测和控制进度、成本和质量时经常要面临较大的风险[1]；无法对软件项目进行计划、跟踪、监督和控制；也势必影响软件项目组成员之间的交流和沟通。在介绍如何定义软件过程之前，先介绍软件工程领域人们已经提出的、常用的软件开发模型。
1． 瀑布模型
瀑布模型要求软件项目的开发严格按照软件生命周期的方式进行，如图 2所示。其特点是：（1）分阶段，将软件过程分为几个阶段来进行，整个软件过程与软件生命周期相一致；（2）阶段间有因果关系，前一阶段的输出是下一阶段的输入，下一阶段必须等到前一阶段完成之后才能实施；（3）评审，每个阶段完成之后需要对该阶段的产品进行评审；（4）允许反馈，如果在评审过程中发现问题，允许反馈到前面的阶段修改错误、弥补疏漏。
与其它软件模型相比较，瀑布模型非常简单，易于理解、掌握和管理。该模型隐式地假设在需求分析和定义阶段能够获得关于软件系统的完整需求，适合于那些需求易于定义、不易变动的软件系统的开发。此外，在该软件模型中，用户和软件项目负责人要等到软件项目的后期阶段才能得到软件系统的最初版本、了解产品的质量，因而不便于用户参与到软件项目的开发当中。如果在软件项目的后期用户对软件项目提出较大的修改意见，那么整个软件项目将蒙受巨大的人力、财力和时间上的损失。
图 2. 瀑布模型示意图
2． 快速原型模型
图 3. 快速原型模型示意图
针对瀑布模型的不足，快速原型模型允许在需求分析阶段对软件的需求进行初步（而不是完全的）的分析和定义，通过快速设计（如利用Visual Studio或JBuilder等工具）开发出软件系统的原型。该原型向用户展示了待开发软件系统的部分或全部功能和性能。用户可以通过对软件原型进行使用和操作，从而对软件原型进行评估，提出改进软件原型的意见。这些意见实际上反映了用户对目标软件系统的需求。根据用户的意见，软件开发人员可进一步对软件原型进行修改和完善，并再次将它交给用户进行分析和评估。如此循环反复，及至软件原型得到用户的最终认可。此时的软件原型对应于用户确认的软件需求。在此基础上，软件开发人员可以对软件系统进行设计、编码、测试和维护（见图 3）。
快速原型模型的特点是它不要求需求的预先完备定义，支持用户参与软件项目的开发过程中，尤其是在需求分析阶段，支持软件需求的渐进式完善和确认，能够有效适应用户需求的变化，因而适合于那些需求较为复杂、难以确定和易于变动的软件系统的开发。但另一方面，由于软件原型的修改和完善需要迭代进行，而且迭代的次数事先难以确定，因而给软件项目的管理带来一定的困难。
3． 增量模型
增量模型由瀑布模型演变而来，因而与瀑布模型很相似。在该软件模型中，软件系统是被增量式的一块块开发的。在完成软件系统的分析和高层设计之后，软件开发人员可以逐步、增量式地实现和完善系统的功能和性能（如图 4所示）。增量模型的一个显著特点是软件系统的各个模块很大程度上可以彼此平行的开发，开发活动允许重叠。这样做的好处是，通过逐步实现和完善系统的功能和性能，可以降低产品的技术风险，更快地开发出目标软件系统。
图 4. 增量模型示意图
4． 迭代模型
迭代模型（见图5）与增量模型似乎很相似，但它们是二个不同的软件过程模型。增量模型支持在软件需求和软件系统高层设计完成和确定之后，对软件系统进行逐步地构造。而迭代模型的特点是通过多次逐步的迭代，建立软件系统，每次迭代都是一个相对独立的软件过程，包含了需求分析、高层设计、详细设计、编码和测试等软件开发活动。每次迭代的结果将作为下一次迭代的基础。迭代的次数取决于具体的项目，当某次迭代的结果（即软件产品）完全反映了用户需求，迭代就可终止。迭代模型不要求一次性地开发出完整的软件系统，它将软件开发视为是一个逐步获取用户需求、完善软件产品的过程。因而能够较好地适应那些需求难以确定、不断变更的软件系统的开发。但是，由于迭代的次数难以事先确定，因而迭代模型增加了过程管理的复杂度。
图 5. 迭代模型示意图
5． 螺旋模型
螺旋模型结合了瀑布模型、快速原型模型和迭代模型的思想，并引进了风险分析活动。在螺旋模型中，软件开发是一个不断循环迭代的过程，每循环迭代一次，螺旋线就增加一周，软件开发前进了一次层次，系统生成一个新的版本，而软件开发的时间和成本又有了新的投入。每个循环迭代包括了以下四个阶段（见图 6）。
（1） 制定计划
（2） 风险分析
（3） 实施工程
（4） 客户评估
螺旋模型是针对风险较大的软件项目而提出来的，它试图克服瀑布模型的不足，并吸纳快速原型模型和迭代模型的优势。在每一个的迭代过程中，它都引入了风险分析活动，因而适合于那些用户需求难以获取和确定、软件开发风险较大的软件系统的开发。
图 6. 螺旋模型示意图
6． RUP
Rup（Rational Unified Process）是一种软件过程，它提供了在开发组织中分配任务和职责的严格方法，综合了许多现代软件开发的最佳实践（包括迭代开发、需求管理、基于构件的体系结构、可视化建模、验证软件质量和控制软件的变更），以一种可剪裁、可操作、详尽和实用的方式为软件项目提供过程指导，以帮助开发人员在预定的进度和预算范围内开发出符合用户需求的高质量软件系统。Rup的完整框架可以用一个二维结构来表示（如图 7所示）。其中，横轴代表时间，刻画了过程的时间因素和生命周期，体现了过程的动态结构，可以用周期、阶段、迭代和里程碑等术语来表示；纵轴代表核心过程规程，体现了过程的静态结构，可以用活动、规程、角色和工作流等术语来表示。
图 7. Rup模型示意图
表 2. 各种软件过程模型的特点
| 软件过程模型 | 特点 | 适合的软件项目 |
| 瀑布模型 | 简单，分阶段，阶段间有因果关系，每个阶段完成后有评审，允许反馈，不支持用户参与，要求需求可预先确定 | 需求易于完善定义且不易变动的软件系统 |
| 快速原型模型 | 不要求需求的预先完备定义，支持用户参与，支持需求的渐进式完善和确认，能够适应用户需求变化 | 需求复杂、难以确定、动态变化的软件系统 |
| 增量模型 | 软件产品是被增量式的一块块开发的，开发活动允许并行和重叠 | 技术风险较大，用户需求较为稳定的软件系统 |
| 迭代模型 | 不要求一次性地开发出完整软件系统，将软件开发视为是一个逐步获取用户需求、完善软件产品的过程 | 需求难以确定、用户需求不断变更的软件系统 |
| 螺旋模型 | 结合了瀑布模型、快速原型模型和迭代模型的思想，并引进了风险分析活动 | 用户需求难以获取和确定、软件开发风险较大的软件系统 |
| Rup | 可改造、扩展和剪裁；可以对它进行设计、开发、维护和发布；强调迭代开发 | 复杂和需求难以获取和确定的软件系统；项目组具有丰富的软件开发和管理经验 |
Rup不仅是一个软件过程，而且还是一个过程产品和过程框架。作为一个过程框架，人们可以对它进行改造、扩展和剪裁，以满足软件开发组织的特殊要求。作为一个过程产品，象其它软件产品一样，可以对它进行设计、开发、维护和发布，并且将它与一系列软件开发工具相集成，从而为Rup的开发、维护和应用提供工具支撑。比如，IBM公司定期地发布Rup的升级版本；提供了一个称为Rup Builder的软件工具对Rup进行剪裁和组织。
根据上述描述，不同的软件过程模型对软件开发过程有不同的理解和认识，支持不同的软件项目和开发组织。表 2对比分析了各个软件过程模型的特点及其适合的软件项目类型。
3.2 定义软件过程
软件项目的开发必须要有良定义的软件过程的指导。因此，在软件项目实施之前，软件项目组面临的一项重要任务是：定义或者选择一个适合于该软件项目的软件过程。如果开发组织已经预定义好了软件过程集，并且具有使用这些软件过程的经验，那么软件项目组可以从中选择适合其软件项目的开发过程。反之，软件项目组必须为其软件项目定义和文档化软件过程。定义和文档化软件过程大致步骤如图 8所示。
图 8. 定义软件过程的步骤
步骤1. 选择合适的软件开发模型
软件项目组需要根据各种软件过程模型的特点、综合考虑以下因素来为软件项目选择合适的软件过程模型。
- 软件开发组织和软件项目的特征
- 软件项目的风险
- 软件项目是否需要预先给用户展示原型
- 需要多少经验和技巧来成功的使用软件过程模型
- 软件开发组织和软件项目组人员的经验和能力
- 技术的成熟度等等
例如，如果软件项目的规模较小，需求易于确定，项目组人员的软件开发经验不够丰富，那么项目组可以考虑选择较为简单的瀑布模型。
步骤2. 确定和描述软件开发活动
一旦选择好软件过程模型之后，软件开发组织或者项目组需要明确软件过程应包含哪些活动，并描述这些活动。确定软件开发活动应遵循以下原则。
- 基于所选择的软件过程模型
- 所确定的活动对于软件项目开发是必要的
一般地，软件过程模型已定义了各种软件开发活动。在某些情况下，软件开发组织或者项目组可以针对软件开发组织或者软件项目的特殊情况和具体需要对软件过程模型中的软件开发活动进行必要的调整，包括增加新的活动、拆分某些活动、合并某些活动等等。例如为了强调软件集成测试计划的制定，可以考虑将软件系统的高层设计这一软件开发活动分解为以下二个子活动：概要设计和制定集成测试计划。
对于所确定的每一个软件开发活动，需要从以下几个方面对它加以定义和描述。
- 名称：说明软件开发活动的名称
- 任务：说明该软件开发活动的任务
- 输入：说明实施该活动所必须的输入，即开展该活动需满足的前提条件
- 输出：说明该活动实施完成之后所产生的结果
- 实施：说明如何实施该活动
下面以需求分析活动为例子说明如何描述和定义软件开发活动。
- 名称：需求分析
- 任务：进行需求调查，定义软件的用户需求；撰写软件需求规格说明书；根据软件需求规格说明书，制定软件确认测试计划；对软件需求规格说明书和软件确认测试计划进行评审，产生经批准的软件需求规格说明书和软件确认测试计划。
- 输入：用户的初步需求描述
- 输出：经批准的软件需求规格说明书；经批准的软件确认测试计划
- 实施：根据用户需求描述，分析和定义软件的用户需求，按照《软件需求规格说明书编写指南》撰写软件需求规格说明书；对软件需求规格说明书进行评审，评审的原则：正确性、完整性、一致性、简洁性、规范化；根据软件的用户需求，制定软件确认测试计划，按照《软件确认测试计划编写指南》撰写软件确认测试计划文档。
步骤3. 确定和描述软件开发活动间的关系
软件过程中的各个软件开发活动往往是相互关联的。这种关联性主要体现在以下二个方面。（1）执行时序关系，描述了软件开发活动之间执行的时间先后关系。例如，集成测试完成之后才能进行确认测试。（2）逻辑依赖关系，一个软件开发活动的执行需要其它软件开发活动实施所产生的结果。例如概要设计活动需要需求分析活动所产生的结果即软件需求规格说明书。可以通过显示地定义软件开发活动的输入和输出条件来描述软件开发活动之间的上述关系。下面描述了概要设计软件开发活动的输入和输出条件，这二方面条件的描述显示地定义了概要设计活动与需求分析、详细设计活动之间的关系。
- 输入（概要设计）：经批准的软件需求规格说明书
- 输出（概要设计）：软件概要设计规格说明书；数据库设计规格说明书；软件接口设计规格说明书
步骤4：文档化软件过程
在完成上述步骤之后，需要对软件过程进行书面、文字化的描述和记录，形成相应的规范化文档。对软件过程进行文档化的主要目的是：便于记录和保存软件过程；便于获取、理解和交流软件过程；便于对软件过程进行改进。
步骤5：评审软件过程
一旦软件过程文档生成之后，有必要在软件开发组织或软件项目组范围内对所制定的软件过程进行评审，以判断它们：
- 是否全面，包含了必须的软件开发活动？
- 是否正确和准确？
- 是否符合软件开发组织和软件项目的特点？
- 描述是否简洁、直观、易于理解？
- 是否易于改进等等。
如果在评审过程中发现了问题，那么可以回溯到前面的步骤以对发现的问题进行纠正。
步骤6：认可、发布和培训
如果软件过程通过评审，那么软件开发组织或者项目组需要公开认可和发布所定义的软件过程、对相关的人员进行必要的培训并强制执行，确保他们知道：为什么需要过程，软件项目组所采用的过程是什么，如何根据软件过程来实施项目等等。图9是印度Infosys公司在瀑布模型的基础上所定义和采用的软件过程[7]。
图 9. Infosys公司采用的软件过程
3.3 改进软件过程
经评审和发布之后，软件过程就可用于指导软件项目的开发。一般地，软件开发组织或者项目组将把文档化的软件过程作为一个配置项纳入配置，并成立独立的软件过程小组，负责对软件过程进行管理和维护。由于软件开发组织业务发展的需要、具体项目提出的一些特殊要求，尤其是在实际应用软件过程中发现的一些问题，因而需要对软件过程进行不断的改进和优化。
图 10. 软件过程改进示意图
软件过程的改进涉及多方人员，须遵循严格的步骤（见图 10）。首先，在软件项目实施过程中、完成之时、或者定期/不定期的检查中，软件开发组织或者项目组人员提出过程变更请求。例如，在进行软件项目管理过程中，项目经理发现软件项目组所采用的软件过程缺乏验收测试环节，因而需要对它进行改进。一般地，过程变更请求应采用书面的文档形式，并详细描述以下几个方面的内容：变更请求的发起人、变更提出时间、变更原因、变更建议等等。图 11描述了一个软件过程变更请求的例子。一旦接受到过程变更请求之后，软件过程小组将对过程变更请求进行评估。评估的结果有二种：接受请求或者拒绝请求。如果接受请求，那么软件过程小组将从软件配置库中提取软件过程文档，对软件过程进行变更，并和相关人员（如过程变更的请求方）一起对变更后的软件过程进行评审。一旦评审通过，需要将新的软件过程文档纳入配置，将它分发给软件开发组织或软件项目组的成员，必要时还需要进行相应的培训，以让它们了解变更。
图 11. 软件过程变更请求的例子
3.4 案例分析
图 12描述了针对本章应用案例和项目假设所制定的软件过程。它建立在瀑布模型的基础之上，并考虑了以下几个方面的因素。
- 项目组以前曾成功地开发过类似的软件项目，拥有该领域的知识，能较好地获取应用需求。
- 根据以往类似项目的软件开发经验，该软件系统的需求相对稳定且易于确定。
- 瀑布模型较为简单，比较适合于项目组人员的已有技能和水平，易于掌握和运用。
- 强调软件过程的简单性。
图 12. 针对软件项目案例所制定的软件过程
下面详细定义该软件过程所涉及的各个软件开发活动。
n 需求分析
- 任务：进行需求调查，定义软件的用户需求，撰写软件需求规格说明书；根据软件需求规格说明书，制定软件确认测试计划；评审软件需求规格说明书和确认测试计划。
- 输入：用户的初步需求描述。
- 输出：软件需求规格说明书；软件确认测试计划。
- 实施：根据用户需求描述，分析和定义软件系统的需求，按照《软件需求规格说明书编写指南》编写软件需求规格说明书；根据软件需求规格说明书，制定软件确认测试计划，按照《软件确认测试计划编写指南》编写软件确认测试计划文档。
n 概要设计
- 任务：根据软件需求规格说明书，进行软件系统的总体结构设计、接口设计和数据设计，撰写软件概要设计规格说明书；根据软件概要设计规格说明书，制定软件集成测试计划；评审软件概要设计规格说明书和软件集成测试计划。
- 输入：软件需求规格说明书。
- 输出：软件概要设计规格说明书；软件集成测试计划。
- 实施：根据软件需求规格说明书进行软件设计，按照《软件概要设计规格说明书
- 编写指南》编写软件概要设计文档；按照软件概要设计文档和《软件集成测试计划编写指南》编写软件集成测试计划文档。
n 详细设计
- 任务：进行软件的详细设计，撰写软件详细设计规格说明书；根据软件的详细设
- 计，制定软件单元测试计划。
- 输入：软件需求规格说明书；软件概要设计规格说明书。
- 输出：软件详细设计规格说明书；软件单元测试计划。
- 实施：根据软件需求规格说明书和软件概要设计规格说明书，进行软件的详细设计，根据《软件详细设计规格说明书编写指南》撰写软件详细设计文档；根据软件详细设计文档以及《软件单元测试计划编写指南》编写软件单元测试计划文档。
n 实现和单元测试
- 任务：编写程序；进行单元测试，撰写单元测试报告。
- 输入：软件详细设计规格说明书；单元测试计划。
- 输出：经过单元测试的软件模块；单元测试报告。
- 实施：根据软件详细设计规格说明书编写程序代码；根据单元测试计划对各个软
- 件模块进行单元测试。
n 集成测试
- 任务：集成各个软件模块进行测试。
- 输入：软件模块的程序代码；软件集成测试计划。
- 输出：可运行的、经过集成测试的目标软件系统；集成测试报告。
- 实施：根据软件模块的程序代码和软件集成测试计划，逐步组装各个软件模块以
- 进行集成测试，撰写集成测试报告。
n 确认测试
- 任务：根据软件系统的程序代码和软件确认测试计划进行确认测试，撰写确认测
- 试报告。
- 输入：软件系统的程序代码；确认测试计划。
- 输出：可运行的、经过确认测试的目标软件系统；确认测试报告。
- 实施：根据软件系统的程序代码和确认测试计划，对软件进行确认测试，撰写确
- 认测试报告。
n 文档编制
- 任务：撰写用户文档。
- 输入：软件需求规格说明书；软件概要设计规格说明书；可运行的目标软件系统。
- 输出：使用手册；安装手册；开发手册等。
- 实施：根据用户软件需求规格说明书，软件概要设计规格说明书和可运行的目标
- 软件系统撰写用户文档，包括：使用手册，安装手册，开发手册等等。
n 制作安装软件
- 任务：制作软件系统的安装程序。
- 输入：可运行的目标软件系统；使用手册；安装手册；开发手册等。
- 输出：软件系统的安装程序。
- 实施：对可运行的目标软件系统和相关文档进行打包，制作安装程序。
n 用户培训
- 任务：对用户就软件系统的安装、使用、维护和二次开发等方面进行培训
- 输入：可运行的目标软件系统；使用手册；安装手册；开发指南。
- 输出：无
- 实施：根据可运行的目标软件系统、使用手册、安装手册、开发指南等对用户进
- 行培训，使他们知道如何安装、操作和维护软件系统。
n 安装和部署
- 任务：将目标软件系统安装和部署到用户的机器上；向用户移交安装程序和相关
- 的文档。
- 输入：软件系统的安装程序。
- 输出：部署好的目标软件系统。
- 实施：根据安装软件和安装手册，安装、配置和部署软件系统。
4 软件度量
在项目策划阶段的碰头会上，公司负责人问项目负责人小王：“软件项目开发估计需要多少时间和成本？”，小王回答说“时间估计不会太长，成本也在一个可接受的范围之内”。公司负责人对小王的这种回答不满意，他希望能够得到关于软件项目较为准确的定量描述。经过一番考虑后，小王回答说“项目估计需要7－8个月，成本大约需40－45万”，公司负责人对这一数据极为兴趣，他进一步向小王问道：“你是如何得到这组数据？”。小王对此没有任何准备，也没有充分的依据，他无法对该问题作出回答。在制定软件项目计划时，小王又碰到一些更为具体的问题包括：不知如何预测软件项目的工作量？不知如何预测软件项目的成本？不知所制定的软件项目计划是否可行和科学？
该案例提示我们：为了支持软件项目的实施和管理，需要对软件项目的规模、工作量、成本、进度、质量等属性进行定量和科学的描述，具体表现在：
- 在开发前对软件项目的有关性质进行定量描述将有助于估算软件项目的成本和工作量，辅助软件项目计划的制定。
- 在开发过程中对软件项目的有关性质进行定量描述可以提供软件项目开发的可视性、支持对软件项目进行跟踪和控制、评估软件系统的质量、加强风险管理。
- 在开发之后对软件项目的有关性质进行定量描述可用于对软件项目的实施情况进行整体评估，为后续软件项目的开发积累经验数据。
4.1 度量、测量和估算
在现实世界中，人们对事物性质的描述大致可分为二类：定性描述和定量描述。例如，人们通常会说某某个子很高，某个软件的成本非常高等等。此类描述通常运用一些形容词来描述事物的性质，属于定性描述。与此相对应的，人们有时会说某某的身高有1.9米，某个软件的开发成本达1200万元人民币。这类描述通常采用一些数字来描述事物的性质，属于定量描述。显然，与定性描述相比较，定量描述能够帮助我们更为准确地理解事物的性质。
在软件工程领域，对软件项目性质的定量描述涉及三个基本的概念：度量（Metric）、测量（Measure）和估算（Estimation）。
软件度量是指对软件产品、软件过程或者资源的简单属性的定量描述。这里所指的产品是指软件开发过程中所生成的各种文档和程序，过程是指各种软件开发活动如需求分析、软件设计等，资源是指软件开发过程中所需的各种支持如人员、费用、工具等。简单属性是指那些无须参照其它属性便可直接获得定量描述的属性，如程序的代码行数目、软件文档的页数、程序中操作符的个数、程序中操作数的个数等等。
软件测量是指对软件产品、过程和资源复杂属性的定量描述，它是简单属性度量值的函数。一般地，软件测量用于事后或实时状态，用于对软件开发的历史情况进行评估。即当一个软件产品生成之后、一个软件开发活动完成之时，对它们的有关性质进行定量描述。例如，基于一些简单属性的定量描述（如程序中发现的错误数目），测量所开发软件系统的质量。
估算是指对软件产品、过程和资源复杂属性的定量描述，它是简单属性度量值的函数。软件估算用于事前，用于指导软件项目的实施和管理。即当软件产品还没有生成、软件开发活动还没有实施的情况下对它们的有关性质进行定量的描述。例如，在软件项目实施之前或者初始阶段，需要对软件项目的开发成本、工作量以及软件系统的规模等进行估算，以协助软件项目合同的签署以及软件项目计划的制定。
估算在软件项目管理中扮演着极为重要的角色。一个典型的例子是，在项目实施前软件项目组通常需要对软件项目的规模、工作量、成本等进行估算，估算的结果被用于指导软件项目计划的制定。因此，软件项目估算结果的合理性和准确性将直接影响到软件项目管理的有效性。试想一想，如果一个项目实际的工作量是500个人月（项目完成之后测量的结果），但是由于某些原因（如不准确的经验数据、过于乐观的估算等）在该项目实施前软件项目组对它的工作量估算为100个人月，显然这一估算结果与实际的结果有很大的差距，如果按照这一估算结果来制定软件项目计划，势必会影响整个软件项目的实施。由于软件是一个逻辑产品而不是物理产品；软件开发是基于各种软件工具的智力活动的过程，而不是体力活动的过程，因此在软件项目实施前估算出软件项目的规模、工作量和成本是一项非常困难的工作。为此，软件项目的估算需要一些方法和技术的支持。
规模、工作量和成本是软件项目的三个重要属性，也是软件项目管理中三个主要的估算对象。尽管它们是从不同的视点和角度（空间、时间和费用）来刻画软件项目的性质，但是对于特定的软件开发组织和项目组而言，这三者之间往往是逻辑相关的。软件项目的规模越大，开发该软件项目所需的成本和工作量相对而言也就越高。因此，在实际的估算过程中，对软件系统规模的估算往往有助于促进对软件项目工作量和成本的估算。
4.2 自顶向下和自底向上的估算方式
软件项目的估算通常可以采用以下二种不同的方式：自顶向下估算和自底向上估算。
在自顶向下的估算方式中，首先对软件项目某些属性的整体值（如整个项目的规模、工作量和成本）进行估算，然后根据这一估算值，软件项目在不同阶段或者软件开发活动中的属性估算值（如在需求分析阶段的工作量）就可以按照在整体工作量的百分比来确定。例如，假设通过估算某个软件项目的总工作量是120个人月，而需求分析在整个软件项目大约占25％的比例，那么就可以估算出需求分析阶段的工作量是30个人月。
在自底向上估算方式中，首先对软件项目某些属性的部分值进行估算（如某些阶段或者某个软件开发活动的工作量和成本，或者某个软件子系统的规模），然后在此基础上进行综合和累加，得到关于软件项目某些属性整体值的估算值（比如整个软件项目的工作量、成本和规模）。例如，如果通过分解可以将一个复杂软件系统分解为五个相对独立的子系统，而每个子系统的规模估算值分别为：10000、5000、6000、8000和12000行代码，那么整个软件项目的规模就是上述值的累加即41000行代码。
4.3 估算方法
下面介绍几种对软件项目的规模、工作量和成本进行估算的方法。
- 基于代码行和功能点的估算
软件项目的规模是影响软件项目成本和工作量的主要因素。在基于代码行（LOC，Line Of Code）和功能点（Function Point）的估算方法中，利用代码行和功能点来表示软件系统的规模，并通过对软件项目规模的估算进而来估算软件项目的成本和工作量。
显然,一个软件项目的代码行数目越多，它的规模也就越大。软件代码行的数目易于度量，许多软件开发组织和项目组都保留有以往软件项目代码行数目的记录，这有助于在以往类似软件项目代码行记录的基础上对当前软件项目的规模进行估算。
用代码行的数目来表示软件项目的规模简单易行，自然、直观且易于度量。但是其缺点也非常明显。在软件开发初期很难估算出最终软件系统的代码行数；软件项目代码行的数目通常依赖于程序设计语言的功能和表达能力；采用代码行的估算方法会对那些设计精巧的软件项目产生不利的影响；该方法只适合于过程式程序设计语言，不适合于非过程式程序设计语言（如函数式或者逻辑语言）。
针对上述问题，人们提出用软件系统的功能数目来表示软件系统的规模。1979年IBM的Albrecht提出了计算功能点的方法。该方法需要对软件系统的二个方面进行评估，即评估软件系统所需的内部基本功能和外部基本功能，然后根据技术复杂度因子对这二个方面的评估结果进行加权量化，产生软件系统功能点数目的具体计算值。具体的，以下是软件系统功能点的计算公式。
FP = CT× (0.65 + 0.01×SFi) （i=1..14）
其中，CT是5个信息量的“加权和”，Fi是14个因素的“复杂性调节值”（i =1..14），0.65和0.01是经验常数。
CT的计算方法如表 3所示，CT =（简单用户输入数×3 ＋一般用户输入数×4＋复杂用户输入数×6）+（简单用户输出数×4＋一般用户输出数×5＋复杂用户输出数×7）+（简单用户查询数×3＋一般用户查询数×4＋复杂用户查询数×6）+（简单文件数×7＋一般文件数×10＋复杂文件数×15）+（简单外部界面数×5＋一般外部界面数×7＋复杂外部界面数×10）。其中，用户输入数是指由用户提供的、用来输入的应用数据项的数目；用户输出数是指软件系统为用户提供的、向用户输出的应用数据项的数目；用户查询数是指要求回答的交互式输入的项；文件数是指系统中主文件的数目；外部界面数是指机器可读的文件数目（如磁盘或者磁带中的数据文件）。
表 3. CT值的加权计算
| 参数\取值\加权 | 加权因子 |
最终值 | ||
| 简单 | 一般 | 复杂 | ||
| 用户输入数 | ´3 | ´4 | ´6 | |
| 用户输出数 | ´4 | ´5 | ´7 | |
| 用户查询数 | ´3 | ´4 | ´6 | |
| 文件数 | ´7 | ´10 | ´15 | |
| 外部界面数 | ´5 | ´7 | ´10 | |
| CT= | ||||
Fi（i=1..14）14个因素的“复杂性调节值”取值见表 4。
表 4. Fi的取值表
| 序号i | 问题 |
Fi的取值（0,1,2,3,4,5） 0-没有影响 1-偶有影响 2-轻微影响 平均影响 4-较大影响 5-严重影响 |
| F1 | 系统需要可靠的备份和复原码 | |
| F2 | 系统需要数据通信吗 | |
| F3 | 系统有分布处理功能吗 | |
| F4 | 性能是临界状态吗 | |
| F5 | 系统是否在一个实用的操作系统下运行 | |
| F6 | 系统需要联机数据项吗 | |
| F7 | 联机数据项是否在多屏幕或多操作之间进行切换 | |
| F8 | 需要联机更新主文件吗 | |
| F9 | 输入、输出、查询和文件很复杂吗 | |
| F10 | 内部处理复杂吗 | |
| F11 | 代码需要被设计成可重用吗 | |
| F12 | 设计中需要包括转换和安装吗 | |
| F13 | 系统的设计支持不同组织的多次安装吗 | |
| F14 | 应用的设计方便用户修改和使用吗 |
例如，假设项目组要开发一个软件项目A。根据用户的需求描述，该软件项目的CT取值如表 5所示。进一步的，假设该软件项目的14个复杂性调节值全部取平均程度。那么根据表 5可知，该软件项目的CT=341，14个复杂性调节因素的累加值SFi=42，因而根据公式FP = CT× (0.65 + 0.01×SFi) （i=1..14）可知，该软件项目的功能点FP=341× (0.65 + 0.01×42) = 364.87，即该项目的功能点数目大致为364。
表 5. 软件项目A的CT值
| 参数\取值\加权 | 加权因子 |
最终值 | ||
| 简单 | 一般 | 复杂 | ||
| 用户输入数 | 6´3 | 2´4 | 5´6 | 56 |
| 用户输出数 | 7´4 | 6´5 | 5´7 | 103 |
| 用户查询数 | 2´3 | 0´4 | 5´6 | 36 |
| 文件数 | 0´7 | 3´10 | 3´15 | 75 |
| 外部界面数 | 2´5 | 3´7 | 4´10 | 71 |
| CT= | 341 | |||
用功能点来表示软件项目规模的好处是：软件系统的功能与实现该软件系统的语言和技术无关，而且在软件开发的早期阶段（如需求分析）就可通过对用户需求的理解获得软件系统的功能点数目，因而该方法可以较好地克服基于代码行软件项目规模表示方法的不足。其不足主要体现在：该方法没有直接涉及算法的复杂度，不适合算法比较复杂的软件系统；功能点计算主要靠经验公式，主观因素比较多；此外计算功能点所需的数据不好采集。
大量的实践表明：针对特定的程序设计语言，软件系统的功能点和代码行二者之间存在某种对应关系（如表 6所示）。根据该表的数据，一个功能点如果用汇编语言来实现大约需要320行代码，如果用C语言来实现大约需要150行代码，如果用SMALLTALK语言来实现大约需要21行代码。从另一个角度上看，该表反映了不同程序设计语言的描述能力是不一样的。
表 6. 功能点和代码行之间的转换表
| 序号 | 程序设计语言 | 代码行/功能点 |
| 1 | 汇编语言 | 320 |
| 2 | C | 150 |
| 3 | COBOL | 105 |
| 4 | FOTTRAN | 105 |
| 5 | PASCAL | 91 |
| 6 | ADA | 71 |
| 7 | PL/1 | 65 |
| 8 | PROLOG/LISP | 64 |
| 9 | SMALLTALK | 21 |
| 10 | 代码生成器 | 15 |
假设用L表示软件系统的规模（或者用LOC表示，或者用FP来表示）。针对一个具体的软件项目，可以采用自顶向下或者自底向上等多种方式来估算出软件项目规模的乐观值a、悲观值b和一般值m，然后根据以下公式估算出软件项目规模的期望值e：
e = (a + 4´m + b)/6
根据软件项目规模的期望值e以及下列公式，就可以估算出软件项目的成本和工作量。
生产率
PM = L / E
其中，L表示软件项目的规模（单位：LOC或者FP)，E表示软件工作量（单位：人月），PM表示单个人月能够生产的功能点或者代码行数。
平均成本
CKL = S / L
其中，S为软件项目总开销，L表示软件项目的规模（单位：LOC或者FP)， CKL表示每行代码或者每个功能点的平均成本。
对于一个特定的软件开发组织或者项目组而言，其软件生产率和平均成本在不同的软件项目实施中可能是比较稳定的。如果有以往软件项目的历史信息，可以很容易地获得关于软件开发组织或者项目组的PM和CKL值。因此，一旦估算出了软件项目的规模，获得了软件开发组织或者项目组的PM和CKL的值，就可根据公式CKL = S / L计算出软件项目的成本S = CKL´ L，也可根据公式PM = L / E计算出软件项目的工作量E= L / PM。
例如，假设项目组要开发一个软件项目A，经过估算该项目的规模是364个功能点。进一步的，根据以往的历史数据，该项目组软件开发的生产率是8FP/人月，每个功能点的平均成本为12000元人民币，那么该软件项目的开发成本S = 6800元人民币´ 364 = 247，5200元人民币，工作量为E= 364/ 8 = 45.5人月。
基于经验模型的估算
基于经验模型的估算根据以往软件项目实施的经验数据（如成本、工作量和进度等）建立相应的估算模型，并以此为基础对软件项目开发的有关属性进行估算。构造性成本模型CoCoMo（Constructive Cost Model）是目前应用最为广泛的经验模型之一。
在二十世纪七十年代后期，Boehm对多达63个软件项目的经验数据进行了分析和研究，在此基础上于1981年提出了CoCoMo模型用于对软件项目的规模、成本、进度等方面进行估算。Boehm把CoCoMo模型分为基本、中间和详细三个层次，分别支持软件开发的三个不同阶段。基本CoCoMo模型用于估算整个软件系统开发所需的工作量和开发时间，适合于软件系统开发的初期。中间层次的CoCoMo模型用于估算各个子系统的工作量和开发时间，适合在获得各个子系统信息之后对软件项目的估算。详细层次的CoCoMo模型用于估算独立的软构件，适合在获得各个软构件信息之后对软件项目的估算。由于篇幅限制，本书仅介绍基本CoCoMo模型，其模型形式描述如下。
E = a * (kLOC)b 。其中E是软件系统的工作量(单位：人月) ，a和b是经验常数，其取值见表 7，kLOC是软件系统的规模（单位：千行代码）。该公式描述了软件系统的规模与工作量之间的关系。
D = c * Ed。其中D是开发时间（单位：月），c和d是经验常数，其取值见表 7。该公式描述了软件系统的开发时间与工作量之间的关系。
表 7. 基本CoCoMo模型参数的取值
| 软件类型 | a | b | c | d | 适用范围 |
| 组织型 | 2.4 | 1.05 | 2.5 | 0.38 | 各类应用程序 |
| 半独立型 | 3.0 | 1.12 | 2.5 | 0.35 | 各类实用程序、编译程序等 |
| 嵌入型 | 3.6 | 1.20 | 2.5 | 0.32 | 各类实时软件、OS、控制程序等 |
CoCoMo模型是一个综合经验模型，它考虑了诸多因素，因而是一个比较全面的估算模型。CoCoMo模型有许多参数，其取值来至于经验值。该估算模型比较实用、易于操作，在欧盟国家应用较为广泛。
例如，针对上面所述的软件项目A，如果已估算出该项目的软件规模是33.3kLOC，而且该项目属于半独立型，即CoCoMo模型中的参数a、b、c、d的取值分别是3.0、1.12、2.5、0.35，那么根据模型公式E =a * (kLOC)b可以估算出该项目的工作量是3.0*(33.3)1.12，即152人月；然后根据公式D = c * Ed可以估算出该项目的开发时间是2.5*(152)0.35，即14.5月。
- 其它估算方法
其它估算方法包括：专家估算、类比估算等等。
专家估算方法是由一组专家来对软件项目所需的成本、工作量和进度等进行估算。一般地，这些专家具有应用领域或者开发环境方面的知识、参与了以往类似软件项目的开发。为了避免专家估算的片面性，专家估算方法一般要求每位专家给出估算的最小值a、可能值m和最大值b，然后计算出每位专家估算的平均值Esti =（a+4m+b）/6，最后根据各位专家的估算情况计算出最终的估算值Est=(Est1+Est2+Est3+……+Estn)/n。如果软件开发组织或者项目组拥有一批经验丰富的专家，可以考虑采用该方法。专家估算方法具有人为因素多、主观因素大的特点，一般应用于软件开发的初期阶段，此时软件项目组往往难以获得估算软件项目所需的各种数据和信息。
类比估算方法是指估算人员根据以往类似软件项目实施所积累下来的数据，通过分析待开发软件项目和以往软件项目二者之间的相似性，估算出软件项目的开发工作量、成本和进度等。使用该方法的前提是：待估算的软件项目和以往的软件项目必须具有一定的相似性（如它们均属于同样的应用领域），并且拥有以往类似软件项目的开发数据（如工作量、周期、参与的人数、规模和成本等）。
软件估算发生在事前，因而估算的结果与实际的结果有所偏差是不可避免的。但是，如果估算的偏差过大，那么估算的结果将会对软件项目的实施和管理产生消极的影响，甚至可能导致软件项目的失败。因此，在对软件项目的规模、成本和工作量等进行估算的过程中，要避免低劣的估算，尽可能地获得合理和准确的估算数据。
4.4 应用度量、测量和估算
软件项目的实施和管理离不开对软件项目的人员、产品和过程等性质的定量描述。对软件项目的定量分析和描述应该贯穿于整个软件开发过程，包括项目实施前、实施中和实施后。
n 项目实施前
– 获取历史数据，对软件项目的规模、成本和工作量等进行估算，以辅助合同的签署以及软件项目计划的制定。
– 记录并保存估算数据。
n 项目实施中
– 随着对软件项目了解的深入，不断调整软件项目的估算结果，以更好地指导软件项目的管理。比如，在完成了软件项目的需求分析之后，此时可较为完整和全面的理解软件项目需求，因而此时对软件项目的估算结果一般会较实施前的估算结果更为准确。
– 对软件项目的过程、产品和资源等方面的属性进行测量。比如，需求分析完成之后，软件项目组可以对需求分析阶段所花费的成本、工作量、人员以及所生成软件产品的质量等进行测量。
– 记录并保存各种估算数据和测量结果。
n 项目完成后
– 对项目进行总结，记录并保存软件项目运作的各种实际数据，如成本、工作量、进度、人员等等，为后续软件项目的估算和管理提供经验数据。
– 对软件项目实施中各个估算数据的调整、偏差等方面的情况进行分析和记录，以备后续软件项目参考。比如，项目实施完成之后，项目组发现：在项目实施之前利用CoCoMo模型对软件项目成本的估算结果较实际结果低10％，而较实施过程中的对软件项目成本的估算结果高5％。这些数据有助于后续软件项目对估算结果进行必要的调整。
5 软件项目计划
软件项目实施之初，公司负责人就提醒小王，为了更好地管理和控制软件开发项目，他应该马上着手制定软件项目计划。由于认识到软件项目计划的重要性，小王花了一周时间制定了一个详细的软件项目计划，包括了详细的工作安排、明确的人员分工和具体的进度要求，计划看起来似乎是科学和合理的。软件项目计划交给项目组的所有成员进行讨论，并交付给公司的领导审阅和批准，开始被付诸实施。软件项目计划分发给了项目组的各个成员，每个成员根据计划了解了各自的任务和工作，这些工作的实施进度要求。
根据软件项目计划开始阶段似乎一切顺利，各项工作已经按照计划的要求有序开展。然而，随着项目实施的进展，小王发现实际的工作很难按照计划中所计划的那样开展进行。在计划制定时，低估了软件项目的规模，高估了开发人员的素质和能力，整个计划过于乐观，软件项目计划不得不多次进行调整，项目进展一拖再拖。后来小王发现，低估项目规模的一个主要原因是由于在制定计划时缺乏对项目规模的详细、准确的了解。尽管小王向用户做了多次的解释将保证按期交付产品，用户对软件项目的按期交付表示怀疑，并要求加快项目的实施进度。公司高层开始表示关注，为了弥补时间和进度，不得不要求员工牺牲休息日进行加班，项目组部分人员开始抱怨。幸运的是，软件项目计划在经过多次的更改，在项目组人员的积极努力和用户的配合下，该软件项目最终在拖延了二个月之后顺利完工。
该案例提示我们：制定软件项目计划是软件项目管理过程中一项非常重要的工作。合理、有效的软件项目计划有助于软件项目负责人对软件项目实施有序和可控制的管理；确保软件项目组人员知道何时可利用哪些资源以开展什么样的工作，并产生什么样的产品，从而加强软件开发人员之间的交流、沟通与合作，保证软件项目实施的高生产率、产品的及时交付以及客户的满意度。
5.1 基本概念
软件项目计划是指对软件项目实施所涉及的活动、资源、任务、进度等方面作出的预先规划。一般地，它主要涉及以下几个方面的内容。
- 活动和任务的计划
这里所指的活动和任务来自于软件过程，它明确描述了软件开发过程中应做哪些方面的工作以及这些工作之间的关系。例如软件过程应包含以下的任务和活动：需求分析、软件概要设计、软件详细设计、编码和单元测试、集成测试、确认测试、用户培训等等。软件项目计划可对软件过程所定义的各种活动和任务作进一步的细化和分解，详细描述完成工作所需的具体步骤和逻辑顺序，从而更好的指导软件项目的实施和管理。例如为了加强需求分析阶段的软件项目管理，软件项目计划可以对 “需求分析”活动作进一步的细分，将它分解为：需求调查、需求分析和建模、撰写软件需求规格说明书以及需求评审等四个子活动，然后再对这些子活动制定它们的开发计划。
- 资源的计划
软件项目的开发需要大量、不同形式的资源，包括：人员、经费、设备等等。软件项目计划需要对这些资源的使用进行预先的规划。例如如何针对不同活动的特点有计划地分配资源（人员、资金、设备等），软件项目组人员在软件项目实施过程中扮演什么样的角色、负责和参与哪些活动等等。
- 进度计划
任何软件项目都有进度方面的要求和限制。进度计划描述了软件项目实施过程中各项软件开发活动和任务的进度要求。例如软件开发活动按什么样的时间进度开展实施，何时开始，何时结束；不同活动在时间周期上如何衔接等等。进度计划是软件项目计划中最为重要和最难制定的部分，它将对软件项目的开发产生重大影响。因此，软件项目负责人应重点关注进度计划的制定。
5.2 表示和分析软件项目计划
软件项目计划的表示和分析涉及以下几个方面的关键内容。
- 软件开发活动之间的关系
从时间的角度上看，软件开发活动之间的关系可以细分为以下几种。
n 结束到开始
该关系用于描述一个软件开发活动结束之后另一个软件开发活动开始实施（见图 13）。根据结束到开始之间时间间隔的差异，该关系又可以进一步细分为：结束之后就开始、结束几天后开始、结束几天前开始。
图 13. 软件开发活动之间的结束到开始关系
n 开始到开始
该关系用于描述一个软件开发活动开始之后另一个软件开发活动开始实施（见图 14）。根据开始到开始之间时间间隔的差异，该关系又可以进一步细分为：同时开始、开始几天后开始、开始几天前开始。
图 14. 软件开发活动之间的开始到开始关系
n 结束到结束
该关系用于描述一个软件开发活动结束之后另一个软件开发活动结束（见图 15）。根据结束到结束之间时间间隔的差异，该关系又可以进一步细分为：同时结束、结束几天后结束、结束几天前结束。
n 开始到结束
该关系用于描述一个软件开发活动开始之后另一个软件开发活动结束。一般地，该关系在制定软件项目计划中并不常用。
图 15. 软件开发活动之间的结束到结束关系
- 进度计划的描述
可以采用多种方法来表示软件项目的进度计划，其中最为常用的是甘特图和网络图。
n 甘特图
甘特图是一种图形化的任务表示方式（如图 16所示）。它的横轴表示时间，纵轴对应于各个软件开发活动或任务。甘特图用矩形来表示软件开发活动或任务，矩形中的文字描述了活动或任务的名称，其右侧的文字描述了该活动或任务所需的资源。矩形在甘特图中的位置反映了该活动或任务在软件项目中的起始时间，连接不同矩形之间的边描述了活动或任务之间在时间上的先后次序。由于甘特图能够方便和直观地描述软件开发活动或任务的起止时间，展示它们之间的时序关系，具有可视化、简单和易于理解的特点，因而被广泛用于描述软件项目进度计划。
图 16. 甘特图示意图
n 网络图
网络图也是一种图形化的任务表示方式。它用矩形来表示软件开发活动或任务，框内的文字显式描述了活动或任务的基本信息，如活动或任务名称、开始日期、结束日期、所需资源等，矩形之间的连线表示任务之间的相关性（见图 17）。
图 17. 网络图示意图
需要注意的是：甘特图和网络图二者是等价的，可以相互转换。用网络图描述的软件项目进度计划完全可以转换为用甘特图来表示，反之亦然。相比较而言，甘特图的特点是更能从时间的视点直观地显示活动或任务的进程，而网络图的特点是更能从过程的视点展示活动或任务之间的相关性。
- 关键路径分析
在制定软件项目进度计划时，进度计划的制订者和软件项目的负责人必须清晰地知道哪些软件开发活动将可能对软件项目的实施进度产生关键性的影响，这就需要对软件项目进度计划的关键路径进行分析。
所谓的关键路径是指软件项目进度计划中从起始活动开始到结束活动为止，具有最长长度的路径。这里所指的长度是指软件开发所需的时间周期。
图 18. 关键路径分析
在图 18所示的、用网络图描述的软件项目进度计划中，可以发现该软件项目首先需要实施开发活动A，然后并发地完成以下的软件开发活动：完成B和C、完成D、完成EFG。当软件开发活动C、D、G均完成之后，软件开发活动H才能得以实施。显然，该软件项目进度计划包含有三条不同的路径，即路径A-B-C-H、路径A-D-H和路径A-E-F-G-H。其中，路径A-B-C-H所需的工作周期是22个工作日；路径A-D-H所需的工作日是18个工作日；路径A-E-F-G-H所需的工作日是15个工作日。显然，路径A-B-C-H所需的工作日最多，因而在该软件项目进度计划中它属于关键路径。
关键路径上软件开发活动的实施进度将直接影响到整个项目的开发进度。如果关键路径上软件开发活动的进度受到影响，那么整个软件项目的开发进度肯定会受到影响，而一个软件项目如果要缩短开发周期，那么必须加快关键路径上开发活动的进度。
对于关键路径A-B-C-H而言，软件开发活动B和C工作周期的变化将直接会影响整个软件项目的进度。如果软件开发活动B和C所需的工作日减少，比如在实际执行项目时，软件开发活动C只需5工作日，而其它活动所需的工作日不变，那么软件开发活动H就可以提前2个工作日开始，整个项目的进度也会提前2个工作日完成；反之，如果软件开发活动C所需的工作日增加，比如在实际执行项目时，软件开发活动C需要10个工作日而不是原先计划的7个，其它活动所需的工作日不变，那么软件开发活动H就会比原先滞后3个工作日开始，整个软件项目的进度将会延迟3个工作日。
- 活动责任矩阵
软件项目进度计划除了要描述软件开发活动的实施进度之外，还需要清晰地定义各项软件开发活动所需的资源，尤其是人员。活动责任矩阵可用于定义与软件开发活动执行、评审和批准相关的人员和角色，它是软件开发进度计划的一个组成部分。
活动责任矩阵由二种不同形式的矩阵组成：软件开发活动－角色责任矩阵和角色－人员责任矩阵。软件开发活动－角色责任矩阵用于表示执行、负责、评审和批准各个软件开发活动所需的角色（见表 8）。例如，针对需求分析这一软件开发活动，执行这一活动的是需求分析小组，需求分析小组的组长负责这一软件开发活动，参与需求分析活动结果评审的角色包括：用户方代表、需求分析小组、软件设计小组、质量保证小组和软件测试小组，此外软件项目负责人和用户方负责人批准需求分析活动的结果。
表 8. 软件开发活动－角色责任矩阵
| 软件开发活动\角色 | 执行 | 负责 | 评审 | 批准 |
| 需求分析 | 需求分析小组 | 需求分析小组组长 | 用户方代表 需求分析小组 软件设计小组 质量保证小组 软件测试小组 | 软件项目负责人 用户方负责人 |
| 概要设计 | 概要设计小组 | 概要设计小组组长 | 需求分析小组 软件设计小组 质量保证小组 软件测试小组 | 软件项目负责人 |
但是，软件项目计划仅有上述软件开发活动－角色责任矩阵是不够的，还必须对软件项目组中的各个人员在项目实施中所承担的角色、或者是各个角色由哪些软件开发人员组成进行详细说明。为此，需要进一步定义角色－人员责任矩阵（见表 9）。
表 9. 角色－人员责任矩阵
| 角色 | 人员 |
| 需求分析小组 | 小张、小李、小王 |
| 需求分析负责人 | 小张 |
| 软件项目负责人 | 小宋 |
| 用户方代表 | 小张 |
| 用户方负责人 | 小董 |
活动责任矩阵明确、清晰地说明软件项目的职责区域；有助于项目组人员了解他们各自的任务和职责以及要参与的工作；促进项目组人员的沟通和合作；帮助他们预计其工作量。
5.3 制定软件项目计划要考虑的因素
软件项目计划的制定必须是针对特定的软件开发组织（如人员、经验等），满足特定软件项目的具体要求（如进度要求、成本要求等），并且要尽可能是合理和科学的。只有这样，所制定的软件项目计划才有意义，才能有效的指导软件项目的管理。
- 制定软件项目计划的基础和依据
制定软件项目计划的基础和依据如图 19所示，它包括以下三个方面。
图 19. 软件项目计划制定的基础和依据
n 软件过程（及其细化）
任何软件开发组织或项目组都有其软件过程用于指导软件项目的开发。软件过程定义了软件项目开发需经历的阶段和步骤，需要完成的活动和任务，以及它们之间的关系。软件项目计划（尤其是进度计划）的制定必须建立在软件开发组织或者项目组所定义的软件过程的基础上，对软件过程中所涉及的各个软件开发活动或任务所需的进度、人员、成本等进行预先的规划，从而确保所制定的软件开发计划符合软件开发组织和项目组特点。
如果软件项目定义了一个以瀑布模型为基础的软件过程来指导其软件项目的开发，而软件开发计划则基于螺旋模型给出了各项软件开发活动的预先规划，显然这样的软件开发计划是没有意义的，它脱离了软件项目组的具体要求，无法指导软件项目的实施。
n 要开展的工作
软件项目计划的制定必须依据要开展的工作（即要开发的软件系统）及其特点，包括：
(1) 工作说明和软件需求
(2) 历史数据
(3) 工作量和成本估算
假设通过估算某个软件项目的开发周期为6.5个月，成本大致需要25万元人民币。而在制定计划时，整个项目自开始开发到完成开发的持续时间为12个月，成本计划需要50万元人民币。显然，这样的计划与该软件项目不一致，因而也就无法指导该软件项目的开发和管理。
n 约束和限制条件
此外，软件项目计划的制定还必须考虑以下的约束和限制。
(1) 人员
任何软件开发项目组所能提供的人员都是有限的，人员方面的限制不仅包括人员的数量，而且还必须考虑人员的质量如经验、技能和知识等。对于同一个软件开发项目，一个由五名经验丰富的软件开发人员所构成的项目组与一个由三名新手所构成的项目组所对应的软件项目计划应该是不一样的。
(2) 资源
任何软件开发项目组所能提供的资源（如资金、设备等）也是有限的，因此软件项目计划的制定必须考虑到资源方面的限制。
(3) 进度
软件项目计划的制定必须考虑到用户对软件项目的进度要求。例如如果用户要求软件项目必须在一年之内完成，而在制定软件开发计划时没有考虑到这一点，最终规划在一年半后提交软件产品，显然这样的软件开发计划对用户而言是难以接受的。
- 制定软件项目计划的时机
软件项目计划一般是在软件项目实施之初制定，以指导软件项目的后续开发。由于制定软件项目计划需要考虑包括软件过程、要开展的工作以及约束和限制等三方面的因素，而在软件项目实施之初尚不完全明确要开展的工作（即软件需求），因此在项目实施之初要制定出一个合理、可行和符合项目特点的软件开发计划是不切实际的。
针对这种情况，可以在以下二个不同的时机来制定软件项目计划：（1）项目开始之初，制定初步的软件项目计划；（2）软件需求分析完成之时，制定详细的软件项目计划（见图 20）。
图 20. 制定软件项目计划的二个不同时机
n 初步的软件项目计划
- 时机：项目开始（1-2周内），但是还没有获取完整和详细的软件需求。
- 依据：项目的初步描述和用户需求的初步描述；软件过程；软件项目的限制和约束。
- 形式：仅仅计划最近（如需求分析阶段，而不是整个项目）的软件开发活动。
n 详细完整的软件项目计划
- 时机：获取了详细、完整的软件需求。
- 依据：软件需求规格说明书；定义的软件过程；软件项目的限制和约束。
- 形式：制定了项目后期的详细、完整的软件开发计划。
- 估算软件开发活动的周期
在制定软件项目进度计划前要做的另外一件非常重要的工作是：估算软件开发活动的持续周期。为了规划整个软件项目计划，项目计划的制订者必须估算出软件过程中各个软件开发活动所需的工作时间。
估算软件开发活动的周期是制定软件项目进度计划中最为困难同时也是最为关键的任务之一。软件开发活动周期估算的困难主要体现在：我们可以利用各种历史数据和经验模型来估算出整个软件项目开发的工作量和周期。但是，这些工作量和周期在软件过程的各个软件开发活动之间如何分布？每个软件开发活动所需的开发周期有多长？等等，关于这些问题在软件项目实施之初很难给出准确回答。
尤其是，软件系统以及软件项目组的不同特点将会对软件开发活动周期产生重要的影响。例如一个经验丰富、拥有应用领域知识的需求分析人员和一个经验缺乏、对应用领域知识一无所知的软件开发人员在实施需求分析活动时所需的开发周期显然是不一样的；对于同样一组需求分析人员要开发二个不同的软件项目，一个项目的需求易于确定、用户积极配合，另一个项目需求不易获取、用户比较消极，即使这二个软件项目的规模大致一样，对这二个项目进行需求分析所需的周期也会有所差别。
估算软件开发活动周期在软件项目计划制定中扮演着极为重要的角色。如果对软件开发活动周期估算的不准确，过于乐观或者过于悲观，都将对软件项目进度计划产生负面的影响。例如如果软件项目进度计划的制订者对软件项目需求分析活动的乐观估算结果是2个月，而实际的需求分析活动花费了整整4个月的时间，显然需求分析活动的这一估算结果将使得进度计划不切实际，不利于软件项目的管理。
对软件开发活动周期的估算大致有以下几种方法。
n 细分活动
大量的软件工程实践表明：将一个大粒度的软件开发活动分解为一组细粒度的软件开发活动，将有助于准确地估算该软件开发活动的周期。
例如，要直接估算出一个软件项目需求分析活动的周期是比较困难的。在这种情况下，可以考虑将需求分析活动分解为以下一组子活动：（1）需求调查；（2）需求建模和分析；（3）撰写软件需求规格说明书；（4）需求评审。显然，对这些子活动的开发周期进行估算要比对整个需求分析的开发周期进行估算要容易的多。如果某个子活动的开发周期仍然不好估算，可以对该子活动作进一步的细分。比如，对于需求调查活动而言，如果其开发周期仍不能给出直接的估算，可以将它进一步细分为以下二个子活动：（1）需求讨论和资料收集；（2）需求资料的汇总。
n 借鉴历史数据
参考以前类似软件项目执行需求分析、概要设计、详细设计、编码和单元测试、集成测试等软件开发活动所需的周期，以此来估算当前软件项目执行相应软件开发活动所需的周期。例如，如果根据历史数据，在以往软件项目中对类似应用进行需求分析大约需要3个月的时间。考虑到已拥有类似项目的需求模型和规格说明书以及需求分析人员拥有该领域的知识背景和开发经验，可以大致估算出当前软件项目的需求分析活动的开发周期不会超出3个月。显然，采用这种方法的前提是必须拥有以往类似软件项目开发的数据。
n 借鉴经验数据
借鉴经验数据，尤其是关于软件开发周期分布的经验数据。大量的软件工程实践经验表明，在软件项目开发过程中，需求分析和软件设计所需的时间大约占整个项目的40%-50%，调试和测试的时间大约占整个项目的30%-40%，编码的时间大约占整个项目的10%-20%（见图 21）。因此，如果一个软件项目的开发周期估算是100个工作日，那么需求分析和软件设计大约需要40-50个工作日，编码大致需要10-20个工作日，测试和调试大约需要30-40个工作日。
图 21. 软件开发周期分布图
需要注意的是，对软件开发活动的周期进行估算应考虑以下的因素。
- 以工作日（而不是星期）来规定活动周期
这主要是考虑到每周尽管有7天，但是其中有2天是休息日。
- 预留缓冲时间
要考虑意外事件的缓冲，确保项目按照计划有足够的时间来完成软件开发活动。例如，假设经过估算需求分析需20个工作日，计划从8月1日开始到8月29日结束，但中间公司要开展2天的全员培训，因此需求分析的计划结束日期应该是8月31日。
- 不要在计划中考虑加班时间
对于许多软件项目而言加班是不可避免的。如果在制定计划时就考虑了加班，那么在项目实施过程中可能会需要更多的加班。
- 考虑节假日
例如，假设经过估算编码活动需10个工作日，计划从9月30日开始，由于10月1日是国庆，期间放假1周，因此该活动的计划结束日期应该是10月16日。
- 考虑评审所花的时间
按照软件工程的思想，任何软件开发活动完成之后，都要对该软件开发活动所产生的软件产品进行评审，而软件产品的评审需要一定的周期。对于某些重要的软件产品（如软件需求规格说明书）而言，其评审往往要持续较长的时间。
- 考虑传播时间
不同软件开发活动之间往往是相互关联的。一个软件开发活动的输出（软件产品）往往是另一个软件开发活动的输入。但是，一个软件产品从一个软件开发活动输出，到另一个软件活动的输入，这期间需要时间。例如需求分析阶段通常会有以下二个子活动：撰写软件需求规格说明书和需求评审。撰写软件需求规格说明书活动的结果是产生软件的需求规格说明书文档，该文档将作为需求评审的主要对象。但是，软件需求规格说明书完成之后，将它递交给相关的人员对它进行评审，这中间需要时间。不能期望通过电子邮件将软件需求规格说明书电子文档发送给用户方代表后，他马上就可以收到。如果采用邮寄的方式，软件需求规格说明书文档的传播时间可能更长。
n 考虑教育和培训需要
在软件项目实施过程中，通常需要对软件项目组人员进行必要的培训。软件开发活动周期的估算必须要考虑到该因素。例如在需求分析开始阶段，项目组要用2个工作日的时间对应用需求的背景、需求建模工具、需求调查的指导原则等方面的内容进行培训，因此对需求分析活动周期必须要包含这2天的时间。
5.4 制定软件项目计划的步骤
软件项目计划的制定可遵循以下的步骤（见图 22）。
图 22. 制定软件项目进度计划步骤
n 步骤1. 指定软件项目计划制定负责人
软件项目计划的制定是一项复杂的工作，工作量大，涉及多方人员包括用户、项目经理、开发人员、其他计算机系统小组，通常需要持续较长的时间，因此在制定软件项目计划之前，软件项目的负责人有必要指定专门的软件项目计划制定负责人。软件项目计划制定负责人既可以是软件项目负责人自身，也可以是其它的人员。他是一个全日制的职位，其职责主要是负责在各类人员之间协商关于软件项目计划的有关约定并以此为基础制定项目软件计划。例如在本章的项目案例中，软件项目负责人小王可以指定自己作为软件项目计划的制订者。
n 步骤2. 召开软件项目计划会议
由于软件项目计划受多方人员的关注，并将对他们参与软件项目的开发和管理产生重要的影响，因此软件项目计划的制定必须征询各方的意见、协调各方的立场，这就有必要召开有关软件项目计划的会议。
例如需求分析活动的周期估算和进度安排必须听取需求分析小组及其负责人的意见。如果软件项目计划负责人所制定的计划要求需求分析小组在一个月内完成需求分析工作，而需求分析小组认为他们不可能按照此进度开展工作，显然这样的软件项目计划是没有意义的。同样的，如果软件项目计划负责人和需求分析小组认为可以通过一周的集中调查来获取用户的初步需求，而用户认为一周的时间过于密集，这会影响他们正常的工作，显然这样的软件项目计划也是不可行的。一般地，软件项目计划会议主要涉及以下几个方面的内容。
- 确定每个软件开发活动的负责人
软件项目的负责人和软件项目计划制定的负责人根据软件过程，确定每个软件开发活动的负责人。这些软件开发活动的负责人将代表他们所在的小组参与软件项目计划的制定，并完成以下与软件项目计划制定相关的工作：细化所负责的软件开发活动（足够详细，便于管理和估算进度）；确定活动之间的关系；确定活动的持续时间；确定活动所需要的资源；列出与每个活动相关的一些基本假设和要求如生产率、所需的人和机器、开发人员的工作能力和技能等等。软件项目计划制定负责人可以和这些人协商他们所负责软件开发活动的进度、人员、资源等方面的问题，从而促进软件开发计划的制定以及相应结果的确认。
- 对软件开发计划进行讨论，协调各方立场，并就有关问题达成一致意见。
软件项目开发所涉及的多方人员可能就计划的某些方面产生不一致的观点。因此，在软件项目计划会议上，软件项目计划制定的负责人需要对这些不一致、甚至是相互矛盾的人员和观点进行协调。例如需求分析活动的负责人认为可以用一周的时间来进行需求调查，而用户方认为一周时间是不够的。在此情况下，软件项目计划的负责人需要协调它们的立场和观点，尽可能达成一致。
- 收集各个软件开发活动负责人所提交的计划数据
进度计划会议的另一项重要工作是收集各个软件开发活动负责人所提交的计划数据，作为制定软件项目计划的依据。
n 步骤3. 制定进度计划
软件项目计划负责人对前一步骤所收集的计划数据进行分析，使用某些工具（如Microsoft Project）来制定整个软件项目的开发计划。
一般地，软件项目计划的制定主要涉及以下三个方面的工作。（1）进度安排，根据各个软件开发活动负责人所提交的活动进度估算数据，软件项目计划负责人可以采用网络图、甘特图等方式详细描述软件项目各项开发活动的进度安排。（2）资源使用，软件开发过程中各项软件开发活动的实施均需要相应的资源（如人员、设备等）。尤其是人员的配置是软件项目计划制定中一项非常重要的工作。软件项目计划负责人根据各个软件开发活动负责人所提交的数据，采用活动责任矩阵等表示方法详细描述各个软件开发活动的资源使用计划。（3）成本预算，一旦确定了各个软件开发活动所需的资源（如人员和设备等），就可以很容易地计算出各个软件开发活动所需的成本，从而给出他们的成本预算。
n 步骤4. 评审软件项目计划
如果软件项目计划能为大部分人所接受，那么接下来的工作就是要对软件项目计划进行评审。一般地，软件项目计划制定负责人召开项目计划的评审会议，与会人员应包括管理层、开发人员、质量保证人员、甚至是用户。
评审的目的是要发现所制定的软件项目计划中存在的问题，包括：（1）是否得到相关人员的认可；（2）是否符合软件项目的特点；（3）是否满足软件项目的具体约束；（4）是否与软件过程相一致；（5）各个估算数据是否中肯和合理等等。如果在评审中发现问题，那么应该将这些问题记录成册，并作为改进软件项目计划的依据。
n 步骤5. 批准项目进度计划
一旦软件项目进度计划在评审会议上通过评审，那么软件项目进度计划制定的负责人就可以将他递交给相应的管理层（如软件项目的负责人、组织的负责人等）进行批准。
5.5 应用软件项目计划
图 23. 成功的软件项目计划的前提和所带来的影响
一个成功的软件项目计划应是多方共同参与制定的，建立在科学和准确的估算基础之上，充分借鉴以往软件项目开发的经验。它将有助于项目组按时完成软件项目，提供高质量的软件产品，提升项目组人员的成就感和实践水平，准时交付软件产品，获得客户的信任。
图 24. 失败的软件项目计划的前提和所带来的影响
失败的软件项目计划往往是由于进度方面的压力、不准确的估算和过于乐观的计划等方面的因素造成的。它将可能引发项目延迟、软件产品质量低下、员工情绪低落发牢骚、频繁换人、软件产品交付延迟、与客户关系紧张和信誉度受损等不良的影响。
一旦软件项目计划得到批准，那么就要在后续的软件项目开发中应用该软件项目进度计划，包括：（1）将评审后的软件项目计划分发给所有的项目组成员，让他们了解软件项目计划，知道他们在软件项目中所扮演的角色以及所承担的任务，明确完成这些任务所需的进度限制，发现与其工作相关的其他人员以更好的进行交流、沟通和合作。（2）严格按照计划来开发软件项目。
6 软件项目跟踪和控制
根据软件项目计划，需求分析负责人老赵带领需求分析小组人员开始需求分析工作。项目执行了两周，一切似乎正常。然而进入第三周后，软件项目出现了许多意想不到的问题。
- 需求分析进行了两周后，需求分析负责人老赵通过对比已完成的工作和尚未完成的工作，发现需求分析小组已无法按照原先软件项目计划按期完成需求分析工作。
- 与进度面临同样问题的是，小王从公司的财务部门得到通知，项目在需求分析阶段的成本已经超支。
- 更为糟糕的是，项目组的技术骨干小刘由于某些原因提出要辞职，他的辞职将给该项目的实施带来一系列的问题。
- 另外根据老赵的反映，近段时间用户对需求分析小组的支持力度不够，出现了闹矛盾的现象。
该案例提示我们：软件项目的实施具有不确定性、动态性和不可预知性的特点，实施过程中会出现很多问题，许多问题事先（即在制定软件项目计划时）很难预测到；此外要确保软件项目完全依照计划来实施是比较困难的，对某些项目而言甚至是不切实际的，软件项目的实际执行和预先计划二者之间会有偏差。因此，在软件项目实施过程中，软件项目负责人必须及时了解软件项目的实际执行情况，发现软件项目实施过程中存在的问题，清楚地知道存在哪些偏差，并采取措施以纠正偏差和解决问题。这就需要在软件项目的实施过程中对软件项目的执行情况进行跟踪和控制。
6.1 软件项目跟踪的对象
软件项目的跟踪和控制是指在软件项目的实施过程中，随时掌握软件项目的实际开发情况，使得当软件项目实施与软件项目计划相背离，或者出现问题和风险时，能够采取有效的处理措施来控制软件项目的实施。
软件项目的跟踪和控制将给软件项目的实施提供可视性，比如项目的实际执行和实施情况，项目实施过程中可能会出现的问题等等，因而知道如何采取相应的措施来防止问题的出现，或者出现时该采取什么办法减少它给软件项目实施带来的影响和损失。比如，当某个软件开发阶段（如需求分析）的任务完成之时，通过跟踪可以发现该阶段的工作相对于软件项目计划而言是提前了还是滞后了，或者按期完成。如果与软件项目计划不一致，那么就需要对原先的软件项目计划进行调整。
一般地，软件项目的跟踪对象主要包括以下几个方面。
n 项目问题和风险
软件项目在实施过程中会出现各种各样的问题和风险，它们将对软件项目的开发产生消极的影响。因此，在软件项目的实施过程中，必须及时地发现这些问题和风险，并采取相应的措施。项目实施过程中可能存在的典型问题和风险包括：
- 技术风险，如某项需求尚未找到合适的技术解决途径，或者原先所设计的技术解决途径被发现不合适。
- 成本风险，如由于没有有效的控制支出，实际成本超出原先计划的成本预算，并且仍然不断增长。
- 人员风险，如项目组成员临时跳槽或者调派，人员缺乏。
- 工具和设备风险，如所需的工具和设备不能按时提供，或者得不到等等。
在项目跟踪过程中，软件开发人员必须识别各种软件开发问题和风险，对这些问题和风险进行描述和分析（如图 26所示），并以风险清单的形式详细记录各个软件开发风险，包括：标识、名称、处理的起始时间、处理的目标结束时间、处理的负责人等等（见表 11）。
图 26. 软件开发问题描述
表 11. 项目风险清单
n 项目进展
由于用户需求的变更、交流的不畅、人员的调整以及受到其它不可预知情况的干扰等因素，软件项目的实际进展与软件项目计划二者之间会产生偏差。比如，原先计划用五周时间完成需求分析工作，但是在实际执行软件项目时，由于某些方面的原因需求分析工作化了六周时间，比原先的计划滞后了一周。
软件项目的实际进展与原先计划二者间的不一致将使得原有的软件项目计划形同虚设，没有意义。试想一想，如果按照原先的软件项目计划，项目组应该在第六周进入概要设计阶段的工作，但是实际上第六周需求分析工作尚未完成。因此，在这种情况下原有的软件项目计划将无法指导软件项目的实施。解决这一问题的办法是在软件项目实施过程中及时了解项目的实际进展情况，发现实际进展和计划之间的偏差，并以此为基础来调整软件项目计划。
因此，在软件项目实施过程中，项目组人员尤其是软件项目的负责人需要记录软件项目尤其是软件开发活动的实际进展情况，通过和原先的软件项目计划进行对比，发现二者之间的偏差。图 27以图形的方式描述了软件项目的实际进展与软件项目计划二者之间的对比分析。表 12以表格的方式描述了项目软件开发活动的实际进展和计划进展之间的对比分析。
图 27. 项目实际进展和计划进展之间的对比分析示意图
表 12. 软件开发活动实际进展和计划进展之间的对比分析
6.2 软件项目跟踪和控制的方法
图 28. 软件项目的跟踪和控制方法
图 28描述了软件项目的跟踪和控制方法。软件项目跟踪和控制的基础包括两个方面：软件项目计划和项目开发进程。软件项目计划描述了有关软件项目开发的进度、成本、资源和人员等方面的预先规划，它是判断软件项目实施是否发生偏差的主要基准。软件项目的开发进程描述了软件项目的实际执行情况，它是了解软件项目的实施进度以及面临问题的主要依据。软件开发人员尤其是软件项目负责人需要跟踪软件项目实施过程中的两方面对象：软件项目存在的风险、问题和项目进展，从而采取相应的措施来应对偏差（如调整软件开发计划）、解决问题和消除风险。
为了支持软件项目的跟踪和控制，软件项目组一般要成立一个软件项目跟踪小组，其成员一般由软件项目组人员组成。对于一些规模比较大的软件项目而言，软件项目跟踪小组的成员可以由一些软件开发活动的负责人或者子课题的负责人组成。软件项目跟踪小组需要指定一个负责人，用于负责协调软件项目的跟踪工作。
一般地，软件项目跟踪小组应定期（如每周一次）召开软件项目跟踪和控制会议，获取软件项目实施的详细情况和面临的问题。软件项目跟踪会议的召开应注意以下问题。
- 围绕跟踪对象，不要离题，以提高会议的效率。
- 明确与会人员的职责和任务，防止推卸责任。
- 会议日程应预先安排好并通知有关人员，以便他们有所准备，确保每个人有备而来。
- 限定阐述时间，言简意赅。
- 费时的问题留待会后解决。
- 鼓励开放、坦诚地汇报情况。
- 形成记录并在会后分发记录。
软件项目跟踪小组可以制定出如图 29所示的报表，以便软件项目跟踪小组成员更好地记录和反应软件项目实施情况以及面临的问题。
图 29. 项目情况汇报示意图
通过跟踪，发现软件项目的偏差以及存在的问题和风险并不是软件项目跟踪和控制的最终目的。软件开发人员尤其是项目负责人必须根据发现的偏差、问题和风险尽快地提出纠正偏差、解决问题和消除风险的办法，以控制软件项目的正常实施。
6.3 软件项目跟踪和控制的步骤
软件项目跟踪和控制与软件项目开发之间的关系如图 30所示。软件项目的跟踪和控制应该与软件项目的开发同步，并且贯穿于整个软件开发过程。软件项目跟踪和控制需要采集项目实施的数据和情况，发现问题和偏差。这两部分工作可以通过定期地召开软件项目跟踪会议来完成。通过跟踪，需要采取措施来解决所发现的问题、纠正偏差，因而可能需要对软件项目计划进行调整。调整后的软件项目计划将用来指导软件项目的进一步实施。图 31描述了软件项目跟踪和控制的一般步骤。
n 步骤1. 成立软件项目跟踪小组
在软件项目实施之初，软件项目组应成立软件项目跟踪小组，并指定负责人。软件项目跟踪小组及其负责人应在召开软件项目跟踪会议之前明确某些要求和约定，如软件项目跟踪会议的时间、地点；会上应采用什么样的方式来汇报项目的实施情况和存在的问题等等。
n 步骤2. 召开软件项目跟踪会议
在软件项目跟踪会议上，软件项目跟踪小组的成员汇报项目进展情况，形成会议记录并在会后分发给相关人员。
n 步骤3. 采取措施
针对发现的问题和偏差，软件项目组人员尤其是软件项目负责人应采取相应的措施来调整软件项目计划以修正偏差，或者解决所发现的问题，消除潜在的软件风险。对于那些相对简单、易于解决的问题而言，软件项目跟踪小组就可以在软件项目跟踪会议上采取措施并达成一致，对于较为复杂的问题而言可在会后加以解决。
n 步骤4. 转到步骤2及至项目结束
图 30. 软件项目跟踪和控制与软件项目实施之间的关系
图 31. 软件项目跟踪和控制的步骤
7 软件风险管理
软件项目的实施往往会遇到各种意想不到的风险。小王所带领的项目组也不例外。
- 软件项目实施三个月后，软件项目组成员小刘突然有一天告诉软件项目负责人小王，他计划离开公司前往国外留学。小刘的离开显然将影响软件项目的正常实施，给项目组带来损失。可以想象，小刘的离开将给项目组带来一系列问题：谁来接替小刘的工作？在此之前谁来负责交接小刘的工作等等。尽管上述事件还没发生，但软件项目负责人小王必须考虑如何避免上述问题的发生，以及一旦发生后该采取的措施，以便将损失减少到最小。
- 在需求分析过程中，需求分析小组在和用户交流中发生了矛盾，出现了争吵。软件项目组和用户方二者之间的关系紧张。软件项目组和用户方出现这种状况是双方没有想到的。如果任其发展下去，势必会影响整个需求分析工作。
- 在软件设计阶段，项目软件设计负责人小王发现，用户需求中的某项需求至今尚未找到有效的技术解决途径。显然，该问题将直接影响软件项目的后续开发工作。如果项目组不尽快找到解决该问题的技术途径，那么整个软件项目就会停滞不前。
上述案例提示我们：软件项目实施过程中存在大量的风险；软件风险形式多样；许多软件风险事先难以确定。如果不对风险进行良好的管理，项目就很难保证按照计划、在成本和进度范围内，开发出高质量的软件产品，甚至会导致项目失败，因此必须对项目实施过程中发生的风险进行有效的管理。
7.1 软件风险
软件风险是指使软件项目的开发受到影响和损失、甚至导致软件项目失败的可能发生的事件。例如软件开发人员的临时流失、软件项目计划过于乐观、软件设计的低劣等等。一般地，软件风险具有以下的特点。
- 事先难以确定。例如在上述例子中软件项目负责人小王和其他项目组人员在项目实施之前或者之初不会想到小刘会要求在项目实施过程中离开项目组。
- 带来损失。对软件项目开发带来负面和消极影响，甚至可能会导致项目失败。软件风险给软件项目开发带来的损失表现出不同的形式，如导致软件产品质量的下降、软件开发进度的滞后、无法满足用户的需求、软件开发成本的上升等等。
- 概率性。软件风险本身是一种概率事件，它可能发生也可能不发生。但是一旦它发生，势必会对软件项目产生消极影响。
- 可变性。软件风险在一定条件下可以转化。原先为风险的事件可以转化为非风险事件，而非风险事件也可以转化为风险事件。
7.2 软件风险类型
软件项目开发会遇到各种形式的风险，下面列举了一些常见的软件风险。
n 计划编制风险
- 计划、资源和产品的定义完全由客户或上层领导决定，忽略了软件项目组的意见，并且这些决定不完全一致。
- 计划忽略了必要的任务和活动。
- 计划不切实际。
- 计划基于特定的项目组人员，而这样的项目组人员得不到。
- 软件规模估算过于乐观。
- 工作量估算过于乐观。
- 进度的压力造成生产率的下降。
- 目标日期提前，但没有相应地调整产品范围和可用资源。
- 一个关键任务的延迟导致其他相关任务的连锁反应。
n 组织和管理风险
- 缺乏强有力、有凝聚力的领导。
- 解雇人员导致软件项目小组能力下降。
- 削减预算打乱软件项目计划。
- 仅由管理层和市场人员进行技术决策。
- 低效的项目组织结构降低软件开发的生产率。
- 管理层审查/决策的周期比预期时间长。
- 管理层作出了打击软件项目组积极性的决定。
- 非技术的第三方的工作比预期要长（如采购硬件设备）。
- 计划性太差，无法适应期望的开发速度。
- 软件项目计划由于压力而放弃，导致开发混乱。
- 管理方面的英雄主义，忽视客观确切的状态报告，降低发现和改正问题的能力。
n 开发环境风险
- 开发设施和工具不能及时到位。
- 开发设施和工具到位但不配套。
- 开发设施和工具不如期望的那样有效。
- 开发人员需要更换开发设施和工具。
- 开发设施和工具的学习期比预期要长。
- 开发设施和工具的选择不是基于技术需求，不能提供计划要求的功能。
n 最终用户风险
- 最终用户坚持新的需求。
- 最终用户对交付的软件产品不满意，要求重新开发。
- 最终用户不买进项目产品，无法提供后续支持。
- 最终用户的意见未被采纳，造成软件产品无法满足用户要求。
n 承包商风险
- 承包商没有按照承诺交付软件产品。
- 承包商提供的软件产品质量低下，必须花时间改进质量。
- 承包商提供的软件产品达不到性能要求。
n 需求风险
- 需求已经成为软件项目基准，但仍在变化。
- 需求定义欠佳：不清晰、不准确、不一致。
- 增加了额外的需求。
n 产品风险
- 错误发生率高的模块，需要更多的时间对它进行测试和重构。
- 矫正质量低下的软件产品需要更多的时间对它进行测试和重构。
- 由于功能错误，导致需要重新进行设计和实现。
- 开发额外不需要的功能延长了进度。
- 要满足软件产品规模和速度要求，需要更多的时间。
- 严格要求与现有系统兼容，需要更多的时间。
- 要求软件重用，需要更多的时间。
n 人员风险
- 招聘人员所需的时间比预期要长。
- 作为开发人员参与工作的先决条件（如培训、其它项目的完成等）不能按时完成。
- 开发人员与管理层关系不佳导致决策迟缓、影响全局。
- 项目组人员没有全身心地投入到项目中，无法达到所需的软件产品功能和性能需求。
- 缺乏激励措施、士气低下。
- 缺乏必要的规范，增加工作失误，重复工作，降低工作质量。
- 缺乏工作基础（语言、经验、工具等）。
- 项目结束前，项目组人员离开软件项目组。
- 项目后期，加入新的软件开发人员，额外的培训和沟通降低了软件项目组人员的开发效率。
- 项目组人员不能有效的在一起工作。
- 由于项目组人员间的冲突，导致沟通不畅，设计欠佳，接口错误和额外重复的工作。
- 有问题的项目组人员没有及时调离软件项目组，影响其他人员的工作积极性。
- 最佳人选没有加入软件项目组，或者加入软件项目组但没有合理使用。
- 项目组关键人员只能兼职参与。
- 项目组人员的数目不足。
- 任务的分配和人员的技能不匹配。
- 人员工作的进展比预期的要慢。
- 项目管理人员怠工，导致计划和进度失效。
- 技术人员怠工导致工作遗漏、质量低下，工作需要重做。
n 设计和实现风险
- 设计过于简单，考虑不仔细、不全面，导致重新设计和实现。
- 设计过于复杂，导致一些不必要的工作，影响效率。
- 设计质量低下，导致重新设计和实现。
- 使用不熟悉的方法，导致需要额外的培训时间。
- 产品使用低级语言编写，导致开发效率较低。
- 分别开发的模块无法有效集成，需要重新设计和实现。
n 过程风险
- 跟踪不准确，导致无法预知项目进展是否落后于计划。
- 前期的质量保证行为不真实，导致后期的重复工作。
- 没有遵循标准，导致沟通不足，质量问题和重复工作。
- 风险管理粗心，导致没有发现重大的软件项目风险。
7.3 软件风险管理模式
鉴于软件风险的负面性和可变性等特点，在项目实施过程中项目组人员和负责人必须对软件项目中的风险进行管理。有效的风险管理可以缓解甚至消除软件风险的发生，降低软件风险发生后给软件项目实施带来的影响和冲击。下面列举了一些常见的软件风险管理模式。
n 危机管理
这种模式类似于救火模式，其特点是听任软件风险的发生，及至软件风险给软件项目开发造成麻烦后才着手进行处理。例如，针对小刘要离开软件项目组这一风险，软件项目负责人知道这一软件风险，但是没有采取任何措施。在小刘离开项目组一个月之后，软件项目组的其它成员需要与小刘所负责的子系统模块进行集成和测试时，才发现相关代码还没编写。显然，此时这一风险已经严重影响了软件项目组其他人员的工作，并将使软件项目的进度滞后。在这种情况，软件项目负责人才采取相应的措施来处理风险（如抽调其他人员来接替小刘的工作）。
n 失败处理
在这种模式中，项目组人员和负责人察觉到了潜在的风险，但听任软件风险的发生和演化，只是在风险发生之后才采取应对措施。例如，针对小刘要离开项目组这一风险，项目组没有采取任何的措施。在小刘离开项目组的第二天，项目组决定抽调其他人员来接替小刘的工作，但是此时已经无法和小刘进行面对面的项目交接。
显然，无论是危机管理模式还是失败处理模式，它们对于风险的处理都是非常消极的，因而在软件项目实施过程中不主张采用这两种风险管理模式。
n 风险缓解
在风险缓解模式中，项目组人员和负责人在软件开发过程中有意识地识别各种软件风险，并且针对这些软件风险事先制定好风险发生后的补救措施，但是不做任何防范措施。也就是说，项目组人员和负责人预先识别和分析哪些不好事件可能会发生，等它发生，并制定好这些事件发生后的应对措施。例如，项目组成员和负责人已经知道小刘要离开项目组，但是没有采取任何措施来防止这一事件的发生，听任其发展，不过他们制定了相应的措施，一旦小刘离开项目组，小张来接替小刘的工作。显然，与危机管理和失败管理模式相比较，风险缓解模式在处理和应对软件风险方面变的较为积极。
n 风险预防
风险预防模式将风险识别和风险防范作为软件项目的一部分加以规划和执行。项目组人员和负责人预先识别和分析哪些不好事件可能会发生，制定好了万一发生的应对措施，同时采取措施防止它发生。例如，项目组人员和负责人知道小刘要离开项目组，一方面和和小刘商量能否等到项目完成之后再离开，另一方面制定了相应的措施，一旦小刘离开项目组，就由小张来接替小刘的工作。
n 消灭根源
在该模式中，项目组人员和负责人不仅要识别软件开发过程中各种潜在的软件风险，而且还要分析导致这些软件风险发生的主要因素，并采取积极的措施消除软件风险产生的根源。也就是说，项目组人员和负责人预先识别哪些不好事件可能会发生，制定好了万一发生的应对措施，同时采取措施消除软件风险根源，杜绝软件风险的发生。例如，针对小刘要离开项目组这一风险，项目组人员和负责人制定了相应的措施，一旦小刘离开项目组，就由小张来接替小刘的工作。同时，通过和小刘的交流发现，导致小刘离开项目组的主要原因是小刘认为公司给他的薪水太低，与他的技术水平以及给公司和软件项目组所做的贡献不匹配。针对这一因素，公司和软件项目组考虑给小刘增加薪水和补贴，以打消小刘离开软件项目组的念头。
显然，后三种风险管理模式对于软件风险的处理更加积极，他们能更为有效地降低软件风险给软件项目实施所带来的消极影响，因而在软件项目管理中应加以提倡。
7.4 软件风险管理方法
软件风险管理的方法如图 36所示，它大致包括风险评估和风险控制二个主要部分，目的是在软件风险影响软件项目实施前，对它进行识别和处理，并预防和消除软件风险的发生，包括：识别风险（会有哪些软件风险），预防和消除风险（最好不要让软件风险发生）以及制定软件风险发生后的处理措施（万一软件风险发生该怎么办）。
图 36. 软件风险管理的方法
- 风险评估
风险评估包括三个子活动：（1）风险识别：识别软件风险，形成软件风险列表；（2）风险分析：评判每个软件风险发生的概率、产生的影响及其重要性；以及（3）风险优先级：按照每个软件风险的重要性给出软件风险的优先级。
n 风险识别
在软件开发过程中，识别软件项目可能存在的各种潜在软件风险，并形成如表 13所示的软件风险列表，它列举了软件项目在某个阶段存在的软件风险及其编号。
表 13. 软件风险列表
n 风险分析
风险分析是要评估所识别的各项软件风险发生的概率、估算软件风险发生后可能造成损失以及计算软件风险危险度。
对软件风险发生概率的评估应采用以下方法。由熟悉系统、有软件开发经验的人参与评估；可以由多人独立评估，然后进行综合折中。软件风险发生的概率既可以采用定量的表示方法（如0.1概率），也可以采用定性的方法（如非常可能、可能等）。一般地，定性表示方法和定量表示方法二者之间有一定的对应关系（见表 14）。
表 14. 软件风险发生概率的定性描述
从总体上看，对软件风险发生概率的评估主观性较强，评估的结果因人而异，不同人对同一软件风险的评估结果可能会有一定的偏差。表 15列举了软件开发风险及其发生概率。其中，编号为1的软件风险“软件项目规模估算的结果过于乐观”发生的概率为0.7。
表 15. 软件风险及其发生概率列表
针对所识别的每一个软件风险，评估它们将对软件项目实施所造成的损失。可以基于“进度”，“成本”或者“工作量”等方式来表示这种损失。表 16用工作量来表示和度量软件风险发生后给软件项目所造成的损失。比如编号为1的风险“软件项目规模估算的结果过于乐观”发生后，将可能给软件项目带来8个人周的工作量损失。
表 16. 软件风险及其发生概率和造成的损失列表
根据每个软件风险发生的概率和损失，计算出它们的危险度 = 风险概率 × 风险损失（见表 17）。
表 17. 软件风险及其发生概率、造成的损失和危险度列表
n 风险优先级
大量的软件工程实践表明，软件项目80%成本用于解决20%的问题。也就是说，在软件工程实践过程中可能会出现大量的问题，其中20%的问题是核心和关键。软件风险管理也类似，要重点关注其中的关键性软件风险。所谓的关键软件风险是指那些危险度较高的软件风险。例如在表 17中，编号为1、3和6软件风险的危险度非常高。根据软件风险的危险数，可以对软件风险的优先级进行排序。经过排序后的软件风险列表（见表 18）清晰地显示了哪些软件风险的危险度比较高，需要重点关注；哪些软件风险的危险度比较低，可以暂时不予考虑。
表 18. 软件风险的优先级列表
需要注意的是，软件风险的危险度在软件过程中会动态地发生变化。比如对于编号为4的软件风险“需求分析人员不能按时到位”，在软件项目实施初始该软件风险的危险度和重要性并不突出。随着项目的开展尤其是需求分析的深入，如果该软件风险仍然没有得到消除，那么其危险度将会越来越高。
- 风险控制
识别和分析风险并不是软件风险管理的最终目标。针对所发现的每一个软件风险，尤其是高危险度的软件风险，风险管理还需要对它们进行有效的控制，包括：（1） 制定风险管理计划：针对各个重要风险制定风险管理计划，并确保它们的一致性；（2）化解风险：执行风险管理计划，以缓解或消除风险；（3）监控风险：监控风险化解的过程。
n 制定风险管理计划
针对每一个重要的软件风险，制定相应的处理该软件风险的计划。风险管理计划主要描述有关软件风险处理的以下内容（如表 19所示）。
- 软件风险名称
- 软件风险由谁引起
- 软件风险的表现形式是什么
- 软件风险可能什么时候发生
- 为什么会发生该软件风险
- 如何避免或者消除软件风险的发生
- 软件风险发生后的处理措施
表 19. 风险管理计划
n 风险化解方式
执行风险管理计划，以缓解或消除风险。一般地，软件风险化解有以下几种方式。
- 避免风险
采取主动和积极的措施来规避软件风险，将软件风险发生的概率控制为零。例如针对用户可能没有时间参加需求评审这一软件风险，项目组可以考虑选择用户方便的时间来进行需求评审，这样“用户不能出席需求评审会”这一软件风险就不会发生。
- 转移风险
将可能或者潜在的软件风险转移给其它的单位或个人，从而使得自己不再承担该软件风险。例如如果开发某个子系统存在技术和人力资源方面的风险，可以考虑将它外包给其它软件开发公司，从而将该软件风险从项目中转移出去。
- 消除发生软件风险的根源
如果知道导致软件风险发生的因素，那么针对这些因素，采取手段消除软件风险发生的根源。例如如果发现导致小刘离开项目组的主要原因是薪酬太低，那么可以通过给小刘增加薪酬来消除发生软件风险的根源。表 20列举了常见软件风险的控制方法。
表 20. 常见软件风险及其控制方法
n 风险监控
在风险评估和控制过程中，项目组人员和负责人必须对软件风险的化解程度及其变化（如发生概率、可能导致的损失和危险度）进行检查和监控，并对收集到的有关软件风险信息进行记录，以促进对软件风险的持续管理。
风险监控的主要内容包括：监控和跟踪重要软件风险，记录这些软件风险危险度的变化以及软件风险化解的进展，确认软件风险是否已经得到化解和消除，是否有新的软件风险发生等等。表 21描述了软件项目实施过程中软件风险的变化及其化解进展。
表 21. 风险监控表格
7.5 案例分析
针对本章项目案例，下面以需求分析阶段的软件开发活动为例，描述软件风险管理过程。在第一周的软件项目跟踪会议上，需求分析负责人老赵向软件项目负责人小王汇报了项目组至今发现的两个潜在软件风险，给出了各个软件风险发生的概率，计算出了它们的危险度，并根据危险度对它们进行排序（见表 22）。老赵在项目开始之初就已经发现至今公司和项目组缺乏相应的规范来指导软件需求规格说明书的撰写；此外根据用户的反映他们由于业务繁忙，在近段时间内无法配合需求分析小组开展需求调查工作。显然，这二方面的软件风险都会给软件项目的实施带来消极的影响。
表 22.第一周的软件风险列表
针对上述软件风险，软件项目负责人小王制定了如下所示的风险管理计划。按照该计划，由项目负责人小王和用户方代表交互，希望用户方能够积极协助需求分析小组开展需求调查工作。此外，软件项目负责人小王还要和公司管理层反应，以获取软件需求规格说明书编写指南。
软件项目实施进行第二周，在软件项目跟踪会议上，需求分析负责人老赵发现，由于公司没有软件需求规格说明书编写规范，因而编号为2的软件风险并没有得到消除；关于编号为1的软件风险，尽管软件项目负责人小王与用户方代表进行了交涉，但是本周用户业务繁忙，无法很好地协助软件项目组开展需求调查工作，从而给软件项目的实施带来了损失，导致软件开发进度滞后。但是用户方已经承诺将在第三周全力以赴支持软件项目组的需求调查工作。此外，需求分析小组在第二周又发现了一些新的、潜在软件风险（见表 23）。
表 23. 项目案例第二周的软件风险列表
- 编号为3的软件风险，用户增加了额外的需求，该软件风险将可能导致软件开发工作量的增加，为此需要调整软件项目计划，甚至推迟软件产品的发布时间。
- 编号为4的软件风险，软件项目规模的估算过于乐观，该软件风险将可能导致实际的软件项目规模大于原先的估算结果，为此项目组将不得不调整软件项目计划。
- 编号为5的软件风险，需求建模和分析所需的软件工具尚未到位，该软件风险将可能导致需求分析小组不得不采用原始的方式来对用户需求进行分析和建模，从而降低需求分析的质量和效率。
需要注意的是，在第二周的软件风险列表中，编号为2的软件风险继续存在，而且随着撰写软件需求规格说明书日期的临近，其软件风险发生的概率在不断增加。针对上述软件风险，软件项目负责人小王制定了如下所示的风险管理计划。
软件风险管理计划
(2006-06-15至2006-06-22)
| 风险编号 | 2 |
| 风险名称 | 缺乏软件需求规格说明书的编写指南 |
| 风险发生的对象 | 项目组 |
| 风险发生的原因 | 未知 |
| 风险可能发生的时机 | 一周后 |
| 消除风险的措施 | 由需求分析负责人制定针对本项目的软件需求规格说明书编写指南 |
| 风险发生后的应对措施 |
|
| 风险编号 | 3 |
| 风险名称 | 用户计划增加额外的需求 |
| 风险发生的对象 | 用户方 |
| 风险发生的原因 | 未知 |
| 风险可能发生的时机 | 本周 |
| 消除风险的措施 | 由项目负责人小王和用户方代表交互，希望用户能够将待增加的需求放在项目二期进行处理 |
| 风险发生后的应对措施 | 重新估算软件项目的规模、成本和工作量，调整初步的软件项目计划，推迟软件产品的交付时间 |
| 风险编号 | 4 |
| 风险名称 | 软件项目规模的估算结果过于乐观 |
| 风险发生的对象 | 软件项目计划制定的负责人小王 |
| 风险发生的原因 | 估算过于乐观 |
| 风险可能发生的时机 | 下周 |
| 消除风险的措施 | 软件项目计划制定的负责人小王重新对软件项目的规模进行估算 |
| 风险发生后的应对措施 | 调整初步的软件项目计划 |
| 风险编号 | 5 |
| 风险名称 | 需求建模和分析所需的软件工作尚未到位 |
| 风险发生的对象 | 需求分析小组 |
| 风险发生的原因 | 未知 |
| 风险可能发生的时机 | 下周 |
| 消除风险的措施 | 由项目负责人小王和公司的有关部门进行交付，让他们确保本周内能够将所需的软件工具购买到位 |
| 风险发生后的应对措施 | 用其它软件工具替代 |
根据上述风险管理计划，软件项目负责人小王首先和用户方代表进行协商，并得到对方的认可同意将待增加的需求放在后续的项目中来实施。此外，通过对软件项目规模的进一步深入分析，原先的估算仍然是比较合理的。小王还在跟踪会议结果之后与公司的采购部分进行了交涉，确保需求分析小组所需的软件工作能够按期到位。
8 软件质量管理
软件项目负责人小王带领软件项目组按照计划实施软件项目。需求分析小组在需求分析截至日期的前两天撰写好了软件需求规格说明书。由于考虑到进度方面的压力，软件项目组用了一天的时间对软件需求规格说明书进行了评审和批准，随即在第二天就开始了软件设计工作。软件设计工作进展顺利，与计划相比较提前一周撰写好了软件设计规格说明书。尽管如此，软件项目组仍然决定尽快地推进软件项目开发，因而只用了一天的时间对软件设计规格说明书进行评审和批准，随后软件项目组开始编码阶段。在程序设计阶段，各个程序员工作的非常卖力，编写好了各个软件模块并且对各个模块进行了简单的测试，认为软件系统已经没有什么大的问题，即使有也是微不足道的，最终将目标软件系统提交给了用户。
但是，用户在使用了目标软件系统之后发现该软件存在诸多问题。软件系统没有完全满足他们的要求，整个软件系统的质量低劣，包括：有些软件功能与他们所想象的不一致；软件系统不稳定，经常出现死机现象；目标软件系统没有用户所需要的一些功能等等。
针对这些问题，项目组不得不重新作进行需求分析，与用户进行充分的协商和确认。在此基础上，设计小组对该软件系统的原先设计重新进行改造。然而此时软件设计小组发现软件系统的原先结构设计得不好，要对软件系统进行调整和修改非常困难。然而为了完成软件项目的开发要求，设计小组只好硬着头皮对原先的软件设计进行修改。经过调整后的软件系统问题更多，系统更加不稳定和脆弱。最后，项目组不得不推翻原有的设计，对整个软件系统重新进行设计和编码。该项目最终在拖延了四个月后完成。
该案例提示我们：在软件过程中，软件项目组尤其是软件项目负责人不仅要考虑软件项目的进度，而且还要确保所开发的软件产品的质量。仅关注进度而不考虑质量将使软件项目的开发受到多方面的损失，包括：软件成品质量低劣，成本超支，进度延滞，客户的满意度低下等等。提高软件系统质量的一个重要措施是在软件项目实施过程中要对待开发软件系统的质量进行有效的管理。
8.1 软件质量
软件质量是指软件产品满足用户要求的程度。可以从多个方面来理解此处所指的用户要求，包括用户期望的软件系统的功能、性能、可维护性、可操作性、可重用性等等。在软件项目实施过程中，经常会听到用户关于软件系统的以下一组质量评价。
- 软件系统没有某些方面的功能
- 软件系统运行速度太慢
- 软件系统有太多的错误
- 软件不好改动
- 软件系统的界面不美观
- 软件系统不好使用
- 软件系统安装过于复杂等等
上述评价揭示了软件系统的质量有内在和外在两方面的表现形式。所谓软件系统质量的外在形式是指那些直接展示给用户的质量要素，如软件系统提供的功能是否完整、性能是否高效、人机交互界面是否美观、是否易于操作、安装是否简单等等。软件系统质量的内在形式是指那些不直接展示给用户，但是与用户的需求息息相关的因素，如软件系统的模块化程度、软件系统的可维护性等等。在软件开发过程中，软件开发人员不仅要关注软件系统的外在质量要素，而且还要关注其内在的质量要素。
n McCall软件质量模型
图 37. McCall的软件质量要素
影响软件系统质量的要素往往是多方面的。图 37描述了由McCall定义的软件质量要素。它从三个不同的视点来理解和分析软件系统的质量，包括：产品转移性、产品修正性和产品运行性。对于每一个视点，McCall提出了一组质量因素来描述从该视点所观察到的质量特性。比如，产品的转移性主要体现为产品的可移植性、可重用性和可互操作性三个因素。针对每个质量因素，McCall进一步定义了25个质量准则，来对基于该要素的质量特性进行分析和度量。比如，判断可移植性高低的质量准则有：模块性、自描述性、软件/硬件平台无关性。表 27列举了各个质量要素的内涵及其评价准则。
表 24. 评价软件质量要素的准则
| 质量因素 | 内涵 | 评价准则 |
| 可移植性 | 把软件从一个硬件配置/软件环境转移到另一个硬件配置/软件环境的难难易程度 | 模块性、自描述性、软件/硬件平台无关性 |
| 可重用性 | 软件能够在其它应用系统的开发中被再次使用的程度 | 普遍性、模块性、软件/硬件平台无关性、自描述性 |
| 可互操作性 | 软件系统与其它系统相互交换信息并使用所交换的信息的能力 | 模块性、通信通用性、数据通用性 |
| 可维护性 | 对软件系统中的故障进行定位和修改以及对软件系统进行扩充的难易程度 | 一致性、简单性、简洁性、模块性和自描述性 |
| 灵活性 | 修改运行程序的难易程度 | 模块性、可扩展性、自描述性 |
| 可测试性 | 对软件系统进行测试以发现故障的难易程度 | 简单性、模块性、工具和自描述性 |
| 正确性 | 软件满足规格说明以及实现用户目的程度 | 可追溯性、一致性、完备性 |
| 可靠性 | 软件在规定的进度下执行预期功能的程度 | 容错性、一致性、精确性、简单性 |
| 有效性 | 软件使用计算机资源的程序 | 执行有效性、存储有效性 |
| 完整性 | 控制未被授权人员访问程序和数据的程序 | 访问控制、访问审计 |
| 可用性 | 学习、操作、准备输入和解释输出的难易程度 | 可操作性、培训、沟通 |
McCall进一步提出了一组经验公式，用于对上述评价准则、质量要素和软件系统的质量进行定量的度量，感兴趣的读者可参阅[9]。
8.2 软件质量保证
确保软件系统的质量是软件项目管理的重要目标之一。因此在软件项目实施过程中，软件开发人员必须要确保：（1）软件项目的实施完全遵循相应的过程和标准，比如软件需求规格说明书撰写完之后，按照软件过程，项目组对软件需求规格说明书进行了评审。（2）有效地发现软件系统中存在的质量问题，比如通过测试发现软件代码中的缺陷等等。这就需要对软件系统的质量进行保证。
所谓软件质量保证（Software Quality Assurance, SQA）是指一组有计划和有组织的活动，用于向有关人员提供证据证明软件项目的质量达到有关的质量标准[5]。一方面，软件质量保证是有计划和有组织的，而不是随机和任意的，想做就做，想不做就不做。因此，在软件项目开发之初，项目组应制定相应的软件质量保证计划，以指导软件过程中的质量保证活动。另一方面，软件质量保证要为软件产品的质量提供某种可视性，知道软件产品是否达到了相应的质量标准，是否遵循相应的标准和规程，发现软件系统中哪些地方有质量问题，便于改进方法和措施，提高软件产品的质量。
因此，在软件过程中，软件质量保证一般要完成以下的活动。
- 了解软件产品的质量，如通过软件测试发现软件系统的缺陷和故障。
- 撰写和提交软件质量报告，如撰写软件测试报告来说明软件系统中的故障和缺陷。
- 为项目组和管理层服务，告诉他们软件系统所存在的问题，便于改进管理和技术手段。
软件质量保证应从以下三个方面关注软件系统的质量。
- 软件开发活动
软件项目组应对软件过程即各种软件开发活动的质量进行保证，如需求分析、软件设计、编码等等，审查这些软件开发活动的实施，并产生审查报告。比如审查软件过程是否遗漏了某些软件开发活动（如评审）、软件开发活动是否遵循某些要求。
- 软件产品
软件项目组要对软件开发结果（即各种软件产品）的质量进行保证。对于文档类的软件产品（如软件需求规格说明书、软件设计规格说明书等）而言，应对它们进行审核并产生审核报告；对于代码类的软件产品（如源程序代码和可执行代码）而言，应对它们进行测试以产生测试报告。
- 标准和规程
为了规范软件产品和软件开发活动、确保其质量，软件项目组应在软件项目开始之时制定相应的标准和规程（如软件过程、软件需求规格规格说明书的编写规范），以指导软件项目的实施。
为了进行软件质量保证，软件项目组在项目实施之时应成立软件质量保证小组（即SQA小组），软件质量保证小组负责制定软件质量保证计划，并按照质量保证计划执行各种软件质量保证活动（如审查、审核、测试等），从而获得软件系统的质量可视性。比如，在软件产品完成之后对它进行审核、在软件开发活动实施过程中对软件开发活动进行审查等。一般地，软件质量保证小组应独立于软件项目开发小组，如需求分析小组、软件设计小组等，拥有较大的权限以便及时向管理层反馈有关软件质量方面的信息。图 41描述了软件质量保证过程。
图 41. 软件质量保证过程
具体的，软件质量保证小组在整个软件过程中应参与以下一组软件质量保证活动。
n 制定质量保证计划
在项目实施之初，质量保证小组应负责制定和撰写质量保证计划，并组织相关人员（如开发人员、测试人员等）对质量保证计划进行评审。
n 制定标准和规程
在开发组织内部或软件项目组内部，软件质量保证小组需要参与制定相关的软件开发标准和规程，以限制和约束软件开发活动，以便得到规范化的软件产品，从而确保软件过程和产品的质量。典型的标准和规程包括：
- 软件过程规程
- 需求管理规程
- 软件需求规格说明书编写规范
- C++编码规范
- Java编码规范等等
n 审查软件开发活动
软件质量保证小组应审查每个软件开发活动是否遵循软件过程规范，包括：
- 每个软件开发活动的输入条件是否都得到满足
- 软件开发活动的执行是否遵循规范
- 每个软件开发活动的输出是否都已经产生
- 软件过程中所定义的各个软件开发活动是否都得到了执行，是否有遗留
- 项目组所执行的每个软件开发活动是否都有意义且在软件过程规程中均有定义等。
n 审核软件工作产品
软件质量保证小组应对软件过程中所生成的各个文档类软件工作产品（如软件需求规格说明书、软件设计规格说明书等）进行审核，判断它们是否：
- 遵循规范和标准，如软件需求规格说明书是否按照软件需求规格说明书编写规范来撰写的
- 正确的
- 一致的
- 准确的
- 可追踪性的
n 测试源程序代码
软件质量保证小组应和软件测试小组一起对软件过程中生成的各种代码类的软件产品进行测试，以发现软件系统中的缺陷，包括：
- 单元测试
- 集成测试
- 确认测试
- 系统测试
n 记录开发活动和软件产品的偏差
软件质量保证小组应记录审查、审核和测试过程中发现的问题，对它们进行分析，并形成软件质量报告。
n 报告高级管理者和相关人员
软件质量保证小组应将软件质量报告提交给管理层和其它相关人员，从而为管理者和相关人员了解软件系统的质量提供可视性。
8.3 软件质量保证计划
为了确保在软件开发过程中有计划、有组织地开展软件质量保证活动，在软件项目实施之初软件质量保证小组需要制定相应的软件质量保证计划。该计划详细描述了与软件项目有关的质量标准和规程，定义了参与质量保证活动的人员和角色，明确软件质量保证活动的策略和步骤等等。下面描述了一个典型软件质量保证计划的模板。
9 软件配置管理
软件项目负责人小王所带领的项目组在软件开发过程中产生大量的软件产品，包括需求分析阶段撰写的软件需求规格说明书，软件设计阶段形成的软件设计规格说明书，以及在编码阶段所产生的程序代码。软件项目组在组织和管理这些软件产品方面感到繁琐、费力和困难。到了编码阶段的后期，用户提出了需求变更的请求。软件项目组根据用户的变更需求修改了软件需求规格说明书，并将更改后的软件需求规格说明书交给了软件设计小组，设计小组以此为基础更改了软件设计，产生了一个新版本的软件设计规格说明书。更改后的软件设计对诸多软件模块和数据设计进行了变动，为此导致许多模块、源程序代码和可执行代码发生了变化。由于变化的范围太大，软件项目组已经很难清晰地掌握和控制哪些软件产品没有发生变化，哪些软件产品发生了变化以及做了什么样的变化。
由此带来新的问题是，软件项目组未能及时将这些变化通知给相关、受影响的小组和人员，从而出现软件产品之间的不一致（如详细设计与程序代码不一致），所开发的软件产品未能完全符合和满足用户的需求。对于软件系统中的某些模块而言情况更为糟糕，软件开发人员已经对这些模块进行了多达六七次的修改，而且每次修改都有意义，从而产生了不同版本的软件模块。由于缺乏有效的管理措施，软件开发人员已经很难清晰和有效地识别、区分这些软件模块。这种状况导致了软件项目组在组装目标软件系统时，不知道应将哪些产品组装在一起，从而得到满足用户需求的软件系统。
上述案例提示我们：软件项目的开发会产生大量的软件产品（包括文档、代码和数据等），这些产品之间存在不同形式的关系；对于同一软件产品，可能需要对它进行多次变更从而产生多个不同的版本。软件项目组必须清晰的知道软件开发过程中会产生哪些产品、这些产品会有哪些不同的形式和版本，这就需要对这些软件产品进行配置管理。
9.1 基本概念
软件配置管理是指在软件生命周期中对软件产品采取以下一系列活动的过程。
- 控制软件产品的标识、存储、更动和发放。
- 记录、报告软件产品的状态。
- 验证软件产品的正确性和一致性。
- 对上述工作进行审计。
软件配置管理有助于唯一和清晰地标识各个软件产品；有效地控制软件产品的变更；确保变更得以实现；及时地向相关人员汇报软件产品的变更；以及确保软件产品的一致性、完整性和可追踪性。
1. 软件配置项
在软件配置管理中，通常将那些在软件生命周期内产生的、需进行配置管理的工作产品称为软件配置项（Software Configuration Item，SCI），它可以是各种形式的文档、程序、数据、标准和规约。
- 技术文档：如软件需求规格说明书、软件概要设计规格说明书、软件详细设计规格说明书、软件数据设计规格说明书、软件测试计划、用户手册等等。
- 管理文档：如软件项目计划、软件配置管理计划、软件质量保证计划、软件风险管理计划等等。
- 程序代码（源和可执行代码）：如模块a的源程序代码a.java、模块a的可执行代码a.class、组件、可执行文件等等
- 数据：如配置文件、数据文件等等。
- 标准和规约：如软件过程规程、需求管理规程、软件需求规格说明书编写规范、C++编码规范、Java编码规范等等。
图 39. 软件配置项及其相关性示意图
图 39描述了常见的软件配置项以及它们之间的相关性。软件配置项间的相关性有助于发现软件配置项变更的影响范围。比如，如果软件需求规格说明书发生了变更，那么软件概要设计规格说明书以及软件数据设计规格说明书都将可能受到影响。
对于每一个软件配置项，软件配置管理需要对它做详细的描述，包括：
- 唯一的命名和编号
- 属性，如版本、类型等
- 关系描述，说明该软件配置项与其它软件配置项之间的相关性
2. 基线
“变”在软件开发过程中不可避免。客户希望通过“变”来不断调整和完善其需求，软件开发人员希望通过“变”来不断调整和完善其技术解决方案。但是，频繁的“变”将使得软件项目的实现和管理变得更加复杂和难以控制。比如，需求分析的“变”将引来一系列软件配置管理项的“变”，过多的“变”将可能导致软件开发人员难以区分不同软件配置项之间的差异。因此，软件项目的开发希望在支持一定程度“变”的基础上稳定地推进项目。为了解决这一矛盾，软件配置管理引入了基线（Baseline）的概念。
所谓基线是指已经通过正式复审和批准的软件产品、标准或规约，它们可以作为进一步软件开发的基础，并且只能通过正式的变化控制过程才允许对它们进行变更。比如软件需求规格说明书经过评审后，发现的问题已经得到纠正，用户和软件项目组双方均已认可，并且得到正式批准，那么该软件需求规格说明书就可作为基线。
图 40. 作为基线的软件配置项和基线库
图 40描述了作为基线的软件配置项和基线库。软件开发活动所产生的软件配置项一旦通过了正式的评审和批准，意味着该软件配置项的正确性和完整性等得到了大家的认可，可以作为项目后续软件开发的基础，在此情况下就可将软件配置项作为基线纳入基线库中。基线库是一个或者多个基线的集合。对处于基线库中的任何软件配置项进行修改和变更将受到严格的控制。比如，如果软件项目组要对经过评审和批准的软件需求规格说明书进行修改，那么它必须提出申请，经过正式的软件配置管理控制之后，才能提取出该软件需求规格说明书并对它进行工程活动。软件开发过程中典型的基线包括：经过评审和批准后的软件需求规格说明书、经过评审和批准后的软件设计规格说明书、经过评审和批准后的软件项目计划、经过评审和批准后的软件测试计划、经过评审和批准后的软件质量保证计划、经过评审和批准后的配置管理计划、经过测试后的源程序代码、经过测试后的可运行目标软件系统等等。
软件配置项经过了评审和批准标志着该软件配置项所对应的软件开发阶段的结束，也意味着以该阶段软件产品为基础的下一阶段软件开发活动的开始。比如，如果软件需求规格说明书通过了正式的评审并被批准，那么需求分析阶段的工作已经完成，下一阶段即软件设计可以基于软件需求规格说明书基线开始实施。
在软件过程中引入基线可以有效地控制对软件配置项的变更，确保软件产品保持一定程度的稳定性，具体表现在：
- 纳入基线的软件配置项是通过正式评审和批准的，得到广泛项目组成员和用户的广泛认可，因此可以作为软件进一步开发的基础和依据
- 不允许对基线进行随意、非正式的更改，确保基线相对稳定
- 如果确实需要对基线进行更改，那么需要对该更改进行正式和严格的评估和认可
9.2 软件配置管理过程
在软件项目实施过程中，软件配置管理需要解决以下一系列问题。
- 如何标识软件配置项、管理软件配置项的诸多版本？
- 如何在软件发布给用户之前和之后控制变化？
- 谁负责批准变化，并确定其优先级？
- 如何保证变化被恰当地进行？
- 采用何种机制告知有关人员已经实施了变化？
针对上述问题，软件配置管理大致需要完成以下的任务和活动。
- 软件配置项的标识，包括软件配置项的识别，明确软件项目有哪些软件配置项；软件配置项的描述，明确每个软件配置项的内容。
- 版本控制，明确每个软件配置项有哪些版本以及这些版本的演化关系。
- 变化控制，如何应对软件配置项的各种变化。
- 配置审计，报告软件配置项的状态。
为了支持上述软件配置管理活动，一般地软件项目应成立软件配置管理小组。软件配置小组的成员可由软件项目组成员担任。在软件配置管理过程中，软件配置管理小组大体上承担以下两方面的职责：负责制定软件配置管理计划和实施软件配置活动。
1. 软件配置项的标识
软件开发过程会产生大量的软件配置项。为了管理和控制这些软件配置项，必须对它们进行标识。软件配置项标识主要有两方面的任务：识别软件系统中有哪些软件配置项以及详细描述每个软件配置项。
对软件配置项的识别应是完整和系统的，不要有遗漏，包括所有的相关文档、程序、数据、标准和规程等。对软件配置项的描述包括两方面内容：（1）为每个软件配置项生成一个唯一和直观的标识；（2）对软件配置项的属性进行详细的描述。
软件配置项的标识应直觉意思明确，便于望文生义，有利于对该软件配置管理项进行控制和管理。图 41描述了软件配置管理项的标识方法。一个软件配置项的标识由五个部分组成：项目名、软件配置项类型、软件配置项的名称、版本号和修订号。其中，软件配置项类型描述了该软件配置项是文档、程序、数据还是标准和规程。例如，WIC.DOC.SRS.1.01标识了“WIC”项目下的一个文档类的软件配置项，它是一个软件需求规格说明书“SRS”，其版本号是“1”，修订号是“01”。
图 41. 软件配置项标识示意模板
对软件配置项属性的描述主要包括以下内容：软件配置项的创建者、创建时间、修改者、发布时间、评审者、所依赖的其它软件配置项等等。为了便于在更动控制时对软件配置项的影响域进行评估，可以用表 26所示的关联矩阵来表示不同软件配置项之间的关系。在该表中，软件需求规格说明书与软件概要设计规格说明书、数据设计规格说明书、详细设计规格说明书相关联。因此，当软件需求规格说明书发生变更时，相应的软件概要设计规格说明书、数据设计规格说明书、详细设计规格说明书也要跟着发生变化。
表 26. 描述不同软件配置项之间关系的关联矩阵
|
| 软件需求规格说明书 | 软件概要设计规格说明书 | 数据设计规格说明书 | 详细设计规格说明书 |
| 软件需求规格说明书 |
| Ö | Ö | Ö |
| 软件概要设计规格说明书 | Ö |
|
| Ö |
| 数据设计规格说明书 | Ö |
|
| Ö |
| 详细设计规格说明书 | Ö | Ö | Ö |
|
2. 版本控制
在软件开发过程中，由于以下原因同一个软件配置项可能会有多个不同的版本。
- 软件因纠错/改进/完善/扩充会导致同一软件配置项有多个版本。比如，在需求分析阶段的任务完成之后，需求分析小组形成了关于软件需求规格说明书的一个版本。在后续的软件过程中，由于用户需求的变化，需求分析小组对原先的软件需求规格说明书进行了修改，产生了一个新版本的软件需求规格说明书。
- 在同时从事多个软件项目开发时，同一个软件配置项可能需要多个不同的版本，分别应用于不同的软件项目。比如，软件项目组开发了一个通用的构件draw.dll用于支持用图形化的方式显示统计信息。为了支持多个不同项目的特殊要求，构件draw.dll产生了多个不同的版本。
因此，软件配置管理应提供手段来区分和描述软件配置项的各个不同版本，以及这些版本之间的关系和演化，确保软件开发人员能够以一种正确、一致和可重复的方式恢复和构造任意最终的软件产品版本。
可采用版本树来表示软件配置项的版本演化（见图 42）。图中的节点表示各个版本的软件配置项，边表示软件配置项不同版本之间的依赖和演化关系。比如节点“SCI 1.1”表示版本为1.1的软件配置项，连接“SCI 1.1”和“SCI 1.2”之间的边表示软件配置项“1.2”版本是由“1.1”版本演化而来。
图 42. 软件配置项的版本树
3. 变更控制
在软件开发过程中变化不可避免（如用户对需求的变更、设计人员对技术解决方案的变更等等），但是无控制的变化将导致混乱。因此，软件配置管理必须对软件配置项的任何变更进行控制。变更控制要求对进入基线的软件配置项进行变更均应履行正规的更动手续，并遵循以下的过程（见图 43）。
图 43. 变更控制过程
- 步骤1. 提出书面变更申请
欲对软件配置项进行变更的人员（如用户、软件开发人员等）首先要提出一个书面的变更申请。该申请应详细描述变更的原因、变更的内容、对应的软件配置项、受影响的范围等方面的内容。
- 步骤2. 评估变更申请
软件开发人员和软件配置管理小组要对变更申请进行评估。比如软件开发人员要评估该变更是否有必要，对软件项目的影响是否在可控的范围之内等等。软件配置管理小组要评估受影响的软件配置项是否允许对它进行变更。对变更申请的评估结果有两种。一种是不同意，那么该次变更过程到此结束；另一种是同意，执行实际的变更程序。
- 步骤3. 提取软件配置项
变更人员从软件配置小组处提取待变更的软件配置项。
- 步骤4. 修改软件配置项
变更人员对提取的软件配置项实施软件工程活动（如需求分析、软件设计等），得到经修改后的软件配置项。
- 步骤5. 质量保证
必须对软件配置项进行变更的软件工程活动以及经修改后所产生的软件配置项进行质量保证。比如对软件工程活动进行审查、对软件开发文档进行评审、对程序代码进行测试等等，确保变更后所得到的软件配置项符合质量要求。
- 步骤6. 纳入基线
如果变更后的软件配置项经过了正式的评审和审核，并且得到了批准，那么可将该软件配置项纳入基线。
4. 软件配置审计
软件配置审计主要包括以下几个方面的内容：
- 检查配置控制手续是否齐全。
- 变化是否完成。
- 验证当前基线对前一基线的可追踪性。
- 确认各软件配置项是否正确反映需求。
- 确保软件配置项及其介质的有效性。
- 对软件配置项定期进行复制、备份、归档，以防止意外的介质破坏。
配置审计的结果应写成报告，并通报给有关人员。此外，软件配置审计不应局限于在基线处或更动控制时进行，而应在软件开发过程中，如有必要随时实施软件配置审计。
5. 状态报告
为了及时追踪软件配置项的变化以备审计时使用，软件配置管理人员需要在软件开发过程中对每个软件配置项的变化进行系统的记录，包括：
- 发生了什么事。
- 谁做的事。
- 此事什么时候发生。
- 对其它产生什么影响。
根据软件配置项的出入库情况和更动控制组的会议记录，产生配置状态报告，并将状态报告及时发放给各有关人员和组织，以避免造成互相矛盾和冲突。通常有以下两种形式的软件配置报告，包括：现行状态报告和历史状态报告。现行状态报告提供了指定软件配置项的现行状态，指明现行版本号、目前是否正被某人专用还是可共享等方面的信息。历史情况报告提供了指定软件配置项的历史记录，描述谁于何时因何故对何软件配置项做了何事（入库/出库/更动）。配置状态报告也被存放在受控库中，可供有关人员随时查询。
目前有许多CASE工具支持软件配置管理工作，帮助软件项目开发人员和配置管理小组完成上述软件配置管理任务。典型的软件工具包括：Microsoft的SourceSafe、IBM的ClearCase等等。
9.3 软件配置管理计划
为了更好地指导软件配置管理工作，一般地在软件项目实施前软件配置管理小组应制定详细和明确的软件配置管理计划，它主要包括以下几个方面内容（见图 44）。
图 44. 配置管理计划模板
