需求收集过程特别集中于软件上。要理解待建造程序的本质，软件工程师（“分析员”）必须了解软件的信息领域以及需求的功能、行为、性能和接口。系统需求和软件需求均要文档化，并与用户一起复审。

设计：软件设计实际上是一个多步骤的过程，集中于程序的四个完全不同的属性上：数据结构、软件体系结构、界面表示及过程（算法）细节。设计过程将需求转换成软件表示，在编码之前可以评估其质量。象需求一样，设计也要文档化，并且是软件配置的一部分。

代码生成：设计必须转换成机器可读的形式。代码生成这一步就是完成这个任务的。如果设计已经表示得很详细，代码生成可以自动完成。

测试：一旦生成了代码，就可以开始程序测试。测试过程集中于软件的内部逻辑——保证所有语句都测试到，以及外部功能——即引导测试去发现错误，并保证定义好的输入能够产生与预期结果相同的输出。

维护：软件在交付给用户之后不可避免地要发生修改（一个可能的例外是嵌入式软件）。在如下情况下会发生修改：当遇到错误时；当软件必须适应外部环境的变化时（例如，因为使用新的操作系统或外设）；或者当用户希望增强功能或性能时。软件维护重复以前各个阶段，不同之处在于它是针对已有的程序，而非新程序。

因为软件总是一个大系统（或商业）的组成部分，所以一开始应该建立所有系统成分的需求，然后再将其中某个子集分配给软件。整个系统基础是，以软件作为其他成分如硬件、人及数据库的接口。系统工程和分析包括了系统级收集的需求，以及一小部分顶层分析和设计。信息工程包括了在战略商业级和商业领域级收集的需求。

瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。

软件工程的线性顺序模型，有时也称“传统生命周期”或“瀑布模型”，线性顺序模型提出了软件开发的系统化的、顺序的方法（虽然由Winston Royce[ROY70]提出的最早的瀑布模型支持带有反馈的循环，但大多数使用该过程模型的组织均把它视为是严格线性的），从系统级开始，随后是分析、设计、编码、测试和维护。

1）阶段间的顺序性和依赖性，项目从开始到结束按照一定的顺序执行；瀑布模型是文档驱动的，各个阶段不连续也不交叉。

2）严格阶段评估，必须先进行一个阶段严格评估才能进入下一个阶段。

3）开发初期需要清楚全部需求。

4）开发周期长，风险大。

1）实际的项目大部分情况难以按照该模型给出的顺序进行，而且这种模型的迭代是间接的，这很容易由微小的变化而造成大的混乱。

2）很多情况下客户难以表达真正的需求，而这种模型却要求如此，这种模型是不“欢迎”具有二义性问题存在的。

3）客户要等到开发周期的末期才能看到程序运行的测试版本，而在这时发现大的错误时，可能引起客户的惊慌，而造成的后果也可能是灾难性的。

4）经常会在过程的开始和结束时碰到等待其他成员完成其所依赖的任务才能进行下去的情况，有可能花在等待的时间比开发的时间要长，称为“堵塞状态”。

1）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

2）尽管有不少缺陷，但比在软件开发中呈现随意的状态要好得多。

如果解释变量X的单位变动引起因变量的变化率

非线性模型的一般形式是：

Y与X之间存在线性关系，但是Y和参数

对于非线性回归分析，只有参数的线性回归分析才是重要的，因为变量的非线性可通过适当的重新定义来解决 。

假定根据理论或经验，已估计输出变量与输入变量之间的非线性表达式，但表达式的系数是未知的，要根据输入输出的n次观测结果来确定系数的值。处理非线性回归的基本方法是，通过变量变换，将非线性回归化为线性回归，然后用线性回归方法处理。

非线性模型指数函数模型

指数函数模型为：

令

非线性模型对数函数模型

对数函数模型为：

令

非线性模型双曲线函数模型

双曲线函数模型为：

令

非线性模型S型曲线函数模型

S型曲线函数模型为：

令

非线性模型多项式模型

在只有一个自变量的情况下，多项式模型如下：