SWEBOK软件工程知识体系 - 7.软件工程管理

软件工程管理（SOFTWARE ENGINEERING MANAGEMENT）

软件工程管理可以定义为管理活动的应用，包括计划、协调、测量、监视、控制和报告1，以确保软件产品和软件工程服务能够高效、有效地交付给利益相关者。管理的相关学科是所有知识领域（KA）的一个重要元素，但它当然与此KA比与其他KA更相关。测量也是所有KA的一个重要方面，本文介绍了测量程序的主题。

在某种意义上，管理一个软件工程项目应该是可能的，就像管理其他复杂的工作一样。然而，软件项目和软件生命周期过程的某些特定方面使有效管理复杂化，包括：

• 客户通常不知道需要什么或什么是可行的。
• 客户通常对软件工程固有的复杂性缺乏了解，特别是对于不断变化的需求的影响。
• 增加理解和改变条件很可能会产生新的或改变的软件需求。
• 由于需求不断变化，软件通常使用迭代过程构建，而不是作为一系列关闭的任务。
• 软件工程必须包含创造性和纪律性。在两者之间保持适当的平衡有时是困难的。
• 新颖性和复杂性的程度通常很高。
• 基础技术的变化速度通常很快。

软件工程管理活动发生在三个层次：组织和基础设施管理、项目管理和度量程序管理。最后两个将在本说明中详细介绍。然而，这并不是要削弱组织和基础设施管理问题的重要性。软件组织工程（engineering）经理应该熟悉本KA中描述的项目管理和软件度量知识。他们还应该具备一些目标领域的知识。同样，如果复杂项目和程序（其中软件是系统体系结构的一个组成部分）的管理者意识到软件过程引入项目管理和项目度量的差异，这也是很有帮助的。

组织管理的其他方面对软件工程产生影响（例如，提供软件工程项目执行框架的组织策略和过程）。这些策略和过程可能需要根据有效软件开发和维护的要求进行调整。此外，可能需要制定或制定一些特定于软件工程的政策，以便在组织层面有效地管理软件工程。例如，为软件工程任务（如软件设计、软件构造、估计、监视和报告）建立特定的组织范围的过程或过程通常需要策略。这些策略对于跨组织的软件工程项目的有效长期管理非常重要（例如，建立一致的基础来分析过去的项目性能和实施改进）。

组织管理的另一个重要方面是人事管理政策和程序，用于雇用、培训和指导人员，以促进职业发展，不仅是在项目层面，而且是为了组织的长期成功。软件工程人员可能会面临独特的培训或人员管理挑战（例如，在基础技术经历快速和持续变化的情况下保持通用性）。

沟通管理也经常被提到，作为一个被忽视但很重要的方面，个人在一个领域的表现，精确理解用户需求，软件，投资组合管理，提供了一个整体的观点，不仅是各种项目和程序（集成项目）中目前正在开发的软件，而且是组织中计划和正在使用的软件。此外，软件重用是保持和提高生产率和竞争力的关键因素。有效的重用需要一个反映重用优缺点的战略远景。
除了了解软件项目对管理的独特影响外，软件工程师还应了解本KA（甚至在毕业后的头几年）中讨论的更一般的管理方面的知识。组织文化和行为的属性，再加上企业其他功能领域的管理，对组织的软件工程过程有影响，尽管是间接的。

有关软件项目管理的详细信息，请参阅《项目管理知识体系指南》（PMBOK®指南）和《PMBOK®指南》（SWX）的软件扩展部分[1][2]。每一本指南包括十个项目管理KA：项目集成管理、项目范围管理、项目时间管理、项目成本管理、项目质量管理、项目人力资源管理、项目沟通管理、项目风险管理、项目采购管理、，项目干系人管理。每个KA都与这个软件工程管理KA直接相关。
本KA的其他参考资料和进一步阅读资料中也提供了其他信息。

本软件工程管理KA由图7.1中前五个主题（启动和范围定义、软件项目规划、软件项目制定、评审和评估、结束）中的软件项目管理过程组成，加上第六个专题中的软件工程度量和第七个专题中的软件工程管理工具。虽然项目管理和测量管理常常被视为是分开的，而且确实每一个都具有许多独特的属性，但这种密切的关系导致了在这一领域的联合处理。

不幸的是，软件行业的一个普遍看法是，软件产品交付晚、预算过高、质量差、功能不完整。测量信息管理——任何真正的工程学科的基本原则（见工程基础KA中的测量）——可以帮助改善感知和现实。本质上，没有测量（定性和定量）的管理意味着缺乏纪律，没有管理的测量意味着缺乏目的或背景。有效的管理需要测量和经验的结合。

这里采用以下工作定义：

• 管理是实现组织设定的战略目标所需的过程和控制系统。
• 度量是指将值和标签分配给软件工程工作产品、过程和资源，以及从中派生的模型，无论这些模型是使用统计或其他技术开发的[3*，c7，c8]。
  本文中的软件工程项目管理部分广泛使用了软件工程度量部分。

本KA与《SWEBOK指南》中的其他KA密切相关，结合本KA阅读以下KA说明将特别有用：

• 工程基础KA描述了一些测量的一般概念，这些概念直接适用于本KA的软件工程测量部分。此外，工程基础KA统计分析部分提出的概念和技术直接适用于本KA中的许多主题。
• 软件需求KA描述了项目启动和范围定义阶段应执行的一些活动。
• 软件配置管理KA处理软件配置的识别、控制、状态记帐和审核，以及软件发布管理和交付以及软件配置管理工具。
• 软件工程过程KA描述了软件生命周期模型以及过程和工作产品之间的关系。
• 软件质量KA强调质量是管理的目标，也是许多软件工程活动的目标。
• 软件工程经济学讨论如何在业务环境中做出与软件相关的决策。

软件工程管理主题分解
因为大多数软件开发生命周期模型需要类似的活动，这些活动可能以不同的方式执行，所以主题的分解是基于活动的。该细分如图7.1所示。该图中所示的顶层分解元素是在管理软件开发项目时通常执行的活动，独立于为特定项目选择的软件开发生命周期模型（参见软件工程过程KA中的软件生命周期模型）。在本细分中，无意推荐特定的生命周期模型。分解只意味着发生了什么，并不意味着每个活动发生的时间、方式或次数。这七个主题是：

• 启动和范围定义，处理开始软件工程项目的决定；
• 软件项目规划，从管理角度阐述为准备成功的软件工程项目而开展的活动；
• 软件项目制定，处理在软件工程项目执行期间发生的普遍接受的软件工程管理活动；
• 审查和评估，确保技术、进度、成本和质量工程活动令人满意；
• 结束，解决为完成项目而完成的活动；
• 软件工程度量，处理软件工程组织中度量程序的有效开发和实施；
• 软件工程管理工具，描述用于管理软件工程项目的工具的选择和使用。

1.启动和范围定义

这些活动的重点是使用各种启发方法有效地确定软件需求，并从各种角度评估项目的可行性。一旦确定了项目可行性，本节中的剩余任务是要求规范和选择修订和评审要求的过程。

1.1. 需求的确定和协商

确定和协商需求为正在执行的一组任务设置了可见的边界（参见软件需求）。活动包括需求获取、分析、规范和验证。方法和技术的选择和应用应考虑到利益相关者的各种观点。这导致项目范围的确定，以满足目标和约束条件。

1.2. 可行性分析

可行性分析的目的是对项目目标进行清晰的描述，并对备选方案进行评估，以确定考虑到技术、资源、财务和社会/政治因素的限制，拟建项目是否是最佳备选方案。应准备一份初始项目和产品范围说明书、项目可交付成果、项目工期限制和所需资源的估计。

资源包括足够数量的拥有所需技能、设施、基础设施和支持（内部或外部）的人员。可行性分析通常需要根据适当的方法对工作量和成本进行近似估算（见第2.3节，工作量、进度和成本估算）。

1.3. 评审和修订要求的过程

考虑到变更的必然性，涉众应就评审和修订需求和范围的方法达成一致（例如，变更管理程序、迭代周期回顾）。这显然意味着范围和要求不会“一成不变”，而是可以而且应该在项目展开时的预定时间点（例如，在创建积压工作优先级时或在里程碑评审时）重新审视。如果变更被接受，则应使用某种形式的可追溯性分析和风险分析来确定这些变更的影响（参见软件配置管理KA中的第2.5节，风险管理和软件配置控制）。

管理的变更方法也可以形成在增量周期或整个项目结束期间，基于过程中发生的变更（见主题5，结束）成功评估的基础。

2.软件项目策划

软件项目规划的第一步应该是选择一个合适的软件开发生命周期模型，并根据项目范围、软件需求和风险评估对其进行裁剪。需要考虑的其他因素包括应用领域的性质、功能和技术复杂性以及软件质量要求（见软件质量KA中的软件质量要求）。

在所有可持续发展信用证中，风险评估应是项目初始规划的一个要素，项目的“风险状况”应得到所有相关利益相关者的讨论和接受。软件质量管理过程（见软件质量KA中的软件质量管理过程）应确定为策划过程的一部分，并形成软件质量保证、验证和确认、评审和审核的程序和责任（见软件质量KA）。项目计划和相关计划的持续审查和修订的过程和责任也应明确说明和商定。

2.1. 工艺规划

软件开发生命周期（SDLC）模型跨越了从预测到自适应的连续统一体（参见软件工程过程KA中的软件生命周期模型）。预测性SDLC的特点是开发详细的软件需求、详细的项目规划和开发阶段之间迭代的最小规划。自适应SDLC的设计是为了适应紧急软件需求和计划的迭代调整。高预测性SDLC以线性顺序执行图7.1中列出的前五个过程，仅在必要时对早期阶段进行修订。自适应SDLC的特点是迭代开发周期。处于SDLC连续体中间范围的SDLC根据预先计划的时间表（在连续体的预测侧）或作为频繁更新的开发周期的产物（在连续体的自适应侧）产生功能增量。

众所周知的SDLC包括瀑布模型、增量模型和螺旋模型，以及各种形式的敏捷软件开发[2][3*，c2]。

应选择相关方法（参见软件工程模型和方法KA）和工具作为规划的一部分。在整个项目中使用的自动化工具也应该被规划和获取。工具可以包括用于项目调度、软件需求、软件设计、软件构造、软件维护、软件配置管理、软件工程过程、软件质量等的工具。虽然这些工具中的许多应主要基于其他KA中讨论的技术考虑因素进行选择，但其中一些工具与本章中讨论的管理考虑因素密切相关。

2.2. 确定可交付成果

每个项目活动的工作产品（例如，软件架构（architecture）设计文档、检查报告、测试软件）都应该被识别和描述。应该评估重用以前项目中的软件组件或使用现成软件产品的机会。应规划软件采购和使用第三方开发可交付成果，并选择供应商（见第3.2节“软件采购和供应商合同管理”）。

2.3. 工作量、进度和成本估算

项目或部分项目所需工作量的估计范围可以使用基于历史规模和工作量数据（如果可用）和其他相关方法（如专家判断和类比）的校准估计模型来确定。例如，可以建立任务依赖关系，并使用甘特图来识别和记录并发和顺序完成任务的潜在机会。对于预测性SDLC项目，通常在计划期间生成具有预计开始时间、持续时间和结束时间的预期任务时间表。对于适应性SDLC项目，通常根据对需求的初步理解来制定工作和进度的总体估计，或者，可以规定对总体工作和进度的限制，并用于确定迭代周期数的初始估计以及分配给每个周期的工作和其他资源的估计。

所需资源（例如人员和工具）可以转化为成本估算。对工作、进度和成本的初步估计是一项迭代活动，应在受影响的利益相关者之间进行协商和修订，直到就项目完成所需的资源和时间达成共识。

2.4. 资源配置

应为确定的任务分配设备、设施和人员，包括完成项目和整个项目的各个要素的责任分配。可以使用显示每个任务的负责人、负责人、咨询人和知情者的矩阵。资源分配基于资源的可用性及其最佳利用，以及与人员有关的问题（例如，个人和团队的生产力、团队动态和团队结构），并受其约束。

2.5. 风险管理

风险和不确定性是相关但不同的概念。不确定性源于缺乏信息。风险的特征是将导致负面影响的事件发生的概率加上对项目负面影响的特征。风险往往是不确定性的结果。风险的反面是机会，其特征是可能发生具有积极结果的事件。

风险管理需要识别风险因素，分析每个风险因素的可能性和潜在影响，确定风险因素的优先顺序，并制定风险缓解策略，以降低风险因素成为问题时的可能性和最小化负面影响。有时可以使用风险评估方法（例如，专家判断、历史数据、决策树和过程模拟）来识别和评估风险因素。

项目放弃条件也可在此时与所有相关利益相关者讨论确定。软件特有的风险方面，如软件工程师增加不需要的特性的倾向，或与软件的无形性质有关的风险，都会影响软件项目的风险管理。应特别注意与软件质量要求相关的风险管理，如安全或安保（见软件质量KA）。风险管理不仅应在项目开始时进行，而且应在整个项目生命周期内定期进行。

2.6. 质量管理

对于一个软件项目和相关的工作产品，软件质量需求应该被识别，也许是定量和定性的。应根据涉众的需求和期望为每个软件质量需求设置可接受质量度量的阈值。在质量策划（planning）期间，还应规定与整个开发过程中的持续软件质量保证（SQA）和质量改进有关的程序，以及可交付软件产品的验证和确认程序（例如，技术评审和检查或已完成功能的演示）；参见软件质量（KA）。

2.7.计划管理

对于期望变更的软件项目，应该管理计划。因此，管理项目计划应该是有计划的。为软件开发选择的计划和过程应该被系统地监视、评审、报告，并在适当的时候进行修改。还应管理与支持过程（例如，文档、软件配置管理和问题解决）相关的计划。报告、监视和控制一个项目应该符合选定的SDLC和项目的实际情况；计划应该考虑将用于管理项目的各种工件。

3.软件项目实施

在软件项目制定（也称为项目执行）过程中，实施计划，并制定计划中包含的过程。自始至终，应将重点放在遵守选定的SDLC过程上，最重要的期望是遵守将导致成功满足利益相关者的要求和实现项目的目标。制定的基础是持续的监控、控制和报告管理活动。

3.1. 计划的实施

项目活动应按照项目计划和支持计划进行。利用资源（例如，人员、技术和资金）并生成工作产品（例如，软件设计、软件代码和软件测试用例）。

3.2. 软件采购与供应商合同管理

软件获取和供应商合同管理涉及到与软件开发组织的客户（他们获取了可交付的工作产品）和供应商（他们向软件工程组织提供产品或服务）签订合同的问题。

这可能涉及选择适当种类的合同，如固定价格、时间和材料、成本加固定费用或成本加奖励费用。与客户和供应商签订的协议通常规定了工作范围和可交付成果，并包括对延迟交付或不交付的惩罚等条款，以及规定供应商提供什么以及收单机构支付什么的知识产权协议，加上将交付给收单机构并由收单机构拥有的信息。对于由供应商（软件开发组织内部或外部）开发的软件，协议通常表示接受交付软件的软件质量要求。

协议生效后，应按照协议条款管理项目的执行（有关此主题的更多信息，请参见SWX第12章“软件采购管理”[2]）。

3.3. 测量过程的实施

测量过程应在软件项目期间制定，以确保收集到相关和有用的数据（参见第6.2节“计划测量过程”和第6.3节“执行测量过程”）。

3.4. 监视进程

对项目计划和相关计划的遵守情况应以预定的时间间隔进行持续评估。此外，还应评估每项任务的产出和完成标准。交付物应根据其要求的特性进行评估（例如，通过检查或演示工作功能）。应分析迄今为止的工作量、进度遵守情况和成本，并检查资源使用情况。应重新审查项目风险概况（见第2.5节，风险管理），并评估对软件质量要求的遵守情况（见软件质量KA中的软件质量要求）。

应分析测量数据（见工程基础KA中的统计分析）。应根据实际结果和预期值的偏差进行方差分析。这可能包括成本超支、进度延误或其他类似措施。应对质量和其他测量数据进行离群点识别和分析（例如，缺陷分析；参见软件质量KA中的软件质量测量）。应重新计算风险敞口（见第2.5节，风险管理）。这些活动可以根据已超过的阈值进行问题检测和异常识别。当超过阈值或必要时，应报告结果。

3.5. 控制过程

项目监测活动的结果为作出决定提供了依据。在适当的情况下，当了解风险因素的可能性和影响时，可以对项目进行更改。这可能采取纠正措施的形式（例如，重新测试某些软件组件）；它可能涉及合并其他措施（例如，决定使用原型来协助软件需求验证；参见软件需求KA中的原型）；和/或可能需要修改项目计划和其他项目文件（例如，软件需求规范），以适应意外事件及其影响。

在某些情况下，控制过程可能导致项目的放弃。在所有情况下，应遵守软件配置控制和软件配置管理程序（见软件配置管理KA），应记录决策并传达给所有相关方，必要时应重新审查和修订计划，并记录相关数据（见第6.3节，执行测量过程）。

3.6. 报告

在规定和商定的时间，应向组织内部（例如，向项目指导委员会）和外部利益相关者（例如，客户或用户）报告迄今为止的进展情况。报告应侧重于目标受众的信息需求，而不是项目团队内部的详细状态报告。

4评审与评价

在预先规定的时间和需要时，应评估实现所述目标和满足干系人（用户和客户）要求的总体进展情况。同样，过程、所涉及的人员以及所采用的工具和方法也应定期进行，并视情况而定。

4.1. 确定满足要求

因为实现干系人满意是软件工程经理的主要目标，所以应该定期评估朝着这个目标取得的进展。进度评估应基于主要项目里程碑的实现（例如，软件设计架构的完成或软件技术评审的完成），或者基于导致产品增量的迭代开发周期的完成。应确定与软件需求的差异，并采取适当的措施。

在上述控制过程活动中（见第3.5节，控制过程），应遵循软件配置控制和软件配置管理程序（见软件配置管理KA），记录决策并传达给所有相关方，必要时重新审查和修订计划，以及相关数据记录（见第6.3节，执行测量过程）。

4.2. 审查和评估绩效

项目人员的定期绩效评估可以提供关于遵守计划和流程的可能性以及可能存在的困难领域（例如，团队成员冲突）的见解。应评估所采用的各种方法、工具和技术的有效性和适当性，还应系统地定期评估项目使用的过程在项目环境中的相关性、实用性和有效性。在适当的情况下，应该做出改变并加以管理。

5关闭

当所有的计划和过程都被制定和完成时，整个项目、项目的主要阶段或迭代开发周期就结束了。应该评估项目、阶段或迭代成功的标准。一旦建立了关闭，就可以执行归档、回顾和过程改进活动。

5.1. 确定关闭

当一个项目、一个阶段或一个迭代的指定任务已经完成，并且完成标准的满意实现已经得到确认时，就发生了闭包。可以确定软件需求是否满足，并确定实现目标的程度。关闭过程应涉及相关利益相关者，并记录相关利益相关者的接受情况；任何已知问题都应记录在案。

5.2. 关闭活动

在确认关闭后，应按照利益相关者商定的方法、地点和期限完成项目材料的归档，可能包括销毁敏感信息、软件和副本驻留的介质。组织的测量数据库应更新相关的项目数据。应进行项目、阶段或迭代的回顾性分析，以便分析遇到的问题、问题、风险和机会（参见主题4，评审和评估）。应从项目中吸取经验教训，并将其纳入组织学习和改进工作中。

6.软件工程测量

测量的重要性及其在更好的管理和工程实践中的作用已得到广泛认可（见工程基础中的测量）。有效的测量已经成为组织成熟度的基石之一。度量可以应用于组织、项目、过程和工作产品。本节的重点是在项目、过程和工作产品的层次上应用度量。
本节遵循IEEE 15939:2008标准[6]，该标准描述了定义实现软件度量过程所需的活动和任务的过程。该标准还包括一个测量信息模型。

6.1. 建立并维持测量承诺

• 测量要求。每个度量工作都应该以组织目标为指导，并由组织和项目建立的一组度量需求驱动（例如，组织目标可能是“首先向市场推出新产品”）。
• 测量范围。应建立适用于每个测量要求的组织单位。这可能包括一个功能区、一个项目、一个站点或整个企业。还应考虑测量工作的时间范围，因为可能需要一些测量的时间序列；例如，校准估算模型（见第2.3节，工作、进度和成本估算）。
• 团队对测量的承诺。承诺应正式确立、传达并得到资源的支持（见下一项）。
• 测量资源。组织对度量的承诺是成功的一个重要因素，这一点可以从为实施度量过程而分配的资源中得到证明。分配资源包括分配测量过程中各种任务的责任（如分析员和图书馆员）。还应为开展这一进程分配充足的资金、培训、工具和支助。

6.2. 计划测量过程

• 确定组织单位的特征。组织单元为度量提供了环境，因此组织环境应该是明确的，包括组织对度量过程施加的约束。特征可以用组织过程、应用领域、技术、组织接口和组织结构来描述。
• 确定信息需求。信息需求基于组织单位的目标、约束、风险和问题。它们可能来自业务、组织、监管和/或产品目标。应该确定它们并确定它们的优先次序。然后，利益相关者可以选择、记录、传达和审查要解决的目标子集。
• 选择措施。应选择与信息需求有明确联系的候选措施。应根据信息需求的优先顺序和其他标准（如收集成本、收集过程中的中断程度、获取准确、一致数据的难易程度以及分析和报告的难易程度）来选择措施。由于内部质量特征（见软件质量KA中的模型和质量特征）通常不包含在具有合同约束力的软件需求中，因此考虑度量软件的内部质量以提供可能影响外部利益相关者的潜在问题的早期指标是很重要的。
• 定义数据收集、分析和报告程序。这包括数据的收集过程和时间表、存储、验证、分析、报告和配置管理。
• 选择评估信息产品的标准。评价标准受组织单位的技术和业务目标的影响。信息产品包括与正在生产的产品相关联的产品，以及与用于管理和度量项目的过程相关联的产品。
• 为测量任务提供资源。测量计划应由相关利益相关者审查和批准，包括所有数据收集程序、存储、分析和报告程序、评估标准、时间表和责任。评审这些工件的标准应该在组织单位级别或更高级别上建立，并且应该用作这些评审的基础。此类标准应考虑到以前的经验、资源的可用性以及在提议改变现行做法时对项目的潜在干扰。批准表明对测量过程的承诺。
• 确定可用于实施计划和批准的测量任务的资源。资源可用性可能会在广泛部署之前进行试点的情况下进行阶段性调整。应考虑到成功部署新程序或措施所需的资源。
• 获取和部署支持技术。这包括评估可用的支持技术、选择最合适的技术、获取这些技术以及部署这些技术。

6.3. 执行测量过程

• 将测量程序与相关软件过程相结合。度量过程（如数据收集）应集成到它们所度量的软件过程中。这可能涉及更改当前的软件过程以适应数据收集或生成活动。它还可能涉及对当前软件过程的分析，以尽量减少额外的工作，确保度量过程被接受。应考虑士气问题和其他人为因素。此外，测量程序应传达给提供数据的人员。培训数据分析和报告程序以类似的方式在项目或过程中进行。
• 收集数据。应收集、验证和存储数据。有时可以通过使用软件工程管理工具（参见主题7，软件工程管理工具）来分析数据和开发报告，从而自动收集数据。数据可以作为分析过程的一部分进行聚合、转换或重新编码，使用与数据性质和信息需求相适应的严格程度。该分析的结果通常是一些指标，如图表、数字或其他将被解释的迹象，从而得出结论并向利益相关者提出建议（见工程基础KA中的统计分析）。通常使用组织定义的过程（可以是正式的，也可以是非正式的）对结果和结论进行评审。数据提供者和计量使用者应参与审查数据，以确保数据有意义和准确，并能采取合理行动。
• 传达结果。信息产品应形成文件，并传达给用户和利益相关者。

6.4. 评估测量

• 根据指定的评估标准评估信息产品和测量过程，并分别确定信息产品或过程的优缺点。评估可以通过内部过程或外部审计进行；评估应包括测量用户的反馈。经验教训应记录在适当的数据库中。
• 确定潜在的改进。这些改进可能是指标格式的改变、计量单位的改变或计量类别的重新分类。应确定潜在改进的成本和收益，并报告适当的改进措施。
• 向测量过程负责人和利益相关者传达改进建议，以供审查和批准。此外，如果分析未能确定任何改进，则应告知缺乏潜在改进。
  
  

7.软件工程管理工具

软件工程管理工具通常用于提供软件工程管理过程的可见性和控制。一些工具是自动化的，而另一些则是手动实现的。最近出现了一种趋势，即在整个项目中使用软件工程工具的集成套件来计划、收集和记录、监视和控制以及报告项目和产品信息。工具可分为以下类别：

• 项目规划和跟踪工具。项目计划和跟踪工具可用于估计项目工作量和成本，并编制项目进度表。一些项目使用自动化的估算工具，这些工具接受软件产品的估算大小和其他特性作为输入，并生成所需总工作量、进度和成本的估算。计划工具还包括自动调度工具，用于分析工作分解结构中的任务、它们的估计工期、它们的优先级关系以及分配给每个任务的资源，以生成甘特图形式的计划。
  跟踪工具可用于跟踪项目里程碑、定期计划的项目状态会议、计划的迭代周期、产品演示和/或行动项。
• 风险管理工具。风险管理工具（见第2.5节，风险管理）可用于跟踪风险识别、估计和监控。这些工具包括使用模拟或决策树等方法来分析成本对收益的影响，以及对风险事件概率的主观估计。montecarlo模拟工具可用于通过以算法方式组合多个输入概率分布来产生工作量、进度和风险的概率分布。
• 通讯工具。沟通工具有助于向参与项目的相关利益相关者提供及时和一致的信息。这些工具可以包括电子邮件通知和向团队成员和利益相关者广播等内容。它们还包括定期计划的项目会议记录、每日站立会议，以及显示进度、积压和维护请求解决方案的图表。
• 测量工具。度量工具支持与软件度量程序相关的活动（参见主题6，软件工程度量）。在这一类中几乎没有完全自动化的工具。用于收集、分析和报告项目度量数据的度量工具可以基于项目团队成员或组织员工开发的电子表格。