随着软件工业不断发展，各种各样的模型不断涌现或退出历史舞台。早期从不同角度提出的各种设计表示方法(常常以发明者的名字来命名)目前似乎已经聚合成为UML这种被广泛接受的标准，结构化设计方法也正在让位于面向对象设计等更受欢迎的方法学，这种变化在更高层次的全局性开发方法学方面同样进行着。
传统意义上的软件方法学描述通常“能够”处理任何大小的项目，而实际上真正的困难就来自于如何对这些方法加以裁剪以适合较小的项目。针对这种理论与实际的脱节现象，国际上一些著名的软件工程专家提出所谓“重(heavy)”方法和“轻(light)” 方法之分，试图为快速发展的软件工业探寻更切合实际的解决方法。
所谓“重”方法，就是指形式化的、戒律森严的软件工程方法学——不仅指这些方法所生成纸文档重量，还意指管理资源投入、QA评审的程度和开发人员被要求遵守的严格流程。相对的，诸如快速应用开发(Rapid Application Development，简记为RAD)和原型方法等则可以被称为“轻”方法——不仅是因为这些方法倾向于产生最小数量的纸文档，还因为其将管理资源投入最小化。不幸的是，1990年代的许多RAD项目在方法学上采取了过“轻”的处理以至于几乎不存在什么方法，这些项目常常退化为杂凑式作坊开发，实质上根本没有任何文档。 显然，需要在两种极端方法之间找到平衡点。
轻方法代表了一种有意识的风险防护方法，依据不同风险在与开发相关的各种活动中投入相应时间、资金和资源。例如，进行多少需求分析工作才算是过多，拟或过少?针对一个几百个需求的开发项目而言，一个需求分析“轻”方法(requirements-light approach)可能是由将每一个需求通过一个简洁的句子加以文档化的行为所组成，一个需求分析“中”方法(requirements-medium approach)可能要求对每个需求通过一段描述性文本来文档化，而一个需求分析“重”方法(requirements-heavy approach)则可能要求详细的UML模型、数据元素定义和每个对象方法的形式化描述。
究竟选择需求分析的“轻”方法还是“重”方法很大程度上受到公司产品上市时间或合同期限压力的影响。同时，公司雇员的流动率也是一种影响因素：作为形式化开发过程的理由之一认为，如果有一份详细的文档来记录需求、设计和编码，那么一旦在项目进行中关键开发成员离职所造成的混乱将会被尽量减小。
然而，尽管1970年代和1980年代的系统生命周期预期为十年或二十年，也许Interbet时代的网络公司更愿意正式承诺其电子商务应用仅持续一年，然后被废弃或完全重写。如果正是这种情况，并且如果下一代应用预期与当前应用存在质的差异，那么仅仅为了达到SCM-CMM三级就遵循需求分析“重”方法还真的有意义吗?
同样地，针对设计和测试工作采用什么样的形式化和严格程度才是合适的呢?与项目管理有关的时间汇报、进展汇报、状态会议及其他常见活动又如何呢——尤其针对那些仅持续一周或两周的项目?这些问题总是相互关联的，但是一些传统上被接受的答案却需要至少每隔几年重新审视一下，因为成本-收益参数正在随着商业环境、技术和软件开发人员的变化而不断变化。
轻方法还重新审视了历史上有关投入资源在需求分析的假定，以及投入资源在过程改进的假定。1981年Barry Boehm在他的经典著作“软件工程经济学”(Software Engineering Economics)中指出了一项惊人发现，即如果我们在项目的系统分析阶