书
名：
Visual Studio Team System
软件工程实践
出
版
社：机械工业出版社
丛
书
名：
著
译
者：
苏南
等
原著书名：
Software Engineering with Microsoft Visual Studio Team System
原著作者：
Sam Guckenheimer; Juan J. Perez
书
号：
7-111-20758-0
责任编辑：
杨庆燕
出版日期：
2007-02
估
价：36.00元
光
盘：
有
开
本：
16
开
页
码：
字
数：
内容提要
·Amazon前50名超级畅销书
·微软公司授权光盘附增VSTS试用版
·微软公司选定的培训教材
·为准备使用VSTS的开发团队量身定做
本书不讲述如何具体操作VSTS，而讲述VSTS的思想及其实践。本书不仅包括了最新的软件工程领域的思想和概念，还为软件开发提出了一种崭新的思维方式——价值增加。价值增加本书的核心思想，同时也是VSTS的核心设计理念。
本书理论与实例并重，图文并茂，运用大量实例详实地论述了如何将最现代的软件工程思想和价值增加的思想应用到需求、项目管理、架构设计、开发和测试等软件开发生命周期中的各个领域中。
本书适合那些正在考虑使用Visual Studio Team System（VSTS）来管理软件项目的团队阅读，也可供软件项目管理人员、开发团队成员学习参考。
读者能够通过本书了解到使用VSTS所必需的知识，包括：
n 价值增加的思维（相对于工作消减）在软件开发生命周期中的角色，以及“流”的意义和重要性
n 用于敏捷软件开发的MSF和用于CMMI过程改进的MSF的应用。
n VSTS中用于计划和管理待处理队列（backlog）的工作项
n 多维的每日度量维护了项目的流，也为估计提供了参考数据
n 使用人物和应用场景来创建需求
n 使用迭代、可信任的透明度和无矛盾的度量来管理项目
n 使用价值增加的观点、面向服务的架构、约束和服务质量来进行架构设计
n 使用单元测试、代码覆盖度、特征分析和构建自动化来进行开发
n 使用应用场景、服务质量、配置、数据、探索和度量来测试客户价值
n 高效地进行缺陷报告和缺陷评估
n 项目问题解析：识别和纠正共同的隐患和反模式
这是那些正在使用或考虑使用VSTS的团队应该阅读的一本书。
专家评论
“这是一本的关于软件工程的第一流著作。在对计划、文档、管制、审计能力和组织等闪光点的讨论中，Sam分别展示了敏捷的和较正式的两种实践的情况，并且还描述了每种情况的理想条件。虽然展示的是使用VSTS的情境，但是其指导性是普遍适用的。”
——
Bill Curtis博士
Borland
软件集团首席过程官
“Sam Guckenheimer把我们引入到一个值得信任的透明度的年代，这将对我们管理软件开发项目的方式进行一场革命。”
——
David J. Anderson
《Agile Management for Software Engineering》的作者
“本书让我们开阔了眼界：打开了通往软件工程新时代的大门。”
——Francis T. Delgado
Avanade
公司资深规划经理
目录
译者序
序言
前言
第1章价值增加的思维方式
1
1
思维变迁
1
1
1
有待和谐的三股力量
1
1
2
什么软件值得构建
1
2
思维方式的对比
1
3
对流的关注
1
3
1
与工作消减的对比
1
3
2
透明度
1
4
一个工作项数据库
1
5
使过程适合于项目
1
6
小结
参考文献
第2章价值增加的过程
2
1
微软解决方案框架
2
2
迭代
2
2
1
为什么迭代
2
2
2
长度
2
2
3
不同的视野，不同的粒度
2
2
4
优先排序
2
2
5
修改过程
2
3
风险管理
2
4
让过程适合项目
2
4
1
自适应与计划驱动
2
4
2
要求的文档与隐含的知识
2
4
3
隐式与显式的审核关卡和
管理模型
2
4
4
审计与法规关注
2
4
5
规定的组织与自组织
2
4
6
一次一个项目与一次
多个项目
2
4
7
地理边界与组织边界
2
5
小结
参考文献
第3章需求
3
1
什么是你的愿景
3
1
1
战略项目
3
1
2
自适应项目
3
2
何时细化需求
3
2
1
需求是易变质的
3
2
2
谁关心需求
3
3
人物和应用场景
3
3
1
从人物开始
3
3
2
应用场景
3
3
3
研究技术
3
3
4
提早具体化
3
3
5
故事板
3
3
6
应用场景的宽度
3
3
7
客户验证
3
3
8
制定应用场景
3
4
人物、应用场景及它们的替代
术语
3
4
1
参与者和用例
3
4
2
用户故事
3
5
兴奋点、满意点和不满意点
3
6
服务质量
3
6
1
安全性和隐私
3
6
2
性能
3
6
3
用户体验
3
6
4
可管理性
3
7
卡诺分析
3
7
1
技术接受生命周期
3
7
2
收集数据
参考文献
第4章项目管理
4
1
理解偏差
4
2
使用描述性的而非规定性的
度量元
4
3
项目健康的多个维度
4
4
回答日常问题
4
4
1
剩余工作
4
4
2
项目速度
4
4
3
计划外工作
4
4
4
质量指示器
4
4
5
缺陷率
4
4
6
重新激活
4
4
7
缺陷的优先级
4
4
8
实际质量与计划速度
4
5
估计迭代
4
5
1
自顶向下
4
5
2
自底向上
4
5
3
精细化
4
5
4
估计的质量
4
5
5
回顾
4
6
优先分配
4
6
1
优先分配的实验
4
6
2
什么让优先分配有效率：
红线
4
6
3
在优先分配中发生了什么
4
6
4
逐步增强和解决问题
4
6
5
迭代和优先分配
4
7
让审计者满意
4
8
小结
参考资料
第5章架构设计
5
1
架构的价值增加观点
5
2
面向服务的架构
5
2
1Web
服务和SOA
5
2
2
契约优先的设计
5
3
自由度的约束
5
3
1
基线架构
5
3
2
验证架构决策
5
3
3
精细化基线
5
3
4
参考架构
5
4 VSTS
和面向服务的架构
5
5
服务质量的理念
5
5
1
安全性
5
5
2
性能
5
6
公民权理念
5
7
针对运行而设计
5
8
小结
参考文献
第6章开发
6
1
开发的价值增加观
6
2
从开发者的视点看质量
6
3
使用测试驱动的开发来确保需求
的清晰
6
4
通过自动和手动代码评审来解决
编程错误
6
4
1
自动的代码分析
6
4
2
手动的代码评审
6
5
用单元测试和代码覆盖度提供
立即的反馈
6
5
1
先测试还是先编码？
6
5
2
代码覆盖度
6
6
使单元测试更好
6
6
1
使用数据
6
6
2
配置
6
6
3
构件集成测试
6
6
4
构建确认测试
6
6
5
性能调整
6
7
防止版本扭曲
6
7
1
签入
6
7
2
搁置
6
7
3
分支
6
7
4
哪些文件需要版本管理
6
7
5
自动化构建
6
8
让工作保持透明
6
9
小结
参考文献
第7章测试
7
1
测试的价值增加观
7
2
基本问题
7
3
我们交付了客户价值吗
7
3
1
自动应用场景测试
7
3
2
让你的测试与UI变更无关
7
4
服务质量适合使用吗
7
4
1
负载测试
7
4
2
安全性测试
7
4
3
易用性测试
7
5
我们测试了变更吗
7
6
我们没测试过什么吗
7
6
1
需求
7
6
2
代码
7
6
3
风险
7
7
软件在生产环境和实验室环境中
运行一样吗
7
8
我们测试的足够吗
7
8
1
定义“足够好”
7
8
2
探索测试
7
8
3
为发现而测试
7
8
4
错误的自信
7
9
我们什么时候应当测试
7
9
1
签入循环
7
9
2
每日构建循环
7
9
3
验收构建循环
7
9
4
迭代循环
7
9
5
项目循环
7
10
哪些测试应当自动化
7
11
我们的团队或外包团队的效率
怎么样
7
12
小结
参考资料
第8章报告缺陷
8
1
警示性的故事
8
2
软件缺陷的生命周期
8
2
1
报告缺陷就像写新闻
8
2
2
主观数据
8
2
3
客观数据
8
2
4
评估数据
8
2
5
计划
8
3
小结
参考资料
第9章项目问题解析
9
1
低估
9
1
1
不均匀的任务分解
9
1
2
架构盲点
9
1
3
范畴蠕变
9
1
4
不充分的缺陷分配
9
1
5
资源漏洞
9
2
开发实践过于松弛
9
2
1
构建失败
9
2
2
不充分的单元测试
9
2
3
重新激活
9
2
4
虚报
9
3
测试通过了，解决方案却不能
工作
9
3
1
高缺陷发现率
9
3
2
测试失去时效性
9
4
解决方案停留在测试
9
4
1
测试失败
9
4
2
过少的测试
9
5
小结
参考资料
第10章总结
10
1
预料中的批评
10
2
再论价值增加
参考资料
3224
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
