软件开发的典型过程模型如下。
瀑布模型:该模型将基本的过程活动、描述、开发、有效性验证和演化视为界限明确的独立过程阶段，包括要求描述阶段、软件设计阶段、实现阶段、测试阶段等增量式开发:该方法结合了描述活动、开发活动、有效性验证活动。 系统的开发确立了一系列的版本(增量)，每个版本将一些功能添加到以前的版本中。面向复用的软件工程:该方法基于现有的大量可复用组件。 系统开发过程的重点是将这些组件集成到新系统中，而不是从一开始就开发。 三种模型互不排斥，特别是常用于开发大系统。 在大系统中，综合瀑布模型和增量开发模型的优点是有意义的。
也可以将瀑布模型视为软件的生命周期模型。
在主要阶段直接测绘基本发展活动：
需求分析和定义:咨询系统用户建立系统的服务、约束和目标。 对其详细定义形成系统描述。系统和软件设计:系统设计过程通过构建系统的总体体系结构将需求分为硬件和软件需求。 软件设计包括识别和描述一些基本软件系统的抽象及其关系。实现和单元测试:在此阶段将软件设计实现为一系列程序或程序单元。 单元测试是指确认各单元是否符合其说明。集成和系统测试:集成单个程序单元或一组程序，测试整个系统以确保满足软件需求。 测试后，软件系统将提供给客户使用。运行和维护:这通常是生命周期最长的阶段。 系统已安装并实际使用。 维护包括纠正在初始每个阶段结束时发现的错误，改善系统各单元的实现，并在新需求出现时提高系统的服务能力。
主要的问题是把项目硬分解到这些清晰的阶段。 因此，只有在很了解需求，在系统开发过程中很难发生重大变化的情况下，才适合使用瀑布模型。
阶段性的开发思想是，首先开发最初的实现，供用户使用，听取用户的使用意见和建议，通过不断修改多个版本，直到产生足够的系统。 说明、开发、有效性验证等活动没有分离，而是交织在一起。 在这些活动之间可以迅速传递反馈信息。
增量开发反映了解决问题的方法。 系统的每个增量或版本都包含用户所需的部分功能。 系统的初始阶段通常包括最重要或最紧急的功能要求。 这意味着，在早期开发阶段，用户可以比较快地评估系统并验证其是否满足了需求。 如果需求无法满足，只需更改当前增量即可。 此外，还可以发现新功能，为下一个增量做准备，从而大幅降低成本。
增量开发与瀑布模型相比的重要优势：
降低满足用户需求变化的成本。 重新分析和修改文档的工作量比瀑布模型少很多。 在开发过程中，更容易获得用户对已经进行的开发工作的反馈。 用户可以评估软件的现实版本，看实现了多少。 这比根据软件设计文档判断工程进度要好得多。 虽然并不包括所有功能，但我们可以更快地向客户提供和部署有用的软件。 可以比瀑布模型更快地使用软件，从而创造商业价值。 从管理角度看，分阶段方法存在以下问题。
看不到过程。 管理员需要通过经常性的可交付文档了解进度，如果系统开发速度太快，创建反映系统各个版本的文档将会很昂贵。 随着新增量的加入，系统结构逐渐退化。 除非投入时间和金钱重建系统结构并改进软件，否则定期变更会破坏系统结构。 随着时间的推移，越晚变更系统越困难，成本也会上升。 增量开发与迭代开发的区别增量开发
每个阶段都要完成高质量的发布版本，后续阶段对前一阶段的内容不做任何修改，只需在前一阶段的基础上增加新业务功能的实现，直到最后一个阶段才形成最终的软件产品。
增量开发只是在现有的基础上添加新的东西。
迭代开发
最初阶段覆盖整个项目，以后的各阶段在前面的基础上进行改善和完善，业务范围没有扩大。
每次迭代开发都在原有的基础上进行改进和完善。
面向复用的软件工程，在许多软件项目中，存在着一定程度的软件复用。
主要阶段：
组件分析:描述要求并查找满足要求的组件。 通常，无法选择合适的组件，往往会得到只提供部分所需功能的组件。需求修改:在此阶段，根据获得的组件信息分析要求，并修改要求以反映可用的组件。 如果不能再修改需求，则必须返回组件分析活动以查找其他可能的备选方案。使用复用的系统设计:在此阶段设计系统框架或重用现有框架。 设计师分析重用的组件，并组织框架以适合这些组件。 如果无法获得可复用组件，则必须重新设计新软件。开发和集成:如果组件不可用，则必须自行开发，将自行开发的组件和现场组件集成在一起。 在这个模型中，系统集成和
其说是一个独立的活动，不如说已经成为开发过程的一个部分。
3种类型的软件组件可能用于面向复用的过程：
优势：
减少了需要开发的软件数量，从而降低了软件开发成本，也降低了开发中的风险可使软件快速地交付