在计算机发展的初期，计算机应用的领域还比较狭窄。那时，计算机主要侧重于科学计算，程序设计是少数聪明人干的活，软件开发几乎等同于程序设计。那时，程序员通常采用“边想边做边用边改”的模式，很少做系统性的需求分析和系统设计。随着软件复杂性的增加，程序员们不知不觉就陷入了“边做边改”的困境：程序质量低下，错误频发，进度延误，费用剧增等问题日益严重。这些问题，统称为“软件危机”。
20世纪60年代末、70年代初，一些程序员意识到，若要把软件开发和应用做好，就必须有条理的安排好需求分析、系统设计、软件编码、验证测试、系统维护等活动，于是就产生了软件生命周期模型，典型的代表是1970年提出的瀑布模型。
那时候，他们主要关注的是技术开发活动，还没有考虑到软件开发过程中的管理活动。因此，各种软件生命周期模型几乎都不涉及到管理，如后来出现的喷泉模型、增量模型、快速原型模型、螺旋模型、迭代模型、RUP模型等。
对软件过程(Software Process)的研究，则相对滞后。20世纪80年代末，业界才开始研究软件过程，典型的案例是1986年美国国防部（DoD）委托卡内基梅隆大学（CMU）的软件工程研究院（SEI）研究如何评估软件开发商的能力，并最终导致CMM 1.0在1991年诞生。
软件过程是为生产出高质量软件产品所需完成的任务的框架，即形成软件产品的一系列步骤，包括中间产品、资源、角色及过程中采取的方法、规程（Procedure）、技术和工具等。软件过程包括三个基本要素：人、方法与规程、技术与工具，三者必须协调好，才能开发出好的产品。也即，过程与产品之间存在某种因果关系，只有好的过程，才可能得到好的产品，而差的过程只会得到差的产品。
软件过程主要针对软件生产和管理进行研究。为了获得满足工程目标的软件，不仅涉及工程开发，而且还涉及工程支持和工程管理。软件过程可概括为三类：基本过程类、支持过程类和组织过程类。
- 基本过程类包括获取过程、供应过程、开发过程、运作过程，维护过程和管理过程。
- 支持过程类包括文档过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审过程、审计过程以及问题解决过程。
- 组织过程类包括基础设施过程、改进过程以及培训过程。
软件过程构成了软件项目管理控制的基础，并且创建了一个环境以便于技术方法的采用、工作产品（模型、文档、报告、表格等）的产生、里程碑的创建、质量的保证、正常变更的正确管理。
从字面上理解，“软件生命周期”涵盖了软件的所有过程，所以用“软件生命周期模型”来表示软件过程的模型是最恰当不过的，但由于历史的原因，人们很早就把“软件生命周期”这一术语占用了，弄得现在这二个术语都不贴切。为了区别，现在人们常常用“软件开发模型”来代替“软件生命周期模型”。
