Software engineering with microsoft Visual Studio Team System
副标题：无
作 者：(美)Sam Guckenheimer，(美)Juan J. Perez著;苏南，贺洁等译
分类号：
ISBN：9787111207580
微信扫一扫,移动浏览光盘
简介
本书不讲述如何具体操作vsts，而讲述vsts的思想及其实践。本书不仅包括了最新的软件工程领域的思想和概念，还为软件开发提出了一种崭新的思维方式——价值增加。价值增加本书的核心思想，同时也是vsts的核心设计理念。.
本书理论与实例并重，图文并茂，运用大量实例详实地论述了如何将最现代的软件工程思想和价值增加的思想应用到需求、项目管理、架构设计、开发和测试等软件开发生命周期中的各个领域中。本书适合软件项目管理人员、开发人员参考。
本书论述了软件开发价值增加的思维方式。这一思维方式构成了vsts的基础，包括vsts的指导思想，为什么这些指导思想会以某些方式表现，以及它们如何才能与管理软件生命周期的过程紧密结合。本书如同一个现场教练，带领开发团队以一贯的流程走完整个软件生命周期。
读者通过学习本书能够了解使用vsts所必需的知识，包括：
■ 价值增加的思维（相对于工作消减）在软件开发生命周期中的角色，以及“流”的意义和重要性。..
■ 用于敏捷软件开发的msf和用于cmmi过程改进的msf的应用。
■ vsts中用于计划和管理待处理队列（backlog）的工作项。
■ 多维的每日度量维护了项目的流，也为估计提供了参考数据。
■ 使用人物和应用场景来创建需求。
■ 使用迭代、可信任的透明度和无矛盾的度量来管理项目。
■ 使用价值增加的观点、面向服务的架构、约束和服务质量来进行架构设计。
■ 使用单元测试、代码覆盖度、特征分析和构建自动化进行开发。
■ 使用应用场景、服务质量、配置、数据、探索和度量来测试客户价值。
■ 高效地进行缺陷报告和缺陷评估。
■ 项目问题解析：识别和纠正共同的隐患和反模式。...
目录
译者序
序言
前言
第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再论价值增加
参考资料
序言
前言
第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再论价值增加
参考资料
Software engineering with microsoft Visual Studio Team System
- 名称
- 类型
- 大小
光盘服务联系方式: 020-38250260 客服QQ：4006604884
云图客服：
用户发送的提问，这种方式就需要有位在线客服来回答用户的问题，这种 就属于对话式的,问题是这种提问是否需要用户登录才能提问
Video Player
×
Audio Player
×
pdf Player
×
亲爱的云图用户，
光盘内的文件都可以直接点击浏览哦
无需下载，在线查阅资料！
