软件项目管理章

1、1. 课堂授课2. 案例讲解3. 专题讲座4. 课程实践 Microsoft Visual SourceSafe (VSS)。微软Windows平台下的一个小型软件配置管理工具。 Microsoft Project。微软Windows平台下国际通用的项目管理软件。1.PANKAJ JALOTE, CMM in Practice: Processes for Executing Software Projects at Infosys, 高等教育出版社, 2000. 1.M.C. Paulk, Capability Maturity Model for Software, SEI-91-TR-2

2、4, 1991.2.Pankaj Jalote, Software Project Management in Practice, 2002. p你是否参加过软件项目的开发?p你是否组织过软件项目的开发?p有哪些印象深刻的成功和失败案例?p你认为软件开发中最具挑战性的问题是什么?p你认为自己能否胜任以下职位 程序员、设计师、项目经理、开发顾问p你希望将来在IT企业中充当什么角色？如何达成？1.1. 软件开发与软件项目管理1.2. CMM简介1.3. INFOSYS公司的项目管理实践1. 软件项目管理的重要性2. 软件危机的提出3. 世界软件产业发展现状及中国软件业的差距 p 为何需要软件项目管

3、理？ 软件的定义： 是使计算机能够工作的指令集合和相应的数据结构和文档，是一种产品，将计算机的硬件能力发挥出来的一种工具，是传递信息的一种工具，对信息的处理手段。 p 软件的特征：1. 软件是一种逻辑元素，而不是物理元素；2. 软件是开发出来的，而不是用传统的方法制造出来的；3. 软件不会被用坏，一般产品的失败概率都遵循浴盆曲线；4. 工业界已经是标准化装配时代，但软件还是定制时代；5. 创新性和人为因素更高。 p 软件开发是一个高风险的过程p 软件过程的管理是软件成功的关键p 职业的发展方向、软件企业的生存的重要性p “软件危机” 的主要原因 用户不易准确描述对软件的需求，经常存在二义性，遗

4、漏甚至错误 p “软件危机” 的主要原因 大型软件往往需要成百上千人的合作，由于软件系统结构复杂，如何有效组织管理、充分发挥团队作用就成为软件开发成功的关键。 个人 VS 团队计算机软件和硬件费用比 60 70 80 90p “软件危机” 的主要原因 缺乏有效的软件开发方法和工具的支持，过分依靠程序设计在开发中的技巧和创造性，加剧了软件产品的个性化。开发过程没有统一、规范的方法论指导，文档资料不齐全。 p “软件危机” 的主要原因 缺乏软件开发经验及相关数据积累，无法准确估计经费和进度，导致经费严重超支，完成期限一拖再拖。 忽视测试阶段的工作，提交的产品质量差。 1999,10月，美国NASA

5、火箭气象卫星失踪，耗资1.25亿美元。软件的错误，英制和公制的转换问题导致。 1963-1966 美国IBM360机器的操作系统，5000人年的工作量，1000多人进行开发，100万行代码，新版本是在老版本中找出1000个以上的错误之后修正开发。当时的情况很不好，主要负责人Brooks 把他们当时比作陷在泥潭的困兽，越挣扎越深。-人月神话 1999年8月，在美国的一个大型的商业高速数据网络里，软件的缺陷影响了7000多个商业用户，时间长达8天。 1998年4月，美国的一个重要数据通讯网络出现24小时的故障，使大部分美国的信用卡业务受到影响。受影响的还有美国的一些大银行、零售商和政府的数据系统。

6、也是软件故障。 1997年8月，美国一家最主要的信用卡报告公司的新网站开启2天就关闭了，主要是查询自己的信用卡使用情况，但看到的是别人的账单，而不是自己的。 逻辑产品，不同于物理产品复杂性高 逻辑产品，逻辑复杂性，远高于硬件复杂性 软件的复杂性随规模呈指数级上升规模大 应用扩大，代码量仍在不断膨胀影响软件生产率和质量的因素比较复杂 人员的能力和水平 团队合作缺乏有效、系统原理、原则、方法和工具的指导和辅助美国印度爱尔兰软件产值的比较（软件产值：亿）印度中国199953.267.5200071.788.5200196.3102.32002110124“2009年，我国软件收入去年已经达到人民币7

7、573亿元，印度700到800亿美元，算下来相当于人民币6000亿左右，从这个角度说中国已经超越印度。” 陈冲，中国软件行业协会理事长软件出口的比较（软件产值：亿）印度中国1999392.52000624200177.87.2中国占世界软件外包行业的比重（软件产值：亿美元）世界软件外包规模中国20043348.3200541410.9200651914.5200764219.9200878127.82009943392006年软件外包份额印度34.2爱尔兰29.2菲律宾2.9中国2.4世界软件外包介绍1.1. 软件开发与软件项目管理1.2. CMM简介1.3. INFOSYS公司的项目管理实践

8、1. CMM简介2. CMM的成熟度级别3. 不同级别的KPA 4. CMM 的评估方法 CMM Capability Maturity Model for Software. 软件能力成熟度模型是一种描述有效软件过程的关键元素的框架，CMM描述一条从无序的不成熟的过程到成熟的、有纪律的过程的进化的改进途径。 CMM包括对软件开发和维护进行策划、工程化和管理的实践。遵循这些关键实践，就能改进组织在实现有关成本、进度、功能和产品质量等目标上的能力。 CMM的起源与发展 CMM的起源: 软件危机1986，SEI（CMU的软件的软件工程研究所）正式着手这工程研究所）正式着手这项工作项工作1987年年

9、9月，月， 发布发布“能力成能力成熟度框架熟度框架”和和“成熟度问卷成熟度问卷”1991，CMM1.01993，CMM1.1CMM-Ip 1999年7月6日，由IBM和清华同方合资成立的北京鼎新信息系统开发有限公司，在国内首次通过CMM2级。p 2000年左右，全球60多家CMM5级的企业，印度占了40个。国内当时通过CMM5级的企业，有摩托罗拉中国研究院，华为印度研究院，2007年东大阿尔派（东软前身）。p 一般，外包企业比较适用于通过CMM评估，而以创造性为主的软件公司，例如微软、IBM、Google等，均没有进行CMM评估。p 大连海辉、华信都通过CMM5，主要做软件外包。我国的CMM发

10、展情况： 软件过程 软件过程能力 软件过程性能 软件过程成熟度 软件过程 人们用于开发和维护软件及其相关过程的一系列活动，包括软件工程活动和软件管理活动。 软件过程能力 描述（开发组织或项目组）遵循其软件过程能够实现预期结果的程度，它既可对整个软件开发组织而言，也可对一个软件项目而言。 软件过程性能 表示（开发组织或项目组）遵循其软件过程所得到的实际结果，软件过程性能描述的是已得到的实际结果，而软件过程能力则描述的是最可能的预期结果，它既可对整个软件开发组织而言，也可对一个特定项目而言。 1. 成熟度的五个级别2. 成熟度等级的五个级别的主要特征3. 软件过程的可视性 4. 过程能力和性能预测

11、 CMM的成熟度级别 1级 初始级 (Initial) 2级 可重复级 (Repeatable) 3级 已定义级 (Defined) 4级 已管理级 (Managed) 5级 优化级 (Optimizing)成熟度等级1-5： CMM的成熟度级别 初始级特征：软件过程的特点是无秩序的，偶尔甚至是混乱的，几乎没有什么过程是经过定义的，成功依赖于个人努力。 可重复级特征：已建立基本的项目管理过程去跟踪成本进度和功能，必要的过程纪律已经就位，使具有类似应用的项目能重复以前的成功。 成熟度等级的五个级别的主要特征 CMM的成熟度级别 已定义级特征：管理活动和工程活动两方面的软件过程均已文档化、标准化，

12、并集成到组织的标准软件过程中，全部项目均采用供开发和维护软件用的组织标准软件过程的一个经批准的普及剪裁版本。 已管理级特征：已采集详细的有关软件过程和产品质量的度量，无论软件过程还是产品均得到定量了解和控制。 优化级特征：利用来自过程和来自新思想、新技术的先导性实验的定量反馈信息，使持续过程的改进成为可能。 成熟度等级的五个级别的主要特征 CMM的成熟度级别软件过程的可视性： 等级1 一个黑盒 等级2 项目里程碑处具有管理可视性 等级3 盒子的内部结构可视 等级4 软件过程被配备上度量，并得到定量地控制 等级5 对过程不断改进 CMM的成熟度级别过程能力和性能预测 随着成熟度增长，实际结果相对

13、预定目标结果的偏差范围减小 随着成熟度增加，预定目标结果得到改善 CMM的成熟度级别什么是关键过程区域（Key Process Area，KPA）？每个关键过程区域识别出一串相关活动，当这些活动全部完成时，能达到一组对增强过程能力至关重要的目标 。KPA的特性：p 每个KPA识别出一串相关活动p 每KPA定义在单个成熟度等级上p KPA鉴别出为达到某一成熟度等级所必须解决的问题 不同级别的KPAKPA的结构：p 目标p 共同特点 执行约定 执行能力 执行活动 测量和分析 验证实施 不同级别的KPAKPA的目标（Goal）：p 目标概括一个KAP中的所有关键实践，并能用于确定一个组织或项目是否已

14、有效地实施此KPA。p 目标表示每个关键过程域地范围、边界和意图。 不同级别的KPAKPA的共同特点：p 执行约定(Commitment to Perform) ：企业为了建立和实施相应KPA所必须采取的行动；p 执行能力(Ability to Perform) ：描述了为了某软件过程得以始终如一地执行必须在项目或企业中存在的先决条件，是企业实施KPA的前提条件；p 执行活动(Activities Performed) ：描述了执行KPA所需求的必要行动、任务和步骤；其是唯一一项与项目执行相关的属性。p 度量和分析(Measurement and Analysis) ：关注于这个关键过程域的活

15、动需要做的度量和度量分析要求。p 验证实施(Verifying Implementation) ：是验证执行活动是否与建立的过程一致，核实以确保所实施的过程是按照原定的计划以及达到其目标，着眼于保证过程的实现要通过独立的个人和高级管理人员验证。 不同级别的KPA执行约定(Commitment to Perform) ：执行约定是企业为了建立和实施相应KPA所必须采取的行动，这些行动主要牵涉到企业范围的政策和高层管理的责任。 不同级别的KPA执行能力(Ability to Perform) 执行能力描述为了使某软件过程得以始终如一地执行的必须在项目或企业中存在的先决条件，是企业实施KPA的前提条

16、件。企业必须采取措施，在满足了这些条件后，才有可能执行KPA的实践活动。 执行能力关注于项目计划的实践；资源的配置；责任的布置与授权；以及各种有关的培训等，这些都是为了执行这个关键过程域的活动而对特定人以及作为整体的机构的能力开发起非常重要作用的事务。 不同级别的KPA执行活动(Activities Performed) 执行活动描述了执行KPA所需求的必要行动、任务和步骤。 在五个公共属性中，执行活动是唯一与项目执行相关的属性，其余四个属性则涉及企业CMM能力基础设施的建立。 执行活动一般包括计划、执行的任务、任务执行的跟踪等。 不同级别的KPA验证实施(Verifying Implemen

17、tation) 验证实施是验证执行活动是否与建立的过程一致，核实以确保所实施的过程是按照原定的计划以及达到其目标，着眼于保证过程的实现要通过独立的个人和高级管理人员验证。涉及到管理的评审和审计以及质量保证活动，包括：过程执行的确保，产品要求的确保，高层管理人员进行的审核和项目经理进行的审核。 不同级别的KPA测量和分析（Measurement and Analysis）：测量和分析关注于这个关键过程域的活动需要作的度量和度量分析要求。典型的测量和分析的要求是确定执行活动的状态和执行活动的有效性。 不同级别的KPA 不同级别的KPAp CMM共有18个KPA，其中： 2级 6个 3级 7个 4级

18、 2个 5级 3个等级2的KPA：p 需求管理 RM(Requirements Management)p 软件项目策划SPP(Software Project Planning)p 软件项目跟踪和监督SPTO(Software Project Tracking and Oversight)p 子合同管理SSM (Software Subcontract Management)p 质量保证SQA(Software Quality Assurance)p 软件配置管理SCM(Software Configuration Management) 不同级别的KPA等级3的KPA：p组织过程焦点OPF

19、(organization process focus)p组织过程定义OPD(organization process definition)p培训大纲TP(training program)p集成软件管理ISM (integrated software management )p软件产品工程SPE(software product engineering)p组间协调IC(intergroup coordination)p同行评审PR( peer reviews) 不同级别的KPA等级4的KPA：p定量过程管理QPM (quantitative process management)p软件质量

20、管理SQM (software quality management)等级5的KPA：p缺陷预防DP (defect prevention)p技术改革管理TCM(technology change management )p过程更改管理 PCM(process change management ) 不同级别的KPA1. 过程评估与过程评价2. 过程评估的方法 CMM的评估方法p 软件过程评估：用于确定一个组织的当前软件过程的状态，确定组织所面临的具有高优先级的与软件过程有关的问题，和获得组织对软件过程改进的支持。p 软件过程评价：用于识别合格的能完成软件工作的承包商或者监控现有软件工作中所应

21、用的软件过程的状态。 CMM的评估方法过程评估的方法：成熟度问卷文档面谈 CMM的评估方法1.1. 软件开发与软件项目管理1.2. CMM简介1.3. INFOSYS公司的项目管理实践1. INFOSYS公司的背景知识 2. SEPG对项目的支持3. 高层经理参与项目4. 项目经理培训5. 项目管理过程(项目规划, 项目执行, 项目收尾)INFOSYS公司的项目管理实践 Infosys技术有限公司是一家总部在印度班加罗尔的一家全球技术服务公司。这家公司在2011年财富印度500强中列第27名。Infosys在29个国家设有办公室并在印度、美国、中国、澳大利亚、英国、加拿大、日本等地设有研发中心

22、。公司在超过30个国家提供商业咨询、技术、工程及外包服务。 Infosys简介 Software Engineering Process Group，软件工程过程小组 工作开销 SEPG VS. QA SEPG1. CEO 2. SEPG 3. 管理委员会 高层管理者介入p项目计划阶段p项目执行阶段p项目收尾阶段 项目管理过程1. 项目管理的概念2. 项目管理的主要内容3. 项目管理的阶段划分下面哪些活动是项目？q上课 q野餐活动q某次企业的校园宣讲会q社区保安q开发某套管理软件q每天的卫生保洁 q玉兔登月计划项目的定义 所谓项目，就是为创建某一独特产品或服务，在一定的环境和约束条件下进行的临

23、时性努力 即它是利用有限的资源，在有限的时间内为特定客户完成特定目标的一次性工作。项目的特征：1.一个明确的范围和目标；2.一个预期的完成时间；3.有可以利用的资源；4.一种已定义的性能评估方法；5.不是例行的任务下面哪些活动是项目？q上课 q野餐活动q某次企业的校园宣讲会q社区保安q开发某套管理软件q每天的卫生保洁 q玉兔登月计划项目日常活动什么是项目管理？p Badiru(1991)将项目管理定义为：一种为高效恰当地完成某个既定的目标而对资源进行管理、分配和调度的过程。 p 我们也可以把项目管理定义为：一种为实现既定目标而对技术、人力及金融资源所进行的系统集成。 质量管理时间管理 成本管理

24、 风险管理 人力资源管理 合同/采购管理范围管理 通讯管理项目综合管理项目管理的三要素：项目质量成本进度项目管理主要有三大阶段p项目规划p项目执行p项目收尾 项目规划： 主要是项目经理审阅合同条款，并制定一个满足他们的计划，实际上包括：定义生命周期、估计工作量和进度、制定任务进度计划等。 项目执行： 包括执行项目计划、跟踪项目的状态，并在项目的绩效偏离项目计划设定的绩效时采取措施进行纠正。 项目收尾： 主要是在客户接收工作产品之后对项目进行系统的总结。数据分析是这一阶段的主要任务。 1. 需求开发（分析和产生需求的过程，发生在软件生命周期的开始）2. 需求管理 （包括对需求的评审、变更、跟踪，

25、贯穿于整个软件生命周期） 1. 需求2. 需求分析和需求规格3. 需求变更4. 需求跟踪 什么是需求？IEEE软件工程标准词汇表（1997年）定义需求为：用户解决问题或达到目标所需的条件或权能（Capability）。系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。一种反映上面 或 所描述的条件或权能的文档说明。 需求分析的过程1) 准备阶段：阅读技术以及商务概念上的背景资料并进行培训、熟悉客户使用的方法和工具、确定信息的采集方法、准备好提问问题、确定用户组与评审专家、计划原型、确定需求规格标准、制定会谈计划；2) 采集、澄清需求：建立系统目标和范围、采集功能需求、

26、采集外部接口信息、采集环境需求、采集性能需求、采集标准需求、采集用户特殊需求、准备和评估原型；3) 分析需求：设计过程模型、设计逻辑数据模型、建立数据字典；4) 准备SRS（Software Requirements Specification, 需求规格说明书）5) 评审SRS6) 客户认可并签署SRS1. 需求规格说明书（需求规格说明书的要求）SRS的要求：正确性、无二义性、完整性、一致性、可测试性、可跟踪性。 需求是会发生变化的，而且需求的变更可以在项目生命周期的任何时间发生。越是发生在后期，对项目的影响越大。如何管理好需求变更的申请是非常重要的。 需求变更管理过程：变更管理过程规定如何

27、发出变更申请、何时需要正式批准等。在出现需求变更申请时，必须执行需求变更管理过程。 一般的变更管理过程 记录变更 分析变更对工作产品的影响 估计变更申请所需的工作量 重新估计交付时间表 执行累计的成本影响风险 如果影响超出一定的限度，则与高级主管一起评审影响 客户不再提出变更申请 修改工作产品 跟踪矩阵 跟踪矩阵的维护和使用1. 软件开发过程及描述2. 过程裁剪p 过程描述/定义 过程描述是项目可以用来遵照执行某些任务的一系列步骤，以及执行这些步骤的指南。开发过程是提炼用户需求，设计、构建和测试满足这些需求的软件并最终将其交付给客户所需的过程：需求分析概要设计详细设计编码单元测试集成测试系统测

28、试验收测试每个开发子过程都包括：1.输入准则2.输入3.输出准则4.输出5.度量给出从计算机的逻辑角度开发针对用户需求的解决方案。p 输入准则：需求规格文档经过评审并授权p 输入：需求规格文档p 输出准则：概要设计文档经过评审和授权p输出：概要设计文档、项目标准、概要设计评审记录p 度量：工作量、缺陷p 主要步骤：p 进一步对概要设计中的整体应用分解，分解成模块和程序，对程序进行逻辑设计。p 输入准则：概要设计文档经过评审和授权p 输入：概要设计文档p 输出准则：详细设计文档和单元测试计划已经经过评审和授权p 输出：详细设计文档和单元测试计划p 度量：工作量、缺陷p 主要步骤：p 根据详细设计

29、用编程语言编写所需要的程序p 输入准则：详细设计文档经过评审并授权p 输入：详细设计文档、项目标准、单元测试计划、程序框架p 输出准则：成功执行所有单元测试计划中的测试用例p 输出：源代码、可执行代码、测试数据p 度量：工作量、缺陷p 主要步骤：p 已通过单元测试的模块构建成一个完整软件结构的系统方法p 输入准则：概要设计文档经过评审和授权p 输入：概要设计文档和程序p 输出准则：成功执行所有集成测试计划中的测试用例p 输出：源代码、可执行代码、测试数据p 度量：工作量、缺陷p 主要步骤：p 依据需求规格验证软件产品有效性的活动；目的是为了发现那些只有通过测试整个系统才能暴露的缺陷p 输入准则

30、：需求规格和概要设计文档经过评审和授权p 输入：需求规格和概要设计文档p 输出准则：成功执行所有集成测试计划中的测试用例p 输出：源代码、可执行代码、测试数据p 度量：工作量、缺陷p 主要步骤：p 把软件产品集成到它的操作环境中，并在这个环境中经受测试，确保它按需求执行。p 输入准则：成功的完成系统测试p 输入：测试后的软件和验收测试文档p 输出准则：客户签署验收单p 输出：安装后的软件p 度量：工作量和缺陷p 主要步骤：p主要是操作手册，用户手册及客户需要的其他文档。p主要活动：p输入准则：p输入：p输出准则：p输出：p度量：p主要步骤：p 过程裁剪是调整组织标准过程的过程，以此来获得用于项

31、目的特定业务或技术需要的过程。p 主要有： 概要裁剪指南 详细裁剪指南p 提出基于某些项目特效，在项目中应该如何执行一些通常的活动。p 概要级剪裁：根据项目特征，应用总体指南标准对标准过程进行剪裁，用到如下特征。（1）团队和项目经理的经验和熟练程度。（2）团队人数最多时的人数。（3）需求透明度（4）项目持续时间（5）应用的关键程度列出过程中各种生命周期阶段的所有活动，还包括对每个活动相应的裁剪活动,指定每个步骤是必要的还是可裁剪，并给出选择的指南。1.软件度量2.过程数据库（Process Database, PDB）3.过程能力基线(Process Capability Baseline ,

32、 PCB)4.过程财富( Process Asset)p软件度量可以来量化地描述软件过程和软件产品的不同方面的特点。p过程度量的要素p产品度量的要素p软件度量的作用（1）项目计划（2）控制项目过程（3）分析和改进组织过程p定义：PDB 是存放从项目可获得的过程性能数据的数据库，这些数据可以用于项目计划、估计、生产率和质量分析等。p PDB的构成：由已经完成的项目的数据构成 项目特征 项目进度 项目工作量 项目规模 故障 风险 pPDB的建立及访问 PDB由SEPG建立 项目经理可以阅读p 过程能力基线（PCB）的主要内容 已交付软件的质量 生产率 进度计划 工作量分布 故障引入率 过程中故障排

33、除率 质量成本 故障分布p过程财富的组成 组织标准软件过程 组织的软件过程数据库/过程能力基线 软件生命周期描述 标准软件过程的剪裁指南和准则 软件有关文档 1. 工作量估计模型概述2. 估计方法- 自底向上的估计方法- 自顶向下的估计方法3. 进度安排p工作量估计模型 自顶向下的估计方法 规模估计整体工作量各阶段工作量 COCOMO 模型 自底向上的估计方法 各阶段的工作量整体的工作量 此方法可以直接估计工作量 工作量估计模型概述p 自底向上估计 任务分解每个程序单元的复杂度定义估计每个单元的编码工作量计算整个程序的编码工作量导出整体项目的工作量各阶段的工作量估计方法 程序单元分类的准则各种

34、平台，各种语言，各种环境分类的标准不一样。 方法的有效性估计工作量与实际工作量的比较估计方法 规模估计：整体工作量-各阶段工作量 软件规模估计的主要估算方法： 代码行（LOC/KLOC）法 功能点法 估计方法p COCOMO模型- 基本COCOMO模型 - 中级COCOMO模型 估计方法 整体进度计划 详细进度计划（主要里程碑）1. 质量管理2.量化质量管理计划p 软件质量和缺陷 软件质量的定义：我们用已交付软件的故障密度作为软件质量的定义即，已交付软件中每个单位规模的故障数。 质量管理的任务是规划合理的质量控制任务，然后正确地执行和控制它们，以实现项目的质量目标。 故障排除任务包括需求评审、

35、设计评审、代码评审、单元测试、集成测试、系统测试和验收测试。 p 质量管理的量化方法 两个关键工作： 设定量化质量目标 量化管理软件开发过程 设定质量目标 质量过程计划 其他阶段的缺陷估计1. 背景2. 风险评估3. 风险控制 风险管理（Risk Management）试图使由于意外事件而导致项目失败的概率降到最小。 主要包括： 风险评估 风险控制 风险和风险管理概念 什么是风险：风险是那些可能发生的事件或者条件，如果它确实发生了，则它的发生会对项目产生有害的或者负面的影响。另一方面，风险是一种概率事件，可能发生也可能不发生。 风险管理的目标：旨在识别出风险，然后采取措施使它们对项目的影响最小

36、 特点：风险管理是要付出额外的成本；风险管理的价值不容易度量 风险识别 识别风险常用的方法 风险等级划分 根据风险暴露度划分（RE） RE(r)=Prob (r) *Loss (r) 风险管理规划 任务是确定使风险后果最小所需的措施，也称风险缓和措施。 风险监督和跟踪 项目管理计划(Project Management Plan, PMP)是项目经理承担的所有规划任务的核心。各规划任务的结果都出现在PMP中，是指导所有项目执行的基准文档。 项目管理计划分四部分： 项目概述 项目计划 项目跟踪 团队 项目管理计划的主要使用者： 业务主管 项目经理 项目的开发人员 项目的起止日期、项目经理、项目目

37、标、与客户的联系、对客户的主要承诺以及所做的假设前提。 项目过程 标准过程的描述、剪裁指南、需求变更管理 工作量估计 开发环境 工具 培训计划 质量计划 里程碑 风险管理计划 任务跟踪 事宜跟踪 客户反馈 状态报告 升级规程 项目机构 项目组 角色和职责 软件配置管理（Software Configuration Management，SCM ）是项目管理中专门用于关注系统地控制项目进行中发生的变更的那些部分，由用来识别组织软件产品并控制其修改的一系列活动构成。 软件配置管理（software configuration management, SCM）是项目管理的一项内容，主要涉及对变更进行

38、系统地控制，建立和维护在项目的整个软件生存周期中软件项目产品的完整性。 主要包括：标识在给定时间点上软件的配置，系统地控制对配置项的更改、并维护在整个软件生存周期中配置的完整性和可跟踪性。 p配置管理的功能与机制 配置管理的功能：（1、给出程序的状态；2、给出一个程序的最新版本；3、处理并发更新申请；4、取消一个程序变更；5、防止未授权的变更或者删除；6、提供需求变更申请和程序变更之间的可跟踪性；7、取消一个需求变更；8、显示相关的变更；9、收集当前系统的所有源代码、文档和其他信息。） 配置管理的机制包括：（1、文件命名和组织的约定；2、版本控制；3、变更申请的可跟踪性；4、访问控制；5、协调

39、过程；6、修改登记程序。） p 配置管理过程主要有： 配置规划 配置执行 状态监控 1. 标识出典型的配置项2. SCM人员或者项目经理进行SCM规划该阶段的任务主要有： 配置控制任务主要有两个： 涉及程序的状态转移管理 涉及必须被实现的变更申请的管理 变更申请的步骤：1、接受变更申请（影响分析之后）；2、建立一种跟踪机制；3、检出需要进行变更的配置项；4、执行变更；5、注册配置项；6、在项目的整个生命期内维护该项目。 正确表示每一个配置项的状态 进行配置项的定期状态检查，产生关于差异的报告，并解决所有差异 检查变更请求的状态 执行配置审计 VSS使用教程 评审是最有效的也是最常用的标识故障的

40、方法，可以对文档及代码进行评审。评审还可以使管理人员掌握项目的进展。1、评审可以应用于软件开发各个阶段、产生的各种类型产品范围广；2、评审比软件测试更有效率，因为他看到的是问题本身而不是征兆；3、通过评审不仅可能发现错误，还可以提出对软件产品的改进意见，防止再发生；4、评审可以在产品开发阶段进行，作者对产品细节很清楚，可以及时修改；5、不只发现错误，还有利于评审员、软件项目相关组熟悉有关产品。 小组评审的几个阶段： 评审规划、 准备和概述、 小组会议、 返工及后续修改 1. 评审规划： 标识要评审的产品； 选择评审成员及安排评审时间 作者准备好相应的材料。 2. 准备和概述： 此阶段的目的：是

41、将要评审的软件包交给评审人员，并在需要时，对工作产品进行说明。 第一次会议； 在正式会议之前，各评审员独立地评审工作产品，作评审日志。 需要准备的材料：评审通知、评审标准、被评审的工作产品、正式的评审记录单、评审检查表、其他资料（如相关文档、标准等） 3. 评审会议 评审会议的目的：最终拿出故障列表 会前检查准备工作； 会议期间提出问题； 会议结束时，给出问题和故障列表。 结论分为：可以通过、不能通过和有条件通过 4. 返工和后续措施 作者执行返工，以改正评审会议上提出的所有故障。 作者与评审主席一起审查改正情况。 在评审的各个阶段，数据都要被记录，每次评审的总结数据都被保存到一个评审数据库中。 1 自备日志 2 小组评审会议日志 3. 小组评审总结报告 监督和控制主要针对评审的效率。 没有效率的评审是对时间和资源的巨大浪费。 项目监督和控制的目的是：建立对项目的实际进展的适当的可视性，使管理者能在软件项目性能明显偏离软件计划时采取有效措施。 活动包括：对照已文档化的估计和计划，评审和跟踪软件完成情况和结果，基于实际的完成情况和结果调整原有