软件开发项目管理教材(PPT47页).ppt
合集下载
软件项目管理教材PPT89页
核心三计划
范围计划 进度计划 成本计划
－－成本基准，进度基准
0
软件项目管理
第三讲 软件项目范围计划
1
本章要点
一、软件需求管理过程 二、任务分解定义 三、任务分解的类型 四、任务分解的过程 五、案例分析
2
1 软件项目需求管理
影响软件项目成败的因素
其它
过少的用户输入
13%
12% 50%
场景串联提供了用户界面以说明系统操作流程，它容易创 建和修改，能让用户知道系统的操作方式和流程。
根据与用户交互的方式，场景串联被分成三种模式：静态 的场景串联、动态的场景串联以及交互的场景串联。
选择提供哪种场景串联是根据系统的复杂性和需求缺陷的 风险来确定的。
23
如何记录需求------需求跟踪矩阵
Inadequate communications for system integration 8
系统集成阶段 , 交流与沟通不充分
9
Insufficient experience as team 团队缺乏经验
10 Shortage of application domain experts
缺乏应用领域专家
4
1 软件项目需求管理
软件开发的目标——按时按预算开发出满足用户真实需要的软件。 需求—— 一个软件项目的开始阶段。在软件工程中，需求分析阶 段是 包括客户、用户、业务或需求分析员、开发人员、测试人员、用 户文档编写者、项目管理者和客户管理者在内的所有的风险承担者都 需要参与的阶段。
5
1 软件项目需求管理
结构化分析方法的优点与局限性。
28
需求规格
需求分析工作完成的一个基本标志是形成 了一份完整的、规范的需求规格说明书
范围计划 进度计划 成本计划
－－成本基准，进度基准
0
软件项目管理
第三讲 软件项目范围计划
1
本章要点
一、软件需求管理过程 二、任务分解定义 三、任务分解的类型 四、任务分解的过程 五、案例分析
2
1 软件项目需求管理
影响软件项目成败的因素
其它
过少的用户输入
13%
12% 50%
场景串联提供了用户界面以说明系统操作流程，它容易创 建和修改，能让用户知道系统的操作方式和流程。
根据与用户交互的方式，场景串联被分成三种模式：静态 的场景串联、动态的场景串联以及交互的场景串联。
选择提供哪种场景串联是根据系统的复杂性和需求缺陷的 风险来确定的。
23
如何记录需求------需求跟踪矩阵
Inadequate communications for system integration 8
系统集成阶段 , 交流与沟通不充分
9
Insufficient experience as team 团队缺乏经验
10 Shortage of application domain experts
缺乏应用领域专家
4
1 软件项目需求管理
软件开发的目标——按时按预算开发出满足用户真实需要的软件。 需求—— 一个软件项目的开始阶段。在软件工程中，需求分析阶 段是 包括客户、用户、业务或需求分析员、开发人员、测试人员、用 户文档编写者、项目管理者和客户管理者在内的所有的风险承担者都 需要参与的阶段。
5
1 软件项目需求管理
结构化分析方法的优点与局限性。
28
需求规格
需求分析工作完成的一个基本标志是形成 了一份完整的、规范的需求规格说明书
软件项目管理.ppt
PSP1在PSP0的基础上增加了计划步骤：
2019-11-2
感谢你的阅读
22
影响CMMI过程改进成败的因素
过程改进必须有高级主管的支持与委托，并积 极地管理过程改进的进展。
获取中层管理的支持，以方便地获取过程改进 的资源（人员、时间、经费和设备）。
基层技术人员的参与和支持极端重要。
利用定量的可观察数据尽快使过程改进的成果 可见，从而激励参与者的兴趣。
2019-11-2
感谢你的阅读
14
软件过程评估和软件能力评价之间的不同
软件过程评估是在一个开放的、互相协作的环 境下进行的。而软件能力评价往往是在有较大 阻力的环境中进行的。（过程评估是为了提高 管理者和工程师的工作水平，而能力评价是为 了表明一个软件组织的实际软件过程能力，为 选择承包者和减少费用服务）。
2019-11-2
感谢你的阅读
25
PSP关注点
如何制订计划 如何控制质量 如何与其他人相互协作 如何预防缺陷(PSP重点)
关键是如何提高设计质量
2019-11-2
感谢你的阅读
26
PSP中的个人任务
为每一个项目/模块制订开发计划； 记录开发时间； 跟踪错误； 在工程摘要报表中保留数据； 使用已有的数据计划以后的项目/模块； 分析已有的数据以改进开发过程，不断提高开
发水平。
2019-11-2
感谢你的阅读
27
PSP的使用效果
参加PSP培训的104位软件人员在应用了PSP后: 软件中总的差错数减少了58.0％； 在测试阶段发现的差错减少了71.9％； 生产效率提高了20.8％
2019-11-2
感谢你的阅读
WBS项目管理(共47张PPT)
工作包可进一步分解为子项目的WBS或各个活动
11
本章要点
一、任务分解定义 二、任务分解的类型 三、任务分解的过程 四、任务分解指南 五、案例分析
12
清单
图表
WBS类型
13
图表类型
“变化计数器”系统
版本
找出
统计
统
标
记
比较
增删
增删
计
记
录
行
行
总
修
修
行
改
改
预
文
结
增
删增
删
处
件
果
加
除加
除
理
比
处
电信运营信息查询系统分解一例
36
网管系统（图表）分解实例
F1
配置管理
F
F2 故障管理
F3
安全管理
F4 性能管理
37
网管系统（图表）分解实例
F1
F1.1
F1.3
F1.5
F1.7
F1.9
F1.11
F1.2
F1.4
F1.6
F1.8
F1.10
F1.4.1 F1.4.2
38
网管系统（图表）分解实例
F2
39
课堂练习
你是某项目的项目经理,这个项目是为用户创 建一个新的邮件服务器以及在所有100个工 作站上部署相应的邮件客户端（要满足用 户的期望）。其中，2个服务器需要重新购 置，而客户端的机器已经存在。请提交任 务分解结果WBS,
WBS的图表
47
规划 需求 设计 编码
测试
提交
按照产品组成分解
1.1 招生管理 1.2 分班管理
11
本章要点
一、任务分解定义 二、任务分解的类型 三、任务分解的过程 四、任务分解指南 五、案例分析
12
清单
图表
WBS类型
13
图表类型
“变化计数器”系统
版本
找出
统计
统
标
记
比较
增删
增删
计
记
录
行
行
总
修
修
行
改
改
预
文
结
增
删增
删
处
件
果
加
除加
除
理
比
处
电信运营信息查询系统分解一例
36
网管系统（图表）分解实例
F1
配置管理
F
F2 故障管理
F3
安全管理
F4 性能管理
37
网管系统（图表）分解实例
F1
F1.1
F1.3
F1.5
F1.7
F1.9
F1.11
F1.2
F1.4
F1.6
F1.8
F1.10
F1.4.1 F1.4.2
38
网管系统（图表）分解实例
F2
39
课堂练习
你是某项目的项目经理,这个项目是为用户创 建一个新的邮件服务器以及在所有100个工 作站上部署相应的邮件客户端（要满足用 户的期望）。其中，2个服务器需要重新购 置，而客户端的机器已经存在。请提交任 务分解结果WBS,
WBS的图表
47
规划 需求 设计 编码
测试
提交
按照产品组成分解
1.1 招生管理 1.2 分班管理
软件项目管理课程(PPT 80张)
六盘水师范学院 孙新杰
3
◆ 人员： 人员是一个成功软件项目中最重要的因素。 可分为5类： ⑴高级管理者：负责定义业务问题，影响着项目。 ⑵技术管理者：组织、激励和控制开发人员。 ⑶开发人员：负责开发一个产品或应用所需的技术。 ⑷客户（customer)：负责说明待开发的软件需求。 ⑸最终用户（user)：直接使用发布的软件。
六盘水师范学院 孙新杰
25
2. 软件度量的方法
（1）面向规模的度量 是对软件和软件开发过程的直接度量。 可以建立一个面向规模的数据表格来记录项目的某 些信息。该表格列出了在过去几年完成的每一个软件开 发项目和关于这些项目的相应面向规模的数据。
六盘水师范学院 孙新杰
26
基于所生产软件的“规模”，使用代码行作为其他 计算的规范化因子。计算： •每千行代码（KLOC) 的错误数。 •每KLOC 的缺陷数。 •每个LOC的花费成本。 •每KLOC 的文档页数 •每人月的错误数。 •每人月的代码行。 •每页文档的成本。
六盘水师范学院 孙新杰
23
◆项目度量： 是战术的，使项目管理者能够以实时的方式改进项 目的工作流程及技术方法，如软件项目的工作量及时间 的估算。 项目度量的基础是历史项目中收集的数据。随着项 目的进展，所花费的工作量及时间和预算的值进行比较， 从而控制项目的进展。 另外，可根据文档的页数、评审的时间、功能点及 源代码行数来度量软件的生产率。
六盘水师范学院 孙新杰
21
1. 过程和项目的度量
◆过程度量： 使一个组织从战略上考察已有过程的功效，如开发 范型、工程任务的划分、工作产品、里程碑等，使管理者 评估那些部分起了作用。度量数据的收集跨越所有的项目， 经历较长的时间，目的是改善软件过程。 间接的度量一个软件过程的功效： • 软件发布之前发现的错误数 • 交付给用户后报告的缺陷数 • 花费的工作量、时间、成本 • 与进度计划是否一致
软件开发项目管理PPT课件(92页)
– 优点：近30年来之所以广为流行，是因为它在支持开发结 构化软件、控制软件的开发复杂度、促进软件开发工程化 方面起着显著作用
– 缺点：缺乏灵活性，无法通过开发活动澄清本来不够确切 的软件需求。这些问题可能导致开发出的软件并不是用户 真正需要的软件，并且这一点在开发过程完成后才有所察 觉
ห้องสมุดไป่ตู้
2.5 进化模型(1)
• 实践表明，各个阶段间的关系并非如此简单。由于阶段评审可 能出现向前阶段的反馈，致使在各阶段间产生环路，瀑布流水 出现上流。W.Royce在提出瀑布模型时，就对此提出了如何进行 的建议
瀑布模型(2)
系统需求 软件需求 分析 设计 编码 测试
每个开发阶段均应具有以下特征
• 从上一阶段接受本阶段工作的对 象，作为输入
1.1 软件项目管理的目的
• 为了生产产品能做到:
–按时交付 –在预算内 –合格的质量 –按计划做事
1.2 软件项目管理的重要性
• 软件工程管理引起广泛注意源于20世纪70年代中期，当时 发现不成功的项目70%是因为管理不善而引起
• 20世纪90年代中期，美国的软件开发仍然很难预测，大约 只有10%的项目能够在预定的费用和进度下交付
1.3 软件项目管理的对象
• 任务 • 成本 • 工作量 • 效率 • 人员 • 资源 • 风险
1.4 项目管理的主要任务
• 定义软件生命周期 • 进行软件规模估算 • 进行软件风险分析 • 制定软件开发计划 • 进行软件项目跟踪与监控 • 进行软件度量
2 软件生命周期
2.1 软件过程的三个主要阶段 2.2 什么是软件生命周期 2.3 软件生命周期模型 2.4 瀑布模型 2.5 进化模型 2.6 螺旋模型 2.7 Rational 软件开发过程框架 2.8 软件生命周期的选取评价准则
– 缺点：缺乏灵活性，无法通过开发活动澄清本来不够确切 的软件需求。这些问题可能导致开发出的软件并不是用户 真正需要的软件，并且这一点在开发过程完成后才有所察 觉
ห้องสมุดไป่ตู้
2.5 进化模型(1)
• 实践表明，各个阶段间的关系并非如此简单。由于阶段评审可 能出现向前阶段的反馈，致使在各阶段间产生环路，瀑布流水 出现上流。W.Royce在提出瀑布模型时，就对此提出了如何进行 的建议
瀑布模型(2)
系统需求 软件需求 分析 设计 编码 测试
每个开发阶段均应具有以下特征
• 从上一阶段接受本阶段工作的对 象，作为输入
1.1 软件项目管理的目的
• 为了生产产品能做到:
–按时交付 –在预算内 –合格的质量 –按计划做事
1.2 软件项目管理的重要性
• 软件工程管理引起广泛注意源于20世纪70年代中期，当时 发现不成功的项目70%是因为管理不善而引起
• 20世纪90年代中期，美国的软件开发仍然很难预测，大约 只有10%的项目能够在预定的费用和进度下交付
1.3 软件项目管理的对象
• 任务 • 成本 • 工作量 • 效率 • 人员 • 资源 • 风险
1.4 项目管理的主要任务
• 定义软件生命周期 • 进行软件规模估算 • 进行软件风险分析 • 制定软件开发计划 • 进行软件项目跟踪与监控 • 进行软件度量
2 软件生命周期
2.1 软件过程的三个主要阶段 2.2 什么是软件生命周期 2.3 软件生命周期模型 2.4 瀑布模型 2.5 进化模型 2.6 螺旋模型 2.7 Rational 软件开发过程框架 2.8 软件生命周期的选取评价准则
软件项目PPT课件
软件开发项目管理
0
承启上课
项目计划
进度计划—核心计划 质量计划 配置计划 风险计划 。。。
辅助计划
1
RoadMap
合同管理 需求管理 生存期 任务分解 规模估算 项目进度
质量计划 配置计划 风险计划 团队管理 项目度量
集成项目 跟踪控制 项目结束
2
软件开发项目管理
第十一章 软件项目团队管理
33
麦克勒格的 Y －理论
如果给予适当的激励和支持性的工作氛围，会 达到很高的绩效预期
具有创造力，想象力，雄心和信心来实现组织 目标
能够自我约束，自我导向与控制，渴望承担责 任
用马斯洛的高层需求（自尊和自我实现）进行 激励
34
期望理论（Expectancy Theory）
人们在下列情况下能够受到激励并且出大量成果 相信他们的努力很可能会产生成功的结果 他们也相信自己会因为成功得到相应的回报
5
团队管理的特点
针对临时性 着重团队性 适应项目生命期
6
本章要点
一、团队管理的基本概念 二、团队管理过程
项目经理的确定和任务 项目组织形式的确定 项目团队的建设 沟通管理
三、案例分析
7
项目经理的角色
1. 项目组织的领导者 2. 项目组织的管理者 3. 项目组织的决策者 4. 项目组织的分析者 5. 项目组织的计划者 6. 项目组织的控制者 7. 项目组织的组织者 8. 项目组织的评价者 9. 项目组织的协调者
协作 4. 行政隶属关系使得项目经理没有充分的权利
15
项目型
16
项目型优点
1. 项目经理对项目可以负全责 2. 项目目标单一，可以以项目为中心,有利于项
目顺利进行 3. 避免多重领很导 4. 组织结构简单，交流简单,快速
0
承启上课
项目计划
进度计划—核心计划 质量计划 配置计划 风险计划 。。。
辅助计划
1
RoadMap
合同管理 需求管理 生存期 任务分解 规模估算 项目进度
质量计划 配置计划 风险计划 团队管理 项目度量
集成项目 跟踪控制 项目结束
2
软件开发项目管理
第十一章 软件项目团队管理
33
麦克勒格的 Y －理论
如果给予适当的激励和支持性的工作氛围，会 达到很高的绩效预期
具有创造力，想象力，雄心和信心来实现组织 目标
能够自我约束，自我导向与控制，渴望承担责 任
用马斯洛的高层需求（自尊和自我实现）进行 激励
34
期望理论（Expectancy Theory）
人们在下列情况下能够受到激励并且出大量成果 相信他们的努力很可能会产生成功的结果 他们也相信自己会因为成功得到相应的回报
5
团队管理的特点
针对临时性 着重团队性 适应项目生命期
6
本章要点
一、团队管理的基本概念 二、团队管理过程
项目经理的确定和任务 项目组织形式的确定 项目团队的建设 沟通管理
三、案例分析
7
项目经理的角色
1. 项目组织的领导者 2. 项目组织的管理者 3. 项目组织的决策者 4. 项目组织的分析者 5. 项目组织的计划者 6. 项目组织的控制者 7. 项目组织的组织者 8. 项目组织的评价者 9. 项目组织的协调者
协作 4. 行政隶属关系使得项目经理没有充分的权利
15
项目型
16
项目型优点
1. 项目经理对项目可以负全责 2. 项目目标单一，可以以项目为中心,有利于项
目顺利进行 3. 避免多重领很导 4. 组织结构简单，交流简单,快速
软件项目质量管理ppt课件
持续性改进质量 • 认为，提高劳动生产率和降低成本的唯
一途经是提高质量
精品课件
16
Deming: PDCA Cycle
• 计划 Plan，分析现状；找出存在问题的 原因；分析产生问题的原因；找出其中 主要原因；拟订措施计划
• 执行 Do，执行技术组织措施计划
• 检查 Check， 把执行的结果与预定目标 对比
精品课件
9
质量理念的发展：适应性质量
• 适用性质量，20世纪60年代，适合顾客 需要的程度作为衡量的依据，从使用的 角度定义产品质量
• 从“符合性”到“适用性”，反映了人 们在对质量的认识过程中，已经开始把 顾客需求放在首要位置
精品课件
10
质量理念的发展：满意性质量
• 满意性质量，20世纪80年代，质量管理 进入到TQM阶段，将质量定义为“一组 固有特性满足要求的程度”。它不仅包 括符合标准的要求，而且以顾客及其他 相关方满意为衡量依据，体现“以顾客 为关注焦点”的原则。
14.改革是工作的一部分，每个人都要为改 进做出贡献
精品课件
24
软件质量的7个致命问题
1. 缺少对系统满足用户要求进行计划的坚定目标，对软 件开发人员 Nhomakorabea用命令式管理
2. 关注短期进度，这会扼杀质量
3. 绩效考核，年度评审。这种方式毁坏员工，进而扼杀 质量
4. 软件专业人员和经理的流动性，员工流动对制定目标 和建立组织知识体系很有害
5. 单纯依赖可见的数字管理
6. 过高的人力成本。由于低效的开发过程和高人员流动 率，软件开发的人员成本非常高
7. 过高的维护成本。由于设计不好，开发中的缺陷以及
维护工作差使得整个生命周期的成本居高不下
一途经是提高质量
精品课件
16
Deming: PDCA Cycle
• 计划 Plan，分析现状；找出存在问题的 原因；分析产生问题的原因；找出其中 主要原因；拟订措施计划
• 执行 Do，执行技术组织措施计划
• 检查 Check， 把执行的结果与预定目标 对比
精品课件
9
质量理念的发展：适应性质量
• 适用性质量，20世纪60年代，适合顾客 需要的程度作为衡量的依据，从使用的 角度定义产品质量
• 从“符合性”到“适用性”，反映了人 们在对质量的认识过程中，已经开始把 顾客需求放在首要位置
精品课件
10
质量理念的发展：满意性质量
• 满意性质量，20世纪80年代，质量管理 进入到TQM阶段，将质量定义为“一组 固有特性满足要求的程度”。它不仅包 括符合标准的要求，而且以顾客及其他 相关方满意为衡量依据，体现“以顾客 为关注焦点”的原则。
14.改革是工作的一部分，每个人都要为改 进做出贡献
精品课件
24
软件质量的7个致命问题
1. 缺少对系统满足用户要求进行计划的坚定目标，对软 件开发人员 Nhomakorabea用命令式管理
2. 关注短期进度，这会扼杀质量
3. 绩效考核，年度评审。这种方式毁坏员工，进而扼杀 质量
4. 软件专业人员和经理的流动性，员工流动对制定目标 和建立组织知识体系很有害
5. 单纯依赖可见的数字管理
6. 过高的人力成本。由于低效的开发过程和高人员流动 率，软件开发的人员成本非常高
7. 过高的维护成本。由于设计不好，开发中的缺陷以及
维护工作差使得整个生命周期的成本居高不下
软件项目管理课程课件-完整版
三．软件工程模型
所有软件工程的活动都必须进行管理。 软件项目管理贯穿于软件工程的演化过程。 软件工程的演化过程：
三．软件工程模型
软件工程模型: 组织软件工程活动的方 法，称为软件工程模型。
软件工程模型是用一定的流程将各个活 动连接起来，并可用规范的方式操作全 过程，如同工厂的生产线。
常见模型有线性、快速原型、螺旋、渐 增式等模型。
常见的软件工程模型
线性模型（也称，瀑布模型，顺序模型）
常用的软件工程模型
螺旋模型 可看成是连接的线性模型
常用的软件工程模型
渐增式模型（增量模型）
常用的软件工程模型
渐增式模型首先构建系统的基本轮询回 路：
1.2项目管理
一．项目与项目管理
１．项目的概念及特点 项目：是指在一定约束条件下具有特定目标的一
一个次里程碑。
各阶段特点
为实现整个项目的某个特定状态，每个阶段都要进 行足够次数迭代。
各阶段的工作产品（制品，文档等），同时进化产 生，但每个阶段都有一个主要焦点： 初始阶段 需求 （生命周期目标里程碑） 细化阶段 设计 （生命周期构架里程碑） 构造阶段 实现 （初始的可操作能力里程碑） 移交阶段 实施 （产品发布里程碑） （这里的模型是渐增式（增量式））
管理科学用于计划、资源、质量、成本 等管理。
二．软件工程框架
软件工程目标 软件工程活动 软件工程原则
软件工程框架
软件工程目标
正确性－－软件产品达到预期功能的程 度。
可用性－－软件基本结构、实现、文档 为用户可用的程度。
合算性－－具有经济效益，即开发、运 行的开销满足用户要求的程度。
软件工程活动---生产软件步骤
问题定义－－明确要解决的问题 可行性分析－－即定义的问题是否有解决的办
软件项目成本管理教材(PPT 39张)
PV=FV/（1+R）n PV—现值 FV—将来值 R—利率 n—时间周期
3.3 成本估算与预算
项目选择与经济术语
经济学术语
可变成本：随生产量和工作量而变的成本，比如：物料、 工资、供应品等； 固定成本：不随生产量和工作量而变的非重复成本，比如： 设置费、租赁费等； 直接成本：直接可以归属到项目工作的成本，比如：项目 成员工资、差旅费、项目用物料等； 间接成本：一般管理费用，或几个项目的公摊费用成本， 比如：税金、保安费等； 沉淀成本：已经花费的成本，对项目下一阶段的活动估算 时不用考虑的成本； 机会成本：选择一个项目后，所放弃的最佳收益项目的成 本；
CPI=800/900=0.89 意味着：每花1元产生的工作价值是0.89元 SPI=800/1000=0.8 意味着：实际进度是计划进度的90%
3.4 项目成本控制
两个完成指数
3.3 成本估算与预算
成本估算的依据
工作分解结构 资源需求计划 工作延续时间 资源的基础成本 历史资料 会计科目表
3.3 成本估算与预算
成本估算的依据
工作分解结构 资源需求计划 工作延续时间 资源的基础成本 历史资料 会计科目表
3.3 成本估算与预算
成本估算的过程
完成项目活动所需资源的成本 投资回报率(ROI),贴现现金流量
3.3 成本估算与预算
会计体系
财务会计—与债权人有关的所有财务事务， 资产负债表和现金流量表是财务的主要报表 管理会计—通常使用财务会计分析公司状况， 以便为管理决策提供依据 项目会计—应用会计体系统中的信息，并将 这些信息与项目管理具体术语，如WBS、挣 值、结合起来。
软件项目开发PPT课件
精选ppt
[ 通过复审 ]
[ 未通过复审 ]
36
2.6 实施活动
• What
– 编码：是将软件设计结果转换成用某种程 序设计语言书写的程序。
– 单元测试：是把一个模块作为独立的程序 单元进行测试，以保证它能够正确执行规 定的功能。
• 1968年NATO软件工程会议首次提出软件工程 概念
• 1968-2013, 近40多年
– “危机”一词
– 软件危机依然存在
精选ppt 5
1.2 为什么要软件工程
• 软件危机面对的问题
– 艺术 vs. 标准化 – 错误的发现 – 软件需求获取 – 软件支持和维护 – 开发速度 vs. 市场需求 – 开发周期过长、开发成本过高 – 研发风险 – 软件开发中的复杂的协作(人员,问题,过程) – 不同角色的软件神话(管理者,用户,开发者,大众)
精选ppt 33
2.5 设计活动
• When
– 项目的中、早期阶段？
工作量
大
小 早期
中期
后期
贯穿于整个软件开发过程的设计活动
项目 时间
精选ppt 34
2.5 设计活动
• Who
– 主要包括架构设计师、软件设计员、复用 工程师、设计复审员、项目经理、财务人 员、软件质量保证（SQA，Software Quality Assure）人员和需求变更者等
• How
网罗需求
entry/ 工作上下文范围 entry/ 领域知识和可重用的需求 do/ 获取涉众的原始需求 exit/ 建立原始需求记录 who/系统分析师、需求阐释者、 客户代表、用户等
定义系统
do/ 分析系统需求 exit/ 制定软件需求文档 exit/ 改进业务词汇表 who/系统分析师、需求阐释者等
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
（若批 准）版 本更新
装变更
chapter_10
29
变更实现
变更实现
受
变
控 基 线 出
更 实 现
库
实
实
受
现 的 测 试 和 验
现 被 承
控 基 线 入
认
库
证
chapter_10
30
变更控制系统-举例
chapter_10
31
4、配置审计
配置管理活动审核 基线审核
chapter_10
32
5、配置状态统计
#1
B 2U4G _ 2
BRANCH
3、基线变更管理过程
基线修改应受到控制，这种变化要经SCCB授权， 按程序进行控制并记录基线修改的过程。
chapter_10
25
基线变更系统
配置控制
变更请求
变更评估
变更批准/ 拒绝
变更实现
chapter_10
26
项目名称 变更申请人
变更题目
变更请求
提交时间 紧急程度 变更具体内容
配置管理 配置项 基线 SCCB
二、软件项目配置管理过程 三、软件项目配置管理计划 四、案例分析
chapter_10
4
配置管理简述
记录软件产品的演化过程 确保软件开发者在软件生命周期中的各个阶段
都能得到精确的产品配置。 最终保证软件产品的完整性、一致性、追朔性、
可控性
chapter_10
5
配置管理的作用
23
配置库
1 2 3
4 5 6
7 MAIN BRANCH
RELEASE 1.0
1
2
3
4
RELEASE 1.1
RELEASE 2.0
WINDOWS NT BRANCH
1 2 3
4 PATCH #2
M AcIhaNpTteEr_N1A0N C E
BRANCH
1 2
BUG_1 BRANCH
1 PATCH
软件配置项是项目需定义其受控于软件配置管 理的款项。每个项目的配置项也许会不同。
chapter_10
8
软件配置项举例
系统规格说明书 软件需求规格说明书 设计规格说明书 源代码 测试规格说明书
chapter_10
9
配置项的版本
需求规格:
配置项类
配置项实例
需求规格V1.1
需求规格V1.2
chapter_10
18
配置项的标识
配置项被唯一的标识
chapter_10
19
配置项的标识约定举例
公司：3个字符 项目：最长10个字符 类型：最长5个字符 编号：最长8位数字 版本号：V m.n
QTD-School–RM–SRS-v1.0
chapter_10
20
配置项的跟踪
案例
chapter_10
chapter_10
13
本章要点
一、软件项目配置管理基本概念 二、软件项目配置管理过程 三、软件项目配置管理计划 四、案例分析
chapter_10
14
基本活动
配置标识
变更控制
状态统计
配置审计
chapter_10
15
配置管理的基本过程
1. 配置项标识、跟踪 2. 配置管理环境建立 3. 基线变更管理 4. 基线审核 5. 配置状态统计 6. 配置管理计划
检查配置管理系统以及内容， 检测配置项变更历史
chapter_10
33
IEEE标准828-1998规定用于计算 配置状态的最小数据集包括
被批准的配置项 配置项的所有请求的变化状态 配置项所有被批准的变更实现状态
软件需求规格说明 软件设计说明
源代码 测试计划、过程、数据
可运行系统
chapter_10
12
SCCB (Software Configuration Control Board)
配置控制委员会(SCCB)
评估变更 批准变更申请 在生存期内规范变更申请流程 对变更进行反馈 与项目管理层沟通
21
2、配置管理环境建立 建立配置管理库
软件配置管理库是用来存储所有基线配置项及 相关文件的等内容的系统，是在软件产品的整 个生存期中建立和维护软件产品完整性的主要 手段。
chapter_10
22
受控操作
Check in 评审/验证
受控库
Check out
变更控制 流程
新版本
chapter_10
软件开发项目管理
计算机与信息工程学院 朱平
chapter_10
0
前言
软件项目中是否遇到如下的问题
找不到某个文件的历史版本； 开发人员使用错误的版本修改程序 开发人员未经授权修改代码或文档； 人员流动，交接工作不彻底； 已修复的Bug在新版本中出现； 无法重新编译某个历史版本； 因协同开发中，或者异地开发，版本变更混乱
chapter_10
16
1、配置项标识、跟踪
将软件项目中需要进行控制的部分拆分成SCI 建立唯一的标识 建立相互间的对应关系，进行系统的跟踪和版
本控制，以确保项目过程中的产品与需求和规 格的要求相一致，
chapter_10
17
配置项的拆分例子
（某医疗网站）需求规格SCI 1. 辅助功能.doc 2. 性能.doc 3. 产品目录.doc 4. 医务管理.doc 5. 医疗专业区.doc 6. 首页.doc
chapter_10
需求规格V1.3
10
基线定义
基线提供了软件生存期中各个开发阶段的一个 特定点
一个(些)配置项形成并通过审核，即形成基线 基线标志开发过程一个阶段的结束和里程碑 基线修改需要按照正式的程序执行
chapter_10
11
软件开发各个阶段基线图示
系统工程
系统规格说明
需求分析 软件设计 程序编写 测试 系统提交
变更影响分析
变更确认
处理结果
签字
chapter_10
27
变更评估
变更评估
软
技
接
进
件
术
口
度
变
影
影
影
更
响
响
响
分
分
分
分
类
析
析
析
图9-11: 变更请求的评估 chapter_10
预 算 影 响 分 析
28
变更批准/拒绝
批准/拒绝变更
决 策
（若批 准）实 施变更
（若批 准）验 证变更
（若批 准）发 布、安
导致整个项目失败； … …
chapter_10
1
前言
软件项目进行中面临的一个主要问题是持续不 断的变化
有效的项目管理能够控制变化，以最有效的手 段应对变化,不断命中移动的目标。
chapter_10
2
软chapter_10
3
本章要点
一、软件项目配置管理基本概念
• Who am I? • Why am I here? • Why am I who I am? • Where do I belong?
chapter_10
6
配置管理的主要功能
版本管理 变更管理 其它
chapter_10
7
软件配置项: SCI software configration item