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

Posted 2023-03-10 文火冰糖的硅基工坊

前言：

第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） 如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，以上是关于[架构之路-131]-《软考-系统架构设计师》-软件工程-1-软件工程方法大全（软件开发过程方法软件开发过程模型逆向工程净室软件工程）的主要内容，如果未能解决你的问题，请参考以下文章

[架构之路-116]-《软考-系统架构设计师》-软架构设计-9-构件与中间件技术

[架构之路-117]-《软考-系统架构设计师》-软架构设计-10-应用程序架构与基于Web的架构设计负载均衡技术

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

[架构之路-110]-《软考-系统架构设计师》-软件架构设计-3-架构描述语言ADL与UML

[架构之路-107]-《软考-系统架构设计师》-0-系统分析师与系统架构设计师简介与官网介绍

系统架构设计师软考简介 ( 软考好处 | 职称晋升 | 工作居住证 | 积分落户 | 系统架构设计师与系统分析师备考及难度 | 软考报名考试注意事项 )