引言

大多数软件项目都是失败的。事实上，Standish group 的报告显示 80% 多的项目是不成功的，原因是超出了预算、未能按时完成、遗漏功能或者因为一个项目中同时出现了这些问题中的其中几个。此外，30% 的软件项目执行得很糟糕以至于半途而废。根据我们的经验，使用现代技术（例如 Java、J2EE、XML 以及 Web 服务）的软件项目都逃不出这个规则。

本文概述了软件开发项目的最佳实践。一些业界泰斗，如 Scott Ambler、Martin Fowler、Steve McConnell 和 Karl Wiegers，已经在因特网上写了许多这样的最佳实践，本文也引用了这些最佳实践。另请参阅本文末尾的相关信息部分。附带的文章软件开发项目实施指南描述了有助于提高项目成功率的十条最重要的因素。

最佳实践项目

1. 开发流程（Development process）－为手头的项目选择适当的开发生命周期流程很重要(CMMI三级自定义过程最大的一个裁剪项)，因为其他的所有活动都是从这个流程派生出来的。现代的软件开发项目多数都是在瀑布式流程的基础上采用某种螺旋式方法。有几种方法可供选择，包括 Rational 统一流程（Rational Unified Process，RUP）、IBM® Global Services 方法（IBM® Global Services Method）以及极端编程（eXtreme Programming，XP）。(还要改进型的瀑布模型，增量等相关模型可以供选择)流程当然比根本没有要好，但在多数情况下流程的执行情况要比使用的是什么流程更重要。以上列举的常用方法都包含关于如何执行流程的指南和构件模板。此外，RUP 还有一系列描述使用 RUP 的最佳实践的书  [1][2][3][4]，即便不选用 RUP，这些书也是获得最佳实践的极好来源。给 RUP 加插件也是可以的。请为基于 WebSphere® J2EE 的项目下载  WebSphere 插件。(RUP是很好的一套增量迭代的开发方法，RUP方法论可以更好的应当变化和体现架构设计在开发过程中的主导作用，但真正用好并不容易)

2.需求－收集需求就需求达成一致是项目成功的基础。这并不一定意味着需要在建立好体系结构、完成设计和编码工作之前确定所有的需求，但对于开发小组来说明白需要构建什么是很重要的。质量需求分两种：功能性的和非功能性的。一种记录功能性需求的好方法是使用用例（Use Case）。注意：用例被用于非面向对象的项目。Armour 和 Miller 著有一本关于用例主题的权威著作 [5]。非功能性需求描述应用程序的性能和系统特性。收集非功能性需求很重要，因为他们对应用程序体系结构、设计以及性能都会产生重要影响。请参阅 ConstruxWeb 站点上的 非功能性需求清单。(非功能性需求和功能性需求一样重要，对于新产品的非功能性需求的前期收集是具有难度的，更多要借鉴其它产品相关经验。需求开发可以采用结构化分析方法，也可以采用用例分析方法。架构设计也应该针对系统的功能性需求和非功能性需求分别进行设计)

3.体系结构 － 为您的应用程序选择合适的体系结构是关键。有好几次 IBM 被要求复查出问题的项目，结果发现开发小组没有应用知名的业界体系结构最佳实践。与 IBM 联系是避免这类问题的好方法。我们的顾问可以与您的开发小组并肩工作以确保项目沿正确的轨道开始。经过实验证明可靠的实践称为模式，有经典的 Gang of Four [6] 模式、Java 模式 [7]，也有 EJB 设计模式 [8]。Sun 公司与此相应的是核心 J2EE 模式（Core J2EE Pattern）目录 [9]。IBM 也发布过一些最佳实践和参考应用程序体系结构 [10]。引言中说过许多项目都是失败的。通过对这些失败的项目的研究提出了反模式这个概念。这些反模式是很有价值的，因为它们针对哪里出了问题以及为什么会出问题提供了有用的信息。

4. 设计－即使有了好的体系结构，也可能设计不好。许多应用程序不是设计得过于复杂就是设计得过于简单。这有两个基本原则 “尽量简单”和 信息隐藏。对于许多项目来说，使用 UML 进行面向对象的分析与设计（Object-Oriented Analysis and Design）很重要。有关 UML 的书有很多，但我们推荐 UML User Guide [11]和 Applying UML and Patterns [12]。重用是面向对象的很有前途的一个方面，重用经常会因为需要额外的工作来创建可重用资产而变得无法实现。代码重用是重用的一种形式，当然也有其他一些能够提高效率的重用种类。(Applying UML and Patterns 这本书结合了模式，RUP很多最佳实践和例子在里面，确实值得推荐)

5. WebSphere 应用程序设计 － IBM 拥有关于 WebSphere 系列产品的最佳实践和设计模式的广泛知识。每个项目都是不同的，我们的顾问有丰富的经验来帮助您。即使您只聘请我们的顾问很短一段时间，这种投资回报（ROI）也是很大的，因为您可以在以后的项目中节省开销。我们的专家也发表过大量有关这类知识的文章，包括高性能 Web 站点注意事项和自主计算指南。

6. 代码的构建－代码的构建虽然只是整个项目工作的一小部分，但往往是最明显的部分。其他同样重要的工作还包括需求、体系结构、分析、设计以及测试。在没有开发流程（所谓的“编码加修正”）的项目中，也会有这些任务，只不过被统称为“编程”而已。构建代码的最佳实践包括每日构建和冒烟测试。Martin Fowler 进一步提出了 连续集成（continuous integration），这个概念还集成了单元测试和自测试代码概念。注意，即使连续集成和单元测试是通过 XP 流行起来的，您也可以在所有类型的项目中使用这些最佳实践。我建议使用标准框架（比如 Ant和 JUnit）使构建和测试自动进行。(冒烟测试的关键点就是用最典型的测试用例来测试最典型的可能应用和过程。采用JUnit,NuUnit
等测试框架后可以保证冒烟测试的自动化，持续集成这个概念很重要，持续集成最重要的目的就是尽早的发现和解决问题)

7. 对等审查 － 审查别人的工作很重要。经验证明这种方法可以及早消除问题，审查和测试一样有效，甚至比测试还有效。开发流程中任何构件都需要审查，包括：规划、需求、体系结构、设计、代码以及测试案例（test case）。Karl Wiegers 的文章 Seven Deadly Sins of Software Reviews 说明了执行对等审查的正确方法。对等审查有助于以最快的速度提高软件质量。

8. 测试 － 即使日程安排再紧也不可以推迟或省去测试。测试是需要计划的软件开发的一个必不可少的部分。提前测试也很重要；这意味着要在开始编码前就安排好测试案例，测试案例的开发与应用程序的设计和编码同时进行。同样也有许多现成的测试模式。

9. 性能测试 － 测试通常是用于检查应用程序缺陷的最后一招。它是劳动密集型工作，通常只检查编码缺陷。体系结构和设计上的缺陷可能会漏掉。一种检查体系结构缺陷的方法是在部署应用程序之前对其进行模拟负载测试，并在性能问题真正成为问题前就处理它们。(性能测试暴露的问题更多都是由于架构设计在对非功能性需求方面考虑不足)

10. 配置管理 － 进行配置管理涉及到了解组成您的系统或项目的所有构件的状态，管理这些构件的状态并发布系统的不同版本。配置管理比单独的源代码控制系统（比如 Rational Clearcase）管理的内容更多。同样也有针对配置管理的最佳实践和模式 [13]。

11. 质量和缺陷管理 － 为项目建立质量优先级和发布标准很重要，这样就可以制定一个计划来帮助开发小组开发出高质量的软件。当对项目进行编码和测试时，缺陷的出现和修正比率有助于测量代码的成熟程度。使用链接到源代码控制管理系统的缺陷跟踪系统也很重要。例如，使用 Rational ClearCase 的项目还可以使用 Rational ClearQuest。使用缺陷跟踪，就可以在准备发布项目时对项目进行测量（gauge）。(小型项目可以使用一些开源免费的缺陷管理功能，如Bug Tracker等)

12. 部署（Deployment）－ 部署是向用户发布应用程序的最后阶段。如果您的项目进行到了这一步 － 那就恭喜您啦！但仍然会有可能出错的地方。您要制定部署计划，并且您可以使用 Construx Web 站点上的部署清单。(硬件环境，软件环境，部署方法和步骤)

13. 系统操作与支持（System operations and support）－ 没有操作部门就不能部署和支持新应用程序。支持范围对于回答和解决用户问题至关重要。为缓解问题流，应用程序缺陷跟踪系统中引入了支持问题数据库。

14. 数据迁移（Data migration）－ 多数应用程序都不是全新的，而是改善或者重写的现有应用程序。从现有的数据源迁移数据这本身通常就是一个比较大的项目。这不是初级程序员能做的。它与新应用程序一样重要。通常新应用程序的业务规则更好，数据质量有可能更高。提高数据质量是一个复杂的主题，已经超出了本文讨论的范围。

15. 项目管理（Project management）－ 项目管理是项目取得成功的关键。本文描述的许多其他的最佳实践都和项目管理有关，出色的项目经理已经知道了这些现有的最佳实践。我们推荐的项目管理权威著作是 Steve McConnell 编写的 Rapid Development [14]。如果把项目管理的其他清单和技巧的数目考虑进去，您会感到大吃一惊，居然有那么多的项目经理不知道这些技巧，并且也没有从以前的项目中吸取教训，比如：“如果没有计划好，就等于计划着要失败。”一种管理困难项目的方法是通过使用时间定量（timeboxing）。

16. 衡量是否成功 － 您可以根据卡内基梅隆大学软件工程学院（Software Engineering Institute at Carnegie Mellon University）的业界标准软件能力成熟度模型（Capability Maturity Model，CMM）来衡量您的开发流程。多数项目处于 1 级（初级）。如果按照上面描述的最佳实践和附带的文章，软件开发项目实施指南，中的执行，就可以开发出更加成熟的软件，使项目取得成功。(软件能力成熟度和项目本身是否成功能否直接划等号？)

结束语

本文提供了一系列有助于提高软件开发项目成功率的最佳实践。遵循这些最佳实践，您的项目成功的机会会更大。

注:红色部分为人月神话添加内容

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号