如何加强 Vista 平台的应用程序开发

1. 如何加强 Vista 平台的应用程序开发

2. 今天的议程 • COMPUWARE 和Microsoft • 如何加强 Vista 平台的应用程序开发

3. Compuware 和 Microsoft 一起创新，充分集成 • Compuware 成立于1973 年，服务于全球主要 IT 企业，通过技术和服务使企业IT价值最大化。 • Microsoft Visual Studio Industry Partner (VSIP) 计划的创始成员 • BoundsChecker – Compuware DevPartner 产品早在16年以前就有了针对Microsoft 应用的第一款错误检测工具 • 与VS环境无缝集成，从 Visual Studio 6, Visual Studio.NET 2002-2003到Visual Studio 2005

4. Compuware 解决方案

5. 挑战 • 期望很高的竞争环境 • 持续变化 • 需要确保新的系统成功投产 • 只能成功不能失败 • 理解并交付业务需要 • 计划并适应变化驱动的项目 • 确保可预期服务水平 • 有效并节约成本的方法来评估变化的影响

6. Development Production Planned Benefit • 计划的成果: • 应用按时上线，花费在预算之内 • 性能满足业务需要并获得预期的业务价值 • 所有应用的整体系统性能持续满足业务需要 Time Actual Cost IT 业务价值曲线典型的应用生命周期

7. Development Production Planned Benefit • 实际结果: • 在投产后发现性能问题或在开发生命周期较晚的时候才发现 • 通常，问题很难并要花费很高的代价才能解决 • 这样的问题还会损害已经投产的其它应用 Time Actual Actual Cost IT 业务价值曲线IT的挑战: 应用达不到预期的服务水平

8. Development Production Planned Benefit Time Actual Actual Cost IT 业务价值曲线IT的挑战: 应用达不到预期的服务水平

9. 需求管理的挑战定义, 文档, 验证, 协作和管理 关键问题: • 业务部门不能有效参与需求定义流程 • 在维护不同格式需求文档上花费太多的时间 • 文档被不正确的表示，误解或曲解，特别是在生命周期的其他流程中 • 远程利益攸关方 (e.g., 外包团队) 不能有效参与需求定义流程 • #1 Reason for Failed • Projects is Poor, Missed or • Changing Requirements • Requirements issues are the #1 cause of cancelled or over-budget projects • 42-64% of all defects originate during requirements • 25-40% of total project expenditures are attributable to rework from requirements defects • Fixing defects during the build phase costs 5-20 times more than catching them during requirements analysis • SEI Research Report (2004)

10. 为什么传统的需求，功能特性和约束还不够？ • 不能描述系统做什么 • 他们倾向关注高层的最终要达到的结果 • 倾向相互之间独立 • 缺乏系统做什么的 “story” • 很难转化成设计 • 由于没有 story，开发人员必须猜测系统应该具有的功能 • 很难测试 • 没有 “story” 和系统将如何被使用的信息

11. 结构化需求所有项目活动的框架 • 描叙系统如何被一个或多个用户以特定的方式所使用，并得到预期的结果 • 提供明确的故事般的描述，这样容易被项目利益攸关方和开发团队的成员所理解 • 用简单的语言表示，而不是用专门的符号，这样所有人都能理解 • 提供一个公共方式让所有项目组成员都可以交流系统应完成的功能 • 表达期望行为的方式 • 替代大量 “传统” 需求 ，通过提供更自然的方式描述用户做什么和系统如何响应

12. 结构化需求的好处 • 简单的 ‘框架’ 驱动项目活动 • 提供连接开发人员和测试人员与其他利益攸关方的桥梁 • 在开发过程中实现需求的可追溯性和需求验证 • 更有效共享需求信息，而不会给开发团队造成额外负担

13. Code Coverage Functional Test Dynamic Code Analysis Static Code Analysis Code Profiler Task Tracking Reporting Service Project Portal Visio and UML Modeling Stress/Load Test Class Designer Project Management Application Designer Model-Base Designer Deployment Designer Construction Server Test Management Manual Test VS Professional Change Management Team Foundation Client Integration Service Development Workflow VSPartner 集成开发环境 Visual StudioTeam Architect Visual StudioTeam Developer Visual StudioTeam Test Visual StudioTeam Foundation

14. 管理业务风险的方法 持续集成测试 最优化测试

15. 及早发现和解决问题 • 在早期定位问题，问题更容易解决，代价更小。 • 交付测试的应用更可靠和扩展性更好 • 有更多的时间关注功能实现的质量 • 降低由于测试不充分造成的在生产中失效的风险 * Giga Group says defects found post-production cost at least 50 percent more than those found early

16. 目前的实际情况… • 测试不充分和不规范 • 测试主要关注功能是否实现而不是代码的性能 • 测试经常是无法重新进行，带来潜在的回归问题。 • 应用带着无法接受的缺陷率交付 • 缺陷在部署后才被发现 • 在开发过程中业务需求改变 Unit testing is not performed 13% Unit testing is informal 46% Unit tests cases aredocumented 11% Unit tests cases and their executions are documented 16% Use a Test DrivenDevelopment approach 14% Participants: 460 www.methodsandtools.comMar 2006

17. 目前的实际情况… • 代码送回开发团队并造成时间延误和减少测试的时间 • 开发人员可能已经开始新的任务了 • 开发人员可能要重新回到几个月前的工作上 • 发现和修复的成本可能呈指数增长 • 性能和可扩展性问题直到开发生命周期的晚期才被发现 • 开发工作以量来测量，而不是以质量，稳定性或性能来测量。

18. 100% Percentage 0% 1stMonth 2ndMonth 3rdMonth 4thMonth 5thMonth 6thMonth Design Develop Debug Test 调试时间 • 花费在调试应用上的时间有多少？ “The more quickly that code and components can be tested in simulated deployment mode,the better the quality in earlier stages of projects.” Dana GardnerYankee Group, April 2004 研究表明团队大约花费30%-65% 的时间进行调试

19. …持续集成测试…更多测试，及早测试，经常测试？…持续集成测试…更多测试，及早测试，经常测试？ • 整合人，方法和自动化工具 • 不断积累的测试 • 在项目开始时开始测试 • 应用测试从开发开始 • 使用一种综合的开发和测试方法 • 可重复的和一致的程序，改善应用质量 • 每日建立，每夜测试… • 测试完全被自动化而且能做到无人值守的，将对开发者的影响降到最小 • 使用工具进行性能和功能测试 • 增加每个项目的测试迭代次数 • 持续地测试 • 有机会就测试–每周每天

20. More time to test • Begin test as early as possible • More testing performed •  Defect rates and  Success rate CIT能给你带来什么好处？ • 在代码开发出来时就能发现大部分的编码问题 • 在最初的编码阶段就提高质量 • 与前一个Ｂuild版本进行性能基准比较 • 测试案例 ‘资产数据库’随着时间而不断积累 • 只有高质量的代码才交给功能和性能测试

21. 成功案例: WebJET • 挑战: • 业务模型基于web 应用 • 应用部署只能成功，不能失败 • 业务整合在第一次，每个时间都要完成 • 解决方案: • Compuware 持续集成测试严格遵守质量控制过程 • 成功: • 超过1100 测试test cycles • 内嵌的测试可以快速开始功能测试 • WebJET如期投入生产 • 在11月内准时完成，花费在预算之内。 “Microsoft selected Compuware tools at the very inception of the project recognising that the project was risk management, flexibility and speed to market.” “Without Compuware tools the project would not have been completed on time and certainly would not have been completed within the risk profile.”  Mr David ClarkeManaging DirectorWebjet Pty Ltd.

22. QACenter Enterprise Edition • 运行期内存分析 • 内存泄露 • 临时对象 • RAM 使用 • 覆盖率分析 • 性能分析 • 自动错误检测 • 安全分析 • 故障模拟 QACenter Portal / QADirector TestParter ClusterDevPartner Studio 测试资产数据库 缺陷 Web 服务器 (IIS) DevPartner Studio DevPartner SecurityChecker DevPartner FaultSimulator 缺陷数据库 TrackRecord 数据库服务器 Compuware CIT 在(.NET)的环境

23. 最优化测试 • 通过基于风险分析的方法平衡质量，时间，成本 • 管理 “what-if” 场景 • 加入或改进自动化 • 改善团队协作和沟通 • 充分利用资源 • 测试和业务目标一致

24. 风险评估 质量优化快速管理变更 • 平衡风险，时间和覆盖率 • 提供可视界面调整风险和覆盖率 • 让QA人员可以理解时间要求和执行what-if 场景 使用交互式滑动条调整计划 可视化展示覆盖率和状态 时间和度量的详细统计信息 详细的需求覆盖率

25. Requirements Development FunctionalTesting LoadTesting Go Live? Production RequirementsAnalysis Development FunctionalTesting LoadTesting Tuning Identify Stress Related Failures 60% 10% 30% 发现缺陷的百分比 IT Management DBAs & Architects Developers Network Engineers 性能保障： IT的挑战性能难题 • 验收实践 • 等功能稳定，再开始负载测试，进行性能验证 • 挑战 • 性能瓶颈很难定位 – 由于系统的复杂性和诊断问题需要的许多技巧 • 一旦问题发生，将涉及架构师，数据库管理员，开发人员，网络专家，和系统运维人员 • 结果 • 严重的性能问题造成应用不能按计划交付 • 潜在的性能问题损害 IT部门的信誉

26. 性能保障: IT挑战什么造成性能缺陷 : 开发环境 • 开发人员 • 工作在局域网环境 • 处理路径复杂，并不完全知晓 • 没有办法评估基础架构的资源使用 • 使用的数据少 • 不对整个交易测试 – 只做他们自己的那一部分 • 当今的开发环境 • 许多 IT组织将开发或测试外包 • 分布式开发团队变得越来越普遍 • 应用直到部署前才将整个应用放在一起

27. Requirements Development FunctionalTesting LoadTesting Go Live? Production PerformanceRequirements ComponentProfiling TransactionProfiling Identify Stress Related Failures 结果: 交付高性能应用 满足项目工期 控制成本 我们投产就绪的理念采用主动方法及早定位和解决性能问题 • 在应用开发生命周期的早期定位和解决很难的性能问题 • 使用先进的性能剖析和负载测试技术结合端到端的性能分析确保性能满足要求 • 确保生产环境有合适的资源容量，当新的应用投产后不会影响当前应用的性能。 Identify BusinessAlignment Issues Identify SlowComponents andResource Drains Identify TransactionBottlenecks andCapacity Problems End-to-EndPerformance Analysis and Quality Management Application Service Management

28. 集成的性能保障多维度性能剖析 • 性能剖析和测试实现性能驱动的开发生命周期 • 在开发生命周期的早期就考虑性能 • 所有的事情始于需求 • 在生命周期的所有阶段定位和解决性能问题 • 为开发提供持续的反馈，使解决问题更有效 • 性能剖析和分析工具可以做： • 应用网络性能 • 服务器性能 • 服务器应用性能 • 代码级性能

29. Virtual Users DBMS Web Servers Application Servers Mainframe 性能保障负载测试的同时进行基础架构的监控 • 负载测试与基础架构监控结合: • 提供交易的真实模拟和流量使用模式: • 确保服务器具有可扩展性，能满足当前和未来的需要 • 建立应用性能和应用基础架构的所有部件的关系

30. 一般你能得到： 方法热点分析 SQL 热点分析

31. R e q u e s t # 1 ASPX ASMX ADO Server ASMX ASMX y l p e R ASPX CICS T1 WIFC ASMX ASMX ASPX TotalTime R e q u e CICS T2 s t # 2 WIFC ASMX WIFC ASPX WIFC CICS T3 Server y l p e R 通过端到端分析你能得到：交易剖析，网络“what if”预测性分析，等等

32. 差别

33. 性能保障 – 案例分析 • 公司: University of North Carolina – Charlotte • 问题: • UNC Charlotte为2005-2006 学年实施一套新的ERP系统 • 四个月的时间，IT部门仍在调研可行的性能测试解决方案 • 方法: • 选择集成的工具集，开发周期内的所有人都可以受益 – 开发人员，测试人员和运维人员 • 雇用有经验的人员快速实施工具和进行所需的复杂测试 • UNC Charlotte 得到的价值 • 最初的发现确认了存在应用和基础架构设计的问题 • 诊断，根本原因分析和修复在60天内完成 • 新的 ERP系统按时部署上线，并满足用户要求

34. 质量保障质量控制, 测试 + 根本原因分析 + 持续改进 质量控制 确保在部署前使用良好 应用测试 功能/回归 – 可扩展/性能 应用质量保障

35. Development Production Stretch Planned Benefit • 短期结果: • 确保关键业务项目满足性能预期 Time Actual Actual Cost • 长期结果: • 持续交付高性能应用 • 建立最佳实践 • 更好地利用 IT资源 Compuware 应用交付管理交付卓越应用