在这里插入图片描述

个人总结，仅供参考，欢迎加好友一起讨论

系分 - 软件工程

考点摘要

信息/软件系统的生命周期（★★）
软件开发方法（★★★）
软件开发模型（★★★★）
逆向工程（★）

信息系统的生命周期

在这里插入图片描述

以上的生命周期的划分偏向项目管理，而以下的划分偏向技术开发：

在这里插入图片描述

软件系统的生命周期

在这里插入图片描述

软件开发方法

在这里插入图片描述

例题1：

在这里插入图片描述

例题1解析与答案：

答案：D A B

解析：软件开发方法是指软件开发过程所遵循的办法和步骤，从不同的角度可以进行不同的分类

从开发风范上看，可分为自顶向下的开发方法和自底向上的开发方法

从性质上看，可分为形式化方法和非形式化方法

形式化方法是一种具有坚实数学基础的方法，允许对系统和开发过程做严格处理和论证

形式化方法适用于系统安全级别要求极高的软件的开发

非形式化方法则不把严格性作为其主要着眼点，通常以各种开发模型的形式得以体现

从适应范围来看，可分为整体性方法与局部性方法。

适用于软件开发全过程的方法称为整体性方法

适用于开发过程某个具体阶段的软件方法称为局部性方法。

1 逆向工程

逆向工程的特点是从已有的程序中抽取数据结构，体系结构和程序设计信息。

它的流程为：现有系统 → 逆向工程 → 考虑新需求 → 正向工程 → 新系统。

软件的逆向工程是一个恢复设计的过程，从现有的程序中抽取数据，体系结构和过程设计信息。逆向工程的完备性可以用在某一个抽象层次上提供信息的详细程度来描述，在大多数情况下，抽象层次越高，完备性就越低。

在这里插入图片描述

与逆向工程相关的概念有重构、设计恢复、再工程和正向工程：

重构（restructuring），重构是指在同一抽象级别上转换系统描述形式。
设计恢复（design recovery），设计恢复是指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息。
逆向工程（reverse engineering），逆向工程是分析程序，力图在比源代码更高抽象层次上建立程序的表示过程，逆向工程是设计的恢复过程。
正向工程（forward engineering），正向工程是指不仅从现有系统中恢复设计信息，而且使用该信息去改变或重构现有系统，以改善其整体质量。
再工程（re-engineering），再工程是对现有系统的重新开发过程，包括逆向工程、新需求的考虑过程和正向工程三个步骤。

逆向工程恢复信息的方法
方法	导出信息
用户指导下的搜索与变换方法	实现级、结构级
变换式方法	实现级、结构级、功能级
基于领域知识的方法	功能级、领域级
铅板恢复法	实现级、结构级

例题2：

在这里插入图片描述

例题2解析与答案：

答案：B C

解析：略

2 净室软件工程CSE

净室即无尘室，洁净室，也就是一个受控污染级别的环境。

使用盒结构规约（或形式化方法）进行分析和设计建模，并且强调将正确性验证而不是测试，作为发现和消除错误的主要机制。

使用统计的测试来获取认证被交付的软件的可靠性所必须的出错率信息。它是一种强调正确性的数学验证和软件可靠性的认证的软件工程模型，其目标和结果具有非常低的出错率。

软件开发模型

开发方法比开发模型要来得大一号。结构化开发方法对应V模型和瀑布模型；面向对象开发方法对应喷泉模型，统一方法模型，敏捷模型，面向服务的模型。所有面向服务的模型都是以面向对象为基础的。

1 瀑布模型

瀑布模型也称为生命周期法，是生命周期法中最常用的开发模型，它把软件开发的过程分为软件计划、需求分析、软件设计、程序编码、软件测试和运行维护6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。如图：

在这里插入图片描述

软件计划（问题的定义及规划）：主要确定软件的开发目标及其可行性。
需求分析：在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。
软件设计：主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计、数据库设计等。软件设计一般分为总体设计（概要设计）和详细设计。
程序编码：将软件设计的结果转换成计算机可运行的程序代码。在程序编写中必须制定统一、符合标准的编写规范，以保证程序的可读性，易维护性，提高程序的运行效率。
软件测试：在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。
软件维护：软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求，要延续软件的使用寿命，就必须对软件进行维护。

瀑布模型有利于大型软件开发过程中人员的组织与管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。然而软件开发的实践表明，上述各项活动之间并非完全是自上而下的，而是呈线性图示，因此，瀑布模型存在严重的缺陷：

由于开发模型呈线性，所以当开发成果尚未经过测试时，用户无法看到软件的效果。这样，软件与用户见面的时间间隔较长，也增加了一定的风险。
在软件开发前期未发现的错误传到后面的开发活动中时，可能会扩散，进而可能导致整个软件项目开发失败。
在软件需求分析阶段，完全确定用户的所有需求是比较困难的，甚至可以说是不太可能的。

2 演化模型

演化模型主要针对事先不能完整定义需求的软件开发，是在快速开发一个原型的基础上，根据用户在调用原型的过程中提出的反馈意见和建议，对原型进行改进，获得原型的新版本，重复这一过程，直到演化成最终的软件产品。

原型方法

软件原型是所提出的新产品的部分实现，建立原型的主要目的是为了解决在产品开发的早期阶段的需求不确定的问题，其目的是明确并完善需求、探索设计选择方案、发展为最终的产品。原型模型比较适合需求不够明确的项目。

原型有很多种分类方法。从原型是否实现功能来分，软件原型可分为水平原型和垂直原型两种。水平原型也称为行为原型，用来探索预期系统的一些特定行为，并达到细化需求的目的。水平原型通常只是功能的导航，但并未真实实现功能。水平原型主要用在界面上。垂直原型也称为结构化原型，实现了一部分功能。垂直原型主要用在复杂的算法实现上。

从原型的最终结果来分，软件原型可分为抛弃型原型和演化型原型。抛弃型原型也称为探索型原型，是指达到预期目的后，原型本身被抛弃。抛弃型原型主要用在解决需求不确定性、二义性、不完整性、含糊性等。演化型原型为开发增量式产品提供基础，是螺旋模型的一部分，也是面向对象软件开发过程的一部分。演化型原型主要用在必须易于升级和优化的项目，适用于Web项目。

有些文献把原型分为实验型、探索型和演化型。探索型原型的目的是要弄清对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。实验型原型用于大规模开发和实现之前，考核方案是否合适，规格说明是否可靠。进化型原型的目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。

还有些文献也把原型分为抛弃式原型、演化式原型和递增式原型。

原型法适合于用户没有肯定其需求的明确内容的时候。它是先根据已给的和分析的需求，建立一个原始模型，这是一个可以修改的模型（在生命周期法中，需求分析成文档后一般不再多修改）。

在软件开发的各个阶段都把有关信息相互反馈，直至模型的修改，使模型渐趋完善。在这个过程中，用户的参与和决策加强了，最终的结果是更适合用户的要求。

这种原型技术又可分为三类：抛弃式、演化式和递增式。这种原型法成败的关键及效率的高低在于模型的建立及建模的速度。

3 螺旋模型

螺旋模型将瀑布模型和演化模型相结合，它综合了两者的优点，并增加了风险分析。它以原型为基础，沿着螺线自内向外旋转，每旋转一圈都要经过制订计划、风险分析、实施工程、客户评价等活动，并开发原型的一个新版本。经过若干次螺旋上升的过程，得到最终的系统，如图：（需求在项目刚开始的时候往往会比较模糊，而随着项目的进行会慢慢的明确下来，也就是需求有渐进明细的特点。）

在这里插入图片描述

例题3：

在这里插入图片描述

例题3解析与答案：

答案：A

解析：略

4 喷泉模型

喷泉模型对软件复用和生命周期中多项开发活动的集成提供了支持，主要支持面向对象的开发方法。"喷泉"一词本身体现了迭代和无间隙特性。系统某个部分常常重复工作多次，相关功能在每次迭代中随之加入演进的系统。所谓无间隙是指在开发活动中，分析、设计和编码之间不存在明显的边界，如图：

在这里插入图片描述

5 V模型

在开发模型中，测试常常作为亡羊补牢的事后行为，但也有以测试为中心的开发模型，那就是V模型。V模型只得到软件业内比较模糊的认可。V模型宣称测试并不是一个事后弥补行为，而是一个同开发过程同样重要的过程，如图：

在这里插入图片描述

V模型是最具有代表意义的测试模型，它是瀑布模型的变种，它在瀑布模型的基础上加强了测试，反映了测试活动与分析和设计的关系。V模型中，左边下降的是开发过程阶段，右边上升部分是测试过程的各个阶段。V模型的软件测试策略既包括低层测试又包括了高层测试，低层测试是为了源代码的正确性，高层测试是为了使整个系统满足用户的需求。V模型存在一定的局限性，它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。让测试工作贯穿于始终。

V模型强调软件幵发的协作和速度，将软件实现和验证有机地结合起来，在保证较高的软件质M情况下缩短开发周期。V模型适合企业级的软件幵发，它更淸楚地揭示了软件开发过程的特性及其本质。

V模型的价值在于它非常明确地表明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系：

单元测试的主要目的是针对编码过程中可能存在的各种错误。例如：用户输入验证过程中的边界值的错误。
集成测试的主要目的是针对详细设计中可能存在的问题，尤其是检查各单元与其他程序部分之间的接口上可能存在的错误。
系统测试主要针对概要设计，检查系统作为一个整体是否有效地得到运行。例如：在产品设置中是否达到了预期的高性能。
验收测试通常由业务专家或用户进行，以确认产品能真正符合用户业务上的需要。

6 增量模型

增量模型融合了瀑布模型的基本成分（重复的应用）和原型实现的迭代特征。增量模型采用随着时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的"增量“。当使用增量模型时，第一个增量往往是核心的产品，也就是说第一个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估，都作为下一个增量发布的新特征和功能。这个过程在每一个增量发布后不断重复，直到产生最终的完善产品。

增量模型强调每一个增量均发布一个可操作的产品。如图：

在这里插入图片描述

增量模型像原型实现模型和其他演化方法一样，本质上是迭代的。但与原型实现不同的是增量模型强调每一个增量均发布一个可操作产品。早期的增量是最终产品的"可拆卸"版本，但它们确实提供了为用户服务的功能，并且提供了给用户评估的平台。增量模型的特点是引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求，还需要更改，但只要这个增量包足够小，其影响对整个项目来说是可以承受的。

采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源，如果核心产品很受欢迎，则可以增加人力实现下一个增量；当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径，这样就可以先发布部分功能给客户，对客户起到镇静剂的作用。此外，增量能够有计划地管理技术风险。增量模型的缺点是如果增量包之间存在相交的情况且不能很好地处理，就必须做全盘的系统分析，不能很好的进行模块划分。增量模型将功能细化、分别开发的方法适用于需求经常改变的软件开发过程。

7 **迭代与增量的概念

在这里插入图片描述

8 基于构件的模型（构件组装模型/基于构件的软件开发）

构件（Component，组件）是一个具有可重用价值的、功能相对独立的软件单元。基于构件的软件开发（ComponentBased Software Development，CBSD）模型是利用模块化方法，将整个系统模块化，并在一定构件模型的支持下，复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程。

基于构件的开发模型融合了螺旋模型的许多特征，本质上是演化型的，开发过程是迭代的。基于构件的开发模型由软件的需求分析和定义、体系结构设计、构件库建立（其中构件库包括了构件获取和构件管理）、应用软件构建、测试和发布5个阶段组成。如图：

在这里插入图片描述

构件作为重要的软件技术和工具得到了极大的发展，这些新技术标准和工具有Microsoft的DCOM/COM，Sun的EJB，OMG的CORBA等。基于构件的开发活动从标识候选构件开始，通过搜索已有构件库，确认所需要的构件是否已经存在，如果已经存在，就从构件库中提取出来复用；如果不存在，就采用面向对象方法开发它。在提取出来的构件通过语法和语义检查后，将这些构件通过胶合代码组装到一起实现系统，这个过程是迭代的。

基于构件的开发方法使得软件开发不再一切从头开始，开发的过程就是构件组装的过程，维护的过程就是构件升级、替换和扩充的过程，其优点是构件组装模型导致了软件的复用，提高了软件开发的效率；构件可由一方定义其规格说明，被另一方实现，然后供给第三方使用；构件组装模型允许多个项目同时开发，降低了费用，提高了可维护性，可实现分步提交软件产品。缺点是由于采用自定义的组装结构标准，缺乏通用的组装结构标准，引入具有较大的风险；可重用性和软件高效性不易协调，需要精干的、有经验的分析人员和开发人员，一般的开发人员插不上手，客户的满意度低；过分依赖于构件，构件库的质量影响着产品质量。

9 RAD模型（快速应用开发模型）

快速应用开发（Rapid Application Development，RAD）模型是一个增量型的软件开发过程模型，强调极短的开发周期。RAD模型是瀑布模型的一个“高速”变种，通过大量使用可复用构件，采用基于构件的建造方法赢得快速开发。如果需求理解得好且约束了项目的范围，利用这种模型可以很快地创建出功能完善的“信息系统“。其流程从业务建模开始，随后是数据建模、过程建模、应用生成、测试及反复。瀑布模型和CBSD（Component-Based Software Development基于构建的软件开发模型）的综合开发模型，如图：

在这里插入图片描述

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

业务建模：以什么信息驱动业务过程运作？要生成什么信息？谁生成它？信息流的去向是哪里？由谁处理？可以辅之以数据流图。
数据建模：为支持业务过程的数据流，找数据对象集合，定义数据对象属性，与其他数据对象的关系构成数据模型，可辅之以E-R图。
过程建模：使数据对象在信息流中完成各业务功能。创建过程以描述数据对象的增加、修改、删除、查找，即细化数据流图中的处理框。
应用程序生成：利用第四代语言（4GL）写出处理程序，重用已有构件或创建新的可重用构件，利用环境提供的工具自动生成并构造出整个应用系统。
测试与交付，由于大量重用，一般只做总体测试，但新创建的构件还是要测试的。

与瀑布模型相比，RAD模型不采用传统的第三代程序设计语言来创建软件，而是采用基于构件的开发方法，复用已有的程序结构（如果可能的话）或使用可复用构件，或创建可复用的构件（如果需要的话）。在所有情况下，均使用自动化工具辅助软件创造。很显然，加在一个RAD模型项目上的时间约束需要“一个可伸缩的范围”。如果一个业务能够被模块化使得其中每一个主要功能均可以在不到三个月的时间内完成，那么它就是RAD的一个候选者。每一个主要功能可由一个单独的RAD组来实现，最后再集成起来形成一个整体。

RAD模型通过大量使用可复用构件加快了开发速度，对信息系统的开发特别有效。但是像所有其他软件过程模型一样，RAD方法也有其缺陷：

并非所有应用都适合RAD。RAD模型对模块化要求比较高，如果有哪一项功能不能被模块化，那么建造RAD所需要的构件就会有问题；如果高性能是一个指标，且该指标必须通过调整接口使其适应系统构件才能赢得，RAD方法也有可能不能奏效。
开发者和客户必须在很短的时间完成一系列的需求分析，任何一方配合不当都会导致RAD项目失败。
RAD只能用于信息系统开发，不适合技术风险很高的情况。当一个新应用要采用很多新技术或当新软件要求与已有的计算机程序有较高的互操作性时，这种情况就会发生。