软件项目管理与案例分析思考题及复习资料.docx

《软件项目管理与案例分析思考题及复习资料.docx》由会员分享，可在线阅读，更多相关《软件项目管理与案例分析思考题及复习资料.docx（13页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、软件项目管理第一章思考题：1、当我们选择软件项目的负责人时，我们在寻找什么？成功的项目负责人应采用一种解决问题的管理风格。也就是说，软件项目经理应该注重理解要解决的问题、把握住涌现 的各种意见、同时让项目团队的每一个人知道质量很重要，不能妥协。2、 选择软件团队的结构时，应该考虑哪些因素？（1）待解决问题的难度；（2）开发程序的规模，以代码行或功能点来度量；（3）团队成员需要共同工作的时间（团队生存期）；（4）能够对问题做模块化划分的程度；（5）待开发系统的质量要求与可靠性要求；（6）交付日期的严格程度；（7）项目所需要的友好交流的程度。3、 定义软件的结构时，我们有哪些选择？封闭式范型。按照

2、传统的权利层次来组织团队。当开发及过去已经做过的产品相似的软件时，这种团队十分有效。但在这种封闭式范型下难以进行创新性的工作。 随机式范型。松散地组织团队，团队工作依赖于团队成员个人的主动性。当需要创新或技术上的突破时，按照这种随机式范型的团队很有优势。但当需要“有次序地执行”才能完成工作时，这种团队就会陷入困境。开放式范型：试图以一种具有封闭式范型的控制性，又包含随机式范型的创新性的方式来组织团队。工作是大家相互协作完成的。良好的沟通与根据团队整体的意见做出决策是开放式范型的特征。开放式范型的团队结构特别适合于解决复杂的问题，但可能不像其他类型的团队那么有效。同步式范型。依赖于问题的自然划分

3、，组织团队成员各自解决问题的一部分，他们之间没有什么交流。4、 何谓有凝聚力的团队？一个有凝聚力的团队是一组团结紧密的人，他们的整体力量大于个体力量的总与。及一般团队相比，有凝聚力的团队成员 有更高的生产率与更大的动力。他们拥有共同的目标与共同的文化，而且在很多情况下，“精英意识”使得它们独一无二。5、 为什么有些团队没有凝聚力？并非所有的团队具有凝聚力。事实上，很多团队都受害于Jackman JAC 98称之为“团队毒性”的东西。她定义了5个“培育潜在含毒团队环境”的因素（1）狂乱的工作氛围（2）引起团队成员产生摩擦的重大挫折（3）“碎片式的或协调很差”的软件过程（4）在软件团队中没有清晰的

4、角色定义（5）“接连不断地重蹈覆辙”。6、 我们如何定义关键的项目特性W5HH原则为什么（Why）要开发这个系统？对这个问题的回答，可以使所有参及者评估软件工作的商业理由的有效性。换句话说，该系统的商业目的值得花费这些人员、时间与金钱吗？将要做什么（What）? 对这个问题的回答将制定完成项目所需的任务清单。什么时候（When）做？就是标识出何时开展项目任务与何时达到里程碑，对这个问题的回答能够帮助团队安排好项目进度。某功能由谁（Who）负责？必须规定软件团队的每个成员的角色与责任。他们的机构组织位于何处（Where）?并非所有角色与责任均属于软件团队，客户、用户与其他共利益者也有责任。如何（

5、How）完成技术工作与管理工作？一旦确定了产品范围，必须定义项目的管理策略与技术策略。每种资源需要多少（How much）?对这个问题的回答，是在对前面问题回答的基础上，通过估算而得到小结：软件项目管理是软件工程的普适性活动。它先于任何技术活动之前开始，且持续贯穿于整个计算机软件的定义、开发与维护之中。4个P人员、产品、过程与项目，对软件项目管理具有重大的影响。必须将人员组织成有效率的团队，激励他们完成高质量的软件工作，并协调他们实现有效的沟通。产品需求必须在客户及开发者之间进行交流，划分（分解）成各个组成部分，并分配给软件团队。过程必须适合于人员与问题。选择通用过程框架，采用合适的软件工程范

6、型，并挑选工作任务集合来完成项目的开发。最后，必须采用确保软件团队能够成功的方式来组织项目。第二章思考题：1、 对软件度量的私有使用与公用使用有什么不同？不同类型的过程数据的使用可以分为“私有的与公用的”。私有过程数据是软件工程师个人改进其工作的重要驱动力。公用度量一般吸取了原本是个人的或团队的私有信息。收集与评估项目级的缺陷率(肯定不能归因于某个个人)、工作量、时间及相关的数据，以找出能够改善组织过程性能的指标。2、 当我们收集软件度量时，应该采用什么指导原则？软件度量规则：解释度量数据时使用常识，并考虑组织的敏感性。向收集测量与度量的个人及团队定期提供反馈。不要使用度量去评价个人。及开发者

7、与团队一起设定清晰的目标，并确定为达到这些目标需要使用的度量。不要用度量去威胁个人或团队。指出问题区域的度量数据不应该被“消极地”看待，这些数据仅仅是过程改进的指标。不要在某一个别的度量上纠缠，而无暇顾及其他重要的度量。3、 在项目中，我们应该如何使用度量？软件过程度量主要用于战略的目的。软件项目度量则是战术的。在大多数软件项目中，项目度量的第一个应用是在估算阶段。从过去的项目中收集的度量可以作为估算当前软件工作工作量及时间的基础。随着技术工作的启动，其他项目度量也开始有意义了。生产率可以根据创建的模型、评审的时间、功能点以及交付的源代码行数来测量。4、 什么是度量基线？它能为软件工程师提供什

8、么益处？度量基线由从以往开发的软件项目中收集的数据构成，一个包含过程与产品测量的数据库。基线是估算的基础。通过建立度量基线，软件工程师及管理者能够更好地了解他们所做的工作与开发的产品，在过程级、项目级与产品（技术）级上都能获得收益。5、 我们应该怎样导出一组“简单的”软件度量？不是从测量而是从结果入手，软件小组通过表决来确定一个需要改进的目标，根据这个目标，小型 组织可以选择一些易于收集的测量，从而得出度量，并进行过程改进。6、 一个Web工程团队已经开发了一个包含145个网页的电子商务WebApp。在这些页面中，65个是动态页面，即根据最终用户的的输入而在内部生成的页面。那么，该应用的定制指

9、数是多少？ Nsp = 静态Web页的数量 Ndp = 动态Web页的数量定制指数 C = Ndp /( Ndp + Nsp ) =65/145 小结：测量能使管理者与开发者改进软件过程，辅助进行软件项目的计划、跟踪及控制，评估生成的产品(软件)的质量。对过程、项目及产品的特定属性的测量可用于计算软件度量。分析这些度量可获得指导管理及技术行为的指标。过程度量使得一个组织能够从战略角度深入了解一个软件过程的功效。项目度量是战术性的，能使项目管理者实时改进项目的工作流程及技术方法。面向规模的度量与面向功能的度量在业界都得到了广泛的应用。面向规模的度量以代码行作为其他测量（如人月，缺陷）的规范化因子

10、。功能点则是从信息域的测量及对问题复杂度的主观评估中导出的。软件质量度量（如生产率度量）关注的是过程、项目及产品。一个组织通过建立并分析质量的度量基线，能够纠正引起软件缺陷的软件过程区域。测量会带来企业文化的改变。如果开始进行度量，则数据收集、度量计算及度量分析是必须完成的三个步骤。通常，目标驱动的方法有助于一个组织关注于对其业务的正确度量。通过建立度量基线一个包含过程与产品测量的数据库，软件工程师及管理者能够更好地了解他们所做的工作与开发的产品。第三章思考题:1、 有效测量过程的步骤是什么？ 公式化。导出适合于所考虑软件表示的测量与度量。 收集。用于导出公式化度量所需数据与积累机制。 分析。

11、度量的计算与数学工具的使用。 解释。为获得对表示的质量的理解而评价度量。 反馈。从对递交给软件团队的产品度量的解释中获得建议。2、 用于提供问题复杂性的指标有哪些？Fi 用于提供问题复杂性的指标。Fi（i114）是值调整因子（VAF），它基于对下列问题的回答来确定：系统需要可靠的备份与恢复吗？需要专门的数据通信从应用系统中传输信息或将信息传输到应用系统吗？存在分布处理功能吗？性能是关键的吗？系统将运行在一个现有的、紧张使用的操作环境吗？系统需要在线数据项吗？在线数据项需要对多个屏幕或操作建立输入事务吗？ILF在线更新吗？输入、输出、文件或查询复杂吗？内部处理复杂吗？所设计的代码是可复用的吗？转

12、换及安装包括在设计中吗？系统是为不同组织中的多个安装而设计的吗？应用系统是为便于变更与易于为用使用而设计的吗？每个问题可用从0（不重要或不适用）到5（绝对必需）间的数值来回答。小结：软件度量为产品内部属性的质量评估提供了一种定量方法，从而可以使软件工程师在产品开发出来之前进行质量评估。度量为创建有效的分析模型、设计模型、可靠的代码与完全的测试提供了必要的理解。为在现实世界中有用，软件度量必须是简单与可计算的、有说服力的、一致与客观的。它应该是及程序设计语言无关的，且为软件工程师提供有效的反馈。分析模型的度量侧重于分析模型的三个成分：功能、数据与行为。第四章思考题：1、 基于LOC与基于FP的估

13、算有什么共同点？LOC与FP估算是两种不同的估算技术，但两者有很多共同的特性：项目计划人员从界定的软件范围陈述入手，根据该说明将软件分解成一些可分别独立进行估算的功能问题。然后，估算每个功能的LOC或FP（即估算变量）。2、 我们如何计算软件规模的期望值？可以通过乐观值(Sopt)、可能值(Sm)与悲观值(Spess)估算的加权平均值来计算估算变量（规模）的期望值S：S = (Sopt + 4Sm + Spess ) / 6 3、 为什么开发基于用例的估算技术很困难？描述用例时，可以采用多种格式与风格没有标准形式。用例表现的是软件的外部视图（用户视图），常常在不同的抽象级别上建立用例没有标识出

14、它所描述的功能与特性的复杂性。用例没有描述出涉及很多功能 与特性的复杂行为（如，交互）。4、 什么是对象点？对象点是一种间接的软件测量。计算对象点时，使用如下的数值：1) （用户界面的）屏幕数2) 报表数3) 构造应用可能需要的构件数小结：在项目开始之前，软件项目计划人员必须先估算三件事：需要多长时间、需要多少工作量、以及需要多少人员。此外，计划人员必须预测所需要的资源(硬件及软件)与蕴含的风险。范围陈述能够帮助计划人员使用一种或多种技术进行估算，这些技术主要分为两大类：分解与经验建模。分解技术需要划分出主要的软件功能，接着估算：（1）LOC的数量；（2）信息域内的选择值；（3）用例的数量；（

15、4）实现每个功能所需的人月数；或者，（5）每个软件工程活动所需的人月数。经验技术使用根据经验导出的关于工作量与时间的公式来预测这些项目数字，可以使用自动 工具来实现特定的经验模型。对项目做精确估算时，一般至少会用到上述3种技术中的两种。通过对不同技术产生的估算值进行比较与调与，计划人员更有可能得到精确的估算。软件项目估算永远不会是一门精确的科学，但可靠的历史数据及系统化的技术结合起来能够提高估算的精确度。第五章思考题：1、 当管理者要求的项目结束期限我们无法实现时，我们应该怎么办？在这种情况下，推荐以下的处理步骤：1) 按照以往项目的历史数据进行详细的估算。确定项目的估算工作量与工期。2) 采

16、用增量过程模型，制定一个软件开发策略，以保证能够在规定的交付日期提供主要功能，而将其他功能的实现推到以后。然后将这一计划做成文档。3) 及客户会谈并(用详细估算结果)来解释为什么规定的交付日期是不现实的，一定要指出所有这些估算都是基于以往的项目实践，而且一定要指出为了在目前规定的交付期限完成项目，及以往相比在工作效率上必须提高的百分比4) 将增量开发策略作为可选计划提交给客户2、 在软件过程的工作流程中应如何分配工作量？软件过程中的工作量分配通常采用402040法则。总体工作量的40%分配给前期的分析与设计，40%的用于后期测试。因此，你可以推断出编码工作（20%的工作量）是次要的。这种工作量

17、分配法只能作为指导原则。各个项目的特点决定了其工作量如何分配。3、 如何计算挣值以评估项目进展？确定挣值的步骤：1) 为进度表中的每个工作任务确定其预计工作的预算成本BCWSBCWSi是指工作任务i的计划工作量。为了确定在项目进度表中某特定时间点的项目进展状况，BCWS的值是在项目进度表中该时间点应该完成的所有工作任务的BCWSi值之与。2) 所有工作任务的BCWS值加起来，可计算出完成工作的预算BAC对所有任务k，BAC(BCWSk)3) 计算已完成工作的预算成本BCWP。BCWP的值是在项目进度表中该时间点已经实际完成的所有工作任务的BCWS值之与。4、 人员与时间的关系是高度非线性的。使

18、用Putnam的软件方程式编制一个表，以反映软件项目中人员数量及项目工期之间的关系。此项目需要50000LOC与15人年的工作量（生产率参数为5000）。假定该软件必须在2412个月的时间期限内交付。小结：计划活动是软件项目管理的重要组成部分，而进度安排是计划活动的首要活动。进度安排及估算方法及风险相结合，可以为项目管理者画出一张路线图。进度安排始于过程分解。根据项目特性，为将要完成的工作选择适当的任务集。任务网络描述了各项工作任务、每一项任务及其他任务之间的依赖关系以及计划工期。任务网络可以用来确定项目的关键路径、时序图以及各种项目信息。以进度表为指导，项目管理者可以跟踪与控制软件工程过程中

19、的每一个步骤。第六章思考题：1. 在建造软件时可能会遇到什么类型的风险？1) 项目风险（project risk）威胁到项目计划。项目风险是指预算、进度、人员(聘用职员及组织)、资源、利益相关者、需求等方面的潜在问题以及它们对软件项目的影响。2) 技术风险（technical risk）威胁到要开发软件的质量及交付时间。技术风险指设计、实现、接口、验证与维护等方面的问题。此外，规格说明的歧义性、技术的不确定性、陈旧的技术以及“前沿”技术也是技术风险因素。3) 商业风险（business risk）威胁到要开发软件的生存能力，且常常会危害到项目或产品。五个主要的商业风险是： (1)开发了一个没有

20、人真正需要的优秀产品或系统(市场风险)； (2)开发的产品不再符合公司的整体商业策略(策略风险)； (3)开发了一个销售部门不知道如何去销售的产品（销售风险）； (4)由于重点的转移或人员的变动而失去了高级管理层的支持(管理风险)； (5)没有得到预算或人员的保证(预算风险)。2. 我们正在进行的软件项目面临严重的风险吗？3. 如何评估风险产生的后果？如果风险真的发生了，有三个因素可能会影响风险所产生的后果，即风险的性质、范围与时间。以下的步骤被建议用来确定风险的整体影响：1) 确定每个风险因素发生的平均概率。2) 确定每个因素的影响。3) 填写风险表，并分析其结果。4. 用什么好的方式来描述

21、风险？按条件转化结果（condition-transition-consequence,CTC）格式来表示风险，即采用如下方式来描述风险：给定，则（可能）将导致：5. 如何缓解风险？为了缓解这个风险，项目管理者必须制定一个策略来减少人员变动。可能采取的步骤包括：1) 及现有人员一起探讨人员变动的起因（如恶劣的工作条件、报酬低、竞争激烈的劳动力市场）。2) 在项目开始之前采取行动，设法缓解那些我们能够控制的起因。3) 项目启动之后，假设会发生人员变动，当人员离开时，找到能够保证工作连续性的方法。4) 组织项目团队，使用得每一个开发活动的信息能被广泛传播与交流5) 制定工作产品标准，并建立相应机制

22、以确保能够及时创建所有的模型与文档。6) 同等对待所有工作的评审（使得不止一个人能够“跟上进度”）。7) 给每个关键的技术人员都指定一个后备人员。小结：对软件项目期望很高时，一般都会进行风险分析。不过，即使进行这项工作，大多数软件项目管理者都是非正式地与表面上地完成它。花在识别、分析与管理风险上的时间可以从多个方面得到回报：更加平稳的项目进展过程；较高的跟踪与控制项目的能力；在问题发生之前已经做了周密计划而产生的信心。风险分析需要占用大量项目计划的工作量。识别、预测、评估、管理与监测都要花费时间。但这是值得的。引用中国2500多年前的军事家孙子的一句话：“知己知彼，百战不殆”。对于软件项目管理

23、者而言，这个“彼”指的就是风险。第七章思考题1、什么是软件质量控制？质量控制是为了保证每一件工作产品都能满足对它的需求而应用于整个开发周期中的一系列审查、复审与测试。质量控制在创建工作产品的过程中包括一个反馈循环。测量与反馈相结合，使得我们能够在得到的工作产品不能满足其规格说明时调整开发过程。质量控制中的关键概念之一就是所有工作产品都具有明确的与可测量的规格说明，我们可以将每个过程的产品 及这一规格说明进行比较。反馈循环对于减少产生的缺陷是至关重要的。2、质量成本的构成有哪些？质量成本包括所有由质量工作或者进行及质量有关的活动所引发的成本。质量成本可以细分为及预防成本、鉴定成本 及失效成本。

24、预防成本包括质量计划、正式技术复审、测试设备及培训。 鉴定成本包括为深入了解“首次通过”各个过程时的产品状态而开展的那些活动。如：过程内与过程间的审查，设备校准与维护，测试。 失效成本是指如果将产品交付给客户之前没有缺陷的话就不会存在的成本。3、如何定义软件质量？软件要符合明确的功能与性能需求，符合已清晰文档化的开发标准，并且具有专业人员开发的软件所应有的隐含特征。定义强调了以下三个重要方面：1) 软件需求是进行质量测量的基础。及需求不符就是质量不高。2) 规定的标准定义了一组指导软件开发的准则。如果不能遵照这些准则，就极有可能导致质量不高。3) 通常有一组“隐含需求”是不会被明确提出的（如对

25、易用性与易维护性的需求）。如果软件明确提出的需求，却没有满足隐含需求，软件质量仍然值得怀疑。4、SQA小组的作用是什么？SQA小组的职责是辅助软件团队实现高质量的软件产品。SQA活动都是由一个独立的SQA小组完成的，包括以下的工作：1) 编制项目质量保证计划2) 参及项目的软件过程描述的编写3) 评审软件工程活动，以验证是否符合规定的软件过程4) 审核指定的软件工作产品以验证是否遵守作为软件过程一部分的那些规定5) 确保根据文档化的规程记录与处理软件工作及工作产品中的偏差6) 记录各种不符合的部分，并报告给高层管理人员5、我们什么时候进行FTR，我们的目标是什么？FTR的目标是：(1)发现软件

26、的任何一种表示形式中的功能、逻辑或实现上的错误；(2)验证评审中的软件是否满足其需求；(3)保证软件的表示符合预先定义的标准；(4)得到以统一的方式开发的软件；(5)使项目更易于管理。FTR一般从介绍会议日程并由生产者做简单的介绍开始。然后由生产者“走查”该工作产品，并对材料做出解释，而评审者则根据预先的准备提出问题。当发现了有根据的问题或错误时，记录员逐一加以记录。6、假设需求模型引入了10个错误，每个错误按2：1的比例在设计阶段放大，设计阶段引入了另外的20个错误，并且这20个错误按1.5：1的比例在编码阶段放大，在编码阶段又引入了另外30个错误。进一步假设，所有单元测试会发现所有错误的3

27、0%，集成测试将找到剩余错误的30%，验证测试会发现剩余错误的50%。没有进行评审，有多少错误将被发布到现场？ 10220201.5203080801305656130393913020 7、重新考虑第6题所述情形，但现在进行了需求评审、设计评审与代码评审，并且这些步骤能有效地发现所有错误的60%。有多少错误将被发布到现场？ 100.44 42200.411111.5300.419190.713130.7990.558、重新考虑第6题与第7题所述情形，对于每个发布到现场的错误，发现与改正的成本是4800美元，在评审时发现并改正每个错误花费240美元，通过进行评审节约多少钱？评审阶段发现并改正的

28、错误：100.642200.6111.5300.651节约的钱：2248005480051240693609、完成基于统计的SQA需要哪些步骤？1) 收集与分类软件缺陷信息。2) 追溯每个缺陷的形成原因（例如，不符合规格说明、设计错误、违背标准、缺乏及客户的交流)。3) 使用Pareto规则（80的缺陷可以追溯到所有可能原因中的20)，将这20（重要的少数）原因分离出来。4) 一旦找出这些重要的少数原因，就可以开始纠正引起缺陷的问题。10、六西格玛方法学的核心步骤 是什么？六西格玛方法学有3个主要的核心步骤：1 定义：通过及客户交流的方法来定义客户需求、可交付的产品及项目目标。2 测量：测量现

29、有的过程及其产品，以确定当前的质量状况（收集缺陷度量信息）3 分析：分析缺陷度量信息，并挑选出重要的少数原因。如果某个现有软件过程是适当的，只是需要改进，六西格玛还需要另外两个核心步骤：改进：通过消除缺陷根本原因的方式来改进过程。控制：控制过程以保证以后的工作不会再引入缺陷原因。以上3个核心步骤与另两个附加步骤有时叫做 DMAIC方法。小结：软件质量管理是在软件过程中的每一步都进行的“普适性活动”包括质量控制与质量保证两部分。SQA包括：对方法与工具有效应用的规程，正式技术评审，测试策略与技术，变更控制规程，保证符合标准的规程，以及测量与报告机制。软件质量，是计算机程序的一种属性，其定义是“及

30、明确与隐含定义的需求的符合程度”。软件质量本质上的复杂性也使SQA复杂化。但是一般说来，软件质量包括了许多不同的产品与过程因素及其相关的度量信息。软件评审是最为重要的质量控制活动之一。评审作为所有软件工程活动的过滤器，当发现及改正错误的成本比较小时，就消除错误。正式技术评审是一种典型的评审会议，在实践中已经证明这种形式对于发现错误极其有效。为了正确软件质量保证，必须收集、评估与发布有关软件工程过程的数据。基于统计的SQA有助于提高产品与过程本身的质量。软件可靠性模型将测量加以扩展，能够由所收集的缺陷数据推导出相应的失效率与进行可靠性预测。第八章思考题1、软件请求变更的起因是什么呢？（1）新的业

31、务或市场条件导致产品需求或业务规则的变更（2）新的客户需求，要求修改信息系统产生的数据、产品提供的功能或系统提供的服务。（3）企业改组或扩大/缩小规模，导致项目优先级或软件工程团队结构的变更（4）预算或进度安排的限制，导致系统或产品的重新定义。2. 每一个参及变更管理的人员的职责与应从事的活动是什么？l 项目经理的职责是保证在确定的时间框架内开发产品。因此项目经理必须对软件的开发进展情况进行监控，找出问题，并对问题做出反应。这可以通过建立与分析软件系统状态报告，并执行对系统的评审来完成。l 配置管理员的职责不仅是要保证代码的创建、变更与测试要遵循相应的规程与方针，还要使项目的相关信息容易得到。

32、l 软件工程师的目标是高效地工作。也就是说，软件工程师在代码的创建与测试以及编写支持文档时不做不必要的相互交流；但同时，软件工程师又尽可能地进行有效的沟通与协调。l 客户只是使用产品。3、SCM中心存储库具有哪些功能？l SCM中心存储库是一 组机制与数据结构，它使软件团队可以有效地管理变更。通过保证完整性，信息共享与数据集成，它具有数据库管理系统的一般功能。此外，SCM中心存储库为软件工具的集成提供了中枢，它是软件过程流的核心。它能够使软件工程工作产品强制实施统一的结构与格式。l 为了实现这些功能，用术语元模型（meta-model）来定义中心存储库。元模型决定了在中心存储库中信息如何存储、

33、如何通过工具访问数据、软件工程师如何查看数据、维护数据完全性与完整性的能力如何，以及将现有的模型扩展以适应新需求时的容易程序如何等。4、SCM 过程应该回答什么问题？1. 发生了什么事？2. 是谁做的？3. 是什么时候发生的？4. 会影响到其他哪些事情？ 5、配置审核期间需要关注的主要问题是什么？l 在ECO中指定的变更已经完成了吗？引起任何额外的修改了吗？l 是否已经进行了技术评审来评估技术正确性？l 是否遵循了软件过程，是否正确地应用了软件标准？l 在SCI中“显著标明”所做的变更了吗？是否说明了变更日期与变更者？l 配置对象的属性反映出该变更了吗？l 是否遵循了SCM规程中标注变更、记录

34、变更与报告变更的规程？l 是否已经正确地更新了所有相关的SCI？ 小结：l 软件配置管理是应用于整个软件过程的普适性活动。SCM标识、控制、审核与报告修改总是发生在软件开发过程中及交付给客户之后。软件过程中产生的所有信息应该作为软件配置的一部分，要适当地对配置进行组织，才能进行有序的变更控制。l 软件配置由一组相关的对象（也称为软件配置项）构成，这些对象是某些软件工程活动所产生的结果。除了文档、程序与数据外，用于创建软件的开发环境也应该属于配置管理。应该将所有的SCI存放在中心存储库中，中心存储库具有保证数据完整性的机制与数据结构，可以支持其他软件工具，支持软件团队所有成员之间的信息共享，还具有版本控制与变更控制功能。l 一旦开发的配置对象通过了评审，它就成为基线。对基线对象的变更将导致对该对象新版本的创建。可以通过分析所有配置对象修订的历史记录来跟踪程序的演l 化过程。基本对象与复合对象可以形成对象池，通过对象池可以构建不同的版本。版本控制就是管理这些对象的一组规程与工具。l 变更控制是一种过程活动，它能够在对配置对象进行变更时保证质量与一致性。变更控制过程从变更请求开始，然后决定是否拒绝该变更请求，最后，对将要变更的SCI进行可控制的更新。l 配置审核是一种SQA活动，它有助于确保进行变更时仍能维护质量。状态报告为那些需要知道变更的人们提供了每次变更的信息。