Ch05-可重复性管理

1、软件过程改进方法与实践案例王安生Chapter 5.可重复性管理“加强纪律性，革命无不胜。”软件过程改进方法与实践案例王安生可重复性？ 虽然没有两场完全一样的战争，但是军事家们同样可以总结出历次战争过程的共性。通过对战例的总结，获得了面对新战争环境下如何能够利用已有战例经验和教训，设计出“可重复”的战争过程。“纪律性”是任何军事组织所强调的第一个共性。铁的纪律是实现“可重复”的基础。 工业化生产的最高境界就是产品生产的可重复性。具有组织纪律、能够进行大规模生产的产业工人是传统工业生产的基础。当今对于制造业，可重复生产的最佳途径是无人值守工厂。软件过程改进方法与实践案例王安生 Process C

2、ategoriesManagementOrganizationalEngineeringLevels/1 Initial2 Repeatable3 Defined4 Managed5 OptimizingAd Hoc ProcessesIntegrated Software ManagementIntergroup CoordinationRequirements ManagementSoftware Project PlanningSoftware Project Tracking and OversightSoftware Subcontract ManagementSoftware Qu

3、ality AssuranceSoftware Configuration ManagementOrganization Process FocusOrganization Process DefinitionTraining ProgramSoftware Product EngineeringPeer ReviewsSoftware Quality ManagementQuantitative Software ManagementTechnology Change ManagementProcess Change ManagementDefect Prevention软件过程改进方法与实

4、践案例王安生CMM Level 2 Key Process AreasRequirements Management需求管理(RM)Software ProjectPlanning软件项目策划(SPP)SoftwareConfiguration Management软件配置管理(SCM)Software Quality Assurance软件质量保证(SQA)Software Subcontract Management软件子合同管理(SSM)Software Project Tracking and Oversight软件项目跟踪和监督(SPTO)软件过程改进方法与实践案例王安生Requir

5、ements Management需求管理(RM)软件过程改进方法与实践案例王安生需 求 管 理 软件需求总是不清楚的。 有人把需求的获取看作一个知识获取或学习的过程。 需求的典型输入是一个想法(idea)，理想的输出是软件规范说明(Specification)。 一旦一个软件需求能够用形式化语言描述清楚，软件的需求就变得100%清楚了。软件过程改进方法与实践案例王安生需求的获取过程 客户的抱怨：“我们不知道我们需要的软件是什么，我们只知道你所交付的软件不是我们所需要的，此软件不好用。” 用户需求 招标/投标 系统需求分析 分配给软件的需求 分配给硬件 的需求 分配给其他 的要求 软件需求文档

6、 分配基线 需求变更 功能 需求 非功能 需求 软件过程改进方法与实践案例王安生Requirements readers用户需求客户经理系统最终用户客户工程师开发方的经理系统体系结构师系统需求系统最终用户客户工程师软件开发人员系统体系结构师软件需求文档软件开发人员系统体系结构师客户工程师(参考)需求类型需求类型读者读者软件过程改进方法与实践案例王安生Requirements Management- Purpose 1. 需求管理的目的 建立客户和项目开发者之间的共同理解(common understanding) 2. 就客户需求，建立和维护与客户之间的协议(合同） 此协议(合同)表示为： s

7、ystem requirements allocated to the software. “customer”既可以解释为系统工程组、市场组、企业内部的一个部门，也可以解释为外部客户。 协议要包括技术和非技术性需求 协议作为建立、策划、执行、追踪软件项目整个生命周期活动的基础软件过程改进方法与实践案例王安生系统需求系统需求分析分析/ / 设计设计HWCI 测试瀑布模型中的需求系统系统设计设计系统要系统要求分析求分析硬件研制软软件件开开发发功能功能基线基线分配分配基线基线开发配置开发配置系统系统集成集成 和测和测试试产品基线产品基线软件软件需求需求分析分析制造详细设计初步设计硬件要求分析验收验

8、收/ /移交移交概要概要设计设计详细详细设计设计编码编码CSUCSU测试测试CSCCSC集集成和成和测式测式CSCICSCI测试测试发发用户需求系统需求软件需求分配的需求招标招标软件过程改进方法与实践案例王安生分配的需求3. 系统需求的分配 通常，软件只是系统的一部分。即使是在软件密集的系统中，仍然是这样的。必须把系统的要求分配给软件需求、硬件需求、以及人(或其他)的操作需求： 这样的分配过程，在大系统研制过程中，往往不是有软件工程组决定的（例如，是由系统工程小组分配的）。因此，许多情况下，软件工程组不能决定和控制这种分配。 在项目的约束条件下，软件工程组要采用适当的步骤，保证系统分配给软件的

9、需求被表达、编写成正式文档、并控制其变更。System Requirements系统需求Hardware Requirements硬件需求(项)Software Requirements软件需求(项)Human Requirements操作人员需求(项)软件过程改进方法与实践案例王安生需求管理的目标 1) 控制分配需求以建立软件工程和管理所使用的基线。 通常系统工程组会将模糊的需求，或者，只要硬件没法实现的，都交给软件实现。高估软件的能力，并带来风险。 需求不清晰、以及今后的不断变更造成项目的失败。 建立基线，掌握“类似”的需求，从而达到“可重复”。 2) 软件计划、工作产品和活动与分配需求相

10、一致。 开发计划往往会偏离实际的软件需求，直接依据项目经理或客户要求，定义进度和工作产品。软件过程改进方法与实践案例王安生需求与项目的可重复性 需求是项目的最基本输入，也是决定项目之间是否具有类似的基本依据。 当需求清晰后，我们就能对项目的规模、问题领域、大致的软件体系结构、人员所需、时间进度、软件质量要求(包括功能和非功能性)有一个大概的了解。 找出“类似”项目，达到可重复！ 一旦需求是非常不稳定的(在开发过程中，不断变更)，以前的项目经验就失去意义。项目的“可重复性”就成为空话！ 顺利到达目的地的最快、最安全的路线是你最熟悉的路线！软件过程改进方法与实践案例王安生 对功能性需求的理解，可以

11、澄清许多问题，例如： 1) 软件需求文档中的用例图(use cases)和部署图能让我们了解未来的系统如何使用和部署。 2) 哪些需求的实现难度大、风险大？软件过程改进方法与实践案例王安生 通过对非功能性需求的理解, 可以澄清许多问题，例如， 1) 对开发环境、运行环境的理解，能让项目组估计出软件的难度。 2) 对行业标准等的理解，可以掌握足够的项目知识，建立与客户的共同理解。 3) 对编程语言、数据库等要求的理解，可以清楚对人力资源的要求。软件过程改进方法与实践案例王安生项目的类似性 通过对功能和非功能性需求的理解，我们能够知道所谓的“类似项目”类似在哪些方面，例如，编程语言、用户的行业背景

12、、数据库、软件规模、人力资源、进度、软件缺陷率的要求等。 特别是非功能性的要求，对于确定项目之间是否具有可比性，起着决定性的作用。 例如，实验室使用的求解微分方程的软件与运载火箭上求解微分方程软件，在功能上是一样的。 但是软件质量和运行环境的差别，造就了后者比前者要付出几十倍的费用代价。软件过程改进方法与实践案例王安生例：针对非功能性需求的改进 Engineering Ingegneria Informattica SPA 意大利的一家大型软件工厂，420员工，1994年营业额3500万ECU。 目的 解决预算的准确性 方法 扩展开发理念，增强正式说明书中非功能需求（例如易用性、可靠性、可移植

13、性）说明，使得这些因素对软件造成的影响可以在整个开发过程中被跟踪 建立自我加强型的生命周期，了解这些因素的影响，从而更好地制定评估和项目计划。软件过程改进方法与实践案例王安生例：针对非功能性需求的改进 商业收益 实验的6个项目，从最初的25%预算误差减少到8%（方法只用于不小于250 000ECU的项目）将非功能性需求文档化基于以前的经验计划合适的活动精确费用预算和资源分配培训客户关于软件质量的问题展示软件能力项目管理和利润率改进从需求到开发活动映射的相关知识软件过程改进方法与实践案例王安生Software Project Planning软件项目策划(SPP)软件过程改进方法与实践案例王安生

14、项 目 策 划 策划的目的和目标 “项目策划”的目的在于建立并维护规定项目各项活动的计划。 “项目策划”包括制订项目计划、与共益者(stakeholders)进行适当交流并且就计划达成一致和维护计划。 “策划工作”是从那些规定产品和项目的需求开始，包括对工作产品和作业的属性及所需资源进行评价、协商各项承诺、拟订进度，以及识别和分析项目风险。软件过程改进方法与实践案例王安生项目计划的开发过程 谈判承诺iate Commitment 估计规模 估计资源ate Project Resources 开发进度 Schedule 初始 需求需求 谈判 WBS SLOC 程 序 员人 月 和机时 项目 进度

15、 Schedule 实际als 估计 Y N 交付产品 比较 分解 需求 进度要求？ 开发 软件过程改进方法与实践案例王安生优化级-不断改进 个人简历jian 用户 需求 企业需求 运行需求 系统环境需求 系统性能需求 实践验证过的 项目控制方法 员工 组织方法 可使用的技术 和项目方法 软件开发计划 1.目的和范围 2.与其他文档的关系 3. 软件开发管理 3.1 项目组织与资源 3.2 进度和里程碑 3.3 风险管理 3.4 安全保密 3.5 与其他承制方的接口 3.6 转承制方的管理 4 软件工程 4.1 组织和资源 4.2 软件开发标准 4.3 非开发软件 5 正式合格性测试 6 软件

16、评审 7 软件配置管理 项目控制需求 承包商 进度 预算 开发过程 模型 合同 计划 发展 方向 系统 要求 接口 定义 性能 需求 软件过程改进方法与实践案例王安生项目策划中的问题 制定一个项目计划的关键是对产品规模、资源、时间进度制定一个项目计划的关键是对产品规模、资源、时间进度的估计。的估计。COCOMO最初发表于1981年巴里勃姆(Barry Boehm)软件工程经济学一书中，作为在软件项中估算工作量、成本以及时间进度表的模型。巴里勃姆于1981年在该公司担任软件研究与技术总监。COCOM是基于对TRW飞机制造公司的63个项目的研究。这些项目所包含的代码量从2000行到10000行，包

17、含的编程语言从汇编语言到PL/I。这些项目采用瀑布模型进行软件开发，这种开发模式是在1981年时主流的软件开发模式。1997年开始研发“COCOMO II”，并最终于2001年发表于软件成本估算：COCOMO 模型方法 软件过程改进方法与实践案例王安生项目开发中的交流方式1 line3 lines10 linesN persons need n(n-1)/2 lines6 lines自设计/自编程/自测试/一包到底, communication easy软件开发是“个人艺术”，而不是工程软件的工程管理软件过程改进方法与实践案例王安生项目的组织结构JuniorProgarmmersSeinor

18、progarmmersLibarariesAdministrationTest teamassitanr chiefprogarammerChiefProgarmmer1972年，首次在IBM使用软件过程改进方法与实践案例王安生矩阵式的组织结构GUI应用服务数据库 话费数据采集QA测试项目 1XXXX项目 2XXXXXX项目 3XXXSEM1M2M3M4T1T2T3T4T5T6T7T8T9T10T11T12RequirementsDesignCodingIntegration/testingDelivery以瀑布模型为基础的项目计划网络图例M: 评审点T: 工程任务关键路径时间进度软件过程改进

19、方法与实践案例王安生活动时间线软件过程改进方法与实践案例王安生员工工作分配4/711/718/725/1/88/815/822/829/85/912/919/9T4T8T11T12T1T3T9T2T6T10T7T5张三李四AnneMaryJim软件过程改进方法与实践案例王安生风险管理 Boehm的十个顶级风险项（Risk Item） 人员流失（Personnel shortfalls） 不实际的进度和财政预算 开发错误的软件功能 开发错误的用户界面 种金子 不断的需求更改 外部完成的任务的不满足 外部提供部件的不满足 实时性能不满足 过分强调计算机科学的能力软件过程改进方法与实践案例王安生计划

20、的可重复性 简单的计算往往是不可行的。 简单公式：所需人天 = 工作量/工作效率 并假：设员工随时可用 实际上 企业的管理者不希望员工没事做 一个员工可能要同时做多个项目 员工的风险是最大的风险 可重复： 预计到一系列的风险 考虑到各种资源等 参考原先成功项目的经验 吸取失败项目的教训软件过程改进方法与实践案例王安生Software Project Tracking and Oversight软件项目跟踪和监督 (SPTO)软件过程改进方法与实践案例王安生项目跟踪与监督 软件项目跟踪和监督要达到的目标为： 1) 依据软件项目计划跟踪实际结果和性能。 2) 在实际结果和性能明显偏离软件计划时，采

21、取纠正措施并加以管理，直到结束。 3) 受影响的组和个人同意对软件承诺的更改。 按照(文档化的)估计、承诺和计划，跟踪和评审软件各阶段完成的情况和结果，并根据实际完成情况和结果调整这些计划。 “软件项目计划”是跟踪软件活动、通报状态和修订计划的依据。 项目管理者需要监控软件项目活动的状态。特别是在项目计划规定的里程碑和基线处，一定要将实际完成的软件规模、工作量、成本和进度与计划进行比较，以准确判断实际进展情况。软件过程改进方法与实践案例王安生跟踪的准确性 从软件的开发角度来看，大多数情况下，0%和99%的完成，其效果几乎是一样的。提升软件开发过程可见性的方法是，在0%与100%之间设立合理的刻

22、度(度量指标)，用更精确的指标让管理者更清楚实际的进展情况。下面的例子是对刻度的一些建议： 每个检查点必须是特定的和可测量的，例如： 50%的需求文档全部通过评审，而不是每个文档都完成50%。 50%模块设计完成、执行设计评审以及纠错工作。 25%模块通过编译，而没有错误。 15%的程序通过测试，执行没有错误。 用户手册的第一个草稿完成，并提交技术评审。在项目计划中以及监督时，使用数字要有准确的百分比，否则就失去意义，例如： 50%的模块完成设计，应当规定为，共有100个模块，其中的50个模块100%完成，而不是所有的模块平均完成50%(可能意味着，一个模块也没完成)。 所有的测试用例都测过一

23、遍，通过率达100%，而不是简单地说：通过测试。软件过程改进方法与实践案例王安生开发队伍的组织形式 层次组织形式 矩阵形式 主程序员形式 SWAT形式 Agile 形式 开源软件开发软件过程改进方法与实践案例王安生开发队伍的组织形式 层次组织形式TABCDE子系统 A子系统 B子系统 QA测试软件过程改进方法与实践案例王安生开发队伍的组织形式 矩阵形式- 移动网络实时信号采集GIS 开发数据库开发QA测试项目 A项目 B项目 C 软件过程改进方法与实践案例王安生 主程序员形式JuniorProgarmmersSeinor progarmmersLibarariesAdministrationT

24、est teamassitanr chiefprogarammerChiefProgarmmer软件过程改进方法与实践案例王安生开发队伍的组织形式 SWAT形式 采用渐进式、迭代的过程 SWAT(Skilled With Advanced Tools) 4-5人左右，一起办公 信息交流快捷，无正式会议 头脑风暴或白板画图 增量式开发 重用部件 良好的工作流程管理 高昂的工作激情软件过程改进方法与实践案例王安生开发队伍的组织形式 Agile 形式 某些类似于SWAT 更依赖于人，而不是队伍 “计划驱动” 在这里成为个人能力充分发挥，而不受到任何的约束 项目的跟踪变得苦难！ 避免项目风险要靠人Le

25、vel人的能力Agile3Fluent能够很灵活地从一种方法到另一种。能够修正方法，适应未遇到的情况。可用，能跟踪其工作2-Detaching对某种方法适应。可以学习其他方法，能接受未遇到过情况的方法。1Following只能遵循一种方法，对于其他新方法就会晕乎。能够按部就班地执行步骤，例如，填写Web网页代码，或运行测试。不可用/不可跟踪软件过程改进方法与实践案例王安生被动使用者开发队伍的组织形式 开源软件开发 “没有围墙的公司” 没有合同 开发进度没有计划， 缺乏文档 出现Bug，不知何时能定位和解决 没法做到项目跟踪和监督积极使用者合作开发者核心队伍软件过程改进方法与实践案例王安生实际与

26、计划差异 实际情况总是与计划具有差异的 计划颗粒度越细，差异可能越大， 越理想的计划，差异越大 各种风险的发生，可能导致计划的很大程度上的改变 记录这些差异(进度、工作量、费用等) 估计和计算出员工生产能力的曲线 今后项目的计划可能做的更准确软件过程改进方法与实践案例王安生项目跟踪与监督颗粒度和工作量 计划跟踪的颗粒度越细，工作量越大 作为项目经理，如果你跟踪到每行代码，你会抱怨“还不如自己开发”，你就又把工程做成了“艺术”。 记录这些偏差(进度、工作量、费用等) 避免太频繁的干涉细小的偏差 用经验，使其偏差在容忍的范围内 如果一个项目的报告中讲，进度和质量(缺陷)没有任何的偏差，这篇报告极可

27、能就是假的。 如果每天都开评审会议，额外工作量将引起员工的疲惫，导致代码或文档质量的下降软件过程改进方法与实践案例王安生Software Quality Assurance软件质量保证(SQA)软件过程改进方法与实践案例王安生软件质量保证 当“哥们式”的生产关系被打破后 就需要建立一套制度，以便于： 1) 寻找摆脱繁杂的管理工作的方法，使得经理们有更多的时间开展或监督员工的开发工作； 2) 雇佣一些人做审计工作； 3) 鼓励员工相互监督质量。软件过程改进方法与实践案例王安生质量管理过程与开发过程的独立性 软件过程改进方法与实践案例王安生过程质量观点对于制造类的产品，过程与产品质量具有直接的关联

28、关系对于软件，问题要复杂的多，因为;个人能力和经验的重要性外部因素，如，新的发明，进度加快等，都会导致质量问题.统计学的质量控制方法，对于软件是适用的软件过程改进方法与实践案例王安生过程质量观点定义过程开发产品评估产品质量质量OK？改进开发过程标准过程软件过程改进方法与实践案例王安生定义标准，如:评审规则配置管理等监督开发过程，保证标准得到执行将质量报告给项目管理和软件购买者实施过程中的质量软件过程改进方法与实践案例王安生定义标准是进行有效质量管理的关键国际、国家、企业、项目标准项目管理者的重点是剪裁和定义出适合项目的标准产品标准(Product standards) 定义软件部件的特性，如编

29、程风格。过程标准(Process standards) 定义软件的开发过程质量保证和标准软件过程改进方法与实践案例王安生 采纳最好的实践，避免错误的重复 质量保证过程框架， 检查标准的兼容性 连续性 新员工可以很好地理解组织的规定、项目的规定标准的重要性软件过程改进方法与实践案例王安生产品和过程标准例子软件过程改进方法与实践案例王安生软件质量保证的目标 1) 软件质量保证活动是有计划的。 2) 软件产品及其活动遵循所用的标准、规程和需求的情况得到客观的验证。 3) 受影响的组和个人接到软件质量保证活动和结果的通知。 4) 高层管理者处理软件项目内部无法解决的不符合问题。软件过程改进方法与实践案

30、例王安生对SQA的误解 1) 把SQA的工作简单地等同于软件测试工作。当软件质量问题比较大时，认为是测试人员测试不够所引起的。 这种观点忘记了“测试只能表明程序的错误，而不能证明程序正确”的论断。 2) 把SQA作为一种摆设，只是对外部客户的宣称，让新来的员工担任就行。 这种观点，削弱了SQA应当承担的过程可视性的作用。 3) 认为SQA人员要解决一切质量问题。SQA人员要做所有的评审、测试等工作。 这种观点，将SQA人员的工作过度理想化。 4) 除非开发经理要求SQA帮助做些工作，否则SQA就不管开发的事。 这种观点，将使得SQA不能发挥作用，长此以往，软件开发队伍将逐步退化为黑箱式的开发状

31、态(回到CMM一级所描述的混乱状态)。软件过程改进方法与实践案例王安生SQA责任 建立SQA制度和小组，并要确保SQA能够： 1) 评审所有(或抽检)的开发计划和质量计划是否完整 2) 作为审查的协调人，参加设计和代码的审查； 3) 评审所有的测试计划，是否遵循标准； 4) 对重要的测试结果进行评审，确定是否符合计划要求； 5) 定期对SCM的工作和性能进行评审，确定是否符合标准； 6) 定期参加所有项目的阶段评审，确认标准和规程是否得到合理的满足。软件过程改进方法与实践案例王安生SQA人员培养 SQA的重要性是由承担SQA工作人员所担负的。 SQA人员的挑选和培养对于企业是十分重要的。这就像

32、国家的审计人员一样，需要从“德”和“技”两个方面挑选和培养SQA人员。 一种可能的解决方案是，让那些准备提升的项目经理，在上任前担当一段SQA工作； 或者，让项目经理与SQA人员进行互换。这种方法可以确保开发队伍和SQA人员的相互理解，增强共同合作的精神。软件过程改进方法与实践案例王安生Software Configuration Management软件配置管理(SCM)软件过程改进方法与实践案例王安生 配置管理(Configuration Management) 更准确的应当称为：配置项管理，也就是对生产过程中能够单独存在、功能独立的项进行有效的管理。 例如，可独立配置的软件项、部件、单元

33、、数据文件及其操作等。 配置管理并不是软件行业的发明。在现代工业生产中，最成熟配置管理也许是机械行业。 那里的配置项是：一个部件、一台发动机、一个螺钉等） 例如，在汽车行业的研发、生产、使用和维护。特别是为汽车使用安全所建立的缺陷招回制度，是对配置管理成功的应用。软件过程改进方法与实践案例王安生建立SCM的需要 在软件的开发和使用，同样存在配置管理问题。随着企业规模的扩大，所承担的项目越来越多。 如果每个项目都从第一行代码编起，也许这家公司永远也没法获得利润。 有效的方法是建立可以重复使用的软件库。 事实上，我们在程序开发中基本上都在使用其他人已经做好的软件库，进行软件的开发。 例如，我们使用

34、C语言编程时，一旦需要使用数学库，我们只需要在程序中写上#include ，就意味着，我们使用编译产品厂家提供的数学库。因此，我们不用再编写sin(x)、log(x)等的程序。 在C语言的编程中，可能最普遍使用的是#include 。stdio（标准输入输出）库提供了最基本的输入输出，例如，printf等。软件过程改进方法与实践案例王安生建立SCM的需要 要做到项目的可重复，最基本的做法也是尽可能地重复使用其他人做好的或先前项目使用过的代码。即，建立可重用库，从项目上做到对代码的重用。 重用库的代码可以是二进制目标码的形式，也可以是源代码的形式。 可重用的运行库，既可以是静态库，也可以是动态库

35、。 静态库中提供的函数功能，在进行连接(link)时，被加入到可执行程序中。而动态库在连接(link)时，只是说明了库函数加载的地址，只有在运行时才加载。软件过程改进方法与实践案例王安生必须建立新的软件版本，随着下面因素的变化：不用的硬件和OS；提供不同的功能；针对客户需求的定制和剪裁。配置管理涉及到对软件进化的管理系统更改时一个团队活动；CM的目的 之一是控制软件更改中所产生的费用和工作量软件版本变更软件过程改进方法与实践案例王安生建立SCM的需要 1) 软件的需求是不断变化，从而导致主要功能一样的软件可具有多个版本； 2) 软件中的错误，导致软件版本的不断升级； 3) 一段代码是多个程序员

36、共同完成的，某个人对自己那块代码的修改，可能引起整个或其他人的代码的错误。 4) 代码被大家共享，一旦修改，而没有通知到其他使用者，版本的管理就会出错； 5) 企业的许多客户已经在使用我们的软件，而每个客户可能使用的版本都不一样。企业需要保留和维护每个客户的版本，从而造成人力资源(越来越多的维护工程师)的极大浪费。软件过程改进方法与实践案例王安生SCM的步骤 1）确定被管理的对象（级别等）确定被管理的对象（级别等） 2）管理（入库、修改等）的权限）管理（入库、修改等）的权限 3）给被管理对象唯一的一个编号）给被管理对象唯一的一个编号(标识号标识号) 4）控制对被管理对象的修改）控制对被管理对象

37、的修改 5）跟踪和记录其修改）跟踪和记录其修改软件过程改进方法与实践案例王安生实现SCM的关键 首先，首先，要搞清被管理的项。依据管理的精细度，一个被管理项可以划分为一个软件系统或子系统、一个计算机软件配置项(CSCI)、一个计算机软件部件(SC)、一个计算软件单元(CSU)，甚至是一段关键的核心代码。 除此之外，被管理项还应当包括相关的软件开发、使用和维护性的文档，以及开发环境、运行环境等。 一旦确定或定义了被管理项，就要给其一个唯一的标识号(ID)。这个ID应当在其生命周期里是始终有效的，且是唯一的。 唯一性能够让用此软件项进行项目开发的开发人员、使用人员和维护人员，能够依据ID正确识别被

38、管理的项。这就像社会管理部门要分发给每个人一个身份证号一样。软件过程改进方法与实践案例王安生实现SCM的关键 其次，其次，对被管理项建立了唯一标识号后，接下来的问题是如何控制对被管理项的状态和修改。 例如，在交通管理中，汽车作为被管理项。交通部门给每辆汽车一个牌号，并对汽车的发动机编号、车架的编号也进行登记备案。其目的是防止对汽车在其生命周期内轻易地更改，以便于控制 对于被管理的软件项，同样要控制其更改。与汽车中的配置项更改不同的是，软件的更改不仅是本软件开发者的事情，还会涉及所有使用此软件项的软件系统、使用者、相关的程序员。 另一方面，软件代码的修改可见性(例如，比汽车牌号等修改的可见性)差

39、。人们很难发现被修改的代码，以及无法估计所修改的代码会产生多大的影响(包括正面和负面的)。 因此在企业中，最好的方法是建立一个更改控制委员会(CCB)，站在企业的高度审视和评审各种修改，把修改所带来的负面影响降到最低。软件过程改进方法与实践案例王安生 再者，再者，人们的记忆能力是有限的。解决的方法是对任何软件项的修改、委员会决定是否修改的意见、以及与修改相关的各种情况进行记录与存档。 以便，人们能够对修改过程进行评审和回顾。 综合上述，我们看到，实现配置管理里的关键是：标识（被管理的项）、控制（其标识（被管理的项）、控制（其修改）、记录（其状态）修改）、记录（其状态）。软件过程改进方法与实践案

40、例王安生SCM的流程 标识（被管理的项）、控制（其修改）、记录（其状态）标识（被管理的项）、控制（其修改）、记录（其状态） 建立新的基线 将确认的更改入库 提取官方版本 更改请求单 源/目标码/ 文档/工具等 产品基线库 更改库 需求/设计/使用 建立/修改基线 确认基线 CCB：授权 开发组： 实现更改 确认更改 CCB：批准更改 初始 版本产品 软件过程改进方法与实践案例王安生 更改库，则要存放确认的更改，包括： 1) 每个模块的修改层次。 2) 所使用的汇编器、编译器、连接器、装载程序以及可执行程序和测试。 3) 测试用例和修改层次。 4) 测试数据。 5) 所使用的文件。 6) 组成系

41、统的软件、硬件、外围设备以及硬件的更改层次。 7) 操作和使用过程。 8) 如果有非单独的测试，还要给出执行的(批命令)流程。软件过程改进方法与实践案例王安生 配置管理的颗粒度 颗粒度的定义要考虑下列几个主要因素： 1) 代码的重要性。 2) 模块的大小。 3) 企业的人力资源状况。 4) 产品的研发周期等。 颗粒度可以简单地划分为：重用库级的、部件级的、单元级的。软件过程改进方法与实践案例王安生配置管理级别和工作量CSCICSCCSCCSUCSCCSUCSCCSCCSCCSUCSU库非开发软件SystemCSCICSCI单元单元/语句级别语句级别部件部件/库级别库级别配置项级别配置项级别系统级别系统级别管理工作量管理工作量小小大大软件过程改进方法与实践案例王安生版本的标识 版本标识的规程，确保所标识的部件版本没有二义性 是那种基本方法： 版本编号(Version numbering); 属