改变开发软件的方式意味着机构需要改变它们制定项目计划的方式。
软件开发世界正在发生改变。软件开发的工具和框架有望提高开发的速度。新的灵巧开发（agile development）技术正在改变我们进行软件开发的过程。不论你所在的机构是否采用了新的工具、新的方法，或者只是想知道市场上到底有什么可用，你都需要压缩软件开发过程中的构造阶段。
银色子弹
尽管软件开发中没有所谓的银色子弹（关于银色子弹的具体内容见Fred Brook的经典著作《人月传说（The Mythical Man-Month）》，但是我们仍然需要对软件开发的过程进行逐步的改进。你可以把这当作是在铅弹上涂上一点白银。我们对软件开发的大多数改进都是对这一过程中构造阶段进行的。
图A |
|
《人月传说》 |
像Visual Studio 2005这样的新工具都有一些用来提高开发速度的编辑技术，它们能够让你更容易记住正在使用的对象的属性和方法。编译过程已经发生了变化，这样这个过程出现了大量的交互内容。你犯下的大多数句法错误都会在编辑的时候自动被识别和标记出来，这样你就可以修改这些问题而不需要运行一个编译循环。
此外，更多的基本函数都以内置功能库以及第三方的开发或者共享源库的形式出现。大多数使用广泛的应用程序对象被编写出来，这些库也越来越多地被捆绑为核心基本库。这就意味着，如果要在一个应用程序里创建一项新的功能，代码已经被（别人）写出来的可能性就越来越大，所以你所要做的就是把它与应用程序的其他代码连接到一起。
即使核心语言操作系统里没有这些代码，还有一些基本的层，用来提供更加丰富的、增强的功能。这些功能可以放在核心库的顶层，以进一步提供增强的功能。例如，微软的企业库（Microsoft Enterprise Library），尽管它不是.NET框架的一员，但是它减少了所需代码的量。这是一个免费文档和设计用来加速企业项目进程的代码的集合。
第三方的开放和共享源代码项目正在填补标准库无法顾及的小地方。不论是用来读取和编写RSS feed的库，还是基于Web的文本编辑器，或是完整的Web管理系统，都有大量能够集成到你应用程序里的独立解决方案。
这一点的优势就是能够减少构造的时间。但是其代价是要在开发过程的开始阶段额外增加花在设计或者探索上的时间，以确认这些基本的组件能够有效地应用在项目中。这些额外的设计或者探索时间是确认第三方的项目能够作为解决方案的一部分发挥作用所必需的。
在Fred Brooks撰写的论文《没有银色子弹——软件工程中的根本问题和次要问题（No Silver Bullet – Essence and Accident in Software Engineering）》里，其中的一个观点是软件开发的过程从根本上讲是极其复杂的，而且很少有或者完全没有能够从根本上降低其复杂性的方法。结果我们只有进行逐步的改进。Steve McConnell在他的《快速开发（Rapid Development）》一书中对银色子弹的观点进行了评论，他指出即使有工具能够降低软件开发过程中某一部分的工作量，但是它们不太可能对项目的所有部分都产生效果。换句话说，让项目构造阶段的工作量降低25％并不意味着整个项目的工作会减少25％。
应用程序开发的管理
软件质量和测试
2006年1月21日，赛门特克（Symantec）公司的杀毒软件能够检测到72,011种威胁。这是一个令人惊讶的数字。目前，每天都有数十种新的计算机威胁出现。并不是所有的威胁都要依靠软件的漏洞，但是有相当数量的新的威胁都直接与软件漏洞有关。
众人皆知的一些重大软件故障，包括一些美国航空航天局（NASA）的任务、主要机场的行李管理系统，以及其他一些问题，都引起过公众的重大关注。至少IT行业是了解这些软件缺陷所造成的故障的。
美国国家标准与技术研究院（National Institute of Standards and Technology，NIST）于2002年5月发表的一篇名为《软件测试的基础结构的缺陷对经济的影响（The Economic Impacts of Inadequate Infrastructure for Software Testing）》报告估计，软件质量（问题）每年会造成上百亿美元的经济损失。这一数字非常接近美国全年国内生成总值的1％。所以这是令人震惊的。
很显然，软件质量（达到令人满意的程度）还有很长的路要走，所以我们在尽量让软件更加可靠。难怪软件开发项目中往往会特别强调软件测试。将测试作为软件开发正式阶段计入项目总体开发时间、投入专门资源的呼声正在大幅提高。
灵巧开发方法正在开始促使测试驱动开发的概念进入开发人员和开发主管的思想意识里。由测试驱动的开发，简而言之，就是一开始编写你的测试情景。首先，你要确定待开发的模块或者对象应该完成什么任务，然后编写测试内容，测试你希望它具有的功能是否能够正常运行，这甚至要在编写对象本身之前就进行。
软件开发项目的实际效果是，在正式构造阶段中，真正花在开发代码上的时间减少，而花在开发测试构造上的时间增加了。最后正式的测试会进一步减少项目构造阶段的时间总量。由测试驱动的开发的支持者认为，花在测试上的额外时间会减少编写软件所需要的总时间，因为后期发现的错误或者未实现的功能会减少，而我们都知道修补错误的成本更高。这种思想在某种程度上已经取得了成功。
这意味着什么？
这些变化意味着机构需要改变它们制定项目计划的方式。它们需要摒弃花在项目构造阶段的时间量的传统指导方针，而必须减少用在构造上的时间，增加花在设计和测试上的时间。如果以前构造阶段占整个项目时间的35％，那么你可能需要把这个比例压缩到25％，同时将设计和测试阶段的时间量再提高5％。
虽然我说过这是一个零和游戏（zero sum game），只会发生在新技术被集成到小组的开发过程中的时候。一旦小组熟悉了新的基本类和第三方的解决方案，设计所需要的额外时间将由于整体时间的减少而被抵消。
诸如测试驱动的开发这样的技术能够减少构造的总时间，尤其对于质量优先的项目。但是在一开始，了解和学习新方法的时间很可能会超过你已经节省的所有时间。
最后，改进软件开发次要（而非主要）方面能够提高软件开发的整体成效。这不会大幅提高项目开发的速度，虽然从长远来看，它确实有正面的影响，如果你愿意从现在就开始在工具和技术上进行投资的话。
责任编辑：张琎
