[架构之路-131]-《软考-系统架构设计师》-软件工程-1-软件工程方法大全（软件开发过程方法、软件开发过程模型、逆向工程、净室软件工程）

前言：

第3章 软件工程

3.1 软件开发过程方法

3.1.1 什么是软件工程

软件工程是一门研究用工业硬件生产的工程化方法构建和维护有效、实用和高质量的软件的学科。

它涉及程序设计语言、数据库、软件开发工具、系统平台、标准、设计件有电子邮件、嵌入式系统、人机界面、办公套件、操作系统、编译器、数据库、游戏等。

同时，各个行业几乎都有计算机软件的应用，如工业、农业、银行、航空、政府部门等，这些应用促进了经济和社会的发展，也提高了工作效率和生活效率 。

BarryBoehm：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。

IEEE：在软件工程术语汇编中的定义：软件工程是：将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化的方法应用于软件开发的整个生命周期；

FritzBauer：在NATO会议上给出的定义：建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。

3.1.2 软件工程的方法论

（1）软件开发过程方法

（2）软件开发过程模型

（3）软件逆向工程

（4）净室软件工程

3.1.3 软件开发方法

方法论，就是关于人们认识世界、改造世界的方法的理论。

它是人们用什么样的方式、方法来观察事物和处理问题。概括地说，世界观主要说明世界“是什么”的问题，方法论主要说明“怎么办”的问题。

方法论是一种以解决问题为目标的理论体系或系统，通常涉及对问题阶段、任务、工具、方法技巧的论述。方法论会对一系列具体的方法进行分析研究、系统总结并最终提出较为一般性的原则。

方法论也是一个哲学概念。人们关于“世界是什么、怎么样”的根本观点是世界观。用这种观点作指导去认识世界和改造世界，就成了方法论。 方法论是普遍适用于各门具体社会科学并起指导作用的范畴、原则、理论、方法和手段的总和。历史唯物主义的著作中经常提到方法论这个概念。

软件开发方式，就是人们是如何认识软件世界的，或者说人们认识软件世界、开发软件世界的方法。

在上个世纪60年代中期爆发了众所周知的软件危机。为了克服这一危机，在1968、1969年连续召开的两次著名的NATO会议上提出了软件工程这一术语，并在以后不断发展、完善。与此同时，软件研究人员也在不断探索新的软件开发方法。已形成了八类软件开发方法，其中常见的五大方法如下：

不同方法的区别在于：其操作的基础目标不同。

3.1.3.1 结构化方法：面向数据流的开发方法

结构化不是指基于数据结构，采用系统化、结构化的方法。

结构化方法包括：分析，设计，程序设计构成，面向数据流的开发方法，分解和抽象的原则，数据流图建立功能模型，完成需求分析工作。

也就是说，人们通过结构化分解的方法来获得目标软件系统的内部实现。

备注：

所谓结构化，是指将逐渐积累起来的知识加以归纳和整理，使之条理化、纲领化，做到纲举目张。知识是逐渐积累的，但在头脑中不应该是堆积的。心理学研究已发现，优生和差生的知识组织存在明显差异。优生头脑中的知识是有组织、有系统的，知识点按层次排列，而且知识点之间有内在联系，具有结构层次性。而差生头脑中的知识则水平排列，是零散和孤立的。

结构化对知识学习具有重要作用，因为当知识以一种层次网络结构的方式进行储存时，可以大大提高知识应用时的检索效率。

3.1.3.1.1 结构化分析方法的基本特征或优点

• 分解法（分而治之）：分阶段、分任务、分模块。

• 串行化：上下游串行执行。

• 标准化：模块之间，阶段与阶段之间都有明确的接口和文档；模块部由顺序、分支、循环基本控制结构组成。

• 自顶向下,逐步求精；

3.1.3.1.2 结构化分析方法的缺点

• (1)开发周期较长难以适应环境的变化。

• (2)开发过程严格无法适应需求的变化。

• (3)难以应付非结构化的问题。

• (4)用户很难尽早建立系统预期的概念结构。

3.1.3.1.3 分阶段法与生命周期模型

软件生命周期(Software Life Cycle,SLC)是软件的产生直到报废或停止使用的生命周期。

软件生命周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，也有将以上阶段的活动组合在内的迭代阶段，即迭代作为生命周期的阶段。

3.1.3.1.4 产品生命周期

3.1.3.2 Jackson方法：面向数据结构开发方法（JSD(Jackson System Development)。

面向数据结构开发方法。

数据结构为驱动，适合小规模的项目，当输入数据结构和输出结构之间没有对应关系，难用此方法，JSD(Jackson Structure Prograamming)是JSP(JacksonSystem Development)的扩充。

该方法先定义数据结构，然后把数据结构转换为问题解的程序结构。在许多领域信息有着清晰的层次结构，输入数据、存储信息（即数据库）及数据输出都有各自的组成样式。因此可以顺序出现的就用顺序结构，选择出现的就用分支结构，反复出现的就用循环结构。

• ①确定数据结构特征；

• ②用顺序、选择和重复三种基本形式表示数据；

• ③把数据结构表示映射为软件的控制结构；

• ④用与具体方法配套的设计指南进一步精化控制结构；

• ⑤软件的过程性描述。

3.1.3.3.原型化方法：面向不确定性的开发方法

和演化模型相对应，需求不清，业务理论不确定，需求经常变化，规模不大去不太复杂时采用。

原型化开发是软件开发的一种常用方法。开发人员对用户提出的问题进行总结，就系统的主要需求取得一致意见后，开发出一个原型并运行之，然后反复对原型进行修改，使之逐步完善，直到用户对系统完全满意为止。

原型化开发是软件开发的一种常用方法。

开发人员对用户提出的问题进行总结，就系统的主要需求取得一致意见后，开发出一个原型并运行之，然后反复对原型进行修改，使之逐步完善，直到用户对系统完全满意为止。

原型化开发方法的开发过程中，可以脱离早期构造的软件原型进行独立,原型化方法实际上是一种快速确定需求的策略，对用户的需求进行提取、求精，快速建立最终系统工作是模型的方法。要求要有完整的生命周期，原型化是一种动态设计过程，它需要加强用户的参与和决策，以求尽快地将需求确定下来，采用这样一个(与最终系统相比)相对简化的模型就可以简化项目的管理。

3.1.3.4.面向对象开发方法：面向对象的开发方法

面向对象开发方法将面向对象的思想应用于软件开发过程中，指导开发活动，是建立在“对象”概念基础上的方法学，简称OO( Object-Oriented)方法。面向对象方法的本质是主张参照人们认识一个现实系统的方法，完成分析、设计与实现一个软件系统，提倡用人类在现实生活中常用的思维方法来认识和理解描述客观事物，强调最终建立的系统能映射问题域，使得系统中的对象，以及对象之间的关系能够如实地反映问题域中固有的事物及其关系。

分析，设计，实现，Booch,Coad,OMT，为统一各种面向对象方法的术语，概念和模型，推出UML (Unified Modeling Language)统一化建模语言，成为工业标准。

面向对象开发方法认为客观世界是由对象组成的，对象由属性和操作组成，对象可按其属性进行分类，对象之间的联系通过传递消息来实现，对象具有封装性、继承性和多态性。

面向对象开发方法是以用例驱动的、以体系结构为中心的、迭代的和渐增式的开发过程，主要包括需求分析、系统分析、系统设计和系统实现四个阶段，但是各个阶段的划分不像结构化开发方法那样清晰，而是在各个阶段之间迭代进行的。

3.1.3.5. 面向服务的开发方法

面向服务的体系结构是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以使用一种统一和通用的方式进行交互。

SOA （Service-Oriented Architecture，SOA），从应用和原理的角度，目前有2种公认的标准定义。

从应用的角度定义：可以认为SOA是一种应用程序架构。将业务应用划分为单独的业务功能和流程，即所谓的服务。所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务来形成业务流程。

这种业务灵活性可以使企业快速发展，降低成本，改善对及时、准确信息的访问。有助于实现更多的资产重用、更轻松的管理和更快的开发和部署。

从软件的基本原理定义：可以认为SOA是一个组件模型。它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。

接口就是采用中立的方式 进行定义的，它独立于服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以一种统一和通用的方式进行交互。

3.1.4 软件开发过程模型（模板、参考、样板、标准、规范）

3.1.4.1 概述

软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。

软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。

软件开发模型，基于某种软件开发方法，能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。

软件开发模型是对某种软件开发方法的细化、结构化、框架化。

对于不同的软件系统，可以采用不同的开发方法、使用不同的软件开发模型、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等，以及允许采用不同的软件工具和不同的软件工程环境。

典型的开发模型有：1. 边做边改模型（Build-and-Fix Model）；2. 瀑布模型（Waterfall Model）；3. 快速原型模型（Rapid Prototype Model）；4. 增量模型（Incremental Model）；5.螺旋模型（Spiral Model）；6.演化模型(evolution model)；7.喷泉模型(fountain model)；8.智能模型(四代技术（4GL）)；9.混合模型（hybrid model）；10.RAD模型；更多模型如下图所示：

3.1.4.2 边做边改型

许多不正规的产品开发都是使用"边做边改"模型来开发的。

在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改.

在这个模型中，只有客户与程序员，只有客户需求与代码，没有中间过程！！！

在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。

这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，大部分大学生的毕业设计就是这种模型。

但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：

• （1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；

• （2） 忽略需求环节，给软件开发带来很大的风险；

• （3） 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。

于是，有了最早的、规范化、最经典的软件开发模型！！！

3.1.4.3 瀑布模型（一气呵成）

1970年Winston Royce提出了著名的"瀑布模型"，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。

瀑布模型强调文档的作用，并要求每个阶段的文档都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：

• （1） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；

• （2） 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；

• （3） 早期遗留的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

我们应该认识到，"线性"是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的"非线性"问题时，总是千方百计地将其分解或转化为一系列简单的线性问题，然后逐个解决。一个软件系统的整体可能是复杂的，而单个子程序总是简单的，可以用线性的方式来实现，否则干活就太累了。

线性是一种简洁，简洁就是美。当我们领会了线性的精神，就不要再呆板地套用线性模型的外表，而应该用活它。例如增量模型实质就是分段的线性模型，螺旋模型则是接连的弯曲了的线性模型，在其它模型中也能够找到线性模型的影子。

瀑布模型适合需求一开始就比较明确的场合，采用瀑布模型的关键就是明确和固化软件需求。

瀑布模型非常适合软件项目外包的场合，但不适合互联网服务器端软件频繁变化的开发。

频繁的需求变更，对瀑布模型来讲，就是噩梦！！！

3.1.4.4 快速原型模型

快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。

通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。

显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。快速原型只关注满足客户需求，可能导致系统设计差、效率低，难于维护。

快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。

3.1.4.5 增量模型、演化模型

增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。运用增量模型的软件开发过程是递增式的过程。相对于瀑布模型而言，采用增量模型进行开发，开发人员不需要一次性地把整个软件产品提交给用户，而是可以分批次进行提交。

又称演化模型。与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成.增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。

整个产品被分解成若干个构件，开发人员逐个构件地交付产品，每个子集（如一个个feature）采用瀑布模型，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。

但是，增量模型也存在以下缺陷：

（1） 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。

（2） 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。

在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。

例如，使用增量模型开发文字处理软件。可以考虑，第一个增量发布基本的文件管理、编辑和文档生成功能，第二个增量发布更加完善的编辑和文档生成功能，第三个增量实现拼写和文法检查功能，第四个增量完成高级的页面布局功能。

该模型适合大型复杂软件系统的研发！！！很多传统的大型的跨国企业，采用的就是这种模型。

3.1.4.6 螺旋模型（敏捷模型、迭代）

1988年，Barry Boehm正式发表了软件系统开发的"螺旋模型"，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。

螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：

（1） 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；

（2） 风险分析：分析评估所选方案，考虑如何识别和消除风险；

（3） 实施工程：实施软件开发和验证；

（4） 客户评估：评价开发工作，提出修正建议，制定下一步计划。

螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制条件，具体如下：

（1） 螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。

（2） 如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。

（3） 软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险

一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，

然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。

如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。

最后，评价该阶段的结果，并设计下一个阶段。

附加信息：增量模型与迭代模型的区别

增量模型与螺旋模型非常相似，都是逐步增加新的需求。

增量模型：每次发布一个完整的功能模块，属于纵向切分。

螺旋模型：每个发布多个功能块的一部分功能，属于横向切分。

3.1.4.7 V模型（强调了测试贯彻始终，强调尽早测试）

RAD（Rapid Application Development，快速应用开发）模型是软件开发过程中的一个重要模型，由于其模型构图形似字母V，所以又称软件测试的V模型。

V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。

解决的思路是，当一个软件开发的时候，研发人员和测试人员需要同时工作，测试在软件做需求分析的同时就会有测试用例的跟踪，这样，可以尽快找出程序错误和需求偏离，从而更高效的提高程序质量，最大可能的减少成本，同时满足用户的实际软件需求。

V模式是一种传统软件开发模型，一般适用于一些传统信息系统应用的开发，而一些高性能高风险的系统、互联网软件，或一个系统难以被具体模块化的时候，就比较难做成V模式所需的各种构件，需要更强调迭代的开发模型或者敏捷开发模型。

• 1、需求分析阶段对应生成需求规格说明书，对应测试生成系统测试方案，即为系统测试准备的，该阶段已经完成了单元测试和集成测试，主要是对软件产品的功能与非功能进行测试，几乎不测试代码，所以测试方法以黑盒为主；

• 2、概要设计阶段对应生成概要设计说明书，对应测试生成集成测试方案，该阶段已完成单元测试，是将各个功能模块组装起来进行的测试，所以也叫组装测试。主要看模块调用是否正常，接口是否可用，数据传输是否正确等，所以用到的测试方法几乎是白盒的方法，如路径覆盖，条件组合覆盖等；

• 3、详细设计阶段对应生成详细设计说明书，对应测试生成单元测试方案，该阶段是开发人员编码后的第一个测试阶段，是对开发出来的单独模块进行测试，以确保每一个功能模块的功能正常，可以构建桩模块和驱动模块来回调用，方法也是以白盒为主。

• 4、白盒测试的准则是尽可能覆盖程序内部的逻辑结构，黑盒则是尽可能覆盖所有的输入输出接口，包括文档等一些静态的测试。除常用的测试方法外，仍需补充大范围的随机测试，尽可能达到覆盖率100%。

3.1.4.8 喷泉模型

喷泉模型（fountain model）是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。该模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性。

喷泉模型主要用于采用对象技术的软件开发项目。该模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性。软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分。无间隙指在各项活动之间无明显边界，如分析和设计活动之间没有明显的界限，由于对象概念的引入，表达分析、设计、实现等活动只用对象类和关系，从而可以较为容易地实现活动的迭代和无间隙，使其开发自然地包括复用。

1、喷泉模型的优点

喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。 并发的前提条件是：对象的独立性！！！

2、喷泉模型的缺点

由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。

3.1.4.9 基于构建的快速应用开发（RAD）模型

快速应用开发（RAD）模型是一个增量型的软件开发过程模型。强调极短的开发周期。

RAD模型是瀑布模型的一个“高速”变种，通过大量使用可复用构件，采用基于构件的建造方法赢得快速开发。

可复用构件是快速开发的前提，软件开发编程了组件的组装！！！

可复用构件的来源：

• 标准库：成熟的标准库

• 第三方库：第三方公司提供的构件库

• 研发自己的构建库：构建库的准备需要花费大量的时间。

微服务架构就非常适合采用快速应用开发RAD模型。

微服务就是基于Web服务应用的、可以远程访问的构件！！！

图形化编程的UI控件，也是一个个构件！！！

Python的软件开发，就有构件开发的味道，Python提供了大量的第三方库和图形化的控件、微服务，都是构件（component）。

如果需求理解得好且约束了项目的范围，随后是数据建模、过程建模、应用生成、测试及反复。采用RAD模型的软件过程如下图所示：

RAD模型各个活动期所要完成的任务如下：

（1）业务建模：以什么信息驱动业务过程运作？要生成什么信息？谁生成它？信息流的去向是哪里由谁处理？可以辅之以数据流图。

（2）数据建模：为支持业务过程的数据流找数据对象集合，定义数据对象属性，与其他数据对象关系构成数据模型，可辅之以E-R图。

（3）过程建模：使数据对象在信息流中完成各业务功能。创建过程以描述数据对象的增加、修改、删除、查找，即细化数据流图中的处理框。

（4）应用程序生成：利用第四代语言（4GL）写出处理程序，重用已有构件或创建新的可重用构件，利用环境提供的工具自动生成并构造出整个应用系统。

（5）测试与交付，由于大量重用，一般只做系统测试，但新创建的构件还是要测试的。

3.1.4.10 统一过程的开发模型（RUP/UML)

统一软件开发过程（Rational Unified Process,RUP)是一个面向对象且基于网络的程序开发方法论。根据Rational(Rational Rose和统一建模语言的开发者)的说法，好像一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针，模版以及事例支持。 RUP和类似的产品--例如面向对象的软件过程（OOSP），以及OPEN Process都是理解性的软件工程工具--把开发中面向过程的方面（例如定义的阶段，技术和实践）和其他开发的组件（例如文档，模型，手册以及代码等等）整合在一个统一的框架内。

架构为中心：架构图贯串需求到设计，再到软件开发，不同阶段，采用不同层面的架构图。

用例驱动：“用例”是整个架构的起点，是整个层次架构图的源头和根，不同的用户用例，代表了不同的用户需求，从而衍生出后续的各种层面的架构图，从而驱动代码的开发。

迭代与增量：用例并非一次性完成，可以通过迭代和增量的方式逐步增强软件系统的功能。

六大经验：

（1）迭代式开发

在软件开发的早期阶段就想完全、准确的捕获用户的需求几乎是不可能的。实际上，我们经常遇到的问题是需求在整个软件开发工程中经常会改变。迭代式开发允许在每次迭代过程中需求可能有变化，通过不断细化来加深对问题的理解。迭代式开发不仅可以降低项目的风险，而且每个迭代过程以可以执行版本结束，可以鼓舞开发人员。

（2）管理需求

确定系统的需求是一个连续的过程，开发人员在开发系统之前不可能完全详细的说明一个系统的真正需求。RUP描述了如何提取、组织系统的功能和约束条件并将其文档化，用例和脚本的使用以被证明是捕获功能性需求的有效方法。

（3）基于组件的体系结构

组件使重用成为可能，系统可以由组件组成。基于独立的、可替换的、模块化组件的体系结构有助于管理复杂性，提高重用率。

RUP描述了如何设计一个有弹性的、能适应变化的、易于理解的、有助于重用的软件体系结构。

（4）可视化建模

RUP往往和UML联系在一起，对软件系统建立可视化模型帮助人们提供管理软件复杂性的能力。

RUP告诉我们如何可视化的对软件系统建模，获取有关体系结构于组件的结构和行为信息。

（5）验证软件质量

在RUP中软件质量评估不再是事后进行或单独小组进行的分离活动，而是内建于过程中的所有活动，这样可以及早发现软件中的缺陷。

（6）控制软件变更

迭代式开发中如果没有严格的控制和协调，整个软件开发过程很快就陷入混乱之中，RUP描述了如何控制、跟踪、监控、修改以确保成功的迭代开发。

RUP通过软件开发过程中的制品，隔离来自其他工作空间的变更，以此为每个开发人员建立安全的工作空间。

备注：

统一过程的开发模型（RUP/UML)不仅仅提供了软件开发的宏观模型，还给出了如何为开发过程中的每个环节进行建模，不同开发阶段，所建立的模型和方法不同！！！

3.1.4.11 敏捷软件开发模型

敏捷开发模式是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。

敏捷比较适合互联网服务器端软件开发模式，服务器的软件部署完全有开发方自己决定，客户的话语权比较弱，比如百度、阿里、腾讯，还软件开发过程还必须有自动化流程配合。

敏捷不太适合甲方-乙方的合同外包软件开发模式，这种模式下，软件的开发需求完全来着与客户，最后项目的验收也完全有客户确定，最后出钱的也是客户，这种情况下的变动，都会影响项目的交付周期和项目及交付的范围。

如果要实行一个很好的scrum,通常要满足两点：

一、团队有三名或以上的研发工程师；

二、团队内有一名合适的Scrum Master。当团队内无法找到合适的Scrum Master时，不要轻易推行敏捷。如果你的团队是由新人组成，或者即使有资深员工但是他并不了解或认同敏捷开发的话，那么你需要等待合适的Scrum Master出现。

当你真正实行敏捷开发时，要注意量化衡量团队的执行力的指标：完成度、评估准确度、计划合理度。这是评定整个进度的很重要的指标，也是让迭代更好的进行下去的准则。

传统的瀑布式开发，也就是从需求到设计，从设计到编码，从编码到测试，从测试到提交大概这样的流程，要求每一个开发阶段都要做到最好。

特别是前期阶段，设计的越完美，提交后的成本损失就越少。

迭代式开发，不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，

最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。

螺旋开发，很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。

敏捷开发，相比迭代式开发两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。

敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。

适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化.

3.1.5 逆向工程

基本概念：

逆向工程（又称逆向技术），是一种产品设计技术再现过程，即对一项目标产品进行逆向分析及研究，从而演绎并得出该产品的处理流程、组织结构、功能特性及技术规格等设计要素，以制作出功能相近，但又不完全一样的产品。

逆向工程源于商业及军事领域中的硬件分析。其主要目的是在不能轻易获得必要的生产信息的情况下，直接从成品分析，推导出产品的设计原理。

逆向工程可能会被误认为是对知识产权的严重侵害，但是在实际应用上，反而可能会保护知识产权所有者。例如在集成电路领域，如果怀疑某公司侵犯知识产权，可以用逆向工程技术来寻找证据。

产生动机：

需要逆向工程的原因如下：

• ●接口设计。由于互操作性，逆向工程被用来找出系统之间的协作协议。

• ●军事或商业机密。窃取敌人或竞争对手的最新研究或产品原型。

• ●改善文档。当原有的文档有不充分处，又当系统被更新而原设计人员不在时，逆向工程被用来获取所需数据，以补充说明或了解系统的最新状态。

• ●软件升级或更新。出于功能、合规、安全等需求更改，逆向工程被用来了解现有或遗留软件系统，以评估更新或移植系统所需的工作。

• ●制造没有许可/未授权的副本。

• ●学术/学习目的。

• ●去除复制保护和伪装的登录权限。

• ●文件丢失：采取逆向工程的情况往往是在某一个特殊设备的文件已经丢失了（或者根本就没有），同时又找不到工程的负责人。完整的系统时常需要基于陈旧的系统上进行再设计，这就意味着想要集成原有的功能进行项目的唯一方法，便是采用逆向工程的方法，分析已有的碎片进行再设计。

• ●产品分析：用于调查产品的运作方式，部件构成，估计预算，识别潜在的侵权行为。

• ●制作游戏外挂：通过逆向工程了解游戏运行机制，进而绕过保护机制并通过修改内存数值、修改内存中的代码、调用内部函数等方式来实现外挂功能。

方法实现：

软件逆向工程有多种实现方法，主要有三：

• 1.分析通过信息交换所得的观察。

最常用于协议逆向工程，涉及使用总线分析器和数据包嗅探器。在接入计算机总线或网络的连接，并成功截取通信数据后，可以对总线或网络行为进行分析，以制造出拥有相同行为的通信实现。此法特别适用于设备驱动程序的逆向工程。有时，由硬件制造商特意所做的工具，如JTAG端口或各种调试工具，也有助于嵌入式系统的逆向工程。对于微软的Windows系统，受欢迎的底层调试器有SoftICE。

• 2.反汇编，即使用反汇编器，把程序的原始机器码，翻译成较便于阅读理解的汇编代码。这适用于任何的计算机程序，对不熟悉机器码的人特别有用。流行的相关工具有OllyDebug和IDA。

• 3.反编译，即使用反编译器，尝试从程序的机器码或字节码，重现高级语言形式的源代码。

3.1.6 净室软件工程

净室软件工程是一种应用数学与统计学理论以经济的方式生产高质量软件的工程技术，力图通过严格的工程化的软件过程达到开发中的零缺陷或接近零缺陷。

净室方法不是先制作一个产品，再去消除缺陷，而是要求在规约和设计中消除错误，然后以“净”的方式制作，可以降低软件开发中的风险，以合理的成本开发出高质量的软件。这种软件开发方法背后的技术基础是数学模型！！！如果AI模型。

传统的软件工程建模、形式化方法、程序验证(正确性证明)、以及统计SQA的集成使用已经组合成一种可以导致极高质量软件的技术。

净室软件工程(Cleanroom software engineering)是一种在软件开发过程中强调在软件中建立正确性的需要的方法。代替传统的分析、设计、编码、测试和调试周期，净室方法建议一种不同的观点。

在净室软件工程后面的哲学是：通过在第一次正确地书写代码增量并在测试前验证它们的正确性来避免对成本很高的错误消除过程的依赖。它的过程模型是在代码增量积聚到系统的过程的同时进行代码增量的统计质量验证。 它甚至提倡开发者不需要进行单元测试，而是进行正确性验证和统计质量控制。

净室方法在很多方面将软件工程提升到另一个层次。象形式化方法技术一样，净室过程强调在规约和设计上的严格性，以及使用基于数学的正确性证明来对结果设计模型的每个元素进行形式化验证。作为对形式化方法中采用的方法的扩展，净室方法还强调统计质量控制技术，包括基于客户对软件的预期的使用的测试。

当现实世界中软件失败时，则充满了立即的和长期的危险。这些危险可能和人的安全、经济损失、或业务和社会基础设施的有效运作相关。净室软件工程是一个过程模型，它在可能产生严重的危险前消除错误。

净室是一种以合理的成本开发高质量软件的基于理论、面向工作组的方法。净室是基于理论的，因为坚实的理论基础是任何工程学科所不可缺少的。再好的管理也代替不了理论基础。净室是面向工作组的，因为软件是由人开发出来的，并且理论必须简化到实际应用才能引导人的创造力和协作精神。净室是针对经济实用软件的生产的，因为在现实生活中，业务和资源的限制必须在软件工程中予以满足。最后，净室是针对高质量软件的生产的，因为高质量改进管理，降低风险及成本，满足用户需求，提供竞争优势。