软件质量保证-2013-06.pptxVIP

软件质量保证;引言 高质量的基础 基础1:软件包质量 基础2:维护方针 维护前的软件质??部件 维护合同评审 维护计划 维护的软件质量保证工具;软件维护 ;质量因素;度量一个可维护的程序的七种特性时常采用的方法有： 质量检查表——用于测试程序中某些质量特性是否存在的一个问题清单。 质量测试 质量标准;度量可维护性——可理解性;度量可维护性——可靠性;度量可维护性——可测试性;度量可维护性——可修改性;度量可维护性——可移植性;度量可维护性——效率;度量可维护性——可使用性;间接度量可维护性;澄清顾客需求 评审提供维护的替代方法 评审对所需维护资源的估计 评审由分包商和/或顾客提供的维护服务 评审维护费用估计;合同规定的维护服务的清单 维护组的组织描述 维护设施清单 已识别的维护服务风险清单 所需软件维护规程和控制的清单 软件维护预算;确立软件质量目标和优先级 质量因素之间相互促进又相互抵触。 根据程序的用途确定优先级 具体提高可维护性的方法有五个方面;一、使用提高软件质量的技术和工具;二、进行明确的质量保证审查;三、选择可维护的程序设计语言;四、改进程序的文档;五、开发软件时考虑到维护;引言 外部参与方的类型 引入外部参与方的风险与益处 保证外部参与方工作的质量:目标 保证外部参与方工作质量的SQA工具;HealthSoft案例;此外，MIS部将根据承包商的规格书采购并安装硬件与通信设备，负责同RedAid供货商的健康服务相接所需要的计算机接口协议，并教会RedAid人员操作新系统。 所有这些系统都要高度安全，对所有构件有高可靠性要求。系统在签订合同后不迟于13个月里全面运行，承包商对所有系统部件的质量和按时完成全面负责。 在开始编制RedAid投标协议书的时候，HealthSoft投标组就认识到他们需要擅长软件安全和数据通信的公司的专业支持。;预计编程工作量的规模使投标组决定要一个分包商承担60%~70%的编程工作量。Cape-Code是位于邻近郊区的一个很小的软件公司，基于该公司建议的最低价位被选定为编程分包商。 在编制建议书的时候，投标组发现广为使用的Medal第5版的新增强Medal Software的产品5E版包含了重要的新模块，这使得到了一些“喘息的机会”。这些用于病人信用的联机外部授权和用于为像RedAid这样的机构顾客编制月度账目的新模块适合投标需求。Medal的开发者强调他们的软件包有多种多样的接口能力，而这被吹捧为适合任何需求。;Medal的5E版集成到建议的软件解决了妨碍建议书完成的剩下一个困难，并使得开发费用可观地降低。 最后，HealthSoft与所有潜在的外部参与方——Lion Sesurities、Comcom和Cape-Code，它们分别是安全、通信和编程的分包商——签订了协议。主要是制定财务问题的责任以及各个机构之间的协调。 HealthSoft被宣布为投标获胜者的那天是公司满足和喜悦的一天。所有项目组都在“全速工作”。定期召开月度的协调会议。分包商根据项目进度安排报告了满意的进展。;第十次会议上出现了第一个报警信号。通信分包商Comcom报告说，若干RedAid的主要供货商拒绝提供计划在他们的建筑内安装通信设备所需的信息，因为他们没有就此问题同RedAid达成任何协议。正如预期的，安全分包商Lion Securities面临类似的困难。两个分包商声明说即使在一个星期内实现完全合作，推迟一个月完成项目也是不可避免的。 而Cape-Code 表面平静的报告都是建立在不真实的基础上的，Cape-Code已经将开发任务转包给另一个小软件公司。并在集成测试阶段，出现比进度推迟了10个月，而且识别出各种比预期多得多的故障。改正时间超过计划时间。;大约同时，分配将MedalVersion 5E软件集成到系统里面来的小组认识到这个增强版本对所有新模块不可运行，同其他系统模块的对接尝试失败。 为此Medal Software分配了一个专门的组完成遗漏模块的开发并进行必要的改正。这使得软件的集成测试比安排进度迟了几乎20个星期。 整个项目的系统测试比进度迟了19个星期，且同样存在严重的质量问题。 最后，大约晚了5个月，才有可能在RedAid的主办公室和其供货商场地安装软硬件。;项目比安排进度推迟了23个星期，却惊人地成功，没有发现重大故障。然而执行阶段却非常失败：列入培训的人只有三分之一实际参加了指导课程，而参加者大多数表现出对新系统的预备知识不足。只在8个星期之后才能开始正常运行这个系统，但大约只有一半的供货商集成到新系统中。 这个项目以一系列的法庭索赔结束。RedAid控告HealthSoft，HealthSoft控告RedAid、Cape-Code和Medal Sofeware。Lion Secu