1.1. 软件的概念和特点

软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合。

其中，程序是按事先设计的功能和性能要求执行的指令序列；数据是使程序能正常操纵信息的数据结构；文档是与程序开发，维护和使用有关的图文材料。

与之相似的是，在1983年IEEE组织对软件下的定义是：计算机程序、方法、规则、相关的文档资料以及在计算机上运行程序时所必需的数据。

比软件定义更重要的是，必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。

1. 软件是一种逻辑实体，而不是具体的物理实体，因而它具有抽象性；
2. 软件的生产与硬件不同，它没有明显的制造过程；
3. 在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题。但就目前的软件工程环境应用而言，在不更新升级的情况下软件的平均寿命大约为5年，如果一个软件5年内没有任何更新，那么它将面临淘汰；
4. 软件的开发和运行常常受到计算机系统的限制，对计算机系统有着不同程度的依赖性；
5. 软件的开发至今尚未完全摆脱手工艺的开发方式；
6. 软件本身是复杂的，这种复杂性可能来自它所反映的实际问题的复杂性，例如相当多的软件工作涉及到社会因素，复杂性也可能来自程序逻辑结构的复杂性；

1.2. 软件规模的分类与发展阶段

软件的分类并没有一个绝对的标准，但一般情况下都会用软件规模来对软件进行分类，如下表：

软件发展的四个时期及其特点

1. 程序设计的原始时期(年代末)，这时既没有汇编语言也没有高级语言，程序员只能用机器指令编写程序；
2. 基本软件期(1950年代末~1960年代末)，出现了汇编语言，并逐渐普及。随着高级语言的发展，编译技术也有较大的发展；
3. 程序设计方法时代(1960 年代末~1970年代中期) 。 这一时期，与硬件费用下降相反，软件开发费急剧上升。于是人们提出了结构式程序设计和模块化程序设计等程序设计方法，设法降低软件的开发费用；
4. 软件工程时期(1970年代中期~现在)。软件开发技术不再仅仅是程序设计技术，而是包括了与软件开发的各个阶段，如需求分析、设计、编码、单元测试、综合测试、使用和维护及其整体有关的各种管理技术。

1968年在西德Garmish召开的国际软件工程会议上正式提出软件危机的概念：计算机软件的开发和维护过程所遇到的一系列严重问题。

软件危机一般表现在以下五个大方面：

1. 对软件开发成本和进度的估算很不准确。 实际成本比估计成本有可能高出一个数量级，实际进度比预期进度拖延几个月甚至几年的现象并不罕见。软件开发人员常常在对用户要求只有模糊的了解，甚至对所要解决的问题还没有确切认识的情况下，就匆忙着手编写程序；另外软件成本在计算机系统总成本中所占的比例逐年上升。由于微电子学技术的进步和生产自动化程度不断提高，硬件成本逐年下降，然而软件开发需要大量人力，软件成本随着通货膨胀以及软件规模和数量的不断扩大而持续土升。美国在1985年软件成本大约已占计算机系统总成本的90%。
2. 软件产品不符合用户的实际需要。 通常情况下用户也不知道自己想要什么，导致开发时常常出现产品与预期不匹配的现象，实际上当前的软件技术已经十分发达，搞明白了需求基本上都能通过技术实现，如下图是软件技术与需求之前的增长关系：
   
3. 软件可靠性和质量保证的确切的定量概念刚刚出现不久，软件质量保证技术(审查、复审和测试)还没有坚持不懈地应用到软件开发的全过程中，这些都导致软件产品发生质量问题;计算机软件不仅仅是程序，还应该有三整套文档资料。这些文档资料应该是在软件开发过程中产生出来的，而且应该是"最新式的"(即和程序代码完全一致的)。软件开发组织的管理人员可以使用这些文档资料作为“里程碑”，来管理和评价软件开发工程的进展状况:软件开发人员可以利用它们作为通信工具，在软件开发过程中准确地交流信息;对于软件维护人员而言，这些文档:资料更是必不可少的。
4. 缺少软件文档，大型软件系统经常失败。 缺乏方法指导和工具支持导致很多程序中的错误是非常难改正的，甚至一旦换了一个新的硬件环境就不能正常运行，也不能根据用户的需要在原有程序中增加一些新的功能。"可重用的软件"还是一个没有完全做到的、正在努力追求的目标，人们仍然在重复开发类似的或基本类似的软件
5. 软件开发效率不高，与计算机应用的迅速发展不匹配。 软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。软件产品"供不应求"的现象使人类不能充分利用现代计算机硬件提供的巨大潜力。

1.3.2. 软件危机产生的原因

客观原因：软件本身特点，例如逻辑部件复杂、规模庞大等等。

在软件开发和维护的过程中存在这么多严重问题，一方面与软件本身的特点有关，另一方面也和软件开发与维护的方法不正确有关。软件不同于硬件，它是计算机系统中的逻辑部件而不是物理部件，在运行过程中不会因为使用时间过长而被"用坏"，如果运行中发现了错误很可能是遇到了一个在开发时期引入的，在测试阶段没能检测出来的错误。

软件不同于一般程序，它的一个显著特点是规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。

主观原因：程序员不正确的开发方法，忽视需求分析，并且错误地认为软件开发等于程序编写，轻视软件维护。

主观上的错误认识和作法主要表现为忽视软件需求分析的重要性，认为软件开发就是写程序并设法使之运行，轻视软件维护等。目前相当多的软件专业人员对软件开发和维护还有不少其他的糊涂观念，在实践过程中或多或少地采用了错误的方法和技术，这可能是使软件问题发展成软件危机的主要原因。

对用户要求没有完整准确的认识就匆忙着手编写程序是许多软件开发工程失败的主要原因之一。另一方面还必须认识到程序只是完整的软件产品的一个组成部分，一个软件产品必须由一个完整的配置组成，主要包括程序、文档和数据等成分，他们缺一不可。

作好软件定义时期的工作，是降低软件，成本提高软件质量的关键。在实际的软件开发中，在软件开发的不同阶段进行修改需要付出的代价是很不相同的，大约如下图所示，它表示了错误发现的越晚，付出的代价越高。
因此可以说，轻视维护是一个巨大的错误。统计数据表明，实际上用于软件维护的费用占软件总费用的55%~70%。软件工程学的一个重要目标就是提高软件的可维护性，减少软件维护的代价。

IBMOS/360操作系统被认为是一个典型的案例，到现在为止，它仍然被使用在360系列主机中。这个经历了数十年，极度复杂的软件项目甚至产生了一套不包括在原始设计方案之中的工作系统。

IBM公司开发OS/360系统，共有4000多个模块，约100万条指令，投入5000人年，耗资数亿美元，结果还是延期交付，在交付使用后的系统中仍发现大量（2000个以上）的错误，造成无法估计的安全隐患。

1.3.3. 软件危机如何解决

实际上就目前的手段而言，软件工程只能解决主观上造成软件危机的原因，对于软件本身特点，例如逻辑部件复杂、规模庞大等客观原因，软件工程是无能为力的。

主观危机的解决途径主要有两条：1、组织管理。2、技术措施

在组织管理可以采用工程项目管理方法；

在技术措施上提升软件开发技术与方法，灵活运用软件工具。应该推广使用在实践中总结出来的开发软件的成功的技术和方法，并且研究探索更好更有效的技术和方法，尽快消除在计算机系统早期发展阶段形成的一些错误概念和做法。并且应该开发和使用更好的软件工具，在软件开发的每个阶段都有许多繁琐重复的工作需要做，在适当的软件工具辅助下，开发人员可以把这类工作做得既快又好。

为了消除软件危机，首先应该对计算机软件有一个正确的认识，首当其冲的就是彻底消除"软件就是程序"的错误 观念，要明确一个软件必须由一个完整的配置组成，是程序、数据及相关文档的完整集合。

2.1. 软件工程学的概念

软件工程学是在1968年，北约计算机科学会议上由Fritz Bauer提出的，他给出的软件工程学的定义为：用工程、科学和数学的原则与方法研制、维护计算机软件的有关技术及管理方法。其中包含了三个要素：方法、工具、过程。

软件工程学的中心思想是把软件当作一种工业产品，要求采用工程化的原理与方法对软件进行计划、开发和维护。因此可以说，软件工程学是一门指导计算机软件开发和维护的工程学科，它包含了开发技术和工程管理两方面。

2.2. 软件工程项目的基本目标

软件工程的目的是为了实现按预期的进度和经费完成软件生产计划，提高软件的生产率和可靠性。

具体来说就是要达到以下几个主要的目标：

1. 能按时完成开发工作，及时交付使用。

但是软件工程的各个目标是不可能全部满足的，下图表示了软件工程目标之间的关系，可见，软件工程的最终目标只能是实现一个均衡的系统。

2.3. 软件工程的八项原则

1. 抽取事物最基本的特性和行为，忽略非基本的细节。采用分层次抽象，自顶向下、逐层分解的办法控制软件开发过程的复杂性。例如，软件瀑布模型、结构化分析方法、结构化设计方法，以及面向对象建模技术等都体现了抽象的原则。
2. 将模块设计成“黑箱”，实现的细节隐藏在模块内部，不让模块的使用者直接访问。这就是信息封装，使用与实现分离的原则。使用者只能通过模块接口访问模块中封装的数据。
3. 模块是程序中逻辑上相对独立的成分，是独立的编程单位，应有良好的接口定义。如C语言程序中的函数过程，C++语言程序中的类。模块化有助于信息隐蔽和抽象，有助于表示复杂的系统。
4. 要求在一个物理模块内集中逻辑上相互关联的计算机资源，保证模块之间具有松散的耦合，模块内部具有较强的内聚。这有助于加强模块的独立性，控制解的复杂性。
5. 软件开发过程中所有概念的表达应是确定的、无歧义性的、规范的。这有助于人们之间在交流时不会产生误解、
   遗漏，保证整个开发工作协调致。
6. 整个软件系统(包括程序、文档和数据)的各个模块应使用一致的概念、符号和术语。程序内部接口应保持一致。软件和硬件、操作系统的接口应保持一致。系统规格说明与系统行为应保持一致。用于形式化规格说明的公理系统应保持一致。
7. 软件系统不丢失任何重要成分，可以完全实现系统所要求功能的程度。为了保证系统的完备性，在软件开发和运行过程中需要严格的技术评审。
8. 开发大型的软件系统需要对系统自顶向下逐层分解。系统分解应遵循系统易于检查、测试、评审的原则，以确保系统的正确性。

2.4. 软件工程的本质特征

软件工程关注于大型程序的构造
"大"与"小"的分界线并不十分清晰。通常把一个人在较短时间内写出的程序称为小型程序，而把多人合作用时半年以上才写出的程序称为大型程序。

软件工程的中心课题是控制复杂性
软件所解决的问题十分复杂，通常不得不把问题分解，使得分解出的每个部分是可理解的，而且各部分之间保持简单的通信关系。用这种方法并不能降低问题的整体复杂性，但是却可使它变成可以管理的。

绝大多数软件都模拟了现实世界的某一部分。现实世界在不断变化，软件为了不被很快淘汰，必须随着所模拟的现实世界一起变化。因此，在软件系统交付使用后仍然需要耗费成本，而且在开发过程中必须考虑软件将来可能的变化。

开发软件的效率非常重要
目前，社会对新应用系统的需求超过了人力资源所能提供的限度，软件供不应求的现象日益严重。因此，软件工程的一个重要课题就是，寻求开发与维护软件的更好更有效的方法和工具。

和谐地合作是开发软件的关键
软件处理的问题十分庞大，必须多人协同工作才能解决这类问题。为了有效地合作，必须明确地规定每个人的责任和相互通信的方法。纪律是成功地完成软件开发项目的一个关键。

软件必须有效地支持它的用户
开发软件的目的是支持用户的工作。软件提供的功能应该能有效地协助用户完成他们的工作。

有效地支持用户意味着必须仔细地研究用户，以确定适当的功能需求、可用性要求及其他质量要求(例如，可靠
性、响应时间等)。有效地支持用户还意味着，软件开发不仅应该提交软件产品，而且应该写出用户手册和培训材料。

在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人
软件工程师是诸如Java程序设计、软件体系结构、测试或统一建模语言(UML)等方面的专家，他们通常并不是图书馆管理、航空控制或银行事务等领域的专家，但是他们却不得不为这些领域开发应用系统。缺乏应用领域的相关知识，是软件开发项目出现问题的常见原因。

有时候，软件开发者通过访谈、阅读书面文件等方法了解到用户组织的“正式”工作流程，然后用软件实现这个工作流程。但是，决定软件系统成功与否的关键问题是，用户组织是否真正遵守这个工作流程

2.5. 软件工程的七条基本原理

著名的软件工程专家B.W.Boehm综合学者们的意见，于1983年在一篇论文中提出了软件工程的七条基本原理。这七条原理是确保软件产品质量和开发效率的原理的最小集合。

这七条原理是互相独立的，其中任意6条原理的组合都不能代替另一条原理。同时这七条原理又是相当完备的，虽然不能用数学方法严格证明它们是一个完备的集合，但是可以证明在此之前已经提出的一百多条软件工程原理都可以由这七条原理的任意组合蕴含或派生。

1. 用分阶段的生命周期计划严格管理
   经统计发现，在不成功的软件项目中有一半左右是由于计划不周造成的。因此应该把软件生命周期划分成若千个阶段，并相应地制定出切实可行的计划，然后严格按照计划对软件的开发与维护工作进行管理。不同层次的管理人员都必须严格按照计划各尽其职地管理软件开发与维护工作，绝不能受客户或上级人员的影响而擅自背离预定计划；一般来说软件的生命周期分为定义阶段、可行性研究阶段、需求分析阶段、程序设计阶段、编码阶段、测试阶段、运行维护阶段。
2. 软件的质量保证工作不能等到编码阶段结束之后再进行，这样说至少有两个理由：
   第一，大部分错误是在编码之前造成的，根据统计，设计错误占软件错误的63%，编码错误仅占37%；
   第二，错误发现与改正得越晚，所需付出的代价也越高；
   因此，在每个阶段都进行严格的评审，以便尽早发现在软件开发过程中所犯的错误，是一条必须遵循的重要原则。
3. 在软件开发过程中改变需求是难免的，只能依靠科学的产品控制技术来顺应这种要求。也就是说，当改变需求时，为了保持软件各个配置成分的一致性，必须实行严格的产品控制，其中主要是实行基准配置管理。
   所谓基准配置又称为基线配置，它们是经过阶段评审后的软件配置成分。基准配置管理也称为变动控制，指的是一切有关修改软件的建议，特别是涉及到对基准配置的修改建议，都必须按照严格的规程进行评审，获得批准以后才能实施修改。绝对不能谁想修改软件，就随意进行修改。
4. 从提出软件工程的概念开始，人们一直把主要精力用于研究各种新的程序设计技术，并进一步研究各种先进的软件开发与维护技术。实践表明，采用先进的技术不仅可以提高软件开发和维护的效率，而且可以提高软件产品的质量。
5. 软件产品不同于一般的物理产品，它是看不见摸不着的逻辑产品。软件开发人员的工作进展情况可见性差，难以准确度量，从而使得软件产品的开发过程比一般产品的开发过程更难于评价和管理。为了提高软件开发过程的可见性，更好地进行管理，应该根据软件开发项目的总目标及完成期限来规定开发组织的责任和产品标准，从而使得所得到的结果能够清楚地审查。
6. 开发小组的人员应该少而精
   软件开发小组的组成人员的素质应该好，而人数则不宜过多。素质高的人员的开发效率比素质低的人员的开发效率可能高几倍至几十倍，而且素质高的人员所开发的软件中的错误明显少于素质低的人员所开发的软件中的错误。
   此外，随着开发小组人员数目的增加，因为交流情况讨论问题而造成的通信开销也急剧增加。当开发小组人员数为N时，可能的通信路径有N(N-1)/2条，可见随着大数N的增大，通信开销将急剧增加。
7. 承认不断改进软件工程实践的必要性
   遵循上述六条基本原理，就能够按照当代软件工程基本原理实现软件的工程化生产，但是，仅有上述6条原理并不能保证软件开发与维护的过程能赶上时代前进的步伐。因此，Boehm提出应把承认不断改进软件工程实践的必要性作为软件工程的第7条基本原理。按照这条原理，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验。

3.1. 软件工程方法学的概念

软件工程包括技术和管理两方面的内容，是技术与管理紧密结合所形成的工程学科。通常把在软件生命周期全过程中使用的整套技术方法的集合称为方法学(Methodology)，也称为范型(Paradigm)。

软件工程方法学包含3个要素:

1. 方法，是完成软件开发的各项任务的技术方法，回答"怎样做"的问题；
   
2. 工具，是为运用方法而提供的自动的或半自动的软件工程支撑环境；
   
3. 过程，是为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。

3.2. 传统软件工程与面向对象软件工程

3.2.1. 传统软件工程与面向对象软件工程的对比

目前使用得最广泛的软件工程方法学有传统方法学（面向数据流/结构化方法学） 和 面向对象方法学。他们分别代表了两种程序设计方法：即结构化程序设计(程序=数据结构+算法) 和 面向对象程序设计(程序=对象+请求消息)

两种方法学的软件开发流程如下所示：
传统软件工程：软件分析→总体设计→详细设计→面向过程的编码→测试。会有一个清楚的流程体系。
面向对象软件工程：软件分析与对象抽取→对象详细设计→面向对象的编码→测试。

3.2.2. 传统软件工程的生命周期

所谓软件生命周期，软件从产生、发展到成熟，直至衰亡为止的整个过程。

国标《计算机软件开发规范》将软件生存周期分为可行性研究与计划、需求分析、总体设计、详细设计、实现(编码和单元测试)、集成测试、确认测试、使用和维护共八个小阶段

这八个小阶段又可以分为三个时期：

1. 计划时期。问题定义、可行性分析
   问题定义阶段必须回答的关键问题是"要解决的问题是什么?"如果不知道问题是什么就试图解决这个问题，显然是盲目的。尽管确切地定义问题的必要性是十分明显的，但是在实践中它却可能是最容易被忽视的一个步骤。通过对客户的访问调查，系统分析员扼要地写出关于问题性质、工程目标和工程规模的书面报告，经过讨论和必要的修改之后这份报告应该得到客户的确认。
   可行性研究阶段的关键是明确要解决问题，找出行得通解决方法，并且给出粗略的计划。系统分析员需要从经济、技术、社会(操作)等方面对软件项目进行可行性分析。可行性研究应该比较简短，这个阶段的任务不是具体解决问题，而是研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法。可行性研究的结果是使用部门负责人作出是否继续进行这项工程的决定的重要依据。可行性研究以后的那些阶段将需要投入更多的人力物力。及时终止不值得投资的工程项目，可以避免更大的浪费。
2. 开发时期。需求分析、软件设计(总体设计、详细设计)、编码、测试(单元测试和集成测试)
   需求分析阶段需要确定目标系统的任务目标以及必须具备哪些功能。系统分析员必须和用户密切配合，充分交流信息以得出经过用户确认的系统逻辑模型。通常用数据流图、数据字典和简要的算法表示在需求分析阶段确定的系统逻辑模型是以后设计和实现系统的基础。这个阶段的一项重要任务，是用正式文档准确地记录对目标系统的需求，这份文档通常称为需求《规格说明书》。
   总体设计阶段应该明确用什么方法去实现目标系统。首先，应该根据需求分析阶段的结果设计出实现目标系统的多种可选的方案。通常至少应该设计出低成本、中等成本和高成本等3种方案。软件工程师在充分权衡各种方案的利弊的基础上，推荐一个最佳方案。制定出实现最佳方案的详细计划。一个程序应该由若干个规模适中的模块按合理的层次结构组织而成。总体设计的另一项主要任务就是设计程序的体系结构，也就是确定程序由哪些模块组成以及模块间的关系，最终完成总体设计后需要记录在文档中，这份文档称为《总体设计说明书》。
   详细设计阶段的任务就是把实现目标系统的方法具体化。详细设计也称为模块设计，在这个阶段将详细地设计每个模块，确定实现模块功能所需要的算法和数据结构，最终形成一份《详细规格说明》，这种规格说明应该包含必要的细节，程序员可以根据这些细节写出实际的程序代码。
   编码和单元测试阶段的关键任务是写出正确的、容易理解、容易维护的程序模块。程序员应该根据目标系统的性质和实际环境，选取适当的程序设计语言，把详细设计的结果翻译成用选定的语言书写的程序，并且仔细测试(调试)编写出的每一个模块。
   集成测试阶段的关键任务是通过各种类型的测试(及相立的调试)使软件达到预定的要求。最基本的测试是集成测试和验收测试。所谓集成测试是根据设计的软件结构，把经过单元测试检验的模块按某种选定的策略装配起来，在装配过程中对程序进行必要的测试；所谓验收测试则是按照规格说明书的规定，由用户对目标系统进行验收。必要时还可以再通过现场测试或平行运行等方法对目标系统进一步测试检验，集成测试和验收测试结束后应该形成文档《测试报告》，里面应当写明测试计划、测试方案和结果。
3. 软件维护阶段是要通过各种必要的维护活动使系统持久地满足用户的需要"。通常有四类维护活动：改正性维护，也就是诊断和改正在使用过程中发现的软件错误；适应性维护，即修改软件以适应环境的变化，例如Windows迁移到Linux；完善性维护，即根据用户的要求改进或扩充软件使它更完善；预防性维护，即修改软件为将来的维护活动预先做准备。每一项维护活动都实质上是经历了一次压缩和简化了的软件定义和开发的全过程。

实际从事软件开发工作时，软件规模、类型、开发环境及技术方法等因素会影响到阶段划分，及各阶段的执行顺序，形成不同生存周期模型，又称过程模型。也就是说以上的三个时期所包含的阶段不一定非要按照国标来进行，应当按照实际情况灵活安排软件周期。

软件开发模型实际上是软件工程三要素中"过程"要素的展开，下面介绍几种经典的软件开发模型

4.1. 传统开发模型

瀑布模型一直是唯一被广泛采用的生命周期模型，现在它仍然是软件工程中应用得最广泛的文档驱动的过程模型。如下图所示为传统的瀑布模型

瀑布模型区别与其他模型最大的特点有三个：

1. 阶段间具有顺序性和依赖性
   (1)必须等前一阶段的工作完成之后，才能开始后一阶段的工作；
   (2)前一阶段的输出文档就是后一阶段的输入文档。因此，只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。
2. 对于规模较大的软件项目来说，往往实现(编码和测试)开始得越早最终完成开发工作所需要的时间反而越长。这是因为，前面阶段的工作没做或做得不扎实，过早地考虑进行程序实现，往往带来灾难性后果瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，清楚地区分逻辑设计与物!理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要的指导思想
3. 软件工程的基本目标是优质、高产。为了保证所开发的软件的质量，在瀑布模型的每个阶段都应坚持两个重要做法:
   (1)每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务；
   (2)每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。

传统的瀑布模型过于理想化了，事实.上，人在工作过程中不可能不犯错误。实际的瀑布模型是带"反馈环"的，如下图所示。
实际的瀑布模型当在后面阶段发现前面阶段的错误时，需要沿图中左侧的反馈线返回前面的阶段，修正前面阶段的产品之后再回来继续完成后面阶段的任务。

快速原型模型是低成本的，进行循环需求分析的一个快速开发模型。它的基本结构如图所示。
原型是值快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集，然后在用户的不断使用中探明用户需求，不断对原型进行改进，最终完成需求分析。

因此它的两个最大的优点就是：

1. 原型系统已经通过与用户交互而得到验证，据此产生的规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工。
2. 开发人员通过建立原型系统已经学到了许多东西，因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。

4.2. 演化开发模型

增量模型也称为渐增模型。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和
测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。开发流程如下图所示
下图是每一个增量构建的实现过程图：

增量模型能在较短时间内向用户提交可完成部分工作的产品。逐步增加产品功能可以使用户有较充裕的时间学
习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。

但是它也是有缺陷的，增量模型面临的最大困难就是必须保证在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便，也就是说，软件体系结构必须是开放的。

螺旋模型的基本思想是，使用原型及其他方法来尽量隆低风险。理解这种模型的一个简便方法，是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。从本质上来讲，螺旋模型就是一个加入了风险分析的快速原型模型。

螺旋模型的主要优势在于，它是风险驱动的。它的开发过程如图所示：

一个螺旋式周期包括下面4个完整步骤：

1. 确定目标，选择方案，选定完成目标的策略
2. 评价前一步的结果，并计划下一轮的工作

4.3. 面向对象开发模型

构建集成模型是一个典型的面向对象开发模型，它的一个典例就是各种开发IDE，例如Visual Studio，可以查找加载各种构建。

构建集成模型有着以下五个特点：面向对象、基于构件库、融合螺旋模型特征、支持软件开发的迭代方法、软件重用

专家简介：黄步余，男，中国石化工程建设公司副总工程师。

测量仪表设计选用原则？

SIS工程设计要求有哪些？

如何进行SIS安全验证？

11.测量仪表设计选用

1）传感器采用隔爆型的变送器（压力、差压、差压流量、差压液位、 温度），不采用开关型传感器；传感器由SIS系统供电。 

2）独立设置原则： 

SIL 1级安全仪表功能，测量仪表可与基本过程控制系统共用；

SIL 2级安全仪表功能，测量仪表宜与基本过程控制系统分开； 

SIL 3 级安全仪表功能，测量仪表应与基本过程控制系统分开。

3）冗余设置原则： 

SIL 1级安全仪表功能，可采用单一测量仪表；

SIL 2级安全仪表功能，宜采用冗余测量仪表； 

SIL 3级安全仪表功能，应采用冗余测量仪表。 

当系统要求高安全性时，应采用“或”逻辑结构；

当系统要求高可用性时，应采用“与”逻辑结构；

当系统的安全性和可用性均需保障时，宜采用三取二逻辑结构。

12.逻辑控制器设计选用

1）逻辑控制器采用可编程电子系统，也可采用可编程电子系统和继电器系统混合构成；

2）逻辑控制器应采用国家权威机构功能安全认证的可编程电子系统。

SIL1级安全仪表功能，逻辑控制器宜与基本过程控制系统分开。 

SIL2级安全仪表功能，逻辑控制器应与基本过程控制系统分开。 

SIL3级安全仪表功能，逻辑控制器必须与基本过程控制系统分开。 

SIL1级安全仪表功能，宜采用冗余逻辑控制器。 

SIL2级安全仪表功能，应采用冗余逻辑控制器。 

SIL3级安全仪表功能，必须采用冗余逻辑控制器。

逻辑控制器专门用于安全防护或安全控制功能；

逻辑控制器经权威机构认证具有SIL能力；

逻辑控制器应有安全手册；

逻辑控制器为了防止随机性硬件失效，系统内部应带自诊断；

逻辑控制器硬件故障裕度和诊断覆盖率满足SIL3要求；

逻辑控制器采用软件故障输入测试、程序流控制诊断、数据确认等技术；

逻辑控制器通信接口具有读写保护，不允许外部直接访问I/0卡；

13.最终元件设计选用

1）最终元件包括控制阀(调节阀、切断阀)、电磁阀、电机等

SIL 1级安全仪表功能，控制阀可与基本过程控制系统分开。 

SIL 2级安全仪表功能，控制阀宜与基本过程控制系统分开。 

SIL 3级安全仪表功能，控制阀应与基本过程控制系统分开。

SIL1级安全仪表功能，可采用单一控制阀。 

SIL2级安全仪表功能，宜采用冗余控制阀。 

SIL3级安全仪表功能，应采用冗余控制阀。 

控制阀可采用一个调节阀和一个切断阀，也可采用二个切断阀。

4）电磁阀应采用长期带电，低功耗，隔爆型；由SIS系统供电。

SIS宜设操作员站。在操作员站失效时，SIS逻辑处理功能不应受影响。 

操作员站功能不应修改SIS的编程软件。

操作员站设置的软件旁路开关应加键锁或口令保护，并应设置旁路状态报警并记录。

操作员站应提供程序运行、联锁动作、输入输出状态、诊断等显示、报警及记录。 

(2) 工程师站及事件顺序记录站 

工程师站用于SIS组态编程、系统诊断、状态监测、编辑、修改及系统维护。

工程师站应设不同级别的权限密码保护。工程师站应显示SIS动作和诊断状态。

事件顺序记录站可与SIS系统的工程师站共用，也可单独设置。

事件顺序记录站记录每个事件的时间、日期、标识、状态等。

工程师站和事件顺序记录站宜设置防病毒等保护措施 。

紧急停车按钮、开关、信号报警器及信号灯等应安装在辅助操作台。

信号报警宜采用操作员站显示；也可采用信号报警器显示。

一般信号报警在操作员站显示,关键信号报警应在辅助操作台上显示。

紧急停车按钮,开关,信号报警器等与SIS采用硬连接方式。 

SIS的维护旁路开关、操作旁路开关、复位按钮可采用下列设置方式： 

1)在SIS操作员站设置软件按钮。 

2)在BPCS中设置软件按钮,采用通信方式与SIS连接。 

3) 在辅助操作台设置件按钮,采用硬连接方式。

SIS的紧急停车按钮应设置在辅助操作台上。

SIS的维护旁路开关、操作旁路开关、复位按钮、紧急停车按钮的操作 , 应按规定的操作程序进行，并应有报警、记录、备份。

SIS与BPCS通信接口宜采用冗余配置。冗余通信接口应有诊断功能。

SIS与BPCS通信不应通过工厂管理网络传输。

除旁路和复位信号之外，BPCS不应采用通信方式向SIS发送指令。

除BPCS外，SIS与其它系统之间不应设置通信接口。 

通信接口故障不应影响SIS的安全功能，不应引起安全功能的动作。

网络通信接口负荷不应超过50%。

应用软件的组态宜采用功能逻辑图或布尔逻辑表达式。

应用软件的组态应使用制造厂的标准组态工具软件 。 

应用软件组态工具软件应符合安全完整性等级的要求。

应用软件组态编程应进行离线测试后方可下载投入运行。

应用软件采用光盘进行数据复制。磁介质文件应防止病毒。

应用软件应做本地备份和异地备份。

应用软件组态编程应与功能逻辑图、因果表或逻辑说明一致。

根据安全完整性等级确定SIS的功能，编制SIS测量仪表、SIS逻辑控制器、 SIS最终元件的技术规格书。

根据工艺安全联锁说明、P&I流程图等，编制SIS 基础工程设计文件。 

* 功能逻辑图、因果表及复杂逻辑联锁说明； 

* 测量仪表、最终元件的选型原则。

* SIS技术规格书；

* 联锁及报警设定值； 

* 应用软件需要的技术资料。

应用软件组态编程文件及图纸等。

18.SIS组态、集成与调试、验收测试

1)SIS系统工程文件包括:系统硬件规格书,系统软件规格书,系统配置图, 机柜布置, 接线图,系统供电,接地图,负荷计算表,功耗计算表；输入/输出卡点分配表,组态编程文件,操作维护手册等。

2)根据详细工程设计文件完成工程师站,操作员站，事件顺序记录站,辅助操作台,系统柜,端子柜,安全栅柜,继电器柜,电源柜,网络柜等集成。

3)根据因果表或逻辑图完成软件组态和编译。审查硬件、系统软件及应用软件集成完成系统硬件和软件检查、应用软件下装及调试。

4)验收测试包括工厂验收测试（FAT）、工厂联合测试（IFAT）和现场验收测试（SAT ）。

自动化仪表工程施工及验收规范（GB 50093） 

石油化工仪表工程施工技术规范（SH 3210）

石油化工仪表工程施工技术规范（SH 3521）

工程建设交工技术文件规定（SH 3503） 

石油化工建设工程项目施工过程技术文件规定（SH 3543）

2)按照SIS功能设计设计规格书、安装手册及安全手册规程安装调试；

3)现场测量仪表、最终执行元件、逻辑控制器及关联部件安装正确；

4)双UPS电源供电、接地、绝缘、防雷等符合设计要求；

5)每根电缆、单模光缆熔接准确无误，无物理损坏； 

6)严格按照SIS制造厂推荐操作程序进行安全功能测试；

7)现场测量仪表、最终执行元件、MCC、AUX与逻辑控制器间信号回路100%检查调试；

8)逻辑控制器输入输出及逻辑控制功能100%检查调试；

9)逻辑控制器、远程控制器、远程I/0、AUX等冗余光纤通信调试；

10)SIS现场测量仪表、最终执行元件、逻辑控制器、网络交换机、人机界面等硬件、 软件集成调试。

SIS安全验证及其安全仪表功能；

SIS实现的全部功能；

SIS冗余控制器的冗余性能及降级模式；

SIS冗余控制器的信号处理、计算逻辑、复位复位、通信等功能； 

SIS冗余控制器的诊断、报警、旁路、故障恢复等功能；

SIS预开车验收测试（PSAT）和现场验收测试； 

全生命周期运行管理团队； 

全生命周期运行管理程序；

SIS系统独立、网络独立、网络安全；

 SIS系统运行、功能测试、维护、保持SIL等级不降低； 

SIS运行管理团队强化培训、工艺、设备、控制、操作相关知识。

22.SIS操作维护、变更、文档管理

维护人员职责与管理规程。

定期诊断测试计划及报告。

停车期间的系统检查管理。 

维护旁路开关、操作旁路开关的使用管理。

变更原因及方案，包括系统的版本升级，增减或修改逻辑等。 

审核评估变更方案，确认变更的安全仪表功能。

变更方案的详细设计与实施方案。

变更软件功能的离线测试与检查要求。

变更报告及操作维护规程更新。

安全生命周期各阶段的文档管理。 

编制文档管理及控制规程。

制定项目统一的文件命名规则、文件格式、文件传递方式。 

编制文件审核流程及文件版本管理规定。

关注“经燕化工平台”，第一时间获取石化、化工行业最新市场动态，以及新技术推广和行业信息。   

媒体合作、专家投稿、新技术推广等需求，欢迎垂询！