在SEI，汉弗里和同事们创建了软件成熟度模型(Capability Maturity Model, CMM ), 作为一种衡量软件开发组织品质的准绳。
CMM 原则的简单的概述
位于第一级的组织基本上什么都没做。
第二级组织做一些计划、跟踪、配置管理工作，也讨论质量保证之类的话题。
第三级组织开始定义过程——如何工作、如何完成任务、可训练的事项等。
第四级，他们采用衡量准绳。他们有一套真正跟踪和管理自己所做工作的框架， 一种可统计跟踪的系统。
第五级组织拥有持续改进的过程。
CMM主要目的是帮助规模庞大的组织改进软件进度和质量。
模式运动让个体程序员有了一条解决问题的新路子，并且提炼经验、供同事所用。但它并不太有助于找到在更大项目中协调工作的方法。
瀑布模型
将项目切分为依序进行的多个独立阶段，比如需求定义、设计、实现、集成、测试和发布。每个阶段需在下一阶段开始前完成。
这套做法在纸上看似合乎逻辑，但实践起来却总是导致延误、混乱和灾难。每个阶段都耗时无算，但没一个工作正常的。“大设计优先”引发大延误，“大爆炸式集成“一一单独编写代码的各个主要部分，在项目将近结束时拼到一起——导致系统崩溃。
螺旋模型
将开发切割为六个月到两年的“迭代周期”——更快生产出可工作代码的小瀑布，从部分完成的产品使用中得到反馈、指导下一步迭代。
快速应用开发(Rapid Application Development)
RAD承诺通过快速原型设计和更紧迫的迭代周期，依靠新工具让计算机处理一些繁重的编程工作，加速完成软件的交付。RAD 帮助软件公司更敏捷地工作。
敏捷软件开发(Agile Software Development)
个体和交互胜于过程和工具
可工作的软件胜于面面俱到的文档
客户协作胜于合同谈判
响应需求胜于遵循计划
尽管右栏条目有其价值，但我们更看重左栏条目。
争球式开发(Scrum)
将项目分解为30 天一轮的“竞跑"'强调每天开例会、维持项目在正轨上运转。
极限编程
采用了一系列广为接受的方法，并将这些方法的使用推至极限。
祖尔测试
索伯斯基提出了祖尔测试( Joel Test)，基于他自己的经验和“集体智慧＂，给出一套快餐式原则， 判断开发组织是否符合这条原则—— “不会叫人头疼的CMM”。
祖尔测试询问以下十二个问题：
1）Do you use source control? 你们使用源代码控制吗？
2）Can you make a build in one step? 你们一步就能完成构建吗？
3）Do you make daily builds? 你们做每日构建吗？
4）Do you have a bug database? 你们有缺陷数据库吗？
5）Do you fix bugs before writing new code? 你们会在写新代码之前修复缺陷吗？
6）Do you have an up-to-date schedule? 你们有与当前工作吻合的进度安排吗？
7）Do you have a spec? 你们有规约吗？
8）Do programmers have quiet working conditions? 程序员工作环境安静吗？
9）Do you use the best tools money can buy? 你们采用了市面上最好工具吗？
10）Do you have testers? 你们有测试人员吗？
11）Do new candidates write code during their interview? 你们会要求应聘者在面试时写代码吗？
12）Do you do hallway usability testing? 你们做走廊可用性测试吗？
“得12分为最佳，“索伯斯基写道， “11分还可以接受，得10分或更低就说明你们问题大了。其实多数软件组织只能得2、3分，他们迫切需要帮助，因为微软等公司一直都得12 分。”