甲方软件项目管理与质量控制

需求中常见的问题与原因
・ 笼统需求 ・ 隐含需求 ・ 与已存在的限制条件
矛盾的需求 ・ 不完整的需求 ・ 乙方代劳的需求
・ 项目可行性分析研 究不深入
・ 不善于提需求
如何设计软件需求
GB/T 9385-1998计算机软件需求说明编制指南 总体要求
无歧性 完整性 可验证性 一致性
可修改性 可追踪性 运行和维护阶段的 可使用性
内容提要
1
软件需求分析阶段
2
软件开发设计阶段
3 软件开发编码及测试阶段
4
其他控制过程
5 第三方测试和项目后评估
项目开发过程中的其他控制过程
项目管理过程 -- 是否按照项目计划执行 / 是否
1
按照里程碑定义实施 / 是否采取项目监控措施
SQA过程 -- 是否有质量计划 / 是否开展管理
2
评审与技术评审活动 /是否有质量改进活动
单元测试方法
• 代码评审 / 选择关键代码进行审查
– 是否与需求相一致 – 是否符合编码规范 – 注释是否详细 – 可读性好
• 白盒测试
– 代码覆盖率评估 – 代码执行效率评估
集成测试的内容
• 测试穿越模块接口的数据是否丢失 • 测试各子功能组合起来后是否达到预期要求的父功能 • 测试一个模块是否对另一个模块产生不利的影响 • 测试全局数据结构是否有问题
•概要设计说明书 •详细设计说明书 •数据库设计说明书
设计阶段评审
• 分析设计是正确的、与需求一致并可追溯到需求 • 分析设计中的事件次序、输入、输出、接口、逻辑
流程、出错定义、错误处理 • 验证根据需求所选择的设计是否合理
设计阶段评审
• 概要设计阶段
– 是否生成概要设计说明书（含数据库设计说明书） – 同行评审：验证系统架构设计正确性及可行性
分析
设计 设计
编码
需求评审
设计评审
代码评审
单元 测试
软件 集成
集成 测试
各阶段测试
系统 测试
交付
对 项目管理 / 配置管理 / 缺陷管理 / 质量保证 相关活动进行监督与控制
第三方 全过程保证
软件项目开发过程中的角色
需求方（甲方）
第三方测试
监理方
开发商（乙方）
需求方在软件开发中的作用（1）
从合同观点：
• 详细设计阶段
– 详细设计说明书 – 每个模块、函数、接口的实现方法，输入参数、数据结
果说明等
Contents
内容提要
1
软件需求分析阶段
2
软件开发设计阶段
3 软件开发编码及测试阶段
4
其他控制过程
5 第三方测试和项目后评估
软件开发编码及测试阶段
•开发 •测试
软件开发编码 及测试阶段
编程评估标准 测试评估标准
SQA活动
• 技术评审
– 评审产品是否符合规格说明 – 评审产品是否完整 – 软件产品的开发、操作和服务是根据项目的计划、进度、
标准和指南进行的 – 对软件产品的改变是适当的
缺陷管理过程
• 软件缺陷（Defect）
狭义
软件中存在的错误，与预期属性的偏 离
广义
软件开发周期中存在的错误、问题以 及偏离
甲方
精确描述需要什么样的产品
乙方
准确理解甲方需要什么样的产品
明确规定产品的检验依据
第三方
需求的层次
业务
满足
任务
完成
软件功能
需求
需求的组织层机构次或客户对系统、 产品高层次的目标要求
业务
需求满评足审：评价业务需 求、用户需求、需求规
格任说务明的一致性
完成
软件功能
用户使用产品必须 要完成的任务
需求
开发人员必须实 现的软件功能
功能点缺陷率 ＝总缺陷数 / 总功能点数
测试缺陷趋势分析
缺陷的趋势分析 --按照测试执行的时间顺序，被发现的缺陷数量的分布
缺
陷
Bug curve
数
Bug Convergence point
Resolved curve
Zero Bug point
时间
开发过程中的文档
可行性研究报告 项目开发计划 软件需求说明书 数据要求说明书 测试计划 概要设计说明书 详细设计说明书 数据库设计说明书 用户手册 操作手册 维护修改建议 测试分析报告 开发进度月报 项目开发总结
甲方软件项目管理与 质量控制
国家应用软件产品质量监督检验中心 副主任：左家平
个人研究方向
• 信息系统架构设计 • 软件企业及实验室质量体系管理认证 • 国家信息技术标准编制 • 软件全过程质量保证解决方案设计 • 软件测试工具研究 • 。。。。。。
软件开发全过程控制与管理
项目
软件需求 软件结构 软件详细
缺陷生命周期中的角色及职责
修复bug 提交测试版本
领导者
跟踪所有bugbug的状态 协调和仲裁存在的问题
开发人员
测试人员
发现bug 报告bug 跟踪bug 确认bug
Status of Bug
Indication
Action Taken by Tester
Action Taken by Developer
开发商的过程能力
第三方检测机构 （以程序和软件文档的测
评为主）
监理机构
（以开发计划和软件文档 的检查为主）
软件项目管理目标（甲方）
质量控制
进度控制
成本控制
组织结构
人员要求
环境要求
Contents
内容提要
1
软件需求分析阶段
2
软件开发设计阶段
3 软件开发编码及测试阶段
4
其他控制过程
5 第三方测试和项目后评估
例子：需求问题记录表
Contents
内容提要
1
软件需求分析阶段
2
软件开发设计阶段
3 软件开发编码及测试阶段
4
其他控制过程
5 第三方测试和项目后评估
软件开发设计阶段
•开发 •测试
设计重要性
•形成软件框架 •软件开发的原形 •开发过程的指导
软件开发设计 阶段
设计评估标准 评估文档
•详细性 •准确性 •可验证性 •一致性 •可实现性
Action Taken by Communication
Pending
N Verif yY Fixed
N Confirm Y Closed
BEGIN
Bug reported
New
N Review
Y Open
N Assign
Y Assigned
Fix
缺陷处理流程
Not A Bug Duplicate Not Reviewed
软件需求描述
必须描述的基本问题
功能
性能
外部 接口
属性
需求基本问题
设计 限制
需求设计-典型案例
苹果 1个苹果 红苹果 带有心形图案的苹果 中间为实心心形图案 的苹果
20
需求设计
沟通
一致性分析
控制
指标
需求评审
大 小
协调
指标定义
r＝a(1-sin(sita)),x=rcos(sita),y=rsin(sita)
测试阶段数据采集与分析的目的
1
评估被测软件的质量
•缺陷的数量 •缺陷的种类
2
评估开发过程的质量
•缺陷的分布 •修复缺陷的时间 •回归测试时发现 的缺陷数量
3
评估测试工程师表现
•是否按计划完成 任务 •发现缺陷的数量
测试阶段主要采集数据
测试用例执行的进度 = 已执行的数目 / 总数目 缺陷的存活时间 = 缺陷从打开到关闭的时间 缺陷分布密度 = 对应于一项需求的总缺陷数 / 对应于该项需求的测试用例总数 缺陷修改质量 = 每次修改后发现的缺陷数量
计划
实施和 控制
评价和 确认
完成
开发方在软件开发中的作用（2）
从工程观点：
开发方 （乙方）
软件需求 软件结构 软件详细 分析 设计 设计
编码
单元 测试
软件 集成
集成 测试
系统 测试
交付
测试方在软件开发中的作用
企业/ 操作需求
功能需求
系统和接口 规格说明
详细设计
编码
测试和改正缺陷
产品
测试需求
测试标准功能需求 测试策略
缺陷管理过程 – 是否有缺陷管理系统 / 是否追
3
踪每个缺陷的状态 / 是否阶段性缺陷分析数据
配置管理过程 -- 软件有什么变更 / 谁做的变更
4
/ 什么时间做的变更 / 为何要变更
项目管理过程
项目监控
项目计划
1.是否在规定的时间内 细化了下一阶段计划 2.任务延迟是否能及时 调整项目计划 3.是否建立开发组织内 部的质量管理过程
需求方 （甲方）
可行性 研究
ຫໍສະໝຸດ Baidu
需求 招标 合同的准备 对乙方 验收和 定义 准备 谈判和修改 的监督 完成
开发方在软件开发中的作用（1）
从合同观点：
开发方
（乙方）
准备 投标
签订 合同
制定 计划
实施和 控制
评审和 评价
交付和 完成
需求方在软件开发中的作用（2）
从管理观点：
需求方 （甲方）
开始和 范围定义
可行性研究和计 划阶段
需求分析阶段
设计阶段
实现阶段
测试阶段
运行与维护阶段
文档验收
文档审查
用户文档编写的规范性
用户文档的全面性
用户手册内容的完整性
一致性检查 用户手册对关键操作有无例图文说明，
例图的易理解性如何 主要功能和关键操作的应用
实例数量及详细程度 用户手册包装的商品化程度和印刷质量
Contents
需求评审的主要内容
• 是否生成软件需求规格说明书 • 所提出的需求的技术可行性 • 需求是否可测 • 需求规格说明书内容完整 • 评价用户需求与需求规格说明书的一致性 • 是否有需求管理过程
需求评审
• 分层次评审 • 正式评审与非正式评审结合 • 分阶段评审 • 建立标准的评审流程 • 做好评审后的跟踪工作 • 充分准备评审 • ……
项目过程中监控
1.项目启动检查 2.是否建立支持过程 3.开发进度例会 4.开发进度周报/月报
SQA活动
• 管理评审
– 应当结合项目计划、时间表、标准和指南评价项目的状 态，进行改进活动
– 依据计划对过程、产品和服务的状态进行评价 – 通过充分的分配资源来保持对项目的全面控制 – 改变项目的方向或确定改变计划的必要性
•需求 •开发
•测试
软件需求分析阶段
需求重要性
•软件开发的基础
•开发过程的依据 •开发管理过程的依据 •用户接收的依据 •测试的依据
需求评估标准 评估文档
•无歧性
•完整性 •可验证性 •一致性 •可修改性 •可追踪性 •运行和维护阶段 的可使用性
需求分析阶段
•软件需求说明书 •数据要求说明书
需求的作用
软件配置管理的重要性
• 使软件产品变为受控的，控制以下问题
– 软件有什么变更？（WHAT） – 谁做的变更？（WHO） – 什么时间做的变更？（WHEN） – 为何要变更？（WHY）
– 软件将在什么时间发布 – 当前发布版本中有哪些功能，由哪些组件构成 – 当前版本中加入了针对哪些Bug的修改 – 软件的某个修改是谁认可的 – 如何建立新的发布版本
Defer
No Plan To Fix
N Deferred or Rejected
Y
Deferred
Rejected
48
•被测功能不能正确实现 •被测数据处理错误
•软件错误导致数据丢失 •用户需求未实现
缺陷的分类
•一般性的错误 S3
S2
严重等级
S1 S5
S4
•导致系统崩溃 •导致程序模块丢失 •主业务流程出现断点 •内存泄漏 •导致死机
•建议性问题
•细小的错误
低 优先级
中
高
沟通的重要手段-- Bug Triage会议
领导层
组织
管理
协调
仲裁
开发人员
测试人员
软件配置管理过程
• 缺乏配置管理造成的常见问题 – 组织的知识和过程财富流失 – 不能及时了解项目的进展状况 – 缺乏实现并行开发的手段 – 软件复用率低下 – 无法开展规范化的测试工作 – 对软件版本的发布缺乏有效的管理 – 缺乏历史数据的积累，没有软件开发的历史数据 – 无法有效的管理和跟踪变更
系统测试及验收测试
• 系统确认测试 – 对比需求规格说明书、测试计划中的系统测试 环境是否与实际的测试环境一致 – 确认系统实现功能与需求规格说明书是否一致
• 验收内容 – 所有文档、代码
• 系统验收测试策略 – 根据已定义的策略和准则进行验收 – 委托第三方检测机构进行验收
最佳实践
• 每日编译与BVT（冒烟测试） • Microsoft以缺陷为核心的开发流程
评估文档 其他评估
•程序编写按照里程碑完成 •使用界面的设计和验证 •用户使用文档内容的确定
•测试计划的完成和执行 •完成单元/集成/系统测试 •完成回归测试 •完成纠正关键缺陷 •完成文档测试
•用户文档 •操作手册
•系统安装和部署计划确定 •售后服务系统计划完成
单元测试内容
・ 检查模块算法的逻辑正确性 ・ 输入参数有没有做正确性检查 ・ 重要的执行路径的正确性 ・ 错误处理的路径的正确性 ・ 异常处理 ・ 边界条件的正确性 ・ 模块接口的正确性 ・ 调用其他模块的接口的正确性 ・ 检查常量或全局变量使用的正确性 ・ 程序风格的一致性、规范性 ・ 检查内部注释是否完整
KPA 1 – 测试计划编 制
测试计划
KPA 2 – 测试开发
测试用例
KPA 3 – 测试环境准备
应用软件质量生命周期
KPA 7 – 质量管理
KPA 4 – 测试执行
测试结果
测试报告
KPA 5 – 测试结果分析 KPA 6 – 编制报告
第三方软件测试
监理机构和第三方检测机构的关系
软件质量
内部质量特征 外部质量特征