软件研发项目管理课件.ppt

1、软件研发项目管理2013-2-20标题添加点击此处输入相关文本内容点击此处输入相关文本内容前言点击此处输入相关文本内容标题添加点击此处输入相关文本内容2研发项目管理基础1计划管理2需求管理3设计管理4开发管理5测试管理6目录配置管理7最佳实践83 基础管理 01 14总纲与规范六为法 需求必为准 团队必为本 计划必为纲 绩效必为证 质量必为出 变化必为形5总纲与规范七定法 兵马未动、合约先行（定需求）可行的做可行事（定技术方案）谋定而后动（定计划）专业的人做专业的事（定人员）沟通无止境、共识促发展（定共识）死亡之地不可不察也（定风险）应对随形、修道保法（定变更）6总纲与规范三出路 以正合（用人

2、之术，诸如选育用留）以曲制（规律之术，诸如过程方法）以奇胜（变化之术，诸如动静之理）7总纲与规范兵法 一曰道 目的 二曰天 制度 三曰地 需求 四曰将 专业角色 五曰法 过程8基础管理-过程管理过程的简单描述9基础管理-过程管理软件研发的分类和组成p软件基本过程：软件获取、供应、开发、运行和维护的过程，包括需求分析、软件设计、编码等过程。p软件支持过程：对软件主要过程提供支持的过程，包括文档编制过程、配置管理过程、质量保证过程、验证和确认过程（测试过程）、评审过程等。p软件组织过程：对软件主要过程和支持过程的组织保证过程，包括管理过程、基础设施过程、改进过程和培训过程。10基础管理-过程管理I

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

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

5、 确定项目范围 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 根据反馈修改功能规范 3.6 获得开展后续工作的批准 3.7 设计工作完成4 开发 4.1 审阅

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

7、本 人力成本 硬件设备 软件费用（2）间接成本 项目管理成本 一般管理成本21计划管理责任矩阵用距阵的形式列出对某项任务负责的人或资源。任务管理人员项目经理分析人员项目范围规划 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 根据反馈修改软件规范A 2.6 确定交付期限A 2.7 获得开展后续工作的批准AP 2.8 获得所需资源A22计划管理项目软硬件资源管理1.软件资源管理 操作系统 编译器 应用软件

8、 测试工具 2.硬件资源管理 服务器 PC 23计划管理10种常见的风险No.软件风险相应对策1人员不足录用优秀人才；人员应适应岗位需要；全面考虑团队建设；骨干人员工作要协调；实施培训；预先安排关键人员的使用计划2进度计划和预算不准确详细评估多种资源成本和进度；依成本进行设计；采用渐增式开发；软件复用；纯净需求3开发了错误的软件功能进行组织分析；实施任务分析；进行用户调查；开发原型；及早编制用户手册4开发了不适用的用户接口开发原型；制作脚本；作业分析；弄清了用户特征(功能性、风格、工作负荷)5只追求表面效果，需求中含有一些不必要的功能（镀金）纯净需求；开发原型；成本效益分析；依成本进行设计6需

9、求不断变更重大变更设限；信息隐蔽；渐进式开发7外供部件不足制定基准点；检验；参考基准检查；兼容性分析8外包任务问题参考基准检查；发包前审核；未发包合同；竞标设计或开发原型；建立团队9实时性能达不到要求模拟；制定基准；建模；开发原型；安装测量装置；调准10误解计算机科学能力技术分析；成本效益分析；开发原型；参考基准检查24计划管理项目跟踪和控制1.了解成员的工作情况2.调整工作安排，合理利用资源3.促进计划内容的完善4.促进项目经理对人员的认识5.促进对项目工作量的估计6.统计并了解项目总体进度7.有利于人员考核25计划管理现代软件研发项目管理路线图概览26计划管理项目预算与成本1、项目成本=直

10、接成本*2.5 直接成本为prj中的成本2、项目工期=基本工期+（悲观时间-乐观时间）/63、项目工期较长，可以分解为多个项目，每个项目不超过6个月，6个月内按两周做计划。4、任务分解一般两周:过粗不利分配工作,过细不利于人员的主动性.5、要识别任务关键路径,根据人员情况并行或串行。27计划管理WBS CHart28计划管理Chart EXPERT29计划管理关键路径实例-Microsoft project 30需求管理30 需求管理 03331需求管理软件研发的需求管理开发软件系统最为困难的部分就是准确说明开发什么。弗雷德里克布鲁克斯32需求管理软件需求工程 所有与需求直接相关的活动统称为需

11、求工程，需求工程分为了两个部分：需求开发和需求管理。其中，需求开发又分为了需求获取、需求分析、需求定义和需求验证4个部分，而需求管理则包含了变更控制、版本控制、需求跟踪和需求状态跟踪 软件需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）。33需求管理软件需求工程l 业务需求（business requirement）反映了组织机构或客户对系统、产品的概括的目标要求，它在项目视图与范围文档中予以说明。主要的目的是对企业目前的业务流程进行评估，得出一个业务前景。业务需求的确定对后面的用户需求和功能需求起到了限制作用。l 用户需求(user requirement)文档描述了

12、用户使用系统而完成的任务的集合，用户需求在用户案例（user case）文档或方案脚本中予以说明。收集和分析用户需求是不容易的，因为很多需求是隐形的，很难获取，更难保证需求完整，而需求又是易变的，这就要求用户和开发人员进行充分地交流。l软件需求(fsoftware requirement)定义了开发人员必须实现的软件功能，它源于用户需求。功能需求是软件需求说明书中最重要的部分之一，它在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。非功能需求描述了系统展现给用户的行为和执行的操作等，包括要遵从的业务规则、人机接口、安全性和可靠性等要求。34需求管理需求开发需求开发的目的是通过

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

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

15、设计管理 04 441设计管理架构开发方法42设计管理架构开发方法43设计管理架构开发方法44设计管理架构是软件的基石架构是软件的基础，一个良好的架构可以让软件有更长久的生命力，能发挥出更出色的性能；架构师要求对业务有深入的了解，这样才能让架构更符合软件的需要，更能发挥软件的特点。45设计管理46设计管理47设计管理48设计管理49开发管理 开发管理 05550开发管理1.开发开发的目的包括：对照开发子系统的分层结构定义代码结构;以构件（源文件、二进制文件、可执行文件以及其他文件等）的方式开发类和对象;对已开发的构件按单元来测试;将各开发员（或团队）完成的结果集成到可执行系统中。51开发管理2

16、.过程策略里程碑：最初操作性能最初操作性能里程碑确定产品是否已经可以部署到 Beta 测试环境。在最初操作性能里程碑，产品随时可以移交给产品化团队。此时，已开发了所有功能，并完成了所有 Alpha 测试（如果有测试）。除了软件之外，用户手册也已经完成，而且有对当前发布版的说明。评估标准该产品发布版是否足够稳定和成熟，可部署在用户群中？是否已准备好将产品发布到用户群？实际的资源耗费与计划的相比是否仍可以接受？如果项目无法达到该里程碑，产品化可能要推迟一个发布版。52开发管理最佳开发实践 新概念与最佳实践 可持续开发节奏 团队激励 障碍列表 持续集成 产品燃尽图 Sprint燃尽图53开发管理可持

17、续开发节奏的相关概念 可持续的开发节奏是一个开发团队可长期（可以认为是永久）保持的开发节奏 为了保持可持续的开发节奏，适当的休假可以让团队及时恢复精力。可持续的开发节奏并非禁止加班，但必须是偶然事件而非经常性事件54开发管理讨论 当项目进度对于完成当前的迭代目标面临压力时，作为Scrum Master，你会采取以下哪种方式？55开发管理Scrum Master要关注团队的健康 高强度的开发节奏如果超过了团队可承受的范围，必然影响团队的健康（包括心理和生理健康）。Scrum Master应该关注团队的健康状况。选择可持续的开发节奏，应该以团队能够感觉舒适地完成迭代目标为前提。56开发管理不可持续

18、开发节奏的影响57开发管理不可持续开发节奏的影响 Defect大量增加：持续加班状况下代码质量很难保证，必然导致defect数量增加。工作效率降低：研究表明，当人疲劳时工作效率将急剧下降。团队士气低下：长期的高强度工作必然使团队身心疲惫，士气低落。开始相互推诿责任：长期高负荷工作下，导致出现问题后开始相互埋怨。放弃探索最佳实践方法：磨刀不误砍柴工，最佳实践方法可以事半功倍。然而长期高强度工作会逐渐放弃花时间去“磨刀”。58开发管理障碍列表在敏捷项目管理中的意义 及时将团队的注意力引导向最重要的问题。集思广益。由团队成员一起讨论解决，而不是由传统意义上的项目经理独自来协调与分配。提高团队的自主性

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

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

21、。67测试管理1 软件工程与测试模型l 不同的开发模式适配不同的测试模型和测试过程。开发流水线产品平台技术平台设计实现测试部署测试需求测试设计测试执行测试执行68测试管理1.1 测试模型1：瀑布模型l 瀑布模型的核心思想是按工序将问题化简，将功能的实现与设计分开，采用结构化的分析与设计方法将逻辑实现与物理实现分开。l 软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试、运行维护。l 规定活动自上而下、相互衔接的固定次序，逐级下落。69测试管理1.2测试模型2：V模型l V模型是最广为人知的测试模型l 由Paul Rook在2世纪年代后期提出的，旨在改进软件开发的效率和效果。l

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

23、编码和测试，此后将进行频繁的交接，通过集成最终合成为可执行的程序，然后再对这些可执行程序进行测试。l 己通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。l X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，给有经验的测试人员在测试计划之外发现更多的软件缺陷。72测试管理2 测试组织产品组/产品线测试组开发组项目1项目2项目3优势：1、与业务结合紧密（用例）；2、与代码结合紧密（白盒）；缺点：1、测试资源未统一动态调配，使用有浪费；2、测试技能的统一提升和培训少。73测试管理2 测试组织规模74测试管理2

24、走向成熟：组织成熟怎么算组织成熟？75测试管理2 走向成熟：技术成熟：工具平台76测试管理2 走向成熟：技术成熟：测试流水线业务知识77测试管理2 走向成熟：技术成熟：持续交付78测试管理3 测试的过程管理：端到端测试过程79测试管理3 3 测试要约l 确定测试的总体范围和目标l 确定总体测试时间计划l 确定测试人员安排及组织结构l 确定对应角色工作职责l 确定测试组运作机制l 确定主要测试流程80测试管理3 总体测试要约：确定测试总流程81测试管理3.测试总体要约：bug类型与界定1.Bug严重程度；2.Bug分类；3.Bug修改的优先级；4.Bug状态82测试管理3 总体测试要约：确定与用

25、户的bug流程(上线&运维)客户投诉内部自查系统BUG业务规则易操作性操作过程BUG管理系统BUG问题列表BUG专题会公司级系统运营评估电话会议前台操作员 工程师客户经理每日问题反馈和解决（每日下午3:00）系统运行情况评估分析（每日下午5:30）现场派驻响应安排技术人员到现场，接收现场咨询，现场无法解决时，提交到省公司问题处理组，省公司问题处理组安排相关人员进行解决。24小时热线电话支持主要是针对紧急问题，快速提供解决问题的方法83基础管理3总体测试要约：确定测试的范围和目标(举例)测试分类 测试范围覆盖 交付目标 1功能测试(含单元/集成/接口/报表/测试)1）覆盖全部网元/动作，支持各种

26、业务；2）覆盖所有接口和报表；3）覆盖所有产品无关的功能点；1、业务覆盖率100%；2、接口连通性100%；3、C类以上Bug修复率100%；2模拟测试渠道为营业厅办理的业务模拟测试通过率95%；3性能测试覆盖70%的业务量的主要业务；主要业务响应时间高于规范标准；资源使用合理；4安全性/兼容性测试主要业务抽取5种，覆盖身份验证、权限操作、密码安全；覆盖IE6、7、8及vista、xp、win7；安全性、兼容性用例通过率100%5容错性测试双机备份、单点故障等通过率100%84测试管理3总体测试要约：确定总体测试时间计划85基础管理3总体测试要约：确定测试人员安排及组织结构86测试管理4、测试

27、度量与评估：项目期间bug管理1.BUG统一录入BUG管理平台;2.每天实时统计各测试人员BUG提交情况；3.每日根据实时汇总的BUG跟踪表统计BUG新增情况与积压延期情况4.修改后的BUG要及时跟进测试5.每日进行BUG处理情况接口人会议87配置管理87 配置管理 07 788配置管理内容提要软件配置管理的概念软件配置管理计划软件配置标识变更管理版本管理配置审核配置状态报告软件配置管理工具89配置管理一、软件配置管理的概念（一）软件配置项的概念1、软件配置项：配置管理的对象称为软件配置项。表1 软件配置项的分类、特征和举例分 类特 征举 例环境类软件开发环境 及 软件维护环境编译器、操作系统

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

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

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

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

32、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.软件工程标准和规程97配置管理（二）配置项命名及其相关信息1、配置项命名。命名的基本要求：唯一性；可追溯性。例：CODE是根结点为PCL_TOOLS树结构的第六

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

34、求？一个特定的版本有多少已报告的错误？100配置管理 三类库配置库 （1）开发库：存放开发过程中需要保留的各种信息，供开发人员个人专用。（2）受控库：在软件开发的某个阶段工作结束时，将工作产品存入或将有关的信息存入。（3）产品库：在开发的软件产品完成系统测试之后，作为最终产品存入库内，等待交付用户或现场安装。101配置管理4、配置基线 基线是软件生存期各开发阶段末尾的特定点，也称为里程碑。102配置管理 三种常见基线 功能基线 在系统分析和软件定义阶段结束时，经过正式评审和批准的系统设计规格说明中对被开发软件系统的规格说明；经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对被

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

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

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

38、更的状态107最佳实践107 最佳实践 08 8108最佳实践软件研发的管理实践不同的项目需要不同的方法论，一个项目的最佳过程是这个项目所能负担的最小过程。Alistair Cockburn109最佳实践本章提纲1 IBM-Rational 业务驱动开发的过程管理2 微软公司的软件开发过程模式3 敏捷模型的软件研发管理4 面向构件的软件研发5 软件研发的自定义体系110最佳实践敏捷模型的软件研发管理1 敏捷方法的过程模型2 敏捷过程的最佳实践111最佳实践敏捷方法的过程模型n 主张简单、轻装前进。n 拥抱变化，这种变化是不断递增的。n 可持续性，简单的说，在开发的时候就能想象到未来。n 项目投

39、资产生最大的效益或回报。n 有目的的建模。n 多种模型。n 高质量的工作、快速反馈。n 软件是项目的主要目标，文档是次要的。112最佳实践极限编程生命周期 113最佳实践测试驱动开发 114最佳实践敏捷过程的最佳实践编程简单设计、测试、重构、编码标准团队实践代码集体所有、持续集成、隐喻、编码标准、每周40小时工作制、结对编程、小型发布过程现场客户、测试、计划博弈、小型发布起始阶段 细化阶段构建阶段交付阶段需求用户素材小型发布先行测试测量分析CRC卡片迭代计划任务计划、迭代编程 计划博弈设计系统隐喻单元测试重构持续集成实现编码标准简单设计集体代码所有权运行所有测试115最佳实践面向构件的软件研发

40、1 面向构件软件研发的思想2 面向构件软件研发的阶段划分116最佳实践面向构件软件研发的思想1从传统的关注点分离到构件组装2以构件为中心组织软件研发。3高度关注可复用性和软件研发知识积累4高度并行的开发过程117最佳实践基于构件描述的网状软件结构 118最佳实践面向构件软件研发的阶段划分 需求阶段。捕获需求、识别业务构件、归纳业务构件需求。分析与高层设计阶段。分析业务构件、识别服务构件，归纳服务构件的需求并完成架构设计。并行开发与测试阶段。提交、发布与部署阶段。应用管理。提问与解答环节Questions and answers结束语 感谢参与本课程，也感激大家对我们工作的支持与积极的参与。课程后会发放课程满意度评估表，如果对我们课程或者工作有什么建议和意见，也请写在上边