第十三章 开发管理

项目管理是指在项目环境中运用专门的知识、技能、工具和方法，使项目能够实现或超过项目干系人的需要和期望。一般的项目管理分为范围管理、时间管理、费用管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理和整体管理9个知识领域。对于软件的开发管理来讲，软件范围管理、软件进度管理、软件成本管理、软件配置管理、软件质量管理、软件风险管理、开发人员管理7个方面的管理尤为重要。

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

项目管理首先要考虑三个约束条件：项目范围、时间进度、成本预算。

13.1.1 项目范围管理

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

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

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

• 对造成范围变更的因素施加影响，以确保这些变更得到一致认可。
• 确定范围变更是否已经发生
• 当范围变更发生时对实际变更进行管理。

13.1.2 项目成本管理

是保证在批准预算内完成项目所需要的过程。包括资源计划编制、成本估算、成本预算、成本控制3个主要部分内容。资源计划编制是确定为完成项目个活动需要什么资源和这些资源的数量。资源计划与成本估算是紧密相关的。成本估算是计算出完成一个项目的个活动所需个资源成本的近似值。当一个项目按合同进行时，应却分成本估算和定价这两个不同意义的词。成本估算所涉及的是对可能数量结果的估算——执行组织为提供产品和服务的花费是多少；而定价是一个商业决策——执行组织为提供的含片或服务索取多少费用。成本估算包括确认和考虑各种不同的成本估算替代方案。

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

成本控制包括以下方面：

• 监测成本执行情况，以寻找出并掌握计划的偏差及原因
• 确保所有变更都准确的记录在成本基准计划中
• 防止把不正确、不适宜或未批准的变更纳入成本基准标准
• 将批准的变更通知项目干系人
• 采取措施，把预计的成本控制在可接受的范围内。

13.1.3 项目时间管理

时间管理包括项目按时完成所需的各个过程。包括活动定义、活动排序、活动历时估算、进度计划编制、进度控制5个部分内容。

活动定义是对WBS中规定的可交付成果或半成品的产生所必须进行的具体活动进行定义，并形成文档。

活动排序是确定各活动之间的依赖关系，并形成文档。

项目活动历时估算是根据项目范围和资源的相关信息为进度表设定历时输入的过程。

制定进度计划要决定项目活动的开始和结束日期。若开始和结束日期是不现实的，项目就不可能按计划完成。

进度控制涉及的是：

• 对造成进度变更的因素施加影响，以确保这些变更得到一致认可。
• 确定进度变更是否已经发生
• 当变更发生时对实际变更进行管理。

13.2 配置管理与文档管理

13.2.1 软件配置管理的概念

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

• 配置标识：产品的结构、产品的构件及其类型，为其分配唯一的标识符，并以某种形式提供对它们的存取。
• 版本控制：通过建立产品极限，控制软件产品的发布和在整个软件生命周期中对软件产品的修改。
• 状态统计：记录并报告构件和修改请求的状态，并收集关于产品构件的重要统计信息。
• 审计和审查：确认产品的完整性并维护构件间的一致性，即确保产品是一个严格定义的构件集合。
• 生产：对产品的生产进行优化管理。它将解决最新发布的产品应由那些版本的文件和工具来生成的问题。
• 过程管理：确保软件组织的规程、方针和软件周期得意正确贯彻执行，它将解决要交付给用户的产品是否经过测试和质量检查的问题。
• 小组协作：控制开发同一产品的多个开发人员的协作。

在另一标准ISO中，对软件配置管理系统做了如下要求：

• 唯一标识每个软件项的版本
• 标识共同构成一个完整产品的特定版本的每一软件项的版本；
• 控制由两个或多个独立工作的人员同时对一个给定软件项的更新
• 按要求在一个或多个位置对复杂产品的更新进行协调
• 标识并跟踪所有的措施和更改；这些措施和更改是从开始直到放行期间，由于更改请求或问题引起的。

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

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

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

1. Rational ClearCase

可以用于Windows和Unix开发环境。主要应用于复杂的产品发放、分布式团队合作、并行的开发和维护任务，支持Client Server的网络结构，主要功能有：

1. 版本控制
2. 工作控件管理
3. 建立管理
4. 过程控制

2. Merant PVCS

1. PVCSVersionManager：能完整、详细的记录开发过程中出现的变更和修改，可快速得到系统中任何文件的各个版本，并使修订版本自动升级。
2. PVCSConfigurationBuilder：提供可靠的自动重构过程
3. PVCSTracker：为整个开发过程中确定个追踪软件的每一变更的要求
4. PVCSNotify：将软件状态的变更通过EMail通知组织机构中的其他成员
5. PVCSReporter：为GUI界面环境提供一个客户报表工具，容易的生成和存储多个项目的报表
6. PVCSProductionGateway：提供了局域网间与大型机MVC系统双向同步互联
7. PVCSDeveloper’sToolkit：提供应用程序开发接口API
8. PVCSRequisitePro：提供了一个独特的界面和需求数据库。=，从而可直接跟踪最终用户的项目需求及需求变更。

3. Mirosoft VSS，CVS

提供了基本的认证安全和版本控制机制，包括入库、出库、分支、标定等功能。是一种源代码控制系统，带有专业的文档、代码管理库。

13.2.3 软件文档管理

1. 软件文档的作用

1. 管理依据。
2. 任务之间联系的凭证
3. 质量保证
4. 培训和参考
5. 软件维护支持
6. 历史档案
7. 销售可能

2. 文档的归类

1. 开发文档。描述软件开发过程，包括软件需求、软件设计、软件测试、保证软件质量的一类文档。也包括软件的详细技术描述（程序逻辑、程序间相互关系、数据格式和存储等）。开发文档起到如下5种作用：

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

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

• 为使用和运行软件产品的任何人规定培训和参考信息
• 使得那些未参加开发本软件的程序员维护它
• 促进软件产品的市场流通或提高可接受性
  产品文档主要应用于下列类型的读者：
• 用户
• 运行着
• 维护者
  产品文档包括如下内容：用于管理者的指南和资料，他们监督软件的使用；宣传资料通过软件的可用性并详细说明它的功能、运行环境等；一般信息对任何对其感兴趣的人描述软件产品。基本的产品文档实物包括：培训手册；参考手册和用户指南；软件支持手册；产品手册和信息广告；维护修改建议等。

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 软件开发的质量和风险

关于软件质量，IEEE729-1983有如下定义：

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

软件质量管理的目的是建立对项目的软件产品质量的定量理解和实现特定的质量目标。

13.4.1 软件质量管理

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

1. 软件质量计划

在正式进行软件开发前，需要制定一个软件质量计划，用于说明项目管理团队奖如何实施其质量方针。在该阶段应该完成以下活动：

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

2. 软件质量保证

指为项目符合相关质量标准要求树立信心而在质量系统内部实施的各项有计划的系统活动。

3. 软件质量控制

指监视项目的具体结果，确定其是否符合相关的质量标准，并判断如何杜绝造成不合格结果的根源。应贯穿于项目的始终。质量管理包括如下活动；

• 对软件产品进行测试，并将测试结果用于软件质量管理活动的状态。
• 高级管理者定期参与评审软件质量管理的活动
• 软件项目负责人定期参与评审软件质量管理的活动
• 软件质量保证评审小组负责评审软件的质量管理活动个工作产品，并填写相关报告。

1. 软件评审。

不是在软件开发完毕后进行评审，而是在软件开发的各个阶段都要进行评审。首先，要明确评审目标包括如下部分：

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

其次，评审过程应包括：

• 召开评审会议
• 会议结束时必须做出以下决策之一：1接受该产品，不需做修改；2由于错误严重，拒绝接受；3暂时接受该产品
• 评审报告与记录：所提出的问题都要进行记录，在评审会结束前产生一个评审问题表，另外必须完成评审简要报告。

还应该遵循基本的评审准则，如：

• 对每个正式技术评审分配资源和时间进度表
• 评审产品，而不是评审设计者，不能使设计者有任何压力；
• 会议不能脱离主题，应建立议事日程并维持它
• 评审会不是为了解决问题，而是为了发现问题，限制争论与反驳
• 对每个被评审的产品建立评审清单，以帮助评审人员思考。

2. 测试。

测试过程中将产生下述基本文档

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

13.4.2 项目风险管理

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

1. 项目风险管理的概念

是指对象项目风险进行识别、分析、并蔡旭应对测试的系统过程。包括尽量扩大有利于项目目标事项发生的概率与后果，而尽量减少不利于项目目标事项发生的概率与后果

项目风险按是否有可确定性划分为：已知风险、可预知风险、不可预知风险。按风险管理的内容又可以划分为如下几种类型：

1. 内部技术风险。采用新技术或技术创新
2. 内部非技术风险。公司经营战略发生的变化，其他项目相关的内容发生变化。
3. 外部法律风险
4. 外部非法律风险

2. 风险管理的过程

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

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

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

1. 风险识别

就是识别整个项目过程中可能存在的风险事件。一般是根据项目的性质，从潜在的事件及产生的后果和潜在的后果和产生的原因来检查风险。收集、整理项目可能的风险并充分征求各方意见就形成项目的风险列表，并对这些风险事件进行描述。

2. 风险分析

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

• 风险得失值：是指一旦风险发生可能对项目造成的影响大小，说明可能造成的损失。如果损失的大小不容易直接估计，可以将损失分解为更小部分再评估它们。风险得失值可以用相对数值表示。
• 风险概率。风险发生可能性的百分比表示，是一种主观判断
• 风险值：又称风险曝光度或风险暴露度，是评估风险的重要参数。“风险值”=“风险概率”*“风险影响”。

风险分析就是对以上识别出来的风险事件做风险影响分析。

3. 风险应对方法

制定风险应对策略主要考虑一下4个方面的因素：可规避性、可转移性、可缓解性、可接受性。4种应对方法如下：

• 规避。规避风险是指改变项目计划，以排除风险或条件，或者包含项目目标，使其不受影响。
• 转移。是指设法将风险的后果连同应对的责任转移到第三方身上。
• 减轻。通过降低风险事件发生概率或得失率来减轻对项目的影响。
• 接受。接受风险造成的结果。

确定风险的应对策略后，就可变写风险应对计划，主要包括：已识别的风险及其描述、风险发生的概率、风险应对的责任人、风险对应策略及行动计划、应急计划等。

4. 风险应对计划

针对需要采取应对措施的风险事件，开发应对计划，一旦发生风险事件，就实施应对计划。应对计划常应用于项目运行期间发生的已识别风险，事先制定应变计划可大大降低风险发生时采取行动的成本。

5. 风险监控

风险监控包括两个层面的工作：其一是跟踪已识别风险的发展变化情况，包括在整个项目周期内，风险产生的条件和导致的后果变化，衡量风险减缓计划需求。其二是根据风险的变化情况及时调整风险应对计划，并对已发生的风险及其产生的遗留风险和新增风险及时识别、分析，并蔡旭适当的应对措施。

13.5 人力资源管理

1. 组织规划

用于确定、记录并分派项目角色、职责和请示汇报关系。角色、职责和请示汇报关系可以分派给个人或集体

1. 垂直团队组织。由多面手组成。优点在于，以单个功能模块为基础实现平滑的端到端开发；开发人员能够掌握更广泛的技能。缺点：

• 多面手通常是一些要加很高并且很难找到的顾问
• 多面手通常不具备快速解决具体问题所需的特定技术专长
• 主体专家可能不得不和若干开发人员小组一起工作，从而增加了他们的负担。
• 所有多面手水平各不相同

2. 水平团队组织。由专家组成。此类团队同事处理多个功能模块，每个成员都从事功能模块中有关自身的方面。优点在于能够高质量的完成项目各个方面的工作。缺点在于：专家们通常无法意识到其他专业的重要性，导致项目的各个方面之间缺乏联系；由于专家们的优先权、看法和需求互不相同，所以项目管理比较困难。
3. 混合团队组织。由专家和多面手共同组成。多面手继续操作一个功能模块的整个开发过程，支持并处理多个功能模块，使各部分的专家们一起工作。可能拥有前两种方案的优点：外部小组只需要与一小部分专家进行交互；专家们可集中精力从事他们所擅长的工作；各个功能模块的实现都保持一致。但是也可能拥有前面两种方案的缺点：尽管这应该由多面手来调节，专家们仍然不能认识到其他专家的工作并且无法很好的协作；多面手很难找到，故而，项目管理仍然较难。

2. 人员招募

是指获取分派到项目上、并在那里工作所需的人力资源（个人或集体）。要考虑的问题有：

• 以往经验
• 个人兴趣
• 能否得到
• 胜任与熟练程度

项目经理是团队组织的核心，其综合素质直接影响项目的成败。一般要求项目经理具备如下能力：

1. 领导能力

项目经理必须具备高超的领导才能拿和强烈的科技意识和较强的业务处理能力。

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

其次，项目经理应善于激励。进行非物质激励。另外，对项目成员的工作成绩要及时表示认可。

第三，项目经理应该为成员梳理榜样，表现出积极的心态，称为团队的典范和信心的源泉。

第四，项目经理应该能够果断抉择，负责人的主要任务是决策。

2. 沟通技巧

有效的沟通是项目顺利进行的保证，沟通及时、集思广益、步调一致，才能取得项目最终的成功。在沟通过程中，项目经理应善于提问，并做到有效的聆听，能经常站在对方的角度思考问题。

3. 人际交往能力

良好的人际关系有助于项目的协调，避免生硬的操作方式。

4. 应付压力的能力

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

5. 培养员工的能力

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

6. 时间管理技能

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

合格的项目经理具有敏锐的洞察力，能瞄准目标，实事求是，精心组织，坚决果断，灵活应变，享有信誉；善于制定计划，解决问题，沟通信息；具有良好的市场意识和交际能力。

他应该具有实现这些条件的素质，并注重经验的积累、素质的提高和能力的培养。

3. 团队建设

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

团队中的每个人必须积极融入整个集体中，不能互相推诿，更不能互相埋怨和职责，正确的态度是大家在充分信任的基础上团队协作、互相帮助、主动承担任务，利用集体的智慧获得成功。

在软件项目中，应该为软件开发人员和管理人员等各类项目人员营造一个和谐、梁皓的工作氛围，为开发人员创造出一个人尽其才的环境也是项目成功的重要缓解，让他们能得心应手的施展自己的才华，特别在工作安排上要煞费苦心，针对每个人不同的特长，根据项目的具体环境和条件把人员合理的安排在恰当的岗位上。使他们能感到项目成功的把握并有积极的工作心态，将项目作为自己事业的一部分，确保项目队伍的稳定性和连续性。

软件项目团队的成长规律，分为以下4个阶段：

1. 形成阶段

促使个体成员转变为团队成员。

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

2. 震荡阶段

这一阶段，成员们开始着手进行分配到的任务，缓慢的推进工作。

震荡阶段的特点是人们有挫折、愤怒或者队里的情绪。这一阶段士气很低，成员可能会抵制形成团队，因为他们要表达与团队联合相对立的个性。

因此在这一阶段，项目经理要做导向工作，致力于解决矛盾，绝不能希望通过压制来使其自行消失。这时，对于项目成员采取的激励方式主要是参与激励、责任激励和信息激励。

3. 正规阶段

经受了震荡阶段的考验，项目团队就进入了发展的正规阶段。项目团队逐渐接受了现有的工作环境，团队的凝聚力开始形成。

在正规阶段，项目经理采取的激励方式除参与激励外，还有两个重要方式：一是发掘每个成员的自我成就感和责任意识，引导员工进行自我激励；二是尽可能多的创造团队成员之间互相沟通、相互学习的环境，以及从项目外部聘请专家讲解与项目有关的新知识、新技术，给员工充分的知识激励。

3. 表现阶段

团队成长的最后阶段是表现阶段。这时，项目团队积极工作，急于实现仙姑目标。这一阶段的工作绩效很高，团队有集体感和荣誉感，信息十足。

这一阶段，项目经理需要特别关注预算、进度计划、工作范围及计划方面的项目业绩。如果实际进程落后于计划进程，项目经理就需要协助支持修正行动的制定与执行。这一阶段的主要方式是危机激励、目标激励和知识激励。

需要强调的是，对于信息系统建设人才，要更多的引导他们进行自我激励和知识激励。足够的物质激励是不言而喻的，永远都是最有效的激励。

激励的结果是使参与信息系统的所有成员组成一个富有成效的项目团队，这种团队具有如下特点：

• 能清晰的理解项目的目标
• 每位成员的角色和职责都有明确的期望
• 以项目的目标为行为的导向
• 项目成员之间高度信任、高度合作互助。

13.6 软件的运行与评价

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

1. 软件的稳定性和可靠性评价
2. 软件是否满足了用户的需求
3. 软件实施给用户带来的好处。

13.7 软件过程改进

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