项目交付质量

持续改进
由休哈特提出并经戴明完善的计划-实施-检查-行动（PDCA）循环是质量改进的基础。另外诸如 全面质量管理（TQM）、和精益六西格玛等质量管理举措，也可以改进项目的管理质量及项目的 产品质量。常用六西格玛的过程改进模型包括马尔科姆· 波多里奇模型、组织级项目管理成熟度模 型（OPM3）和能力成熟度模型（CMMI）
4. ITO项目自身管理 请假问题 上班纪律问题 项目团队建设问题 项目团队协作问题
关于风险处理的办法建议
5. 质量管理计划 • 描述如何实施执行组织的质量政策 • 对计划进行评审，以确保决策是基于准确信息的（减少返工） • 计划可简可繁
6. 过程改进计划 • 2个目的：说明过程分析的步骤识别增值的活动 • 4个方面：过程边界，过程配置，过程测量指标，绩效改进目 标
鱼骨图:
又名因果图，是一种发现问题“根本原因”的分析方法，现代工商管 理教育将其划分为问题型、原因型及对策型鱼骨图等几类。_____石川
质量管理理论和工具 流程图：
又成过程图，用来显示在一个或多个输入转化成一个或多个输出的过程，所需要的步骤顺序和可 能分支
帕累托图：
是一种特殊的垂直条形图，用于识别造成大多数问题的少数重要原因
项目交付质量报告
何加辉 2014.11.08
目录
1.软件质量的风险点及影响 2.软件质量的定义和属性 3.软件质量的控制 4.控制软件质量的工具和理论 5.质量大师
风险点
自身风险点
1. 上班期间出去不打招呼
项目风险点
1. 需求模糊
2. 自身代码逻辑不严密
3. 不配合客户工作 4. 代码版本管理不得当 5. 随意修改生产数据
可用性 安全性 机密性
可维护性
质量与等级
工作的前提是确定要求
什么是要求？ 要求就是明示的、通常隐含的或必须履行的需求和期望 明示的
合同等明确规定的
必须履行的
法律法规等强制规 定的
要
通常隐含的
组织、顾客和其它相关 方的惯例或一般做法， 不言而喻的要求
求
客 户 相关利益方 管理制度
下道工序
工作中如何确定要求？
要明确
• •
要避免

在过程开始之前进行确定 在要求确定之前进行商讨， 确保达成一致
不清楚 遗漏 简化 忽视 错误
• •
确保相互理解 监督其变化
检验只能告知已发生的事情
• 太迟 – 缺陷已经产生 • • • • 会遗漏一些缺陷 不能直接产生符合项 影响正常的工作 增加成本，降低效率
预防才能实现低成本、高效率地满足要求！
该法则通常称为80/20原则，即80%的问题是由20%的原因 导致的。帕累托图也用于汇总各种类型的数据，并进行 80/20分析
质量管理理论和工具
检查表：
检查表又称调查表，统计分析表等。检查表是QC七大手法中最简单也是使用得最多的手法
控制图：
用来确定一个过程是否稳定，或者是否具有可预测的绩效,控制图(Control chart)就是对生产过程 的关键质量特性值进行测定、记录、评估并监测过程是否处于控制状态的一种图形方法。 根据假设检验 的原理构造一种图，用于监测生产过程是否处于控制状态。
质量管理理论和工具
散点图：
又称相关图，标有许多坐标点（X,Y），解释因变量Y相对于自变量X的变化。
质量管理理论和工具
标杆对照
参照其他相类似的项目，识别最佳实践
实验设计
统计抽样
其他质量工具
• • • • • 头脑风暴 力场分析 名义小组技术 质量管理和控制工具 会议
质量大师：
克劳士比
戴明（Deming）
管理层的责任
项目的成功需要项目团队全体成员的参与。然而，管理层在质量责任内。肩负着为项目提供具 有足够能力的资源的相应责任。
质量成本
质量成本指一致性成本和非一致性成本。
质量成本
质量管理理论和工具
PDCA(plan-Do-check-action)
循环又名戴明环，是美国质量管理专家休哈特博士首先提出的，由戴明采纳、宣传，获得普及， 它是全面质量管理所应遵循的科学程序。
关于风险处理的办法建议
什么是质量？
质量的定义就是符合要求， 而不是“好”。
——克劳士比
项目交付中的“好”
为什么质量不是“好”?
“好、优秀、美丽、独特”等 术语都是主观的和含糊的。 “用户界面友好”、“满足
客户 所有要求”、“客户100
％满意“
软件质量属性
功能
性能 软件质量 易用性 可信性
可靠性
质量管理三个标准化过程
如何做到预防
防患于未然


防止再发生

明确要求
制定科学合理的工作计划 作业标准化，按流程办事 ……
进行根因分析 针对根本原因制定解决措施 执行措施，从根本上解决问题 ……
百度文库
与一开始就没有问题相比，解决复杂问题的方案再具有原创性也没有多少乐趣。 《永续成功的组织》－－菲利普· 克劳士比
补充---质量的五个基本理念
客户满意
了解、评估、定义和管理要求，以便满足客户的期望。这就需要把“符合要求”（确保项目产 出预定的结果）和“适合适用”（产品或服务必须满足实际需求）想结合起来。
预防胜于检查
质量应该被规划和设计，并且在项目的管理过程或可交付成果产生过程中建造出来（而不是被 检查出来），预防错误的成本远远低于在检查或使用中发现并纠正错误的成本。
1. 代码没有注释
2. 项目团队沟通不彻底 3. 弱化需求 4. 项目经理管理不得当
风险控制不得当的影响
干系人（客户）不满意
时间成本增加
合同续约问题 公司涨价问题
…….
关于风险处理的办法建议
1. 每周周四，每组组员整理相关风险点和相关疑难问题，整理 给组长，由组长组织大家一起寻找解决问题办法 小组内解决 项目组解决 公司解决
2. 采用实验设计的方法——需求模糊
修改文档
根据初始需求制作DEMO 修改DEMO
与业务沟通
关于风险处理的办法建议
3. 配置管理的统一操作和后续操作
业务提出需求变更，不能口头提出，得由书面提出且由行方技术部门相 关负责人定夺 在修改代码时切记一定要同时修改文档，避免后续人员或者测试人员， 在处理问题时，不知道以什么地方的为准 代码注释
朱兰（Joseph H.Juran）
非根堡姆（Arnold V.Feigenbaum） 石川馨（Koaru Ishikawa） 田口原一(Genichi Taguchi) 沃尔特· 休哈特（Dr.W.A.Shewhart）