软件研发项目管理

1、软件研发项目管理2013-2-201研发项目管理基础1计划管理2需求管理3设计管理4开发管理5测试管理6目录目录配置管理7最佳实践82 基础管理 01 13总纲与规范六为法 需求必为准 团队必为本 计划必为纲 绩效必为证 质量必为出 变化必为形4总纲与规范七定法 兵马未动、合约先行（定需求） 可行的做可行事（定技术方案） 谋定而后动（定计划） 专业的人做专业的事（定人员） 沟通无止境、共识促发展（定共识） 死亡之地不可不察也（定风险） 应对随形、修道保法（定变更）5总纲与规范三出路 以正合（用人之术，诸如选育用留） 以曲制（规律之术，诸如过程方法） 以奇胜（变化之术，诸如动静之理）6总纲与规范

2、兵法 一曰道 目的 二曰天 制度 三曰地 需求 四曰将 专业角色 五曰法 过程7基础管理基础管理-过程管理过程管理过程的简单描述8基础管理基础管理-过程管理过程管理软件研发的分类和组成p软件基本过程：软件基本过程：软件获取、供应、开发、运行和维护的过程，包括需求分析、软件设计、编码等过程。p软件支持过程：软件支持过程：对软件主要过程提供支持的过程，包括文档编制过程、配置管理过程、质量保证过程、验证和确认过程（测试过程）、评审过程等。p软件组织过程：软件组织过程：对软件主要过程和支持过程的组织保证过程，包括管理过程、基础设施过程、改进过程和培训过程。9基础管理基础管理-过程管理过程管理ISO/I

3、EC15504软件生存周期过程10基础管理基础管理-过程规范过程规范软件研发规范的建立p软件能力成熟度模型（CMM/CMMI ）pIBM-Rtaional 统一过程（RUP）p极限编程 （eXtreme Programming，XP） p微软软件框架（MSF）11基础管理基础管理-过程规范过程规范n瀑布模型n螺旋模型、增量模型、迭代模型nV模型 n并发过程模型n极限编程（XP）nIBM-Rational统一过程（RUP） 软件研发模型12基础管理基础管理-过程规范过程规范不是好的东西都能用，适用的才是最好的! 需要我们根据自己人员的水平、公司情况、业务状况综合确定适合自己的研发过程13基础管理

4、基础管理13 计划管理 02 214计划管理计划管理软件研发的项目管理有效的项目管理是在用来实现项目具体目标的规定时间内，对组织机构资源进行计划、引导和控制工作。 项目管理知识指南15计划管理计划管理WBS： 项目计划形成之前，最好先画WBS表（Work Breakdown Structure），主要原理是：将任务逐级分解直至个人，在矩阵中体现为：先确定横向有多少结点，再将每一结点任务逐渐细化直到个人，工作分解图（WBS）实际上就是将一个复杂的开发系统分层逐步细化为一个个工作任务单元，这样可以使我们将复杂、庞大的、不知如何下手的大系统划分成了一个个独立的我们能预测、计划和控制的单元，从而也就达

5、到了对整个系统进行控制的目的。16WBS-工作分解结构1 项目范围规划 1.1 确定项目范围 1.2 获得项目所需资金 1.3 定义预备资源 1.4 获得核心资源 1.5 项目范围规划完成2 分析/软件需求 2.1 行为需求分析 2.2 起草初步的软件规范 2.3 制定初步预算 2.4 工作组共同审阅软件规范/预算 2.5 根据反馈修改软件规范 2.6 确定交付期限 2.7 获得开展后续工作的批准(概念、期限和预算) 2.8 获得所需资源 2.9 分析工作完成3 设计 3.1 审阅初步的软件规范 3.2 制定功能规范 3.3 根据功能规范开发原型 3.4 审阅功能规范 3.5 根据反馈修改功能

6、规范 3.6 获得开展后续工作的批准 3.7 设计工作完成4 开发 4.1 审阅功能规范 4.2 确定模块化/分层设计参数 4.3 分派任务给开发人员 4.4 编写代码 4.5 开发人员测试(初步调试) 4.6 开发工作完毕 计划管理计划管理17计划管理计划管理创建WBS的基本法则l每个工作工作单元在WBS只能出现一次l概要任务是对其下所有任务的总结l每个WBS的条目都有单独的人员负责l与实际要做的工作情形保持一致l建立WBS时应让项目组员参予l每个WBS条目都应备案lWBS既要灵活又要不失控制18计划管理计划管理项目估算令人烦恼的项目估算： 这个项目需要多长时间？ 这个模块大概多久完成？ 需

7、要花费多少人力才能完成这个项目？ 项目的总成本大概为多少？ 19计划管理计划管理项目成本的组成1. 项目成本的组成（1）直接成本 人力成本 硬件设备 软件费用（2）间接成本 项目管理成本 一般管理成本20计划管理计划管理责任矩阵用距阵的形式列出对某项任务负责的人或资源。任务任务管理管理人员人员项目项目经理经理分析分析人员人员项目范围规划 1.1 确定项目范围A 1.2 获得项目所需资金A 1.3 定义预备资源A 1.4 获得核心资源A分析/软件需求 2.1 行为需求分析A 2.2 起草初步的软件规范A 2.3 制定初步预算A 2.4 工作组共同审阅软件规范/预算AP 2.5 根据反馈修改软件规

8、范A 2.6 确定交付期限A 2.7 获得开展后续工作的批准AP 2.8 获得所需资源A21计划管理计划管理项目软硬件资源管理1. 软件资源管理 操作系统 编译器 应用软件 测试工具 2. 硬件资源管理 服务器 PC 22计划管理计划管理10种常见的风险No.软件风险软件风险相应对策相应对策1人员不足录用优秀人才；人员应适应岗位需要；全面考虑团队建设；骨干人员工作要协调；实施培训；预先安排关键人员的使用计划2进度计划和预算不准确详细评估多种资源成本和进度；依成本进行设计；采用渐增式开发；软件复用；纯净需求3开发了错误的软件功能进行组织分析；实施任务分析；进行用户调查；开发原型；及早编制用户手册

9、4开发了不适用的用户接口开发原型；制作脚本；作业分析；弄清了用户特征(功能性、风格、工作负荷)5只追求表面效果，需求中含有一些不必要的功能（镀金）纯净需求；开发原型；成本效益分析；依成本进行设计6需求不断变更重大变更设限；信息隐蔽；渐进式开发7外供部件不足制定基准点；检验；参考基准检查；兼容性分析8外包任务问题参考基准检查；发包前审核；未发包合同；竞标设计或开发原型；建立团队9实时性能达不到要求模拟；制定基准；建模；开发原型；安装测量装置；调准10误解计算机科学能力技术分析；成本效益分析；开发原型；参考基准检查23计划管理计划管理项目跟踪和控制1. 了解成员的工作情况2. 调整工作安排，合理利

10、用资源3. 促进计划内容的完善4. 促进项目经理对人员的认识5. 促进对项目工作量的估计6. 统计并了解项目总体进度7. 有利于人员考核24计划管理计划管理现代软件研发项目管理路线图概览25计划管理计划管理项目预算与成本1、项目成本=直接成本*2.5 直接成本为prj中的成本2、项目工期=基本工期+（悲观时间-乐观时间）/63、项目工期较长，可以分解为多个项目，每个项目不超过6个月，6个月内按两周做计划。4、任务分解一般两周:过粗不利分配工作,过细不利于人员的主动性.5、要识别任务关键路径,根据人员情况并行或串行。26计划管理计划管理WBS CHart27计划管理计划管理Chart EXPER

11、T28计划管理计划管理关键路径实例- Microsoft project 29需求管理需求管理29 需求管理 03330需求管理需求管理软件研发的需求管理开发软件系统最为困难的部分就是准确说明开发什么。弗雷德里克布鲁克斯31需求管理需求管理软件需求工程 所有与需求直接相关的活动统称为需求工程，需求工程分为了两个部分：需求开发和需求开发和需求管理需求管理。其中，需求开发又分为了需求获取、需求分析、需求定义和需求验证4个部分，而需求管理则包含了变更控制、版本控制、需求跟踪和需求状态跟踪 软件需求包括三个不同的层次：业务需求、用户需求和功业务需求、用户需求和功能需求能需求（也包括非功能需求）。32需

12、求管理需求管理软件需求工程l 业务需求业务需求（business requirement）反映了组织机构或客户对系统、产品的概括的目标要求，它在项目视图与范围文档中予以说明。主要的目的是对企业目前的业务流程进行评估，得出一个业务前景。业务需求的确定对后面的用户需求和功能需求起到了限制作用。l 用户需求用户需求(user requirement) 文档描述了用户使用系统而完成的任务的集合，用户需求在用户案例（user case）文档或方案脚本中予以说明。收集和分析用户需求是不容易的，因为很多需求是隐形的，很难获取，更难保证需求完整，而需求又是易变的，这就要求用户和开发人员进行充分地交流。l软件需

13、求软件需求(fsoftware requirement)定义了开发人员必须实现的软件功能，它源于用户需求。功能需求是软件需求说明书中最重要的部分之一，它在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。非功能需求描述了系统展现给用户的行为和执行的操作等，包括要遵从的业务规则、人机接口、安全性和可靠性等要求。33需求管理需求管理需求开发需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。 获取数据获取数据分析、处理分析、处理目标系统模型目标系统模型需求获取需求获取系统分析员系统分析员从数据流和数据结构出发，从数

14、据流和数据结构出发，找出系统各元素之间的联找出系统各元素之间的联系、接口特征及设计限制、系、接口特征及设计限制、能否满足功能需求能否满足功能需求34需求管理需求管理需求获取的方法需求研讨会头脑风暴用例模型访谈角色扮演原型法35需求管理需求管理基于用例的需求获取执行者执行者的识别的识别l谁使用系统的主要功能？l谁将提供、使用和删除信息？l谁负责维护、管理并保持系统正常运行？l谁会对某一特定需求感兴趣？l系统的外部资源是什么？l系统需要和哪些外部系统交互？用例的用例的识别识别l某个执行者要求系统为其提供什么功能？该执行者需要做哪些工作？l执行者需要阅读、创建、销毁、更新或存储系统中哪些（类）信息？

15、l系统中的事件一定要告之执行者吗？执行者需要告诉系统一些什么吗？那些系统内部的事件从功能的角度代表什么？l由于新功能的识别，执行者的日常工作被简化或效率提高了吗？l系统需要什么样的输入输出？输入在哪里？输出去往哪里？l该系统的当前情况存在哪些问题？36需求管理需求管理需求确认为什么需要需求评审？在哪个阶段发现在哪个阶段发现成本成本率率需求需求1设计设计3-6编码编码10功能测试功能测试15-40验收测试验收测试30-70发布之后发布之后40-1000修订一个缺陷的相关成本修订一个缺陷的相关成本37基础管理基础管理需求跟踪需求的标识需求类型可以是：F=功能需求，D=数据需求，B=行为需求，I=接

16、口需求；O=输出需求。 例：需求标识为例：需求标识为F03的需求表示编号的需求表示编号为为3的功能需求。的功能需求。38基础管理基础管理39设计管理设计管理39 设计管理 04 440设计管理设计管理架构开发方法41设计管理设计管理架构开发方法42设计管理设计管理架构开发方法43设计管理设计管理架构是软件的基石架构是软件的基础，一个良好的架构可架构是软件的基础，一个良好的架构可以让软件有更长久的生命力，能发挥出以让软件有更长久的生命力，能发挥出更出色的性能；更出色的性能；架构师要求对业务有深入的了解，这样架构师要求对业务有深入的了解，这样才能让架构更符合软件的需要，更能发才能让架构更符合软件的

17、需要，更能发挥软件的特点。挥软件的特点。44设计管理设计管理45设计管理设计管理46设计管理设计管理47设计管理设计管理48开发管理开发管理 开发管理 05549开发管理开发管理1. 开发开发开发的目的包括：对照开发子系统的分层结构定义代码结构;以构件（源文件、二进制文件、可执行文件以及其他文件等）的方式开发类和对象;对已开发的构件按单元来测试;将各开发员（或团队）完成的结果集成到可执行系统中。50开发管理开发管理2.过程策略过程策略里程碑：最初操作性能最初操作性能里程碑确定产品是否已经可以部署到 Beta 测试环境。在最初操作性能里程碑，产品随时可以移交给产品化团队。此时，已开发了所有功能，

18、并完成了所有 Alpha 测试（如果有测试）。除了软件之外，用户手册也已经完成，而且有对当前发布版的说明。评估标准该产品发布版是否足够稳定和成熟，可部署在用户群中？是否已准备好将产品发布到用户群？实际的资源耗费与计划的相比是否仍可以接受？如果项目无法达到该里程碑，产品化可能要推迟一个发布版。51开发管理开发管理最佳开发实践 新概念与最佳实践 可持续开发节奏 团队激励 障碍列表 持续集成 产品燃尽图 Sprint燃尽图52开发管理开发管理可持续开发节奏的相关概念 可持续的开发节奏是一个开发团队可长期（可以认为是永久）保持的开发节奏 为了保持可持续的开发节奏，适当的休假可以让团队及时恢复精力。 可

19、持续的开发节奏并非禁止加班，但必须是偶然事件而非经常性事件53开发管理开发管理讨论 当项目进度对于完成当前的迭代目标面临压力时，作为Scrum Master，你会采取以下哪种方式？54开发管理开发管理Scrum Master要关注团队的健康 高强度的开发节奏如果超过了团队可承受的范围，必然影响团队的健康（包括心理和生理健康）。 Scrum Master应该关注团队的健康状况。选择可持续的开发节奏，应该以团队能够感觉舒适地完成迭代目标为前提。55开发管理开发管理不可持续开发节奏的影响56开发管理开发管理不可持续开发节奏的影响 Defect大量增加：持续加班状况下代码质量很难保证，必然导致defe

20、ct数量增加。 工作效率降低：研究表明，当人疲劳时工作效率将急剧下降。 团队士气低下：长期的高强度工作必然使团队身心疲惫，士气低落。 开始相互推诿责任：长期高负荷工作下，导致出现问题后开始相互埋怨。 放弃探索最佳实践方法：磨刀不误砍柴工，最佳实践方法可以事半功倍。然而长期高强度工作会逐渐放弃花时间去“磨刀”。57开发管理开发管理障碍列表在敏捷项目管理中的意义 及时将团队的注意力引导向最重要的问题。 集思广益。由团队成员一起讨论解决，而不是由传统意义上的项目经理独自来协调与分配。提高团队的自主性。 与风险管理结合，对即将或已经发生的风险采取积极的应对态度。58开发管理开发管理 团队激励59开发管

21、理开发管理团队阶段回顾60开发管理开发管理什么是激励激励= 活力+ 指引 + 坚持61开发管理开发管理什么是团队讨论：一群个体与一个团队的区别 一群个体 避免交流与冲突 自我中心 低投入 被动工作 一个团队 彼此信任 有共同目标 开诚布公 互相帮助 有原则 有乐趣 团结 积极交流 倾向于解决问题62开发管理开发管理团队绩效曲线63开发管理开发管理开发开发 详细设计开发单元测试为专业开发开发时间开发时间 任务=2周=2月；这是一种健康节奏,不能经常加班。最佳开发实践最佳开发实践 可持续开发节奏、团队激励、障碍列表、持续集成、产品燃尽图、Sprint燃尽图任务分配时间任务分配时间 分配任务时按规划

22、时间/1.2计算。如规划10天，10/1.2=8天，则安排8天完成，以保留时间贮备 在分配任务时在分配任务时1、以需求为主线（一个部分的需求、设计、开发、测试由一个人完成）2、以健康节奏（按120/100原则分配，具体因人而异3、任务分配在两周之内4、版本控制在两个月内5、行动之前落实承诺 开发主管在分配任务时开发主管在分配任务时1、选：胜任力2、定：定好目标，获得承诺3、育：培训4、用：定好绩效（工作节奏）5、留：奖惩（按绩效）总结64测试管理测试管理 测试管理 06665测试管理测试管理 测试测试测试的目的在于：核实对象之间的交互。核实软件的所有构件是否正确集成。核实所有需求是否已经正确实

23、施。确定缺陷并确保在部署软件之前将缺陷解决。66测试管理测试管理1 软件工程与测试模型l 不同的开发模式适配不同的测试模型和测试过程。开发流水线产品平台技术平台规划需求设计实现测试部署测试需求测试设计测试执行测试执行67测试管理测试管理1.1 测试模型1：瀑布模型l 瀑布模型的核心思想是按工序将问题化简，将功能的实现与设计分开，采用结构化的分析与设计方法将逻辑实现与物理实现分开。l 软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试、运行维护。l 规定活动自上而下、相互衔接的固定次序，逐级下落。68测试管理测试管理1.2测试模型2：V模型l V模型是最广为人知的测试模型l 由P

24、aul Rook在2世纪年代后期提出的，旨在改进软件开发的效率和效果。l 从左到右，描述了基本的开发过程和测试行为l 非常明确地标明了测试过程中存在的不同级别，描述了这些测试阶段和开发过程期间各阶段的对应关系69测试管理测试管理1.3 测试模型3：W模型l 测试伴随整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，测试与开发是同步进行的。l W模型有利于尽早地全面的发现问题。l 测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法很好的支持迭代开发。70测试管理测试管理1.4 测试模型4：X模型l 很好地处理测试与开发的交接过程

25、（交接的过程是一个时间段，而不是一个点）l 左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终合成为可执行的程序，然后再对这些可执行程序进行测试。l 己通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。l X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，给有经验的测试人员在测试计划之外发现更多的软件缺陷。71测试管理测试管理2 测试组织产品组/产品线测试组开发组项目1项目2项目3优势：1、与业务结合紧密（用例）；2、与代码结合紧密（白盒）；缺点：1、测试资源未统一

26、动态调配，使用有浪费；2、测试技能的统一提升和培训少。72测试管理测试管理2 测试组织规模73测试管理测试管理2 走向成熟：组织成熟怎么算组织成熟？怎么算组织成熟？74测试管理测试管理2 走向成熟：技术成熟：工具平台75测试管理测试管理2 走向成熟：技术成熟：测试流水线业务知识76测试管理测试管理2 走向成熟：技术成熟：持续交付77测试管理测试管理3 测试的过程管理：端到端测试过程总体总体测试要约测试要约测试准备测试准备测试计划测试计划与方案与方案测试设计测试设计测试分析测试分析与报告与报告测试执行测试执行78测试管理测试管理3 3 测试要约测试要约l 确定测试的总体范围和目标l 确定总体测试

27、时间计划l 确定测试人员安排及组织结构l 确定对应角色工作职责l 确定测试组运作机制l 确定主要测试流程79测试管理测试管理3 总体测试要约：确定测试总流程80测试管理测试管理3. 测试总体要约：bug类型与界定1.Bug严重程度；2.Bug分类；3.Bug修改的优先级；4.Bug状态81测试管理测试管理3 总体测试要约：确定与用户的bug流程( (上线上线& &运维运维) )客户投诉内部自查系统BUG业务规则易操作性操作过程BUG管理系统BUG问题列表BUG专题会专题会公司级系统运营评估电话会议前台操作员 工程师客户经理每日问题反馈和解决（每日下午3:00）系统运行情况评估分

28、析（每日下午5:30）现场派驻响应现场派驻响应安排技术人员到现场，接收现场咨询，现场无法解决时，提交到省公司问题处理组，省公司问题处理组安排相关人员进行解决。24小时热线电话支持小时热线电话支持主要是针对紧急问题，快速提供解决问题的方法82基础管理基础管理3总体测试要约：确定测试的范围和目标(举例)测试分类测试分类 测试范围覆盖测试范围覆盖 交付目标交付目标 1功能测试(含单元/集成/接口/报表/测试)1）覆盖全部网元/动作，支持各种业务；2）覆盖所有接口和报表；3）覆盖所有产品无关的功能点；1、业务覆盖率100%；2、接口连通性100%；3、C类以上Bug修复率100%；2模拟测试渠道为营业

29、厅办理的业务模拟测试通过率95%；3性能测试覆盖70%的业务量的主要业务；主要业务响应时间高于规范标准；资源使用合理；4安全性/兼容性测试主要业务抽取5种，覆盖身份验证、权限操作、密码安全；覆盖IE6、7、8及vista、xp、win7；安全性、兼容性用例通过率100%5容错性测试双机备份、单点故障等通过率100%83测试管理测试管理3总体测试要约：确定总体测试时间计划84基础管理基础管理3总体测试要约：确定测试人员安排及组织结构85测试管理测试管理4、测试度量与评估： 项目期间bug管理1.BUG统一录入BUG管理平台;2.每天实时统计各测试人员BUG提交情况；3.每日根据实时汇总的BUG跟

30、踪表统计BUG新增情况与积压延期情况4.修改后的BUG要及时跟进测试5.每日进行BUG处理情况接口人会议86配置管理配置管理86 配置管理 07 787配置管理配置管理内容提要1. 软件配置管理的概念2. 软件配置管理计划3. 软件配置标识4. 变更管理5. 版本管理6. 配置审核7. 配置状态报告8. 软件配置管理工具88配置管理配置管理一、软件配置管理的概念（一）软件配置项的概念1、软件配置项：配置管理的对象称为软件配置项。表1 软件配置项的分类、特征和举例分 类特 征举 例环境类软件开发环境 及 软件维护环境编译器、操作系统、编辑器、数据库管理系统、开发工具（如测试工具）、项目管理工具、

31、文档编辑工具定义类需求分析及定义阶段完成后得到的工作产品需求规格说明书、项目开发计划、设计标准或设计准则、验收测试计划设计类设计阶段结束后得到的产品系统设计规格说明、程序规格说明、数据库设计、编码标准、用户界面标准、测试标准、系统测试计划、用户手册编码类编码及单元测试后得到的工作产品源代码、目标码、单元测试数据及单元测试结果测试类系统测试完成后的工作产品系统测试数据、系统测试结果、操作手册、安装手册维护类进入维护阶段以后产生的工作产品以上任何需要变更的软件配置项89配置管理配置管理2、软件配置 软件配置是一个软件产品在生存期各个阶段的不同形式（记录特定信息的不同媒体）和不同版本的程序、文档及相

32、关数据的集合，或者说是配置项的集合。初始系统机型1机型2机型n操作系统1操作系统2用户1用户2图1 不同用户有自己的工作环境90配置管理配置管理（二）软件配置管理1、什么是软件配置管理（1）ISO 9000-3 :1997 配置管理是一个管理学科，它对配置项（包括软件项）的开发和支持生存期给与技术上的和管理上的指导。配置管理的应用取决于项目的规模、复杂程度和风险大小。（2） W.Babich 的解释 软件配置管理能协调软件开发，使混乱减到最小，目的是最有效的提高生产率。（3） GB/T 11457 :1995软件工程术语国家标准 A.表示和确定系统中配置项的过程，在系统整个生存期内控制这些配置

33、项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。 B.对下列工作进行技术和行动指导与监督的一套规范： 对配置项的功能特性和物理特性进行标识和文件编制工作； 控制这些特性的更动情况； 记录并报告这些更动进行的处理和实现的状态。91配置管理配置管理2、软件配置管理的任务制定软件配置管理计划确定配置标识规则实施变更控制报告配置状态进行配置审核进行版本管理和发行管理 92配置管理配置管理二、软件配置管理计划 配置管理计划标准IEEE 828-19901引言配置管理计划的目的、适应范围、使用要求项目概述项目中需特别关注的配置管理问题和风险软件配置管理严格性要求的等级限制和假设

34、术语参考文件93配置管理配置管理2、软件配置管理配置管理的组织结构职责和权限指令和方针参照的规程（组织的规程或客户的规程）遵循的标准3、软件配置管理活动配置管理活动变更管理和配置控制配置状态说明配置审核接口和子合同方控制94配置管理配置管理4、软件配置管理进度安排软件配置管理重要事件的顺序软件配置管理各项活动间的依赖关系5、软件配置管理所需的资源采用的工具使用的设备所需的培训对其他人员的要求6、软件配置管理计划的维护维护的职责计划更新的条件和审批计划变更的交流和通报95配置管理配置管理三、软件配置标识（一）确定配置项1、 系统规格说明2、软件项目计划3、软件需求规格说明书a.图形分析模型b.处

35、理规格说明c.原型d.数学规格说明4 初步用户手册5 设计规格说明书a.数据设计描述b.体系结构设计描述c.模块设计描述d.接口设计描述e.对象描述（采用面向对象技术时）6 源代码清单7、 测试规格说明 a.测试计划和步骤 b.测试用例和记录的结果8、操作和安装手册9、 可执行程序 a.模块可执行代码b.连接的模块10、数据库描述 a.模式和文件结构 b.初始内容11、联机用户手册12、维护文档 a.软件问题报告 b.维护请求 c.工程变更指令13.软件工程标准和规程96配置管理配置管理（二）配置项命名及其相关信息1、配置项命名。命名的基本要求：唯一性；可追溯性。 例：CODE是根结点为PCL

36、_TOOLS树结构的第六层结点，对其命名为：PCL_TOOLS/EDIT/FORMS/DISPLAY/AST_INTERFACE/CODE 97配置管理配置管理2、配置项的相关标识信息 每一配置项的有关信息：组名项名项标识（文件名或命名规则）版本编号规则什么情况下纳入控制之下，或版本号所遵循的变更控制规程98配置管理配置管理3、配置库 记录与配置相关的所有信息 利用库中的信息可评价变更的后果 可利用库中的信息查询，例如： 那些客户已提取了某个特定的系统版本？ 运行一个给定的系统版本需要什么硬件和系统的哪些版本? 一个系统到目前已生成了多少版本，何时生成的？ 如果某一特定的构件变更了，会影响到系

37、统的那些版本？ 一个特定的版本曾提出过那几个变更请求？ 一个特定的版本有多少已报告的错误？99配置管理配置管理 三类库配置库 （1）开发库：存放开发过程中需要保留的各种信息，供开发人员个人专用。（2）受控库：在软件开发的某个阶段工作结束时，将工作产品存入或将有关的信息存入。（3）产品库：在开发的软件产品完成系统测试之后，作为最终产品存入库内，等待交付用户或现场安装。100配置管理配置管理4、配置基线 基线是软件生存期各开发阶段末尾的特定点，也称为里程碑。101配置管理配置管理 三种常见基线 功能基线 在系统分析和软件定义阶段结束时，经过正式评审和批准的系统设计规格说明中对被开发软件系统的规格说

38、明；经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对被开发软件系统的规格说明；由下级申请及上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。分配基线 在软件需求分析阶段结束时，经正式评审和批准的软件需求规格说明。产品基线 在软件组装与系统测试阶段技术时，经正式评审和批准的有关所开发的软件产品的全部配置项的规格说明。102配置管理配置管理四、版本管理1、软件版本：包含两种不同含义（1）为满足不同用户的不同使用要求，如适用于不同运行环境或不同平台的系列产品。（2）软件产品投入使用以后，经过一段时间运行提出了变更的要求，需要做较大的修正或纠错，增强功能或提

39、高性能。2、版本标识版本管理也称版本控制。版本标识方法：（1）号码版本标识（2）符号版本标识：把重要的版本属性有选择地给出。 如：V1/VMS/DB Server103配置管理配置管理五、配置审核（一）什么是配置审核 它是指对于存储配置项及相关记录的软件基线库的结构、内容和设施进行检验，其目的在于验证基线是否符合描述基线的文档。 验证包括： 配置项的处理是否有背离初始的规格说明或已批准的变更请求的现象；是否保持了可追溯性。 配置标识的准则是否得到了遵循； 变更控制规程是否以遵循，变更记录是否可供使用配置审核配置审核工作主要集中在两个方面，即： 功能配置审核验证配置项的实际功效是与其软件需求一致

40、的。 物理配置审核确定配置项符合预期的物理特性，即特定的媒体形式。104配置管理配置管理（二）为什么要实施配置审核 确保软件配置管理的有效性，不允许出现任何混乱现象。例如：防止出现向用户提交了不适合的产品，如交付了用户手册不适当的版本；发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更；找出各配置项间不匹配或不相容的现象；确认配置项已在所要求质量控制审查之后作为基线入库保存；确认记录和文档保持着可追溯性。105配置管理配置管理六、配置状态报告（一）什么是配置状态报告 1、配置状态报告 任务：有效的记录和报告管理配置所需要的信息 目的：及时、准确的给出软件配置项的当前状况，供相关人员了解，以加强