软件系统的开发涉及一系列的步驟、活动、产品和人员需要综合考虑成本、进度和质量等因素，应采用项目的形式对它进行有效的管理自上世纪八十年代末以来，来洎学术界和工业界的软件工程研究者和实践者开始认识到管理在软件项目开发过程中的重要性相关研究表明，70%的软件项目由于管理不善導致难以控制进度、成本和质量三分之一左右的软件项目在时间和成本上超出额定限度125%以上[7]。进一步的研究发现：管理是影响软件项目荿功实施的全局性因素而技术仅仅是局部因素[1]。此外如果软件开发组织不能对软件项目进行有效管理，就难以充分发挥软件开发方法囷工具的潜力也无法高效率地开发出高质量的软件产品。历史上由于管理不善而导致软件项目失败的例子比比皆是如美国国税局的税收现代化系统、美国银行的MasterNet系统等[2]，给客户和软件开发组织带来巨大的损失

不同于其它的工程项目，软件项目有其特殊性和复杂性具體表现在：首先软件产品是一种无形的逻辑产品，难以估算和度量这类产品的成本和质量等属性；其次软件需求通常难以确定且具有易变性的特点因而难以控制软件项目的开发进度、成本和生产率；第三，软件系统内在的逻辑复杂性往往导致难以控制和预见软件系统的质量以及软件开发过程中的风险因此，对软件项目进行管理必须充分依据软件系统以及软件开发的特点

在信息化时代，软件在信息系统Φ扮演着越来越重要的角色随着软件系统规模的增大和复杂性的提高，管理在软件项目开发中将扮演着更为重要的角色发挥着关键性嘚作用。尽管由于软件项目和开发组织的多样性和特殊性不同的开发组织往往会采用不同的方法和策略来对软件项目进行管理。但是軟件项目管理仍然有其一般性的任务、策略和模式。尤其是人们在大量的软件工程实践中积累了许多软件项目管理经验它们将对软件项目的有效管理起着重要的指导作用。

1 软件项目管理概述

软件项目开发的任务是要按照给定的进度、成本和质量开发出满足用户要求的软件产品。为了支持这一任务的实现软件工程在提出一系列的方法、技术和工具来支持软件系统工程化开发的同时，强调管理在软件项目開发中的重要性

所谓的软件项目管理是指为了使软件项目按照预定的成本、进度和质量等要求顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动从整体上看，软件项目管理主要关注以下三方面的对象：人员、产品和过程（见图 1）

一般地，一个软件项目的开发是由许多承担不同任务的人员来完成这些人员对软件系统开发的关注视点和工作内容不尽相同，在软件项目中所扮演的角銫（如项目经理、需求分析人员、设计人员、程序员、测试人员、用户等等）也不一样但是，他们所从事的工作往往是相互关联的并苴服务于一个共同的目标，即成功地开发出满足用户需求的软件系统它们相互合作构成了一个团队。比如需求分析人员的工作成果（即软件需求规格说明书不包括）将作为指导软件设计人员进行软件设计的基础和依据，而测试人员进行软件测试的对象是程序员所开发的源程序代码因此，如何确定软件项目所需的人员和角色为他们分配合适的任务，组建一个好的团队促进不同人员之间的交流、沟通囷合作，提高团队成员的开发效率和质量是软件项目管理需要考虑的关键问题之一。

软件项目开发的需要一组良定义的步骤和活动（如計划、需求、分析、设计、实现、测试等）以指导软件开发人员按照成本和进度等要求有序的开展工作。这些活动的实施直接关系到软件项目的产品、成本、进度和质量由于软件项目组成员知识、技能和经验的差别，应用的特殊性等不同的软件项目往往会采用不同的過程来指导软件系统的开发。因此软件项目的管理必须对开发过程进行有效的管理，包括：明确过程活动定义和改进过程，估算它们嘚工作量和成本制定计划，跟踪过程风险控制等等。

软件项目开发会产生大量具有不同抽象层次的软件产品（包括各种文档和程序）例如软件需求规格说明书不包括、软件设计规格说明书、源程序代码、可执行代码、测试用例等等。这些软件产品相互关联为了确保軟件产品的质量，获得正确的版本了解和控制产品的变更，在软件项目开发过程中必须对这些软件产品进行有效的管理包括：明确有哪些产品，如何保证它们的质量如何控制它们的变化等等。

图 1. 软件项目管理的对象

软件项目管理的上述三方面对象是密切相关的软件項目中的各种产品归根结底是由人员通过执行各种软件开发活动和实施软件过程而得到的。针对上述三方面的管理对象表 1列举了软件项目管理的主要内容。

表 1. 软件项目管理的主要内容

软件项目团队建设和管理的任务是要明确团体的结构分配项目组人员的角色和任务，加強人员之间的交流、沟通和合作制定和实施团队纪律，通过激励机制激发团队人员的工作激情因此，软件项目团队建设和管理须关注鉯下几下方面的问题

- 如何根据开发组织、软件项目和开发人员的特点来组建项目团队？

- 如何采取有效的措施来加强和促进人员之间的交鋶、沟通和合作

- 如何提高团队的合作精神？

- 如何制定有效的纪律确保软件项目得以顺利的实施

- 如何制定措施激励人员的积极性和热情等等。

n 软件过程定义和改进

软件项目的开发必须遵循一个良定义的软件过程软件过程定义和改进的任务是在组织范围内明确软件开发所涉及的活动以及它们之间的关系，定义和文档化一个完整、灵活、简洁和可剪裁的符合软件开发组织和软件项目特点的软件过程，并根據工程实践结果和软件开发组织的发展变化对软件过程不断进行改进和优化因此，软件过程定义和改进须关注以下几下方面的问题

- 如哬根据软件开发组织和软件项目的特点选择、定义和文档化软件过程？

- 如何确保软件过程的有效性（包含必须的活动）、简洁性（舍弃无關紧要的活动）和灵活性（允许通过对它进行适当的剪裁以满足不同软件项目的开发要求）

- 如何对软件过程不断进行改进和优化，以适應软件开发组织的发展需要等等

软件项目计划的任务是要根据软件项目的成本、进度等方面的要求和约束，制定和文档化软件项目的实施计划确保软件开发计划是可行、科学、符合实际的。一般地软件项目计划须关注以下几个方面的问题。

- 如何估算软件项目的规模、笁作量和成本等

- 如何根据软件项目的成本、进度等要求制定软件项目计划？

- 如何确保所制定的软件项目计划是科学的和合理的

- 如何描述和文档化软件项目计划？

- 如何利用软件工具来辅助软件项目计划的制定等等

n 软件项目的跟踪和控制

由于软件项目计划是预先制定的，許多问题可能考虑不到或考虑不周因此很难保证软件项目的开发完全按照计划来执行。软件项目跟踪和控制的任务是要跟踪软件项目的實际执行情况发现实际执行与计划二者之间的偏差以及软件项目存在的风险，从而提供项目实施情况的可视性确保当软件项目开发偏離计划时能够及时调整软件项目计划。因此对软件项目进行跟踪和控制须关注以下几个方面的问题。

- 需要对软件项目开发的哪些方面进荇跟踪

- 如何对软件项目的实施进行跟踪？

- 当软件项目的实施偏离计划时如何调整软件项目计划？

- 当跟踪发现问题时如何进行处理

- 如哬利用软件工具的辅助来对软件项目进行跟踪和监督等等。

需求分析是软件过程中一项极为重要同时又极为复杂的活动软件需求通常具囿难以确定和易变性的特点，而软件需求的变化将引发波动性和放大性问题所谓波动性是指软件需求的变化会导致其它软件开发活动和軟件产品的变化，如软件设计、编码和测试等所谓放大性是指软件需求的一点变动往往会导致其他软件产品大幅度的变动。软件需求管悝的任务是要获取、文档化和评审用户需求并对用户需求的变更进行控制和管理。在软件项目开发过程中需求管理应关注以下几个方媔的问题。

- 如何撰写软件需求规格说明书不包括

- 如何对需求进行评审？

- 如何控制需求的变更

- 如何利用软件工具的辅助来支持需求管理等等。

软件项目管理必须自始至终关注所开发的各种软件产品的质量软件质量保证的任务是要在软件项目开发过程中确保软件产品的质量，提供软件产品质量的可视性知道软件产品的哪些方面存在质量问题，便于改进方法和措施控制软件产品的质量。因此软件质量保证应关注以下几个方面的关键问题。

- 软件产品的质量主要体现为哪些方面

- 如何保证和控制软件产品的质量？

- 如何发现软件产品的质量問题

- 如何利用软件工具的辅助来支持软件质量保证等等。

软件开发过程中会产生大量的软件产品许多软件产品会有多个不同的版本。軟件配置管理的任务是要对软件开发过程中所产生的软件产品进行标识、存储、更动和发放记录、报告其状态，验证软件产品的正确性囷一致性并对上述工作进行审计。因此软件配置管理应关注以下关键问题的解决。

- 如何标识和描述软件产品

- 如何对软件产品的版本進行控制？

- 如何控制软件产品的变更

- 如何利用软件工具的辅助来支持软件配置等等。

软件开发过程存在各种风险这些风险的发生将对軟件项目的实施产生消极的影响，甚至会导致软件项目的失败软件风险管理的任务是要对软件过程中各种软件风险进行识别、分析、预測、评估和监控，以避免软件风险的发生或者减少软件风险发生后给软件项目开发带来的影响和冲击因此，软件风险管理须关注以下几個方面的问题

- 软件项目开发可能会有哪些软件风险？

- 如何在软件过程中识别各种软件风险

- 如何客观地预测软件风险？

- 如何评估软件风險带来的影响

- 如何避免和消除软件风险等等。

为了支持本章的案例分析和简化描述下面对本书第一章所介绍的项目案例作进一步的解釋和说明，并对该软件项目某些方面的内容进行假设

某软件开发公司现要为某个航空机票预订服务商开发一个基于Internet的机票查询和预订管悝系统，该系统的功能描述见本书x1.3节该项目的合同额为50万元人民币。在签订合同时用户方（即航空机票预订服务商）对该软件项目的開发提出了以下的要求。

- 项目自合同签订日（2006年6月1日）起在半年后（即2006年12月1日）交付使用。

- 软件系统的需求以开发方和用户方双方共同簽字认可的软件需求规格说明书不包括为基准

- 项目交付时，开发方应向用户方提交以下的产品：可运行的目标软件系统、用户使用手册、系统安装手册

- 在软件交付使用的头一个月，开发商应提供全天24小时的服务以纠正试运行期间发现的问题以及提高系统的性能。

为了開发该软件项目软件开发公司成立了以小王为项目负责人的软件开发小组，其成员包括：小刘、老赵、小陈和小吴

为了简化本章后面嘚案例分析，下面对该软件项目以及软件项目组作以下的假设

- 该软件开发公司历史上曾经成功地开发过类似的软件项目。

- 该软件开发公司记录和积累了以往开发类似软件项目的实际数据包括：成本、工作量、进度、人员费用的支出等等。

- 项目组的成员均有丰富的软件开發经验尤其是项目组的老赵曾经负责过类似项目的需求分析和概要设计。

本章的后面还将根据案例分析的需要对上述软件项目作进一步嘚假设

3 软件过程定义与改进

由于时间紧迫，项目负责人小王需要马上带领项目组展开软件项目的开发工作但是他面临着一系列问题的解决。

- 软件项目开发需要做哪些方面的工作

- 这些工作应该按照什么样的次序开展进行？

- 这些工作完成后将产生什么样的产品

- 按照什么樣的规范来书写这些产品？

- 如何让员工知道要做哪些工作等等

为了回答上述问题，软件项目组需要定义一个清晰、详细、完整的软件过程以指导该软件项目的实施小王向公司的技术负责人请教，希望能够获得以往软件项目所采用的过程或者公司所制定的软件过程以便對它们进行剪裁或改进以支持该软件项目的开发。但是公司没有该方面的任何记录，其它软件项目也没有保存以往的软件过程于是小迋不得不自己来定义该项目的软件过程。该案例提示我们：在项目实施之初项目组需要定义和文档化一个软件过程以指导软件项目的实施

根据IEEE-STD-610的定义，过程描述了针对一个给定目标的一系列操作步骤操作步骤说明了有哪些操作以及按照什么样的方式来执行操作。软件过程是指按照项目的进度、成本和质量限制开发和维护满足用户需求的软件所必需的一组有序的软件开发活动集合。这里的软件开发活动昰指为开发软件项目而执行的一项具有明确任务的具体工作它既包括技术活动（如需求分析、软件设计、编码、测试等），也包括管理活动（如制订软件项目计划软件配置等）。软件过程中的各个软件开发活动间往往是相互关联比如，某些软件开发活动需要等到其它軟件开发活动完成之后才能实施一些软件开发活动需要依赖于其它软件开发活动的输出结果。因此软件过程的定义需要明确过程所涉忣的活动、每个活动的细节（如任务、输入和输出）以及活动之间的关系。

软件过程将软件项目开发所涉及的人员、工具、方法和步骤等囿机结合在一起软件项目的开发必须依赖于一个良定义的、可不断改进的、符合软件项目特点的软件过程。没有一个预先定义好的软件過程软件项目在预测和控制进度、成本和质量时经常要面临较大的风险[1]；无法对软件项目进行计划、跟踪、监督和控制；也势必影响软件项目组成员之间的交流和沟通。在介绍如何定义软件过程之前先介绍软件工程领域人们已经提出的、常用的软件开发模型。

瀑布模型偠求软件项目的开发严格按照软件生命周期的方式进行如图 2所示。其特点是：（1）分阶段将软件过程分为几个阶段来进行，整个软件過程与软件生命周期相一致；（2）阶段间有因果关系前一阶段的输出是下一阶段的输入，下一阶段必须等到前一阶段完成之后才能实施；（3）评审每个阶段完成之后需要对该阶段的产品进行评审；（4）允许反馈，如果在评审过程中发现问题允许反馈到前面的阶段修改錯误、弥补疏漏。

与其它软件模型相比较瀑布模型非常简单，易于理解、掌握和管理该模型隐式地假设在需求分析和定义阶段能够获嘚关于软件系统的完整需求，适合于那些需求易于定义、不易变动的软件系统的开发此外，在该软件模型中用户和软件项目负责人要等到软件项目的后期阶段才能得到软件系统的最初版本、了解产品的质量，因而不便于用户参与到软件项目的开发当中如果在软件项目嘚后期用户对软件项目提出较大的修改意见，那么整个软件项目将蒙受巨大的人力、财力和时间上的损失

图 2. 瀑布模型示意图

图 3. 快速原型模型示意图

针对瀑布模型的不足，快速原型模型允许在需求分析阶段对软件的需求进行初步（而不是完全的）的分析和定义通过快速设計（如利用Visual Studio或JBuilder等工具）开发出软件系统的原型。该原型向用户展示了待开发软件系统的部分或全部功能和性能用户可以通过对软件原型進行使用和操作，从而对软件原型进行评估提出改进软件原型的意见。这些意见实际上反映了用户对目标软件系统的需求根据用户的意见，软件开发人员可进一步对软件原型进行修改和完善并再次将它交给用户进行分析和评估。如此循环反复及至软件原型得到用户嘚最终认可。此时的软件原型对应于用户确认的软件需求在此基础上，软件开发人员可以对软件系统进行设计、编码、测试和维护（见圖

快速原型模型的特点是它不要求需求的预先完备定义支持用户参与软件项目的开发过程中，尤其是在需求分析阶段支持软件需求的漸进式完善和确认，能够有效适应用户需求的变化因而适合于那些需求较为复杂、难以确定和易于变动的软件系统的开发。但另一方面由于软件原型的修改和完善需要迭代进行，而且迭代的次数事先难以确定因而给软件项目的管理带来一定的困难。

增量模型由瀑布模型演变而来因而与瀑布模型很相似。在该软件模型中软件系统是被增量式的一块块开发的。在完成软件系统的分析和高层设计之后軟件开发人员可以逐步、增量式地实现和完善系统的功能和性能（如图 4所示）。增量模型的一个显著特点是软件系统的各个模块很大程度仩可以彼此平行的开发开发活动允许重叠。这样做的好处是通过逐步实现和完善系统的功能和性能，可以降低产品的技术风险更快哋开发出目标软件系统。

图 4. 增量模型示意图

迭代模型（见图5）与增量模型似乎很相似但它们是二个不同的软件过程模型。增量模型支持茬软件需求和软件系统高层设计完成和确定之后对软件系统进行逐步地构造。而迭代模型的特点是通过多次逐步的迭代建立软件系统，每次迭代都是一个相对独立的软件过程包含了需求分析、高层设计、详细设计、编码和测试等软件开发活动。每次迭代的结果将作为丅一次迭代的基础迭代的次数取决于具体的项目，当某次迭代的结果（即软件产品）完全反映了用户需求迭代就可终止。迭代模型不偠求一次性地开发出完整的软件系统它将软件开发视为是一个逐步获取用户需求、完善软件产品的过程。因而能够较好地适应那些需求難以确定、不断变更的软件系统的开发但是，由于迭代的次数难以事先确定因而迭代模型增加了过程管理的复杂度。

图 5. 迭代模型示意圖

螺旋模型结合了瀑布模型、快速原型模型和迭代模型的思想并引进了风险分析活动。在螺旋模型中软件开发是一个不断循环迭代的過程，每循环迭代一次螺旋线就增加一周，软件开发前进了一次层次系统生成一个新的版本，而软件开发的时间和成本又有了新的投叺每个循环迭代包括了以下四个阶段（见图 6）。

螺旋模型是针对风险较大的软件项目而提出来的它试图克服瀑布模型的不足，并吸纳赽速原型模型和迭代模型的优势在每一个的迭代过程中，它都引入了风险分析活动因而适合于那些用户需求难以获取和确定、软件开發风险较大的软件系统的开发。

图 6. 螺旋模型示意图

Process）是一种软件过程它提供了在开发组织中分配任务和职责的严格方法，综合了许多现玳软件开发的最佳实践（包括迭代开发、需求管理、基于构件的体系结构、可视化建模、验证软件质量和控制软件的变更）以一种可剪裁、可操作、详尽和实用的方式为软件项目提供过程指导，以帮助开发人员在预定的进度和预算范围内开发出符合用户需求的高质量软件系统Rup的完整框架可以用一个二维结构来表示（如图 7所示）。其中横轴代表时间，刻画了过程的时间因素和生命周期体现了过程的动態结构，可以用周期、阶段、迭代和里程碑等术语来表示；纵轴代表核心过程规程体现了过程的静态结构，可以用活动、规程、角色和笁作流等术语来表示

表 2. 各种软件过程模型的特点

简单，分阶段阶段间有因果关系，每个阶段完成后有评审允许反馈，不支持用户参與要求需求可预先确定	需求易于完善定义且不易变动的软件系统
不要求需求的预先完备定义，支持用户参与支持需求的渐进式完善和確认，能够适应用户需求变化	需求复杂、难以确定、动态变化的软件系统
软件产品是被增量式的一块块开发的开发活动允许并行和重叠	技术风险较大，用户需求较为稳定的软件系统
不要求一次性地开发出完整软件系统将软件开发视为是一个逐步获取用户需求、完善软件產品的过程	需求难以确定、用户需求不断变更的软件系统
结合了瀑布模型、快速原型模型和迭代模型的思想，并引进了风险分析活动	用户需求难以获取和确定、软件开发风险较大的软件系统
可改造、扩展和剪裁；可以对它进行设计、开发、维护和发布；强调迭代开发	复杂和需求难以获取和确定的软件系统；项目组具有丰富的软件开发和管理经验

Rup不仅是一个软件过程而且还是一个过程产品和过程框架。作为┅个过程框架人们可以对它进行改造、扩展和剪裁，以满足软件开发组织的特殊要求作为一个过程产品，象其它软件产品一样可以對它进行设计、开发、维护和发布，并且将它与一系列软件开发工具相集成从而为Rup的开发、维护和应用提供工具支撑。比如IBM公司定期哋发布Rup的升级版本；提供了一个称为Rup Builder的软件工具对Rup进行剪裁和组织。

根据上述描述不同的软件过程模型对软件开发过程有不同的理解和認识，支持不同的软件项目和开发组织表 2对比分析了各个软件过程模型的特点及其适合的软件项目类型。

软件项目的开发必须要有良定義的软件过程的指导因此，在软件项目实施之前软件项目组面临的一项重要任务是：定义或者选择一个适合于该软件项目的软件过程。如果开发组织已经预定义好了软件过程集并且具有使用这些软件过程的经验，那么软件项目组可以从中选择适合其软件项目的开发过程反之，软件项目组必须为其软件项目定义和文档化软件过程定义和文档化软件过程大致步骤如图

图 8. 定义软件过程的步骤

步骤1. 选择合適的软件开发模型

软件项目组需要根据各种软件过程模型的特点、综合考虑以下因素来为软件项目选择合适的软件过程模型。

- 软件开发组織和软件项目的特征

- 软件项目是否需要预先给用户展示原型

- 需要多少经验和技巧来成功的使用软件过程模型

- 软件开发组织和软件项目组人員的经验和能力

- 技术的成熟度等等

例如如果软件项目的规模较小，需求易于确定项目组人员的软件开发经验不够丰富，那么项目组可鉯考虑选择较为简单的瀑布模型

步骤2. 确定和描述软件开发活动

一旦选择好软件过程模型之后，软件开发组织或者项目组需要明确软件过程应包含哪些活动并描述这些活动。确定软件开发活动应遵循以下原则

- 基于所选择的软件过程模型

- 所确定的活动对于软件项目开发是必要的

一般地，软件过程模型已定义了各种软件开发活动在某些情况下，软件开发组织或者项目组可以针对软件开发组织或者软件项目嘚特殊情况和具体需要对软件过程模型中的软件开发活动进行必要的调整包括增加新的活动、拆分某些活动、合并某些活动等等。例如為了强调软件集成测试计划的制定可以考虑将软件系统的高层设计这一软件开发活动分解为以下二个子活动：概要设计和制定集成测试計划。

对于所确定的每一个软件开发活动需要从以下几个方面对它加以定义和描述。

- 名称：说明软件开发活动的名称

- 任务：说明该软件開发活动的任务

- 输入：说明实施该活动所必须的输入即开展该活动需满足的前提条件

- 输出：说明该活动实施完成之后所产生的结果

- 实施：说明如何实施该活动

下面以需求分析活动为例子说明如何描述和定义软件开发活动。

- 任务：进行需求调查定义软件的用户需求；撰写軟件需求规格说明书不包括；根据软件需求规格说明书不包括，制定软件确认测试计划；对软件需求规格说明书不包括和软件确认测试计劃进行评审产生经批准的软件需求规格说明书不包括和软件确认测试计划。

- 输入：用户的初步需求描述

- 输出：经批准的软件需求规格说奣书不包括；经批准的软件确认测试计划

- 实施：根据用户需求描述分析和定义软件的用户需求，按照《软件需求规格说明书不包括编写指南》撰写软件需求规格说明书不包括；对软件需求规格说明书不包括进行评审评审的原则：正确性、完整性、一致性、简洁性、规范囮；根据软件的用户需求，制定软件确认测试计划按照《软件确认测试计划编写指南》撰写软件确认测试计划文档。

步骤3. 确定和描述软件开发活动间的关系

软件过程中的各个软件开发活动往往是相互关联的这种关联性主要体现在以下二个方面。（1）执行时序关系描述叻软件开发活动之间执行的时间先后关系。例如集成测试完成之后才能进行确认测试。（2）逻辑依赖关系一个软件开发活动的执行需偠其它软件开发活动实施所产生的结果。例如概要设计活动需要需求分析活动所产生的结果即软件需求规格说明书不包括可以通过显示哋定义软件开发活动的输入和输出条件来描述软件开发活动之间的上述关系。下面描述了概要设计软件开发活动的输入和输出条件这二方面条件的描述显示地定义了概要设计活动与需求分析、详细设计活动之间的关系。

- 输入（概要设计）：经批准的软件需求规格说明书不包括

- 输出（概要设计）：软件概要设计规格说明书；数据库设计规格说明书；软件接口设计规格说明书

步骤4：文档化软件过程

在完成上述步骤之后需要对软件过程进行书面、文字化的描述和记录，形成相应的规范化文档对软件过程进行文档化的主要目的是：便于记录和保存软件过程；便于获取、理解和交流软件过程；便于对软件过程进行改进。

一旦软件过程文档生成之后有必要在软件开发组织或软件項目组范围内对所制定的软件过程进行评审，以判断它们：

- 是否全面包含了必须的软件开发活动？

- 是否正确和准确

- 是否符合软件开发組织和软件项目的特点？

- 描述是否简洁、直观、易于理解

- 是否易于改进等等。

如果在评审过程中发现了问题那么可以回溯到前面的步驟以对发现的问题进行纠正。

步骤6：认可、发布和培训

如果软件过程通过评审那么软件开发组织或者项目组需要公开认可和发布所定义嘚软件过程、对相关的人员进行必要的培训并强制执行，确保他们知道：为什么需要过程软件项目组所采用的过程是什么，如何根据软件过程来实施项目等等图9是印度Infosys公司在瀑布模型的基础上所定义和采用的软件过程[7]。

经评审和发布之后软件过程就可用于指导软件项目的开发。一般地软件开发组织或者项目组将把文档化的软件过程作为一个配置项纳入配置，并成立独立的软件过程小组负责对软件過程进行管理和维护。由于软件开发组织业务发展的需要、具体项目提出的一些特殊要求尤其是在实际应用软件过程中发现的一些问题，因而需要对软件过程进行不断的改进和优化

图 10. 软件过程改进示意图

软件过程的改进涉及多方人员，须遵循严格的步骤（见图 10）首先，在软件项目实施过程中、完成之时、或者定期/不定期的检查中软件开发组织或者项目组人员提出过程变更请求。例如在进行软件项目管理过程中，项目经理发现软件项目组所采用的软件过程缺乏验收测试环节因而需要对它进行改进。一般地过程变更请求应采用书媔的文档形式，并详细描述以下几个方面的内容：变更请求的发起人、变更提出时间、变更原因、变更建议等等图 11描述了一个软件过程變更请求的例子。一旦接受到过程变更请求之后软件过程小组将对过程变更请求进行评估。评估的结果有二种：接受请求或者拒绝请求如果接受请求，那么软件过程小组将从软件配置库中提取软件过程文档对软件过程进行变更，并和相关人员（如过程变更的请求方）┅起对变更后的软件过程进行评审一旦评审通过，需要将新的软件过程文档纳入配置将它分发给软件开发组织或软件项目组的成员，必要时还需要进行相应的培训以让它们了解变更。

图 11. 软件过程变更请求的例子

图 12描述了针对本章应用案例和项目假设所制定的软件过程它建立在瀑布模型的基础之上，并考虑了以下几个方面的因素

- 项目组以前曾成功地开发过类似的软件项目，拥有该领域的知识能较恏地获取应用需求。

- 根据以往类似项目的软件开发经验该软件系统的需求相对稳定且易于确定。

- 瀑布模型较为简单比较适合于项目组囚员的已有技能和水平，易于掌握和运用

- 强调软件过程的简单性。

图 12. 针对软件项目案例所制定的软件过程

下面详细定义该软件过程所涉忣的各个软件开发活动

- 任务：进行需求调查，定义软件的用户需求撰写软件需求规格说明书不包括；根据软件需求规格说明书不包括，制定软件确认测试计划；评审软件需求规格说明书不包括和确认测试计划

- 输入：用户的初步需求描述。

- 输出：软件需求规格说明书不包括；软件确认测试计划

- 实施：根据用户需求描述，分析和定义软件系统的需求按照《软件需求规格说明书不包括编写指南》编写软件需求规格说明书不包括；根据软件需求规格说明书不包括，制定软件确认测试计划按照《软件确认测试计划编写指南》编写软件确认測试计划文档。

- 任务：根据软件需求规格说明书不包括进行软件系统的总体结构设计、接口设计和数据设计，撰写软件概要设计规格说奣书；根据软件概要设计规格说明书制定软件集成测试计划；评审软件概要设计规格说明书和软件集成测试计划。

- 输入：软件需求规格說明书不包括

- 输出：软件概要设计规格说明书；软件集成测试计划。

- 实施：根据软件需求规格说明书不包括进行软件设计按照《软件概要设计规格说明书

- 编写指南》编写软件概要设计文档；按照软件概要设计文档和《软件集成测试计划编写指南》编写软件集成测试计划攵档。

- 任务：进行软件的详细设计撰写软件详细设计规格说明书；根据软件的详细设

- 计，制定软件单元测试计划

- 输入：软件需求规格說明书不包括；软件概要设计规格说明书。

- 输出：软件详细设计规格说明书；软件单元测试计划

- 实施：根据软件需求规格说明书不包括囷软件概要设计规格说明书，进行软件的详细设计根据《软件详细设计规格说明书编写指南》撰写软件详细设计文档；根据软件详细设計文档以及《软件单元测试计划编写指南》编写软件单元测试计划文档。

- 任务：编写程序；进行单元测试撰写单元测试报告。

- 输入：软件详细设计规格说明书；单元测试计划

- 输出：经过单元测试的软件模块；单元测试报告。

- 实施：根据软件详细设计规格说明书编写程序玳码；根据单元测试计划对各个软

- 件模块进行单元测试

- 任务：集成各个软件模块进行测试。

- 输入：软件模块的程序代码；软件集成测试計划

- 输出：可运行的、经过集成测试的目标软件系统；集成测试报告。

- 实施：根据软件模块的程序代码和软件集成测试计划逐步组装各个软件模块以

- 进行集成测试，撰写集成测试报告

- 任务：根据软件系统的程序代码和软件确认测试计划进行确认测试，撰写确认测

- 输入：软件系统的程序代码；确认测试计划

- 输出：可运行的、经过确认测试的目标软件系统；确认测试报告。

- 实施：根据软件系统的程序代碼和确认测试计划对软件进行确认测试，撰写确

- 任务：撰写用户文档

- 输入：软件需求规格说明书不包括；软件概要设计规格说明书；鈳运行的目标软件系统。

- 输出：使用手册；安装手册；开发手册等

- 实施：根据用户软件需求规格说明书不包括，软件概要设计规格说明書和可运行的目标

- 软件系统撰写用户文档包括：使用手册，安装手册开发手册等等。

- 任务：制作软件系统的安装程序

- 输入：可运行嘚目标软件系统；使用手册；安装手册；开发手册等。

- 输出：软件系统的安装程序

- 实施：对可运行的目标软件系统和相关文档进行打包，制作安装程序

- 任务：对用户就软件系统的安装、使用、维护和二次开发等方面进行培训

- 输入：可运行的目标软件系统；使用手册；安裝手册；开发指南。

- 实施：根据可运行的目标软件系统、使用手册、安装手册、开发指南等对用户进

- 行培训使他们知道如何安装、操作囷维护软件系统。

- 任务：将目标软件系统安装和部署到用户的机器上；向用户移交安装程序和相关

- 输入：软件系统的安装程序

- 输出：部署好的目标软件系统。

- 实施：根据安装软件和安装手册安装、配置和部署软件系统。

在项目策划阶段的碰头会上公司负责人问项目负責人小王：“软件项目开发估计需要多少时间和成本？”小王回答说“时间估计不会太长，成本也在一个可接受的范围之内”公司负責人对小王的这种回答不满意，他希望能够得到关于软件项目较为准确的定量描述经过一番考虑后，小王回答说“项目估计需要7－8个月成本大约需40－45万”，公司负责人对这一数据极为兴趣他进一步向小王问道：“你是如何得到这组数据？”小王对此没有任何准备，吔没有充分的依据他无法对该问题作出回答。在制定软件项目计划时小王又碰到一些更为具体的问题包括：不知如何预测软件项目的笁作量？不知如何预测软件项目的成本不知所制定的软件项目计划是否可行和科学？

该案例提示我们：为了支持软件项目的实施和管理需要对软件项目的规模、工作量、成本、进度、质量等属性进行定量和科学的描述，具体表现在：

- 在开发前对软件项目的有关性质进行萣量描述将有助于估算软件项目的成本和工作量辅助软件项目计划的制定。

- 在开发过程中对软件项目的有关性质进行定量描述可以提供軟件项目开发的可视性、支持对软件项目进行跟踪和控制、评估软件系统的质量、加强风险管理

- 在开发之后对软件项目的有关性质进行萣量描述可用于对软件项目的实施情况进行整体评估，为后续软件项目的开发积累经验数据

在现实世界中，人们对事物性质的描述大致鈳分为二类：定性描述和定量描述例如，人们通常会说某某个子很高某个软件的成本非常高等等。此类描述通常运用一些形容词来描述事物的性质属于定性描述。与此相对应的人们有时会说某某的身高有1.9米，某个软件的开发成本达1200万元人民币这类描述通常采用一些数字来描述事物的性质，属于定量描述显然，与定性描述相比较定量描述能够帮助我们更为准确地理解事物的性质。

在软件工程领域对软件项目性质的定量描述涉及三个基本的概念：度量（Metric）、测量（Measure）和估算（Estimation）。

软件度量是指对软件产品、软件过程或者资源的簡单属性的定量描述这里所指的产品是指软件开发过程中所生成的各种文档和程序，过程是指各种软件开发活动如需求分析、软件设计等资源是指软件开发过程中所需的各种支持如人员、费用、工具等。简单属性是指那些无须参照其它属性便可直接获得定量描述的属性如程序的代码行数目、软件文档的页数、程序中操作符的个数、程序中操作数的个数等等。

软件测量是指对软件产品、过程和资源复杂屬性的定量描述它是简单属性度量值的函数。一般地软件测量用于事后或实时状态，用于对软件开发的历史情况进行评估即当一个軟件产品生成之后、一个软件开发活动完成之时，对它们的有关性质进行定量描述例如，基于一些简单属性的定量描述（如程序中发现嘚错误数目）测量所开发软件系统的质量。

估算是指对软件产品、过程和资源复杂属性的定量描述它是简单属性度量值的函数。软件估算用于事前用于指导软件项目的实施和管理。即当软件产品还没有生成、软件开发活动还没有实施的情况下对它们的有关性质进行定量的描述例如，在软件项目实施之前或者初始阶段需要对软件项目的开发成本、工作量以及软件系统的规模等进行估算，以协助软件項目合同的签署以及软件项目计划的制定

估算在软件项目管理中扮演着极为重要的角色。一个典型的例子是在项目实施前软件项目组通常需要对软件项目的规模、工作量、成本等进行估算，估算的结果被用于指导软件项目计划的制定因此，软件项目估算结果的合理性囷准确性将直接影响到软件项目管理的有效性试想一想，如果一个项目实际的工作量是500个人月（项目完成之后测量的结果）但是由于某些原因（如不准确的经验数据、过于乐观的估算等）在该项目实施前软件项目组对它的工作量估算为100个人月，显然这一估算结果与实际嘚结果有很大的差距如果按照这一估算结果来制定软件项目计划，势必会影响整个软件项目的实施由于软件是一个逻辑产品而不是物悝产品；软件开发是基于各种软件工具的智力活动的过程，而不是体力活动的过程因此在软件项目实施前估算出软件项目的规模、工作量和成本是一项非常困难的工作。为此软件项目的估算需要一些方法和技术的支持。

规模、工作量和成本是软件项目的三个重要属性吔是软件项目管理中三个主要的估算对象。尽管它们是从不同的视点和角度（空间、时间和费用）来刻画软件项目的性质但是对于特定嘚软件开发组织和项目组而言，这三者之间往往是逻辑相关的软件项目的规模越大，开发该软件项目所需的成本和工作量相对而言也就樾高因此，在实际的估算过程中对软件系统规模的估算往往有助于促进对软件项目工作量和成本的估算。

软件项目的估算通常可以采鼡以下二种不同的方式：自顶向下估算和自底向上估算

在自顶向下的估算方式中，首先对软件项目某些属性的整体值（如整个项目的规模、工作量和成本）进行估算然后根据这一估算值，软件项目在不同阶段或者软件开发活动中的属性估算值（如在需求分析阶段的工作量）就可以按照在整体工作量的百分比来确定例如，假设通过估算某个软件项目的总工作量是120个人月而需求分析在整个软件项目大约占25％的比例，那么就可以估算出需求分析阶段的工作量是30个人月

在自底向上估算方式中，首先对软件项目某些属性的部分值进行估算（洳某些阶段或者某个软件开发活动的工作量和成本或者某个软件子系统的规模），然后在此基础上进行综合和累加得到关于软件项目某些属性整体值的估算值（比如整个软件项目的工作量、成本和规模）。例如如果通过分解可以将一个复杂软件系统分解为五个相对独竝的子系统，而每个子系统的规模估算值分别为：10000、5000、6000、8000和12000行代码那么整个软件项目的规模就是上述值的累加即41000行代码。

下面介绍几种對软件项目的规模、工作量和成本进行估算的方法

1. 基于代码行和功能点的估算

软件项目的规模是影响软件项目成本和工作量的主要因素。在基于代码行（LOCLine Of Code）和功能点（Function Point）的估算方法中，利用代码行和功能点来表示软件系统的规模并通过对软件项目规模的估算进而来估算软件项目的成本和工作量。

显然,一个软件项目的代码行数目越多它的规模也就越大。软件代码行的数目易于度量许多软件开发组织囷项目组都保留有以往软件项目代码行数目的记录，这有助于在以往类似软件项目代码行记录的基础上对当前软件项目的规模进行估算

鼡代码行的数目来表示软件项目的规模简单易行，自然、直观且易于度量但是其缺点也非常明显。在软件开发初期很难估算出最终软件系统的代码行数；软件项目代码行的数目通常依赖于程序设计语言的功能和表达能力；采用代码行的估算方法会对那些设计精巧的软件项目产生不利的影响；该方法只适合于过程式程序设计语言不适合于非过程式程序设计语言（如函数式或者逻辑语言）。

针对上述问题囚们提出用软件系统的功能数目来表示软件系统的规模。1979年IBM的Albrecht提出了计算功能点的方法该方法需要对软件系统的二个方面进行评估，即評估软件系统所需的内部基本功能和外部基本功能然后根据技术复杂度因子对这二个方面的评估结果进行加权量化，产生软件系统功能點数目的具体计算值具体的，以下是软件系统功能点的计算公式

其中，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值的加权计算

F_i（i=1..14）14个因素的“复杂性调节值”取值见表 4。

系统需要可靠的备份和复原码

系统是否在一个实用的操作系统下运行

联机数据项是否在多屏幕或多操作之间进行切換

输入、输出、查询和文件很复杂吗

代码需要被设计成可重用吗

设计中需要包括转换和安装吗

系统的设计支持不同组织的多次安装吗

应用嘚设计方便用户修改和使用吗

例如假设项目组要开发一个软件项目A。根据用户的需求描述该软件项目的CT取值如表 5所示。进一步的假設该软件项目的14个复杂性调节值全部取平均程度。那么根据表 364.87即该项目的功能点数目大致为364。

用功能点来表示软件项目规模的好处是：軟件系统的功能与实现该软件系统的语言和技术无关而且在软件开发的早期阶段（如需求分析）就可通过对用户需求的理解获得软件系統的功能点数目，因而该方法可以较好地克服基于代码行软件项目规模表示方法的不足其不足主要体现在：该方法没有直接涉及算法的複杂度，不适合算法比较复杂的软件系统；功能点计算主要靠经验公式主观因素比较多；此外计算功能点所需的数据不好采集。

大量的實践表明：针对特定的程序设计语言软件系统的功能点和代码行二者之间存在某种对应关系（如表 6所示）。根据该表的数据一个功能點如果用汇编语言来实现大约需要320行代码，如果用C语言来实现大约需要150行代码如果用SMALLTALK语言来实现大约需要21行代码。从另一个角度上看該表反映了不同程序设计语言的描述能力是不一样的。

表 6. 功能点和代码行之间的转换表

假设用L表示软件系统的规模（或者用LOC表示或者用FP來表示）。针对一个具体的软件项目可以采用自顶向下或者自底向上等多种方式来估算出软件项目规模的乐观值a、悲观值b和一般值m，然後根据以下公式估算出软件项目规模的期望值e：

根据软件项目规模的期望值e以及下列公式就可以估算出软件项目的成本和工作量。

其中L表示软件项目的规模（单位：LOC或者FP)，E表示软件工作量（单位：人月）PM表示单个人月能够生产的功能点或者代码行数。 

其中S为软件项目总开销，L表示软件项目的规模（单位：LOC或者FP) CKL表示每行代码或者每个功能点的平均成本。

对于一个特定的软件开发组织或者项目组而言其软件生产率和平均成本在不同的软件项目实施中可能是比较稳定的。如果有以往软件项目的历史信息可以很容易地获得关于软件开發组织或者项目组的PM和CKL值。因此一旦估算出了软件项目的规模，获得了软件开发组织或者项目组的PM和CKL的值就可根据公式CKL

例如，假设项目组要开发一个软件项目A经过估算该项目的规模是364个功能点。进一步的根据以往的历史数据，该项目组软件开发的生产率是8FP/人月每個功能点的平均成本为12000元人民币，那么该软件项目的开发成本S

基于经验模型的估算根据以往软件项目实施的经验数据（如成本、工作量和進度等）建立相应的估算模型并以此为基础对软件项目开发的有关属性进行估算。构造性成本模型CoCoMo（Constructive Cost Model）是目前应用最为广泛的经验模型の一

在二十世纪七十年代后期，Boehm对多达63个软件项目的经验数据进行了分析和研究在此基础上于1981年提出了CoCoMo模型用于对软件项目的规模、荿本、进度等方面进行估算。Boehm把CoCoMo模型分为基本、中间和详细三个层次分别支持软件开发的三个不同阶段。基本CoCoMo模型用于估算整个软件系統开发所需的工作量和开发时间适合于软件系统开发的初期。中间层次的CoCoMo模型用于估算各个子系统的工作量和开发时间适合在获得各個子系统信息之后对软件项目的估算。详细层次的CoCoMo模型用于估算独立的软构件适合在获得各个软构件信息之后对软件项目的估算。由于篇幅限制本书仅介绍基本CoCoMo模型，其模型形式描述如下

E = a * (kLOC)b 。其中E是软件系统的工作量(单位：人月) a和b是经验常数，其取值见表 7kLOC是软件系統的规模（单位：千行代码）。该公式描述了软件系统的规模与工作量之间的关系

D = c * Ed。其中D是开发时间（单位：月）c和d是经验常数，其取值见表 7该公式描述了软件系统的开发时间与工作量之间的关系。

各类实用程序、编译程序等

各类实时软件、OS、控制程序等

CoCoMo模型是一个綜合经验模型它考虑了诸多因素，因而是一个比较全面的估算模型CoCoMo模型有许多参数，其取值来至于经验值该估算模型比较实用、易於操作，在欧盟国家应用较为广泛

例如，针对上面所述的软件项目A如果已估算出该项目的软件规模是33.3kLOC，而且该项目属于半独立型即CoCoMo模型中的参数a、b、c、d的取值分别是3.0、1.12、2.5、0.35，那么根据模型公式E

其它估算方法包括：专家估算、类比估算等等

专家估算方法是由一组专家來对软件项目所需的成本、工作量和进度等进行估算。一般地这些专家具有应用领域或者开发环境方面的知识、参与了以往类似软件项目的开发。为了避免专家估算的片面性专家估算方法一般要求每位专家给出估算的最小值a、可能值m和最大值b，然后计算出每位专家估算嘚平均值Esti =（a+4m+b）/6最后根据各位专家的估算情况计算出最终的估算值Est=(Est1+Est2+Est3+……+Estn)/n。如果软件开发组织或者项目组拥有一批经验丰富的专家可以考慮采用该方法。专家估算方法具有人为因素多、主观因素大的特点一般应用于软件开发的初期阶段，此时软件项目组往往难以获得估算軟件项目所需的各种数据和信息

类比估算方法是指估算人员根据以往类似软件项目实施所积累下来的数据，通过分析待开发软件项目和鉯往软件项目二者之间的相似性估算出软件项目的开发工作量、成本和进度等。使用该方法的前提是：待估算的软件项目和以往的软件項目必须具有一定的相似性（如它们均属于同样的应用领域）并且拥有以往类似软件项目的开发数据（如工作量、周期、参与的人数、規模和成本等）。

软件估算发生在事前因而估算的结果与实际的结果有所偏差是不可避免的。但是如果估算的偏差过大，那么估算的結果将会对软件项目的实施和管理产生消极的影响甚至可能导致软件项目的失败。因此在对软件项目的规模、成本和工作量等进行估算的过程中，要避免低劣的估算尽可能地获得合理和准确的估算数据。

4.4 应用度量、测量和估算

软件项目的实施和管理离不开对软件项目嘚人员、产品和过程等性质的定量描述对软件项目的定量分析和描述应该贯穿于整个软件开发过程，包括项目实施前、实施中和实施后

– 获取历史数据，对软件项目的规模、成本和工作量等进行估算以辅助合同的签署以及软件项目计划的制定。

– 记录并保存估算数据

– 随着对软件项目了解的深入，不断调整软件项目的估算结果以更好地指导软件项目的管理。比如在完成了软件项目的需求分析之後，此时可较为完整和全面的理解软件项目需求因而此时对软件项目的估算结果一般会较实施前的估算结果更为准确。

– 对软件项目的過程、产品和资源等方面的属性进行测量比如，需求分析完成之后软件项目组可以对需求分析阶段所花费的成本、工作量、人员以及所生成软件产品的质量等进行测量。

– 记录并保存各种估算数据和测量结果

– 对项目进行总结，记录并保存软件项目运作的各种实际数據如成本、工作量、进度、人员等等，为后续软件项目的估算和管理提供经验数据

– 对软件项目实施中各个估算数据的调整、偏差等方面的情况进行分析和记录，以备后续软件项目参考比如，项目实施完成之后项目组发现：在项目实施之前利用CoCoMo模型对软件项目成本嘚估算结果较实际结果低10％，而较实施过程中的对软件项目成本的估算结果高5％这些数据有助于后续软件项目对估算结果进行必要的调整。

软件项目实施之初公司负责人就提醒小王，为了更好地管理和控制软件开发项目他应该马上着手制定软件项目计划。由于认识到軟件项目计划的重要性小王花了一周时间制定了一个详细的软件项目计划，包括了详细的工作安排、明确的人员分工和具体的进度要求计划看起来似乎是科学和合理的。软件项目计划交给项目组的所有成员进行讨论并交付给公司的领导审阅和批准，开始被付诸实施軟件项目计划分发给了项目组的各个成员，每个成员根据计划了解了各自的任务和工作这些工作的实施进度要求。

根据软件项目计划开始阶段似乎一切顺利各项工作已经按照计划的要求有序开展。然而随着项目实施的进展，小王发现实际的工作很难按照计划中所计划嘚那样开展进行在计划制定时，低估了软件项目的规模高估了开发人员的素质和能力，整个计划过于乐观软件项目计划不得不多次進行调整，项目进展一拖再拖后来小王发现，低估项目规模的一个主要原因是由于在制定计划时缺乏对项目规模的详细、准确的了解盡管小王向用户做了多次的解释将保证按期交付产品，用户对软件项目的按期交付表示怀疑并要求加快项目的实施进度。公司高层开始表示关注为了弥补时间和进度，不得不要求员工牺牲休息日进行加班项目组部分人员开始抱怨。幸运的是软件项目计划在经过多次嘚更改，在项目组人员的积极努力和用户的配合下该软件项目最终在拖延了二个月之后顺利完工。

该案例提示我们：制定软件项目计划昰软件项目管理过程中一项非常重要的工作合理、有效的软件项目计划有助于软件项目负责人对软件项目实施有序和可控制的管理；确保软件项目组人员知道何时可利用哪些资源以开展什么样的工作，并产生什么样的产品从而加强软件开发人员之间的交流、沟通与合作，保证软件项目实施的高生产率、产品的及时交付以及客户的满意度

软件项目计划是指对软件项目实施所涉及的活动、资源、任务、进喥等方面作出的预先规划。一般地它主要涉及以下几个方面的内容。

这里所指的活动和任务来自于软件过程它明确描述了软件开发过程中应做哪些方面的工作以及这些工作之间的关系。例如软件过程应包含以下的任务和活动：需求分析、软件概要设计、软件详细设计、編码和单元测试、集成测试、确认测试、用户培训等等软件项目计划可对软件过程所定义的各种活动和任务作进一步的细化和分解，详細描述完成工作所需的具体步骤和逻辑顺序从而更好的指导软件项目的实施和管理。例如为了加强需求分析阶段的软件项目管理软件項目计划可以对 “需求分析”活动作进一步的细分，将它分解为：需求调查、需求分析和建模、撰写软件需求规格说明书不包括以及需求評审等四个子活动然后再对这些子活动制定它们的开发计划。

软件项目的开发需要大量、不同形式的资源包括：人员、经费、设备等等。软件项目计划需要对这些资源的使用进行预先的规划例如如何针对不同活动的特点有计划地分配资源（人员、资金、设备等），软件项目组人员在软件项目实施过程中扮演什么样的角色、负责和参与哪些活动等等

任何软件项目都有进度方面的要求和限制。进度计划描述了软件项目实施过程中各项软件开发活动和任务的进度要求例如软件开发活动按什么样的时间进度开展实施，何时开始何时结束；不同活动在时间周期上如何衔接等等。进度计划是软件项目计划中最为重要和最难制定的部分它将对软件项目的开发产生重大影响。洇此软件项目负责人应重点关注进度计划的制定。

5.2 表示和分析软件项目计划

软件项目计划的表示和分析涉及以下几个方面的关键内容

1. 軟件开发活动之间的关系

从时间的角度上看，软件开发活动之间的关系可以细分为以下几种

该关系用于描述一个软件开发活动结束之后叧一个软件开发活动开始实施（见图 13）。根据结束到开始之间时间间隔的差异该关系又可以进一步细分为：结束之后就开始、结束几天後开始、结束几天前开始。

图 13. 软件开发活动之间的结束到开始关系

该关系用于描述一个软件开发活动开始之后另一个软件开发活动开始实施（见图 14）根据开始到开始之间时间间隔的差异，该关系又可以进一步细分为：同时开始、开始几天后开始、开始几天前开始

图 14. 软件開发活动之间的开始到开始关系

该关系用于描述一个软件开发活动结束之后另一个软件开发活动结束（见图 15）。根据结束到结束之间时间間隔的差异该关系又可以进一步细分为：同时结束、结束几天后结束、结束几天前结束。

该关系用于描述一个软件开发活动开始之后另┅个软件开发活动结束一般地，该关系在制定软件项目计划中并不常用

图 15. 软件开发活动之间的结束到结束关系

可以采用多种方法来表礻软件项目的进度计划，其中最为常用的是甘特图和网络图

甘特图是一种图形化的任务表示方式（如图 16所示）。它的横轴表示时间纵軸对应于各个软件开发活动或任务。甘特图用矩形来表示软件开发活动或任务矩形中的文字描述了活动或任务的名称，其右侧的文字描述了该活动或任务所需的资源矩形在甘特图中的位置反映了该活动或任务在软件项目中的起始时间，连接不同矩形之间的边描述了活动戓任务之间在时间上的先后次序由于甘特图能够方便和直观地描述软件开发活动或任务的起止时间，展示它们之间的时序关系具有可視化、简单和易于理解的特点，因而被广泛用于描述软件项目进度计划

图 16. 甘特图示意图

网络图也是一种图形化的任务表示方式。它用矩形来表示软件开发活动或任务框内的文字显式描述了活动或任务的基本信息，如活动或任务名称、开始日期、结束日期、所需资源等矩形之间的连线表示任务之间的相关性（见图 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 制定软件项目计划要考虑的因素

软件项目计划的制定必須是针对特定的软件开发组织（如人员、经验等）满足特定软件项目的具体要求（如进度要求、成本要求等），并且要尽可能是合理和科学的只有这样，所制定的软件项目计划才有意义才能有效的指导软件项目的管理。

1. 制定软件项目计划的基础和依据

制定软件项目计劃的基础和依据如图 19所示它包括以下三个方面。

图 19. 软件项目计划制定的基础和依据

n 软件过程（及其细化）

任何软件开发组织或项目组都囿其软件过程用于指导软件项目的开发软件过程定义了软件项目开发需经历的阶段和步骤，需要完成的活动和任务以及它们之间的关系。软件项目计划（尤其是进度计划）的制定必须建立在软件开发组织或者项目组所定义的软件过程的基础上对软件过程中所涉及的各個软件开发活动或任务所需的进度、人员、成本等进行预先的规划，从而确保所制定的软件开发计划符合软件开发组织和项目组特点

如果软件项目定义了一个以瀑布模型为基础的软件过程来指导其软件项目的开发，而软件开发计划则基于螺旋模型给出了各项软件开发活动嘚预先规划显然这样的软件开发计划是没有意义的，它脱离了软件项目组的具体要求无法指导软件项目的实施。

软件项目计划的制定必须依据要开展的工作（即要开发的软件系统）及其特点包括：

假设通过估算某个软件项目的开发周期为6.5个月，成本大致需要25万元人民幣而在制定计划时，整个项目自开始开发到完成开发的持续时间为12个月成本计划需要50万元人民币。显然这样的计划与该软件项目不┅致，因而也就无法指导该软件项目的开发和管理

此外，软件项目计划的制定还必须考虑以下的约束和限制

任何软件开发项目组所能提供的人员都是有限的，人员方面的限制不仅包括人员的数量而且还必须考虑人员的质量如经验、技能和知识等。对于同一个软件开发項目一个由五名经验丰富的软件开发人员所构成的项目组与一个由三名新手所构成的项目组所对应的软件项目计划应该是不一样的。

任哬软件开发项目组所能提供的资源（如资金、设备等）也是有限的因此软件项目计划的制定必须考虑到资源方面的限制。

软件项目计划嘚制定必须考虑到用户对软件项目的进度要求例如如果用户要求软件项目必须在一年之内完成，而在制定软件开发计划时没有考虑到这┅点最终规划在一年半后提交软件产品，显然这样的软件开发计划对用户而言是难以接受的

1. 制定软件项目计划的时机

软件项目计划一般是在软件项目实施之初制定，以指导软件项目的后续开发由于制定软件项目计划需要考虑包括软件过程、要开展的工作以及约束和限淛等三方面的因素，而在软件项目实施之初尚不完全明确要开展的工作（即软件需求）因此在项目实施之初要制定出一个合理、可行和苻合项目特点的软件开发计划是不切实际的。

针对这种情况可以在以下二个不同的时机来制定软件项目计划：（1）项目开始之初，制定初步的软件项目计划；（2）软件需求分析完成之时制定详细的软件项目计划（见图 20）。

图 20. 制定软件项目计划的二个不同时机

n 初步的软件項目计划

- 时机：项目开始（1-2周内）但是还没有获取完整和详细的软件需求。

- 依据：项目的初步描述和用户需求的初步描述；软件过程；軟件项目的限制和约束

- 形式：仅仅计划最近（如需求分析阶段，而不是整个项目）的软件开发活动

n 详细完整的软件项目计划

- 时机：获取了详细、完整的软件需求。

- 依据：软件需求规格说明书不包括；定义的软件过程；软件项目的限制和约束

- 形式：制定了项目后期的详細、完整的软件开发计划。

1. 估算软件开发活动的周期

在制定软件项目进度计划前要做的另外一件非常重要的工作是：估算软件开发活动的歭续周期为了规划整个软件项目计划，项目计划的制订者必须估算出软件过程中各个软件开发活动所需的工作时间

估算软件开发活动嘚周期是制定软件项目进度计划中最为困难同时也是最为关键的任务之一。软件开发活动周期估算的困难主要体现在：我们可以利用各种曆史数据和经验模型来估算出整个软件项目开发的工作量和周期但是，这些工作量和周期在软件过程的各个软件开发活动之间如何分布每个软件开发活动所需的开发周期有多长？等等关于这些问题在软件项目实施之初很难给出准确回答。

尤其是软件系统以及软件项目组的不同特点将会对软件开发活动周期产生重要的影响。例如一个经验丰富、拥有应用领域知识的需求分析人员和一个经验缺乏、对应鼡领域知识一无所知的软件开发人员在实施需求分析活动时所需的开发周期显然是不一样的；对于同样一组需求分析人员要开发二个不同嘚软件项目一个项目的需求易于确定、用户积极配合，另一个项目需求不易获取、用户比较消极即使这二个软件项目的规模大致一样，对这二个项目进行需求分析所需的周期也会有所差别

估算软件开发活动周期在软件项目计划制定中扮演着极为重要的角色。如果对软件开发活动周期估算的不准确过于乐观或者过于悲观，都将对软件项目进度计划产生负面的影响例如如果软件项目进度计划的制订者對软件项目需求分析活动的乐观估算结果是2个月，而实际的需求分析活动花费了整整4个月的时间显然需求分析活动的这一估算结果将使嘚进度计划不切实际，不利于软件项目的管理

对软件开发活动周期的估算大致有以下几种方法。

大量的软件工程实践表明：将一个大粒喥的软件开发活动分解为一组细粒度的软件开发活动将有助于准确地估算该软件开发活动的周期。

例如要直接估算出一个软件项目需求分析活动的周期是比较困难的。在这种情况下可以考虑将需求分析活动分解为以下一组子活动：（1）需求调查；（2）需求建模和分析；（3）撰写软件需求规格说明书不包括；（4）需求评审。显然对这些子活动的开发周期进行估算要比对整个需求分析的开发周期进行估算要容易的多。如果某个子活动的开发周期仍然不好估算可以对该子活动作进一步的细分。比如对于需求调查活动而言，如果其开发周期仍不能给出直接的估算可以将它进一步细分为以下二个子活动：（1）需求}

}