软件架构之开发管理

第 13 章：开发管理

美国国防部曾于 20 世纪 70 年代中期专门针对软件项目失败的原因做了调查。调查结果显示 70%的失败软件项目都是因为管理不善引起的，而并不是事先以为的技术实力不够。到了 20 世纪 90 年代，据对美国软件工程实施现状的调查显示，大约只有 10%的项目，尤其是商用软件，能够按预先计划的费用和进度交付。因此，业界认为影响软件研发项目全局的因素是管理水平，而技术只影响局部，这就有必要从项目管理的角度去管理软件的开发和运行。

加强项目管理的好处是明显的，它可以控制财务成本、提高资源利用率；改进客户关系；缩短开发时间；降低成本；提高利润、生产率、产品质量和可靠性；完善公司内部协调等。

根据美国项目管理协会的项目管理知识体系可知，项目管理是指“在项目活动中运用专门的知识、技能、工具和方法，使项目能够实现或超过项目干系人的需要和期望。”一 般的项目管理可以分为范围管理、时间管理、费用管理、质量管理、人力资源管理、沟通 管理、风险管理、采购管理和整体管理 9 个知识领域。对于软件的开发管理来讲，软件范围管理、软件进度管理、软件成本管理、软件配置管理（属于整体管理）、软件质量管理、软件风险管理、开发人员管理（属于人力资源管理）7 个方面的管理尤为重要，软件开发的每个阶段、每个过程都要重视这几个方面的管理。

13.1 项目的范围、时间与成本

项目管理首先要考虑三个约束条件：项目范围、时间进度、成本预算。在签订软件开发合同时要明确：项目的任务是什么？发起人要通过项目获得什么样的产品或服务？这属于项目范围的范畴；项目需要多长时间？进度如何安排？这属于时间进度的范畴；项目需要花费多少？资金来源如何？这属于项目成本的范畴。

13.1.1 项目范围管理

所谓项目范围管理，包括保证项目顺利完成所需的全部工作过程。其目的是控制项目的全部活动都在需求范围内，以确保项目资源的高效利用。它主要包括项目启动、范围计划编制、范围定义、范围核实和范围变更控制 5 个部分的内容。项目启动指批准项目启动或者允许项目进入下一个阶段；范围计划编制是将生产项目产品所需进行的项目工作渐进明细和形成文件的过程；项目范围定义是把主要的项目可交付成果分解成更小、更易管理的单元，以达到如下目的：

• 提高对成本、时间及资源估算的准确性。
• 为绩效测量与控制定义一个基准计划。
• 便于进行明确的职责分配。

正确的范围定义是项目成功的关键。“当范围定义不明确时，不可避免的变更会使最终项目成本大大超出预算，因为这些不可避免的变更会破坏项目节奏，导致返工、增加项目历时、降低生产率和工作人员的士气”。范围核实是项目干系人（发起人、客户）正式接受项目范围的过程。范围核实需要审查可交付成果和工作结果，以确保它们都已经正确圆满地完成。如果项目被提前终止，范围核实过程应当对项目完成程度建立文档。范围核实与质量控制是不同的，范围核实是有关工作结果的“接收”，而质量控制是有关工作结果的正确性。
项目范围变更控制涉及的是：

• 对造成范围变更的因素施加影响，以确保这些变更得到一致认可；
• 确定范围变更是否已经发生；
• 当范围变更发生时对实际变更进行管理。
• 范围变更控制必须与其他控制管理过程（进行控制、成本控制和质量控制）结合在一起使用，才能取得良好的效果。

13.1.2 项目成本管理

所谓项目成本管理，是保证在批准预算内完成项目所需要的过程。成本对项目有关各方来说都是非常敏感的问题。因此成本管理在软件项目管理中是一项非常重要的工作。软件项目的成本不仅包括开发成本，也包括开发之前立项阶段及软件在运行中的费用。此外，操作者的培训费用和项目所使用的各种硬件设施费用也都是整个项目成本的一部分，这些成本都需要很好地计划和控制。
项目成本管理包括资源计划编制、成本估算、成本预算、成本控制 4 个主要部分内容。

资源计划编制是确定为完成项目各活动需什么资源（人、设备、材料）和这些资源的数量。资源计划与成本估算是紧密相关的。成本估算就是计算出完成一个项目的各活动所需各资源成本的近似值。当一个项目按合同进行时，应区分成本估算和定价这两个不同意义的词。成本估算所涉及的是对可能数量结果的估算——执行组织为提供产品和服务的花费是多少；而定价是一个商业决策——执行组织为提供的产品或服务索取多少费用。成本估算是定价要考虑的因素之一。成本估算包括确认和考虑各种不同的成本估算替代方案。例如软件设计阶段多做些工作可减少编码阶段的成本。而成本估算过程必须考虑增加的设计工作所多花的成本是否被以后的节省所抵消。

成本预算是把估算的总成本分配到单个活动或工作包上去，建立基准计划来度量项目实际绩效。成本控制的内容有：对造成成本基准计划变化的因素施加影响，以保证这种变化得到一致认可；确定成本基准计划是否已经发生变化；当变化发生和正在发生时，对这种变化执行管理。成本控制包括以下方面：

• 监测成本执行情况，以寻找出并掌握计划的偏差及原因。
• 确保所有变更都准确地记录在成本基准计划中。
• 防止把不正确、不适宜或未批准的变更纳入成本基准成本。
• 将批准的变更通知项目干系人。
• 采取措施，把预计的成本控制在可接受的范围内。
• 成本控制包括寻找产生正负偏差的原因。成本控制必须和其他控制过程结合。例如，如果成本偏差采取不恰当的应对措施常会引起项目的质量和进度问题或引起项目在后期出现无法接受的风险。

13.1.3 项目时间管理

时间管理包括确保项目按时完成所需的各个过程。它包括活动定义、活动排序、活动历时估算、进度计划编制、进度控制 5 个部分内容。活动定义是对 WBS 中规定的可交付成果或半成品的产生所必须进行的具体活动进行定义，并形成文档。为使项目目标得以实现，在这个过程中对活动做出定义无疑是必要的。活动排序是确定各活动之间的依赖关系，并形成文档。活动必须被正确地加以排序，以便今后制定切实可行的进度计划。排序可由计算机辅助或用手工排序。

项目活动历时估算是根据项目范围和资源的相关信息为进度表设定历时输入的过程。历时估算的输入通常来自项目团队中熟悉该活动特性的个人和团体。估算通常采用渐进明细的方式，同时此过程需考虑输入数据的质量和可获得性。因此，可以假设此估算逐步精确，并且其质量水平是已知的。项目团队中最熟悉具体活动性质的个人或团队应当完成历时估算。制订进度计划要决定项目活动的开始和结束日期。若开始和结束日期是不现实的，项目就不可能按计划完成。进度计划、历时估算、成本估算等过程交织在一起，这些过程反复多次，最后才能确定项目进度计划。进度控制涉及的是：对造成进度变更的因素施加影响，以确保这些变更得到一致认可；确定进度变更是否已经发生；
当变更发生时对实际变更进行管理。

13.2 配置管理与文档管理

随着软件规模和复杂性的增大，许多大型开发项目往往都会延迟和超出预算，软件开发不得不直面越来越多的问题，表现为开发的环境日益复杂，代码共享日益困难，需跨越的平台增多；软件的重用性需要提高；软件的维护越来越困难。

为了解决这些问题，作为控制软件系统一系列变化的学科，软件配置管理（Software Configuration Management，SCM）应运而生。其主要作用是通过结构化的、有序化的、产品化的管理软件工程的方法来维护产品的历史，鉴别和定位产品独有的版本，并在产品的开发和发布阶段控制变化；通过有序管理和减少重复性工作，配置管理保证了生产的质量和效率；它涵盖了软件生命周期的所有领域并影响所有数据和过程。作为软件开发中一个重要过程，实现在有限的时间和资金内，满足不断增长的软件产品质量要求，软件配置管理已经逐渐受到各类软件企业的重视。

13.2.1 软件配置管理的概念

对于软件配置管理，IEEE 给出了一个定义：SCM 是指在软件系统中确定和定义构件（源
代码、可执行程序、文档等），在整个生命周期中控制发布和变更，记录和报告构件的状态
和变更请求，并定义完整的、正确的系统构件的过程。在 IEEE 标准 729-1983 中，软件配
置管理包括以下几个方面功能：

• 配置标识：产品的结构、产品的构件及其类型，为其分配唯一的标识符，并以某种形式提供
  对它们的存取。
• 版本控制：通过建立产品基线，控制软件产品的发布和在整个软件生命周期中对软件产品的修改。例如，它将解决哪些修改会在该产品的最新版本中实现的问题。
• 状态统计：记录并报告构件和修改请求的状态，并收集关于产品构件的重要统计信息。例如，
  它将解决修改这个错误会影响多少个文件的问题。
• 审计和审查：确认产品的完整性并维护构件间的一致性，即确保产品是一个严格定义的构件
  集合。例如，它将解决目前发布的产品所用的文件的版本是否正确的问题。
• 生产：对产品的生产进行优化管理。它将解决最新发布的产品应由哪些版本的文件和工具来
  生成的问题。
• 过程管理：确保软件组织的规程、方针和软件周期得以正确贯彻执行。它将解决要交付给用
  户的产品是否经过测试和质量检查的问题。
• 小组协作：控制开发统一产品的多个开发人员之间的协作。例如，它将解决是否所有本地程
  序员所做的修改都已被加入新版本的产品中的问题。 而在另外一个标准 ISO9000.3 中，对软件配置管理系统做了如下要求：
• 唯一地标识每个软件项的版本；
• 标识共同构成一个完整产品的特定版本的每一软件项的版本；
• 控制由两个或多个独立工作的人员同时对一个给定软件项的更新；
• 按要求在一个或多个位置对复杂产品的更新进行协调；
• 标识并跟踪所有的措施和更改；这些措施和更改是在从开始直到放行期间，由于更改请求或
  问题引起的。

两个文件都强调了配置管理三个核心部分：版本管理、问题跟踪和建立管理，其中版本
管理是基础。版本管理应完成以下主要任务：

• 建立项目；
• 重构任何修订版的某一项或某一文件；
• 利用加锁技术防止覆盖；
• 当增加一个修订版时要求输入变更描述；
• 提供比较任意两个修订版的使用工具；
• 采用增量存储方式；
• 提供对修订版历史和锁定状态的报告功能；
• 提供归并功能；
• 允许在任何时候重构任何版本；
• 权限的设置；
• 晋升模型的建立；
• 提供各种报告。

13.2.2 软件配置管理的解决方案

目前，软件配置管理的解决方案有许多厂商提供，如 Rational ClearCase，Merant PVCS，
Microsoft VSS。大部分软件具备版本控制、建立管理、构造管理、问题追踪这些基本的功能
模块，有些软件还融合了需求管理、需求变更管理技术，并支持工作流程，以至Internet/Intranet 应用的异地通信和管理功能。可以看到软件配置管理的趋势是涉及面越来越广，将影响软件开发环境、软件过程模型、配置管理系统的使用者、软件产品的质量和用户的组织机构。

常用的软件配置管理工具，主要有如下产品：Rational ClearCase，Merant PVCS，Microsoft VSS，CVS。

1．Rational ClearCase
ClearCase 是 Rational 公司的主要配置管理工具，可以用于 Windows 和 UNIX 开发环境。ClearCase 主要应用于复杂的产品发放、分布式团队合作、并行的开发和维护任务，支持 Client/Server 网络结构。ClearCase 提供了全面的配置管理功能，包括版本控制、工作空间管理、建立管理和过程控制，而且无须软件开发者改变他们现有的环境、工具和工作方式。
下面列举其主要功能：
（1）版本控制。ClearCase 的核心功能是版本控制，它是对软件开发进程中一个文件或一个目录发展过程进行追踪的手段，通过分支和归并功能支持并行开发。在软件开发环境中，ClearCase 可以对每一种对象类型（包括源代码、二进制文件、目录内容、可执行文件、文档、测试包、编译器、库文件等）实现版本控制。因而，ClearCase 提供的能力远远超出资源控制，并且可以帮助团队在开发软件时为他们所处理的每一种信息类型建立一个安全可靠的版本历史记录。

（2）工作空间管理。所谓空间管理，即保证开发人员拥有自己独立的工作环境，拥有自己的私人存储区，同时可以访问成员间的共享信息。ClearCase 给每一位开发者提供了一致、灵活的可重用工作空间域。它采用名为 View 的新技术，通过设定不同的视图配置规格，帮助程序员选择特定任务的每一个文件或目录的适当版本，并显示它们。View 可以让开发者在资源代码共享和私有代码独立的不断变更中达到平衡，从而使他们的工作更有效。

（3）建立管理。ClearCase 自动产生软件系统构造文档信息清单，而且可以完全、可靠地重建任何构造环境。ClearCase 也可以通过共享二进制文件和并发执行多个建立脚本的方式支持有效的软件构造。使用 ClearCase，构造软件的处理过程可以和传统的方法兼容。对 ClearCase 控制的数据，既可以使用自制脚本也可使用本机提供的 make 程序，但 ClearCase 的建立工具clearmake（支持 UNIX）和 omake（支持 NT）为构造提供了重要的特性：自动完成任务、保证重建的可靠性、存储时间和支持并行的分布式结构的建立。此外，ClearCase 还可以自动追踪、建立产生永久性的资料清单。

（4）过程控制。ClearCase 有一个灵活、强大的功能，可以明确项目设计的流程。ClearCase 为团队通信、质量保证、变更管理提供了非常有效的过程控制和策略控制机制。ClearCase 可以有效地设置监控开发过程，这体现在：为对象分配属性；超级链接；历史记录；定义事件触发机制；访问控制查询功能等几个方面。自动的常规日志可以监控软件被谁修改、修改了什么内容及执行政策，如可以通过对全体人员的不同授权来阻止某些修改的发生，无论任何时刻某一事件发生应立刻通知团队成员，对开发的进程建立一个永久记录并不断维护它。综上所述，ClearCase 支持全面的软件配置管理功能，给那些经常跨越复杂环境（如 UNIX、Windows 系统）进行复杂项目开发的团队带来巨大效益。此外，ClearCase 也支持广泛的开发环境，它所拥有的特殊构件已成为当今软件开发人员、工程人员和管理人员必备的工具。

2．Merant PVCS
Merant 的 PVCS 是世界领先的软件开发管理工具，在软件生命周期管理市场占有绝大多数市场份额，是公认的工业标准。全球的著名企业、软件机构、银行等诸多行业及政府机构大多数都应用了 PVCS。它能够实现配置管理中的各项要求，并且能和多种流行开发平台集成，为配置管理提供了很大的方便。PVCS 包含多种工具，几乎覆盖了软件开发管理中的所有问题。

• PVCSVersionManager：能完整、详细地记录开发过程中出现的变更和修改，可快速得到系统中任何文件的各个版本，并使修订版本自动升级。
• PVCSConfigurationBuilder：为软件系统提供了可靠的自动重建过程。它保证系统在任何时候对某一发布的产品准确地进行重建，避免发生错误，同时自动地对修改过的模块重新编译以节省时间。
• PVCSTracker：在整个开发过程中确定和追踪软件的每一变更的要求。
• PVCSNotify：将软件状态的变更通过 E-mail 通知组织机构中的其他成员。
• PVCSReporter：为 GUI 界面环境提供一个客户报表工具，使用它能很容易地生成和存储多个项目的报表。
• PVCSProductionGateway：提供了局域网间与大型机 MVS 系统双向同步互联。
• PVCSDeveloper’sToolkit：为 PVCS 客户提供了应用程序开发接口（API），使项目信息通过编程访问。
• PVCSRequisitePro：提供了一个独特的 MicrosoftWord 界面和需求数据库，从而可以使开发机构实时、直观地对来自于最终用户的项目需求及需求变更进行追踪和管理，可有效地避免重复开发，保证开发项目按期、按质、按原有的资金预算交付用户。

上述的 8 个模块既可以单独安装和使用，也可以相互集成，建立工业化软件开发企业所需的完整的软件开发管理环境。PVCS 不仅很好地解决了代码重用、数据丢失等问题，它还从下述的几个主要方面，满足了软件开发机构迅速增长的市场需求，成为全球开发机构首选的软件配置管理工具。

3．Microsoft VSS，CVS
微软的 VSS（Visual SourceSafe）提供了基本的认证安全和版本控制机制，包括 CheckIn（入库）、CheckOut（出库）、Branch（分支）、Label（标定）等功能。版本控制是工作组软件开发中的重要方面，它能防止意外的文件丢失、允许反追踪到早期版本、并能对版本进行分支、合并和管理。在软件开发中比较两种版本的文件或找回早期版本的文件时，源代码的控制是非常有用的。

VSS 是一种源代码控制系统，它提供了完善的版本和配置管理功能，以及安全保护和跟踪检查功能。VSS 带有一个专业的文档、代码管理库，通过将有关项目文档（包括文本文件、图像文件、二进制文件、声音文件、视频文件）存入数据库进行项目研发管理工作。通过 VSS 与 APT 系统的配合，能够对文件进行控制，用户可以根据需要随时快速有效地共享文件。从文档的控制流程（增加、删除、修改、借阅等），到文档的修改信息记录，实现完善的文档管理。VSS 提供了历史版本的提取、提供源码历史版本对比。VSS 文件一旦被添加进 VSS，它的每次改动都会被记录下来，用户可以恢复文件的早期版本，项目组的其他成员也可以看到有关文档的最新版本，并对它们进行修改，VSS 也同样会将新的改动记录下来。用 VSS 来组织管理项目，使得项目组间的沟通与合作更简易而且直观。

VSS 可以同 Visual studio 开发环境及 Microsoft Office 应用程序集成在一起，提供了方便易用、面向项目的版本控制功能。VSS 可以处理由各种开发语言、创作工具或应用程序所创建的任何文件类型，用户可以同时在文件和项目级进行工作。VSS 面向项目的特性能更有效地管理工作组应用程序开发工作中的日常任务。VSS 的客户端既可以连接服务器运行，也可以在本机运行，非常适合于个人程序开发的版本管理。CVS（并发版本系统，ConcurrentVersions System）是主流的开放源码的版本控制系统，Linux 和 UNIX 下系统自带的版本控制工具。CVS 对于从个人开发者到大型、分布式团队都是有用的。与微软 VSS 在实现功能上属于同一个级别，不过支持的操作平台不一样。

13.2.3 软件文档管理

所谓文档，是指某种数据媒体和其中所记录的数据。它具有永久性，并可以由人或机器阅读，通常仅用于描述人工可读的东西。在软件工程中，文档常常是用来对活动、需求、过程或结果进行描述、定义、规定、报告或认证的任何书面或图示的信息。在软件生产过程中，总是产生和使用大量的信息。软件文档在产品的开发过程中起着重要的作用。

1．软件文档的作用
（1）管理依据。在软件开发过程中，管理者必须了解开发的进度、存在的问题和预期目标。每一阶段计划安排的定期报告提供了项目的可见性，把开发过程中发生的事件以某种可阅读的形式记录在文档中。定期报告还提醒各级管理者注意该部门对项目承担的责任及该部门效率的重要性。开发文档规定若干个检查点和进度表，使管理者可以评定项目的进度，如果开发文档有遗漏、不完善或内容陈旧，则管理者将失去跟踪和控制项目的重要依据。管理人员可把这些记载下来的材料作为检查软件开发进度和开发质量的依据，分析评估项目、检查调整项目/计划、调配专用资源，实现对软件开发的工程管理。

（2）任务之间联系的凭证。大多数软件开发项目通常被划分成若干个任务，并由不同的小组去完成。学科方面的专家建立项目，分析员阐述系统需求，设计员为程序员制定总体设计，程序员编制详细的程序代码，质量保证专家和审查员评价整个系统性能和功能的完整性，负责维护的程序员改进各种操作或增强某些功能。这些人员需要的互相联系是通过文档资料的复制、分发和引用而实现的，因而，任务之间的联系是文档的一个重要功能。大多数系统开发方法为任务的联系规定了一些正式文档。分析员向设计员提供正式需求规格说明，设计员向程序员提供正式设计规格说明等

（3）质量保证。软件文档能提高开发效率。软件文档的编制使得开发人员对各个阶段的工作都进行周密思考、全盘权衡、减少返工。并且可在开发早期发现错误和不一致性，便于及时加以纠正。那些负责软件质量保证和评估系统性能的人员需要程序规格说明、测试和评估计划、测试该系统用的各种质量标准，以及关于期望系统完成什么功能和系统怎样实现这些功能的清晰说明；必须制订测试计划和测试规程，并报告测试结果；他们还必须说明和评估完全控制、计算、检验例行程序及其他控制技术。这些文档的提供可满足质量，保证人员和审查人员上述工作的需要。

（4）培训与参考。软件文档作为开发人员在一定阶段的工作成果和结束标志，它的另一个功能是使系统管理员、操作员、用户、管理者和其他有关人员了解系统如何工作，以及为了达到他们各自的目的，如何使用系统。

（5）软件维护支持。记录开发过程中有关信息，便于协调以后的软件开发、使用和维护。维护人员需要软件系统的详细说明以帮助他们熟悉系统，找出并修正错误，改进系统以适应用户需求的变化或适应系统环境的变化。软件文档提供对软件的运行、维护的有关信息，便于管理人员、开发人员、操作人员、用户之间的协作、交流和了解。

（6）历史档案。良好的文档系统，作为全组织范围内共享所存储的文档信息，对于软件企业而言，也是一个很好的学习资源。通常文档记载系统的开发历史，可使有关系统结构的基本思想为以后的项目利用。系统开发人员通过审阅以前的系统以查明什么部分已试验过了，什么部分运行得很好，什么部分因某种原因难以运行而被排除。良好的系统文档有助于把程序移植和转移到各种新的系统环境中。

（7）销售可能。软件文档便于潜在用户了解软件的功能、性能等各项指标，为他们选购符合自己需要的软件提供依据。

从某种意义上来说，良好的文档管理是优秀项目的重要标志，文档是软件开发规范的体现和指南，也是记录和管理知识的重要形式。文档与知识管理文档是固化的知识，是显性知识的重要载体，按规范要求生成一整套文档的过程，就是按照软件开发规范完成一个软件开发的过程。从历史经验来看，写作文档在项目开发的早期可能会使项目的进度比起不写文档要稍慢，但随着项目的进展，部门间配合越来越多、开发方对用户需求越来越细，开发者越来越需要知道系统设计的开发思路和用户的进一步功能需求，才能使自己的开发朝着正确的方向推进。一个明显的例子就是系统整合，或者某些环节是建立在其他环节完成的基础之上时，就更显现出文档交流的准确性和高效性。文档的管理虽然是一个非常烦琐的工作，但是长远来看，它不仅使项目的开发对单个主要人员的依赖减少，从而减少人员流动给项目带来的风险，更重要的是在项目进行到后 10%的时候起到拉动项目的作用。所以，在使用工程化的原理和方法来指导软件的开发和维护时，应当充分注意软件文档的编制和管理。

2．文档的归类
按照文档产生和使用的范围，软件文档大致可分为 3 类：开发文档；管理文档；产品文档。

（1）开发文档。开发文档是描述软件开发过程，包括软件需求、软件设计、软件测试、保证软件质量的一类文档，开发文档也包括软件的详细技术描述（程序逻辑、程序间相互关系、数据格式和存储等）。开发文档起到如下 5 种作用：它们是软件开发过程中包含的所有阶段之间的通信工具，它们记录生成软件需求、设计、编
码和测试的详细规定和说明；

它们描述开发小组的职责。通过规定软件、主题事项、文档编制、质量保证人员，以及包含在开发过程中任何其他事项的角色来定义做什么、如何做和何时做；它们用作检验点而允许管理者评定开发进度。如果开发文档丢失、不完整或过时，管理者将失去跟踪和控制软件项目的一个重要工具；它们形成了维护人员所要求的基本的软件支持文档。而这些支持文档可作为产品文档的一部分；它们记录软件开发的历史。基本的开发文档包括：可行性研究和项目任务书；需求规格说明；概要设计说明；详细设计说明，包括程序和数据规格说明；项目开发计划；软件集成和测试计划；质量保证计划、标准、进度；安全和测试信息。

（2）产品文档。产品文档规定关于软件产品的使用、维护、增强、转换和传输的信息。产品的文档起到如下 3 种作用：

• 为使用和运行软件产品的任何人规定培训和参考信息；
• 使得那些未参加开发本软件的程序员维护它；
• 促进软件产品的市场流通或提高可接受性。
  产品文档主要应用于下列类型的读者：
• 用户——他们利用软件输入数据、检索信息和解决问题；
  -运行者——他们在计算机系统上运行软件；
• 维护人员——他们维护、增强或变更软件。

产品文档包括如下内容：用于管理者的指南和资料，他们监督软件的使用；宣传资料通告软件产品的可用性并详细说明它的功能、运行环境等；一般信息对任何对其感兴趣的人描述软件产品。基本的产品文档实物包括：培训手册；参考手册和用户指南；软件支持手册；产品手册和信息广告；维护修改建议等。

（3）管理文档。这种文档建立在项目管理信息的基础上，从管理的角度规定涉及软件生存的信息。它包括：项目开发计划、测试计划；开发过程的每个阶段的进度和进度变更的记录；软件变更情况的记录；相对于开发的判定记录；开发人员职责定义；测试报告、开发进度月报；项目开发总结等。

另外，软件文档从用途上还可以分为内部文档和外部文档。其中，内部文档包括项目开发计划、需求分析、架构设计说明、详细设计说明、构件索引、构件成分说明、构件接口及调用说明、构件索引、构件接口及调用说明、类索引、类属性及方法说明、测试报告、测试统计报告、质量监督报告、源代码、文档分类版本索引和软件安装打包文件等。外部文档主要包括软件安装手册、软件操作手册、在线帮助、系统性能指标报告和系统操作索引等。

3．文档编制计划
软件开发的管理部门应该根据本单位承担的应用软件的专业领域和本单位的管理能力，制定一个对文档编制要求的实施规定。对于一个具体的应用软件项目，项目负责人应根据上述实施规定，确定一个文档编制计划。

文档计划可以是整个项目计划的一部分或是一个独立的文档。应该编写文档计划并把它分发给全体开发组成员，作为文档重要性的具体依据和管理部门文档工作责任的备忘录。编制计划的工作应及早开始，对计划的评审应贯穿项目的全过程。如同任何别的计划一样，文档计划指出未来的各项活动，当需要修改时必须加以修改。导致对计划作适当修改的常规评审应作为该项目工作的一部分，所有与该计划有关的人员都应得到文档计划。 文档计划一般包括以下几方面内容：

• 列出应编制文档的目录；
• 提示编制文档应参考的标准；
• 指定文档管理员；
• 提供编制文档所需要的条件，落实文档编写人员、所需经费及编制工具等；
• 明确保证文档质量的方法，为了确保文档内容的正确性、合理性，应采取一定的措施，如评审、鉴定等；
• 绘制进度表，以图表形式列出在软件生存期各阶段应产生的文档、编制人员、编制日期、完成日期、评审日期等。

还必须明确：要编制哪几种文档，详细程度如何；各文档的编制负责人和进度要求；审查/批准负责人和时间进度安排；在开发时期内各文档的维护、修改和管理的负责人，以及批准手续。文档计划还应确定该计划和文档的分发，有关的开发人员必须严格执行这个文档编制计划。文档计划还应该规定每个文档要达到的质量等级，以及为了达到期望的结果必须考虑哪些外部因素。

4．对文档质量的要求如果不重视文档编写工作，或是对文档编写工作的安排不当，就不可能得到高质量的
文档。质量差的文档一般会使读者难以理解，给使用者造成许多不便；会削弱对软件的管理（难以确认和评价开发工作的进展情况），提高软件成本（一些工作可能被迫返工）；造成误操作。一般而言，好的软件文档要求具备如下特征。

（1）针对性。文档编制前应分清读者对象。对不同的类型、不同层次的读者，决定如何满足适应他们的需要。
管理文档主要面向管理人员。用户文档主要面向用户。这两类文档不应像开发文档（面向开发人员）那样过多地使用软件的专业术语。

（2）精确性。文档的行文应当十分确切，不能出现多义性的描述。同一课题几个文档的内容应当是协调一致、没有矛盾的。

（3）清晰性。文档编写应力求简明，如有可能，配以适当的图表，以增强其清晰性。

（4）完整性。任何一个文档都应当是完整的、独立的，它应自成体系。例如，前言部分应做一般性介绍，正文给出中心内容，必要时还有附录，列出参考资料等。同一课题的几个文档之间可能有部分内容相同，这种重复是必要的。不要在文档中出现转引其他文档内容的情况。如，一些段落没有具体描述，用“见××文档××节”的方式。

（5）灵活性。各个不同软件项目，其规模和复杂程度有着许多实际差别，不能相同看待。应根据具体的软件开发项目，决定编制的文档种类。

13.3 软件需求管理

在软件开发的整个过程中，随着客观条件的变化和客户对软件或业务理解的加深，会产生很多新的软件需求，项目经理需要经常面对需求变更。需求管理的目的就是控制和维持事先约定，保证项目开发过程的一致性，使用户能够得到他们最终想要得到的软件产品。下面的内容主要涉及需求管理的两个方面：需求变更、需求跟踪。

13.3.1 需求变更

需求变更是指在软件开发过程中，用户确定软件需求之后，由于各种客观和主观条件的
变化，用户增加了新的需求或改变了原有需求。项目经理需要在整个项目生命周期中管理需求变更，将项目变更的影响降到最低。进行需求变更控制的主要依据是项目计划、变更请求和反映项目执行状况的绩效报告。为保证项目变更的规范性和项目的有效实施，通常软件开发机构会采取如下措施。

（1）项目启动阶段的变更预防。对于任何项目，变更都无可避免，也无从逃避，只能积极应对。这个应对应该是从项目启动的需求分析阶段就开始了。对一个需求分析做得很好的项目来说，基准文件定义的范围越详细、清晰，用户跟项目经理的分歧就越少。如果需求做得好，文档清晰且有客户签字，那么后期客户提出的变更超出了合同范围，就需要另外处理。

（2）项目实施阶段的需求变更。成功项目和失败项目的区别就在于项目的整个过程是否是可控的。项目经理应该树立一个理念 “需求变更是必然的、可控的、有益的”。项目实施阶段的变更控制需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。控制需求变更需要注意以下几点：

需求一定要与投入有联系，如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。所以，在项目的开始，无论是开发方还是出资方都要明确这一条：需求变，软件开发的投入也要变。需求的变更要经过出资者的认可，使需求的变更有成本的概念。这样项目实施涉及各方就能够慎重地对待需求的变更。小的需求变更也要经过正规的需求管理流程。在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。但正是由于这种观念才使需求逐渐变为不可控，最终导致项目的失败。还要注意沟通的技巧。实际情况是用户、开发者都认识到了上面的几点问题，但是由于需求的变更可能来自客户方，也可能来自开发方，因此，作为需求管理者，项目经理需要采用各种沟通技巧来使项目的各方受益。

13.3.2 需求跟踪

需求跟踪是指在软件需求管理的过程中定义需求变更流程，分析需求变更影响，控制变化的版本，维护需求变更记录,跟踪每项需求状态。

（1）确定需求变更控制过程。制定一个选择、分析和决策需求变更的标准过程，所有的需求变更都需遵循此过程。

（2）进行需求变更影响分析。评估每项需求变更，以确定它对项目计划安排和其他需求的影响，明确与变更相关的任务，并评估完成这些任务需要的工作量。通过这些分析将有助于需求变更控制部门做出更好的决策。

（3）建立需求基准版本和需求控制版本文档。确定需求基准，这是项目各方对需求达成一致认识时刻的一个快照，之后的需求变更遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。

（4）维护需求变更的历史记录。将需求变更情况写成文档，记录变更日期、原因、负责人、版本号等内容，及时通知到项目开发所涉及的人员。为了尽量减少困惑、冲突、误传，应指定专人来负责更新需求。

（5）跟踪每项需求的状态。可以把每一项需求的状态属性（如已推荐的，已通过的，已实施的，或已验证的）保存在数据库中，这样可以在任何时候得到每个状态类的需求数量。

13.4 软件开发的质量与风险

随着软件开发的规模越来越大，软件的质量问题越来越引起人们的关注。关于软件质量，IEEE 729—1983 标准有以下定义：

• 软件产品满足给定需求的特性及特征的总体的能力。
• 软件拥有所期望的各种属性组合的程度。
• 顾客或用户认为软件满足他们综合期望的程度。
• 软件组合特性在使用中，满足用户预期需求的程度。

从上述这个定义可以看到质量不是绝对的，它总是与给定的需求有关。因此，对软件质量的评价总是在将产品的实际情况与从给定的需求中推导出来的软件质量的特征和质量标准进行比较后得出来的。尽管如此，这里给出的软件质量还是一个模糊的概念且难以衡量。所以，软件质量管理的目的是建立对项目的软件产品质量的定量理解和实现特定的质量目标。

13.4.1 软件质量管理

项目质量管理包括保证项目能满足原先规定的各项要求所需要的过程，即“总体管理功能中决定质量方针、目标与责任的所有活动，并通过诸如质量规划、质量保证、质量控制、质量改进等手段在质量体系内加以实施”。软件质量管理着重于确定软件产品的质量目标、制订达到这些目标的计划，并监控及调整软件计划、软件工作产品、活动及质量目标以满足顾客及最终用户对高质量产品的需要及期望。

软件质量管理包括三个部分：质量计划——判断哪些质量标准与本项目相关，并决定应如何达到这些质量标准；质量保证——定期评估项目总体绩效，建立项目能达到相关质量标准的信心；质量控制——监测项目的总体结果，判断它们是否符合相关质量标准，并找出如何消除不合格绩效的方法。

1．软件质量计划
在正式进行软件开发前，需要制订一个软件质量计划，用于说明项目管理团队将如何实施其质量方针。用 ISO9000 的话来说，它应该说明项目质量体系，即：“用以实施质量管理的组织结构、责任、程序、过程和资源”。目前国际上有许多质量标准，较常用的是 ANSI/IEEE STOL730—1984，983—1986 标准。质量计划可以识别哪些质量标准适用于本项目，并确定如何满足这些标准的要求。在软件质量计划阶段应该完成如下活动：

• 对项目的软件质量活动做出计划。
• 对软件产品质量的可测量的目标及其优先级进行定义。
• 确定软件产品质量目标的实现过程是可量化和可管理的。
• 为管理软件产品的质量提供适当的资源和资金。
• 对实施和支持软件质量管理的人员进行实施和支持过程中所要求的培训。
• 对软件开发项目组和其他与软件项目有关的人员进行软件质量管理方面的培训。
• 按照已文档化的规程制订和维护项目的软件质量计划。
  项目的软件质量管理活动要以项目的软件质量计划为基础。
• 在整个软件生命周期，要确定、监控和更新软件产品的质量目标。

2．软件质量保证质量保证指为项目符合相关质量标准要求树立信心而在质量系统内部实施的各项有计划的系统活动。质量保证应贯穿于项目的始终，在事件驱动的基础上，对软件产品的质量进行测量、分析，并将分析结果与既定的质量标准相比较，以提供质量改进的依据。如果属于软件外包，还需要对软件产品的定量质量目标进行合理的分工，分派给项目交付软件产品的承包商。

3．软件质量控制质量控制指监视项目的具体结果，确定其是否符合相关的质量标准，并判断如何杜绝造成不合格结果的根源。软件质量的控制不单单是一个软件测试问题，评审、调试和测试是保证软件质量的重要手段。质量控制指监视项目的具体结果，确定其是否符合相关的质量标准，并判断如何杜绝造成不合格结果的根源。质量控制应贯穿于项目的始终。项目结果既包括产品结果（例如可交付成果）、也包括项目管理结果（例如成本与进度绩效）。质量控制通常由机构中的质量控制部或名称相似的部门实施，软件质量控制包括如下活动：对软件产品进行测试，并将测试结果用于软件质量管理活动的状态。高级管理者定期参与评审软件质量管理的活动。
软件项目负责人定期参与评审软件质量管理的活动。

软件质量保证评审小组负责评审软件的质量管理活动和工作产品，并填写相关报告。
（1）软件评审。软件评审并不是在软件开发完毕后进行评审，而是在软件开发的各个阶段都要进行评审。因为在软件开发的各个阶段都可能产生错误，如果这些错误不及时发现并纠正，会不断地扩大，最后可能导致开发的失败。

首先，要明确评审目标包括如下部分：

• 发现任何形式表现的软件功能、逻辑或实现方面的错误；
• 通过评审验证软件的需求；
• 保证软件按预先定义的标准表示；
• 已获得的软件是以统一的形式开发的；
• 使项目更容易管理。

其次，评审过程应包括：

• 召开评审会议。
• 会议结束时必须做出以下决策之一：① 接受该产品，不需作修改；② 由于错误严重，拒绝
  接受；③ 暂时接受该产品。
• 评审报告与记录；所提出的问题都要进行记录，在评审会结束前产生一个评审问题表，另外
• 必须完成评审简要报告。
• 还应该遵循基本的评审准则，如：对每个正式技术评审分配资源和时间进度表；
• 评审产品，而不是评审设计者，不能使设计者有任何压力；
• 会议不能脱离主题，应建立议事日程并维持它；
• 评审会不是为了解决问题，而是为了发现问题，限制争论与反驳；
• 对每个被评审的产品建立评审清单，以帮助评审人员思考；

（2）测试。软件测试是软件开发的一个重要环节，同时也是软件质量保证的一个重要环节。所谓测试就是用已知的输入在已知环境中动态地执行系统（或系统的构件）。测试一般包括单元测试、模块测试、集成测试和系统测试。如果测试结果与预期结果不一致，则很可能是发现了系统中的错误，测试过程中将产生下述基本文档。

• 测试计划：确定测试范围、方法和需要的资源等。
• 测试过程：详细描述与每个测试方案有关的测试步骤和数据（包括测试数据及预期的结果）。
• 测试结果：把每次测试运行的结果归入文档，如果运行出错，则应产生问题报告，并且必须经过调试解决所发现的问题。

13.4.2 项目风险管理

无论是系统集成还是软件开发，IT 公司经常面临着各种项目的实施和管理，面临着如何确定项目的投资价值、评估利益大小、分析不确定因素、决定投资回收时间等众多问题。并且，一个 IT 项目，无论其规模大小，必然会为被实施方（用户）在管理、业务经营等多方面带来变革，这就使 IT 项目必然具有高风险性的特点。尤其是近年来，IT 项目的广泛实施，一方面为众多的企业带来了管理、经营方面的革新，而另一方面，夭折、中断、失败的项目也不在少数。因此，如何在项目实施中有效地管理风险、控制风险，已经成为了项目实施成功的必要条件。

实际上，项目风险的管理不仅贯穿于整个项目过程，而且在项目事件发生之前风险的分析就已经开始。可以根据风险控制与项目事件发生的时间将风险管理划分为三个部分：事前控制——风险管理规划，事中控制——风险管理方法，事后控制——风险管理报告。

1．项目风险管理的概念
根据 PMBOK2000 版的定义，风险管理指对项目风险进行识别、分析、并采取应对措施的系统过程。它包括尽量扩大有利于项目目标事项发生的概率与后果，而尽量减小不利于项目目标事项发生的概率与后果。项目风险按是否有可确定性划分为：已知风险、可预知风险、不可预知风险。按风险管理的内容又可以划分为如下几种类型。

（1）内部技术风险：技术变化和创新是项目风险的重要来源之一。一般说来，项目中采用新技术或技术创新无疑是提高项目绩效的重要手段，但这样也会带来一些问题，许多新的技术未经证实或并未被充分掌握，则会影响项目的成功。还有，当人们出于竞争的需要，就会提高项目产品性能、质量方面的要求，而不切实际的要求也是项目风险的来源。

（2）内部非技术风险：公司的经营战略发生了变化相关的战略风险、涉及公司管理/ 项目管理人员管理水平等的管理风险，以及与范围变更有关的风险；没有按照要求的技术性能和质量水平完成任务的质量风险；没有在预算的时间范围内完成任务的进度风险；没有在预算的成本范围内完成任务的成本风险。

（3）外部法律风险：包括与项目相关的规章或标准的变化，如许可权、专利、合同失效、诉讼等。

（4）外部非法律风险：主要是指项目的政治、社会影响、经济环境的变化，组织中雇佣关系的变化，如公司并购、政府干预、货币变动、通货膨胀、税收、自然灾害等。这类风险对项目的影响和项目性质的关系较大。

2．风险管理的过程风险管理包括对项目风险识别、分析和应对的过程，从而将正面事件影响扩大到最大化和将负面事件影响减少到最小化。项目风险管理的主要过程包括：

• 风险管理规划，决定如何指导和规划项目的风险管理活动。
• 项目风险识别，找到哪些风险可能影响项目，并记录其特征。
• 定性风险分析，完成风险和环境的定性分析，并按其对项目目标的影响进行排序。定性风险
• 分析是决定具体风险的重要性并指导做出相关反应的一种方法。与风险相关的动作的时间相关性可能使风险的重要性加大。
• 定量风险分析，度量风险的可能性和后果，估量其对项目目标的潜在影响。
• 风险应对计划，创建过程和技术来为项目目标增进机会和减小威胁。
• 风险监督与控制，在项目生命周期中监视现存的风险、识别新的风险、执行缓解风险计划及评估其效果。

上述过程不仅彼此有交互作用，而且也同其他知识领域的过程有交互作用。一般来说，每个过程在项目中至少出现一次。

（1）风险识别。风险的识别就是识别整个项目过程中可能存在的风险事件。在项目开始、每个项目阶段中间、主要范围变更批准之前都要进行风险识别，实际上它在整个项目生命周期内都是一个连续的过程。要识别风险，首先应该了解在软件开发的各个阶段都有可能发生哪些风险（风险事件或风险来源）。表 13-1 列出软件开发各阶段可能发生的风险。

其中，初始阶段主要进行大部分需求分析、小部分设计（大部分业务建模和需求、少部分分析设计）；设计阶段主要进行大部分设计、小部分编码（大部分分析设计，部分实施及测试，开始考虑部署）；实施阶段进行大部分编码和测试，也涉及小部分设计（大部分实施及测试，部分部署）；收尾阶段完成安装及维护（大部分部署）。 除了考虑项目过程之外，软件企业在人力资源管理中也存在风险，如招聘失败、新政策引起员工不满、技术骨干突然离职等，这些事件会影响公司的正常运转，甚至会对公司造成致命的打击。特别是高新技术企业，由于对人的依赖更大，所以更需要识别人力资源方面的风险。

以上只是列举了常见的风险事件，对不同项目可能发生的风险事件不同，应该对具体项目识别出真正有可能发生在该项目的风险事件。一般是根据项目的性质，从潜在的事件及其产生的后果和潜在的后果及其产生的原因来检查风险。收集、整理项目可能的风险并充分征求各方意见就形成项目的风险列表，并对这些风险事件进行描述，如：可能性、可能后果范围、预计发生时间、发生频率等。风险识别的有效方法有很多，如：建立风险项目检查表、因果分析图、采访各种项目干系人等。

（2）风险分析。确定了项目的风险列表之后，接下来就可以进行风险分析了。风险分析的目的是确定每个风险对项目的影响大小，一般是对已经识别出来的项目风险进行量化估计，这里要注意三个概念。

• 风险得失值：它是指一旦风险发生可能对项目造成的影响大小，说明可能造成的损失。如果损失的大小不容易直接估计，可以将损失分解为更小部分再评估它们。风险得失值可用相对数值表示，建议将损失大小折算成对计划影响的时间表示。
• 风险概率：它是风险发生可能性的百分比表示，是一种主观判断。
• 风险值：风险值又风险曝光度或风险暴露，它是评估风险的重要参数，“风险值” “风概率” “风险影响”。如：某一风险概率是 25%，一旦发生会导致项目计划延长 4 周，因而，风险值 25% 4 周 1 周。 风险分析就是对以上识别出来的风险事件做风险影响分析。通过对风险及风险的相互作用的估算来评价项目可能结果的范围，从成本、进度及性能三个方面对风险进行评价，确定哪些风险事件或来源可以避免，哪些可以忽略不考虑（包括可以承受），哪些要采取应对措施。

（3）风险应对方法。完成了风险分析后，就已经确定了项目中存在的风险及它们发生的可能性和对项目的风险冲击，并可排出风险的优先级。此后就可以根据风险性质和项目对风险的承受能力制订相应的防范计划，即风险应对。制订风险应对策略主要考虑以下 4 个方面的因素：可规避性、可转移性、可缓解性、可接受性。风险的应对策略在某种程度上决定了采用什么样的项目开发方案。对于应“规避”或“转嫁”的风险在项目策略与计划时必须加以考虑。

项目中的风险永远不能全部消除，PMBOK2012 版提到 4 种应对方法：

• 规避。规避风险指改变项目计划，以排除风险或条件，或者保护项目目标，使其不受影响。虽然项目永远不可能排除所有的风险事件，但某些具体风险则是可以规避的。出现于项目早期的某些风险事件可以通过澄清要求、取得信息、改善沟通，或获取技术专长而获得解决。通过分析找出发生风险事件的原因，消除这些原因来避免一些特定的风险事件发生。例如，如何避免客户不满意？客户不满意有两种情况，一种情况是没有判断客户满意度的依据，即没有双方互相认可的客户验收标准，还有一种是开发方没有达到验收标准，即没有满足用户
  需求。不管是哪一种，开发方都有不可推卸的责任，只要做好以下环节就完全可以避免：业务建模阶段要让客户参与；需求阶段要多和客户沟通，了解客户真正的需求；目标系统的模型或 DEMO 系统要向客户演示，并得到反馈意见，如果反馈的意见和 DEMO 系统出入比较大时，一定要将修改后的 DEMO 系统再次向客户演示，直到双方都达成共识为止；要有双方认可的验收方案和验收标准；做好变更控制和配置管理等。

• 转移。转移风险指设法将风险的后果连同应对的责任转移到第三方身上。转移风险实际只是把风险管理责任推给另一方，而并非将其排除。该方法基本上需要向承担风险者支付风险费用。它包括利用保险、履约保证书、担保书和保证书。可以利用合同将具体风险的责任转嫁给另一方。如果项目的设计是稳定的，可以用固定总价合同把风险转嫁给卖方。虽然成本报销合同把较多的风险留给了顾客或赞助人，但如果项目中途发生变化时，它有助于降低成本。

• 减轻。通过降低风险事件发生的概率或得失量来减轻对项目的影响。提前采取行动以减小风险发生的概率或者减小其对项目所造成的影响，这样比在风险发生后亡羊补牢地进行补救要有效得多。减轻风险的成本应估算得当，要与风险发生的概率及其后果相称。项目预算中考虑应急储备金是另一种降低风险影响的方法。例如，经过风险识别发现，项目组的程序员对所需开发技术不熟。可以采用熟悉的技术来减轻项目在成本或进度方面的影响。也可以事先进行培训来减轻对项目的影响。

• 接受。接受风险造成的后果。采取此项技术表明项目团队已经决定不为处置某项风险而改变项目计划，或者表明他们无法找到任何其他应对良策。主动地接受风险包括制定一套万一发生风险时所准备实施的应变计划。例如，为了避免自然灾害造成的后果，在一个大的软件项目中考虑了异地备份中心。 确定风险的应对策略后，就可编制风险应对计划，它主要包括：已识别的风险及其描述、风险发生的概率、风险应对的责任人、风险对应策略及行动计划、应急计划等。

（4）风险应对计划。针对需要采取应对措施的风险事件，开发应对计划，一旦发生风险事件，就实施应对计划。应对计划常应用于项目进行期间发生的已识别风险，事先制订应变计划可大大降低风险发生时采取行动的成本。风险触发因素，例如缺失的中间里程碑，应确定其定义，并进行跟踪。如果风险的影响甚大，或者所选用的对策不见得有效时，就应制订一套后备权变计划。该项计划可包括留出一笔应急款项、制定其他备用方案、或者改变项目范围。最常见的接受风险的应对措施是预留应急储备，或者简称储备，包括为已知风险留出时间、资金、或者资源。为所接受的风险所预留的储备取决于按可接受风险水平计算所得影响的大小。

例如，在一个软件开发项目中，某开发人员有可能离职，离职后会对项目造成一定的影响，则应该对这个风险事件开发应对计划，过程参照如下：进行调研，确定流动原因。在项目开始前，把缓解这些流动原因的工作列入风险管理计划。项目开始时，作好一旦人员离开时便可执行的计划，以确保人员离开后项目仍能继续进行。
制定文档标准，并建立一种机制，保证文档及时产生。对所有工作进行细微详审，使更多人能够按计划进度完成自己的工作。对每个关键性技术人员培养后备人员。 当然该应对计划需要花费一定的成本，在考虑风险成本之后，决定是否采用上述策略。

（5）风险监控。制定了风险应对计划后，风险并非不存在，在项目推进过程中还可能会增大或者衰退。因此，在项目执行过程中，需要时刻监督风险的发展与变化情况，并确定随着某些风险的消失而带来的新的风险。风险监控包括两个层面的工作：其一是跟踪已识别风险的发展变化情况，包括在整个项目周期内，风险产生的条件和导致的后果变化，衡量风险减缓计划需求。其二是根据风险的变化情况及时调整风险应对计划，并对已发生的风险及其产生的遗留风险和新增风险及时识别、分析，并采取适当的应对措施。对于已发生过和已解决的风险也应及时从风险监控列表调整出去。

最有效的风险监控工具之一就是“前 10 个风险列表”，它是一种简便易行的风险监控活动，是按“风险值”大小将项目的前 10 个风险作为控制对象，密切监控项目的前 10 个风险。每次风险检查后，形成新的“前 10 个风险列表”。

13.5 人力资源管理
软件项目人力资源管理包括为最有效地使用参与项目人员所需的各项过程，一般包括组织规划、人员招募和团队建设三个主要过程。

1．组织规划组织规划用于确定、记录并分派项目角色、职责和请示汇报关系。角色、职责和请示汇报关系可以分派给个人或者集体。这些个人与集体可以是项目实施组织的一部分，也可以来自组织外部，通过人员招聘、借用等方式获得。实施组织往往与某个具体职能部门相关，例如，工程部门、销售部门或者财务部门，通过与职能经理协商、谈判等方式获得。

软件项目组织一般由担当各种角色的人员所组成。每位成员扮演一个或多个角色，常见的一些项目角色包括：策划师、数据库管理员、设计师、操作/支持工程师、程序员、项目经理、项目赞助者、质量保证工程师、需求分析师、用户、测试人员等。组织规划取决于可供选择的人员、项目的需求及组织的需求，组织的具体形式可以有三种方案：垂直方案、水平方案和混合方案。以垂直方案组织的团队由多面手组成，每个成员都充当多重角色。以水平方案组织的团队由专家组成，每个成员充当一到两个角色。以混合方案组织的团队既包括
多面手，又包括专家。

如果可供选择的人员中大多数人员是多面手，则往往需要采用垂直方案；同样，如果大多数人员是专家，则采用水平方案。如果正引入一些新人，即使这些人员都是合同工，则仍然需要优先考虑项目和组织。本节描述了形成团队组织的垂直、水平和混合方案，并指出了它们各自的优缺点。

（1）垂直团队组织。垂直团队由多面手组成。如，功能模块分配给了个人或小组，然后由他们从头至尾地实现该功能模块。其优点在于，以单个功能模块为基础实现平滑的端到端开发；开发人员能够掌握更广泛的技能。而缺点也很明显：多面手通常是一些要价很高并且很难找到的顾问。多面手通常不具备快速解决具体问题所需的特定技术专长。主题专家可能不得不和若干开发人员小组一起工作，从而增加了他们的负担。所有多面手水平各不相同。

（2）水平团队组织。水平团队由专家组成。此类团队同时处理多个功能模块，每个成员都从事功能模块中有关其自身的方面。其优点在于能高质量地完成项目各个方面（需求、设计等）的工作；一些外部小组，如用户或操作人员，只需要与了解他们确切要求的一小部分专家进行交互。其缺点在于：专家们通常无法意识到其他专业的重要性，导致项目的各方面之间缺乏联系；由于专家们的优先权、看法和需求互不相同，所以项目管理比较困难。

（3）混合团队组织。混合团队由专家和多面手共同组成。多面手继续操作一个功能模块的整个开发过程，支持并处理多个功能模块，使各部分的专家们一起工作。它可能拥有前两种方案的优点：外部小组只需要与一小部分专家进行交互；专家们可集中精力从事他们所擅长的工作；各个功能模块的实现都保持一致。但是它可能拥有前两种方案的缺点：尽管这应该由多面手来调节，专家们仍然不能认识到其他专家的工作并且无法很好地协作；多面手较难找到，故而，项目管理仍然较难。

因而，要综合考虑、确定团队组织方案。在方案确定后，合理配备人员是成功完成软件开发项目的切实保证。所谓合理配备人员应包括按不同阶段适时运用人员，恰当掌握用人标准。一般来说，软件项目不同阶段、不同层次技术人员的参与情况是不一样的。如人员配置不当，很容易造成人力资源的浪费，并延误工期。特别是采用恒定人员配备方案时，在项目的开始和最后都会出现人力过剩，而在中期又会出现人力不足的情况。 在多数项目中，组织规划大都是作为项目早期阶段的一部分进行的。但在项目的整个过程中都应对其结果定期检查，以保证其继续适用性。如果当初的组织规划已不再适用，就应该及时对其进行修改。

2．人员招募人员招募指获取分派到项目上、并在那里工作所需的人力资源（个人或集体）。在多数环境中，很可能无法到“最佳”资源，因此项目管理团队必须注意保证所物色到的人力资源符合项目要求。通过前一阶段完成的成果——人员配备管理计划，来进行实际的人员招募。首先必须了解组织可用/备用人员库的情况。按照组织规划确定的人力资源需求情况，充分考虑可调配人员的特点。要考虑的问题主要有：

• 以往经验——这些个人或集体以前是否从事过类似或者相关的工作？工作表现如何？
• 个人兴趣——这些个人或集体对本项目的工作感兴趣吗？
• 能否得到——最理想的个人或集体人选能在规定期限内招募到手吗？
• 胜任与熟练程度——需要何种能力及何种水平？

而后，通过谈判、事先分派和采购等方式获取项目人员，以保证项目在规定期限内获得足以胜任的工作人员。其中谈判对象可能是实施组织的职能经理，也可能分到其他项目团队，以争取稀缺或特殊人才得到合理分派。在某些情况下，人员可能事先被分派到项目上。这种情况往往发生在：项目是方案竞争的结果，而且事先已许诺具体人员指派是获胜方案的组成部分，或者项目为内部服务项目，人员分派已在项目章程中明确规定。在实施组织缺乏完成项目所需的内部人才时，就需要动用采购手段。项目经理是团队组织的核心，其综合素质直接影响项目的成败。一般要求项目经理具备如下能力：

（1）领导能力。项目经理必须具备高超的领导才能和强烈的科技意识和较强的业务处理能力。领导能力，简单地说，通过项目团队来达到目标。

首先，项目经理应懂得如何授权和分配职责，采取参与和顾问式的领导方式，发挥导向和教练作用，让成员在职责范围内充分发挥能动性，自主地完成项目工作；

其次，项目经理应善于激励。由于项目经理通常没有太大的权力对成员进行物质方面的激励，因此，非物质激励方式就特别重要。例如，借助项目的唯一性，给项目成员接受挑战的机会往往可以对优秀的项目成员起到极大的激励作用；另外，对项目成员的工作成绩要及时表示认可。及时是非常重要的，并且最好是当众表扬，例如，在上级领导或客户面前对项目团队或具体成员做出正面的评价。

第三，项目经理应该为成员树立榜样，表现出积极的心态，成为团队的典范和信心的源泉。只有身先士卒，各方面以身作则，才能得到广大开发人员的认可和信任，才能树立较高的威信。

第四，项目经理应该能够果断抉择，负责人的重要任务是决策，特别是有多种选择的情况下，一个正确的选择往往事半功倍。

（2）沟通技巧。有效的沟通是项目顺利进行的保证，沟通及时、集思广益、步调一致，才能取得项目最终的成功。项目过程中，项目经理需要通过多种渠道保持与团队及分包商、客户方、公司上级的定期交流沟通，及时了解项目的进程、存在的问题及获得有益的建议。沟通的方式可以是口头的或书面的，如：面谈、电话、邮件、会议等。在沟通过程中，项目经理应善于提问，并做到有效地聆听，能经常站在对方的角度思考问题。

（3）人际交往能力。良好的人际关系有助于项目的协调，避免生硬的操作方式。项目经理必须积极对外联络，充分利用外部资源，例如其他部门做过类似项目者，可以向他们取经甚至直接获得源码。这对一个项目争取时间，避免重复工作很重要项目协调是随时需要的，主要来自于项目内部及客户，可能是资源的配置问题，也可能是项目范围的调整等。人际交往需要从一点一滴做起，而且往往发生在项目工作之外，项目经理需要采取主动、热情的姿态。

（4）应付压力的能力。项目的特点决定了项目工作过程存在一定的不可预见性，项目经理需要做好随时面对压力甚至是冲突的准备。一旦面临压力或冲突，最重要的是保持冷静，避免使项目陷入困境。项目经理要以乐于解决问题的姿态出现在团队及上级或客户面前。

（5）培养员工的能力。出色的项目经理重视对项目成员的培养，通过项目过程使小组每个成员都能发挥才能并提升员工的能力，促进员工的自我发展。项目经理要帮助成员明晰自己的职业与技能发展方向，分配合适的工作任务，鼓励学习和相互交流，让项目小组成员具有很强的成就感。

（6）时间管理技能。当需要在同一时段处理两项以上的任务时，时间管理就是必要的。而项目经理往往需要同时面对数项甚至十几项任务，可见有效的时间管理是极为重要的。项目经理不仅需要管理好自己的时间，还需要与相关部门及人员订立时间使用协议，尽量减少非预期的时间占用。

合格的项目经理具有敏锐的洞察力，能瞄准目标，实事求是，精心组织，坚决果断，灵活应变，享有信誉；善于制订计划，解决问题，沟通信息；具有良好的市场意识和交际能力。当然同时满足这些条件比较困难，但是他应该具有实现这些条件的素质，并注重经验的积累、素质的提高和能力的培养。

3．团队建设项目团队的建设既包括提高项目干系人作为个人做出贡献的能力，也包括提高项目团队作为集体发挥作用的能力。个人的培养（管理能力与技术水平）是团队建设的基础，而团队建设则是项目实现其目标的关键。

因为软件开发是一项长期艰苦的工作，一个团结、协作的团体才能在规定的时间内完成一个质量上乘的软件项目。团队中的每个人必须积极融入整个集体中，不能互相推诿，更不能互相埋怨和指责，正确的态度是大家在充分信任的基础上团结协作、互相帮助、主动承担任务，利用集体的智慧获得成功。整个团队就是一部机器，只有每一个齿轮都能正常运作，才能生产出优质的产品。

人是最宝贵的资源，在软件项目中，应该为软件开发人员和管理人员等各类项目人员营造一个和谐、良好的工作氛围，为开发人员创造出一个人尽其才的环境也是项目成功的重要环节，让他们能得心应手地施展自己的才华，特别在工作安排上要煞费苦心，针对每个人不同的特长，根据项目的具体环境和条件把人员合理地安排在恰当的岗位上。使他们能感到项目成功的把握并有积极的工作心态，将项目作为自己事业的一部分，确保项目队伍的稳定性和连续性。在项目结束之际，项目团队的各个成员是否感到他们从自己的经历中学到了一些知识、是否喜欢为这次项目工作，以及是否希望参与组织的下一个项目都是非常重要的。

对于软件项目团队的成长规律，有人归纳出了以下 4 个阶段：
（1）形成阶段。形成阶段促使个体成员转变为团队成员。每个人在这一阶段都有许多疑问：我们的目的是什么？其他团队成员的技术、人品怎么样？每个人都急于知道他们能否与其他成员合得来，自己能否被接受。

为使项目团队明确方向，项目经理一定要向团队说明项目目标，并设想出项目成功的美好前景及成功所产生的益处；公布项目的工作范围、质量标准、预算及进度计划的标准和限制。项目经理在这一阶段还要进行组织构建工作，包括确立团队工作的初始操作规程，规范沟通渠道、审批及文件记录工作。所以在这一阶段，对于项目成员采取的激励方式主要为预期激励、信息激励和参与激励。

（2）震荡阶段。这一阶段，成员们开始着手执行分配到的任务，缓慢地推进工作。现实也许会与个人当初的设想不一致。例如，任务比预计的更繁重或更困难；成本或进度计划的限制可能比预计的更紧张；成员们越来越不满意项目经理的指导或命令。 震荡阶段的特点是人们有挫折、愤怨或者对立的情绪。这一阶段士气很低，成员可能会抵制形成团队，因为他们要表达与团队联合相对立的个性。 因此在这一阶段，项目经理要做导向工作，致力于解决矛盾，决不能希望通过压制来使其自行消失。这时，对于项目成员采取的激励方式主要是参与激励、责任激励和信息激励。

（3）正规阶段。经受了震荡阶段的考验，项目团队就进入了发展的正规阶段。项目团队逐渐接受了现有的工作环境，团队的凝聚力开始形成。这一阶段，随着成员之间开始相互信任，团队内大量地交流信息、观点和感情，合作意识增强，团队成员互相交换看法，并感觉到他们可以自由地、建设性地表达他们的情绪及意见。在正规阶段，项目经理采取的激励方式除参与激励外，还有两个重要方式：一是发掘每个成员的自我成就感和责任意识，引导员工进行自我激励；二是尽可能地多创造团队成员之间互相沟通、相互学习的环境，以及从项目外部聘请专家讲解与项目有关的新知识、新技术，给员工充分的知识激励。

（4）表现阶段。团队成长的最后阶段是表现阶段。这时，项目团队积极工作，急于实现项目目标。这一阶段的工作绩效很高，团队有集体感和荣誉感，信心十足。团队能感觉到被高度授权，如果出现技术难题，就由适当的团队成员组成临时攻关小组，解决问题后再将相关知识或技巧在团队内部快速共享。

这一阶段，项目经理需要特别关注预算、进度计划、工作范围及计划方面的项目业绩。如果实际进程落后于计划进程，项目经理就需要协助支持修正行动的制定与执行。这一阶段激励的主要方式是危机激励、目标激励和知识激励。需要强调的是，对于信息系统建设人才，要更多地引导他们进行自我激励和知识激励。当然，足够的物质激励是不言而喻的，它从始至终都是最有效的激励。 激励的结果是使参与信息系统的所有成员组成一个富有成效的项目团队，这种团队具有如下特点：

• 能清晰地理解项目的目标；
• 每位成员的角色和职责有明确的期望；
• 以项目的目标为行为的导向；
• 项目成员之间高度信任、高度合作互助。总之，科学地进行团队建设有助于按期、保质、高效、在预算内完成软件项目。

13.6 软件的运行与评价

软件的运行与评价是指软件开发结束后交付用户使用，用户在实际使用中对软件是否符合开发时制定的一系列评价标准进行打分，看是否满足了用户的使用要求。通常，关注如下几点:

（1）软件的稳定性和可靠性评价。软件的稳定性，指软件在一个运行周期内、在一定的压力条件下，软件的出错几率、性能劣化趋势等，并观察其运行环境内的应用服务器、数据库服务器等系统的稳定性。从用户角度看,软件在使用过程中如果出现系统故障、系统反应速度慢等就表明软件本身的可靠性需要提高。通常在软件交付用户使用前都要进行大量的系统功能测试和用户可靠性测试，如果测试工作做得很好，后期运行使用时这方面的问题会减少。

（2）软件是否满足了用户的需求。满足用户的需求是软件开发的基本要求。系统交付使用前，需要用户对系统提供的需求进行评价。用户评价的标准就是归档的需求文档，用户可以根据文档的要求逐个检查系统是否提供了相应的功能。只有软件满足了用户需求，用户才会同意交付使用。

（3）软件实施给用户带来的好处。这是用户需要软件开发的原因。通常体现为价值指标,如节省多少人工成本，节省业务流程时间，减小数据质量出错率等。软件交付用户使用后一段时间，用户可以测量相应的指标是否满足了之前设定的目标，对新系统给予评价。

13.7 软件过程改进

处于激烈市场竞争中的软件开发机构若想在预定的期限内用有限的资金，满足不断增长的软件产品的需求，就必须不断加强软件开发过程的管理，对软件开发的所有环节施加有效的管理和控制，将软件的开发逐渐转变成为一种工业化的生产过程。

软件过程改进（Software Process Improvement，SPI）用于帮助软件企业对其软件生产过程进行计划、过程诊断、改进方案的制订及实施等工作。它的实施对象是软件企业的软件过程，即软件产品的生产过程，也包括配置管理、软件维护等辅助过程。目前，使用最多的软件过程改进模型包括 CMM、CMMI、ISO9000 和 ITIL 等系列标准。

1．CMM
W-CMM（软件能力成熟度模型）为软件企业的过程能力提供了一个阶梯式的进化框架，阶梯共有五级。第一级实际上是一个起点，任何准备按 CMM 体系进化的企业都自然处于这个起点上，并通过这个起点向第二级迈进。除第一级外，每一级都设定了一组目标，如果达到了这组目标，则表明达到了这个成熟级别，可以向下一个级别迈进。 CMM 体系不主张跨越级别的进化，因为从第二级起，每一个低的级别实现均是高的级别实现的基础。

（1）初始级。初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许，有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行没有政策、资源等方面的保证时，那么它仍然被视为初始级。

（2）可重复级。根据多年的经验和教训，人们总结出软件开发的首要问题不是技术问题而是管理问题。因此，第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，一个可重复的过程则能逐渐进化和成熟。第二级的管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面。其中项目管理分为计划过程和跟踪与监控过程两个过程。实施这些过程，从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。

（3）定义级。在第二级仅定义了管理的基本过程，而没有定义执行的步骤标准。在第三级则要求制定企业范围的工程化标准，而且无论是管理还是工程开发都需要一套文档化的标准，并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程，剪裁出与项目适宜的过程，并执行这些过程。过程的剪裁不是随意的，在使用前需经过企业有关人员的批准。

（4）管理级。第四级的管理是量化的管理。所有过程需建立相应的度量方式，所有产品的质量（包括工作产品和提交给用户的产品）需有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品。量化控制将使软件开发真正变成一种标准的工业生产活动。

（5）优化级。第五级的目标是达到一个持续改善的境界。所谓持续改善是指可根据过程执行的反馈信息来改善下一步的执行过程，即优化执行步骤。如果一个企业达到了这一级，那么表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。

2．CMMI
CMMI（Capability MaturityModel Integration），即能力成熟度模型集成。CMMI 是 CMM 模型的最新版本。CMMI 与 CMM 最大的不同点在于：CMMISM-SE/SW/IPPD/SS 1.1 版本有四个集成成分，即：系统工程（SE）和软件工程（SW）是基本的科目，对于有些组织还可以应用集成产品和过程开发方面（IPPD）的内容，如果涉及供应商外包管理可以相应地应用SS（Supplier Sourcing）部分。

CMMI 有两种表示方法，一种是和软件 CMM 一样的阶段式表现方法，另一种是连续式的表现方法。这两种表现方法的区别是：阶段式表现方法仍然把 CMMI 中的若干个过程区域分成了 5 个成熟度级别，帮助实施 CMMI 的组织建议一条比较容易实现的过程改进发展道路。而连续式表现方法则通过将 CMMI 中过程区域分为四大类：过程管理、项目管理、工程及支持。对于每个大类中的过程区域，又进一步分为基本的和高级的。这样，在按照连续式表示方法实施 CMMI 的时候，一个组织可以把项目管理或者其他某类的实践一直做到最好，而其他方面的过程区域可以完全不必考虑。

3．ISO 9000
国内软件公司采用的 ISO 9000 系列质量体系认证通常有 ISO 9001 的 1994 年版和2000 年版。ISO 9001 和 CMM 非常相似的是，两者都共同着眼于质量和过程管理，而且它们都是基于戴明博士的全面质量管理 TQM 产生的，因此不存在任何矛盾的地方。但是，它们的基础是不同的：ISO9001（ISO9000 标准系列中关于软件开发和维护的部分）确定一个质量体系的最少需求，而 CMM 强调持续过程改进。在 1994 年版的 ISO 9001 中，CMM 2 级的 6 个关键过程区域所涉及的部分，基本上都比较明确地作出了要求；而 CMM 3 级的7 个关键过程区域中所涉及的内容大多数都提到了，但做出的要求不是非常详细。很多实施了 94 版 ISO9000 的企业在了解了 SW-CMM 以后，普遍反映 CMM 比 ISO 的要求明确、详细得多。如果 94 版 ISO 实施的效果很好的话，实施 CMM 2 级工作量是可以减少很多的。而 2000 版的 ISO 则和 CMM 有更多的直接对应的关系，甚至是大量 CMM 4 级和 5 级的要求。

4．ITIL
ITIL（信息技术基础设施库）是英国政府中央计算机与电信管理中心（CCTA）在 20 世纪 90 年代初期发布的一套 IT 服务管理最佳实践指南。在此之后，CCTA 又在 HP、IBM、BMC、CA 和 Peregrine 等主流 IT 资源管理软件厂商近年来所做出的一系列实践和探索的基础之上，总结了 IT 服务的最佳实践经验，形成了一系列基于流程的方法，用以规范 IT 服务的水平，并在 2000 年至 2003 年期间推出新的 ITIL V2.0 版本，于 2007 年推出 V3.0 版本。

ITIL 为企业的 IT 服务管理实践提供了一个客观、严谨、可量化的标准和规范，企业的IT 部门和最终用户可以根据自己的能力和需求定义自己所要求的不同服务水平，参考 ITIL 来规划和制定其 IT 基础架构及服务管理，从而确保 IT 服务管理能为企业的业务运作提供更好的支持。对企业来说，实施 ITIL 的最大意义在于把 IT 与业务紧密地结合起来，从而让企业的 IT 投资回报最大化。