工行个人消费信贷项目软件开发质量计划.doc

软件质量计划软件质量计划 （文档编号：（文档编号：DW-ZFZQ-01-001DW-ZFZQ-01-001） 方正奥德计算机系统有限公司方正奥德计算机系统有限公司 20022002 年年 9 9 月月 软件质量计划 I 文档管理信息表文档管理信息表 主题：主题：质量计划 版本：版本：10.0 内容：内容：关于个贷总行移植质量的计划 关键字关键字 参考文档：参考文档： 提交时间：提交时间：2002 年 11 月 29 日 创建人：创建人：刘军伟 文档修改记录表文档修改记录表 修改人修改人修改时间修改时间修改内容修改内容 软件质量计划 I 目目 录录 1 1、 产品的质量目标产品的质量目标1 2 2、 质量保证措施质量保证措施1 2.1、设计过程质量保证措施 1 2.1.1、实际和开发的策划1 2.1.2、组织和技术接口设计1 2.1.3、设计输入和输出及验收准则2 2.1.4、设计评审3 2.1.5、设计验证4 2.1.6、设计确认4 2.1.7、设计更改4 2.1.8、病毒防治4 2.2、测试过程质量保证措施 5 2.2.1、测试阶段5 2.2.2、测试规范5 2.2.3、测试要求5 2.2.4、质量记录5 2.2.5、其它5 2.3、维护过程质量保证措施 5 2.3.1、维护要求5 2.3.2、质量记录6 3 3、 风险控制风险控制6 4 4、 质量保证活动的职责和权限质量保证活动的职责和权限9 软件质量计划 1 1 1、 产品的质量目标产品的质量目标 系统的接收标准为用户接收的 UAT 测试报告， 系统测试报告和模块测试报 告。产品的质量目标为： 1.UAT 测试中， 系统的功能要求和效率要求满足合同要求和需求规格说明 书要求。 2.在模块测试和系统测试中，没有影响系统运行的严重 BUG, 属于实现形式、 操作形式上的 BUG 应该低于 1 个/千行； 3.已发现 BUG 的修改率为 95%； 4.系统的接收时间与合同时间的差异小于 1 个月。 2 2、 质量保证措施质量保证措施 按照公司的质量管理体系以及部门的质量管理规范，在需求分析、软件设 计、软件实现、软件测试和售后服务等各个阶段，应有严格的质量保证措施。 具体划分为如下阶段： 2.12.1、设计过程质量保证措施设计过程质量保证措施 2.1.12.1.1、 实际和开发的策划实际和开发的策划 在开发计划中对需求分析、软件设计、软件实现、软件测试和测试状 态及软件发布等几个开发阶段进行了策划，并将各个阶段的活动配备了相应的 资源，保证落实到有资格的开发人员，而且开发人员基本上划分了相应的职责。 2.1.22.1.2、 组织和技术接口设计组织和技术接口设计 开发实施过程遵循公司质量体系规范, 在开发实施每个阶段由项目经理提交 软件质量计划 2 阶段性成果记录, 部门秘书向相关部门传递成果记录, 由相关部门进行评审。组 织接口有：项目推进部（提供项目建议书、合同、立项报告；接收并审核开发 计划） ；商务管理部（接收并审核开发计划、质量计划、需求分析、设计分析、 测试计划等程序文件要求商务管理部审核的阶段性控制资料） ；总裁办公室（发 版审核等） 。 2.1.32.1.3、 设计输入和输出及验收准则设计输入和输出及验收准则 开发阶段阶段输入阶段输出验收准则进入 下一 阶段 要求 需求分析项目合同书（要求评审） 、软 件开发计划（要求评审） 、软 件质量计划（要求评审） 、 经营性网站备案登记管理 暂行办法 、 合同评审记录 表 需求分析说明 书（要求评审） 功能范围描述全面无 落漏； 功能描述做到明确无 歧义； 满足输入条件。 通过 验收 准则 通过 评审 软件设计需求分析说明书（要求评审） 软件质量计划（要求评审） 、 软件开发计划（要求评审） 软件设计说明 书（要求评审 代码模块划分及输入 输出关系明确；算法 明确；符合需求说明 书的功能、性能要求； 满足输入条件。 通过 验收 准则 通过 评审 编码实现软件质量计划、软件设计说 明书 系统代码（要 求评审） 、 软件测试计划 （要求评审） 、 代码抽查验证 表（要求评审） 编码严格遵守详细设 计， 必要的调整必 须写入备忘录；遵守 编码规范；满足输入 条件。 通过 验收 准则 通过 评审 软件测试 和测试状 态 系统编码、软件测试计划、 软件质量计划、测试大纲、 模块测试通过标准、系统测 试通过标准 模块测试报告 （要求审批） 、 系统测试报告 （要求审批） 功能实现测试， 需 求说明中的功能全部 实现；性能测试满足 预期用户的访问效率 要求；满足输入条件。 通过 验收 准则 通过 评审 软件发布 确认 需求分析说明书、软件设计 说明书、用户手册、测试大 纲、测试报告、软件原码、 软件母盘 用户接受报告UAT 测试报告满足 用户确认系统功能和 性能满足需求；满足 输入条件。 通过 验收 准则 通过 评审 软件质量计划 3 软件质量计划 4 2.1.42.1.4、 设计评审设计评审 开发阶段时间会议内容人员 软件需求分析评审 2002/9/1 讨论需求分析设 计情况， 审查 需求分析说明书； 用户签字； 总控组; 项目经理; 客户代表; 系统设计总结2002/9/20总结软件设计情 况，审查设计说 明书 总控组; 项目经理; 编码实现总结2002/9/25总结编码实现情 况， 审查编码 计划， 代码抽 查验证表，代码 完成情况表 总控组; 项目经理; 开发人员; 软件测试总结2002/11/5总结模块测试,系 统测试情况。审 查模块测试报告， 系统测试报告 总控组; 项目经理; 开发人员; 测试人员; 系统发布准备2002/12/6讨论系统发布的 准备工作；审查 发布有关文档， 包括：需求分析 说明书、设计说 明书， 开发计 划， 发布母盘， 用户手册， 测 试报告。 总控组; 项目经理; 开发人员; 测试人员; 系统发布总结2002/12/14反馈系统发布后 情况。审查用户 反馈意见， 用 户问题提出表。 总控组; 项目经理; 开发人员; 测试人员; （会议记录记录入评审会议记录 ） 2.1.52.1.5、 设计验证设计验证 验证包括：需求分析验证、软件设计验证、软件实现验证和软件测试验证 软件质量计划 5 四个部分。 （验证记录记录入评审会议记录表和相关审批表） 2.1.62.1.6、 设计确认设计确认 通过验证之后即可确认。 （确认结果记录入评审会议记录 ） 2.1.72.1.7、 设计更改设计更改 所有更改需要经过授权人员确认，并且记录入设计更改文档。注意：不能 在原有文档基础上直接更改。 2.1.82.1.8、 病毒防治病毒防治 在开发过程中, 要做好病毒防治措施,具体有： 1） 开发环境不允许进行网络数据下载； 2） 开发中使用的磁盘媒体要求为未格式化的软盘， 格式化后由项目经理统一 管理使用； 3） 采用正版工具； 4）定期进行系统查毒。 2.22.2、测试过程质量保证措施测试过程质量保证措施 2.2.12.2.1、 测试阶段测试阶段 测试包括单元测试、模块测试、系统测试、压力测试和 UAT 测试四个 阶段。 软件质量计划 6 2.2.22.2.2、 测试规范测试规范 测试规范可以参见软件测试大纲 。 2.2.32.2.3、 测试要求测试要求 测试过程中应合理运用各种测试方法，通过黑盒测试，验证模块接口 和功能的实现；通过白盒测试，验证关键算法的实现科学性。 测试遵循典型性和覆盖性原则。 2.2.42.2.4、 质量记录质量记录 记录入测试大纲 、 测试报告和相应审批表中。 2.2.52.2.5、 其它其它 有关策划、评审、验证、确认等部分的内容可以参见 “设计过程质量保证 措施” 。 2.32.3、维护过程质量保证措施维护过程质量保证措施 2.3.12.3.1、 维护要求维护要求 维护过程要在与客户方达成一致的基础上，保持对服务的实施、验证 和报告的形成文件的程序。 2.3.22.3.2、 质量记录质量记录 在项目过程中形成质量记录文件包括： DW-ZFZQ-28-03-001 质量记录清单.doc DW-ZFZQ-31-01-001 工具软件选用申请表.doc 软件质量计划 7 DW-ZFZQ-31-02-001 工具软件使用纪录.doc等。 3 3、 风险控制风险控制 系统面临的主要风险和控制策略有： 1技术风险 在技术方案中存在如下的技术问题: 1)系统中对加密和数字签名技术的使用目前为初次使用, 需要对加密 和数字签名技术在系统实现中的位置和使用方法作更加慎重考虑和 方案分析。 控制策略：郑武林负责分析整个网站应用系统中加密、数字签名的 应用分析， 决定实现策略， 并结合公司在安全方面人才对安全策 略和实现方法进行重点分析评价。保证安全和加密方案可行、可实 现性好。 风险指数：*， 该项风险影响系统的可用性。 2)对 WLCS 中各种元素的配置优化。 尽管公司有人员参与了 Weblogic 的培训， 但是在 WLCS 上没有应 用经验， 对 WLCS 提供的调用接口没有很好的应用实践，对可用 资源没有很好的了解,将影响系统开发的复杂性、高效性和可维护性。 控制策略：由刘军伟、刘波、梁伦发、马建军、战乃国对 WLCS 的 调用接口和元素， 参照技术手册和技术支持， 进一步分析， 提 出商业逻辑开发可供依赖的平台支持接口。 风险指数：*， 该项风险影响系统的开发周期和系统可维护性 和高效性。 3）数据库 ORACLE 的使用 在开发梯队中， 对 ORACLE 应用缺少具有成熟经验的数据库系统 设计分析人员， 如何设计高效合理的数据库对系统效率和系统的可维护性有重 要意义。 软件质量计划 8 控制策略：由电子商务部中 ORACLE 熟悉的人员对系统数据库的设 计进行质疑和咨询， 特别是从数据效率、数据一致性、数据冗余、数据挖掘和 分析等方面。 风险指数：* * ， 该项风险涉及到系统的效率、可维护性、可实现 性。 4）JAVA 编程技术 在开发梯队大多数开发人员的 JAVA 开发经验并不是很长。在开发队伍 中， 不可避免地存在一些编码设计繁杂等问题。 控制策略：开发人员对于复杂和效率相关的代码，必须进行适当注释， 便于检查；在开发初期， 增加代码抽查的次数， 便于及时发现问题。 风险指数：* ， 该项风险影响到系统的可靠性、高效性。 2需求风险 需求风险是该项目的最大风险之一。其主要原因是： （1）用户需求不是很成熟。 用户需求中存在若干不成熟的业务思想。 控制策略：用户需求提出代表要严格要求。 （2）用户界面复杂， 需求难于一致。 所有功能的实现方法和实现形式， 不同的需求主题有不同的要求。 例如论坛、聊天室、采编对权限管理的需求。 控制策略：用户需求提出人员经过授权应该确定， 不应变化。 （3）业务关系较复杂， 业务关系需要跨模块进行考虑。 需求关系在各个系统之间由交叉。业务需求需要跨系统进行考虑。 控制策略：需要在各个系统之外， 安排需求分析人员对系统之间 的交叉需求进行分析。 并且， 为了保证需求的准确、全面和系统化， 应该组织多次的会议交 流和讨论， 及时发现需求分析中的偏差。 该项风险指数：* 该项风险影响到系统实现工期、项目成本。 软件质量计划 9 3设计风险 设计中存在的风险主要有： （1）由于系统总体方案中结构不合理， 如数据库分布形式， 各个系统之 间的关系。该种风险将影响到系统的可实现性、系统的安全性和可维 护性。 控制策略： 对整体方案的总体结构进行深入分析和讨论。 （2）代码单元的接口设计和代码共享 控制策略：代码单元的接口设计明确， 代码单元功能复杂性适度， 在各个系统之间、系统内部之间建立代