实用软件工程方法PPT11.pptVIP

第11章项目开发阶段 课程介绍 本章重点介绍了MSF开发阶段的活动和相关的零缺陷理念和指导原则 本章内容 开发阶段的活动 零缺陷理念 开发阶段成功的标准 范围完成里程碑的交付物 范围完成里程碑和中间里程碑 开发阶段小组角色的职责 本章小结 问题和讨论 11.1 开发阶段的活动 开发技术基础架构 解决方案技术基础架构的验证 内部发布 每日构造 代码审核 构造用户体验交付物 构造运营文档 测试解决方案 缺陷管理 11.1.1 开发技术基础架构 1. 人员（people） 2. 过程（process） 3. 技术（technology） 11.1.2 解决方案技术基础架构的验证 开发验证需要做的工作有 在非生产的模拟环境中测试解决方案 用户走查解决方案，确认他们的需求是否得到满足 开发实现规程（Implement procedure） 自动化部署和安装过程 测试本解决方案和过程 撰写部署检测表（deployment checklist） 撰写运营和管理规程（operation and management procedure） 11.1.3 内部发布 MSF建议每次内部发布可作为一个中间里程碑 11.1.3 内部发布的优点 将复杂的事分解为简单的事，干完一件再干一件 有利于风险优先级管理 由于内部发布只提短期的目标，使大家看到进展 多设内部里程碑对软件开发还有一特殊好处是它缩小了出错的潜在范围 11.1.3 内部发布指南 单个项目中的内部发布，可以看作是产品不对外的版本 早发布风险优先级高的或对开发工作有益的功能 内部发布的关键点是要达到明确的、能表达的项目状态，并以通过质量标准定义的基准来实现 每次发布工作产品内聚性要好，便于开发测试。与上几次发布工作产品相对独立，耦合性低，便于更改 每次内部发布后要事先审核，有利于小组不断总结经验，多作设计重用 11.1.4 每日构造 每日构造有以下三个步骤： 开发、测试、验证 每日构造的好处 即早找出问题、减少集成风险、提高质量 每日构造的指导原则 每天都要交出测试过的构造，必须严格制度 11.1.5 代码审核 代码审核的优点 代码审核方法 代码审核指导原则 11.1.5 代码审核（1） 代码审核的优点 提高代码质量 加快开发速度 提供了一种培训开发者的方法 增强代码的可维护性 降低解决缺陷的费用 有利于编出更规范的代码 代码审核方法 全面正式审核 不定时的，同事间审核 独立的第三方审核 11.1.5 代码审核（2） 代码审核指导原则 代码审核，越早越好 代码审核列入计划 共享审核中取得的经验教训 把正式审核作为不同开发小组相互交流的一次机会 把同事间审核作为营造开发人员创造性冲动的工具 第三方审核作为规范标准审核最易行 代码审核唯一的缺点是不彻底 11.1.6 构造用户体验交付物 用户参考资料（用户手册和帮助文件） 用户界面中的图形元素 最终用户培训 可用性测试场景 11.1.7 构造运营文档 操作指南、标准的操作流程 用户支持和技术支持的流程 知识库 技术支持人员的培训 11.1.8 测试解决方案 测试就是找出代码和文档中的错误，俗称bug（缺陷） 测试确能验证小组正在正确地做程序，也能确认小组正在做正确的事 MSF开发阶段中的测试过程 测试的种类 MSF的两大类测试 项目测试过程 11.1.8 测试的种类 从开发而言 从产品角度 从测试技术角度 从产品性能的角度 从产品使用性角度 11.1.8 MSF的两大类测试 覆盖测试：找出程序中的缺陷 使用性测试：找出程序中的失败 11.1.8 项目测试过程 在项目计划认可里程碑处 小组则应制定测试计划，明确基准后作详细的测试规范 在项目的范围完成里程碑处 即开发阶段完成，所有的测试规范都应完成 到达项目范围完成里程碑时 表示产品开发完成了，是功能齐备的基准产品，小组可进入alpha测试 开发阶段的内部发布里程碑 均作覆盖测试。稳定阶段中完成其它测试，而beta测试为其中心工作 11.1.9 缺陷管理 相关术语 缺陷分类 成功的缺陷管理 11.1.9 相关术语 缺陷（Bug），是产品在使用过程中发生的任何问题。 缺陷比较严格的定义有以下五条： 产品规范中说要做某件事，软件没做 产品规范中说不做某件事，软件做了 产品规范提供没有提的事，软件却做了 产品规范该提却没有提的事，软件没做 最终用户感觉不好用，测试者承认是难于理解，难于使用和低效的，都算缺陷 缺点（Defect） 从开发者的观点，是导致代码不能工作的缺陷。 失败（Failure） 从测试者和客户的观点，程序不能工作，则称失败。 11.1.9 缺陷分类 按严重性分类可分为以下四级： 系统崩溃（System Crash）