sdlc（软件生命周期，软件生存周期）是软件的产生直到报废的生命周期，是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。

简介

SDLC方法

同步数据链路控制

SDLC的六个阶段(问题的定义及规划 需求分析 软件设计 程序编码 软件测试 运行维护)

软件生命周期模型(概念 典型模型)

简介

SDLC（Software Development Life Cycle），即软件生命周期，软件生存周期，是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。但随着新的面向对象的设计方法和技术的成熟，软件生命周期设计方法的指导意义正在逐步减少。

SDLC方法

SDLC方法一般包括如下几步：

1、 评估现有系统。　(问题定义与规划)

2、 确定新系统的要求。　（需求分析）

3、 设计提议的系统。　（软件设计）

4、 开发新系统。　（程序编码）

5、 新系统投入使用。　（软件测试）

6、 新系统完成以及运行一段时间后，需要进行彻底评估，并时刻进行严格维护。 （运行维护）

同步数据链路控制

同步数据链路控制（SDLC）协议是一种 IBM 数据链路层协议，适用于系统网络体系结构（SNA）。

通过同步数据链路控制（SDLC）协议，数据链路层为特定通信网络提供了网络可寻址单元（NAUs：Network Addressable Units）间的数据差错释放（Error-Free）功能。信息流经过数据链路控制层由上层往下传送至物理控制层。然后通过一些接口传送到通信链路。SDLC 支持各种链路类型和拓朴结构。应用于点对点和多点链接、有界（Bounded）和无界（Unbounded）媒体、半双工（Half-Duplex）和全双工（Full-Duplex）传输方式，以及电路交换网络和分组交换网络。

SDLC 支持识别两类网络节点：主节点（Primary）和次节点（Secondary）。主节点主要控制其它节点（称为次节点：Secondaries）的操作。主节点按照预先确定的顺序选择次节点，一旦选定的次节点已经导入数据，那么它即可进行传输。同时主节点可以建立和拆除链路，并在运行过程中控制这些链路。主节点支配次节点，也就是说，次节点只有在主节点授权前提下才可以向主节点发送信息。

SDLC 主节点和次节点可以在四种配置中建立连接：

点对点（Point-to-Point）：只包括两个节点：一个主节点，一个次节点。

多点（Multipoint）：包括一个主节点，多个次节点。

环（Loop）：包括一个环形拓朴：连接起始端为主节点，结束端为次节点。通过中间次节点相互之间传送信息以响应主节点请求。

集线前进（Hub Go-Ahead）：包括一个 Inbound 信道和一个 Outbound 信道。主节点使用Outbound信道与次节点进行通信。次节点使用 Inbound 信道与主节点进行通信。通过每个次节点，Inbound 信道以菊花链（Daisy-Chained）格式回到主节点。

为适应不同环境，SDLC 具有一些派生类：

HDLC，一种 ISO 协议，适用于 x.25 网络；

LAPB，一种 ITU-T 协议，适用于 ISDN 网络；

LAPF，一种 ITU-T 协议，适用于帧中继（Frame Relay）网络；

IEEE 802.2，通常指 LLC，具有三种类型，适用于局域网（Local Area Network）；

QLLC，适用于在 X.25 网络上传输 SNA 数据。

协议结构

1 byte 1-2 bytes 1-2 bytes Variable 2 bytes 1 byte

Flag Address field Control field Data FCS Flag

Flag ― 启动和终止差错校验。

Address ― 包括次站 SDLC 地址，表明帧来自于主站还是次站。

Control ― 使用3种不同格式，取决于使用的 SDLC 帧类型：

Information（I）frame ― 传递上层信息和一些控制信息。

Supervisory （S）frame ― 提供控制信息。S 帧可以请求和挂起传输、报告状态、确认 I 帧接收。S 帧不包含信息帧（information field）。

Unnumbered （U）frame ― 支持控制目标，无编号。U 帧用于启动次站。取决于 U 帧，其控制字段可能为1字节也可能为2字节。有些 U 帧包含信息字段。

Data ― 包含路径信息单元（PIU）或交换识别（XID）信息。

Frame check sequence （FCS））― 优于结束标签分隔符，通常指循环冗余校验（CRC）计算余数。

SDLC的六个阶段

问题的定义及规划

此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。

需求分析

在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。“唯一不变的是变化本身。”，同样需求也是在整个软件开发过程中不断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。

软件设计

此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件设计一般分为总体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。

程序编码

此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。

软件测试

在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。

运行维护

软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。

软件生命周期模型

概念

任何软件都是从最模糊的概念开始的：为某个公司设计办公的流程处理；设计一种商务信函打印系统并投放市场。这个概念是不清晰的，但却是最高层的业务需求的原型。这个概念都会伴随着一个目的，例如在一个“银行押汇系统” 的目的是提高工作的效率。这个目的将会成为系统的核心思想，系统成败的评判标准。99年政府部门上了大量的OA系统，学过一点Lotus Notes的人都发了财（IBM更不用说了），但是更普遍的情况是，许多的政府部门原有的处理模式并没有变化，反而又加上了自动化处理的一套流程。提高工作效率的初衷却导致了完全不同的结果。这样的软件究竟是不是成功的呢？

从概念提出的那一刻开始，软件产品就进入了软件生命周期。在经历需求、分析、设计、实现、部署后，软件将被使用并进入维护阶段，直到最后由于缺少维护费用而逐渐消亡。这样的一个过程，称为“生命周期模型”（Life Cycle Model）。

典型模型

典型的几种生命周期模型包括瀑布模型、快速原型模型、迭代模型。瀑布模型（Waterfall Model）首先由Royce提出。该模型由于酷似瀑布闻名。在该模型中，首先确定需求，并接受客户和SQA小组的验证。然后拟定规格说明，同样通过验证后，进入计划阶段…可以看出，瀑布模型中至关重要的一点是只有当一个阶段的文档已经编制好并获得SQA小组的认可才可以进入下一个阶段。这样，瀑布模型通过强制性的要求提供规约文档来确保每个阶段都能很好的完成任务。但是实际上往往难以办到，因为整个的模型几乎都是以文档驱动的，这对于非专业的用户来说是难以阅读和理解的。想象一下，你去买衣服的时候，售货员给你出示的是一本厚厚的服装规格说明，你会有什么样的感触。虽然瀑布模型有很多很好的思想可以借鉴，但是在过程能力上有天生的缺陷。

迭代式模型

迭代式模型是RUP推荐的周期模型，也是我们在这个系列文章讨论的基础。在RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段（需求及其它）都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。迭代的思想如上图所示。

迭代和瀑布的最大的差别就在于风险的暴露时间上。“任何项目都会涉及到一定的风险。如果能在生命周期中尽早确保避免了风险，那么您的计划自然会更趋精确。有许多风险直到已准备集成系统时才被发现。不管开发团队经验如何，都绝不可能预知所有的风险。”（RUP）二者的区别如下图所示：

由于瀑布模型的特点（文档是主体），很多的问题在最后才会暴露出来，为了解决这些问题的风险是巨大的。“在迭代式生命周期中，您需要根据主要风险列表选择要在迭代中开发的新的增量内容。每次迭代完成时都会生成一个经过测试的可执行文件，这样就可以核实是否已经降低了目标风险。”（RUP）

快速原型（Rapid Prototype）模型是我喜欢采用的另一种模型。快速原型模型在功能上等价于产品的一个子集。注意，这里说的是功能上。瀑布模型的缺点就在于不够直观，快速原型法就解决了这个问题。一般来说，根据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品。这个产品只是实现部分的功能（最重要的）。它最重要的目的是为了确定用户的真正需求。在我的经验中，这种方法非常的有效，原先对计算机没有丝毫概念的用户在你的原型面前往往口若悬河，有些观点让你都觉得非常的吃惊。在得到用户的需求之后，原型将被抛弃。因为原型开发的速度很快，设计方面是几乎没有考虑的，如果保留原型的话，在随后的开发中会为此付出极大的代价。至于保留原型方面，也是有一种叫做增量模型是这么做的，但这种模型并不为大家所接受，不在我们的讨论之内。

上述的模型中都有自己独特的思想，其实现在的软件组织中很少说标准的采用那一种模型的。模型和实用还是有很大的区别的。

软件生命周期模型的发展实际上是体现了软件工程理论的发展。在最早的时候，软件的生命周期处于无序、混乱的情况。一些人为了能够控制软件的开发过程，就把软件开发严格的区分为多个不同的阶段，并在阶段间加上严格的审查。这就是瀑布模型产生的起因。瀑布模型体现了人们对软件过程的一个希望：严格控制、确保质量。可惜的是，现实往往是残酷的。瀑布模型根本达不到这个过高的要求，因为软件的过程往往难于预测。反而导致了其它的负面影响，例如大量的文档、繁琐的审批。因此人们就开始尝试着用其它的方法来改进或替代瀑布方法。例如把过程细分来增加过程的可预测性。