软件项目管理与质量保证概述

可回答的问题 它做了该做的事吗？
它总能准确地工作吗？
效率
程序实现其功能所需要的计算资源量
能在硬件上尽力工作吗？
安全性 使用性 维护性
软件或数据不受未授权人控制的程度 学习、操作程序、准备输入输出的工作量 对运行的程序找到错误并排除错误的工作量
它是安全的吗？ 它可用吗？ 它可调整吗？
测试性 灵活性 移植性 复用性 共运行性
0 0 70% 10
集成测试
24 0 50% 0
详细设计
2 1*1.5 50%
25
确认测试
12 0 50% 0
单元测试
5 10*3
25
60%
系统测试
6 0 50% 0
软件评审
技术工作需既要然评技审术评审这么好， 评审的目的是是不什是么？应该大量频繁
指出个人或的小进组行生产？的产品所需进行的改进
Fagan评审的基本原理
对于所有主要的交付物都要进行审查 所有类型的缺陷都要记录——不仅仅是逻辑或功能缺
陷 审查应该由除非常高层领导外的各级同事来执行 采用预先规定的步骤进行审查 审查会议不能超过两个小时 审查是由经过特殊技术培训的协调员来领导的 为其他参与者定义不同的角色 使用检查表来协助缺陷查找过程 检查材料的理想速度是每小时100行 维护统计数据，以便监督审查过程的有效性
样本间是有差异的！！
质量（2）什么样的软件是
与需软两求件设种用不需计不户符求高质同满就是量质的意是进设量质度质行量计的量“=质？不质高量量。”+符测量合的基础， 指定符的合合标质质格准量量产定？品义+了一组指导软件开发
的准则。如好果的不质能量遵+ 照这些准则，就极 有可能导致在质预量算不和高进。度表内交付
保 修故工障作成本
外部故障成本
预防总成本：
质量2成82,本120（美元2）
平均缺陷成本：
70既晚I5B然进39M差个1质行审美距小量质元查：时管量2，理管0维0结需理护0果要就0总05是成越成,行0预本省本0代0防：，钱,码0了那？0总03么美共1是元1用2不了个是越 潜在的缺陷5。00雇平0佣均00缺一0陷名/2成程8本2序：1员20的报酬 为40美=元17/.小7 时。 25,000美元
项目质量管理过程
分类 项目
质量计划编制
质量保证
项质目量方质针 量管质量理管理计划
输入 （依据）
范围说明 产品描述
标准和规则
质量控制测量结果 操作定义
其它过程输出
收益/成本分析 质量计划编制方法和技术
检验基准法
质量审计
方法和技术
流程图 试验分析设计
输出结果
质量管理计划 操作定义 检查表 其它过程输入
软件缺陷（3）
缺陷放大模型：
通过的错误 放大的错误1:x 新产生的错误
错误检测有效性百 分比
软件缺陷（4）
例：假设：
概要设计阶段生成10个错误 详细设计阶段生成25个错误，同时会放大
1/3的继承错误，放大系数为1.5 编码和单元测试阶段生成25个错误，同时会
放大2/3的继承错误，放大系数为3 在测试中可以发现并改正50%的错误，同时
测试种类
单元测试 集成测试 确认测试
功能测试 回归测试
α测试β测试 验收测试
软件测试（3）
测试方法
白盒测试 黑盒测试
软件测试（4）
测试类型
功能测试 性能测试 算法测试 正向测试 逆向测试 边界测试 配置测试 负载测试
软件测试（5）
测试计划
测试计划 测试用例 测试报告
项目管理与质量保证
软件质量保证
软件质量保证（SQA） ——引论
为什么要引入软件质量保证？
生产出高质量的软件 为了“在正确的时间、以正确的方式、做正
质确量的管事理情”的问题不在于人们不知 道什么是质量，问题在于人们认为 他们自己对质量知道…
质量（1）
什么是质量？ 差某产异一品遗控事或憾物 工制的的 作是是特 的：质征 优量或 劣控属 程制性 度的核心
评审总结报告内容：
评审什么 由谁评审 发现和结论是什么
正式技术评审（5）
正式技术评审的指导原则：
评审产品，而不是评审生产者 制定日程并且遵守日程 限制争论和辩驳 对各个问题都发表见解，但是不要试图解决所有记
录的问题 做书面笔记 限制参与者人数并坚持事先做准备 为每个可能要评审的工作产品建立一个检查表 为FTR分配资源和时间 对所有评审者进行有意义的培训 评审以前所做的评审
应该少于2小时 评审会议时间应该不超过2小时
正式技术评审（3）
每个FTR步骤：
确定参加评审的人员 人员培训 评审准备 分发评审材料，评审员审读评审材料 开评审会议 生成评审报告和问题列表
正式技术评审（4）
评审结论：
工作产品可以不经修改而被接受 由于严重错误而否决工作产品 暂时接受工作产品
质量提高
质量控制
工作结果 质量管理计划 操作定义 检查表
检查 控制图 帕累托图 统计抽样 流程图 趋势分析 质量提高 验收决定 返工 完成检查表 过程调整
软件质量保证 ——概述（1）
什么是软件质量保证？
Software Quality Assurance，简称SQA 一种应用于整个软件过程的庇护性活动
确定产品中不需要或者不希望改进的部分 得到与没有进行评审相比更加一致、或者至
少更可预测的技术工作的质量，从而使得技 术工作更小易于管理
为什么需要评审
在去除明显的错误时，审查是非常有效 的方法
鼓励开发人员产生结构更好的、不需要 加以说明的软件
能促进优秀编程实践的传播 能增进团队精神
正式技术评审（FTR）（1）
FTR想要达到什么目标？
在软件的任何一种表示形式中发现功能、逻 辑或实现的错误
证实经过评审的软件的确满足需求 保证软件的表示符合预定义的标准 得到以一种一致的方式开发的软件 使项目更易于管理
正式技术评审（2）
每个评审会议约束：
评审会议通常应该在3~5人之间进行 应该进行提前准备，但是每人占用工作时间
软件质量保证的范围？
软件产品质量 软件过程质量
软件质量保证 ——概述（2）
软件质量保证包含哪些内容？
一种质量管理方法 有效的软件工程技术 在整个软件过程中采用的正式技术评审 一种多层次的测试策略 对软件文档及其修改的控制 保证软件遵从软件开发标准的规程 度量和报告机制
软件质量保证 ——概述（3）
容错性 可恢复性 可靠性符合性
质量（6）
软件质量特性——易用性
可理解性 可学习性 可操作性 吸引性 可用性符合性
质量（7）
软件质量特性——效率
时间特性 资源利用 有效性符合性
质量（8）
软件质量特性——可维护性
可分析性
确定故障产生原因的容易程度
可变性
灵活性
稳定性
错误 总计
严重
一般
通常有一组“隐含需求”是不被提及的。 不符合的话软件质量也很难保证。
质量（3）
软件质量特性：
功能性
包括软件产品提供的用来满足用户需要的功能
可靠性
与软件维护其性能等级的能力相关
易用性
与使用软件所要花费的工作量相关
效率
与软件执行过程中所占用的物理资源相关
可维护性
与进行软件变更所需要的工作量相关
软件质量保证 ——SQA活动（2）
2. 参与开发该项目的软件过程描述 3. 评审各项软件工程活动、对其是否符合定义
好的软件过程进行核实 4. 审计制定的软件工作产品、对其是否符合定
义 好的软件过程中的相应部分进行核实 5. 确保软件工作及工作产品中的偏差已被记录
在案并根据预定规程进行处理 6. 记录所有不符合的部分并报告给高级管理者 7. 协调变更的控制和管理 8. 帮助收集和分析软件度量信息
统计软件质量保证
80%的缺陷
什么是统计软可件以质追量溯保到证？
是质量的量化所有可能原
统计软件质量因保中证的有20哪%些步骤？
收集和分类软件缺陷信息
尝试对每个缺陷的形成原因进行追溯
使用Pareto原则，将这20%（重要少数）分 离出来
一旦找到重要少数原因，就可以开始纠正引 起缺陷的问题
对软件修改的可能性
可测试性 可维护性符合性
质量（9）
软件质量特性——可移植性
适应性 可安装性 共存性
软件和其他软件分享资源的能力
可替代性 可移植性符合性
质量特性 含义
正确性 程序满足规格说明和完成用户业务目标的程 度
质量（10） 可靠性 程序按要求的精确度实现其预定功能的程度
为保证程序执行其规定的功能所需的测试工 作量 修改程序所需工作量 将程序从一个环境转移到另一环境的工作量
程序可被用于其他应用问题的程度
一系统与另一系统协同运行所需的工作量
它可测试吗？
它可修改吗？ 可以在其他机器上使用 吗？ 可以重复使用它的某些 部分吗？ 能与其他系统连接吗？
质量（11）
怎❖ 么正能确地保完证成质一量件？事情比解释你为
假设交付的产品中每1000行代码中
有1个缺陷，此时改正每个缺陷成本的
时间为25000美元。
质量成本（3）
改正一个错误的相对成本
需求分析阶段：1倍 设计阶段：3~6倍 编码阶段：10倍 开发测试阶段：15~40倍 系统测试阶段：30~70倍 实际操作阶段：40~1000倍
软件缺陷（1）
什 质么 质量将量未控事控制情经制做跟是错为踪所了的保花证的工每时作一间件要工少作产品都满 ❖ 人足 一们对 系等会它列于忘的审记没需查你求、做而评做！应审一用和！件于测工！整试作个有开发多周快期，中的
但他 质们量总控会制记在得创你建工做作得产有品多的好过程中包含一
个反馈循环
质量保证
质量保证由管理层的ຫໍສະໝຸດ Baidu计和报告功能构成
质量 内成部本故障（成1本） 返工
什么 修是复质量成本？
所有故由障模质式量分工析作或质者量进计行划与质量有关
外部的故活障动成所本导致的成正本式技术评审
解退求有 决 换 助预 鉴哪客 产 电防 定些户 品 话成 成质的支本本量抱持成怨本？ 内测培过设测部试训程备试故设内校障备和准成过 和本程 维间 护审查
可移植性
与把软件转换到不同环境的能力相关
质量（4）
软件质量特性——功能性
适合性
软件是否符合用户需要
准确性
软件是否正确地实现了功能
互操作性
软件和其他系统的交互能力
功能符合性
软件和需求的匹配程度
安全性
系统访问控制
质量（5）
软件质量特性——可靠性
成熟度
软件中缺陷所造成的故障的频率
软件测试（1）
软件的确认（Validation）和验证 （Verification），简称V&V
什么是确认？
在软件开发过程期间（针对单元）或结束 （针对系统）时，单元或系统是否满足用户 特定的需求？
什么是验证？
在一个给定的开发阶段中，单元或系统是否 满足在此阶段开始时确定的条件？
软件测试（2）
几个概念：
缺陷（defect） 故障（bug） 错误（error）
缺陷、故障：软件交付之后发现的质量 问题
错误：软件交付之前发现的质量问题
软件缺陷（2）
几个结论：
设计活动引入的错误占软件过程中出现的所 有错误（和最终的缺陷）数量的50%到65%
正式技术评审在发现设计错误方面最高达到 75%的有效性
可能的错误原因
规约不完整或规约错误（IES） 与客户通信中所产生的误解（MCC） 故意与规约偏离（IDS） 违反编程标准（VPS） 数据表示有错（EDR） 构件接口不一致（ICI） 设计逻辑有错（EDL） 不完整或错误的测试（IET） 不准确或不完整的文档（IID） 将设计翻译成程序设计语言中的错误（PLT） 不清晰或不一致的人机界面（HCI） 杂项（MIS）
SQ A那小些得组人到的应高职该为质责软量是件的辅质最助量终软负产件责品工？程小组
软件工程师 项目管理者
SQA小客 销组户 售人充员当客户在公司内部的代表
SQA小组成员
软件质量保证 ——SQA活动（1）
1. 为项目准备SQA计划
计划里应标识出什么？
需要进行的评价 需要进行的审计和评审 项目可采用的标准 错误报告和跟踪的规程 由SQA小组产生的文档 为软件项目组提供的反馈数量
不引入新的错误
概要设计阶段错误的改正成本为1，详细设 计时为1.5，测试前是6.5，测试中是15，发 布后是67
概要设计
0 0 0% 10
集成测试
94 0 50% 0
详细设计
6 4*1.5 0%
25
确认测试
47 0 50% 0
单元测试
10 27*3
25
20%
系统测试
24 0 50% 0
概要设计