第1章 微软解决方案框架(MSF)简介 1
1.1 微软的组织结构 2
1.2 软件产业面临的挑战 3
1.2.1 不断变化的商业环境 3
1.2.2 成功来之不易 5
1.3 什么是微软解决方案框架(MSF) 6
1.4 微软解决方案框架的由来 7
1.5 微软解决方案框架中的主要模型 8
1.5.1 企业架构模型(Enterprise Architecture Model) 8
1.5.2 解决方案设计模型(Solution Design Model) 9
1.5.5 过程模型(Process Model) 10
1.5.3 风险管理模型(Risk Management Model) 10
1.5.4 组队模型(Team Model) 10
1.5.6 应用模型(Application Model) 11
1.6 MSF解决方案开发准则 12
1.7 总结 13
第2章 MSF组队模型 14
2.1 什么是MSF组队模型 15
2.2 MSF组队模型的基本原则 15
2.2.1 小型的、多元化的项目组(Small,Multidisciplinary Teams) 15
2.2.4 以产品发布为中心(Focus on competency and shipping products) 16
2.2.2 角色依赖和职责共享(Interdependent roles and shared responsibilities) 16
2.2.3 专深的技术水平和业务技能(Deep technical and business acumen) 16
2.2.5 明确的目标(Clear goals and objectives) 17
2.2.6 客户的主动参与(Active customer participation) 17
2.2.7 分享产品的前景(Shared project vision) 17
2.2.8 所有人都参与设计(Everyone participating in design) 18
2.2.9 认真从过去的项目中吸取经验(Deliberate efforts to leam from past projects) 18
2.2.10 共同管理，共同决策(Shared project management and shared decision-making) 18
2.2.11 项目组成员在同一地点办公(Team members working together at one site) 18
2.3 小型项目组的优势 19
2.2.12 大型项目组也像小项目组一样运转(Large teams working like small teams) 19
2.4 成功的项目组 20
2.5 组队角色 21
2.5.1 产品管理(Product Management)角色 22
2.5.2 程序管理(Program Management)角色 23
2.5.3 开发(Development)角色 24
2.5.4 测试(Testing)角色 25
2.5.5 用户体验(User Experience)角色 25
2.5.6 发布管理(Release Management)角色 26
2.6 MSF组队模型不是组织结构图 26
2.7 对等团队(Team of Peers)结构 27
2.9 项目组的六大工作目标 29
2.8 授权 29
2.10 组队模型的灵活应用 31
2.10.1 小型项目组中的角色合并原则 31
2.10.2 按产品特性划分项目组 32
2.10.3 按职能划分项目组 35
2.11 交流和沟通 36
2.12 总结 38
第3章 MSF过程模型 39
3.1.1 软件开发项目的全过程 40
3.1 什么是MSF过程模型 40
3.1.2 MSF过程模型 41
3.1.3 MSF过程模型与传统过程模型之间的关系 41
3.2 MSF过程模型的特点 42
3.2.1 目标驱动而非任务驱动(Driven by goals not tasks) 42
3.2.2 外部可见的里程碑(Extemally visible milestones) 43
3.2.3 应提交项的变更管理(Change management of deliverables) 43
3.2.4 递进的版本发布策略(Versioned releases) 43
3.2.5 风险驱动的进度管理(Risk-driven scheduling) 43
3.3.1 制定计划时兼顾未来的不确定因素 44
3.3 微软软件开发过程的基本原则 44
3.3.2 通过有效的风险管理减少不确定因素的影响 44
3.2.7 管理产品质量(Managing quality) 44
3.2.6 项目组集体参与(Full team involvement) 44
3.3.3 经常生成过渡版本(Build)并进行快速测试来提高产品的稳定性及可预测性 45
3.3.4 快速循环、递进的开发过程 45
3.3.5 从产品特性和成本控制出发创造性地工作 45
3.3.6 创建确定的进度表 46
3.3.7 使用小型项目组并发完成工作，并设置多个同步点 46
3.3.8 将大型项目分解成多个可管理的单元，以便更快地发布产品 46
3.3.9 用产品的前景目标和概要说明指导项目开发工作——先基线化，后冻结 46
3.3.13 非责难式的里程碑评审会 47
3.3.12 零缺陷观念 47
3.3.11 使用概念验证原型，进行开发前的测试 47
3.3.10 避免产品走形 47
3.4 MSF过程模型的阶段划分和里程碑设置 48
3.4.1 主要里程碑和临时里程碑 48
3.4.2 里程碑是由目标驱动的 49
3.4.3 里程碑是项目的同步点 50
3.4.4 里程碑驱动的项目职责划分 50
3.5 关键在于交流和沟通 51
3.6 项目管理中的均衡三角形 52
3.6.1 均衡三角形(Tradeoff Triangle) 52
3.6.2 项目均衡矩阵(Project Tradeoff Matrix) 52
3.7 递进的版本发布策略 54
3.8.1 概述 55
3.8 构想阶段(Envisioning Phase) 55
3.8.2 里程碑：前景/范围得到认可 56
3.8.3 应提交项 56
3.8.4 项目组的分工 56
3.8.5 建议的临时里程碑 57
3.9 计划阶段(Planning Phase) 57
3.9.1 概述 57
3.9.2 里程碑：项目计划得到认可 58
3.9.3 应提交项 58
3.9.5 建议的临时里程碑 59
3.9.4 项目组的分工 59
3.10 开发阶段(Developing Phase) 60
3.10.1 概述 60
3.10.2 里程碑：开发完成 60
3.10.3 应提交项 61
3.10.4 项目组的分工 61
3.10.5 建议的临时里程碑 61
3.11 稳定阶段(Stabilizing Phase) 62
3.11.1 概述 62
3.11.5 建议的临时里程碑 63
3.11.4 项目组分工 63
3.11.3 应提交项 63
3.11.2 里程碑：可发布版本准备就绪 63
3.12 发布阶段(Deploying Phase) 65
3.12.1 概述 65
3.12.2 里程碑：发布完成 66
3.12.3 应提交项 66
3.12.4 项目组的分工 66
3.12.5 建议的临时里程碑 67
3.12.6 产品发布均衡矩阵(Release Tradeoff Matrix) 67
3.13 总结 68
第4章 微软公司的程序经理 69
4.1 程序经理简介 70
4.1.1 什么是程序经理 70
4.1.2 微软产品部门的组织结构图 70
4.1.3 项目组的工作结构 71
4.1.4 程序经理的历史 73
4.1.5 软件产品≠代码 73
4.1.6 为什么需要程序经理 74
4.1.7 程序经理的职责 75
4.1.8 项目经理和程序经理的对比 75
4.2 产品生命周期中的程序经理角色 76
4.2.1 计划阶段中程序经理的职责 77
4.2.2 开发阶段中程序经理的职责 78
4.2.3 稳定阶段中程序经理的职责 79
4.2.4 发布阶段中程序经理的职责 81
4.2.5 总结阶段中程序经理的职责 82
4.3 程序经理的工作策略 83
4.3.1 程序经理的核心能力——智商(IQ) 83
4.3.2 程序经理的核心能力——情商(EQ) 83
4.3.3 什么样的人才能成为程序经理 84
4.3.4 程序经理的核心素质 85
4.3.5 沟通的方式 86
4.3.6 领导素质 87
4.3.7 协调能力 89
4.4 总结 90
第5章 案例分析：IE浏览器项目 91
5.1 概述 92
5.2 浏览器市场情况回顾 92
5.2.1 市场回顾 92
5.2.2 浏览器战争 93
5.2.3 新的目标 94
5.2.4 微软为什么会赢得浏览器战争 96
5.2.4.1 正确的市场策略 96
5.2.4.2 一切为“战争”服务(War Mindset) 96
5.3.2 IE4.0产品部门的结构 98
5.3 IE项目组的组织和管理 98
5.3.1 IE产品部门的规模 98
5.3.3 IE4.0产品部门内的汇报关系 99
5.3.4 IE的产品特性项目组 100
5.3.5 IE产品特性项目组的成员 100
5.3.6 产品特性项目组的工作结构 101
5.3.7 项目角色：程序经理 102
5.3.8 项目角色：开发工程师 102
5.3.9 项目角色：测试工程师 103
5.3.10 项目角色：产品经理 103
5.3.12 IE项目组的主要组织原则 104
5.3.11 项目角色：其他成员 104
5.4 IE项目的生命周期管理 105
5.4.1 IE项目的生命周期 105
5.4.2 计划阶段 105
5.4.2.1 一般工作流程 105
5.4.2.2 项目前景和产品目标 107
5.4.2.3 产品里程碑确定 108
5.4.2.4 产品特性的概要和详细设计 108
5.4.3 开发阶段 109
5.4.3.2 安装、配置开发环境 110
5.4.3.3 代码检入工作(Check-in) 110
5.4.3.1 开发计划工作 110
5.4.3.4 每日产品生成(Daily Build) 111
5.4.3.5 管理Bug数据库 111
5.4.4 稳定阶段 112
5.4.4.1 产品特性冻结 112
5.4.4.2 代码完成 112
5.4.4.3 用户界面冻结 113
5.4.4.4 Beta版本发布 113
5.4.5 发布阶段 113
5.4.5.1 零Bug日期 113
5.4.5.4 正式发布版本和签字认可 114
5.4.5.2 发布候选版本 114
5.4.5.3 源代码树分支 114
5.4.6 总结阶段 115
5.4.7 微软过程管理策略 115
5.5 微软公司开发管理的演变 116
5.5.1 项目组管理方式的演变 116
5.5.2 过程管理方式的演变 116
5.6 总结 116
第6章 高信度计算：开发安全的软件 117
6.1 关于本章内容 118
6.2.1 从著名的“ILOVEYOU”病毒谈起 119
6.2 我们需要安全的系统 119
6.2.3 疯狂的网 121
6.2.2 Intemet时代的安全问题 121
6.2.4 树大招风 122
6.2.5 确保安全是CIO们面临的首要课题 122
6.3 必须做好5件事 123
6.3.1 SQL Server中的xp_cmdshell问题 124
6.4 致命威胁：缓冲区溢出攻击 126
6.4.1 什么是缓冲区溢出攻击 126
6.4.2 缓冲区溢出攻击实验 129
6.4.4 其他可能导致缓冲区溢出的库函数 133
6.4.3 防范缓冲区溢出攻击的方法 133
6.4.5 Visual Studio.NET的解决方案 134
6.4.6 其他危险的API函数 135
6.5 Web安全隐患：SQL嵌入攻击 136
6.5.1 什么是SQL嵌入攻击 136
6.5.2 如何防范SQL嵌入攻击 138
6.6 总结 139
6.7 参考文献 140
第7章 软件测试 141
7.1 什么是软件测试 142
7.2 软件测试的历史 143
7.2.2 PC时代 144
7.2.3 网络时代 144
7.2.1 萌芽时代 144
7.3 测试角色 145
7.3.1 产品部门中的测试团队 146
7.3.2 测试工程师的类型 147
7.3.3 测试角色的职能项目组 150
7.3.4 测试角色与其他角色的合并 150
7.4 项目过程中的测试工作 150
7.4.1 案例：发布条件 151
7.5.1 什么是Bug 152
7.5 Bug和Bug跟踪 152
7.5.2 Bug跟踪过程 153
7.5.3 Bug的不同处理方式 154
7.6 测试的分类 156
7.6.1 覆盖测试和使用测试 156
7.6.2 白盒测试和黑盒测试 158
7.6.3 手工测试和自动测试 160
7.6.4 软件评测(Benchmarks) 161
7.7 测试工具 161
7.8 软件测试的基本思想 163
7.9 测试文档 164
7.8.1 杜绝不可靠的软件产品 164
7.9.1 测试计划(Test Plan) 165
7.9.2 测试说明书(Test Specification) 166
7.9.3 测试用例(Test Case) 167
7.9.4 Bug报告(Bug Report) 168
7.9.5 测试结果报告(Test Result Report) 168
7.9.6 工作报告(Status Report to Boss) 170
7.10 如何成为优秀的测试工程师 171
7.11 总结 172
第8章 案例分析:XML Web Service和开发过程管理 173
8.1 概述 174
8.2.1 软件架构的发展过程 175
8.2 NET框架和XML Web Service技术简介 175
8.2.2 微软.NET框架简介 176
8.2.2.1 客户端应用程序开发 177
8.2.2.2 服务器应用程序开发 178
8.2.2.3 .NET的互操作性 178
8.2.3 XML Web Service简介 178
8.2.3.1 XML Web Service基础结构 180
8.2.3.2 基于XML Web Service的应用模型 181
8.2.3.3 XML Web Service的消息结构 181
8.3.1.1 游戏概述 183
8.3.1 开发者的游戏：Terrarium(生态系统游戏) 183
8.3 体验XML Web Service技术 183
8.3.1.2 用户界面 184
8.3.1.3 XML Web Service 185
8.3.1.4 对等网络 186
8.3.1.5 支持多种编程语言 187
8.3.1.6 通过远程Web Service更新版本 187
8.3.1.7 凭据验证和代码访问安全性 187
8.3.1.8 结论 188
8.3.2 西安交通大学“联网拱猪”游戏 188
8.3.3 重庆大学“MyBank.Net”网上银行系统 189
8.3.4 上海交通大学“自动化图书馆”系统 191
8.3.5 XML Web Service在连锁餐厅中的应用 193
8.4 体验软件开发过程管理 194
8.4.1 制定项目的前景目标 195
8.4.1.1 微软公司对技术方向的把握 195
8.4.1.2 项目前景目标示例 196
8.4.2 组建项目组 196
8.4.3 编写功能说明书 198
8.4.3.1 Message Board功能说明书 198
8.4.3.2 “联网拱猪”游戏的功能说明书 200
8.4.5.1 MiniWord测试用例 203
8.4.4 里程碑管理 203
8.4.5 测试和Bug管理 203
8.4.5.2 “联网拱猪”游戏的自动化测试记录 205
8.5 结论 206
第9章 案例分析：面向自然用户界面的语音技术 207
9.1 语音技术概述 208
9.1.1 语音技术是自然用户界面技术的重要组成部分 208
9.2 语音识别技术 209
9.2.1 语音识别技术的不同应用模式 210
9.2.2 语音识别技术在软件开发中的应用 211
9.2.4 如何评估语音识别系统 212
9.2.3 语音识别的核心算法 212
9.2.5 语音识别系统的主要功能 213
9.2.6 语音识别技术面临的挑战 213
9.2.7 应用案例：情感分析 214
9.2.8 应用案例：语音留言(Voice messages)的自动处理 215
9.2.9 应用案例：自动会议记录(Meeting transcription) 215
9.3 语音合成技术 216
9.3.1 语音合成技术的应用 217
9.3.2 语音合成的技术环节 217
9.3.3 语音合成系统的评价标准 217
9.3.5 木兰语音合成系统 219
9.3.4 语音合成系统的优势 219
9.3.6 应用案例：声音变形技术在童话故事中的应用 220
9.4 微软语音开发平台 220
9.5 SAPI简介 221
9.5.1 API概述 221
9.5.2 语音合成API 221
9.5.3 语音识别API 222
9.5.4 文法格式(Text Grammar Format)简介 224
9.6 Microsoft.NET Speech SDK简介 224
9.6.1 为什么要开发Microsoft.NET Speech SDK 224
9.6.2 Microsoft.NET Speech SDK概述 225
9.7 SALT简介 226
9.7.1 SALT是什么 226
9.7.2 SALT如何工作 227
9.7.3 SALT参考模型 228
9.7.4 SALT代码示例 228
9.8 总结 229
第10章 信息技术的展望 230
10.1 前言 231
10.2 IT技术的发展趋势 231
10.2.1 Intemet的发展 231
10.2.2 计算的发展 232
10.2.3 物理学三大定律 234
10.2.4 计算的四大定律 235
10.2.5 新数字媒体渐成主流 236
10.2.6 X-Intemet时代即将到来 239
10.2.7 无线通信、多媒体及Intemet的融合 240
10.2.8 多模式用户界面 242
10.2.9 数字娱乐成为主流应用 244
10.2.10 高信度计算 246
10.3 微软亚洲研究院及其研究成果 247
10.3.1 微软公司的企业使命 247
10.3.2 微软研究院 248
10.3.3 微软亚洲研究院 249
10.3.4 微软亚洲研究院的主要研究方向 250
10.3.5 木兰双语种语音合成系统 250
10.3.6 数字墨水技术 251
10.3.7 消费者数字体验 253
10.3.8 媒体搜索、提取和浏览的核心技术 256
10.3.9 数字娱乐 258
10.4 中国软件产业的发展 261
10.4.1 软件的服务化趋势 262
10.4.2 软件的国际化趋势 264
10.4.3 中国IT产业面临的机遇和挑战 265
10.5 总结 267