软件管理工程课件

软件管理工程I.管理工程的重要性和意义II．项目管理III．配置管理1软件管理工程I.管理工程的重要性和意义1I.管理工程的重要性和意义管理是实现软件工程基本目标的保证。软件工程管理引起广泛注意源于20世纪70年代中期，当时发现不成功的项目70%是因为管理不善而引起。20世纪90年代中期，美国的软件开发仍然很难预测，大约只有10%的项目能够在预定的费用和进度下交付。2I.管理工程的重要性和意义管理是实现软件工程基本目标的保II.项目管理1．管理的内容2．管理过程的主要活动3II.项目管理1．管理的内容3管理的内容 要完成的任务； 需要的资源（人、软／硬件）； 花费的工作量（成本）；可能遇到的风险；工作进度。4管理的内容 要完成的任务；4管理过程的活动

一。制定计划二。度量三。估算四。风险管理五。计划实施、追踪控制5管理过程的活动一。制定计划5一。软件项目计划的基本问题1。计划的重要性2。谁负责以及何时制定计划？3。项目计划的特点4。项目计划包括哪些子计划？5。软件过程和SPP6。SPP的动态性7。项目策划的主要步骤6一。软件项目计划的基本问题1。计划的重要性61.计划的重要性项目计划是为实现预定目标而作的科学预测，以它为基准跟踪和控制项目的开发它确定未来的行动方案和资源分配，引导项目的实施项目计划的质量是决定项目成败、优劣的关键因素之一71.计划的重要性项目计划是为实现预定目标而作的科学预测，以它2.谁负责以及何时制定计划？项目经理负责制定计划，项目组成员参与。软件项目开发计划是指导项目的纲，应尽早制定。在项目定义阶段，只要明确了软件项目的目标和软件要实现的基本功能；只要项目人员明白用户的意图就应制定。有时也称初始计划为基础计划。通过初始计划的制定，项目经理能熟悉项目工作的基本方面：范围、需求、总的时间和里程碑、组织机构、人员要求等。它确定了生存周期，管理过程、技术过程等。这些在项目过程中，变化不会太大。82.谁负责以及何时制定计划？项目经理负责制定计划，项目组成员3.项目计划的特点它是文档化的，而不是只在经理的脑袋里描述任务；如何作，包括资源，时间周期，可接受的偏差范围等可读性好模块化足够简炼，让人愿意看项目计划中应包括所有的项目管理问题93.项目计划的特点它是文档化的，而不是只在经理的脑袋里94.项目计划包括哪些子计划？项目计划中包括：SDP计划－软件开发计划SQA计划－软件质量保証计划SCM计划－配置管理计划测试计划风险计划培训计划跟踪计划……104.项目计划包括哪些子计划？项目计划中包括：105。软件过程和SPP任何项目都有自己确定的过程。过程管理对软件尤为重要。无论在CMM的哪个等级，都必须将过程文档化。但一般项目确定的软件过程描述不够明确以致不能直接执行。SDP中以各种方式（如索引）包含项目过程的描述，但建立项目过程并不是SPP的任务。SDP在项目已确定的软件过程的基础之上建立。项目的SDP在项目确定的软件过程（将做什么和如何作）和项目的具体完成方式（例如，谁将按照什么进度生成哪个工作产品）之间建立联系。例如，SCM、设计等。115。软件过程和SPP任何项目都有自己确定的过程。过程管理对软6。SPP的动态性众所周知，项目策划是基于当前已有的信息(包括过去的经验，当前项目的目标、范围、组织结构、资源等)，安排工作和进度，预测作业结果随着项目的进展、信息的增多和理解的深入，预测会逐渐地接近实际，所以对任何类型的项目来说，计划的修订不可避免软件项目计划将不断修订，贯穿全生存周期(SPP活动3)；每次修订应按CMM中SPP-KPA的要求进行。126。SPP的动态性众所周知，项目策划是基于当前已有的信息(包7.项目策划的主要步骤定义可交付产品(what,why,when,how)估计和策划工作量和成本协商各方约定(who,where)安排进度和资源，使能按时交付编写计划Gantt图和PERT图137.项目策划的主要步骤定义可交付产品(what,why,有关进度的安排和监控几个问题（1）任务分解结构（2）甘特图（3）PERT技术和CPM技术（4）开发模块的任务网络图示例（5）分层任务网络图（6）关键路径分析14有关进度的安排和监控几个问题（1）任务分解结构14（1）工作分解结构

(WBS-workBreakdownstructure)概述WBS中的层次结构WBS的构造将两者混合的WBS的例子WBS在项目“阶段”的应用WBS的局限性传统的WBS及产品层次传统的WBS的基本缺陷进化的WBS一个缺省的进化的WBS15（1）工作分解结构

(WBS-workBreakdow概述WBS用于策划（制定计划），跟踪、控制。WBS是项目计划的“构架”。在整个项目生命周期中，它必须用适当的细节等级封装变更和进化。WBS以层次结构组织项目活动的元素，将项目分解成易于管理的活动进化的WBS的组织方式与传统的WBS的组织方式不同16概述WBS用于策划（制定计划），跟踪、控制。WBS是项目WBS中的层次结构产品的层次结构指明各种软件的构件如何安置在软件系统中反映软件产品的基本结构，由软件设计者确定构件有：例行程序(routine)、模块、子系统等活动的层次结构指明处理一个软件构件的各种方法合适时，活动层次的一部分可以运用到产品的任何一个层次可以将两者混合WBS关注如何组织它们，以便能最适合项目的特征17WBS中的层次结构产品的层次结构17WBS的构造迭代式构造构造有意义的逐步细分的层次结构向下细分到能实际作出策划和控制的层次，但是不要太碎综合自顶向下和由底向上两种方法采用混合的产品/活动的层次结构18WBS的构造迭代式构造18将两者混合的WBS的例子ACTIVITYBreak-upProductBreak-up19将两者混合的WBS的例子ACTIVITYBreak-upPWBS在项目“阶段”的应用如果项目按阶段进行对当前阶段作详细的分解对未来阶段保留不动当知道更多细节时，进一步分解为更细的WBS20WBS在项目“阶段”的应用如果项目按阶段进行20WBS的局限性不能显示执行任务的序列性不能显示任务间的依赖性要用网络描述进度安排21WBS的局限性不能显示执行任务的序列性21传统的WBS及产品层次 系统需求和设计 子系统1 构件11 需求 设计 编码 测试 文档 …（其它构件的相似结构） 构件1n

需求 设计 编码 测试 文档 …（其它构件的相似结构）

集成和测试 测试计划 测试过程准备 测试 测试报告 其它支持领域 配置控制 质量保证 系统管理

子系统M

构件M1

需求 设计 编码 测试 文档 …（其它构件的相似结构） 构件Mn

需求 设计 编码 测试 文档 …（其它构件的相似结构）22传统的WBS及产品层次 系统需求和设计 22传统的WBS的基本缺陷(1)传统的WBS的三个基本缺陷。(A)过早地围绕产品设计进行了结构化：如果计划和产品构架都已经成熟，那么将二者紧密结合起来是合理的。如果计划或是构架需要改变时，松散的结合则更为合适。23传统的WBS的基本缺陷(1)传统的WBS的三个基本缺陷。23传统的WBS的基本缺陷(1)传统的WBS的三个基本缺陷。(B)过早地在过于详细或过于简单的细节上进行分解、计划和预算：大型软件项目容易计划过剩，小型软件项目则容易计划不足24传统的WBS的基本缺陷(1)传统的WBS的三个基本缺陷。24传统的WBS的基本缺陷(1)传统的WBS的三个基本缺陷(C)传统的WBS是项目相关的，交叉项目通常很难比较或者根本不可能比较：没有标准的WBS，要在多个项目之间比较计划、财务数据、进度数据、组织效率、成本趋势、生产力趋势或质量趋势是极其困难的。25传统的WBS的基本缺陷(1)传统的WBS的三个基本缺陷25传统的WBS的基本缺陷(2)使用传统的WBS的项目群组，多数无法回答下面这些简单的问题，而这些问题对于有组织的过程改进是很关键的：(A)生产活动(需求、设计、实现、评估和实施)与日常管理活动(管理和环境)的比率如何？(B)花在返工活动的工作量的百分比是多少？(C)花在软件基本设备(环境开销)上的成本所占的百分比是多少？(D)生产性测试与(非生产性)集成的比率是多少？26传统的WBS的基本缺陷(2)使用传统的WBS的项目群组，多数进化的WBS进化的WBS围绕过程框架组织计划的元素，而不是围绕产品框架组织这些元素。

27进化的WBS进化的WBS围绕过程框架组织计划的元素，而不是关于进化的WBS的建议第一级WBS元素是工作流(管理、环境、需求、设计、实现、评估和实施)。这些元素通常分配给单一的群组，它们构成了用于项目的计划和项目间比较的解剖结构。第二级元素是为生命周期的阶段而定义的(初始、细化、构造和移交)。这些元素允许项目计划以更加自然的方式精确地理解需求、构架和内在风险。第三级元素是为生产各阶段制品的活动而定义的。这些元素可能是结构中级别最低的，用来对给定阶段的离散制品进行成本结算，或许它们可以进一步分为几个更低层次的活动一起共同生产一个制品。28关于进化的WBS的建议第一级WBS元素是工作流(管理、一个推荐的进化的WBS(1)

A管理

AA初始阶段管理

AAA业务案例开发

AAB细化阶段发布规格说明

AAC细化阶段WBS基线的制定

AAD软件开发计划

AAE初始阶段项目控制和状态评估

AB细化阶段管理

ABA构造阶段发布规格说明

ABB构造阶段WBS基线的制定

ABC细化阶段项目控制和状态评估

AC构造阶段管理

ACA实施阶段计划

ACB实施阶段WBS基线的制定

ACC构造阶段项目控制和状态评估

AD移交阶段管理

ADA下一代计划

ADB移交阶段项目控制和状态评估

C 需求

CA初始阶段需求开发

CAA可视化规格说明

CAB用况建模

CB细化阶段需求基线的制定

CBA可视化基线的制定

CBB用况模型基线的制定

CC构造阶段需求维护

CD移交阶段需求维护

D 设计

DA初始阶段构架原型

DB细化阶段构架基线的制定

DBA构架设计建模

DBB设计演示计划并实施

DBC软件构架描述

DC构造阶段设计建模

DCA构架设计模型维护

DCB构件设计建模

DD移交阶段设计维护B环境

BA初始阶段环境规格说明

BB细化阶段环境基线的定制

BBA开发环境安装与管理

BBB开发环境集成与定制工具制造

BBCSCO数据库简洁陈述

BC构造阶段环境维护

BCA开发环境安装与管理

BCBSCO数据库维护

BD移交阶段环境维护

BDA开发环境维护与管理

BDBSCO数据库维护

BDC维护环境包装与移交一个缺省的进化的WBS是与过程框架(阶段、工作流和制品)相一致的29一个推荐的进化的WBS(1)A管理C 需求B一个推荐的进化的WBS(2)

E 实现

EA 初始阶段构件原型

EB 细化阶段构件实现

EBA关键构件编码演示集成

EC 构造阶段构件实现

ECA初始阶段发布构件编码与单机测试

ECBAlpha发布构件编码与单机测试

ECCBeta发布构建编码与单机测试

ECD构件维护

ED 移交阶段构件维护

G 实施

GA 初始阶段实施计划

GB 细化阶段实施计划

GC构造阶段实施

GCA用户手册基线的制定

GD 移交阶段实施

GDA产品向用户移交F评估

FA 初始阶段评估计划

FB 细化阶段评估

FBA测试建模

FBB构架测试情景实现

FBC演示评估与发布说明书

FC 构造阶段评估

FCA初始发布评估与发布说明书

FCBAlpha发布评估与发布说明书

FCCBeta发布评估与发布说明书

FD 移交阶段评估

FDA产品发布评估与发布说明书30一个推荐的进化的WBS(2)E 实现G 实施F一个推荐的进化的WBS(3)这个推荐的结构示范了如何按照过程框架元素制订计划。它提供了一个框架，用于估计每个元素的成本和进度，在一个项目组织中分配元素，跟踪开支。所示的结构需要根据项目的以下特点剪裁。A.规模。更大型的项目需要更多层次和子结构。31一个推荐的进化的WBS(3)这个推荐的结构示范了如何按照过程一个推荐的进化的WBS(4)B.组织结构。包含子承包商或跨多个组织实体的项目可能会引进对不同WBS的分配限制。C.定制开发的程度。D.业务环境。合同性项目要求更加细致的管理和评估元素。开发商业产品的项目可能需要更加细致的实施元素基础。局限在单个站点的应用程序可能有一个很简陋的实施元素或者一个精致的实施元素。E.经验。32一个推荐的进化的WBS(4)B.组织结构。包含子承包商或（1）Gantt图33（1）Gantt图33（2）PERT技术和CPM技术(1)PERT和CPM技术是安排开发进度，制定软件计划的最常用的方法。两种技术都是由较早的项目计划活动中已经产生的信息来驱动。计划评价和评审技术(ProgramEvaluation&Review Technique-PERT)关键路经(CriticalPathMethod–CPM)34（2）PERT技术和CPM技术(1)PERT和CPM技术是安PERT技术和CPM技术(2)任务网络图描述任务之间的依赖关系任务分解结构—定义可针对整个产品，也可针对单个功能。两种方法都提供项目工作定量划分的工具，支持：确定关键路经，决定项目持续时间的任务链通过统计模型为单个任务建立最有可能的时间估计计算为特定任务定义其时间“窗口”的边界时间。35PERT技术和CPM技术(2)任务网络图35PERT技术和CPM技术(3)重要的边界时间某个任务的最早开始时间是当其所有前驱任务在最短的可能时间中完成时某个任务的最晚开始时间是在不延迟项目最小完成时间的前提下，最晚启动该任务的时间最早结束时间是最早开始时间加上任务持续时间最晚结束时间是最晚开始时间加上任务持续时间总浮动量是在保证进度的前提下，调度任务时所允许的富裕时间或回旋时间总和36PERT技术和CPM技术(3)重要的边界时间36（3）开发模块的任务网络图示例A：公共模块模块B：新编模块，依赖A的完成C：已有模块，修复缺陷。依赖A的完成起点A编码B编码A测试A调试C理解C修改B测试B调试C测试C调试BC组装测试04123657837（3）开发模块的任务网络图示例A：公共模块模块起点A编码B编（4）分层任务网络图起点A编码B编码A测试A调试C理解C修改B测试B调试C测试C调试BC组装测试04123657838（4）分层任务网络图起点A编码B编码A测试A调试C理解C修改（5）关键路径分析某软件项目的PERT图，圆框中的数字代表活动的周数，请找出关键路径和完成项目的最短时间起点终点A3B6C5F5G7H4I6J6E3D639（5）关键路径分析某软件项目的PERT图，圆框中的数字代表活二软件度量什么是软件度量软件度量的作用软件度量的主要内容40二软件度量什么是软件度量40什么是软件度量度量在现实世界中，把数字或符号指定给实体的某一属性，以便根据已明确的规则来描述它们。软件度量就是在软件开发过程中把反映或影响软件开发成本、开发效率、软件质量的各种数据测量出来并记录下来。41什么是软件度量度量在现实世界中，把数字或符号指定给实体的某一软件度量的作用为了有效地定量地进行管理。是进行计划、估算、风险分析、过程监控、质量监控、评价等活动的基础。是改进过程提高软件质量的重要手段。42软件度量的作用为了有效地定量地进行管理。是进行计划、估算、风软件度量的主要内容过程属性的度量产品属性度量43软件度量的主要内容过程属性的度量43过程属性的度量工作量度量工作时间度量资源费用度量事件度量44过程属性的度量工作量度量44工作量度量工作产品(对象)标识：项目、文档、模块工作内容： 调研、编写文档、编码、测试、评审、改错、项目例会工作成果量： 文档页数、代码行数、模块数、发现或纠正的错误数工作量： 人月、人周、人时45工作量度量工作产品(对象)标识：45资源费用度量工作产品(对象)标识： 项目、模块时间： 起止年/月/日资源：人数、设备数、支持工具数、资金数、场地面积46资源费用度量工作产品(对象)标识： 46事件度量工作产品标识：项目发生时间：年/月/日事件描述：更改、偏离计划（进度、费用）处理结果：更改/不更改、处理花费（损失）事件发生总数或频率47事件度量工作产品标识：项目47产品属性度量面向产品规模的度量。面向功能点的度量错误缺陷及改正率度量测试覆盖率测量生产率、单位成本的计算48产品属性度量面向产品规模的度量。48规模度量的基本方法因为估计受到许多因素的影响，如人、技术、环境、政策等，因此，软件的规模、成本和工作量等都还没有一个精确的计算方法。我们主要研究软件规模的估计，它基于：软件的代码行(LineofCode–LOC)软件的功能点(FunctionPoints-FP)软件的用例(UseCase)49规模度量的基本方法因为估计受到许多因素的影响，如人、技术、面向产品规模的度量工作产品标识：项目、模块代码行数：千行语句数、字符数、字节数注释率：注释语句数/代码行数错误数／KLOC文档页数／KLOC成本／KLOCKLOC数／人月50面向产品规模的度量工作产品标识：项目、模块50代码行的计算度量方法可执行的行数可执行的行数＋数据定义可执行的行数＋数据定义＋注释屏幕上输入的物理行数逻辑分隔符号行计算的类型仅新行新的＋修改的新的＋修改的＋重用的所有交付的＋临时支撑的代码所有交付的＋临时支撑的代码和支持代码51代码行的计算度量方法行计算的类型51面向产品规模度量的特点代码行是开发项目的生成品，容易计算；依赖于程序设计语言；必须在项目完成后才能得到数据。52面向产品规模度量的特点代码行是开发项目的生成品，容易计算；5面向功能的度量工作产品标识：项目、规模；功能点数FD；每个功能点的错误数；每个功能点的文档数；每个功能点的成本；每人月完成的功能点数。53面向功能的度量工作产品标识：项目、规模；53功能点计算的参数用户输入数据数：在系统运行时要用户输入的数据用户输出数据数：在系统运行时用户要求输出的数据用户请求（查询）数：用户交互式有实时响应的次数内部文件数（数据库）：数据库中与本系统有交换的数据结构数外部文件数：本系统运行时机器可读的有交换的外系统数据结构数54功能点计算的参数用户输入数据数：在系统运行时要用户输入的数据功能点计算方法

加权因数直接测量项 计数简单中间复杂加权计数用户输入数据数 346用户输出数据数 45 7用户请求（查询）数 34 6内部文件数 71015外部文件数 5710总计数功能点FP=总计数×（0.65+0.01×SUM(Fi)）Fi(i=1···14)为其它影响因素对计算功能点的校正值。Fi取值范围从0到555功能点计算方法 影响因素56影响因素56功能点度量的特点与程序设计语言无关在评估的早期就可知道数据依赖于主观经验57功能点度量的特点与程序设计语言无关57调和不同的度量方法代码行（软件规模）和功能点数之间的关系依赖于程度设计语言和设计质量。下表给出了不同程序设计语言中，建造一个功能点所需的平均代码行数。程序设计语言LOC/FP(平均值)程序设计语言LOC/FP(平均值)汇编语言CCobolFortranPascalAda3201281051059070面向对象语言第四代语言(4GLs)代码生成器电子表格图形语言(图标)3020156458调和不同的度量方法代码行（软件规模）和功能点数之间的关系依赖错误缺陷及改正率度量工作产品标识产品规模 千行代码或功能点数测试级别单元测试、集成测试、(第几遍测试)错误级别 分三级或五级错误个数改正个数错误率 错误数/软件规模改正率 改正错误数/发现错误数59错误缺陷及改正率度量工作产品标识59测试覆盖率测量工作产品标识语句覆盖率 试经历语句数/总语句数分支覆盖率 测试经历支路数/总支路数简单路径覆盖率 测试经历简单路径数/总简单 路径数60测试覆盖率测量工作产品标识60生产率、单位成本的计算生产率＝工作成果／工作量单位成本＝资源消耗折算成的成本（元）／产生的成果（最终成果）61生产率、单位成本的计算生产率＝工作成果／工作量61七个核心度量元概述度量元目的视角工作和进展迭代计划，计划与实际情况，管理指标SLOC，功能点，对象点，情景，测试用例，SCOs(SoftwareChangeOrder)预算成本和开支财务洞察，计划与实际对比，管理指标每月的成本，每月的全职人员，实际花费占预算的百分比人员结构和群组动力学计划资源与实际资源对比，雇佣率，离职率每月增加的人数，每月离职的人数变更量和稳定性迭代计划，进度收敛的管理指标打开的SCO和关闭的SCO，按类型(0,1,2,3,4)和发布/构件/子系统分类。变更范围和模块度收敛，软件废品，质量指标每次变更返工的SLOC，按类型(0,1,2,3,4)和发布/构件/子系统分类。返工和适应性收敛，软件返工，质量指标每次变更的平均小时数，按类型(0,1,2,3,4)和按发布/构件/子系统分类。平均无故障时间和成熟度测试覆盖/合适性，使用的健壮性，质量指标故障计数，故障发生前的测试小时数，按发布/构件/子系统分类。62七个核心度量元概述度量元目的视角工作和进展迭代计划，三。软件估计软件估计的基本问题基本估计方法CMM对估计的要求规模度量的基本方法COCOMO模型面向功能点的估计加权平均法Delphi估计法63三。软件估计软件估计的基本问题COCOMO模型63软件估计的基本问题(1)

软件估计过程软件估计过程由如下的步骤组成：估计规模；估计成本和工作量；估计进度；估计关键计算机资源；评估风险；审查/批准；跟踪与报告估计；度量与改进过程。64软件估计的基本问题(1)

软件估计过程软件估计过程由如下的软件估计的基本问题(2)

进行估计时应注意的问题1。至少使用两种方法进行估计，以提供交叉检查单独估计的手段，并增加总估计的可信度。至少由两个人进行估计。对于大型项目，应有三个或更多人参加估计。2。在项目的早期，应完成手工估计，并应使估计者理解自动工具使用的过程和参数。在完成手工估计后，再使用自动工具进行一次估计，以便自动工具不会影响手工估计。在使用自动工具时，如果可能，应校准模型，以更好地反映来自项目域的历史数据，从而可以改进结果。65软件估计的基本问题(2)

进行估计时应注意的问题软件估计的基本问题(2)

进行估计时应注意的问题3。应该比较两个估计的结果，对于任何不一致都要解释其原因。多大的不一致是可接受的，取决于项目所处生命周期的阶段。项目的早期，在20%以内的估计是合理的。随着项目成熟，估计应该趋于集中。4。这种比较的方法也应在规模估计和进度估计时使用。所有假设和输入应该文档化，并归入软件估计文件(SEF)。66软件估计的基本问题(2)

进行估计时应注意的问题3。软件估计的基本问题(3)

软件估计的动态性软件估计是制定软件计划的基础。软件估计是一个持续过程，应该用于项目的整个生命周期。67软件估计的基本问题(3)

软件估计的动态性软件估计是制定软件基本估计方法自顶向下与由底向上相结合自顶向下：整体->阶段->工作单元。估计工作量小，结果有盲目性。由底向上：工作单元->阶段->整体。容易拉掉一些管理工作量，结果易偏低。差别估计：与历史项目比较。集中上述两方法，有时不容易找到相似的项目。

只有对项目选定一种（或几种）能够改进的估计方法，并将多次估计的结果进行比较，才能积累经验和数据，估计才能越来越准确。68基本估计方法自顶向下与由底向上相结合68由底向上的估计法当一个待解决的问题过于复杂时，可以把它进一步分解(WBS)，直到分解后的子问题变得容易解决为止。然后分别解决每一个子问题。从而能根据历史数据估算出每个子功能的规模。例如把问题逐级分解直到分解成“录入功能”、“计算功能”、“排序功能”、“报表生成功能”、“……”，使软件人员对每个问题都能较容易地映射到过去的经验，将这些子问题的解答综合起来，从而得到原问题的解答。69由底向上的估计法当一个待解决的问题过于复杂时，可以把它进一步成本和进度的估计过程(1)

自顶而下的方法项目计划需要从两个视角考虑。第一个是向前观望、自顶而下的方法。从一个普通的需求和限制开始，得到一个宏观级别的预算和进度，然后，将这些元素细分到较低级别预算和中间里程碑。从这个视角，会发生下面的计划序列：1。软件项目经理（和其他人）开发出项目所需的规模、过程、环境、开发人员和质量的全局描述。2。使用软件成本估计模型，在宏观级别上估计整体工作量和制定进度。

70成本和进度的估计过程(1)

自顶而下的方法项目计划需要从两个成本和进度的估计过程(1)

自顶而下的方法3。SPM使用上述指南将估计的工作量分配到第一级WBS中，将进度划分成主里程碑日期，将工作量分配给人员结构剖面图。此刻，便有了一个项目级的计划。4。下一步，子项目经理负责将每一个WBS元素划分到更低的级别，尽量使其满足顶层分配、人员结构剖面图和主里程碑日期的限制。71成本和进度的估计过程(1)

自顶而下的方法3。SPM使成本和进度的估计过程(2)

由底向上的方法第二个视角是向后观望、由底向上的方法。从终点开始思考，分析微观级别的预算和进度，综合考虑这些元素，制定出更高级别预算和中间里程碑。这种方法由底向上制定和填充WBS。从这个视角，会发生下面的计划序列：1。将最低级别的WBS元素细化成细节任务，相关的WBS元素的管理人员根据这些任务估计预算和进度。这些估计与项目相关参数结合得非常紧密。2。在较高级别预算和里程碑中结合并集成估计。需要均衡估计者的 个人建议，形成一致的磋商基础72成本和进度的估计过程(2)

由底向上的方法第二个视角是向后观成本和进度的估计过程(3)

－－两种方法互向校正将由底向上的结果与自顶向下的预算和进度里程碑进行比较。评估其区别并进行校正，最后取得一致。73成本和进度的估计过程(3)

－－两种方法互向校正73CMM对估计的要求1。所有可靠的估计技术均依靠历史数据；历史数据愈多，估计愈精确。2。从CMML2开始估计，不要求精确，但要求能不断改进。CMM的核心思想是不断学习，不断改进。因而：要有文档化估计规程要从现有的项目开始每次迭代均应有所改进

74CMM对估计的要求1。所有可靠的估计技术均依靠历史CMM对估计的要求3。尽量使用数据，特别是要积累自己的数据。4。估计要经常进行。在项目生命周期内，随着信息的增加应不断精化估计。因而在项目进程中，要不断修订计划，每次修订必须重新进行估计。75CMM对估计的要求3。尽量使用数据，特别是要积累自初始估计数据的选择1。对于数据，在CMML2的估计规程中只要求“如果有的话，使用历史数据”。所以起步时，只要选定方法，进行估计就是了。2。初始数据的来源：如有自己项目的数据，则用自己的数据；否则用本组织的数据。如果无组织的数据，则可依次选用本地区的数据、本国行业的数据、国际上的行业数据。

76初始估计数据的选择1。对于数据，在CMML2的估初始估计数据的选择3。CMML2的SPP的活动15要求建立一个数据库，记录项目估计数据，包括计划时用的数据、再计划时用的数据。为使数据可用，必须记录估计的假设，例如所采用的估计模型、模型参数、任务的描述等。77初始估计数据的选择3。CMML2的SPP的活动制定软件计划时的估计对工作量，不仅需要知道总的估计，而且需要知道它按阶段的分布情况以及在每一阶段中按角色的分布情况。78制定软件计划时的估计对工作量，不仅需要知道总的估计，而且需要制定软件计划时的估计基于历史数据的实例(Infosys)阶段工作量的％工作量需求分析414设计2068构造40136测试1034验收测试414项目管理827培训517其他930总计10034079制定软件计划时的估计基于历史数据的实例(Infosys)阶CMML2中的估计对象及其相互关系1。估计对象有规模、工作量、成本、进度、CCR、风险、设施和支持工具等。在作项目计划时，就应对待开发软件的这些对象进行估计。2。其中规模是源，如果没有对规模的值，就无法知道项目的工作量，就无法计划开发进度和所需的资源。80CMML2中的估计对象及其相互关系1。估计对象有CMML2中的估计对象及其相互关系3。而规模又取决于需求，因而估计要从估计需求开始。如果需求变更，则各项估计都要作相应的变更。4。在CMML2中，并不要求估计缺陷，但要求记录缺陷的类型和数值；在CMML3中，既要求估计缺陷，也要求记录缺陷的类型和数值。5。一般这些量之间有一定的关系，具体值由历史数据确定。当缺乏历史数据时，可分别估计多个量，以便相互验证。81CMML2中的估计对象及其相互关系3。而规模又取程序规模的估计把新程序按程序的规模等级与从前编写的程序排列判断新程序的规模可能落于从前编写的程序的哪个规模范围，进而估计出可能的代码行。程序的需求模块1（小）模块3（大）模块2（稍大）模块5（中）模块4（较大）原程序1（80）原程序3（100）原程序4（60）原程序5（40）原程序2（30）原程序6（10）模块6（中偏小）需求2需求1需求3需求4需求582程序规模的估计把新程序按程序的规模等级与从前编写的程序排列判编写程序的效率度量程序规模的方法是统计源程序有多少行(LOC)。编程效率是指单位时间内编写的代码行数。估计编写某个程序所用的时间时，根据以前编写类似程序所用的时间进行估计。随着经验的增加，编写一行程序所用的时间将会有很大的变化，应该以分钟/代码行这个速率进行跟踪，并且以最近5～10个程序所获得的数据为依据进行估计。83编写程序的效率度量程序规模的方法是统计源程序有多少行(LOC从程序规模导出工作量从程序规模可以导出工作量。估计的一般步骤：工作效率的度量－分钟/代码行数软件规模的度量–代码行数工作量的度量–分钟程序可能会有多少代码行编写每行代码需要多少分钟计算出总共需要的时间84从程序规模导出工作量从程序规模可以导出工作量。估计的一般步骤

COCOMO模型当今有几个软件成本模型在使用中。其中一个流行的的软件成本模型就是由BarryBoehm开发的构造型成本模型（COnstructiveCOstModel，COCOMO）。针对不同类型的软件有不同模式（1）组织模式：较小的、简单的软件项目，有良好应用经验的小型项目组，针对一组不是很严格的需求展开的；85COCOMO模型当今有几个软件成本模型在使用中。其中一个

COCOMO模型（2）半分离模式：中等软件项目（在规模和复杂性上），具有不同经验的项目组必须满足严格的及不严格的需求（如一个事务处理系统，对于终端硬件和数据库软件有明确要求）；（3）嵌入模式：必须在一组严格的硬件、软件及操作下开发的软件项目（如飞机的航空控制系统）。86COCOMO模型（2）半分离模式：中等软件项目（在规模和原始的COCOMO估计公式这些是原始的COCOMO模型的成本估计关系：组织模式 Effort=3.2EAF(Size)1.05 Time（Man-Month）=2.5(Effort)0.38半分离模式 Effort=3.0EAF(Size)1.12 Time（Man-Month）=2.5(Effort)0.35嵌入模式 Effort=2.8EAF(Size)1.2 Time（Man-Month）=2.5(Effort)0.3287原始的COCOMO估计公式这些是原始的COCOMO模型的成本公式中参数的意义（1)Effort=人月的数量(2)EAF=15个工作量调整因子的乘积（见表1），其值通常在0.5到1.5之间。它代表多个参数的综合效果，这些参数使得项目可以特征化并根据COCOMO数据库中的项目规格化。每个参数可以定为：很低，低，正常，高，很高。每个参数设置的效。(3)Size=交付的源指令的数量（以千行代码KLOC为单位）

88公式中参数的意义（1)Effort=人月的数量88公式中参数的意义(4)最终产品的过程的内在的规模经济指数，特别是避免无附加值活动（返工、官僚主义的拖延和沟通开销）的过程能力(5)Time的指数P2=刻画在管理一个软件开发工作中内在的惯性和并行性的指数89公式中参数的意义(4)最终产品的过程的内在的规模经济指数，COCOMO项目特征参数标识符工作量调整因子参数范围潜在的影响RELY需要的可靠性0.75–1.401.87DATA数据库大小0.94–1.161.23CPLX产品复杂度0.70–1.652.36TIME执行时间限制1.00–1.661.66STOR主存限制1.00–1.561.56VIRT虚拟机变动性0.87–1.301.49TURN计算机往返时间0.87–1.151.32ACAP分析能力1.46–0.712.06AEXP应用经验1.29–0.821.57PCAP程序员能力1.42–0.702.03

VEXP 虚拟机经验1.21–0.901.34LEXP语言经验1.14–0.951.20MODP现代实践的使用1.24–0.821.51TOOL软件工具的使用1.24–0.831.49SCED需要的开发进度1.23–1.101.2390COCOMO项目特征参数标识符工作量调整因子参数范围潜在的影在COCOMO中缺省的WBS活动预算（％）注解需求分析4产品设计12编程 44包括详细设计、编码、单元测试和集成测试计划6确认和验证14项目职责7项目办公室的职能（管理和经营）CM和QA7手册编写691在COCOMO中缺省的WBS活动预算（％）注加权平均法当其它方法都不可行时，根据经验和历史数据，计划人员对每个功能按最佳的、可能的、悲观的三种情况给出LOC或FP估计值，记作：a、m、b。当这些值的范围确定之后，计算出LOC或FP的期望值E： E=(a+4m+b)/6其中可能的估计值m是加权最重的，并遵循贝塔概率分布。知觉和经验是重要的，也应交叉使用其它方法。92加权平均法当其它方法都不可行时，根据经验和历史数据，计划人员加权平均法的估计规程(1)首先作出以下三种估计：非常可能的值tm，最乐观的值to，最悲观的值tp。再使用公式计算平均值=(to+4tm+tp)/6计算标准偏差和方差的值：标准偏差=(tp-to)/6方差=((tip-to)/6)293加权平均法的估计规程(1)首先作出以下三种估计：93加权平均法的估计规程(2)利用方差和概率分布的概念，可得到平均值落在一个区间内的概率:为预期平均值，概率是50%左右扩大一个标准偏差，概率是84.0%左右扩大两个标准偏差，概率是97.7%左右扩大三个标准偏差，概率是99.9%有时公式中再引进一个复杂度乘积因子。94加权平均法的估计规程(2)利用方差和概率分布的概念，可得到平

Delphi估计法当许多专家基于相同假设独立地作出估计，该估计多半是正确的必须确保专家对相同的正确假设进行工作95Delphi估计法当许多专家基于相同假设独立地作出估计，Delphi估计规程(1)Delphi估计规程如下：组织估计群组估计专家(例如，4-6个有关项目经理或资深专家)作者估计协调者2. 作者陈述待待估计的系统3. 作者和专家一起识别作业和假设4. 作者和专家一起就可接收的估计差异水准达成一致(例如20%)协调者整理一份群组所决定的作业清单，发给每个专家96Delphi估计规程(1)Delphi估计规程如下：96Delphi估计规程(2)6. 针对每个作业，专家独立地对每个作业作出估计(无讨论/咨询)，将估计交给协调者协调者对如下表格作出综合：协调者将综合表发给全部专家和作者当%差别(variance)大于可接受水平时，专家与作者讨论作业和假定。不讨论估计值。某些作业可能作进一步分解或合并返回步骤5；继续工作直到全部作业处在可接受的水平之内作业最小估计最大估计平均估计%差别(VAR)接受/不接受97Delphi估计规程(2)6. 针对每个作业，专家独立地对Delphi估计规程(3)Delphi估计法成功的关键因素：绝对不讨论估计。讨论作业和假设。估计是保密的，估计者不知道相互的估计。应至少有三个估计者。将项目分解到小的作业(约20个人日)。98Delphi估计规程(3)Delphi估计法成功的关键因四。风险管理风险策略风险特性风险管理活动99四。风险管理风险策略99风险策略被动式：风险发生后才采取措施，是“救火模式”。主动式：在项目开发前就标识出潜在的风险，有计划地管理风险。主要目标是预防风险。必要时加以控制，减轻影响。100风险策略被动式：风险发生后才采取措施，是“救火模式”。100风险特性不确定性：刻划风险的事件可能发生也可能不发生；即，没有100％发生的风险（100％发生的风险是加在项目上的约束）。损失：如果风险变成了现实，就会产生恶性后果或损失。101风险特性不确定性：刻划风险的事件可能发生也可能不发生；即，没活动风险识别风险估计风险评估风险驾驭和监控102活动风险识别102风险识别根据历史数据及经验，标识相关的风险，列出全部风险项S1，S2…，Sn。项目风险识别技术风险识别商业风险103风险识别根据历史数据及经验，标识相关的风险，列出全部风险项S项目风险识别项目风险识别是要找出潜在的预算、进度、个人（包括人员和组织）、资源、用户和需要方面的问题，以及它们对软件项目的影响。如项目复杂性、规模和结构等都可构成风险因素。104项目风险识别项目风险识别是要找出潜在的预算、进度、个人（包括技术风险识别技术风险识别是要找出潜在设计、实现、接口、检验和维护方面的问题。规格说明的多义性、技术上的不确定性、技术陈旧、最新技术（不成熟）也是风险因素。105技术风险识别技术风险识别是要找出潜在设计、实现、接口、检验和商业风险识别商业风险有：(1)建立的软件不是真正所想要的；(2)建立的软件不适合整个软件产品战略；(3)销售部门不清楚如何推销这种软件；(4)失去上级管理部门的支持；(5)失去预算或人员的承诺（预算风险）。106商业风险识别商业风险有：106人员风险识别人员风险有：(1)缺乏优秀人才；(2)缺乏配套人才；(3)人员不够；(4)人员对分配工作缺乏兴趣；(5)人员流动过快。(6)人员意外缺勤（因病、因事）(7)人员缺乏足够培训。107人员风险识别人员风险有：107开发环境风险(1)是否有可用的软件支持工具（项目管理工具、配置管理工具、测试工具、……）。(2)设备是否陈旧。设备意外损坏。(3)是否发生病毒，使开发环境瘫痪。108开发环境风险(1)是否有可用的软件支持工具（项目管理工具、风险估计估计风险发生的可能性。估计风险可能产生的结果。建立一个尺度或标准来表示一个风险的可能性；可以使用概率尺度表，其值分为：极罕见的、罕见的、普通的、可能的、极可能的。描述风险的结果，分出影响的类别：性能、支持、成本、进度。估计风险对项目和产品的影响；影响可分为4级：灾难性的；严重性的；轻微的；可忽略的。109风险估计估计风险发生的可能性。估计风险可能产生的结果。109风险评价在项目进行中，进一步检验在风险估计时所得到的估计的准确性，对已暴露的风险进行优先排队，考虑控制和（或）消除可能出现风险的方法。定义风险参考水平值：对前述风险影响类别——性能、支持、成本、进度分别（或组合）制定一个参考水平，即性能下降，支持困难、成本增加、进度延迟到某个程度（水平）项目被迫中止。110风险评价在项目进行中，进一步检验在风险估计时所得到的估计的准风险驾驭和监控

风险驾驭是指利用某些技术，及某些项目管理方法等设法避开或转移风险。风险监控： 1）

做风险因素跟踪； 2）

进行风险再估计； 3）

收集可用于将来的风险分析的信息。111风险驾驭和监控风险驾驭是指利用某些技术，及某些项目管理方法五。项目计划实施追踪和控制

追踪控制目的：注意并发现软件工程过程实际进展与计划、标准（规范）之间的偏离，采取适当措施进行处理。112五。项目计划实施追踪和控制追踪目的：注意并发现软件工程过程追踪周报、月报。定期举行项目状态会议。在会上，报告进展遇到的问题。评价软件工程过程中所产生的所有评审的结果。确定由项目的计划进度所安排的正式的里程碑。比较每一个任务的实际开始时间和计划开始时间。与开发人员交谈，得到对开发进展和刚冒头的问题的客观评价。113追踪周报、月报。113控制

当问题出现的时候，项目管理人员必须实行控制以尽可能快地排解它们。在问题领域可能需要一些追加资源；人员可能要重新部署，或者项目进度要重新调整。114控制当问题出现的时候，项目管理人员必须实行控制以尽III.软件配置管理

SoftwareConfigurationManagement

2022/12/12115III.软件配置管理

SoftwareConfigu软件配置管理一。为什么要进行配置管理二。软件配置管理的基本概念三。软件配置管理的主要活动四。如何进行配置管理116软件配置管理一。为什么要进行配置管理116一为什么要进行配置管理软件配置管理的意义软件规模不断增大，中间产品多，管理困难。软件变更是不可避免的，而变更更加剧了项目中软件工程师间的混乱。配置管理协调软件开发使得混乱减到最小的程度配置管理建立和维护在整个软件生存周期中项目软件产品的完整性、一致性和可追遡性。2022/12/12117一为什么要进行配置管理软件配置管理的意义2022/12二软件配置管理的基本概念1。软件配置管理2。软件配置3。配置项4。配置标识5。里程碑、基线6。版本控制7。变更控制8。软件配置管理过程118二软件配置管理的基本概念1。软件配置管理21。什么叫配置管理配置管理是一种对软件项进行标识、组织和控制修改的管理工作和技术。是协调软件开发使得混乱减到最小的技术。1191。什么叫配置管理配置管理是一种对软件项进行标识、组织和控制2。软件配置组成一个完整的软件系统的所有软件部件的排列。在软件工程过程中产生的组成一个系统某版本的所有的信息项（配置项）构成了该系统版本软件配置。软件配置是一个动态的概念。随着软件过程的推进，配置项的数量在不断增多，并随时有变更而形成新的版本配置。1202。软件配置组成一个完整的软件系统的所有软件部件的排列。123。配置项（SCI）为了配置管理目的而作为一个单位来看待的软件成份(软部件)。软件配置管理的对象就是软件配置项或叫配置对象，它们是软件工程过程中产生的信息项（文档、报告、程序、表格、数据）1213。配置项（SCI）为了配置管理目的而作为一个单位来看待的软基本配置项和复合配置项（1）基本配置项（配置对象）是在软件过程中通过分析、设计、编码、测试所产生的“文本单元”，是配置管理中不再分割的软件成份（软部件）。极端情况下，可以把文档中的一节或测试中的一个测试用例等定为一个SCI，通常的做法是把一个文档、一整个测试用例组。一个命名的源程序，测试中一个等价类的测试用例看成一个SCI。122基本配置项和复合配置项（1）基本配置项（配置对象）是在软件过基本配置项和复合配置项（2）标识的配置项利用面向对象的方法组织起来。这种标识的对象分为：基本对象和复合对象复合配置项（配置对象）是基本对象或其它复合对象的聚集。例如把《设计规格说明书》看成是一个复合对象则它是由“数据设计”、“体系结构设计”、“模块设计”、“界面设计”等各章节作为基本对象的聚集。123基本配置项和复合配置项（2）标识的配置项利用面向对象4。配置标识配置标识是一组信息，它应能唯一地标识一个配置项。为了方便对软件配置项进行控制和管理，不致造成混乱，要用一组信息来唯一地标识每一个配置项，这一组信息就叫配置标识。对软件系统(版本)的配置是通过配置标识实现的1244。配置标识配置标识是一组信息，它应能唯一地标识一个配置项。如何定义配置标识配置项标识是一个字符串，它的基本内容包括：配置项名字、配置项属性描述、实现。名字：是一个字符串，例如“数据设计”、“体系结构设计”、“……”、“设计说明”、程序模块名。描述：配置项的类型（如文档、程序、数据、测试用例、工具），项目标识，变更／版本信息。实现：该配置项指向父/子配置项的指针。125如何定义配置标识配置项标识是一个字符串，它的基本内容包括：配文档配置标识实例RDV-BILL-WSite-HLD-003v2.0ProductProjectComponentDeliverableTypeDeliverableNumberVersion:Ele:YIBO-R&D-PROC-SCM-003v2.0

xamp126文档配置标识实例RDV-BILL-WSite-HLD-0035.里程碑（Milestone),基线（Baseline）在软件生存期各开发阶段末尾的提交时间叫做里程碑（Milestone），是一个阶段结束，下阶段开始的时间点。在某些里程碑通过正式评审批准的软件配置的正式文本成为基线。基线是某里程碑时新产生的配置项。基线的作用是把各阶段工作划分更加明确，以便于检验和肯定阶段成果，是后面各软件开发阶段的依据（出发点），所以叫做基线。1275.里程碑（Milestone),基线（Baseline）在基线以下软件配置项可以是软件配置管理的对象并可形成基线。系统规格说明软件项目实施计划软件需求说明设计规格说明（数据设计、体系结构设计、模块设计、接口设计、对象描述——使用面向对象技术时）可执行的或“书面”的原型初步的用户手册128基线以下软件配置项可以是软件配置管理的对象并可形成基线。12文档编制的起始与完成时间表文阶段件可行性研究与计划阶段需求分析阶段设计阶段实现阶段测试阶段运行与维护阶段可行性研究报告项目开发计划软件需求说明书数据要求说明书测试计划概要设计说明书详细设计说明书数据库设计说明书模块开发卷宗用户手册操作手册测试分析报告开发进度月报项目开发总结129文档编制的起始与完成时间表文阶各阶段的基线及配置项对应需求分析客户需求说明书软件功能需求说明书据需求说明书工作陈述软件项目计划配置管理计划质量保证计划验收测试计划系统测试计划系统测试用例说明书概要设计Req基线总体概要设计说明书模块概要设计说明集成测试计划集成测试用例说明书详细设计各模块详细设计说明各模块测试用例说明编码&UT测试发布各模块编码及单元测试报告项目中层汇总逻辑集成测试分析报告系统测试分析报告系统安装手册系统维护手册Test基线用户使用说明书项程序源代码项验收测试报告项目开发总结报告HLD基线DD基线Code基线Test基线Release基线变更130各阶段的基线及配置项对应需求分析客户需求说明书6.版本控制版本控制是利用工具来管理在软件工程过程中产生的配置对象由于多次修改和变更所建立的不同版本。配置管理实施的版本控制使用用户或开发者选择适当的版本来确定软件系统的配置。如果该图是一个软件系统的版本演变图，则每个结点都是聚合对象给出该软件系统的某个版本的软件配置。1316.版本控制版本控制是利用工具来管理在软件工程过程中产生的版本控制（续）下图是一个配置对象版本的演变图示例。对于每个配置对象都可以建立类似的演变图。版本1.0版本1.1版本1.2版本1.3版本1.4版本2.0版本2.1版本1.1.1版本1.1.2132版本控制（续）下图是一个配置对象版本的演变图示例。对于每个配版本号示例版本编号约定:增量为0.1：小变更或bug修复第一个版本：V1.0增量为1.0：新的发布（增加若干功能）变体例：某软件的一个版本由5个组件构成，其中：

组件4适用于彩色显示器

组件5适用于单色显示器

则它的两个版本，或称两个变体是

Version1:组件1，2，3，4

Version2:组件1，2，3，512345133版本号示例版本编号约定:例：某软件的一个版本由5个组件构成，7.变更控制软件工程过程中对变更加以严格的控制和管理，以免发生混乱。变更控制过程：提出变更请求评估变更请求实施变更复审变更建立软件新版本1347.变更控制软件工程过程中对变更加以严格的控制和管理，以免发三。软件配置管理的主要活动1。计划配置管理活动2。选择配置管理工具3。建配置管理库4。执行配置控制5。识别配置；6。变更控制7。状态记录和报告8。审计2022/12/12135三。软件配置管理的主要活动1。计划配置管理活动2022/121。计划配置管理活动（1）软件配置管理计划应是软件开发计划的一个组成部分。应包括以下重要内容：管理组织和责任、规程、工具、技术和方法计划应描述如何且何时执行这些规程在此计划发布之前要进行如下过程:确认和验证过程文档开发2022/12/121361。计划配置管理活动（1）软件配置管理计划应是软件开发计划的计划配置管理活动（2）软件配置管理计划还应包括：规定项目基线、制定配置项标识编排规则，规则应能反映配置项的结构以便于追踪，使标识具有唯一性（不允许多个配置项重名）和可追溯性（即标识能够反映各配置项之间的相互关系，可追溯到相关的配置项）。2022/12/12137计划配置管理活动（2）软件配置管理计划还应包括：2022/1计划配置管理活动（3）软件配置管理计划应至少计划建立三个基线它们是：功能基线：项目系统分析、设计完成后分配基线;软件需求分析完成后产品基线:软件系统测试完成后这三个里程碑的基线必须入受控库,其他里程碑的产品是否作为基线可酌情处理。基线不宜建立过早、过多。例如,从详细设计至确认测试前不宜设基线.2022/12/12138计划配置管理活动（3）软件配置管理计划应至少计划建立三个基线功能基线功能基线：是指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待开发软件系统的规格说明；或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是指由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标识。139功能基线功能基线：是指在系统分析与软件定义阶段结束时，经过正指派基线指派基线：是指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标识。140指派基线指派基线：是指在软件需求分析阶段结束时，经过正式评审产品基线产品基线：是指在软件组装与系统测试阶段结束时，经过正式评审和批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标识。141产品基线产品基线：是指在软件组装与系统测试阶段结束时，经过正2.选择软件配置管理工具为做好配置管理工作，寻求工具的支持是十分有益的，它可促进软件配置管理工作提高效率。需要注意的是选择时应认真考察其适用性。工具名厂商CCC/Harvest

ChangeMan

ClearCase

Continuus

Endevor/MVS

PCVS

PCVSDimensions

Razor

SourceIntegrity

SourceSafe

TeamConnection

TUREchangePlatinumTechnology

SERENAInternational

Rational

Continuus

ComputerAssociates

INTERSOLV

INTERSOLV

TowerConcepts

MKS

MS

IBM

TRUEsoftware1422.选择软件配置管理工具为做好配置管理工作，寻求工具的支持是软件配置管理工具的主要功能配置支持；版本控制变化控制；Build支持；（配置项用于形成基线）过程支持；团队支持；报告/查询；审计控制。2022/12/12143软件配置管理工具的主要功能配置支持；2022/12/11143。建立三类配置管理库开发库(DevelopmentLibrary)是指在软件生存周期的某一个阶段期间，存放与该阶段软件开发工作有关的计算机可读信息和人工可读信息的库。专供开发人员使用，其中的信息会频繁修改，对其控制相当宽松。1443。建立三类配置管理库开发库(DevelopmentLib建立三类配置管理库受控库(ControlledLibrary)在生存期某一阶段的工作结束时，存放阶段产品而释放的、与软件开发工作有关的计算机可读信息和人工可读信息。软件配置管理就是对受控库中的各个软件项进行管理，也称软件配置管理库。145建立三类配置管理库受控库(ControlledLib建立三类配置管理库产品库(ProductLibrary)在被开发的软件产品完成系统测试后，存放最终产品等待交付用户运行或现场安装的软件库。146建立三类配置管理库产品库(ProductLibrary5。执行配置控制跟踪受控产品的变更来确保在所有时间都了解产品的配置。建立每个基线，跟踪所有已建立的基线发生的的变更。所有基线配置项都应遵循变更管理规范。每个基线配置变更状态的历史在整个生命周期过程中都应受到维护以便进行状态统计。对受控项的更改应由授权的人的批准。建立正式的软件配置控制委员会（SCCB）。1475。执行配置控制跟踪受控产品的变更来确保在所有时间都了解产品SCCB成分项目经理关键的软件开发工程师关键的软件测试工程师SQA代表SCM代表148SCCB成分项目经理148SCCB责任批准软件基线和配置项的确定代表项目经理和所有受软件基线修改影响的组的利益评审和批准基线的变更批准从软件基线库中创建产品受影响组的例子有：硬件质量保证，硬件配置管理，硬件工程，制造工程，软件工程（包括所有下属组，如软件设计），系统工程，系统测试，软件质量保证，软件配置管理合同管理，及文档支持。149SCCB责任批准软件基线和配置项的确定受影响组的例子有：配置控制委员会的活动对差异报告和变更请求报告作出评价。对以下问题作决定：（1）变更的规模（2）相关系统的影响（3）变更要求的日期（4）对当前及后续工作的影响（5）成本150配置控制委员会的活动对差异报告和变更请求报告作出评价。对以下配置控制委员会的活动（6）涉及的范围的危险程度（7）处理中已批准的变更（8）测试需求（9）资源(skills,hardware,system)（10）CPU和存储器（11）方针（12）有可选择的办法？151配置控制委员会的活动（6）涉及的范围的危险程4。变更控制流程（1）提交变更请求该请求描述了变更的理由、怎样变更，必需注意的约束、复审和审计的标准（2）对变更请求评估评估变更的必要性、潜在副作用、对其他配置对象和系统功能的整体影响、以及对于变化成本的预测。（3）评估的结果以评估报告的形式给出，该报告被审核者审核1524。变更控制流程（1）提交变更请求152变更控制流程（4）对批准的变更实施变更将被修改的对象从项目受控库“提取（checkout）”出来,进行修改，并配合合适的SQA活动（5)建立新版本将更改后并经过复审的对象“提交（checkin）”进数据库，并使用合适的版本控制机制去建立软件的下一个版本153变更控制流程153变更控制流程变更控制过程：提出变更请求评估变更请求实施变更复审变更建立软件新版本154变更控制流程变更控制过程：提出变更请求评估变更请求实施变更复6.配置状态报告（ConfigurationStatusReporting)－1什么是配置状态报告配置状态报告（也称StatusAccounting）的目的是及时、准确地给出软件配置项的当前状态，供相关人员了解，以加强配置管理工作。相当于照片。1556.配置状态报告（ConfigurationStatus配置状态报告（ConfigurationStatusReporting)－2配置状态报告可能提供的信息包括：当前作了哪些变更？谁参与了这些变更？何时作的变更？可能影响的范围是哪些？156配置状态报告（Config