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

Page 2

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

Page 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

Page 4

Compuware 解决方案

Page 5

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

挑战

Page 6

Development Production

Time

Benefit

Cost

Planned

Actual

计划的成果 : 应用按时上线，花费在预算之内 性能满足业务需要并获得预期的业务价

值 所有应用的整体系统性能持续满足业务

需要

IT 业务价值曲线典型的应用生命周期

Page 7

Development Production

Time

Benefit

Cost

Planned

ActualActual

IT 业务价值曲线IT 的挑战 : 应用达不到预期的服务水平

实际结果 : 在投产后发现性能问题或在开发生命周

期较晚的时候才发现 通常，问题很难并要花费很高的代价才

能解决 这样的问题还会损害已经投产的其它应

用

Page 8

Development Production

Time

Benefit

Cost

Planned

ActualActual

% Resolved in ProductionApproach

Resolving Performance Defects (2006)

Firefighting

Performance Validation

Performance Driven

Source: Forrester Research

100%

5%

30%

IT 业务价值曲线IT 的挑战 : 应用达不到预期的服务水平

Page 9

需求管理的挑战定义 , 文档 , 验证 , 协作和管理

关键问题 :业务部门不能有效参与需求定义流程在维护不同格式需求文档上花费太多的

时间文档被不正确的表示，误解或曲解，特

别是在生命周期的其他流程中远程利益攸关方 (e.g., 外包团队 ) 不能

有效参与需求定义流程

#1 Reason for FailedProjects is Poor, Missed orChanging 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)

Page 10

为什么传统的需求，功能特性和约束还不够？ 不能描述系统做什么

– 他们倾向关注高层的最终要达到的结果 倾向相互之间独立

– 缺乏系统做什么的 “ story” 很难转化成设计

– 由于没有 story ，开发人员必须猜测系统应该具有的功能 很难测试

– 没有 “ story” 和系统将如何被使用的信息

Page 11

结构化需求所有项目活动的框架

描叙系统如何被一个或多个用户以特定的方式所使用，并得到预期的结果

提供明确的故事般的描述，这样容易被项目利益攸关方和开发团队的成员所理解

– 用简单的语言表示，而不是用专门的符号，这样所有人都能理解– 提供一个公共方式让所有项目组成员都可以交流系统应完成的功能

表达期望行为的方式– 替代大量 “传统” 需求 ，通过提供更自然的方式描述用户做什么

和系统如何响应

Page 12

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

Page 13

集成开发环境

Change Management

Task Tracking

Reporting Service

Project Portal

Visual StudioTeam Foundation Integration Service

Project Management

Develo

pm

en

t D

evelo

pm

en

t W

ork

flow

Work

flow

Visual StudioTeam Architect

Visio and UML Modeling

Team Foundation Client

VS Professional

Class Designer

Test Management

Application Designer

Model-Base Designer

Deployment Designer

Visual StudioTeam Developer

Visual StudioTeam Test

VS

VS

P

artn

er

Partn

er

Construction Server

Dynamic Code Analysis

Static Code Analysis

Code Profiler

Code Coverage

Functional Test

Manual Test

Stress/Load Test

Page 14

管理业务风险的方法

最优化测试持续集成测试

Page 15

及早发现和解决问题 在早期定位问题，问题更

容易解决，代价更小。 交付测试的应用更可靠和

扩展性更好– 有更多的时间关注功能实现

的质量– 降低由于测试不充分造成的

在生产中失效的风险

* Giga Group says defects found post-production cost at least 50 percent more than those found early

Page 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: 460www.methodsandtools.com

Mar 2006

Page 17

目前的实际情况… 代码送回开发团队并造成时间延

误和减少测试的时间– 开发人员可能已经开始新的任务

了– 开发人员可能要重新回到几个月

前的工作上 发现和修复的成本可能呈指数增长

性能和可扩展性问题直到开发生命周期的晚期才被发现

开发工作以量来测量，而不是以质量，稳定性或性能来测量。

Page 18

调试时间 花费在调试应用上的时间有多少？

研究表明团队大约花费30%-65% 的时间进行调试

1stMonth

2ndMonth

3rdMonth

4thMonth

5thMonth

6thMonth

0%

100%

Design Develop Debug Test

Pe

rce

nta

ge

“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

Page 19

…持续集成测试 …更多测试，及早测试，经常测试？ 整合人，方法和自动化工具 不断积累的测试 在项目开始时开始测试

– 应用测试从开发开始– 使用一种综合的开发和测试方法

可重复的和一致的程序，改善应用质量

– 每日建立，每夜测试…– 测试完全被自动化而且能做到无人值

守的，将对开发者的影响降到最小– 使用工具进行性能和功能测试

增加每个项目的测试迭代次数– 持续地测试– 有机会就测试–每周每天

Page 20

CIT 能给你带来什么好处？ 在代码开发出来时就能发现大部

分的编码问题– 在最初的编码阶段就提高质量

与前一个Ｂ uild版本进行性能基准比较

测试案例 ‘资产数据库’随着时间而不断积累

只有高质量的代码才交给功能和性能测试

More time to test Begin test as early as possible More testing performed

Defect rates and Success rate

Page 21

“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 Director

Webjet Pty Ltd.

成功案例 : WebJET

挑战 :– 业务模型基于 web 应用– 应用部署只能成功，不能失败 – 业务整合在第一次，每个时间都要完成

解决方案 :– Compuware 持续集成测试严格遵守质量控制过

程 成功 :

– 超过 1100 测试 test cycles – 内嵌的测试可以快速开始功能测试– WebJET 如期投入生产

在 11 月内准时完成，花费在预算之内。

Page 22

Compuware CIT 在 (.NET) 的环境QACenter Enterprise Edition

缺陷数据库

TrackRecord

缺陷

测试资产数据库

`

` `

TestParter ClusterDevPartner Studio

QACenter Portal / QADirector

`

数据库服务器

Web 服务器 (IIS)DevPartner Studio

DevPartner SecurityCheckerDevPartner FaultSimulator

• 运行期内存分析• 内存泄露• 临时对象• RAM 使用

• 覆盖率分析• 性能分析• 自动错误检测• 安全分析• 故障模拟

• 运行期内存分析• 内存泄露• 临时对象• RAM 使用

• 覆盖率分析• 性能分析• 自动错误检测• 安全分析• 故障模拟

Page 23

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

Page 24

质量优化快速管理变更 平衡风险，时间和覆盖

率 提供可视界面调整风险

和覆盖率 让 QA 人员可以理解时

间要求和执行 what-if 场景

风险评估

可视化展示覆盖率和状态

使用交互式滑动条调整计划

详细的需求覆盖率

时间和度量的详细统计信息

Page 25

性能保障： IT 的挑战性能难题

验收实践– 等功能稳定，再开始负载测

试，进行性能验证 挑战

– 性能瓶颈很难定位 – 由于系统的复杂性和诊断问题需要的许多技巧

– 一旦问题发生，将涉及架构师，数据库管理员，开发人员，网络专家，和系统运维人员

结果– 严重的性能问题造成应用不

能按计划交付– 潜在的性能问题损害 IT 部

门的信誉 Network EngineersDevelopers

DBAs & Architects

IT Management

Requirements FunctionalTesting

LoadTesting Go Live? ProductionDevelopment

RequirementsAnalysis

Development

FunctionalTesting

LoadTesting Tuning

10% 60% 30%

发现缺陷的百分比

Identify Stress Related Failures

Page 26

性能保障 : IT 挑战什么造成性能缺陷 : 开发环境

开发人员– 工作在局域网环境– 处理路径复杂，并不完全知晓– 没有办法评估基础架构的资源使用– 使用的数据少– 不对整个交易测试 – 只做他们自己的那一部分

当今的开发环境– 许多 IT 组织将开发或测试外包– 分布式开发团队变得越来越普遍– 应用直到部署前才将整个应用放在一起

Page 27

我们投产就绪的理念采用主动方法及早定位和解决性能问题

在应用开发生命周期的早期定位和解决很难的性能问题

使用先进的性能剖析和负载测试技术结合端到端的性能分析确保性能满足要求

确保生产环境有合适的资源容量，当新的应用投产后不会影响当前应用的性能。

Requirements FunctionalTesting

LoadTesting Go Live? ProductionDevelopment

PerformanceRequirements

ComponentProfiling

TransactionProfiling

Identify Stress Related Failures

End-to-EndPerformance Analysis and Quality Management

Application Service Management

Identify TransactionBottlenecks and

Capacity Problems

Identify SlowComponents andResource Drains

Identify BusinessAlignment Issues

交付高性能应用

满足项目工期

控制成本

结果 :

Page 28

集成的性能保障多维度性能剖析

性能剖析和测试实现性能驱动的开发生命周期– 在开发生命周期的早期就考虑性能

所有的事情始于需求– 在生命周期的所有阶段定位和解决性能问题– 为开发提供持续的反馈，使解决问题更有效

性能剖析和分析工具可以做：– 应用网络性能– 服务器性能– 服务器应用性能– 代码级性能

Page 29

性能保障负载测试的同时进行基础架构的监控

负载测试与基础架构监控结合 :– 提供交易的真实模拟和流量使用模式 :

确保服务器具有可扩展性，能满足当前和未来的需要 建立应用性能和应用基础架构的所有部件的关系

Virtual Users

Web Servers Application Servers

DBMS

Mainframe

Page 30

一般你能得到：

方法热点分析

SQL 热点分析

Page 31

通过端到端分析你能得到：交易剖析，网络 “ what if” 预测性分析，等等

TotalTime

Request #1

Request #2

Reply

Reply

Server

Server ASPX

ASMX

WIFC

ADO

CICS T1

CICS T2

CICS T3

ASMXASPX

ASPX

ASPX

ASMX

ASMX

ASMX

ASMX WIFC

WIFC WIFC

Page 32

差别传统性能测试 性能保障

关注 项目结束时测试 集成生命周期方式

资源 分离 集成自动化 负载测试 剖析 , 负载 & 根本原因分析

价值 以 IT 为中心 以客户为中心

Page 33

性能保障 – 案例分析 公司 : University of North Carolina –

Charlotte 问题 :

– UNC Charlotte 为 2005-2006 学年实施一套新的 ERP 系统

– 四个月的时间， IT 部门仍在调研可行的性能测试解决方案

方法 :– 选择集成的工具集，开发周期内

的所有人都可以受益 – 开发人员，测试人员和运维人员

– 雇用有经验的人员快速实施工具和进行所需的复杂测试

UNC Charlotte 得到的价值– 最初的发现确认了存在应用和基础架构设计的问题

– 诊断，根本原因分析和修复在 60天内完成

– 新的 ERP 系统按时部署上线，并满足用户要求

Page 34

应用质量保障

应用测试功能 / 回归 – 可扩展 / 性能

质量控制确保在部署前使用良好

质量保障质量控制 , 测试 + 根本原因分析 + 持续改进

Page 35

Development Production

Time

Benefit

Cost

Planned

Actual

Stretch

Actual

短期结果 : 确保关键业务项目满足性能预期

长期结果 : 持续交付高性能应用 建立最佳实践 更好地利用 IT 资源

Compuware 应用交付管理 交付卓越应用

Page 36