从事软件开发的人都希望自己的项目成功，它是所有开发成员的期望，也是项目经理或项目负责人的最大责任。虽然世上并没有保证成功的规则可遵循，不过以下的方程式可以指引你迈向成功之路。
Effort = (Team) (Tools) (Complexity) Process
这是软件业界广泛使用的一种结构成本模型 (COCOMO) 表示法，由美国南加大软件工程中心综合大量的产业研究所发展出来的。这个方程式用 Team （开发团队）、 Tools （工具）、 Complexity （复杂度）、 Process （程序）等四个参数的组合关系，代表一个项目所需投入的成本及可以产生的成果。因此可将 Effort 视为成本，也可以视为成功机会。
如果从成本角度来看，我们的目标就是尽可能降低四个参数对成本的影响；如果从成功机会来看，则是尽可能增加四个参数对成功的贡献度。接下来我们将同时以两个角度来讨论这四个重要参数，也就是如何降低他们的负面影响，并增加正面贡献。
复杂度
「复杂度」是指软件架构与规模。一般而言，软件规模越大，复杂度就越高，所以这个参数也可以用「规模大小」（ Size ）来代替。通常软件开发项目越庞大、越复杂时，它的相对成功率就越低，所以这里的主要目标就是尽量降低软件的规模，也就是降低它的开发复杂度。有三种方法可以达到这个目标：
1. 调整软件规模：把一个软件依它所需要的功能特色（ Feature ）切割成几个独立小系统，然后让每一个小系统都有自己的成本（ cost ）与价值（ value ）这两个数字，代表完成这个小系统的所需成本与所得回馈。我们的目标就是选定一种系统组合方式，让它的总价值与总成本的比值最大化。
2. 降低人为程序代码数量：许多程序语言都可以达成同样一件事，差别只在于其程序代码的大小。例如，同样一个应用程序，用汇编语言可能需要 100 万行的程序代码， C++ 需要 40 万行，而 Java 搭配现有组件则可能只要 5000 行就搞定。人为程序代码越多，开发过程就越麻烦，出错机会也越高，成功率自然就降低。所以应该选择人为程序代码较少的方式（例如采用比较高阶的语言），这样才能增加项目的成功机率。
3. 采用可视化模块：目前的软件架构与运作环境都日趋庞杂，不是二十年前那种单机版单功能软件可以比拟，开发成员根本已经无法单纯用「想象」或「便条纸」进行沟通与管理。所以此时应该利用标准模块化语言（例如 UML ）等专业工具来建立整个开发计划，以协助进行巨细靡遗的掌控与管理，这样才能有效降低管理上的复杂与困难度。
程序
程序是指完成一个软件项目的整个作业流程，包括生产性活动与非生产性活动。从公式中可以看出，程序与软件复杂度有着密切关连，而且会对它造成指数性影响。在这个部分，同样有三种方法能达到目标：
1. 采用往复式流程法（ Iteration ）：软件开发有两种流程法，一种是传统的瀑布式流程法，另一种是新的往复式流程法。关于他们之间的优缺点与差异比较，在先前文章已经介绍多次，因此不再赘述。只要记住一点，往复式流程法是专门解决成功率偏低的改良性工法，而且软件规模越大时，它的效果就越明显。
2. 早期发现早期治疗：我们都知道，突发性风险（ Risk ）是导致项目失败的重要因素，而且当它越晚发作时，所需投入的治疗成本就越高，「治愈率」也越低。所以在软件开发过程里，不应是祈求危机不要爆发，而是该想办法让高风险的危机在早期就被发掘出来，立刻予以治疗，如此才能增加项目的成功率。
3. 参考最佳典范（ Best practice ）：软件工业已经发展超过三十年，过程中有成功也有许多失败，业界已经撷取这些大量经验，淬炼出一套最佳化的软件开发程序典范。与其自己埋头苦干，重蹈覆辙，不如直接参考他人的成功典范来得实际与聪明，而且能增加自己的成功机会。
