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

软件开发编码及测试阶段
其他控制过程
第三方测试和项目后评估
软件开发编码及测试阶段
•开发 •测试 编程评估标准
•程序编写按照里程碑完成 •使用界面的设计和验证 •用户使用文档内容的确定
测试评估标准
•测试计划的完成和执行 •完成单元/集成/系统测试 完成单元/集成/ •完成回归测试 •完成纠正关键缺陷 •完成文档测试 •用户文档 •操作手册
需求分析阶段
设计阶段
实现阶段
测试阶段
运行与维护阶段
文档验收
用户文档编写的规范性
用户文档的全面性
用户手册内容的完整性
文档审查
一致性检查 用户手册对关键操作有无例图文说明， 例图的易理解性如何 主要功能和关键操作的应用 实例数量及详细程度 用户手册包装的商品化程度和印刷质量
Contents
内容提要
1 2 3 4 5
需求评估标准
评估文档
需求分析阶段
•软件需求说明书 •数据要求说明书
需求的作用
精确描述需要什么样的产品
甲方
乙方
准确理解甲方需要什么样的产品
第三方
明确规定产品的检验依据
需求的层次
业务
满足
任务
完成
软件功能
需求
需求的层次 组织机构或客户对系统、
产品高层次的目标要求
业务
满足 需求评审：评价业务需 求、用户需求、需求规 格说明的一致性 任务 完成
设计阶段评审
• 概要设计阶段
– 是否生成概要设计说明书（含数据库设计说明书） – 同行评审：验证系统架构设计正确性及可行性
• 详细设计阶段
– 详细设计说明书 – 每个模块、函数、接口的实现方法，输入参数、数据结 果说明等
Contents
内容提要
1 2 3 4 5
软件需求分析阶段 软件开发设计阶段
软件需求分析阶段 软件开发设计阶段
软件开发编码及测试阶段
其他控制过程
第三方测试和项目后评估
项目开发过程中的其他控制过程
1
项目管理过程 -- 是否按照项目计划执行 / 是否 按照里程碑定义实施 / 是否采取项目监控措施
2
SQA过程 -- 是否有质量计划 / 是否开展管理 评审与技术评审活动 /是否有质量改进活动 是否有质量改进活动
缺陷生命周期中的角色及职责
跟踪所有bug bug的状态 协调和仲裁存在的问题
领导者
修复bug bug 提交测试版本
开发人员
测试人员
发现bug bug 报告bug bug 跟踪bug bug 确认bug bug
BEGIN Bug reported
缺陷处理流程
Not A Bug N
Status of Bug
监理机构和第三方检测机构的关系
软件质量
内部质量特征 外部 外部质量特征 特
第三方检测机构 （以程序和软件文档的测 评为主） 监理机构 （以开发计划和软件文档 的检查为主）
开发商的过程能力
软件项目管理目标（甲方）
质量控制
进度控制
成本控制
组织结构
人员要求
环境要求
Contents
内容提要
1 2 3 4 5
评估文档
软件开发编码 及测试阶段
其他评估
•系统安装和部署计划确定 •售后服务系统计划完成
单元测试内容
・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ 检查模块算法的逻辑正确性 输入参数有没有做正确性检查 重要的执行路径的正确性 错误处理的路径的正确性 异常处理 边界条件的正确性 模块接口的正确性 调用其他模块的接口的正确性 检查常量或全局变量使用的正确性 程序风格的一致性、规范性 序 格的 致性 性 检查内部注释是否完整
测试阶段主要采集数据
测试用例执行的进度 = 已执行的数目 / 总数目
缺陷的存活时间 = 缺陷从打开到关闭的时间 缺陷分布密度 = 对应于一项需求的总缺陷数 对应于 项需求的总缺陷数 / 对应于该项需求的测试用例总数 缺陷修改质量 = 每次修改后发现的缺陷数量
功能点缺陷率 ＝总缺陷数 / 总功能点数
3
缺陷管理过程 – 是否有缺陷管理系统 / 是否追 踪每个缺陷的状态 / 是否阶段性缺陷分析数据
4
配置管理过程 -- 软件有什么变更 / 谁做的变更 / 什么时间做的变更 / 为何要变更
项目管理过程
项目监控
项目计划
1.是否在规定的时间内 1 是否在规定的时间内 细化了下一阶段计划 2.任务延迟是否能及时 调整项目计划 3.是否建立开发组织内 是否建立开发组织内 部的质量管理过程
其他控制过程
第三方测试和项目后评估
软件开发设计阶段
•开发 •测试 设计重要性
•形成软件框架 •软件开发的原形 •开发过程的指导
设计评估标准
•详细性 •准确性 •可验证性 •一致性 致性 •可实现性
评估文档
•概要设计说明书 •详细设计说明书 •数据库设计说明书
软件开发设计 阶段
设计阶段评审
• 分析设计是正确的、与需求一致并可追溯到需求 • 分析设计中的事件次序 输入 输出 接口 逻辑 分析设计中的事件次序、输入、输出、接口、逻辑 流程、出错定义、错误处理 • 验证根据需求所选择的设计是否合理
测试缺陷趋势分析
缺陷的趋势分析 --按照测试执行的时间顺序，被发现的缺陷数量的分布
缺 陷 数 Bug curve
Bug Convergence point
Resolved curve
Zero Bug point
时间
开发过程中的文档
可行性研究和计 划阶段 可行性研究报告 性 究 告 项目开发计划 软件需求说明书 数据要求说明书 测试计划 概要设计说明书 详细设计说明书 数据库设计说明书 用户手册 操作手册 维护修改建议 测试分析报告 开发进度月报 项目开发总结
单元测试方法
• 代码评审 / 选择关键代码进行审查
– – – – 是否与需求相一致 是否符合编码规范 注释是否详细 可读性好
• 白盒测试
– 代码覆盖率评估 – 代码执行效率评估
集成测试的内容
• • • • 测试穿越模块接口的数据是否丢失 测试各子功能组合起来后是否达到预期要求的父功能 测试一个模块是否对另一个模块产生不利的影响 测试全局数据结构是否有问题
软件需求分析阶段 软件开发设计阶段
软件开发编码及测试阶段
其他控制过程
第三方测试和项目后评估
软件需求分析阶段
•需求 •开发 •测试 需求重要性
•软件开发的基础 •开发过程的依据 •开发管理过程的依据 •用户接收的依据 •测试的依据 •无歧性 •完整性 •可验证性 •一致性 •可修改性 •可追踪性 •运行和维护阶段 的可使用性
测试需求
功能需求 测试标准
测试策略
KPA 7 – 质量管理
KPA 1 – 测试计划编 制
测试计划 测试用例
KPA 2 – 测试开发 KPA 3 – 测试环境准备
KPA 4 – 测试执行
测试结果
KPA 5 – 测试结果分析
测试报告
应用软件质量生命周期
KPA 6 – 编制报告
第 方软件测试 第三方软件测试
缺陷的分类
•导致系统崩溃 导致系统崩溃 •导致程序模块丢失 •主业务流程出现断点 •内存泄漏 •导致死机
S2 S1
•一般性的错误 S3
严重等级
S5 •建议性问题 建议性问题 S4
•细小的错误
优先级
低
中
高
沟通的重要手段-沟通的重要手段 Bug Triage会议
需求方在软件开发中的作用（1）
从合同观点：
需求方 （甲方）
可行性 研究
需求 定义
招标 准备
合同的准备 谈判和修改
对乙方 的监督
验收和 完成
开发方在软件开发中的作用（1）
从合同观点：
开发方 （乙方）
准备 投标
签订 合同
制定 计划
实施和 控制
评审和 评价
交付和 完成
需求方在软件开发中的作用（2）
从管理观点：
系统测试及验收测试
• 系统确认测试 – 对比需求规格说明书 测试计划中的系统测试 对比需求规格说明书、测试计划中的系统测试 环境是否与实际的测试环境一致 – 确认系统实现功能与需求规格说明书是否一致 确认系统实现功能与需求规格说明书是否 致 • 验收内容 – 所有文档 代码 所有文档、代码 • 系统验收测试策略 – 根据已定义的策略和准则进行验收 – 委托第三方检测机构进行验收
最佳实践
• 每日编译与BVT（冒烟测试） • Microsoft以缺陷为核心的开发流程
测试阶段数据采集与分析的目的
1
评估被测软件的质量
2
评估开发过程的质量
3
评估测试工程师表现
•缺陷的数量 •缺陷的种类
•缺陷的分布 •修复缺陷的时间 •回归测试时发现 的缺陷数量
•是否按计划完成 任务 •发现缺陷的数量
需求评审
软件结构 软件详细 设计 设计
设计评审 对
编码
代码评审
单元 测试
软件 集成
集成 测试
各阶段测试
系统 测试
交付
项目管理 / 配置管理 / 缺陷管理 / 质量保证 相关活动进行监督与控制
第三方 全过程保证 全过程保
软件项目开发过程中的角色
需求方 甲方） 需求方（甲方）
第三方测试
监理方
开发商（乙方）
无歧性 完整性 可验证性 一致性
可修改性 可追踪性 运行和维护阶段的 可使用性
必须描述的基本问题
软件需求描述
ห้องสมุดไป่ตู้
功能 性能
外部 接口