Table of Contents
- 1. 一、绪论
- 1.1. 软件的定义
- 1.2. 软件的特征
- 1.3. 软件危机产生的原因
- 1.4. 软件过程
- 1.5. 软件过程能力
- 1.6. 软件过程性能
- 1.7. CMM定义
- 1.8. CMM5各级别的内容和特征
- 1.8.1. 初始级
- 1.8.2. 可重复
- 1.8.3. 已定义
- 1.8.4. 已管理
- 1.8.5. 优化级
- 1.9. KPA定义
- 1.10. KPA结构（目标、共同特点）
- 1.10.1. KPA目标
- 1.10.2. KPA共同特点
- 1.11. CMM每个成熟度等级的KPA
- 1.11.1. 初始级KPA
- 1.11.2. 可重复KPA
- 1.11.3. 已定义KPA
- 1.11.4. 已管理KPA
- 1.11.5. 优化级KPA
- 2. 二、软件项目管理概述
- 2.1. 项目的定义
- 2.2. 项目的特征
- 2.3. 项目管理的概念
- 2.4. 项目管理的三要素
- 2.5. 项目管理的内容(9个: 4 + 4 + 1)
- 2.6. 项目管理的阶段划分(了解即可)
- 3. 三、需求分析
- 3.1. 需求的定义
- 3.2. 需求分析的过程
- 3.3. 需求规格说明书的要求(六点)
- 3.4. 需求变更管理的过程(8个步骤: 4+2+2)
- 4. 四、过程定义和过程裁剪
- 4.1. 过程的定义（了解）
- 4.2. 一般软件开发的子过程
- 4.3. 每个子过程的参加者
- 4.4. 子过程的五要素(2+2+1)
- 4.5. 过程裁剪的定义
- 4.6. 过程裁剪的分类(两类)
- 4.7. 概要裁剪可依据的项目特征
- 5. 五、过程数据库和过程能力基线
- 5.1. 软件度量的含义
- 5.2. 软件度量的作用
- 5.3. 过程数据库定义PDB
- 5.4. 过程数据库的数据
- 5.5. 过程能力基线定义PCB
- 5.6. 过程能力基线的数据
- 5.7. PCB数据项的计算方法
- 5.8. PDB的建立以及访问权限
- 5.9. 过程财富的含义
- 6. 六、工作量估计和进度安排
- 6.1. 软件规模的估计方法(代码行、功能点)
- 6.1.1. 代码行法
- 6.1.2. 功能点法
- 6.2. 功能点法估计软件规模的步骤
- 6.3. 自底向上的工作量估计方法步骤
- 6.4. 自顶向下的工作量估计方法步骤
- 6.5. COCOMO初级模型
- 6.5.1. COCOMO初级模型概述
- 6.5.2. 计算公式
- 6.6. COCOMO中级模型
- 6.6.1. COCOMO中级模型概述
- 6.6.2. 工作量调整因子EAF(Effort Adjustment Factor)
- 6.6.3. 计算公式
- 6.1. 软件规模的估计方法(代码行、功能点)
- 7. 七、质量计划和缺陷估计
- 7.1. 软件质量的定义
- 7.2. 缺陷注入和清除的环节
- 7.3. 质量管理的主要任务
- 7.4. 如何制定量化质量管理计划
- 7.4.1. 直接设定质量目标的方法
- 7.4.2. 直接设定缺陷注入率的方法
- 8. 八、风险管理
- 8.1. 风险的定义
- 8.2. 风险管理的含义
- 8.3. 风险管理的内容
- 8.4. 风险管理的目标
- 8.5. 风险管理的特点
- 8.6. 如何进行风险评估
- 8.7. 常见风险种类或类型
- 9. 九、项目管理计划
- 9.1. 项目管理计划定义
- 9.2. 项目管理计划的内容
- 9.3. 项目管理计划的主要使用者
- 10. 十、配置管理
- 10.1. 配置管理的概念
- 10.2. 配置管理包括的内容
- 10.3. 配置管理的功能
- 10.4. 配置管理的主要任务
- 10.5. 配置管理中如何执行变更申请
- 11. 十一、评审
- 11.1. 评审的功能和特点(5点)
- 11.2. 评审的过程
- 11.3. 评审分析指南(重要)
- 11.3.1. 缺陷少于正常
- 11.3.2. 缺陷多于正常
- 12. 十二、项目监督和控制
- 12.1. 项目监督和控制的主要活动
- 12.2. 数据采集的内容(3个方面 2个数据1个测量)
- 12.3. 项目跟踪的内容
- 12.4. 里程碑分析的内容(工作量/进度、测试性能)
- 12.4.1. 工作量、进度性能指南
- 12.4.2. 测试性能指南
- 12.5. 缺陷分析和预防的内容(两种分析方法)
- 12.5.1. 帕累托分析
- 12.5.2. 因果分析
一、绪论
软件的定义
是使计算机能够工作的指令集合和相关数据结构以及文档
是一种产品，发挥计算机的硬件能力，传递信息的工具，处理信息的手段
软件的特征
- 逻辑元素
- 开发而不是制造
- 不能被用坏
- 定制时代
- 创新型和个人因素
软件危机产生的原因
- 需求二义性、遗漏、错误
- 大型软件合作，系统复杂，如何组织协调发挥团队作用
- 缺乏工具和方法支持，依赖程序设计的技巧和创造性，加剧个性化；没有统一、规范的工具方法支持，
文档资料不齐全 - 缺乏相关经验和数据的积累，无法估计经费和进度，导致经费超支，工期一拖再拖
- 忽视测试阶段工作，提交产品质量差
软件过程
用于开发和维护软件，以及其相关过程的一系列活动(管理活动、工程活动)
软件过程能力
组织或者项目组遵循软件过程能够实现的*预期结果*
软件过程性能
组织或者项目组遵循软件过程所得到的*实际结果*
CMM定义
Capability Maturity Model for Software:
对于软件组织在 定义、实现、度量、控制、改善其软件过程的进程中各阶段的描述
CMM5各级别的内容和特征
初始级
软件过程是无序的，甚至是混乱的，没有什么是经过定义的
可重复
建立基本的项目管理过程去跟踪成本、质量、进度，必要的过程纪律已经就位，
可以重复类似项目的成功
已定义
管理活动和工程活动均已文档化和标准化，并集成到组织标准软件过程中。全部项目均采用组织标准软件
过程中一个经批准的普及剪裁版本
已管理
已采集详细的软件过程和产品质量的度量，过程和产品均得到了定量的认识
优化级
利用来自过程、新思想、新技术的先导性实验的定量反馈信息，使得持续的过程改进成为可能
KPA定义
识别出一串相关活动，全部完成时，能达到一组对增强过程能力至关重要的目标
KPA结构（目标、共同特点）
KPA目标
概括一个KPA中所有关键实践，用于确定一个组织是否有效实施该KPA
KPA共同特点
- 执行约定
- 执行能力
- 执行活动
- 测量、分析
- 验证实施
CMM每个成熟度等级的KPA
初始级KPA
无
可重复KPA
1.需求分析
2.项目策划
3.项目跟踪与监督
4.子合同管理
5.质量管理
6.软件配置管理
已定义KPA
- 组织过程焦点
- 组织过程定义
- 培训大纲
- 集成软件管理
- 软件产品工程
- 组间协调
- 同行评审
已管理KPA
- 定量过程管理
- 软件质量管理
优化级KPA
- 缺陷预防
- 技术改革管理
- 过程更改管理
二、软件项目管理概述
项目的定义
为创建某一独特的产品或者服务，在一定环境和约束条件下进行的
临时性努力
项目的特征
- 一个明确的范围和目标
- 一个预期完成时间
- 可以利用的资源
- 一个已定义的性能评估方法
- 不是例行任务
项目管理的概念
一定主体，为了实现目标，综合运用专门的知识、技能、工具、方法，
对执行中项目各阶段工作进行计划、组织、协调、控制，
以满足甚至超越项目干系人的需求和期望
项目管理的三要素
质量、进度、成本
项目管理的内容(9个: 4 + 4 + 1)
| 中文 | English |
|---|---|
| 范围管理 | Scope Management |
| 时间管理 | Time Management |
| 成本管理 | Cost Management |
| 质量管理 | Quality Management |
| 人力资源管理 | Human Resource Management |
| 通讯管理 | Communication Management |
| 风险管理 | Risk Management |
| 合同和采购管理 | Procurement Management |
| 项目综合管理 | Integration Management |
项目管理的阶段划分(了解即可)
- 项目规划
- 项目执行
- 项目收尾
三、需求分析
需求的定义
用户解决问题或达到目标所需要的条件或者权能(Capability)
需求分析的过程
- 准备阶段
- 采集、澄清需求
- 分析需求
- 准备SRS (Software Requirements Specification, 需求规格说明书)
- 评审SRS
- 客户认可并签署SRS
需求规格说明书的要求(六点)
正确性、无二义性、
完整性、一致性、
可测试性、可跟踪性
需求变更管理的过程(8个步骤: 4+2+2)
| No. | 过程步骤 |
|---|---|
| 1. | 记录变更 |
| 2. | 分析影响 |
| 3. | 估计变更工作量 |
| 4. | 重新估计交付时间表 |
| 5. | 执行累计成本影响风险 |
| 6. | 影响超出限度，与高级主管评审 |
| 7. | 客户不再提出变更申请 |
| 8. | 修改工作产品 |
四、过程定义和过程裁剪
过程的定义（了解）
遵照执行某些任务的一系列步骤，以及执行这些步骤的指南
开发过程是提炼用户需求，设计、构建和测试满足需求的软件并交付给客户的过程
一般软件开发的子过程
需求分析 -> 概要设计 -> 详细设计 -> 编码和单元测试 -> 集成测试 -> 系统测试 -> 验收测试和安装 -> 文档 -> 系统维护
每个子过程的参加者
| 子过程 | 参加者 |
|---|---|
| 需求分析 | |
| 概要设计 | 设计团队、评审团队、客户 |
| 详细设计 | 设计团队 |
| 编码和单元测试 | 项目组成员、项目经理 |
| 集成测试 | 集成测试团队 |
| 系统测试 | 系统测试团队 |
| 验收测试和安装 | 安装团队、客户、项目经理 |
| 文档 | // |
| 系统维护 | 安装团队、维护团队 |
子过程的五要素(2+2+1)
- 输入准则
- 输入
- 输出准则
- 输出
- 度量
过程裁剪的定义
调用组织标准过程的过程，以获得用于项目特定业务或技术需要的过程
过程裁剪的分类(两类)
- 概要裁剪指南
- 详细裁剪指南
概要裁剪可依据的项目特征
- 团队和项目经理的 经验、熟练程度
- 团队最大人数
- 需求透明度
- 项目持续时间
- 应用的关键程度
五、过程数据库和过程能力基线
软件度量的含义
量化地描述*软件过程*和*软件产品*不同方面的特点
软件度量的作用
- 项目计划
- 控制项目过程
- 分析和改进软件过程
过程数据库定义PDB
存放 从项目可获得的 过程性能数据的 数据库 (用于计划、估计、生产率和质量分析)
过程数据库的数据
- 项目特征
- 项目进度
- 项目工作量
- 项目规模
- 故障和风险
过程能力基线定义PCB
用 基线形式 量化地表示过程能力(有助于对过程进行分析和改进)
过程能力基线的数据
- 已交付软件的质量
- 生产率
- 进度计划
-
工作量分布
-
故障引入率
- 过程中故障排除率
-
故障分布
-
质量成本
PCB数据项的计算方法
| Data | Calculations | Meaning |
|---|---|---|
| F | 用功能点描述的软件规模 | |
| E | 总工作量(人月) | |
| D1 | 开发过程(提交前)发现的所有缺陷数 | |
| D2 | 提交后发现的缺陷数 | |
| D | D1 + D2 | 总缺陷数 |
| 生产率 | F / E | 功能点规模 / 工作量 |
| 质量 | D2 / F | 提交后缺陷数 / 功能点规模 |
| 缺陷注入率 | D / F | 平均每个功能点的缺陷 |
| 整体缺陷清除率 | D1 / D | 提交前检出的缺陷占总缺陷的比重 |
PDB的建立以及访问权限
- 建立: SEPG (Software Engineering Process Group, 软件工程过程小组)
- 项目经理可以阅读
过程财富的含义
- 组织标准软件过程
- 组织关键过程数据库／过程能力基线 (PDB and PCB)
- 软件生命周期描述
- 标准软件过程的裁剪指南和准则
- 软件有关文档
六、工作量估计和进度安排
软件规模的估计方法(代码行、功能点)
代码行法
| 优点 | 1. 不管用什么编程语言，都容易计算 |
| 2. 存在很多基于LOC的软件估算模型和文献数据 | |
| 3. 容易导出其他度量 | |
| 缺点 | 1. 只有在产品完成后才能计算 |
| 2. 依赖设计语言 | |
| 3. 不利于好的设计而产生短小程序 |
功能点法
| 编号 | 步骤内容 | 计算方法 |
|---|---|---|
| A | 计算未调整的功能点UFP | 确定输入、输出、查询、数据文件、界面元素数量和复杂度，计算功能点 |
| B | 计算技术复杂度因子TCF | 14个因子评估，并相加 TCF = F1 + F2 +… + F14 |
| C | 计算功能点 | FP = UFP * (0.65 + 0.01 * TCF) |
| D | 功能点与代码行的转换 | 根据 LOC/FP 表的内容计算 |
功能点法估计软件规模的步骤
- 计算 输入(4)、输出(5)、查询(4)、主控文件(10)、接口需求数目(10)
- 加权乘
- 根据复杂度的判断
自底向上的工作量估计方法步骤
| 步骤编号 | 步骤内容 |
|---|---|
| 1 | 确定系统中的程序，分为简单、中等、复杂(S/M/C) |
| 2 | 存在特定基线，从中构建 S/M/C 程序平均工作量 |
| 3 | 基线不存在，查找类似项目(类型、技术、语言)来定义S/M/C程序工作量 |
| 4 | 没有类似项目和特性基线，用通用过程能力基线定义S/M/C构建工作量 |
| 5 | 使用项目特定因素 改进S/M/C程序构建工作量 |
| 6 | 使用S/M/C构建工作量和被调用次数获得 总构建工作量和总工作量 |
| 7 | 给予项目特定的因素重新改进估计 |
自顶向下的工作量估计方法步骤
| 步骤编号 | 步骤内容 |
|---|---|
| 1 | 获得按照功能点计算的 软件规模估计 |
| 2 | 使用类似 过程类型的PCB生产率数据 或 PDB种类似项目的生产率数据 确定项目生产率级别 |
| 3 | 从生产率 和 规模 获得整体工作量估计 |
| 4 | 使用PCB获得的工作量分布数据 估计工作量 |
| 5 | 用项目的特定因素 修正估计 |
COCOMO初级模型
COCOMO初级模型概述
应用于中小规模项目进行快速又粗略的估计，将开发工作量作为软件规模函数进行计算
软件规模以代码行来表示
计算公式
注: a, b, c, d是不同项目的常数系数(考试会给出)
| Symbols | Calculation | Meaning |
|---|---|---|
| S | 代码行数(千行) | |
| E | a * S^b | 工作量估算(人月) |
| D | c * E^d | 开发时间估计(月) |
COCOMO中级模型
COCOMO中级模型概述
将软件开发工作量作为“软件规模”及“工作量调整因子EAF”的函数进行计算
精度有所提高
工作量调整因子EAF(Effort Adjustment Factor)
包括一组“成本驱动因子属性”值的评估，ci为成本驱动因子属性值，共四类15个，在六个等级上取值
计算公式
| Symbols | Calculation | Meaning |
|---|---|---|
| EAF | ci1 * ci2 *… * ci15 | 工作量调整因子 |
| E | a * S^b * EAF | 工作量估算(人月) |
七、质量计划和缺陷估计
软件质量的定义
已交付软件的故障密度
缺陷注入和清除的环节
| Process | In / Out |
|---|---|
| 需求分析 | 注入 |
| R | |
| 设计 | 注入 |
| R | |
| 编码 | 注入 |
| R | |
| 单元测试 UT | R |
| 集成和系统测试IT/ST | R |
| 验收测试AT | R |
质量管理的主要任务
规划合理的质量控制任务，然后正确地执行和控制它们，实现项目质量目标
如何制定量化质量管理计划
直接设定质量目标的方法
- 设定质量目标
- 估计规模
- 估计验收测试(AT)缺陷数
- 估计各阶段缺陷数
- 质量过程计划
直接设定缺陷注入率的方法
- 设定缺陷注入率(D/S)
- 估计规模S
- 估计总缺陷数D
- 估计验收测试缺陷数D2
- 质量过程计划
八、风险管理
风险的定义
可能发生的事件或条件，如果发生，对项目产生负面影响
风险管理的含义
试图使由于意外事件 导致项目失败的概率最小化
风险管理的内容
风险评估、风险管理
风险管理的目标
识别风险，最小化它们的影响
风险管理的特点
付出额外成本，价值不易度量
如何进行风险评估
确定风险 –> 风险分析 –> 风险等级划分
常见风险种类或类型
| 分类 | 原因 |
|---|---|
| 人员 | 人员流动 |
| 缺乏经验 | |
| 不充分的业务知识 | |
| 客户 | 需求变更过多 |
| 需求不清晰 | |
| 不能满足的性能需求 | |
| 管理 | 强加于项目的外部决策 |
| 不切实际的进度 | |
| 使用新技术 |
九、项目管理计划
项目管理计划定义
Project Management Plan (PMP):
项目经理承担的所有规划任务的核心，各规划任务的结果都出现在PMP中，
是指导所有项目执行的基准文档
项目管理计划的内容
1.项目概述
2.项目计划
3.项目跟踪
4.团队
项目管理计划的主要使用者
1.业务主管
2.项目经理
3.开发人员
十、配置管理
配置管理的概念
项目管理的一项内容，系统控制变更，建立和维护在项目的整个生存周期中 项目产品的完整性
配置管理包括的内容
1.标识 在给定时间点上 软件的配置
2.控制对配置项的更改
3.维护在整个软件生存周期 配置的完整性和可跟踪性
配置管理的功能
- 给出程序的状态
-
给出一个程序的最新版本
-
处理并发更新申请
- 取消一个变更
-
防止未经授权的变更或删除
-
提供需求变更申请 和 程序变更之间的可跟踪性
-
取消一个需求变更
-
显示相关变更
- 收集当前系统所有 源代码、文档和其他信息
配置管理的主要任务
a) 程序状态转移管理
b) 必须被实现的变更申请管理
配置管理中如何执行变更申请
- 接受 变更申请(影响分析之后)
- 建立跟踪机制
- 检出需要变更的配置项
- 执行变更
- 检入配置项
- 在整个生命周期 维护该配置项
十一、评审
评审的功能和特点(5点)
- 各阶段、各类型–范围广
- 比测试更有效率：问题本身>>征兆
- 不仅发现错误，提出改进意见，防止再发生
- 可在开发阶段进行，作者熟悉细节，及时修改
- 利于评审员、项目组熟悉有关产品
评审的过程
- 评审规划
- 准备和概述
- 评审会议
- 返工和后续措施
评审分析指南(重要)
缺陷少于正常
| Causes | Solutions |
|---|---|
| 产品非常简单 | 单人评审 |
| 没有仔细评审 | 重新安排评审 |
| 没有足够评审培训，或对评审材料经验不足 | 安排评审培训；安排其他队伍 |
| 产品质量高 | 确认事实，是否能够重现 |
缺陷多于正常
| Causes | Solutions |
|---|---|
| 产品
来源：jdjihaoyu2008 声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！
软件架构与组件
上一篇
2016年5月15日
学生成绩管理系统（六）：项目总结
下一篇
2016年5月16日
|