NO.5软件工程 - 技术栈

一、软件工程

1、软件工程概论

软件工程是将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件并对上述方法的研究。软件要经历从需求分析、软件设计、软件开发、运行维护，直至被淘汰这样的全过程，这个过程称为软件的生命周期。软件工程4个支持活动：

（1）P（Plan）------软件规格说明。规定软件的功能及其运行时的限制。

（2）D（Do）------软件开发。开发出满足规格说明的软件。

（3）C（Check）------软件确认。确认开发的软件能够满足用户的需求。

（4）A（Action）------软件演进。软件在运行过程中不断改进以满足客户新的需求。

2、软件逆向工程

逆向工程源于硬件术语，类似于"山寨"的概念。

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

逆向工程的完备性分级

实现级：包括程序的抽象语法树、符号表、过程的设计表示。
结构级：包括反映程序分量之间相互依赖关系的信息（调用图、结构图、程序和数据结构）。
功能级：包括反映程序段功能及程序段之间关系的信息（数据和控制流模型）。
领域级：包括程序分量或程序实体与应用领域概念之间对应关系的信息（实体关系模型）。

二、开发模型

为了使软件生命周期中的各项任务能够有序地按照规程进行，需要一定的工作模型对各项任务给予规程约束，这样的工作模型称之为软件生命周期模型。主要的开发模型有：

瀑布模型、原型化模型、螺旋模型、喷泉模型、智能模型、增量模型、迭代模型、构件组装模型、V模型、快速应用开发模型、敏捷方法、统一过程(UP)

1、瀑布模型

瀑布模型也称为生命周期法，是结构化方法中最常用的开发模型，它把软件开发的过程分为软件计划、需求分析、软件设计、程序编码、软件测试和运行维护6个阶段。

1、瀑布模型的优点：

(1) 为项目提供了按阶段划分的检查点。

(2) 当前一阶段完成后，只需要去关注后续阶段。

(3) 它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

2、瀑布模型的缺点：

(1) 各个阶段之间产生大量的文档，极大地增加了工作量。

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

(3) 不适应用户需求的变化，并且在需求分析阶段不可能完全获取。

(4) 在软件开发前期未发现的错误传到后面的开发活动中时，可能会扩散，进而可能会导致整个软件项目开发失败。

3、适用于需求明确或很少变更的项目。

2、原型化模型

在获取一组基本的需求定义后，利用高级软件工具可视化的开发环境，快速地建立一个目标系统的最初版本 ，并把它交给用户试用、补充和修改，再进行新的版本开发。反复进行这个过程，直到得出系统的"精确解"，即用户满意为止。

1、原型的分类

从原型是否实现功能来分，软件原型可分为：

· 水平原型

· 垂直原型

从原型的最终结果来分，软件原型可分为：

· 抛弃型原型

· 演化型原型

2、原型法适合于用户需求不明确的场合。

3、原型法成败的关键及效率的高低，在于模型的建立及建模的速度。

4、原型模型主要有以下两个阶段。

（1）原型开发阶段。开发原型可以考虑以下3种途径：

①利用模拟软件系统的人机界面和人机交互方式。

②真正开发一个原型。

③找来一个或几个正在运行的类似软件进行比较。

（2）目标软件开发阶段。

3、螺旋模型

螺旋模型是在快速原型的基础上扩展而成。将瀑布模型和演化模型相结合，强调风险分析。

(1) 目标设定。为该项目进行需求分析，定义和确定这一个阶段的专门目标，指定对过程和产品的约束，并且制订详细的管理计划。

(2) 风险分析。对可选方案进行风险识别和详细分析，制定解决办法，采取有效措施避免这些风险。

(3) 开发和有效性验证。风险评估后，可以为系统选择开发模型，并且进行原型开发，即开发软件产品。

(4) 评审。对项目进行评审，以确定是否需要进入螺旋线的下一次回路，如果决定继续，就要制订下一阶段计划。

该模型支持大型软件开发，适用于面向规格说明、面向过程和面向对象的软件开发方法，也适用于几种开发方法的组合。

4、敏捷模型

敏捷型方法主要有两个特点，这也是其区别于其他方法，尤其是计划驱动 或重型开发方法的最主要的特征。

1、敏捷型方法是"适应性 "（adaptive）而非"预设性"（predictive）的。

2、敏捷型方法是"面向人的 "（People-oriented）而非"面向过程的"（Process-oriented）。

①敏捷开发过程还要求开发人员必须有权做技术方面的所有决定。

②敏捷方法特别强调开发中相关人员之间的信息交流。

③敏捷方法还特别提倡直接的面对面交流。

3、敏捷方法特点：

① 敏捷方法是适应型，而非可预测型。

② 敏捷方法是以人为本，而非以过程为本。

③ 迭代增量式的开发过程。

4、敏捷模型相关思想和方法

✔ 极限编程（XP） ：价值观是（交流、朴素、反馈和勇气 ）、近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈。

✔ 水晶方法 ：提倡"机动性的"方法，包含具有共性的核心元素，每个都含有独特的角色、过程模式、工作产品和实践。对不同类型项目非常有效的敏捷过程，它的发明使得敏捷团队可以根据其项目和环境选择最合适的Crystal家族成员。

✔ SCRUM ：侧重于项目管理，是迭代式增量 软件开发过程。

✔ 特征驱动开发方法（Feature Driven Development，FDD） ：FDD是一个迭代的开发模型。FDD认为有效的软件开发需要3个要素：人、过程和技术。FDD定义了6种关键的项目角色：项目经理、首席架构设计师、开发经理、主程序员、程序员 和领域专家。FDD有5个核心过程：开发整体对象模型，构造特征列表、计划特征开发、特征设计和特征构建。其中，计划特征开发根据构造出的特征列表、特征间的依赖关系进行计划，设计出包含特征设计和特征构建过程组成的多次迭代。

其他：

开放源码：程序员地域上分布广泛。
ASD方法：其核心是三个非线性的、重叠的开放阶段：猜测、合作和学习。
动态系统开放方法DSDM：倡导以业务为核心。

最佳实践（尽可能多记住）：

5、构件组装模型

基于构件的软件开发(CBSD)模型是利用模块化方法，将整个系统模块化，并在一定构件模型的支持下，复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程。

CBSD模型融合了螺旋模型的许多特征，本质上是演化型的，开发过程是迭代的。

基于构件的软件开发方法由5个阶段组成：

①需求分析和定义

②体系结构设计

③构件库的建立

④应用软件构建

⑤测试和发布

6、V模型

V模型强调：测试分段 、测试计划先行

7、快速应用开发模型

快速应用开发（RAD）模型是一个增量型 的软件开发过程模型，当模块化要求程度较高时候 ，通过大量使用可复用构件 ，采用基于构件的建造方法赢得快速开发强调极短的开发周期。

快速应用开发模型的流程：

①业务建模

②数据建模

③过程建模

④应用生成

⑤测试与交付

8、能力成熟度模型CMMI

级别	要点
初始级	无秩序的、混乱的，软件产品所取得的成功往往依赖于极个人的努力和机遇。
已管理级	建立了基本的项目管理过程，类似项目可取得成功。
已定义级	软件过程均已文档化、标准化，并形成整个软件组织的标准软件过程。
量化管理级	有详细的度量标准。
优化级	不断地、持续地进行过程改进。

三、需求工程

1、需求内容

按需求内容可分为业务需求、用户需求、系统需求三类。

（1）业务需求：由客户提出的一个宏观的功能需求。（整体性和全局性）

（2）用户需求：设计员去调查需求中涉及的每个用户的具体需求。

（3）系统需求：经过整合，形成最终的系统需求，包括功能、性能、设计约束等。

①功能需求：软件必须完成的基本动作。

②性能需求：说明软件或人与软件交互的静态或动态数值需求，如系统响应速度、处理速度等。

③设计约束：受其他标准硬件限制等方面的影响。

例题：

2、客户需求分类

从客户角度可分为基本需求、期望需求、兴奋需求三类。

基本需求：需求明确规定的功能。
期望需求：除了基本需求外，客户认为理所应当包含在内的其他功能。
兴奋需求 ：客户未要求的其他功能需求，会浪费项目开发时间和成本。

3、需求开发和管理

（1）需求获取

需求获取的步骤：

①开发高层的业务模型

②定义项目范围和高层需求。常见的建模手段包括系统上下文图和系统顶层用例图等。

③识别用户角色和用户代表

④获取具体的需求

⑤确定目标系统的业务工作流

⑥需求整理与总结

需求获取方法包括：

（2）需求变更管理过程

变更控制过程用来跟踪已建议变更的状态，使已建议的变更确保不会丢失或疏忽。一旦确定了需求基线，应该使所有已建议的变更都遵循变更控制过程。

1.需求变更过程

2.常见的需求变更策略：

①所有需求变更必须遵循变更控制过程。

②对于未获得批准的变更，不应该做设计和实现工作。

③变更应该由项目变更控制委员会决定实现哪些变更。

④项目风险承担者应该能够了解变更的内容。

⑤绝不能从项目配置库中删除或者修改变更请求的原始文档。

⑥每一个集成的需求变更必须能跟踪到一个经核准的变更请求，以保持水平可追踪性。

（3）需求跟踪矩阵

需求跟踪提供了由需求到产品实现整个过程范围的明确查阅的能力。需求跟踪的目的是建立与维护"需求-设计-编程-测试"之间的一致性，确保所有的工作成果符合用户需求。

需求跟踪有两种方式：

①正向跟踪 。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。

②逆向跟踪 。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。

四、系统分析

1、结构化分析

（1）数据流图DFD

例如：

其中包括：

（2）实体联系图ER

例如：

（3）状态转换图STD

例如：

（4）界面设计的三大原则

①置于用户控制之下。

②减少用户的记忆负担。

③保持界面的一致性。

（5）结构化设计SD

是一种面向数据流的设计方法，它以SRS和SA阶段产生的数据流图和数据字典等文档为基础，是一个自顶向下、逐步求精和模块化的过程。

概要设计和详细设计两个阶段：

概要设计 的主要任务是确定软件系统的结构，对系统进行模块划分，确定每个模块的功能、接口和模块之间的调用关系；
详细设计 的主要任务是为每个模块设计实现的细节。

在SD中，这种功能分解就是将系统划分为模块，模块是组成系统的基本单位，它的特点是可以自由组合、分解和变换，系统中任何一个处理功能都可以看成一个模块。

①信息隐藏与抽象。信息隐藏原则要求采用封装技术，将程序模块的实现细节（过程或数据）隐藏起来，对于不需要这些信息的其他模块来说是不能访问的，使模块接口尽量简单。

②模块化：模块是实现功能的基本单位，它一般具有功能、逻辑和状态3个基本属性，功能是指该模块"做什么"，逻辑是描述模块内部"怎么做"，状态是该模块使用时的环境和条件。

③设计原则：高内聚、低耦合。内聚表示模块内部各代码成分之间联系的紧密程度。耦合表示模块之间联系的程度。

1.内聚：表示模块内部各代码成分之间联系的紧密程度。一个好的内聚模块应当恰好做目标单一的一件事情。(口诀：公顺通过时罗偶)

内聚类型	描述
功能内聚	完成一个单一功能，各个部分协同工作，缺一不可
顺序内聚	处理元素相关，而且必须顺序执行
通信内聚	所有处理元素集中在一个数据结构的区域上
过程内聚	处理元素相关，而且必须按特定的次序执行
时间内聚	所包含的任务必须在同一时间间隔内执行
逻辑内聚	完成逻辑上相关的一组任务
偶然内聚	完成一组没有关系或松散关系的任务

2.耦合：模块直接的联系程度。（口诀：非数标控通公内）

耦合类型	描述
非直接耦合	两个模块之间没有直接关系，它们之间的联系完全是通过上级模块的控制和调用来实现的
数据耦合	一组模块借助参数表传递简单数据
标记耦合	一组模块通过参数表传递记录等复杂信息（数据结构）
控制耦合	模块之间传递的信息中包含用于控制模块内部逻辑的信息
通信耦合	一组模块共用了一组输入信息，或者它们的输出需要整合以形成完整数据，即共享了输入或输出
公共耦合	多个模块都访问同一个公共数据环境，公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等
内容耦合	一个模块直接访问另一个模块的内部数据；一个模块不通过正常入口转到另一个模块的内部；两个模块有一部分程序代码重叠；一个模块有多个入口等

（6）结构化编程

结构化程序设计采用自顶向下、逐步求精的设计方法，各个模块通过"顺序、选择、循环" 的控制结构进行连接，并且只有一个入口和一个出口。

结构化程序设计的原则可表示为：程序=（算法）+（数据结构）。

算法是一个独立的整体，数据结构（包含数据类型与数据）也是一个独立的整体。两者分开设计，以算法（函数或过程）为主。

结构化程序设计提出的原则可以归纳为32个字：自顶向下，逐步细化；清晰第一，效率第二；书写规范，缩进格式；基本结构，组合而成。

（7）数据库设计

数据库设计的内容包括：需求分析、概念结构设计、逻辑结构设计、物理设计、数据库的实施和数据库的运行和维护。

概念结构设计阶段--E-R图。E-R图提供了表示实体类型、属性和联系的方法，用来描述现实世界的概念模型。

（1）实体。一般认为，客观上可以相互区分的事物就是实体，实体可以是具体的人和物，也可以是抽象的概念与联系。

（2）属性。实体所具有的某一特性，一个实体可由若干个属性来刻画。

（3）联系。联系也称关系，信息世界中反映实体内部或实体之间的关联。

2、面向对象分析与UML

（1）开发方法

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

面向对象开发方法是以用例驱动的、以体系结构为中心的、迭代的和渐增式的开发过程。主要包括需求分析、系统分析、系统设计和系统实现4个阶段。

（2）面向对象分析OOA

OOA模型由5个层次(主题层、对象类层、结构层、属性层和服务层)和5个活动(标识对象类、标识结构、定义主题、定义属性和定义服务)组成。OOA定义了两种对象类之间的结构：

✔ 分类结构：就是一般与特殊的关系。

✔ 组装结构：反映了对象之间的整体与部分的关系。

OOA原则:

①抽象：从许多事物中舍弃个别的、非本质的特征，抽取共同的、本质性的特征叫作抽象。抽象原则包括过程抽象和数据抽象两方面。

过程抽象是指任何一个完成确定功能的操作序列，其使用者都可以把它看作一个单一的实体，尽管实际上它可能是由一系列更低级的操作完成的。

数据抽象是根据施加于数据之上的操作来定义数据类型，并限定数据的值只能由这些操作来修改和观察。数据抽象是OOA的核心原则。它强调把数据（属性）和操作（服务）结合为一个不可分的系统单位（即对象），对象的外部只需要知道它做什么，而不必知道它如何做。

②封装：把对象的属性和操作结合为一个不可分的系统单位，并尽可能隐蔽对象的内部细节。

③继承：特殊类的对象拥有的其一般类的全部属性与操作，称特殊类对一般类的继承。继承的好处：使系统模型比较简练、清晰。

④多态 (polymorphism)。在OO技术中，多态性是指同一个操作作用于不同的对象时可以有不同的解释，并产生不同的执行结果。

⑤分类：就是把具有相同属性和操作的对象划分为一类，用类作为这些对象的抽象描述。分类原则实际上是抽象原则运用于对象描述时的一种表现形式。

⑥聚合：又称组装，其原则是把一个复杂的事物看成若干比较简单的事物的组装体，从而简化对复杂事物的描述。

⑦关联：是人类思考问题时经常运用的思想方法，通过一个事物联想到另外的事物。能使人发生联想的原因是事物之间确实存在着某些联系。

⑧消息通信：指对象之间只能通过消息进行通信，而不允许在对象之外直接地存取对象内部的属性。通过消息进行通信是由于封装原则而引起的。在OOA中要求用消息连接表示出对象之间的动态联系。

⑨粒度控制：人在面对一个复杂的问题域时，不可能在同一时刻既能纵观全局，又能洞察秋毫。因此需要控制自己的视野：考虑全局时，注意其大的组成部分，暂时不详察每一部分的细节；考虑某部分的细节时则暂时撇开其余的部分。这就是粒度控制原则。

⑩行为分析：现实世界中事物的行为是复杂的。由大量的事物所构成的问题域中各种行为往往相互依赖、相互交织。

（3）基本步骤

OOA大致上遵循如下5个基本步骤：

①确定对象和类

②确定结构

③确定主题

④确定属性

⑤确定方法。

（4）对象用例与UML图关联

（1）参与者 。外部触发因素。参与者是指存在于系统外部并与系统进行交互的任何事物，既可以是使用系统的用户，也可以是其他外部系统和设备等外部实体。其他系统、硬件设备，例如：在开发集成电路卡门禁系统时，IC卡读写器就是一个参与者。时钟（时间或温度）

（2）用例。用例是在系统中执行的一系列动作，功能单元。

（3）通信关联。通信关联表示的是参与者和用例之间的关系，或用例与用例之间的关系。

（5）用例和用例的关系

①包含：当两个或多个用例中共用一组相同的动作，这时可以将这组相同的动作抽出来作为一个独立的子用例，供多个基用例所共享。因为子用例被抽出，基用例并非一个完整的用例，所以include关系中的基用例必须和子用例一起使用才够完整，子用例也必然被执行。include关系在用例图中使用带箭头的虚线表示(在线上标注<>)，箭头从基用例指向子用例。

②扩展：是对基用例的扩展，基用例是一个完整的用例，即使没有子用例的参与，也可以完成一个完整的功能。extend关系在用例图中使用带箭头的虚线表示(在线上标注<>)，箭头从子用例指向基用例。

③泛化：也就是继承关系的反关系，特殊/一般的关系。子类继承自父类，父类是子类的泛化。

（6）类之间的关系

五、软件测试

1、软件测试概述

软件测试是系统化验证软件质量的过程，通过人工或自动化手段运行程序，发现错误、验证需求满足度，并评估功能完整性、性能、安全性等非功能性指标。

2、测试方法

软件测试方法分类有很多种，其中：

以测试过程中程序执行状态为依据的可分为：静态测试、动态测试；
以具体实现算法细节和系统内部结构的相关情况可分为：黑盒测试、白盒测试和灰盒测试；
程序执行的方式可分为：人工测试、自动化测试。

（1）静态测试 ：被测试程序不运行，只依靠分析或检查源程序的语句、结构、过程说明书等来检查程序是否有错误。

（2）动态测试 ：通过运行被测试程序，对得到运行结果与预期的结果进行比较分析，同时分析运行效率和健壮性能等。

（3）黑盒测试 ：不关注内部结构，仅通过输入、输出验证功能，方法包括等价类划分、边界值分析、因果图、场景法等，适用于功能测试、验收测试。

（4）白盒测试 ：基于代码逻辑，采用语句覆盖、路径覆盖、逻辑覆盖等方法，常用于单元测试、集成测试。

（5）灰盒测试 ：结合黑盒与白盒特点，关注接口与部分内部逻辑，适用于集成测试、性能测试。

（6）自动化测试 ：在预先设定的条件下自动运行被测程序，如利用Selenium（Web）、Appium（移动）、JMeter（性能）等工具，实现测试用例的快速执行与结果分析，提升效率。

3、测试阶段

（1）单元测试 ：针对软件最小可测试单元（如函数、方法、类）的独立测试，经常采用路径覆盖，组合覆盖，属于白盒测试范畴。

（2）集成测试 ：将已通过单元测试的模块按设计要求组合成子系统或系统，验证模块间接口匹配与协作。一般采用黑盒+白盒测试。

模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其他模块。这些辅助模块分为两种：

(1)驱动模块：相当于被测模块的主程序。它接收测试数据，把这些数据传送给被测模块，最后输出实测结果。

(2)桩模块：用于代替被测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。

√ 自顶向下进行组装，不需要驱动模块。

√ 自底向上进行组装，不需要桩模块。

在每个版本提交时，都需要进行"冒烟"测试，即对程序主要功能进行验证。冒烟测试也称为版本验证测试或提交测试。

（3）确认测试

确认测试也称为有效性测试，主要包括验证软件的功能、性能及其他特性是否与用户要求（需求）一致。确认测试计划是在需求分析阶段完成的。根据用户的参与程度，包括以下4种类型：

①内部确认测试：由软件开发组织内部按软件需求说明书进行测试。

②Alpha测试 ：由用户在开发环境下进行测试。

③Beta测试 ：由用户在实际使用环境下进行测试。

④验收测试 ：针对软件需求说明书，在交付前以用户为主进行测试。

（4）系统测试：对整个软件系统在真实或模拟环境下进行端到端验证，涵盖功能与非功能需求。一般是黑盒多轮测试

（5）性能测试 ：包括负载测试，压力测试（测上限），强度测试（测下限），容量测试，可测试系统负载正常值、峰值。

（6）其他测试：兼容测试、SQL注入测试、链接测试、表单测试等。

六、净室软件工程CSE

净室软件工程CSE是一种应用数学与统计学理论以经济的方式生产高质量软件的工程技术，力图通过严格的工程化的软件过程达到开发中的零缺陷或接近零缺陷。净室方法不是先制作一个产品，再去消除缺陷，而是要求在规约和设计中消除错误，以"净"的方式制作，可以降低软件开发中的风险，以合理的成本开发出高质量的软件。净室软件工程使用盒结构规约进行分析和设计建模，并且强调将正确性验证 （而不是测试）作为发现和消除错误的主要机制，使用统计的测试来获取交付软件时所必需的可靠性（出错率）信息。

1、理论基础

净室软件工程的理论基础是函数理论和抽样理论。

函数理论

一个函数定义了从定义域到值域的映射。一个特定的程序好似定义了一个从定义域（所有可能的输入序列的集合）到值域（所有对应于输入的输出集合）的映射。这样，一个程序的规范就是一个函数的规范。一个明确定义的函数应当具有以下特性：

✔ 完备性：对定义域中的每个元素，值域中至少有一个元素与之对应。对程序而言，每种可能的输入都必须定义，并有一个输出与之对应。

✔ 一致性：在值域中最多有一个元素与定义域中的同一元素对应。对程序而言，每个输入只能对应一个输出。

✔ 正确性：函数的正确性可以由上述性质判断。对程序而言，某项设计的正确性可以通过基于函数理论的推理来验证。
抽样理论

不可能对软件的所有可能应用都进行测试。把软件所有可能的使用情况看作总体，通过统计学手段对其进行抽样，并对样本进行测试，根据测试结果分析软件的性能和可靠性。

2、技术手段

统计过程控制下的增量式开发

增量开发不是把整个开发过程作为一个整体，而是将其划分为一系列较小的累积增量。小组成员在任何时刻只须把注意力集中于工作的一部分，而无须一次考虑所有的事情。

基于函数的规范与设计

盒子结构方法按照函数理论定义了三种抽象层次：行为视图（黑盒）、有限状态机视图（状态盒）、过程视图（清晰盒或明盒）。

(1) 黑盒。刻划系统或系统的某部分的行为。通过运用由激发得到反应的一组变迁规则，系统对特定的激发（事件）作出反应。

(2) 状态盒。以类似于对象的方式封装状态数据和服务（操作）。在这个规约视图中，表示出状态盒的输入（激发）和输出（反应）。

(3) 清晰盒。在清晰盒中定义状态盒所蕴含的变迁功能，简单地说，清晰盒包含了对状态盒的过程设计。

正确性验证

正确性验证是净室软件工程的核心，正是由于采用了这一技术，净室项目的软件质量才有了极大的提高。

统计测试和软件认证

净室测试方法采用统计学的基本原理，即当总体太大时必须采取抽样的方法。首先确定一使用模型来代表系统所有可能使用的（一般是无限的）总体。然后由使用模型产生测试用例。因为测试用例是总体的一个随机样本，所以可得到系统预期操作性能的有效统计推导。

3、净室软件工程的缺点

①CSE太理论化，需要更多的数学知识。其正确性验证的步骤比较困难且耗时多。CSE要求采用增量式开发、盒子结构、统计测试方法，普通工程师必须经过加强训练才能掌握，开发软件的成本比较高昂。

②CSE不进行传统的模块测试，这是不现实的。工程师可能对编程语言和开发环境还不熟悉，而且编译器或操作系统的Bug也可能导致未预期的错误。

③CSE毕竟脱胎于传统软件工程，不可避免地带有传统软件工程的一些弊端。

七、基于构件的软件工程CBSE

基于构件的软件工程（CBSE）是一种基于分布对象技术、强调通过可复用构件设计与构造软件系统的软件复用途径。基于构件的软件系统中构件可以是COTS（商用现货）构件，也可以是自行开发构件。CBSE体现了"购买而不是重新构造"的哲学，将软件开发的重点从程序编写转移到了基于已有构件的组装，以便更快地构造系统，减轻系统的维护负担，降低软件开发的费用。

1、构件和构件模型

构件是一个独立的软件单元，可以与其他构件构成一个软件系统。构件的特征：

(1)可组装：对于可组装的构件，所有外部交互都必须通过公开定义的接口进行。

(2)可部署：软件必须是自包含的，必须能作为一个独立实体在提供其构件模型实现的构件平台上运行。构件总是二进制形式，无须在部署前编译。

(3)文档化：构件必须是完全文档化的，用户根据文档来判断构件是否满足需求。

(4)独立性：构件应该是独立的，可以在无其他特殊构件的情况下进行组装和部署，如确实需要其他构件提供服务，则应显示声明。

(5)标准化：构件标准化意味着在基于构件的软件开发过程中使用的构件必须符合某种标准化的构件模型。

目前主流的构件模型有Web Services模型、Sun公司的EJB模型、微软的.NET模型。

2、CBSE过程

(1) 系统需求概览

(2) 识别候选构件

(3) 根据发现的构件修改需求

(4) 体系结构设计

(5) 构件定制与适配

(6) 组装构件创建系统

3、构件组装

构件组装是指构件相互之间集成或是用专门编写的"胶水代码"将它们整合在一起来创造一个系统或另一个构件的过程。

常见的构件组装有3种方式：

（1）顺序组装

通过按顺序调用已经存在的构件，可以用两个已经存在的构件来创造一个新的构件。顺序组装适用于作为程序元素的构件或是作为服务的构件。需要特定的胶水代码，来保证两个构件的组装：上一个构件的输出与下一个构件的输入相兼容。

（2）层次组装

这种情况发生在一个构件直接调用由另一个构件所提供的服务时。被调用的构件为调用的构件提供所需的服务。因此，被调用构件的"提供"接口必须和调用构件的"请求"接口兼容。如果接口相匹配，则调用构件可以直接调用被调用构件，否则就需要编写专门的胶水代码来实现转换。

（3）叠加组装

这种情况发生在两个或两个以上构件放在一起创建一个新构件的时候。这个新构件合并了原构件的功能，从而对外提供了新的接口。外部应用可以通过新接口来调用原有构件的接口。原有构件不互相依赖，也不互相调用。

八、软件项目管理

1、项目管理概述

软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对人员（People）、产品（Product）、过程（Process）和项目（Project）进行分析和管理的活动。

2、进度管理（时间管理）

（1）工作分解结构

工作分解结构（WBS）就是把一个项目，按一定的原则分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人的日常活动中。即项目→任务→工作→日常活动。

进度管理指的是为了确保项目按期完成所需要的管理过程。进度管理的主要活动过程：

①活动定义

②活动排序

③活动资源估算

④活动历时估算

⑤制定进度计划

⑥进度控制

（2）工作分解的基本要求（原则）

①WBS的工作包是可控和可管理的，不能过于复杂。

②任务分解也不能过细，一般原则WBS的树形结构不超过6层。

③每个工作包要有一个交付成果。

④每个任务必须有明确定义的完成标准。

⑤WBS必须有利于责任分配。

（3）任务活动图

活动定义是指确定完成项目的各个交付成果所必须进行的各项具体活动，明确每个活动的前驱、持续时间、必须完成日期、里程碑或交付成果。任务活动图的表示方法：

前导图法（单代号网络图法）
箭线图法（双代号网络图法）

3、软件配置管理

软件配置管理（Software Configuration Management，SCM）是一种标识、组织和控制修改的技术。软件配置管理应用于整个软件工程过程。在软件建立时变更是不可避免的，而变更加剧了项目中软件开发者之间的混乱。SCM活动的目标就是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更。从某种角度讲，SCM是一种标识、组织和控制修改的技术，目的是使错误降为最小并最有效地提高生产效率。

软件配置管理核心内容包括版本控制和变更控制。

①版本控制（Version Control）。

②变更控制（Change Control）。变更控制的目的并不是控制变更的发生，而是对变更进行管理，确保变更有序进行。

项目中引起变更的因素有两个：一是来自外部的变更要求，如客户要求修改工作范围和需求等；二是开发过程内部的变更要求，如为解决测试中发现的一些错误而修改源码甚至设计。比较而言：最难处理的是来自外部的需求变更，因为IT项目需求变更的概率大，引发的工作量也大（特别是到项目的后期）。

所有配置项的操作权限应由CMO严格管理，基本原则是：

基线配置项（如：代码）向开发人员开放读取的权限；
非基线配置项（如：项目进度文档）向PM、CCB及相关人员开放。

配置项的状态可分为"草稿""正式"和"修改"三种。配置项刚建立时，其状态为"草稿"；配置项通过评审后，其状态变为"正式"；此后若更改配置项，则其状态变为"修改"。当配置项修改完毕并重新通过评审时，其状态又变为"正式"，如下图（图未给出）所示：

①处于"草稿"状态的配置项的版本号格式为0.YZ，YZ的数字范围为01～99。随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。

②处于"正式"状态的配置项的版本号格式为X.Y，X为主版本号，取值范围为1～9。Y为次版本号，取值范围为0～9。配置项第一次成为"正式"文件时，版本号为1.0。

③处于"修改"状态的配置项的版本号格式为X.YZ。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态成为"正式"时，将Z值设置为0，增加X.Y值。参见上述规则2)。

配置库可以分为动态库（开发库、程序员库、工作库）、受控库（主库）、静态库（软件仓库）。

①动态库。也称为开发库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体。可以随意修改。

②受控库。也称为主库或系统库，是用于管理当前基线和控制对基线的变更。受控库包括配置单元和被提升并集成到配置项中的组件。软件工程师和其他人员可以自由地复制受控库中的单元或组件。然而，必须有适当的权限授权变更。受控库中的单元或组件用于创建集成、系统和验收测试或对用户发布的构建。

③静态库。也称为软件仓库或软件产品库，用于存档各种广泛使用的已发布的基线。不能修改。

配置管理的工具：

4、软件质量管理

（1）软件质量保证的关注点集中在于一开始就避免缺陷的产生。质量保证的主要目标是：

① 事前预防工作，例如，着重于缺陷预防而不是缺陷检查。

② 尽量在刚刚引入缺陷时即将其捕获，而不是让缺陷扩散到下一个阶段。

③ 作用于过程而不是最终产品，因此它有可能会带来广泛的影响与巨大的收益。

④ 贯穿于所有的活动之中，而不是只集中于一点。

（2）软件质量保证的主要任务是以下3个方面。

① SQA审计与评审。SQA审计包括对软件工作产品、软件工具和设备的审计，评价这几项内容是否符合组织规定的标准。

② SQA报告。SQA人员应记录工作的结果，并写入到报告之中，发布给相关的人员。SQA报告的发布应遵循三条原则：SQA和高级管理者之间应有直接沟通的渠道；SQA报告必须发布给软件工程组，但不必发布给项目管理人员；在可能的情况下向关心软件质量的人发布SQA报告。

③ 处理不符合问题。这是SQA的一个重要的任务。

（3）软件质量认证：目前国内软件企业主要采用的是ISO 9000 和能力成熟度模型（Capability Maturity Model, CMM）。

软件质量就是软件与明确地和隐含地定义的需求相一致的程度。软件质量是软件符合明确地叙述的功能和性能需求、文档中明确描述的开发标准以及所有专业开发的软件都应具有的隐含特征的程度。

从管理角度出发，可以将影响软件质量的因素划分为3组：产品运行、产品修改和产品转移。

5、软件风险管理

项目风险是一种不确定的事件或条件，一旦发生，会对项目目标产生某种正面或负面的影响。风险管理的主要活动过程：

①风险管理计划编制

②风险识别

③风险定性分析

④风险定量分析

⑤风险应对计划编制

⑥风险监控

6、软件维护

在系统运行过程中，软件需要维护的原因是多样的，根据维护的原因不同，可以将软件维护分为以下4种：

①改正性维护。为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就称为改正性维护。------知错能改

②适应性维护。在使用过程中，外部环境（新的硬、软件配置）、数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）可能发生变化。------与时俱进

③完善性维护。在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。------锦上添花

④预防性维护。这是指预先提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。通常，预防性维护可定义为"把今天的方法学用于昨天的系统以满足明天的需要"。也就是说，采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编码和测试。------防患于未然

7、系统转换

系统转换是指新系统开发完毕、投入运行，取代现有系统的过程，需要考虑多方面的问题，以实现与老系统的交接，有以下三种转换计划：

①直接转换：现有系统被新系统直接取代了，风险很大，适用于新系统不复杂，或者现有系统已经不能使用的情况。优点是节省成本。

②并行转换：新系统和老系统并行工作一段时间，新系统经过试运行后再取代，若新系统在试运行过程中有问题，也不影响现有系统的运行，风险极小，在试运行过程中还可以比较新老系统的性能，适用于大型系统。缺点是耗费人力和时间资源，难以控制两个系统间的数据转换。

③分段转换：分期分批逐步转换，是直接和并行转换的集合，将大型系统分为多个子系统，依次试运行每个子系统，成熟一个子系统，就转换一个子系统。同样适用于大型项目，只是更耗时，而且现有系统和新系统间混合使用，需要协调好接口等问题。

8、遗留系统改造

遗留系统指的是任何基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统。遗留系统的特点：

①系统虽然完成企业中的许多重要业务管理工作，但是不能全部满足要求。

②系统在性能上已经落后，采用的技术已经过时。

③通常是大型的软件系统，已经融入企业的业务运作和决策管理机制之中，维护工作十分困难。

④没有使用现代信息系统建设方法进行管理和开发，现在基本上已经没有文档，很难理解。

（1）淘汰策略

遗留系统的技术含量较低，且具有较低的业务价值。对遗留系统的完全淘汰是企业资源的根本浪费，系统分析师应该善于"变废为宝"，通过对遗留系统功能的理解和借鉴，可以帮助新系统的设计，降低新系统开发的风险。

（2）继承策略

遗留系统的技术含量较低，已经满足企业运作的功能或性能要求，但具有较高的商业价值，目前企业的业务尚紧密依赖该系统。对这种遗留系统的演化策略为继承。在开发新系统时，需要完全兼容遗留系统的功能模型和数据模型。为了保证业务的连续性，新老系统必须并行运行一段时间，再逐渐切换到新系统上运行。

（3）改造策略

遗留系统具有较高的业务价值，基本上能够满足企业业务运作和决策支持的需要。这种系统可能建成的时间还很短，对这种遗留系统的演化策略为改造。改造包括系统功能的增强和数据模型的改造两个方面。系统功能的增强是指在原有系统的基础上增加新的应用要求，对遗留系统本身不做改变，数据模型的改造是指将遗留系统的旧的数据模型向新的数据模型的转化。

（4）集成策略

遗留系统的技术含量较高，但其业务价值较低，可能只完成某个部门（或子公司）的业务管理。这种系统在各自的局部领域里工作良好，但对于整个企业来说，存在多个这样的系统，不同的系统基于不同的平台、不同的数据模型，形成了一个个信息孤岛，对这种遗留系统的演化策略为集成。