CMM课程笔记及作业.doc

《CMM课程笔记及作业.doc》由会员分享，可在线阅读，更多相关《CMM课程笔记及作业.doc（83页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、思考题（一）：1、 试举例说明过程的各个要素；2、 为什么要进行需求管理，需求管理的主要任务是什么？3、 CMM 2级的一个关键过程域，为什么不称“软件需求管理”，而称“需求管理”。4、 为什么要作风险管理，要在什么时候作？5、 你是否有在项目中因未作风险管理而遭受孙数的教训？是什么风险，应怎样对待？6、 你认为在自己的组织中实施软件评审的主要障碍和实际困难是什么？7、 简要说明软件质量保证工作的主要任务。思考题（二）8、 举出软件配置管理失误的实例、教训在哪里，加以分析。9、 变更管理的要点是什么？10、 人们普遍认为软件企业实施ISO9000标准不应以是否获证论成败，那么应根据什么？11、

2、 八项质量管理原则具有鲜明的实践性和指导性，请结合自己的实践，表明对其中12项原则的体会。12、 软件企业按ISO9000标准监理质量管理体系最难解决的问题是什么？思考题（三）13、 CMM的KPA为什么要规定五个共同特征？它和目标目标有什么关系？这一设置方法对其他领域的管理有普遍意义吗？14、 SEPG、SQA、SCM、SCCB人员的职责是什么？15、 在LPA SPE中对软件工程项目要做的工作规定了要求，这些要求必要吗？合理吗？可行吗？目标：1、 理解软件过程的概念2、 理解软件过程存在的问题及过程改进的意义3、 掌握软件工程管理的基本概念和方法4、 掌握ISO9000及CMM2、3级的要

3、求基础：1、 先修课软件工程掌握软件工程的基础知识和软件开发方法2、 参加过软件开发工作具有软件开发的实践经验3、 参加过软件管理工作具有软件项目管理的实践经验教训比经验更可贵特点：1、 实践性2、 年轻3、 文化内容：1、 软件工程与软件过程2、 软件工程管理专题需求管理软件风险管理软件评审软件质量和质量保证软件配置管理3、 ISO9000：2000标准4、 软件能力成熟度模型CMM问题的提出能力成熟度CMM结构2、3的关键过程域RMOPFSPPOPDSPTOTPSSMISMSQASPESCMICPRCMM应用CMM I简介参考资料：1、 Carnejie Mellon University

4、, software engineering InstituteThe capability Maturity Model guidelines for inprobing the software process reading ma Addison-wesley 1994(CMM 11版文本，网上可见sei.cmu.edu)2、 郑人杰等，课本3、 能力成熟度模型（CMM）：软件过程改进指南，刘孟仁等，电子工业出版社200不4、 郑人杰等，软件工程高级教程，清华大学出版社教学形式1、 讲课笔记（*部分）重点黄色标记2、 课后阅读3、 思考、讨论4、 作业题考试1、 时间：11月2日上午 9

5、：0012：002、 形式：开卷笔试，独立完成，不得交流3、 要求：a) 在讲课范围内b) CMM 1.1文本的理解和使用软件工程和软件过程内容一、 发展二、 焦点三、 软件开发流程四、 软件生存期五、 软件过程一、发展程序设计语言 Programming LanguageALGOL60机器语言FORTRAN汇编语言COBOLBASIC软件 Software 1960 程序、文档、数据软件危机引出软件工程1、 软件开发工程化 1968 NATO2、 软件开发阶段与瀑布模型3、 软件工程标准二、焦点目标少资源、高效益在人力投入、开发期、成本、质量诸方面求得最佳风险需求：不明与变更人员流动软件知识

6、产权保护不存在绝对缺陷的软件产品成功的标志如期完成预算内完成达到质量要求（需求和期望）软件业和制造业的差异设计生产运输仓储功能度（缺图例）三、软件开发流程（图二）四、软件生存期 Life Cycle软件生存期的概念软件生存期模型瀑布模型计划需求分析设计编码测试运行/维护 定义阶段开发阶段运行阶段XXXXXX五、软件过程1、 过程思维什么是过程将输入转化为输出的一组彼此相关的资源和活动（资源：人员、资金、设施、设备、技术和方法等）为达到一个预期的目的所实施的一系列不扎欧，例如，软件开发过程IEEESDT610一组将输入转化为输出的相互关联或相互作用的活动ISO9000过程的作用过程应支持业务目标

7、，服务于目的的要求过程的实施把机构、管理者、人员和技术基础设施汇聚起来过程思维 一个群体为了追求某个目标，把每个人的精力和活动汇聚在一起，用对过程的共同理解去考虑问题 过程思维和传统的任务思维有着本质的差别所有产品的生产都是经历生产过程而得到的生产的每个阶段可视为生产过程的子过程，它可分为：直接过程：如市场调研、产品设计、生产制作、检验、包装、储存等；间接错成（支持过程）：如检验手段的控制、不合格品的控制、人员培训、质量审核等 过程要素：输入、输出、活动、任务（作业）、资源、测量与验证（）、效果：增值 过程间的关系 包容 邻接交错（部分重叠）并行 2、软件过程 对软件过程的认识尚未摆脱软件危机

8、的困惑 项目大、负责、要求高 用户对软件产品不满意；软件开发超支、超期、质量不佳 频繁发生软件缺陷引发的系统事故。 认识的转变 软件产品的质量很大程度上取决于软件过程（人员、技术、过程位于三角形顶点，质量生产率位于中心） 关注点的转移（软件产品软件过程） 3、ISO /IEC 12207软件生存期过程标准简介软件生存期过程基本过程（获取过程、供应过程、开发过程、运行过程、维护过程）支持过程（文档编制过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审过程、审核过程、问题解决过程）组织过程（管理过程、基础设施过程、改进过程、培训过程）2003年10月12日星期日（第二课）软件需求和需求

9、管理内容：1、 软件需求2、 需求工程3、 需求变更4、 需求变更控制要求5、 需求变更控制实施6、 可追溯性管理一、软件需求1、 系统需求分析（图1、系统需求分配）2、 软件需求（1） 定义（IEEESTD610）用户为解决某个问题，或成为实现某一目标，需求软件必须满足的条件和能力。（2） 软件需求的三个层次 业务要求 用户要求 功能和非功能要求非功能需求： 过程需求：交付需求，实现需求，遵循的标准 性能需求：速度，容量，可靠性 外部需求：互操作性，伦理性，机密性，安全性，使用要求图2软件需求的层次（参见书P59）（3） 质量功能展开（QFDQuality Function Developm

10、ent） 客户要求： 常规需求：客户明确提出 期望需求：并未明确提出的潜在需求 兴奋需求：客户未想到，若实现客户感到意外（4） 分配需求的实例（图三）（P58 图）3、 CMM 2级 关键过程域需求管理（KPA RM）中对软件需求的解释：分配需求（allocated requirements）：分配给软件的系统需求（1） 分配需求包括（P5758）第3点影响和确定软件项目活动的非技术性需求（在合同条款中规定），如： 要交付的产品 交付日期 里程碑软件的技术需求，如： 最终用户、操作人员、支持或集成的功绩 性能需求 设计的约束条件 编程语言 界面要求用于确认软件产品满足分配需求的验收准则（2）

11、分配的需求应当是 以软件来实现是可行的，而且是适合的 已得到清晰二正确的阐述 相互之间是一致的 可以测试的 同时，分配需求应当： 被管理和控制（如必要课纳入软件项目配置管理） 是制定软件开发计划SDP的基础 是指定软件需求的基础（3） 与分配需求相关的组 软件估算组 系统工程组 系统测试组 软件质量保证组SQA 合同管理组 文档支持组 软件工程组二、需求工程1、 需求工程需求开发需求管理图4需求工程的构成（参见P60 图）图5需求开发和需求管理（参见P60 图）2、 需求开发 （参见P61）（1） 获取需求 确定目标用户、服务对象 明确用户代表 用户培训 了解实际业务和业务需求（2） 分析需求

12、 分清功能需求、性能需求、使用需求 必要性 可行性（3） 定义需求 编写软件需求规格说明（SRS） 作用 要求：完整、正确、可行、无歧意、可验证 形式：图表文字（4） 验证需求三、需求变更1、难于完全避免图6 需求的变更（参见P61 图3.6）2、需求变更原因分析1) 单纯的用户因素2) 市场形式变化3) 系统因素4) 工作环境和要求变化5) 需求开发的缺陷 需求分析、定义和评审不充分 与用户沟通不够3、需求变更对软件开发的影响1） 使变更前开发工作和成果失效2） 返工成为被迫采取的对策3） 工作量及资源投入的增加使开发成本提高4） 项目完成时间后延4、需求变更失控可能导致的后果（1） 未受控

13、的需求变更引起需求和实现不一致图P62（2） 受控的需求变更使需求和实现一致图P62（3）5、需求变更风险的策略（1） 与用户充分沟通 与用户共同明确确定的需求的意义表（参见P63表） 向用户说明需求不确切或频繁变更对开发工作的冲击 使用户理解过多变更最终对用户不利（2） 与用户共同确定需求，作为合同附件，签字生效（3） 合同中含有对需求变更的条款（4） 采用原型方法开发，或螺旋模型开发（5） 项目计划中适当留有余地（时间进度、人力投入、费用等）（6） 严格实施变更控制四、需求变更控制要求1、 变更控制的策略（1） 所有需求变更必须遵循需求变更控制规程实施变更规程：procedure 5W1H

14、 什么任务描述 什么目的、目标 何时环节 何处 谁责任人 如何作步骤以上文档化（2） 需求变更提出后是否被接受，应由专门的组织变更控制委员会（CCBChange Control Board）审查决定（3） 不得以任何理由删除和修改需求变更的原是文件（4） 应将已接受的需求变更通知到所有相关人员（5） 已接受的需求变更应能追溯到批准的变更请求（6） 对项目的需求赋予状态属性，以利于需求变更的控制2、 需求变更影响的控制按CMM2级RM KPA的要求，由于分配需求的变更导致软件计划、工作产品和活动的变更，都应对其作： 识别 评价 风险分析 编制文档 制定计划 传达给受影响的小组和人员 跟踪直至结束

15、3、 变更控制的步骤（1） 提出变更请求（2） 审理变更请求，进行变更影响评估、评估内容包括： 变更所需人力投入 变更对原计划安排的影响 估计变更引起的成本增加（3） 批准变更请求（4） 取得用户的认可（5） 修订项目计划（6） 实施变更（7） 验证变更图8（参见P64图3.8）五、需求变更控制实施1、需求变更请求（1）内容 申请号 变更说明 变更类别 .（2）需求变更请求实例（表三需求变更请求）参见P65表格2、表四 需求变更累积表 参见P66表格3、需求控制流（1）需求状态及其演变软件需求在后继阶段开发工作中将逐步展开，加以实现在不同的开发阶段软件需求以不同的像是进行着状态的演变。例如：

16、需求阶段从获取的需求到定义的需求 建议阶段指定出项目计划以后演化为承诺的需求 设计阶段设计工作完成并在验收后成为设计的需求 编码阶段完成变慢和单元测试后成为实现的需求 测试阶段完成确认测手后成为完成的需求图9 生存期各阶段需求状态的演变（参加P67图3.9）六、可追溯性管理1、需求可追溯性与需求变更控制 随着开发工作的进展需求将逐步扩张和演化 各个开发阶段的工作产品之间存在的集成关系 可追溯性矩阵2、可追溯性管理的目标 使每一项需求均能追溯到 前后继承关系的脉络清晰可见3、 两类不同的追溯4、 可追溯性矩阵（1） 矩阵的应用 防止遗漏 可为评审提供方便 便于进行变更影响追踪、分析和检索（2）

17、矩阵的建立和维护表五追溯矩阵实例（参见P69表3.5）（3） 矩阵的应用完整性检验 考察有无需求遗漏的情况 有无冗余代码 检查所有性能需求是否已被测试用例测试 对集成测试计划和系统测试计划进行交互检查需求变更控制 需求变更后相关的工作产品受影响的部分应随之变更 更新需求规格说明，同时要更新追溯矩阵 每增加一项需求，应在追溯矩阵中得到实现软件风险管理（参见P352）一、 什么是软件风险1、 困难和挫折难免 完成软件工程项目需有多种因素配合 不利因素会给项目造成困难、挫折甚至失败 不以人们的意志为转移，是客观现时2、 风险的特点 可能发生的不利事件，发生的概率 R （0R1） 会给项目带来损失 人

18、为地加以干预，可以减少损失“有备无患”、“有备少患”3、 10种最为常见的软件风险（B.Bcehm）A. 合格的人员不足B. 进度家华和预算不切实际C. 开发的软件功能不复核要求D. 软件的用户界面不适用E. 功能有多余的成分F. 需求频变G. 外购部件不能及时提供H. 外包任务出现问题I. 实时性能达不到要求J. 过高估计计算机能力4、 风险分类依据危害性 成本风险：预算不准确造成 绩效风险：不恩嫩构实现预期要求，达不到预期效益 进度风险：速度达不到计划要求风险涉及范围 项目风险：涉及预算、进度、成本、人员等 技术风险 商业风险风险可知性 已知风险 可预知风险 二、 风险管理的任务1、 目标

19、 识别风险 采取措施，降低风险的影响2、 策略 回避 转移 迎接和接受风险的挑战，但将风险损失控制在项目资源可承受的范围内3、 风险管理活动图（参见P358图20.2）三、 风险评估1、 风险识别 检查单（Checklist）是识别的有力工具 项目分解，便于识别高风险部分2、 风险分析 分析每个风险可能造成的影响 给出可供风险大小比较的量值 模型用于分析（COCOMO模型）3、 风险排序 风险概率表（参见P360表20.2）概率取值范围低0.00.3中0.30.7高0.71.0 风险影响表（参见P360表20.3） 风险显露RE（R）Prob（R） Loss（R）式中：RE（R）：风险R发生可

20、能造成的损失Prob（R）：风险R发生的概率Loss（R）风险R如果发生将会造成的损失实例：回归测试的风险露计算图（参见P361图20.3）4、 风险控制风险策略 针对已识别、分析和排序的风险判定风险管理计划 风险管理计划包括： 对该风险进行管理的必要性 风险管理能提供什么条件 实施风险管理活动的责任人 风险管理采取的措施 所需的资源采取的风险管理措施可包括： 收集和获取风险信息 风险回避 风险转移 风险减轻 各种具体的，有针对性的措施，对人员风险，针对需求风险等风险化解措施 Infosys经验 P363 表20.4风险监控 在外部影响因素改变时，风险形式与原评估结果不同 实施跟踪监控，可作定

21、期重新评估或在里程碑处重新评估5、四、2003年10月15日星期三（第三课）软件评审（课本21章）目录一、 软件评审方法二、 软件项目评审实例三、 软件评审的定义1、 软件评审2、 缺陷四、 评审再若干国际标准中的要求五、 软件评审的作用1、 及时清楚开发中2、 提高软件生产率3、六、 正式评审的实施七、 评审实践中所显示的效益八、 实施软件评审经常出现的问题九、 做好软件评审的建议一、软件评审方法软件工程过程是一个重要的质量保证手段是软件测试不可替代的最早于1972年IBM公司实施了M.E.Fagan提出的代码检查法时间表明了它的效果，后推广到针对需求、设计以至管理许多软件工程标准都对其做了

22、规范化要求被广泛采用后，展开成各种形式和不同的称呼，但本质上无太大区别。入如：Inspection，Review，Formal Review（正式评审），以下着重介绍正式评审。二、软件项目评审实例（图 略 ）（图21.2 P376）（实例P376最下）三、软件评审的定义1、 软件缺陷（Defect）对产品规格说明（Specifications）的偏离。如：规格说明规定：abc，而实际产品不是。对客户/用户期望的偏离，客户/用户要求未纳入产品中（可能是规格说明疏漏，也可能实现有问题）。Fault在硬件中称为故障，在软件中它和Defect同义。2、 缺陷有三种错误（Wrong）：未将规格说明正确实

23、现（对规格说明的偏离）。遗漏（Missing）：规定的或预期的需求未体现在产品额外的实现（Extra）：规格说明未规定的.3、 缺陷和事故（Failures）机械与建筑的比喻缺陷是软件内部的“裂痕”，在未影响到用户和系统运行时，并未表现出来。当缺陷引发运行错误（Error）或产生负面影响时，构成事故，对我们造成伤害。4、 评审（Review）IEEE定义：评审是软件开发组之外的人员或小组对软件需求，设计或代码进行详细审查的一种正式评价方法，其目的在于发现其中的缺陷，找出违背执行标准的情况以及其他问题。1994年，IEEE在软件评审和审核标准（IEEE Standard for Software

24、 Reviews and Audits）中说：软件评审是一种对软件元素所作 的正式的、同行间的评审活动，其目的在于验证软件元素满足其规格说明，并能符合标准的要求。与通过评审会来实施的正式评审不同，走遍通常是非正式的，特别是针对程序而言。软件评审通常针对技术产品 (参见P379)四、评审在多干国际标准中的要求五、软件评审的作用 （P383图 切记切记。）八、实施软件评审常出现的问题 （P398）九、做好软件评审的建议软件质量保证目录一、 软件质量的基本概念二、 软件质量的挑战三、 解决软件质量问题的实际困难四、 软件质量国标一、软件质量基本概念1、 质量：产品、体系或过程满足顾客和其他相关防要求

25、的能力的一组固有特性。要求：明示的、习惯上隐含的或必须履行的需求或期望；相关方：顾客、所有者、员工、供方、银行、行业协会等2、 软件质量：软件产品或软件过程为蛮子顾客和相关方质量管理质量目标质量方针质量改进质量保证质量控制质量策划QPQCQAQI3、 质量管理指导和控制组织的与质量有关的相互协调的活动。质量管理活动： 质量策划：确定质量目标，规定必要的作业过程和相关资源以实现质量目标； 质量控制：以大道质量要求为目的（测试、评审）； 质量保证：为大道质量要求提供信任（审核）； 质量改进：提高有效性（达到预期结果程度的度量）和效率（得到的结果与使用资源间的关系）软件质量控制 质量控制（J.M.J

26、uran）一个常规的过程，通过它度量实际的质量特性，并与标准比较，当出现差异时采取行动。 软件质量控制（Donald Reifer）软件开发过程中开展的一系列验证活动。，在开发的某些点检验所得到的产品在技术上是否符合前阶段指定的规格说明。 质量控制的有效方法评审递增式开发根源分析验证和确认（测试）软件质量保证 有计划和系统性的活动，它对部件或产品满足确定的技术需求提供足够的信心（IEEE软件工程术语标准） 基本任务式确保项目履行其对产品和过程的承诺； 是对软件质量计划的管理，SQA并不保证软件的质量，而是确保软件质量计划的有效性； SQA应贯穿于整个开发过程 SQA活动：为软件开发活动及其产品

27、和所用资源提供独立的视角；依据标准来检查产品及其文档的复合型，软件开发流程的符合性；评审需求，设计和编码，以减少测试及其消除缺陷的成本。质量控制质量保证目的使产品达到质量要求对达到质量要求提供信任对象产品过程（产品）做法通过检测，找出缺陷分析原因，加以纠正收集、通报缺陷信息，促进解决举例测试（评审）评审、审核责任人质检人员质保人员（第三方QA）对谁负责对生产部分负责对企业领导和用户负责4、 质量保证的作用 要注意区分质量保证 质量控制，质量控制不能代替质量保证质量保证 质量管理 质量保证和质量控制互相制约，相辅相成，缺一不可，同样重要5、 影响软件质量的因素图略6、质量成本2003年10月16

28、日星期四（第四课）二、软件质量的挑战1、 软件质量事故的困扰2、 用户对软件工程项目成果评价统计3、 Y2K的启示4、 软件开发面临的严重问题5、 “有没有银弹”的争论6、 软件开发面临的严重问题（漫画）三、解决软件质量问题的实际困难1、 软件开发各环节之间需保持协调一致2、 软件需求 用户提不清 需求多变3、 软件质量的量化尚未成熟4、 软件测试技术的局限性 传统的测试方法多年来没有突破性进展 目前的测试技术现状是：发现一个缺陷便清楚一个缺陷，但无法回答软件中还有多少缺陷 何时停止测试是个难题5、 我国软件企业在质量管理方面的弱点 工程化意识不足 管理意识差，认为管理束缚创造性 重视编程（但

29、不注意可读性），忽视文档编址，不愿作测试 标准意识薄弱，缺乏规程，许多工作因人而异，眉头统一的要求 项目中不注意收集数据，经验难于积累 不注意工具的建设，不理解软件工具在软件开发中的作用四、软件质量国际/国家标准（第18章）1、 GB/T16260（idt.ISO/IEC 9126：1991）软件产品评价质量特性及其使用指南 该标准制定了6各质量特性和21个子特性 评价方法可操作性不理想质量特性 子特性 （P306两个表格）2、 ISO / IEC FDIS 9126 （14）：19972001信息技术软件产品质量质量模型内部质量外部质量使用质量（P311 ，图）图中为新的ISO/IEC 91

30、26增加的质量子特性吸引行：软件产品吸引用户的能力*符合性：软件产品符合*相关的标准或约定（或法规）的能力共存性：软件产品（P313，图）（P314，图）（P315，图）3、 ISO/IEC 14598(1-6):19982000 软件产品的评价（P326页图和文字）（P327页图和文字） 评价过程框架适用于上述：开发方的过程获取方的过程评价方的过程 差异：鉴于三种评价五、软件质量保证的基本概念1、质量保证QAQuality Assurance2、验证（Verification） 通过提供客观证据对规定要求已取得满足的认定（ISO2000：2000） 确定开展某项活动的软件产品能否满足此前一些

31、活动对其提出的要求和条件 确定软件开发周期中的一个给定阶段的产品是否达到前阶段确定的需求的过程3、确认（Validation） 通过提供客观证据对特定的预期用途或应用要求已得到满足的认定 确定需求和最终的、已建成的系统或软件产品是否满足其特定的预期用途 在软件开发过程结束时，对软件进行评价，以确认它和软件需求是否相一致的过程。（图：验证与确认的关系）4、评审（Review） 确定主题事项达到规定目标的适宜性，充分行有效性所进行的活动 评价项目活动的状态和产品是否适合4、 审核（Audit） 获得客观证据并对其进行客观的评价，以确定满足审核准则（作为依据的一组方针、规程或要求）的程度所进行的系统

32、的、独立的、并形成文件的过程。ISO9000：2000 确定与需求、计划和合同符合性 （ISO/IEC12207：1995） 为评估是否符合软件需求、规格说明、基线、标准、过程、指令、代码以及合同和特殊要求而进行的一种独立的检查。 （GB/T11475：1995） 通过调查研究确定已指定的过程、指令、规格说明、代码和标准或其他的合同及特殊要求是否恰当和被遵守，以及其实现是否有效而进行的活动。六、软件质量保证过程 （第7章）（ISO/IEC12207：1995 即GB8566：2001） 为软件产品和过程在项目生存期中符合规定的要求，并遵循已指定的计划提供足够的保证 软件质量保证人员应有相应的授

33、权，且不带偏见 可以是内部的，也可以是外部的。差别在于向谁提供信任。七、软件质量保证方法 （P128）1、 指定SQA计划，作为软件项目开发计划的一部分2、 按PDCA开展工作3、 在软件生存期的适当阶段评审项目活动审核工作产品以验证对使用规程和标准的符合情况4、 充分利用其他过程，如测试过程其他组织，如SCM组的评审、验证、确认、审核等活动结果5、 将评审和审核结果通报给项目经理或其他相关经理6、 评审和审核发现的问题无法在项目内解决时，上报给高层主管以求解决7、 SQA各种活动讲求实效，切忌走过场8、 定期请有关方面平评审SQA工作，或是向有关方面征求对SQA工作的意见软件配置管理 （第8

34、章）配置（Configuration）词其他领域中已有广泛的应用，只不过称呼有所不同，但都有其确切的含义。如原子结构的形态和组态.1、 什么是配置管理1） 几种说法 ISO 9003的4.8中给出：配置管理是一个管理学科，它对配置项（包括软件项）的开发和支持生存期给予技术上和管理上的指导。配置管理的应用取决于项目的规模，复杂程度和风险大小。 W.Babich认为，软件配置管理能协调软件开发，使得混乱减少到最小、软件配置管理是一个标识、组织和控制修改的技术，目的是最有效地提高生产率。 GB/T 11457：1995（软件工程术语）对配置管理的解释：A 标识和确定系统中配置项的过程，在系统整个生存

35、周期内控制这些项的投放和更动。记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。B 对下列工作进行技术和行政指导与监督的一套规范一对一配置项的功能和物理特性进行标识和文件编制工作；一控制这些特性的更动情况；一记录一含意：配置管理的对象，软件工程过程产生的所有信息项。一包括：计算机可执行的源代码。目标马等。2）2、2003年10月17日星期五（第五课）2、软件配置管理计划 项目开始制定，作为软件开发计划SDP的一部分 国家标准GB/T /250590 计算机软件配置管理计划中的主要内容1） 负责软件配置管理的组织及其任务、职责及其有关接口的控制2） 软件配置管理活动 配置标识 配置控制

36、（即变更控制） 配置状态记录和报告 配置审核及其评审3） 配置管理采用的工具、技术和方法4） 附：软件配置管理计划示例及其配置管理报表示例3、 软件配置标识（Configuration Identification）确定配置项（Configuration Item） 在软件生存期中需要管理起来的（或称需要受控的）软件项（图2软件配置项：见课本，5个大圆圈，中间是“目标代码”） 配置项的多少因项目而异，项目大、负责、其数量可达数百、以至上千 配置项分类1） 技术性：规格说明，源代码清单、测试用例；非技术性（管理性）：计划、报告等2） 组织内或项目开发的；外购的（表2软件配置项清单：见课本）指定命

37、名规则 原则1） 唯一性2） 可追溯性 树状层次式命名规则（图3 树状结构命名示例）4、 变更管理（Change Managemnet）1） 配置数据库作用 记录与配置相关的信息 评价系统变更的后果 提供配置管理信息三类库 开发库 Development Librarya、 专供开发人员使用b、 库中信息可能频繁修改、更动c、 控制宽松 受控库 Controlled Libraryd、 存放开发阶段结束时的工作后果e、 也称软件配置管理库 产品库 Product Libraryf、 存放系统测试后的最终产品g、 等待交付典型的数据库查询问题1）哪些客户已提取了某个特定的系统版本运行一个给定的系

38、统版本需要什么硬件和操作系统一个系统已生长了多少个版本，核实生成的若某个特定的组建变更了，回影响到系统的哪些版本一个特定的版本有那几个变更请求是最为重要的一个特定的版本有多少已报告的错误2） 基线与变更控制开发中的变更不可能完全避免 变更来源A、 用户的需求变更B、 开发人员对技术方案或设计细部的变更C、 管理人员提出的方案，设计变更 变更的原因D、 开发人员掌握了更多的信息E、 对问题或方案有了更深刻的认识 变更管理的任务F、 分析变更G、 记录、追踪变更H、 使变更在受控状态下进行必要性、经济可行性、技术可行性基线（BaseLine） 软件生存期开发阶段末尾的特定点，也成为里程碑（mile

39、stone）（图4软件配置基线，见课本） 开发阶段末尾，已经过验证的开发成果，不应作任意变更，将其“冻结”起来 三种常用的基线（1） 功能基线 经过正式评审和批准的系统设计说明中对待开发软件提出的规格说明 经过项目委托单位和项目承担单位双方签字同意的合同中规定的待开发软件的规格说明 由下级申请及上级同意，或直接上级下达的项目任务书中规定的待开发软件的规格说明（2） 分配基线软件需求阶段结束时，经过正式评审和批准的软件需求规格说明SRSSoftware Requirement （3） 产品基线软件集成3） 变更控制变更请求：提出变更请求表 Change Request Form（CRF）表3 变更控制表项目名变更请求人 日期 编号要求的变更描述变更分析员分析日期受影响模块变更评估变更优先性变更实现估计工作量CCB收到日期CCB决定变更实施负责人变更日期递交QA日期QA决定递交CM日期表中：CCB是变更控制委员会（Change Control Board） QA质量保证组 （Quality Assuranme） CM是配置管理组（）变更管理过程（表4）记录变更A、 将CRF作为配置项在数据库中登录B、 在变更了的模块代码上变更记录（表5变更记录示例）5、 版本管理和发行管理