快速开发最佳软件
点击看大图基本信息
- 原书名： Better software faster
- 原出版社： Pearson
- 作者： （英）Andy Carmichael Dan Haywood [作译者介绍]
- 译者： 詹梅 杨卫东 等
- 丛书名： 软件工程丛书
- 出版社：电子工业出版社
- ISBN：7505396714
- 上架时间：2004-4-22
- 出版日期：2004 年3月
- 开本：16开
- 页码：372
- 版次：1-1
- 所属分类：
计算机 > 软件工程及软件方法学 > 综合
内容简介回到顶部↑
本书的主要目标是使开发团队用最小的预算获得最大的帮助，开发出最佳的软件。本书向你推荐了一种轻量级、灵活的软件开发过程：刚刚够用的过程，刚刚够用的形式，以及刚刚够用的文档。本书全篇贯穿了四大主题：只维护一个单源模型；最小元模型；扰乱改变模型；持续的质量测量，主要讲述的是如何使用Together这一软件开发平台帮助您在更短的时间内交付同样质量或更高质量的软件，即快速开发最佳软件。
本书适合于软件开发团队、团队领导和项目经理，尤其是将Java或类似的面向对象语言作为程序设计语言的软件开发团队使用，也适于教师、学生、培训人员及顾问做参考手册。
本书适合于软件开发团队、团队领导和项目经理，尤其是将Java或类似的面向对象语言作为程序设计语言的软件开发团队使用，也适于教师、学生、培训人员及顾问做参考手册。
作译者回到顶部↑
本书提供作译者介绍
Andy Carmichael：在软件工程领域工作了20年，专门研究软件开发方法和工具。在担任TogetherSoft公司的专业服务主管及欧洲和英国的技术服务主管期间，与Dan Haywood合作编写了《快速开发最佳软件》。他还编写了其他两本书：《对象开发方法》和《开发业务对象》。他是“Application Development Advisor”杂志的技术编辑。
Dam Haywood：作为一名独立的顾问和Sybase专业服务顾问，在大大小小的软件开发项目中工作超过12年。
.. << 查看详细
Dam Haywood：作为一名独立的顾问和Sybase专业服务顾问，在大大小小的软件开发项目中工作超过12年。
.. << 查看详细
目录回到顶部↑
第1章 together——与众不同之处
1.1 现在需要together
1.2 本书所蕴含的原则
1.3 为什么说together是一种令人激动的技术
1.3.1 维护单源模型（live source技术）
1.3.2 通过配置管理控制协作
1.3.3 烦琐事务的自动化
1.3.4 使用模式传播专家经验
1.3.5 持续的质量监控和反馈
1.4 过程、过程，自始自终
1.4.1 只构造所需要的
1.4.2 要素
1.4.3 非线性生命周期总是处于过程之中
1.4.4 最小元模型
1.5 下章内容
第2章 最后的步骤：部署和运行
2.1 轿车服务（carserv）系统
2.1.1 cloudscape（云图数据库）
2.2 演化的系统
2.3 检查单个模型
1.1 现在需要together
1.2 本书所蕴含的原则
1.3 为什么说together是一种令人激动的技术
1.3.1 维护单源模型（live source技术）
1.3.2 通过配置管理控制协作
1.3.3 烦琐事务的自动化
1.3.4 使用模式传播专家经验
1.3.5 持续的质量监控和反馈
1.4 过程、过程，自始自终
1.4.1 只构造所需要的
1.4.2 要素
1.4.3 非线性生命周期总是处于过程之中
1.4.4 最小元模型
1.5 下章内容
第2章 最后的步骤：部署和运行
2.1 轿车服务（carserv）系统
2.1.1 cloudscape（云图数据库）
2.2 演化的系统
2.3 检查单个模型
前言回到顶部↑
◣ 编写本书的目的是什么
强迫你改变工作方式的产品和激发你以不同方式工作的产品存在着巨大的区别。被迫以“别人的”方式工作很不舒服，并且效率低下；自由地发现较好的工作方式令人愉快，并且能够将新的思想注入别的方法以完成工作。
我们编写本书的缘由是称为Together ControlCentre的产品，以及它所支持的不同的工作方式。我们不只是为Together的用户编写此书，也希望，与其竞争的开发平台或没有使用开发平台的用户也能够从中获益。但是，我们承认，本书的灵感来自Together。
你并不是经常能碰到“鼓舞人心的”产品，对于大多数用户而言，Together似乎正是这样的产品。相比较于先前的、具有代表性的建模和代码生成工具，Together无疑是革命性的。对于我们而言，Together ControlCentre使我们重新考虑开发团队如何协同工作。因此，本书的目的之一就是Together如何帮助你在更短的时间内交付同样质量或更高质量的软件——简而言之，即如何快速开发最佳软件。
◣ 本书的读者是谁
本书是为软件开发团队、团队领导，以及他们的经理人员而编写的——尤其是将Java或类似的面向对象语言作为其程序设计语言的小团队。
小团队，其开发人员的人数多于两个，少于12个。小的团队没有必要为了管理的需要进一步细分。它的日常性管理开支最小，且组成人员彼此之间非常熟悉——至少在项目开始的几个月之后是这样。相对于大规模团队，尽管他们的资源较少，但这些特点给他们带来了很大的优势。项目失败的可能性会随着开发团队规模的扩大而显著增加*。这就是为什么大量的商业软件（如果不是大多数）是由小的团队开发而成的。
小团队没有必要使用著名的软件开发过程。本丛书的其他书用于帮助各种各样著名过程的实践者，诸如FDD（Palmer & Felsing 2002），XP（Astels, Miller, & Novak 2001），以及UP（Norman & Kranz, 正在发行）成功地应用它们。但是，本书更多地推荐使用最简单的方式完成任务，同时，又从很多更为正式的过程中，汲取最好的思想和建议。我们的目标是使开发团队用最小的预算获得最大的帮助。
本书主要是为用Java实现软件的那些人员而编写的。我们希望这不会阻止那些使用C++、C#和VB.NET的人员从本书中寻求知识。但是，在这里我要向他们道歉，本书通篇使用了Java的例子，我们所提供的可供下载的用例研究也是用Java编写的，并且，分布式系统和持久性的讨论专门使用了Java环境，尤其是J2EE体系结构。
当然，我们希望很多其他的人对本书感兴趣：大规模团队中的人员或使用其他语言的人员。这些人包括业务分析人员、用户、测试人员，甚至是学生、教师、培训人员、顾问。但是，本书是为技术（软件开发）人员，而不是非技术人员而编写的。最好的项目往往是这样的：对于在给定的时间内能完成哪些功能，在业务和技术人员中存在一种信任。根据我们的经验，当业务代表和用户真正对开发过程感兴趣，甚至在某些情况下作为项目成员加入到开发团队的时候，能够最好地建立起这种信任。我们确实讨论了在开发过程的某些阶段，业务代表和用户主动进行参与，尤其是在建模问题领域、需求说明及排出需求优先顺序的时候。在这些地方及其他方面，我们希望本书能够为增进技术团队和非技术团队之间的相互理解做出贡献。因此，如果你认为你是非技术人员，那么，我们希望你了解一些Together能做什么，以及通过使用它如何更有效地开发软件。
◣ 本书是如何组织的
第1章“Together —— 与众不同之处”，讲述了Together为什么是一个令人激动的技术。在这里，我们并不对市场包装感兴趣。与其他平台相比，Together的确与众不同，并且展示了新的潜在的价值。我们想深入了解它到底是什么，以及为什么使团队表现得如此不同凡响。在第1章中，我们也介绍了贯穿全书大部分章节的四个重要的主题：
■ 只维护一个单源模型
■ 最小元模型
■ 扰乱改变模型
■ 持续的质量测量
只维护一个单源模型是基于这样一种思想：尽管以多种形式查看和修改，系统的信息应该仅在一个地方保存而且只维护一次。
最小元模型是任何开发过程中需要定义和有效交叉引用的最基本元素的一个视图，这些开发过程包括需求、测试、设计和实现。
扰乱改变模型是指在一个小的迭代步骤中，按照从一个有效的构造转移到下一个有效的构造，考虑开发过程的一种方法。这并不是一个不同的开发过程，而是考虑大多迭代演化开发过程的一种方法。
持续的质量测量是迭代演化生命周期不可或缺的部分。与瀑布生命周期相比，不同的是，它强调开发的活动和工具环境。
强迫你改变工作方式的产品和激发你以不同方式工作的产品存在着巨大的区别。被迫以“别人的”方式工作很不舒服，并且效率低下；自由地发现较好的工作方式令人愉快，并且能够将新的思想注入别的方法以完成工作。
我们编写本书的缘由是称为Together ControlCentre的产品，以及它所支持的不同的工作方式。我们不只是为Together的用户编写此书，也希望，与其竞争的开发平台或没有使用开发平台的用户也能够从中获益。但是，我们承认，本书的灵感来自Together。
你并不是经常能碰到“鼓舞人心的”产品，对于大多数用户而言，Together似乎正是这样的产品。相比较于先前的、具有代表性的建模和代码生成工具，Together无疑是革命性的。对于我们而言，Together ControlCentre使我们重新考虑开发团队如何协同工作。因此，本书的目的之一就是Together如何帮助你在更短的时间内交付同样质量或更高质量的软件——简而言之，即如何快速开发最佳软件。
◣ 本书的读者是谁
本书是为软件开发团队、团队领导，以及他们的经理人员而编写的——尤其是将Java或类似的面向对象语言作为其程序设计语言的小团队。
小团队，其开发人员的人数多于两个，少于12个。小的团队没有必要为了管理的需要进一步细分。它的日常性管理开支最小，且组成人员彼此之间非常熟悉——至少在项目开始的几个月之后是这样。相对于大规模团队，尽管他们的资源较少，但这些特点给他们带来了很大的优势。项目失败的可能性会随着开发团队规模的扩大而显著增加*。这就是为什么大量的商业软件（如果不是大多数）是由小的团队开发而成的。
小团队没有必要使用著名的软件开发过程。本丛书的其他书用于帮助各种各样著名过程的实践者，诸如FDD（Palmer & Felsing 2002），XP（Astels, Miller, & Novak 2001），以及UP（Norman & Kranz, 正在发行）成功地应用它们。但是，本书更多地推荐使用最简单的方式完成任务，同时，又从很多更为正式的过程中，汲取最好的思想和建议。我们的目标是使开发团队用最小的预算获得最大的帮助。
本书主要是为用Java实现软件的那些人员而编写的。我们希望这不会阻止那些使用C++、C#和VB.NET的人员从本书中寻求知识。但是，在这里我要向他们道歉，本书通篇使用了Java的例子，我们所提供的可供下载的用例研究也是用Java编写的，并且，分布式系统和持久性的讨论专门使用了Java环境，尤其是J2EE体系结构。
当然，我们希望很多其他的人对本书感兴趣：大规模团队中的人员或使用其他语言的人员。这些人包括业务分析人员、用户、测试人员，甚至是学生、教师、培训人员、顾问。但是，本书是为技术（软件开发）人员，而不是非技术人员而编写的。最好的项目往往是这样的：对于在给定的时间内能完成哪些功能，在业务和技术人员中存在一种信任。根据我们的经验，当业务代表和用户真正对开发过程感兴趣，甚至在某些情况下作为项目成员加入到开发团队的时候，能够最好地建立起这种信任。我们确实讨论了在开发过程的某些阶段，业务代表和用户主动进行参与，尤其是在建模问题领域、需求说明及排出需求优先顺序的时候。在这些地方及其他方面，我们希望本书能够为增进技术团队和非技术团队之间的相互理解做出贡献。因此，如果你认为你是非技术人员，那么，我们希望你了解一些Together能做什么，以及通过使用它如何更有效地开发软件。
◣ 本书是如何组织的
第1章“Together —— 与众不同之处”，讲述了Together为什么是一个令人激动的技术。在这里，我们并不对市场包装感兴趣。与其他平台相比，Together的确与众不同，并且展示了新的潜在的价值。我们想深入了解它到底是什么，以及为什么使团队表现得如此不同凡响。在第1章中，我们也介绍了贯穿全书大部分章节的四个重要的主题：
■ 只维护一个单源模型
■ 最小元模型
■ 扰乱改变模型
■ 持续的质量测量
只维护一个单源模型是基于这样一种思想：尽管以多种形式查看和修改，系统的信息应该仅在一个地方保存而且只维护一次。
最小元模型是任何开发过程中需要定义和有效交叉引用的最基本元素的一个视图，这些开发过程包括需求、测试、设计和实现。
扰乱改变模型是指在一个小的迭代步骤中，按照从一个有效的构造转移到下一个有效的构造，考虑开发过程的一种方法。这并不是一个不同的开发过程，而是考虑大多迭代演化开发过程的一种方法。
持续的质量测量是迭代演化生命周期不可或缺的部分。与瀑布生命周期相比，不同的是，它强调开发的活动和工具环境。
加载中...
