全面讲解如何构建稳定可靠的软件
　　《软件工程入门经典》揭秘专业开发人员为设计和构建稳定、可靠、高效软件所运用的软件工程技术和方法。本书通俗易懂，在大量案例的引导下，演示适用于任何编程语言的重要概念和技术；即使你目前不具有编程、开发和管理经验，同样可以阅读和学习本书。每章末尾附有精选习题，以测试你对知识的理解程度，引导你悟透主要概念。本书全面介绍了瀑布、生鱼片、敏捷、RAD、Scrum、看板和极限编程等各种开发方法所涉及的基本任务。
　　主要内容
　　◆详述软件工程概念
　　◆阐释参与软件工程项目的团队成员的角色和职责
　　◆指出软件工程项目都必须经历哪些重要阶段才能开发出功能卓越的可靠应用程序
　　◆详述主流软件开发方法及其处理重要开发任务的不同方式
　　◆提供从每章主要知识点引申的习题
　　◆附有详明的软件工程术语表

　◆详述软件工程概念
　　◆阐释参与软件工程项目的团队成员的角色和职责
　　◆指出软件工程项目都必须经历哪些重要阶段才能开发出功能卓越的可靠应用程序
　　◆详述主流软件开发方法及其处理重要开发任务的不同方式
　　◆提供从每章主要知识点引申的习题
　　◆附有详明的软件工程术语表

　　前 言
　　如今的编程是“程序员正努力创建一个更大更傻的程序”和“世界在尝试创造更多更傻的人”之间的一种角逐。到目前为止，后者是赢家。
　　——Rick Cook
　　借助一些现代开发工具，不需要事先设计和计划，坐在键盘旁就可以敲打出一个可以工作的程序。某些情况下，这还是可行的。我的VB Helper(www.vb-helper.com)和C# Helper(www. csharphelper.com)站点就包含了数以千计的Visual Basic和C#示例程序——这些程序正是通过这样的方法进行创建的。每当我有一个想法(或是别人向我提出一个问题时)，我都会敲击出一个简单示例程序。
　　如果只有你自己使用而且只是短期使用这些程序，那么还好。如果只用于实验，演示一些编程技巧，那么也还好。
　　如果是将这种草率粗糙的程序用于生产，其结果将是灾难性的。即便作最乐观的估计，使用这些程序的非编程员也将很快束手无策。最糟的情况下，它们可以破坏计算机，甚至严重影响你和朋友、同事之间的关系。
　　即使经验最丰富的开发人员有时也会被这种不靠谱的程序弄得焦头烂额。我知道有人(我不想指名道姓，但我绝不会干这种事情)编写一些简单的递归脚本来删除某个目录层次中的文件。遗憾的是，这样的脚本将以递归方式爬行到目录树顶部，然后幸灾乐祸地删除系统中的每个文件。这种脚本在停止前仅运行大约5秒钟，但它已经破坏了足够多的文件，从而导致必须重新安装操作系统(实际上，一些开发人员认为每隔一年左右重装一次操作系统是在锻炼意志力。如果认同这样的看法，不妨尝试一下)。
　　我还认识一位经验丰富的开发人员。她在测试Windows系统设置时，曾设法把每种系统颜色都设置为黑色，结果却导致黑色光标悬停在黑色的桌面上，显示的是带有黑色边框、菜单以及文本的黑色窗口。此人(不是我)最终通过重启的方式，通过另一台色彩正常的计算机，仅通过键盘快捷键修复了颜色设置。这确实是明智的胜利，但我怀疑她宁愿没有发生这件事，也不情愿白白浪费两天的时间。
　　对于那些代码量比较大或者是面向可信赖终端用户的程序而言，这种自由散漫的开发方式并不适用。为编写出安全、有效、可靠的应用程序，不能只坐下来敲敲键盘。你需要“软件工程”。
　　本书主要介绍软件工程。它将向我们阐释软件工程是什么以及如何借助它创建高效、灵活、健壮的应用程序。
　　本书不能使你成为专家级的系统分析师、软件架构师、项目经理或程序员，却向我们阐释了这些人做什么，以及对于高质量的软件开发而言，他们为什么是不可或缺的。本书介绍了一些入门级工具。你不用一个人去“战斗”，或是带领1000人给FAA开发一个航空交通管制系统，但它的确有助于在不同规模的开发项目中高效工作(当你的老板意味深长地说“是啊，我们主要使用的是深度结合了XP技术的敏捷开发”时，它也有助于你悟透这句话中的“玄机”)。
　　软件工程的概念
　　软件工程的比较正式的一个概念可能为：“设计、开发、使用、维护软件的结构化分析方法。”
　　更直观地讲，软件工程是成功的软件开发所需要的一切，它包含将可能模糊不清、不成熟的想法转变成为一个强大、直观的应用程序需要的所有步骤，从而能够更好地满足用户未来日益变化的需求。
　　当设计应用程序时，可能仅把软件工程视为上述过程的开始部分。毕竟，一个航空工程师只是设计飞机但不建造它们，或者是当第一个客舱满员后再添加一个(尽管这里我设想的是使用背负在747这类飞机上的航天飞机来达到上述目的)。
　　软件工程和航天工程(或者是其他类型的工程)一个很大的区别在于：软件不是物理的。它只存在于计算机虚拟的世界里。这意味着很容易就能对程序的任何部分进行修改，即使是在它彻底完成的情况下。相比之下，如果是等到一座桥梁建造完成后，才告诉结构工程师你决定另外添加两个车道。他肯定会喋喋不休地提供各种富有创意但脱离实际的建议。
　　软件的虚拟特性所带来的灵活性是一把双刃剑。有利之处是：能够在开发的过程中精益求精，从而更好地满足用户的需求，如增加新特性、充分利用实现过程中所发现的一切有利之机、修改以适应不断变化的业务需求，甚至允许一些应用程序让用户自己编写脚本，执行连开发人员都意想不到的新任务。对于其他类型的工程而言，这种灵活性是不可能达到的。
　　遗憾的是：这种允许在软件项目生命周期中进行修改的灵活性，也能够在开发过程中的任何一点上把事情弄糟。增加一个新特性可能中断现有的代码，或者是把一个简洁、优雅的设计变成一个无法收拾的乱摊子。在开发过程中，不停地添加、删除以及修改一些功能也使得系统的不同部分不能够协调一致的工作。一些情况下，甚至不可能知道软件的具体完成时间。
　　由于软件具有很好的可拓展性，因此直到项目结束的任何一点上，都可以进行设计决策。事实上，在最初的发行后，成功的应用程序通常会继续演化很长时间。例如，微软的Word已经演化了近30年的时间(有时会变得很好，有时则很糟。还记得微软办公系统中的那个大眼回形针助手吗？它是变得更好还是更糟呢？反正我是有一段时间没看见它了)。
　　随时都可以进行修改的事实，意味着需要把整个开发过程视为单一、长期的复杂任务。不能只“策划”一个宏伟的设计，让程序员不辞辛苦地完成所有任务。最宏观的那些设计决策可以提前制定，软件开发当然要分阶段，但是这些阶段要相互衔接，要通盘考虑。
　　软件工程之所以重要的原因
　　软件开发在概念上相对比较简单：有一个想法，然后将这个想法变成有用的程序。遗憾的是，对于具体的项目而言，一个简单概念有无数种出错的方式。程序员可能并不了解客户的所想和所需，因此他们创建了错误的应用程序，其中充满bug，使用起来令人沮丧，无法修改，也不能进一步完善。这样的程序可能十分高效，但让人迷惑不解，以至于需要解谜的博士学位才能使用它。一个绝对完美的应用程序甚至可能被内部业务策略或市场规律所扼杀。
　　软件工程包含了很多可以用来避免陷阱的技术。否则，这些陷阱可能在将来的某个时候葬送你的项目。它能够确保你的应用程序有效、可用、可维护。它有助于按照计划完成整个项目各主要阶段的任务，并且确保在预算内如期完成整个项目。也许最重要的是：软件工程的这种灵活性，可以让我们在没有完全变更计划和预算的前提下，对软件进行修改，以满足一些非预期的需求。
　　简言之，软件工程有助于控制软件开发过程中所出现的一些意料不到的看似混乱不堪的局面。
　　本书读者对象
　　参与软件开发工作的每个人都应该对软件工程有一个基本的了解，无论是确定软件用途和功能的执行客户(executive customer)，还是最后使用应用程序产品(以及报告bug)的终端客户、监督其他开发人员(不要玩太多《彩球连线》)的首席开发者，或是为每周的会议准备甜甜圈的伙计——你要知道如何整合所有的参与者。这些人中的任何失误(特别是提供甜甜圈的人)都将影响其他人，因此每个人都知道项目正转向灾难的警告标志是至关重要的。
　　本书主要面向那些没有太多经验的软件工程人员。它并不需要你具备软件开发、项目管理以及编程的任何经验(我猜测大多数读者都有一些制作甜甜圈的经验，但这并非必要)。
　　即便对这些主题有一定的认识，特别是编程方面，也可以获益于本书。如果一直关注的只是所在项目的部分主题，为有助于引导该项目走向成功，仍需要了解这些部分之间如何相互影响。
　　例如，在我把开发过程作为一个整体认真看待之前，我已从事过数年的程序员工作，甚至参与了一些较大规模项目的开发工作。我知道其他人在编写用例和部署计划，但我只关注我的那部分工作。直到后来，我在项目中担任了一个较高层的角色，才真正了解该项目的整个过程。
　　本书与如何编程无关。它主要阐释一些可用的编程技巧，例如，如何编写足够灵活的代码，以处理不可避免的软件变更请求；如何让代码更易于调试(至少你的代码将是如此)；如何让你的代码能够在以后更完善和易于维护(面向更多的软件变更请求)。所有这些都是一些概要性内容，并不需要你知道如何编程。
　　如果你从事的并非程序员工作，如终端用户或项目经理，即使不直接使用它，也将发现书中的内容非常有趣。同时，你将惊奇地发现：一些技巧也适用于一些非编程问题。例如，用于生成问题解决方案的方法同样适用于所有类型的问题，并非只有编程决策(也可以这样问开发人员：“你在单元测试前使用断点和黑盒测试吗?”看看他们是否理解你正在谈论的话题)。基本上，你正在使用黑盒测试判断这些开发人员是否了解黑盒测试，详见第8章“测试”。
　　方法
　　本书分为两个部分。第Ⅰ部分主要介绍软件开发的一些基本任务，如设计、编码、测试。本书的第Ⅱ部分主要介绍一些常见的软件开发模型。
　　然而，在能够开始从事软件开发项目工作之前，还是需要准备一下。为了能够在整个项目中保持对进度的跟踪，你需要一些工具和技术。第1章“软件工程概览”主要介绍这些开始前的准备活动。
　　完成这些前期的准备后，可用来进行软件开发的方法有很多。所有这些方法都有一个共同的目标——开发可用的软件，因此它们必须处理近乎相同的任务，如需求收集、制定计划、编写实际代码。本书的第Ⅰ部分主要介绍这些任务。第1章主要对这些任务进行概述；第2章～第11章将详细介绍这些任务，同时将探讨如何有效完成这些任务。
　　本书第Ⅱ部分介绍了一些目前较流行的软件开发方法。所有这些模型都要解决本书前面章节所介绍的相同问题，只不过方式不同。其中的一些模型侧重于可预测性，以便能够了解到底需要提供何种软件功能以及何时提供；而其他一些模型关注的是尽快构建大多数功能，即使这意味着与最初的设计相比有一些偏差。第12章～第14章主要介绍一些最常见的软件开发模型。
　　上述就是本书针对软件工程的基本学习路线。首先，要了解完成软件开发的一些基本任务；然后，了解处理这些任务的一些基本模型。
　　然而，很多人都难以适应罗列式的枯燥学习，为让书中的内容更易于掌握，本书也包含了其他一些元素。书中每一章的后面都附有练习，它们可用来检测对每章内容的掌握程度。我并不喜欢那些只是让人简单复述每章内容的练习(快速问答：软件“缥缈不定”的性质的一些优势和不足是什么？)，大多数练习主要用来对每章的主要内容进行拓展。在学习每一章内容之后，希望大家能够去思考一些新的方法。
　　部分练习是作为某部分内容的补充材料出现的，因此和测试题相比，附录A中的那些问题更像拓展内容和思维实验。
　　强烈推荐至少浏览并思考一下这些问题，然后琢磨一下自己是否理解。所有答案都包含在附录A“习题答案”中。
　　本书主要内容(以及非本书主要内容)
　　本书主要介绍软件工程，例如，完成一个成功的软件项目必须执行的任务，以及用来实现我们目标的一些最常见的开发模型。虽然它并未涵盖每一个细节，但的确对整个软件开发过程进行了详细探讨。
　　本书并未囊括每一个可能的软件模型。事实上，目前软件行业使用的开发模型有数十种(可能数百种)。本书只是对其中最常见的一些开发方法进行了简要介绍。
　　如果打算深入了解某种特殊的软件开发方法，可以求助于很多与它有关的一些书籍和网站。很多开发模型都有自己的推广机构(都有网站)，例如www.extremeprogramming.org、agilemanifesto.org以及www.scrum.org。
　　本书并不是一本有关软件开发技巧和提示的百科全书。它仅介绍了和软件开发有关的一些常见思想和理念，旨在帮助我们轻松地开发更高效、健壮的软件产品。本书主要探讨较高层次上的软件工程问题，所以并未囊括使程序更加完善的所有“窍门”。本书的内容并非针对某种特定的编程语言，所以也不可能使用属于某种特定编程语言的一些工具和技巧。
　　需要的一些工具
　　阅读本书不需要任何工具，需要的是阅读本书的能力(还有眼镜，或者是文本-声音转换工具——如果有本书的电子版；或者是让朋友读给你听；好吧，我猜你有好几种选择)。
　　为了能够真正参与到某个项目的开发中，可能需要很多工具。如果是开发小型的个人项目，则可能只需要像Visual Studio、Eclipse、RAD Studio之类的编程环境。对于比较大型的团队开发而言，还需要项目管理、文档(文字处理)、修改跟踪、软件修订跟踪等其他工具。当然，还需要其他开发人员的帮助。本书将对这些工具一一介绍，但阅读本书不需要这些工具。
　　本书约定
　　为有助于更好地阅读本书，同时跟踪软件工程的一些最新技术，本书使用了以下约定：
　　侧边栏
　　类似这样的侧边栏包含有一些其他方面的信息和主题。
　　警告
　　这种类型的文本框中的内容是和其周围文本有直接关系的重要信息。一个软件项目有多种失败的可能，这些信息提醒你应该避免的一些“最差实践”。
　　注意
　　这些文本框用来表示和当前内容有关的说明、提示、建议、技巧以及旁白。
　　至于文本中的样式：
　　● 键盘敲击的显示方式是这样的：Ctrl+A，这意味着在按下Ctrl(Control或CTL或你键盘上的其他标记方式 )键的同时按下A键。
　　● 本书几乎没有实际的程序代码，因为我并不知道你所使用的编程语言(若有的话)。如果是代码，其显示方式如下：
　　//如果a和b互质，则返回ture
　　private bool AreRelativelyrime(int a, int b)
　　{
　　// Only 1 and -1 are relatively prime to 0.
　　if (a = 0) return ((b == 1) || (b == -1));
　　if (b = 0) return ((a == 1) || (a == -1));
　　int gcd = GCD(a, b);
　　return ((gcd == 1)) || (gcd == -1));
　　}
　　(不必担心不理解上述代码，正文中有解释)。
　　● 文件名称、URL以及文本中出现的少量代码的显示方式是这样的：www.csharphelper.com。
　　勘误
　　我已竭尽全力避免书中的一些错误。本书的文本已经通过了一支小规模的编辑队伍和技术审阅们的审核。然而，正向书中介绍的那样，任何重大的项目无一例外都曾出现过错误。我能期望的最好的结果是：剩下的都是小错误，它们还不至于影响对本书文字的理解。
　　如果在阅读本书的过程发现有错误(像是拼写错误、代码碎片或是不能理解的任何地方)，那么我将非常感激你的反馈。我将通过本书的勘误页面登出你的反馈，这样有利于其他读者更好地理解本书，同时也能帮助我进一步完善此书。
　　如欲查阅本书的勘误页面，请访问www.wrox.com/go/beginningsoftwareengineering，然后在本书详细信息页面上单击Book Errata链接。可以在该页面上查看已提交的和Wrox编辑们张贴的所有勘误信息。你也可以访问www.wrox.com/misc‐pages/booklist.shtml，查看Wrox已出版的所有书籍列表(包含每本书的勘误信息)。
　　如果没有在Book Errata页面发现你提交的错误，请访问www.wrox.com/contact/ techsupport.shtml，并在此页面上完成表格的填写，提交所发现的错误。经过严格训练的编辑们将迅速检查此信息(通过给我发送一封电子邮件)。如果必要，那么他们将马上在本书的勘误页面上张贴勘误信息，并在本书的后续版本中修订相应错误。
　　p2p.wrox.com
　　通过P2P论坛p2p.wrox.com(P2P是指“Programmer to Programmer”，但因为本书并非只针对程序员，因此这里我特意用“Person to Person”进行表示)提交反馈、咨询和本书有关的一些问题也是不错的方法。
　　这些论坛都是基于Web的系统，可以在上面张贴和Wrox书籍以及相关技术有关的一些信息，同其他读者、技术用户以及作者(像是我)互动。这些论坛都提供有订阅功能。每当论坛有新帖提交时，我们选择的感兴趣的话题，将通过电子邮件的形式发送给我们。这些论坛的活跃用户包括Wrox的作者、编辑、其他行业专家以及读者群体。
　　只需要完成以下步骤，就可以加入这些论坛：
　　(1) 访问 p2p.wrox.com，单击Register链接；
　　(2) 阅读使用说明，然后单击Agree；
　　(3) 填写一些必要信息以及你打算提供的可选信息，然后单击 Submit；
　　(4) 你将收到一封有关如何验证账户以及完成加入过程的电子邮件。
　　快来加入论坛
　　不需要加入P2P，就可以阅读论坛信息。但如果要发贴，那么就必须要加入。不用担心Wrox给你的邮箱发送垃圾邮件(至少，他们过去从未如此)。他们这样做的目的只是为了防止一些“网络恶魔”不会冒充你的名字发帖。
　　加入后，就可以发帖，回复其他读者的帖子，并且可以在任何时间阅读网上的信息。如果打算接收某个特殊论坛的新邮件消息，则可以通过论坛列表里的论坛名称，单击Subscribe to this Forum图标。
　　请务必要阅读P2P FAQ上的有关论坛软件如何工作的问答，以及针对P2P和Wrox书籍的一些问答。阅读这些FAQ，请单击P2P页面上的FAQ链接。
　　这些P2P论坛让其他读者能够从你的问题及其解答中受益。我也非常关注本书的论坛，只要能够提供帮助，就一定会予以回应。
　　一些重要的URL
　　下面列举和本书有关的一些重要URL：
　　● www.wrox.com/go/beginningsoftwareengineering——本书的网页。
　　● p2p.wrox.com——Wrox P2P论坛。
　　● www.wrox.com——Wrox的网站，包含有勘误和其他信息。可以通过书名或ISBN检索。
　　● RodStephens@CSharpHelper.com——我的电子邮件地址。让我们保持联系吧！
　　● www.CSharpHelper.com——我的C#站点，包含有数以千计的针对C#开发人员的提示、技巧以及示例。
　　● www.vb-helper.com——我的Visual Basic站点，包含有数以千计的针对Visual Basic开发人员的提示、技巧以及示例。
　　联系作者
　　如果有任何问题、意见或建议，都可以给我发送电子邮件(RodStephens@CSharpHelper.com)。我不敢保证能帮助你解决每一个问题，但我承诺将尽力帮助你。
　　免责声明
　　软件工程并非总是最激动人心的话题，所以为了能让读者保持头脑清醒并且兴趣盎然，书中所选择的一些示例都极具幽默色彩。如果你将本书置于床头，作为失眠治疗的最后一剂良药，那么我就失败了。
　　那些极具才华的软件工程师不必阅读本书。我并没有不尊重他们的意思，因为要为客户开发高质量的应用程序，他们要长期工作(至于那些缺乏才干的软件工程师，他们也不需要阅读本书，因为他们的失败工作经历比我更有说服力)。
　　我也无意对书中所介绍的一些开发模型“大打折扣”。每一种开发模型都来之不易，无论过去或现在，它们都将在软件工程领域占有一席之地。
　　由于本书篇幅有限，一些软件开发方法和最佳编程实践有所遗漏在所难免，即使是书中介绍的一些方法也未能覆盖其全貌。
　　如果对书中的一些内容有异议，或者打算提供某个主题更详细的信息，抑或是介绍自己正在使用的一些软件技术或变体，那么请加入Wrox P2P论坛，与大家一起分享。论坛上的“小伙伴们”都试图提高自己的开发技巧，所以我们拭目以待。事实上，学习和提高开发技术是许多敏捷方法的规定要求，因此加入论坛是必需的。
　　所以，请戴好眼镜，喝一杯含咖啡因的饮料，准备步入软件工程的殿堂吧！

　　Rod Stephens儿时梦想成为数学家，但当在麻省理工学院学习时，他发现编程非常有趣，从此便开始了专业的编程生涯。在其职业生涯中，他从事过很多不同领域的应用程序开发，如电话交换、计费、维修调度、税务处理、污水处理、演唱会门票销售、制图以及专业足球运动员培训。
　　十多年来，Rod 一直都是“微软Visual Basic 有价值专家(MVP)”，曾教授过一些编程的入门课程。他撰写过30 多本书，并且这些书籍还都被翻译成不同的语言。他撰写过250 多篇杂志文章，主要涉及Visual Basic、C#、Visual Basic for Applications、Delphi 以及Java。
　　Rod 广受欢迎的VB Helper 站点(www.vb-helper.com)包含有数千个针对Visual Basic 程序开发人员的提示、技巧以及示例程序页面。他的C# Helper 站点(www.csharphelper.com)包含类似的一些C#开发资源。
　　可以通过RodStephens@CSharpHelper.com 或RodStephens@vb-helper.com 和Rod 保持联系。

第Ⅰ部分 进阶
第1章 软件工程概览 3
1.1 需求收集 3
1.2 概要设计 4
1.3 详细设计 5
1.4 开发 5
1.5 测试 6
1.6 部署 7
1.7 维护 8
1.8 总结和反思 8
1.9 一次性处理所有事项 8
1.10 本章小结 9
第2章 入手之前 13
2.1 文档管理 13
2.2 历史文档 15
2.3 电子邮件 16
2.4 代码 18
2.5 代码文档 18
2.6 应用程序文档 21
2.7 本章小结 21
第3章 项目管理 25
3.1 管理支持 26
3.2 项目管理 27
3.2.1 PERT图 28
3.2.2 关键路径方法 33
3.2.3 甘特图 35
3.2.4 软件日程安排 36
3.2.5 估算时间 36
3.3 风险管理 41
3.4 本章小结 42
第4章 需求收集 45
4.1 需求定义 46
4.1.1 清晰 46
4.1.2 没有歧义 46
4.1.3 一致 47
4.1.4 优先级排序 47
4.1.5 可验证 50
4.1.6 应避免使用的词 51
4.2 需求分类 51
4.2.1 受众导向的需求 51
4.2.2 FURPS 54
4.2.3 FURPS+ 54
4.2.4 通用需求 56
4.3 收集需求 57
4.3.1 倾听客户(和用户)的需要 57
4.3.2 使用5W(和一个H) 57
4.3.3 研究用户 59
4.4 细化需求 60
4.4.1 复制现有系统 60
4.4.2 未卜先知 61
4.4.3 头脑风暴 62
4.5 记录需求 64
4.5.1 UML 64
4.5.2 用户故事 65
4.5.3 用例 65
4.5.4 原型 66
4.5.5 需求说明 67
4.6 确认和验证 67
4.7 更改需求 67
4.8 本章小结 68
第5章 概要设计 71
5.1 纵览全局 72
5.2 指定的事项 73
5.2.1 安全性 73
5.2.2 硬件 74
5.2.3 用户接口 75
5.2.4 内部接口 76
5.2.5 外部接口 76
5.2.6 架构 77
5.2.7 报表 83
5.2.8 其他输出 83
5.2.9 数据库 84
5.2.10 配置数据 86
5.2.11 数据流及状态 86
5.2.12 培训 87
5.3 UML 87
5.3.1 结构图 88
5.3.2 行为图 90
5.3.3 交互图 93
5.4 本章小结 95
第6章 详细设计 97
6.1 面向对象设计 98
6.1.1 识别类 99
6.1.2 创建继承体系 99
6.1.3 对象组合 103
6.2 数据库设计 104
6.2.1 关系数据库 104
6.2.2 第一范式 106
6.2.3 第二范式 109
6.2.4 第三范式 111
6.2.5 更高级的规范化 112
6.3 本章小结 113
第7章 开发 117
7.1 使用正确的工具 118
7.1.1 硬件 118
7.1.2 网络 119
7.1.3 开发环境 119
7.1.4 源代码控制 120
7.1.5 分析器 120
7.1.6 静态分析工具 120
7.1.7 测试工具 121
7.1.8 源代码格式器 121
7.1.9 重构工具 121
7.1.10 培训 121
7.2 选择算法 121
7.2.1 有效果 122
7.2.2 有效率 122
7.2.3 可预测 124
7.2.4 简洁 124
7.2.5 预包装 125
7.3 自上而下的设计 125
7.4 编程提示和技巧 127
7.4.1 保持清醒 127
7.4.2 为人编写代码，并非计算机 127
7.4.3 注释优先 128
7.4.4 编写自文档化的代码 130
7.4.5 保持小巧 131
7.4.6 保持专注 132
7.4.7 避免副作用 132
7.4.8 验证结果 133
7.4.9 实践“进攻式”编程 135
7.4.10 使用异常 136
7.4.11 首先编写异常处理程序 136
7.4.12 切勿重复代码 137
7.4.13 推迟优化 137
7.5 本章小结 138
第8章 测试 141
8.1 测试的目的 142
8.2 永不消亡的bug 143
8.2.1 收益递减 143
8.2.2 最后期限 143
8.2.3 影响 143
8.2.4 为时尚早 143
8.2.5 有用性 144
8.2.6 过时 144
8.2.7 这并非一个bug 144
8.2.8 没有尽头 145
8.2.9 有总比没有好 145
8.2.10 修复 bug很危险 145
8.2.11 修复哪些bug 146
8.3 测试级别 146
8.3.1 单元测试 146
8.3.2 集成测试 148
8.3.3 自动化测试 148
8.3.4 组件接口测试 149
8.3.5 系统测试 150
8.3.6 验收性测试 150
8.3.7 其他测试类型 151
8.4 测试技术 152
8.4.1 穷举测试 152
8.4.2 黑盒测试 153
8.4.3 白盒测试 153
8.4.4 灰盒测试 153
8.5 测试习惯 154
8.5.1 清醒时再进行测试和调试 154
8.5.2 测试自己的代码 154
8.5.3 让其他人测试你的代码 155
8.5.4 修复自己的bug 156
8.5.5 修改前请“三思” 157
8.5.6 不要相信魔法 157
8.5.7 查看改变之处 157
8.5.8 修复bug，并非症状 158
8.5.9 对测试用例进行测试 158
8.6 如何修复bug 158
8.7 估算bug的数量 159
8.7.1 跟踪发现的bug 159
8.7.2 播种 160
8.7.3 林肯指数 161
8.8 本章小结 162
第9章 部署 165
9.1 范围 166
9.2 计划 166
9.3 切换 167
9.3.1 阶段性部署 167
9.3.2 逐步切换 168
9.3.3 增量部署 169
9.3.4 并行测试 170
9.4 部署任务 170
9.5 部署错误 171
9.6 本章小结 172
第10章 度量 175
10.1 庆祝会 176
10.2 缺陷分析 176
10.2.1 bug的种类 176
10.2.2 石川图 178
10.3 软件度量 181
10.3.1 好的属性和度量指标的一些特征 182
10.3.2 度量的用途 182
10.3.3 需要度量的对象 184
10.3.4 规模标准化 186
10.3.5 功能点标准化 188
10.4 本章小结 192
第11章 维护 195
11.1 维护成本 196
11.2 任务分类 197
11.2.1 完成性任务 197
11.2.2 适应性任务 200
11.2.3 纠正性任务 201
11.2.4 预防性任务 203
11.2.5 个别bug 207
11.2.6 “非我发明” 207
11.3 任务执行 208
11.4 本章小结 208
第Ⅱ部分 模型
第12章 预测模型 215
12.1 模型 215
12.2 预备知识 216
12.3 预测和自适应 216
12.3.1 成功和失败的标志 217
12.3.2 利与弊 218
12.4 瀑布 219
12.5 带有反馈的瀑布 220
12.6 生鱼片 221
12.7 增量瀑布 222
12.8 V模型 224
12.9 系统开发生命周期 224
12.10 本章小结 227
第13章 迭代模型 229
13.1 迭代与预测 230
13.2 迭代与增量 231
13.3 原型 232
13.3.1 原型的类型 233
13.3.2 优缺点 234
13.4 螺旋模型 235
13.4.1 澄清 237
13.4.2 优势和不足 238
13.5 统一过程 239
13.5.1 优势和不足 240
13.5.2 RUP 241
13.6 洁净室模型 241
13.7 本章小结 242
第14章 RAD 245
14.1 RAD的主要原则 246
14.2 James Martin RAD 249
14.3 敏捷开发 249
14.3.1 自组织团队 252
14.3.2 敏捷方法 253
14.4 XP 256
14.4.1 XP的角色 257
14.4.2 XP的价值观 257
14.4.3 XP实践 258
14.5 Scrum 264
14.5.1 Scrum角色 264
14.5.2 Scrum冲刺 265
14.5.3 计划扑克 266
14.5.4 燃尽图 267
14.5.5 速率 268
14.6 精益软件开发 268
14.7 水晶方法 269
14.7.1 透明水晶 271
14.7.2 黄色水晶 272
14.7.3 橙色水晶 272
14.8 功能驱动开发 274
14.8.1 FDD角色 274
14.8.2 FDD阶段 275
14.8.3 FDD迭代里程碑 277
14.9 敏捷统一过程 278
14.10 规范敏捷交付 280
14.10.1 DAD原则 280
14.10.2 DAD角色 280
14.10.3 DAD阶段 281
14.11 动态系统开发方法 282
14.11.1 DSDM阶段 282
14.11.2 DSDM原则 283
14.11.3 DSDM角色 284
14.12 看板软件开发方法 285
14.12.1 看板的一些原则 285
14.12.2 和看板有关的一些实践 286
14.12.3 看板图 286
14.13 本章小结 287
附录A 习题答案 293
术语表 337