第16章软件项目管理与过程改进课件

第十六章

软件项目管理与过程改进软件工程(第三版)

齐治昌谭庆平宁洪2012年8月第十六章

软件项目管理与过程改进软件工程(第十六章

软件项目管理与过程改进16.1软件项目管理与过程模型16.2软件项目度量与估算16.3风险分析16.4软件项目计划16.5软件项目人员和组织16.6软件质量保证16.7软件配置管理16.8软件过程改进2023/7/31国防科技大学计算机学院2第十六章

软件项目管理与过程改进16.1软件项目管软件项目管理与过程改进软件管理是软件工程学科的重要组成部分，在软件生存周期中发挥着重要的作用。软件开发过程中的软件管理称软件项目管理，直接关系到软件项目的成败。软件配置管理贯穿整个软件生存周期，在软件开发过程中是软件项目管理的重要组成部分，在软件交付后是软件有效运行和维护的保障。软件开发组织建设和过程改进是不断推出高质量软件制品的关键。本章主要介绍软件项目管理、软件配置管理、软件过程改进。软件项目管理与过程改进软件管理是软件工程学科的重要组成部分，16.1软件项目管理与过程模型本节主要介绍软件项目管理的概念软件项目管理的过程模型软件项目管理的原则软件项目制品16.1软件项目管理与过程模型本节主要介绍16.1.1软件项目管理的概念软件项目管理是软件工程的重要组成部分。软件项目已通过软件项目的可行性论证和立项的法定程序。软件项目可能是基于计算机的系统工程的一部分，也可能是独立的实体。按照合同要求，软件项目应具有明确的目标、任务、责任人、技术途径、资金投入、交付时间、客户实体、利益相关方。在面向领域的应用软件开发项目中，领域专家和客户愿意和软件开发团队密切合作，这是项目成功的关键。2023/7/31国防科技大学计算机学院516.1.1软件项目管理的概念软件项目管理是软件工程的重要组软件项目管理的概念软件工程是人的智力密集型劳动，软件是逻辑制品，软件项目管理更要强调工作的计划性，人员、进度、制品的可控性，要及时进行软件项目的风险分析和管理。客户与开发者必须在项目开发早期、软件需求工程的初始阶段完成下列六项任务。2023/7/31国防科技大学计算机学院6软件项目管理的概念软件工程是人的智力密集型劳动，软件是逻辑制软件项目管理的概念①确定制品目标、范围，主要技术指标、功能

和行为特性；②确定管理者和开发人员；③进行成本估算；④进行有效的风险分析、验证与确认；⑤给出恰当的项目任务划分；⑥根据约束条件，如制品交付期限、预算、可

用人员、技术接口等因素，选择“最佳”方

案，制定可管理的项目进度计划，给出明确

的项目进展标志,并将任务、责任落实到人。2023/7/31国防科技大学计算机学院7软件项目管理的概念①确定制品目标、范围，主要技术指标、功能软件项目管理的概念1999年，软件产业界的统计数据表明，26％的软件项目彻底失败，46％的项目成本和进度超出预定计划。软件项目失败率仍然很高。实践表明，良好的软件开发过程孕育着好的软件制品，而好的软件制品一般隐含良好的软件开发过程。本节的其余部分介绍软件项目管理原则、软件项目的管理模型、生存周期各阶段的软件制品。软件项目管理的概念1999年，软件产业界的统计数据表明，2616.1.2软件项目管理的过程模型第一章讨论了软件生存周期和软件开发的几种模型。生存周期及其划分涉及软件开发过程和过程生成的制品。软件开发过程分为线性过程和非线性过程两类。瀑布模型是典型的线性过程模型。增量模型、螺旋模型虽是迭代模型,但本质上是瀑布模型的应用。统一过程RUP是迭代的非线性模型，与瀑布模型存在本质的区别。这些模型既用于软件开发的技术过程，也用于软件开发的管理过程。16.1.2软件项目管理的过程模型第一章讨论了软件生存周期软件项目管理的过程模型软件开发的技术人员和管理人员在软件开发过程中分工明确,他们在模型中参与相应的活动，开发相应的制品。软件过程的活动序列按任务分类,组成软件开发人员开发软件制品的“工作流”。“工作流”强调“人的活动”，目标是开发软件制品，其中蕴含开发人员使用的技术、工具和必须遵循的约束条件。第二章介绍了RUP的九个工作流，及在软件生存周期各阶段的工作量分布。2023/7/31国防科技大学计算机学院10软件项目管理的过程模型软件开发的技术人员和管理人员在软件开发软件项目管理的过程模型启动每个工作流都要完成某项任务，产生某些制品，都要使用一定的资源，必须满足一定的约束条件。如，需求工作流将系统工程师或用户以某种方式提供的系统功能和特征作为前置条件，通过需求获取、分析、建模活动生成用软件建模语言（如，UML）描述的软件需求规约。需求阶段的约束是需求文档的标准、表示法、需求预算、进度等。2023/7/31国防科技大学计算机学院11软件项目管理的过程模型启动每个工作流都要完成某项任务，产生某软件项目管理的过程模型软件团队选择软件过程模型时，有很大的灵活性，应根据项目需要确定过程模型。如果问题能很好地划分，时间紧，不可能完成所有功能，可采用增量模型，分期交付。如果项目需求不能完全确定、需求变更频繁可采用RUP迭代过程模型等。2023/7/31国防科技大学计算机学院12软件项目管理的过程模型软件团队选择软件过程模型时，有很大的灵16.1.3软件项目管理的原则W.Royce总结了现代软件项目管理应该遵循的十条重要原则。⑴体系结构优先的过程软件体系结构是软件需求、软件设计活动的关键制品。软件体系结构过程涉及软件项目全局,包括:软件项目计划、需求获取、描述、风险分析、软件体系结构设计等。软件体系结构过程与软件实现、交付、维护相比，涉及的人较少，工作量较小。16.1.3软件项目管理的原则W.Royce总结了现代软软件项目管理的原则稳定、优质的体系结构是软件实现和交付的基础，可以避免软件上游缺陷蔓延到下游，减少软件制品返工和报废，避免时间和资源的浪费。软件体系结构基线是软件初始、软件细化阶段成熟的标志。体系结构优先的过程体现了软件体系结构在现代软件开发过程中的重要地位。2023/7/31国防科技大学计算机学院14软件项目管理的原则稳定、优质的体系结构是软件实现和交付的基础软件项目管理的原则⑵风险驱动的迭代过程软件开发存在许多不确定因素，存在许多风险。适时进行风险分析，提出化解风险的措施，驱动迭代过程，是保证软件开发过程按计划前行，软件制品随软件开发的迭代过程不断进化的有效途径。⑶基于构件的设计基于构件的软件设计可以降低软件复杂性，有效实施软件复用，提高软件质量，降低软件开发成本，缩短交付期限，提高软件项目计划和成本估算的准确性。2023/7/31国防科技大学计算机学院15软件项目管理的原则⑵风险驱动的迭代过程2023/7/31国软件项目管理的原则⑷建立配置和变更管理环境软件开发过程中变更不可避免，需求不能完全确定的项目只能在探索中前进。软件开发文档、中间制品很多，某一文档的变更通常会涉及相关文档，必须对这些文档进行相应的维护，保持软件制品的一致性。采用迭代、增量开发模型，面对不同的用户需求，项目团队将持续发布多种版本的软件制品。复杂多变的软件项目和制品,需要变更管理工具、配置数据库和配置管理系统的支持，人工不能完成这一任务。软件项目管理的原则⑷建立配置和变更管理环境软件项目管理的原则⑸建立支持双向工程的工具和环境为了保持变更的一致性，软件工具和环境要支持正向工程和逆向工程。详细设计、代码的修改确定后，利用逆向工程工具和环境自动生成软件开发上游的体系结构和需求文档。正向和逆向工程的工具和环境相互配合，为可变更的迭代开发过程提供了灵活性，提高了软件开发的效率和软件制品的质量。2023/7/31国防科技大学计算机学院17软件项目管理的原则⑸建立支持双向工程的工具和环境2023/软件项目管理的原则⑹用严格的、基于模型的符号描述设计制品程序设计语言是描述程序的工具，用于人与人、人与机器的交流，控制计算机的运行。程序设计语言是用一组符号按照严格的语法、语义、语用定义的。目前广泛使用统一建模语言UML，支持软件需求、设计和实现的全过程（实现过程需要Java、C++等程序设计语言的支持）。UML标准提供用例图、结构图（类图、对象图、包图）、行为图（交互图、状态图、顺序图、通信图）、构件图、部署图五类共十种图形建模表示法和OCL约束语言。软件项目管理的原则⑹用严格的、基于模型的符号描述设计制品软件项目管理的原则⑺为客观的质量控制插装验证和确认过程客观的软件质量强调软件制品的实际质量。在初始和细化阶段，只能通过检查、审查方式评估软件制品，软件的质量评估往往带有主观色彩。在软件开发过程中，设置关键点插装评估过程，对软件制品和过程进行严格检查和V&V可防止缺陷蔓延、减少制品报废和返工，提高软件制品质量。2023/7/31国防科技大学计算机学院19软件项目管理的原则⑺为客观的质量控制插装验证和确认过程20软件项目管理的原则⑻借助演示评估中间制品现代软件开发过程借助场景、用例描述需求。场景、用例具有直观、便捷、容易理解的优点。软件开发过程中借助演示，验证确认基于场景、用例的中间制品的演化过程，有利于团队成员的沟通，及时统一软件开发人员对软件制品的认识，减少因理解过失导致的软件制品缺陷，提高软件制品的评审质量和软件开发效率。2023/7/31国防科技大学计算机学院20软件项目管理的原则⑻借助演示评估中间制品2023/7/31软件项目管理的原则⑼大量使用场景。按照场景细化等级，在软件生存周期的前期就开始持续的发布有用的软件版本。保持需求、设计和计划均衡进化。⑽争取更多的投资回报。推广项目团队掌握的方法、技术、工具和经验，建立灵活的配置过程，在经济上争取更多的回报。2023/7/31国防科技大学计算机学院21软件项目管理的原则⑼大量使用场景。2023/7/31国防科软件项目管理的原则现代软件项目管理要素是，人员、环境、质量、规模和过程。上述十项原则符合软件经济学基本规律：成本=（人员）×（环境）×（质量）×（规模）（过程）

人员：用演示方式进行沟通、不断发布用例进化细节，提高人员对项目、软件制品的理解和认识，避免误解和无效劳动。环境：建立软件双向工程的工具和环境，采用过程插装，进行客观的质量度量和控制，提高软件开发质量和效率。软件项目管理的原则现代软件项目管理要素是，人员、环境、质量、软件项目管理的原则质量：贯彻体系结构优先的原则，统一开发过程和语言，实施变更管理，加强环境基础建设，重视对项目和软件制品的V&V，提高软件制品的质量。规模：采用构件开发，统一开发过程的语言描述，利用多种途径降低复杂性，化解规模带来的压力。过程：采用迭代开发模型，实施可配置的过程改进，进行风险分析和管理，重视项目的过程复用，优化软件开发过程。成本和规模、过程的指数关系表明,减少规模，改进过程对降低成本的特殊重要性。人员、环境、质量、规模、过程的改进可减少大量文档，降低软件开发成本。软件项目管理的原则质量：贯彻体系结构优先的原则，统一开发过程软件项目管理的原则按照上述原则进行软件项目管理是现代软件开发实践经验的总结，也是软件项目取得成功的关键。软件项目团队应根据自身的实际，在软件项目开发过程中灵活运用，并不断创造新的实践经验和原则。

软件项目管理的原则按照上述原则进行软件项目管理是现代软件开发16.1.4软件项目制品现代软件项目的管理过程与开发过程配套，多采用迭代方式。软件制品不是在生存周期的阶段内按照线性方式开发，而是采用迭代方式一起进化。进化过程中不仅要不断丰富、细化系统描述，还要对约束、抽象层次和自由度进行折衷，尽量保持软件制品细节的平衡。为了对软件项目实施管理，软件开发活动产生的制品通常划分为若干制品集，支持软件项目的开发活动。16.1.4软件项目制品现代软件项目的管理过程与开发过程配软件项目制品W.Royce将软件项目制品划分为：用文本语言描述的管理集用文本和模型描述问题空间的需求集用解空间模型描述的设计集用程序设计语言及相关文档描述的实现集用机器语言及相关文档描述的实施集2023/7/31国防科技大学计算机学院26软件项目制品W.Royce将软件项目制品划分为：2023/7软件项目制品近年来用RUP过程开发软件项目已成为一种潮流。用强有力的、可视化的、具有严格语法和语义定义的统一建模语言UML支持体系结构优先策略开发的需求制品集和设计制品集是软件工程在技术上的重大进步。这些制品集是软件工程数据库的重要组成部分。下面从管理制品和工程制品两个方面分别介绍五类制品集。2023/7/31国防科技大学计算机学院27软件项目制品近年来用RUP过程开发软件项目已成为一种潮流。21.管理制品集管理制品集即管理集，包括：①工作分解WBS和财务追踪制品②成本、进度和利润预测、度量和统计业务案例制品③描述软件制品范围、开发计划和发布基线的发布版规约④软件项目开发计划⑤基于基线的发布版说明书⑥反映项目进展状态的验证和确认制品⑦软件变更管理系统和软件配置管理系统1.管理制品集管理制品集即管理集，包括：管理制品集⑧实施文档,包括：移交计划、用户培训课程、销售展示工具包等⑨软件开发环境，包括：软件工具、文档、人员培训资料等管理集制品的形式有软件、文本、图形、图像、视频等项目相关人员应对管理集制品进行评审，按照里程碑进行展示评审管理集制品反映软件项目成本、进度、质量、项目变更、软件制品进化的情况2023/7/31国防科技大学计算机学院29管理制品集⑧实施文档,包括：移交计划、用户培训课程、销售展示2.工程制品集工程制品集由需求集、设计集、实现集和实施集组成。制品集随时间进化，必须保证需求、设计、实现和实施制品之间的系统性、正确性和一致性。2.工程制品集工程制品集由需求集、设计集、实现集和实施集组成需求集用结构化文本描述构想、合同、管理需求、用户原型。用UML描述需求模型，如用例模型和领域业务模型。需求集是评审设计集、实现集和实施集的主要依据，也是生成测试用例的基础。需求集制品用于评审需求集与管理集规约的一致性分析构想和需求模型的一致性支持需求集、设计集、实现集和实施集制品描述的一致性和完整性,及版本变更等2023/7/31国防科技大学计算机学院31需求集用结构化文本描述构想、合同、管理需求、用户原型。202设计集在不同的抽象层次上用UML描述设计模型，描述解空间的构件和属性，描述静态架构和动态活动等利用设计模型的结构和行为信息可以直接或自动转换为实现集和实施集制品设计集制品

设计模型、测试模型、软件体系结构描述设计集制品评审

设计模型的一致性和质量，设计模型与需求模型的一致性和完整性，向实现集和实施集迁移的可追踪性，源代码生成、编译和链接问题，反映设计模型过程中出现的废品、返工和缺陷排除趋势的版本变更等目前设计集制品质量主要靠人工评审。2023/7/31国防科技大学计算机学院32设计集在不同的抽象层次上用UML描述设计模型，描述解空间的构实现集实现集制品

用程序设计语言描述的源代码，编译脚本、数据文档，单机环境下的构件可执行代码，自文档化的测试源代码基线、测试用例的输入和输出文档，及构件测试驱动程序的可执行代码，配置管理设施等。源代码表示构件、构件接口、依赖关系及实现。最终制品

可执行代码、可复用构件、遗留构件、定制构件、商业构件及应用程序接口(API)、程序设计语言（如Java、C++、VisualBasic或汇编）API组成。实现集制品通过编译或链接转换为实施集的可执行代码。实现集评估

测试构件或可执行文档，测试源代码与设计模型的一致性，分析实现集版本的一致性、完整性和变更趋势等。

2023/7/31国防科技大学计算机学院33实现集实现集制品2023/7/31国防科技大学计算机学院33实施集实施集制品

可执行的基线及运行时的文档和用户手册。

交付给用户的机器语言的可执行软件、构造文档、安装脚本，以及在目标环境中使用该制品所需要的数据。

在使用环境安装和执行实施集的源代码，支持最终制品的运行并发挥全部设计功能和性能。实施集测试和度量

按需求测试使用场景和质量属性，测试一致性、完整性；

测试将实现集构件映射到实施系统的合理性、正确性；

测试用户手册定义的使用场景；

测试安装、面向用户的配置、日常使用及异常管理；

分析实施集缺陷排除趋势和性能变更等。2023/7/31国防科技大学计算机学院34实施集实施集制品2023/7/31国防科技大学计算机学院34表16.1软件项目制品集需求集①构想文档②需求模型设计集①设计模型②测试模型③体系结构描述实现集①源代码基线②编译文档③可执行构件实施集①可执行的集成化的制品集②运行文档③用户手册管理集：计划制品管理集：可操作制品①工作分解结构WBS⑤发布版说明书②业务案例⑥V&V状态③发布版规约⑦配置和变更管理数据库④软件开发计划⑧实施文档

⑨环境讨论软件项目生成的制品和制品集的目的是，进一步了解软件开发过程、了解软件开发制品及其描述。表16.1软件项目制品集需求集设计集实现集实施集管理集：计划软件项目制品表16.2反映软件制品在工作流的作用下经历软件生存周期各个阶段的进化过程。软件项目管理的进一步讨论请参阅文献[1][3][112][113[115][116][128][130]。软件项目制品表16.2反映软件制品在工作流的作用下经历软件生16.2软件项目度量与估算软件项目度量和估算是软件开发组织量化管理的重要内容，也是软件开发组织成熟度的标志。软件开发过程中对软件过程、项目和制品属性进行测量获得数据，再经过度量计算、度量分析获得重要的管理及技术指标。项目度量能够支持软件项目的计划、软件项目跟踪及控制，能够评估生成软件制品的质量，及时改进项目的工作流程和技术方法。软件开发组织的过程度量能够使软件开发组织从战略高度了解、改进软件过程,提升企业文化。项目度量和过程度量是软件开发组织的基础性工作,相互促进相互依存。16.2软件项目度量与估算软件项目度量和估算是软件开发组软件项目度量与估算软件规模、可靠性、软件项目工作量、开发时间和过程生产率是软件和软件项目度量的核心要素。上一章讨论了软件规模和可靠性度量，这一章讨论软件项目的度量与估算。大型复杂软件项目的度量必须进行分解,采用自顶向下、自底向上、专家判断、经验公式等方法“分而治之”。对于规模较小的软件项目可参照类似项目或选用适宜的估算模型直接估算。软件开发工作量估算在软件项目估算中尤其重要,直接用于项目进度计划、成本估算和人员安排等。2023/7/31国防科技大学计算机学院38软件项目度量与估算软件规模、可靠性、软件项目工作量、开发时间16.2.1软件项目分解在软件项目策划的过程中，往往对软件项目的工作制品和过程进行层次分解，分解为较小的易于管理和开发的子系统或模块。借助软件项目管理的工作分解结构可采用自顶向下和自底向上方法进行估算。估算内容除各子系统或模块外还应考虑各子系统之间关联和系统级的工作量。如，软件风险分析、软件变更管理、软件配置管理、软件质量管理等。16.2.1软件项目分解在软件项目策划的过程中，往往对软件⑴自顶向下方法步骤①根据完成的类似软件项目的工作量或成本，估算待开发软件项目的工作量或成本W0。②估算软件开发各项任务协调、交流、管理、集成和软件项目特殊要求的工作量W10③软件开发工作量为W20=W0-W10

2023/7/31国防科技大学计算机学院40⑴自顶向下方法步骤2023/7/31国防科技大学计算机学院自顶向下方法参照Boehm给出的软件生存周期各阶段工作量的基本分布（如表16.3所示），计算软件生存周期各阶段工作量

W2J0=pjⅹW20

pj是W2j在W20中所占的百分比，j=1,2,…k,于是W20=W210+W220+…

+W2K02023/7/31国防科技大学计算机学院41自顶向下方法参照Boehm给出的软件生存周期各阶段工作量的基表16.3Boehm统计的工作量分布阶段制品规模2KDSI8KDSI32KDSI128KDSI计划与需求+6%+6%+6%+6%概要设计16%16%16%16%详细设计26%25%24%23%编码与单元测试42%40%38%36%集成与测试16%19%22%25%表16.3中“计划与需求”预置6%的附加工作量，用于团队获取领域知识和经验、与客户合作、处理知识产权等问题，DSI表示项目开发的有效的不含注释的源指令行。表16.3Boehm统计的工作量分布软件项目分解Boehm给出的软件生存周期各阶段工作量的基本分布可根据今天的软件开发方法、环境和问题，软件开发组织的实际进行必要的调整。估算的各个部分的工作量带有主观成分，应根据项目的实际情况进行修改。⑤软件开发过程中，及时统计实际工作量W2J，并与初始估算W2J0进行比较，以此为参考对尚无实际工作量的初始估算进行修正。自顶向下方法适用于软件开发早期，但不精确，需要在软件开发过程中不断调整、修正。软件项目分解Boehm给出的软件生存周期各阶段工作量的基本分⑵自底向上方法利用软件项目管理的工作分解结构，自底向上估算各项任务的工作量（或成本），再逐步相加，得到待开发软件的总工作量（或成本）。Boehm给出了用自底向上方法进行软件估算的示例（如表16.4所示）。该方法的成效取决于工作分解结构的质量和稳定性。如果分解结构在软件开发过程中很少变更，估算的准确性较高。⑵自底向上方法利用软件项目管理的工作分解结构，自底向上估算各表16.4a自底向上方法进行软件估算示例1构件：人机交互开发者：王平日期：阶段任务人天总计计划与需求组件需求开发计划718概要设计概要设计用户手册初稿测试计划84113详细设计用PDL描述的详细设计定义数据测试用例设计64515总计（人天）36表16.4a自底向上方法进行软件估算示例1构件：人机交互开表16.4b自底向上方法进行软件估算示例2构件：人机交互开发者：张洁日期：阶段任务人天总计详细设计生成测试数据编写完整的用户手册6814编码与单元测试编码单元测试101222集成与集成测试集成集成测试编写文档57517总计（人天）532023/7/31国防科技大学计算机学院46将各阶段工作量数据相加，得w=36+53=89.表16.4b自底向上方法进行软件估算示例2构件：人机交互开(3)根据实验或历史数据根据实验或历史数据给出软件项目工作量或成本的经验估算公式。上述三种方法可以同时、单独或组合使用，取长补短、互相参考，提高项目估算的精度和可靠性。采用分解技术估算软件项目应考虑各项任务之间协调、系统集成时需要的工作量。为了实现软件项目估算，实践中开发了大量的软件项目自动估算工具，支持软件工作量或成本估算。(3)根据实验或历史数据根据实验或历史数据给出软件项目工作量软件项目分解传统软件工程的软件项目按照瀑布模型分解，分别估算出软件项目在软件开发各个阶段的工作量和成本，再进行汇总，估算出整个项目的工作量和成本。现代软件工程的软件项目采用RUP过程，迭代模型，可按照初始、细化、构造阶段分解，分别估算工作量，也可以按照各个工作流统计工作量。积累软件开发组织和团队开发软件项目的历史数据，对开发组织的软件项目估算和管理十分必要。软件项目分解传统软件工程的软件项目按照瀑布模型分解，分别估算16.2.2采用代码行、功能点度量的工作量估算软件项目的规模是影响软件项目成本和工作量的重要因素。较小的软件项目或模块可采用代码行和功能点估算，然后根据类似项目的专家经验换算成工作量和成本。采用上述估算方法可以估算出LOC或FP的乐观值a，悲观值b和一般值m，然后根据下列加权公式计算出期望值。E=(a＋4m＋b)／616.2.2采用代码行、功能点度量的工作量估算软件项目的规采用代码行、功能点度量的工作量估算我们希望LOC或FP的值落在区间［a,b］之外的概率极小。当LOC或FP的期望值估算出来之后，根据以前软件项目开发的平均生产率，每人月代码行（LOC/PM），或每人月功能点（FP/PM）就可以计算出工作量。如，软件项目的规模估算为310FP，以前完成类似软件项目的生产率为5.5FP/PM，于是工作量估算为E=310/5.5=56PM。如果当前估算的软件子项目比以前完成的项目复杂，所用的生产率值可以低于平均生产率，反之高于平均生产率。采用代码行、功能点度量的工作量估算我们希望LOC或FP的值落例16.1估算计算机辅助设计(CAD)软件项目将CAD项目按功能分解为七个子项目：

①用户界面和控制；②二维几何分析；

③三维几何分析；④数据库管理；

⑤计算机图形显示；

⑥外设控制；

⑦设计分析。表16.5给出七个子项目代码行的乐观估计、悲观估计和一般估算值，然后计算出加权平均值。分析七个子项目的规模、复杂性和难度，参照以前开发类似项目的经验给出开发每行代码的平均成本，每月开发的代码行数。用这两组数据计算出七个子项目的开发成本和工作量。最后汇总的CAD软件开发项目

规模为33360LOC，

成本为656680$，工作量为144.5PM2023/7/3151国防科技大学计算机学院例16.1估算计算机辅助设计(CAD)软件项目将CAD项目估算计算机辅助设计(CAD)软件项目再用第二种方法分别估算软件开发子项目在软件工程各个阶段的工作量，估算结果列入表16.6。两种方法估算的工作量分别为144.5PM和152.5PM，相差5%左右。估算的成本分别为656680$和708075$，相差7%左右。两种方法估算的工作量和成本基本一致。这个例子只给出估算方法的步骤和说明，具体数据不一定符合今天软件开发的实际状况。2023/7/3152国防科技大学计算机学院估算计算机辅助设计(CAD)软件项目再用第二种方法分别估算软表16.5基于功能分解的代码行、成本、工作量估算2023/7/3153国防科技大学计算机学院表16.5基于功能分解的代码行、成本、工作量估算2023/表16.6功能和过程分解的工作量估2023/7/31国防科技大学计算机学院54表16.6功能和过程分解的工作量估2023/7/31国防16.2.3软件项目的生产率度量管理人员希望在不同的软件过程和不同的环境中评估软件开发人员的生产率。传统模型的生产率度量是，用规模除以工作量。直接用于软件生产率度量是

代码行数／人月

功能点数／人月

对象点数／人月这些度量没有反映影响生产率的许多其他重要因素，如代码质量，软硬件环境，复杂性等。2023/7/31国防科技大学计算机学院5516.2.3软件项目的生产率度量管理人员希望在不同的软件过软件项目的生产率度量图16.1的生产率模型从经济学的角度出发，用软件的价值和投入成本的比值度量生产率，并对软件的市场价值和成本进行了分解。

生产率=软件制品价值/软件成本从经济学的角度定义生产率比较全面的反映了生产率和生产要素的关系。适用于软件组织和软件项目的生产率度量。模型没有指明各种要素对生产率的具体影响。只从管理的角度要求软件开发过程要降低成本、提高质量，开拓软件制品市场、增加发行数量，没有对软件开发人员提出提高生产率的具体技术措施。2023/7/31国防科技大学计算机学院56软件项目的生产率度量图16.1的生产率模型从经济学的角度出发图16.1软件生产率模型2023/7/31国防科技大学计算机学院57图16.1软件生产率模型2023/7/31国防科技大学计16.2.4一般经验估算模型软件工作量估算模型是根据以前完成项目的实际数据导出的，用于新软件项目的计划阶段。导出的模型参数是“从前的”、“局部的”，估算模型不可能适用于当前所有的软件项目和全部开发环境，仅有一定的参考价值。2023/7/31国防科技大学计算机学院5816.2.4一般经验估算模型软件工作量估算模型是根据以前完一般经验估算模型估算工作量、进度和成本的一般算法模型：

其中：E是以人月为单位的工作量ev是以KLOC或FP为单位的规模估算变量A,B,C是大量软件项目数据通过回归分析得出的经验常数m(X)是项目调整因子，取值依赖于项目属性向量X2023/7/31国防科技大学计算机学院59一般经验估算模型估算工作量、进度和成本的一般算法模型：202一般经验估算模型如，X=(项目复杂性，可靠性，人员经验，环境，…)为向量X各元素定值是由定性到定量的估算过程。如，将项目复杂性为（高，较高，一般，较低，低）的属性量化为（1.0,0.9,0.8,0.7,0.6）形式。当某软件项目复杂性评估为“较高”时，向量元素“项目复杂性”取值为0.9.其余向量元素的定值如法炮制。得到向量X各元素的值后，可按各元素的重要程度加权求和，最后得m(X)的值。

2023/7/31国防科技大学计算机学院60一般经验估算模型如，2023/7/31国防科技大学计算机学院一般经验估算模型表16.7给出几个基于代码行和功能点的估算模型，这些模型都是针对特定软件开发环境和项目数据库的数据得出的，应用时必须和具体的项目环境相结合，对参数进行修正，或修改项目调整因子中的向量元素。本节的其余部分介绍两个常用的估算模型：COCOMO模型、Putnam模型。2023/7/31国防科技大学计算机学院61一般经验估算模型表16.7给出几个基于代码行和功能点的估算表16.7基于代码行和功能点的

工作量估算模型基于代码行的模型

E=a(KLOC)b+cWalston-Felixa=5.200b=0.910c=0Bailey-Basilia=0.730b=1.160c=5.5Doty(KLOC>9)a=5.288b=1.047c=0基于功能点的模型

E=a+bⅹFPAlbrecht-Gaffneya=-91.40b=0.355Kemerera=-37.00b=0.960小型项目回归模型

a=-12.88b=0.4052023/7/31国防科技大学计算机学院62表16.7基于代码行和功能点的

工作量估算模型基于代码行的16.2.5COCOMO模型1981年Boehm提出“构造性成本模型”,简称COCOMO模型(ConstructiveCostModel)1989年COCOMO模型用于Ada软件开发2000年经进一步加工推出COCOMOⅡCOCOMO模型被广泛应用，经历了三十年的进化取得了较好的效果。原始的COCOMO模型是在软件工程的结构化时代，广泛采用瀑布模型的历史背景下产生的，是1980年代软件工程的一项重要成果。2023/7/31国防科技大学计算机学院6316.2.5COCOMO模型1981年Boehm提出“构造COCOMO模型原始的COCOMO模型是一个静态、单变量经验模型。模型将规模作为工作量（或成本）估算的主要因素，根据多个领域的56个软件项目数据库，从工程和经济两个方面的大量测量数据，提取调节因子得出经验公式。公式描述了开发系统的工作量或时间与系统规模、制品、过程、项目和团队之间的关系。Boehm把软件生存周期划分为:

计划需求、制品设计、详细设计、编码和单元测试、集成和系统测试

五个阶段。2023/7/31国防科技大学计算机学院64COCOMO模型原始的COCOMO模型是一个静态、单变量经验COCOMO模型COCOMO模型假设①软件项目管理、设施、保障满足软件项目过程需要，这部分工作量不列入COCOMO模型的工作量估算范围；②源代码行数不包括注释；③开发过程的工作量估算从设计开始，计划和需求获取额外处理；④一个人月包括152个小时。2023/7/31国防科技大学计算机学院65COCOMO模型COCOMO模型假设2023/7/31国防科COCOMO模型COCOMO模型分为基本、中间、详细三个层次。基本COCOMO模型用于系统开发初期，软件制品设计阶段，估算整个系统的工作量(包括软件维护)和软件开发所需要的时间。中间COCOMO模型用于软件的详细设计阶段，估算各子系统的工作量和开发时间。详细COCOMO模型用于估算独立的软构件，如子系统内部各模块，软件的集成和测试。2023/7/31国防科技大学计算机学院66COCOMO模型COCOMO模型分为基本、中间、详细三个层次图16.2软件项目工作量估算趋势随着软件开发的进展，能够提供的影响参数估算的消息逐步增多，精度越来越高，工作量的估算也趋于实际，但估算的预报功能也逐渐丧失软件开发过程终止时，软件开发工作量的估算值应收敛到核算值（如图

所示）。详细COCOMO请见［133］[135]。2023/7/31国防科技大学计算机学院67图16.2软件项目工作量估算趋势随着软件开发的进展，能够1.基本COCOMO模型基本COCOMO模型具有下列形式：E＝a(L)b(16-6)D＝c(E)d(16-7)其中：E表示工作量，单位是人月(PM)D表示开发时间，单位是月(M)L是项目的代码行估算值，单位是千行代码（KLOC）a,b,c,d是常数，取值如表16.8所示2023/7/31国防科技大学计算机学院681.基本COCOMO模型基本COCOMO模型具有下列形式：表16.8基本COCOMO模型参数软件类型abcd适用范围组织型2.41.052.50.38各类应用程序半独立型3.01.122.50.35各类实用程序、编译程序等

嵌入型3.61.202.50.32实时程序、控制程序、操作系统

公式给出了软件代码行数与工作量、工作量与开发时间的函数关系。Boehm把软件划分为组织型、半独立型和嵌入型三类，允许不同应用领域和复杂程度的软件按照上述三类软件的适用范围选取相应的参数a,b,c,d。2023/7/31国防科技大学计算机学院69表16.8基本COCOMO模型参数软件类型2.中间COCOMO模型软件类型ab组织型3.21.05半独立型3.01.12嵌入型2.81.20中间COCOMO模型以基本COCOMO模型为基础工作量估算公式中乘以工作量调节因子EAF，充分利用软件开发进入详细设计阶段的信息。中间COCOMO模型具有下列形式：E=a(L)bEAF(16-8)其中：L是项目的代码行估算值，

单位是千行代码。a,b是常数，取值如表所示。2023/7/31国防科技大学计算机学院702.中间COCOMO模型软件类型ab组织型3.21.05半中间COCOMO模型工作量调节因子EAF是软件项目15个要素的函数：①软件制品属性（软件可靠性、软件复杂性、数据库的规模）②计算机属性（程序执行时间、程序占用内存的大小、软件开发环境的变化、软件开发环境的响应速度）③人员属性（分析员的能力、程序员的能力、有关应用领域的经验、开发环境的经验、程序设计语言的经验）④软件项目属性（软件开发方法的能力，软件工具的质量和数量、软件开发的进度要求）。COCOMO模型要求为上述四种属性15个要素赋予要素调节因子Fi,i=1,2,...,15,Fi的值对应的属性状态可能是：很低、低、正常、高、很高、极高，共六级。Boehm推荐的Fi的取值范围如表16-10所示。正常情况下Fi=1。2023/7/31国防科技大学计算机学院71中间COCOMO模型工作量调节因子EAF是软件项目15个要表16.10COCOMO模型调节要素和

调节因子的范围调节要素i调节因子Fi的范围调节要素i调节因子Fi的范围制品属性可靠性

0.75-1.40数据库规模

0.94-1.16软件复杂性

0.70-1.65人员属性分析员能力

1.46-0.71应用经验

1.29-0.82程序员能力

1.42-0.70虚拟机经验

1.21-0.90语言经验

1.14-0.95计算属性执行时间限制

1.00-1.66主存限制

1.00-1.56虚拟机的变更

0.87-1.30计算等待时间

0.87-1.15项目属性现代实践的使用

1.24-0.82软件工具的使用

1.24-0.83开发进度约束

1.23-1.102023/7/31国防科技大学计算机学院72表16.10COCOMO模型调节要素和

中间COCOMO模型当15个Fi的值选定后，EAF的计算如下：(16-9)调节因子集的定义和调节因子定值是由统计结果和经验决定的。不同的软件开发组织，在不同的历史时期，随着环境的变化，软件开发的进展这些数据可能变化。显然，越到软件开发的中、后期调节因子的定值效果越好。使用中间COCOMO模型可以估算开发软件制品的工作量，比较各种开发方案对工作量的影响。2023/7/31国防科技大学计算机学院73中间COCOMO模型当15个Fi的值选定后，EAF的计算如例16.2用基本COCOMO模型估算例16.1的工作量、开发时间和参加项目开发的人数。在例16.1中，目标代码行数为33.3KLOC,CAD软件开发属于中等规模、半独立型从表16.9中查到a=3.0，b=1.12。代入公式E=3.0(L)1.12=3.0(33.3)1.12=152PM将E的估算值代入公式，并取C=2.5，d=0.35D=2.5(E)0.35=2.5(152)0.35=14.5MN=E/D=152/14.5≈11（人）

2023/7/31国防科技大学计算机学院74例16.2用基本COCOMO模型估算例16.1的工作量、中间COCOMO模型例16.2中计算出来的11人是粗略估计。在软件项目开发过程中，需要的11个人不可能都有相同的能力和个性，相同的经验和知识结构，并且在软件开发的各个阶段对人的要求也不同。若干人共同开发一个软件项目还应该增加他们之间相互通信和交换意见的额外工作量。N个程序员组成的小组，实现相同规模的程序，相互通信数为C2N=N(N-1)/2,设每次通信和交换意见的平均工作量为μ则增加的通信开销为：Ec＝μN(N-1)/2(16-10)2023/7/31国防科技大学计算机学院75中间COCOMO模型例16.2中计算出来的11人是粗略估计例16.3计算3人和5人开发一个程序的通信开销3人和5人开发一个程序相互通信和交换意见的关系如图16.3所示。将N=3和N=5分别代入公式Ec(3)＝μ3(3-1)/2＝3μEc(5)＝μ5(5-1)/2＝10μ2023/7/31国防科技大学计算机学院76

图16.3N=3和N=5时的相互通信关系

例16.3计算3人和5人开发一个程序的通信开销3人和5人中间COCOMO模型由N个程序员组成的小组共同开发一个程序总的工作量ET满足：ET=E+Ec于是，程序员小组的生产率是PG=LOC/(E+Ec)程序员小组生产率和单个程序员生产率的比为：Rp=E/(E+Ec)随着程序员小组人数的增加Ec≈μN2/2，程序员小组的生产率将会下降。模型说明，盲目增加程序员人数会推迟软件完成的日期.2023/7/31国防科技大学计算机学院77中间COCOMO模型由N个程序员组成的小组共同开发一个程序中间COCOMO模型以静态单变量COCOMO模型为基础，还可以定义估算资源R的静态多变量模型：其中：ei表示软件第i个特性,ai,bi是与软件第i个特性有关的常数，由实验数据的回归分析确定。Boehm给出一个大型嵌入式软件项目的工作量和进度分布，如表16.11所示。一般软件项目COCOMO工作分解默认的工作量分配如表16.12所示。2023/7/31国防科技大学计算机学院78中间COCOMO模型以静态单变量COCOMO模型为基础，还表16.11大型嵌入式软件项目的工作量和进度分布

活动工作量%时间%计划和需求

+8+36制品设计

1836详细设计

2518代码和单元测试

2618集成和集成测试

31282023/7/31国防科技大学计算机学院79表16.11大型嵌入式软件项目的工作量和进度分布表16.12一般软件项目COCOMO工作分解默认的工作量分配活动工作量%

需求分析

4制品设计

12实现

44测试计划

6V&V14项目管理

7配置管理和质量保证

7编写使用手册

62023/7/31国防科技大学计算机学院80表16.12一般软件项目COCOMO工作分解默认的工作量16.2.6COCOMOII模型二十世纪九十年代，迭代式软件开发过程、面向对象、基于构件、软件复用、使用四代语言4GL等方法应用广泛，网络软件逐步兴起，软件开发的制品、过程、方法、工具和环境有了很大变化系统中有些软件是自主开发的，有些是现成的，而另一些是经过维护后采用的。传统的COCOMO模型己不适应现代软件开发方法1995年Boehm对COCOMO模型进行了扩充，称COCOMOII,估算工作量的公式是

E=a(L)bEAF＋ER2023/7/31国防科技大学计算机学院8116.2.6COCOMOII模型二十世纪九十年代，迭代式COCOMOII模型公式的第一项与公式(16-8)形式相同第二项ER表示复用构件、代码自动生成需要的工作量，单位以人月计参数a,b，EAF的选择依赖于软件开发的时间结点。对于COCOMOII模型Boehm认为，应在三个时间点上根据软件过程的特点及软件开发信息库提供的信息分别进行工作量估算。这三个时间点是，①系统需求确定后；②概要设计、设计原则、环境、复用构件确定后；③软件体系结构细节基本确定时。如图16.4所示。2023/7/31国防科技大学计算机学院82COCOMOII模型公式的第一项与公式(16-8)形式图16.4迭代模型软件项目估算的

精度趋势2023/7/31国防科技大学计算机学院83图16.4迭代模型软件项目估算的

精度趋势2023/7/3COCOMOII模型对于RUP迭代模型可将系统需求分解，软件项目估算要与需求分解相对应。对确定的需求和增量逐个进行估算后，将所有需求和增量的估算相加，得到整个项目的估算。在对确定的需求和增量进行估算时，需求工作流和设计工作流在初始阶段和细化阶段需要多次交互。初始阶段结束时，软件需求获取基本完成，这次迭代系统的需求场景基本确定。2023/7/31国防科技大学计算机学院84COCOMOII模型对于RUP迭代模型可将系统需求分解，软COCOMOII模型但软件开发信息库还不具备采用功能点和代码行估算这次迭代软件开发规模的条件。为此，COCOMOII估算模型采用对象点估算开发软件的规模。对象点开发软件的屏幕数、报告数、第三代语言构件数等要素估算软件项目规模。要素由计算机辅助软件工程环境定义，可借助高层工作量生成器进行统计。每个要素分为简单、适中或难3个级别，分别赋予三个不同的权值（1，2，3）。利用15.2节介绍的对象点度量方法估算对象点数。2023/7/31国防科技大学计算机学院85COCOMOII模型但软件开发信息库还不具备采用功能点和代COCOMOII模型统计出所有对象点OPi(i=1,2,…,k)后，可根据开发人员的经验和能力、CASE成熟度确定生产率因子pi（表16.13给出pi的统计值）。生产率因子pi是对大量软件项目和团队在通常的软件开发环境支持下，对完成各类对象点所需工作量的统计结果，应存放在COCOMOII的支持工具中。第i类生产率因子PiPi=OPi/PMii=1,2,…,k(16-16)其中OPi表示第i类要素对象点个数PMi表示完成OPi个对象点所需的人月数2023/7/31国防科技大学计算机学院86COCOMOII模型统计出所有对象点OPi(i=1,2COCOMOII模型如果开发人员经验和能力被认为“低”，CASE成熟度和能力也是“低”，那么从表16.13查出生产率的值是每人月7个对象点。所需人月数是对象点数除以7。当开发人员的经验“低”，但CASE成熟度“高”时，生产率估算是两个值的平均p=（7+25）/2=16。表16.13选择生产率因子开发人员的经验和能力非常低低一般高非常高CASE成熟度和能力非常低低一般高非常高生产率因子(对象点/人月)pj471325502023/7/31国防科技大学计算机学院87COCOMOII模型如果开发人员经验和能力被认为“低”，CCOCOMOII模型于是，估算工作量

EPM=PMi=OPi/piCOCOMOII的支持工具应不断收集、充实各类对象点度量及完成工作量的数据（OPi，PMi），适时增加或调整生产率因子Pi的类型，提高统计精度和置信度。为提高初始阶段工作量估算精度打下基础。细化阶段结束后，软件系统的功能、体系结构基本确定、与对象点相比，这时的软件开发信息库可以提供更多的软件描述细节，可以使用功能点对软件系统规模进行估算，估算的精度会有较大提高。细化阶段的工作量估算采用COCOMOII的计算公式2023/7/31国防科技大学计算机学院88COCOMOII模型于是，估算工作量2023/7/31COCOMOII模型指数b的取值范围是[1.01，1.26]，取决于开发组织在应用领域的经验、软件开发过程的灵活性、风险预测和解决情况、开发团队的凝聚力、过程成熟度5个要素。调节因子EAF取决于制品可靠性和复杂性、可复用构件数、平台困难程度、个人能力、个人经验、项目进度、支持设施7个要素。在构造阶段，软件详细设计、编码、测试全面展开，软件开发信息库有更多的详细信息可以利用，采用功能点或代码行进行规模估算可以获得较为准确的结果。指数b的取值与细化阶段相同，调节因子EAF取决于制品可靠性、复杂性、执行时间、主存限制、平台经验、平台变更、应用经验、语言/工具经验、文档、复用、程序员能力等17个要素。2023/7/31国防科技大学计算机学院89COCOMOII模型指数b的取值范围是[1.01，1.26COCOMOII模型常用的COCOMOII模型估算工具：Costar()EstimateProfessional()COCOMOII的详细讨论请参考[133][135]2023/7/31国防科技大学计算机学院90COCOMOII模型常用的COCOMOII模型估算工具：16.2.7Putnam模型1978年，Putnam提出了大型软件项目(一般在30人年以上)的工作量估算模型。它是动态多变量模型，适用于软件开发的各个阶段，估算模型以大型软件项目的实测数据为基础，导出如图16.5所示的工作量分布曲线。该曲线与著名的Rayleigh-Norden(R-N)曲线的形状相似它描述了开发工作量，开发时间和软件代码行数之间的关系。2023/7/31国防科技大学计算机学院9116.2.7Putnam模型1978年，Putnam提图16.5大型软件项目的工作量分布2023/7/31国防科技大学计算机学院92图16.5大型软件项目的工作量分布2023/7/31国防科技Putnam模型方程L=CkE1/3td4/3

（16-18）其中：

L表示源程序代码行数

E表示工作量(以人年记，包括维护)

td表示开发时间

Ck表示软件开发环境

的常数，取值如表

所示。软件开发环境

CK的值比较差

2000一般

8000比较好

110002023/7/31国防科技大学计算机学院93Putnam模型方程软件开发环境差的软件开发环境指，软件开发没有方法学的支持，缺乏对文档的评审，采用批处理方式。一般的软件开发环境应有软件开发方法学的支持，有适宜的文档和评审，采用交互处理方式。好的软件开发环境应采用CASE工具和集成化CASE环境。由(16-18)有

E＝L3/(CK3td4)

(16-19)td对应于Rayleigh-Norden曲线的最大值，表示软件交付时工作量最大，参与软件项目的人最多。2023/7/31国防科技大学计算机学院94Putnam模型差的软件开发环境指，软件开发没有方法学的支持，缺乏对文档的评Putnam模型当工作量估算出来之后，利用每人年的开销($/PY)可以估算成本。公式(16-19)表明，开发软件项目的工作量与交货时间的4次方成反比，将0.9td代入(16-19)式的td计算E，我们发现，提前10%的时间要增加52%的工作量，降低了软件开发生产率。软件开发过程中，人员与时间的折衷十分重要。2023/7/31国防科技大学计算机学院95Putnam模型当工作量估算出来之后，利用每人年的开销($图16.6软件开发时间与人力投入的关系图16.6(a)所示曲线表明，软件开发项目每年所需要的人年数与开发时间t的关系满足Rayleigh-Norden分布，相应的累计人年数与开发时间t的关系如图16.6(b)所示。2023/7/31国防科技大学计算机学院96图16.6软件开发时间与人力投入的关系图16.6(a)所示Putnam模型曲线表明：软件开发项目的工作量随着时间t的增长并不呈线性增长趋势。参加软件项目开发的人员数目不应该是一成不变的。图16.6表明，如果按照线性分布方案配备人员，即每年的人数是常数。这样初始段将有部分人力是多余的，而峰值段人力又不够，到项目后期再增加人力为时已晚，造成浪费。由于人力调度的不合理，不得不延长项目开发时间，增加一部分额外工作量。2023/7/31国防科技大学计算机学院97Putnam模型曲线表明：软件开发项目的工作量随着时间t的Putnam模型Putnam模型虽然揭示了软件项目的工作量、软件开发时间和程序代码长度三者之间的关系，但它没有反映软件制品、软件项目、软件开发人员、计算机软硬件资源等属性。用Putnam模型进行软件项目的成本估算是十分粗糙的。软件项目度量的进一步讨论请参阅[1][3][113][114][115][116][133][134][135]PriceS(WWW.)CostXpert()SLIM-Estimate(WWW.)2023/7/31国防科技大学计算机学院98Putnam模型Putnam模型虽然揭示了软件项目的工作量16.3风险分析与任何其他工程项目一样，软件工程项目的开发也存在各种各样的风险，有些风险甚至是灾难性的。R.Charette认为，风险与将要发生的事情有关，它涉及诸如思想、观念、行为、地点、时间等多种因素；风险随条件的变化而改变，人们改变、选择、控制与风险密切相关的条件可以减少风险，但改变、选择、控制条件的策略往往是不确定的。2023/7/31国防科技大学计算机学院9916.3风险分析与任何其他工程项目一样，软件工程项目的开发风险分析软件开发过程中，人们关心的问题是，什么风险会导致软件项目的彻底失败?顾客需求、开发环境、目标机、时间、成本的改变对软件项目的风险会产生什么影响?必须抓住什么机会、采取什么措施才能有效地减少风险、顺利完成任务?所有这些问题都是软件开发过程中不可避免并需要妥善处理的。2023/7/31国防科技大学计算机学院100风险分析软件开发过程中，人们关心的问题是，2023/7/31风险分析软件工程风险分析的任务

找出并标识对项目构成威胁的各类风险，通过风险估算量化风险的不确定性和可能带来的损失程度，在此基础上制定风险管理和监控计划，实施风险管理。本节将分别介绍风险标识、风险估算、风险评价和风险管理。2023/7/31国防科技大学计算机学院101风险分析软件工程风险分析的任务2023/7/31国防科技大学16.3.1风险标识宏观上，风险可以分为项目风险、技术风险和商业风险三类。由于项目在预算、进度、人力、资源、顾客和需求等方面的原因对软件项目产生的不良影响称为项目风险。软件在设计、实现、接口、验证和维护过程中可能发生的潜在问题，如规约的二义性、采用陈旧或尚不成熟的技术等等，对软件项目带来的危害称技术风险。2023/7/31国防科技大学计算机学院10216.3.1风险标识宏观上，风险可以分为项目风险、技术风险风险标识开发了一个没人需要的优质软件，或销售部门不知如何推销这一软件产品，或开发的产品不符合公司的产品销售战略等等称为商业风险。这些风险有些是可以预料的，有些是很难预料的。为了帮助项目管理人员、项目规划人员全面了解软件开发过程存在的风险，Boehm建议设计并使用各类风险检测表标识各种风险。例16.4给出一个参考性的“人员配备风险检测表”。2023/7/31国防科技大学计算机学院103风险标识开发了一个没人需要的优质软件，或销售部门不知如何推销例16.4人员配备风险检测表(1)开发人员的水平如何。(2)开发人员在技术上是否配套。(3)开发人员的数量如何。(4)开发人员是否能够自始至终地参加软件开发

工作。(5)开发人员是否能够集中全部精力投入到软件

开发工作。(6)开发人员对自己的工作是否有正确的期望。(7)开发人员是否接受过必要的培训。(8)开发人员的流动是否能够保证工作的连续性。2023/7/31国防科技大学计算机学院104例16.4人员配备风险检测表(1)开发人员的水平如何。2人员配备风险检测表上述问题可以选用0,1,2,3,4,5来回答。完全肯定取值为0，反之为5，中间情况分别取值1,2,3,4，值越大表示风险越大。人员配备风险检测表反映了人的因素对软件项目的影响，可以用它来估算人的因素对软件项目带来的风险。2023/7/31国防科技大学计算机学院105人员配备风险检测表上述问题可以选用0,1,2,3,4,5来回16.3.2风险估算软件项目管理人员可以从影响风险的因素和风险发生后带来的损失两方面来度量风险。为了对各种风险进行估算，必须建立风险度量指标体系；必须指明各种风险带来的后果和损失；必须估算风险对软件项目及软件产品的影响；必须给出风险估算的定量结果