六、软考-系统架构设计师笔记-软件工程基础知识

1、软件工程

软件工程是将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件并对上述方法的研究。
软件要经历从需求分析、软件设计、软件开发、运行维护，直至被淘汰这样的全过程，这个过程称为软件的生命周期。
为了使软件生命周期中的各项任务能够有序地按照规程进行，需要一定的工作模型对各项任务给予规程约束，这样的工作模型称之为软件生命周期模型。

主要的开发模型有：

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

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

瀑布模型的优点：
(1)为项目提供了按阶段划分的检查点。
(2)当前一阶段完成后，只需要去关注后续阶段。
(3)它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

瀑布模型的缺点：

• (1)各个阶段之间产生大量的文档，极大地增加了工作量。
• (2)由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
• (3)不适应用户需求的变化，并且在需求分析阶段不可能完全获取。
• (4)在软件开发前期未发现的错误传到后面的开发活动中时，可能会扩散，进而可能会导致整个软件项目开发失败。所以，瀑布模型适用于需求明确或很少变更的项目

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

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

• 水平原型
• 垂直原型

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

• 抛弃型原型
• 演化型原型

原型法适合于用户需求不明确的场合。
它是先根据已给的和分析的需求，建立一个原始模型，这是一个可以修改的模型。在软件开发的各个阶段都把有关信息相互反馈，直至模型的修改，使模型渐趋完善。在这个过程中，用户的参与和决策加强了，缩短了开发周期，降低了开发风险，最终的结果是更适合用户的要求。原型法成败的关键及效率的高低，在于模型的建立及建模的速度。

三、螺旋模型
将瀑布模型和演化模型相结合，综合了两者的优点，并增加了风险分析。它以原型为基础，沿着螺线自内向外旋转，每旋转一圈都要经过制订计划、风险分析、实施工程及客户评价等活动，并开发原型的一个新版本。经过若干次螺旋上升的过程，得到最终的系统。

螺旋模型的优点：

• (1)设计上灵活，可以在项目的各个阶段进行变更；
• (2)以小的分段来构建大型系统，使成本计算变得简单容易；
• (3)客户始终参与每个阶段的开发，保证了项目不偏离正确方向；
• (4) 随着项目推进，客户始终掌握项目的最新信息 , 从而能够和管理层有效地交互。

螺旋模型的缺点：

• (1) 需要具有相当丰富的风险评估经验和专门知识，如果未能够及时标识风险，势必造成重大损失；
• (2)过多的迭代次数会增加开发成本，延迟提交时间。

四、喷泉模型
是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程，该模型认为软件开发过程自下而上的，各阶段是相互迭代和无间隙的。无间隙是指在开发活动中，分析、设计和编码之间不存在明显的边界。

五、智能模型
是基于知识的软件开发模型，它把瀑布模型和专家系统结合在一起，利用专家系统来帮助软件开发人员的工作。该模型应用基于规则的系统，采用归约和推理机制，帮助软件人员完成开发工作，并使维护在系统规格说明中一级进行。
该模型在实施过程中要建立知识库，将模型本身、软件工程知识与特定领域的知识分别存入数据库。

六、增量模型
融合了瀑布模型的基本成分和原型实现的迭代特征。当使用增量模型时，第一个增量往往是核心的产品，即第一个增量实现了基本的需求。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。

增量模型与原型实现模型和其他演化方法一样，本质上是迭代的，但与原型实现不一样的是其强调每一个增量均发布一个可操作产品。
增量模型的特点是引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。

增量模型优点：
(1) 人员分配灵活，初期不用太大投入。
(2) 每隔一小段时间就提交用户部分功能，用户可以直观感受项目进展，及时试用产品功能。
(3) 有利于风险的把控。
增量模型将功能细化、分别开发的方法适应于需求经常改变的软件开发过程。

增量模型缺点：

• (1)由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
• (2)需求的变化是不可避免的。增量模型的灵活性使其适应这种变化，但也很容易退化为边做边改，使软件过程的控制失去整体性。
• (3)如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析。

七、迭代模型
迭代模型，摒弃了传统的需求分析，设计，编码，测试的流程，而是将整个生命周期变成若干个冲刺（Sprint）阶段，每一个阶段都是由以上若干或者全部传统的流程组成，在每一个阶段中，都包含下面阶段：初始阶段，细化阶段，构建阶段，交付阶段。

• 在迭代模型中，每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。
• 迭代模型适用于项目事先不能完整定义产品所有需求、计划多期开发的软件开发。

八、构件组装模型
基于构件的软件开发(CBSD)模型是利用模块化方法，将整个系统模块化，并在一定构件模型的支持下，复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程。CBSD模型融合了螺旋模型的许多特征，本质上是演化型的，开发过程是迭代的。

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

• 需求分析和定义
• 体系结构设计
• 构件库的建立
• 应用软件构建
• 测试和发布

基于构件的软件开发的优点：

• (1)提高了软件开发的效率。
• (2)CBSD允许多个项目同时开发，降低了费用。
• (3)提高了可维护性和产品质量。

基于构件的软件开发的缺点：

• (1)由于采用自定义的组装结构标准，缺乏通用的组装结构标准引入具有较大的风险。
• (2)可重用性和软件高效性不易协调，需要精干的、有经验的分析人员和开发人员。
• (3)构件库的质量影响着产品的质量。

九、V模型
单元测试是检测代码的开发是否符合详细设计的要求。单元测试的计划是在软件详细设计阶段完成的。
集成测试是检测测试过的各组成部分是否能完好地结合到一起。
系统测试是检测已集成在一起的产品是否符合系统规格说明书的要求。
验收测试是检测产品是否符合最终用户的需求。

十、快速应用开发
快速应用开发（RAD）模型是一个增量型的软件开发过程模型，强调极短的开发周期。RAD模型是瀑布模型的一个高速变种，通过大量使用可复用构件，采用基于构件的建造方法赢得快速开发。

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

• 业务建模
• 数据建模
• 过程建模
• 应用生成
• 测试与交付

十一、敏捷方法
敏捷开发是从20世纪90年代开始逐渐引起广泛关注的一些新型软件开发方法，以应对快速变化的需求。
敏捷开发更强调程序员团队与业务专家之间的紧密协作、面对面沟通、频繁交付新的软件版本、紧凑而自我组织型的团队、能够
很好地适应需求变化的代码编写和团队组织方法，也更注重人的作用。

常见的敏捷开发方法：

• 极限编程（XP）
• 自适应软件开发
• 水晶方法
• 特性驱动开发

从开发者的角度，主要的关注点：

• 短平快会议(Stand Up)
• 小版本发布(Frequent Release)
• 较少的文档(Minimal Documentation)
• 合作为重(Collaborative Focus)
• 客户直接参与(Customer Engagement)
• 自动化测试(Automated Testing)
• 适应性计划调整(Adaptiye Planning)
• 结对编程(Pair Programming)

从管理者的角度，主要的关注点：

• 测试驱动开发(Test-Driven Development)
• 持续集成(Continuous Integration)
• 重构(Refactoring)

敏捷方法适用于中小型软件开发团队，并且客户的需求模糊或需求多变。
这些方法所提出来的一些所谓的“最佳实践”并非对每个项目都是最佳的，需要项目团队根据实际情况来决定。而且，敏捷方法的有些原则在应用中不一定能得到贯彻和执行。

十二、统一过程（UP/RUP）
是一个通用过程框架，可以用于种类广泛的软件系统、不同的应用领域、不同的组织类型、不同的性能水平和不同的项目规模。UP是基于构件的，软件系统建模时，UP使用的是UML。与其他软件过程相比，UP具有三个显著的特点：

• 用例驱动
• 以体系结构为中心
• 迭代和增量

UP中的软件过程在时间上被分解为四个顺序的阶段

• 初始阶段
• 细化阶段
• 构建阶段
• 交付阶段
  每个阶段结束时都要安排一次技术评审，以确定这个阶段的目标是否已经达到。

CMM（能力成熟度模型）

• (1)初始级：软件过程的特点是无秩序的，有时甚至是混乱的。软件过程定义几乎处于无章法和无步骤可循的状态，软件产品所取得的成功往往依赖于极个人的努力和机遇。
• (2)可重复级：已经建立了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪。对类似的应用项目，有章可循并能重复以往所取得的成功。
• (3)已定义级：用于管理和工程的软件过程均已文档化、标准化，并形成整个软件组织的标准软件过程。
• (4)已管理级：软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。
• (5)优化级：通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地、持续地进行过程改进。

CMMI（软件能力成熟度模型集成）
与CMM相比，CMMI涉及面更广，专业领域覆盖软件工程、系统工程、集成产品开发和系统采购。
CMMI模型分为5个级别：

• (1)初始级
• (2)已管理级
• (3)严格定义级
• (4)定量管理级
• (5)优化级

2、需求工程

需求工程是包括创建和维护系统需求文档所必需的一切活动的过程，可分为需求开发和需求管理两大工作。

(1)需求开发

• 需求获取
• 需求分析
• 编写规格说明书 (需求定义）
• 需求验证

(2)需求管理

• 定义需求基线
• 处理需求变更
• 需求跟踪

这两个方面是相辅相成的，需求开发是主线，是目标；需求管理是支持，是保障。

需求开发概述
需求开发所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件与其他系统元素的接口细节，定义软件的其他有效性需求，细化软件要处理的数据域。用一句话概括：需求开发主要确定开发软件的功能、性能、数据和界面等要求。

需求的分类
软件需求包括功能需求、非功能需求和设计约束3个方面的内容。

• (1)功能需求：是指系统必须完成的工作，即为了向它的用户提供有用的功能，产品必须执行的动作。
• (2)非功能需求：是指产品必须具备的性能或品质，例如，可靠性、容错性等。
• (3)设计约束：也称为限制条件、补充规约，通常是对解决方案的一些约束说明。

三个处于不同层面下的需求概念：

• (1)业务需求：是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求。
• (2)用户需求：是指描述用户使用产品必须要完成什么任务以及怎么完成的需求，是从具体用户角度考虑的需求。
• (3)系统需求：是从系统的角度来说明软件的需求，它包括了用特性说明的功能需求，质量属性及其他非功能需求，还有设计约束等。

需求获取

• (1)用户访谈
• (2)用户调查
• (3)现场观摩
• (4)阅读历史文档
• (5)联合讨论会

需求捕获的策略
在整个需求过程中，需求捕获、需求分析、需求定义、需求验证四个阶段不是瀑布式的发展，而是迭代式的演化过程。在进行需求捕获时，不要期望着一次就将需求收集完，而是应该捕获到一些信息后，进行相应的需求分析，并针对分析中发现的疑问和不足，带着问题再进行有针对性的需求捕获工作。

需求分析

• (1)结构化分析方法。
• (2)面向对象分析方法。
• (3)面向问题域的分析（PDOA）方法。

需求定义
需求定义的过程就是形成需求规格说明书的过程，通常有两种需求定义方法：

• 严格定义方法
• 原型方法

严格定义方法
严格定义（预先定义）是目前采用较多的一种需求定义方法。在采用严格定义的传统的结构化开发方法中，各个工作阶段排列成一个理想的线性开发序列，在每一工作阶段中，都用上一阶段所提供的完整、严格的文档作为指导文件，因此它本质上是一种顺序型的开发方法。

需求的严格定义建立在以下的假设基础之上：

• (1)所有需求都能够被预先定义
• (2)开发人员与用户之间能够准确而清晰地交流。
• (3)采用图形/文字可以充分体现最终系统。

严格定义的结构化开发方法存在以下缺陷：

• (1)文档量大
• (2)开发过程可见性差，来自用户的反馈太迟

原型方法
原型化的需求定义过程是一个开发人员与用户通力合作的反复过程。从一个能满足用户基本需求的原型系统开始，允许用户在开发过程中提出更好的要求，根据用户的要求不断地对系统进行完善，它实质上是一种迭代的循环型的开发方式。

采用原型方法时需要注意的问题：

• (1)并非所有的需求都能在系统开发前被准确地说明。
• (2)项目参加者之间通常都存在交流上的困难，原型提供了克服该困难的一个手段。
• (3)需要实际的、可供用户参与的系统模型。
• (4)有合适的系统开发环境。
• (5)反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法。

软件需求说明书
软件需求说明书（SRS）是需求开发阶段的成果。

• 是所有子系列项目规划、设计和编码的基础。
• 是软件项目后期开发和维护的基础。
• 是系统测试和用户文档的基础。
  但不应该包括设计、构造、测试或工程管理的细节，也不应该包括对算法的详细过程描述。

需求管理
需求管理通常包括定义需求基线、处理需求变更及需求跟踪方面的工作。
需求跟踪分为正向跟踪和逆向跟踪，合称为“双向跟踪”。

• 不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵。
• 需求跟踪矩阵保存了需求与后续工作成果的对应关系，通过需求跟踪矩阵可以跟踪一个需求使用期限的全过程，即从需求源到实现的前后生存期。

3、系统分析与设计

系统分析的基本任务是在充分了解用户需求的基础上，把对新系统的理解表达为系统需求规格说明书。
系统设计的目标是根据系统分析的结果，完成系统的构建过程。其主要目的是绘制系统的蓝图，权衡和比较各种技术和实施方法的利弊，合理分配各种资源，构建新系统的详细设计方案和相关模型，指导系统实施工作的顺利开展。

结构化方法
结构化方法也称为面向功能的软件开发方法或面向数据流的软件开发方法。它利用图形表达用户需求，强调开发方法的结构合理
性以及所开发软件的结构合理性。结构化开发方法提出了一组提高软件结构合理性的准则，如分解与抽象、模块独立性、信息隐蔽等。
针对软件生存周期的不同阶段，结构化方法又包括结构化分析(SA)、结构化设计(SD)和结构化编程(SP)等方法。

结构化分析(SA)
结构化分析方法给出一组帮助系统分析人员产生功能规约的原理与技术。它一般利用图形表达用户需求，使用的手段主要有数据流图、数据字典、结构化语言、判定表以及判定树等。结构化分析的常用手段是数据流图(DFD)和数据字典(DD)。

• 1)数据流图DFD
  DFD 建模方法的核心是数据流，从应用系统的数据流着手以图形方式描述一个业务系统中的数据流从输入到输出的变换过程。
  

数据流图DFD由4种基本元素(模型对象)构成:

• (1)数据流(Data Flow)。
  数据流用一个带有名字的箭线表示，名字表示流经的数据，箭头表示流向。
  如“订单信息”，它由商品名、订购数量、产地、单价等数据组成。
  

• (2)加工(处理)。表示对数据的加工和转换，加工名包含一个动词。用圆角矩形或圆表示。
  

• (3)数据存储。表示用数据库或文件的形式存储的数据。用开口矩形表示。
  

• (4)外部实体。也称数据源或者数据终点。描述系统数据的提供者或者数据的使用者。外部实体指系统之外的人、物或者其它系统。
  

数据字典
数据字典(DD)对数据流程图中的各个元素做出详细的说明和解释。数据流图上所有元素的定义和解释的文字集合就是数据字典。
数据字典包括：

• (1)数据结构：数据流图中数据块的数据结构说明，反映了数据之间的组合关系。
  数据结构描述={数据结构名，含义说明，组成:{数据项或数据结构}}

• (2)数据项：数据流图中数据块的数据结构中的数据项说明。数据项是不可再分的数据单位。
  数据项描述={数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系}

• (3)数据流：数据流图中流线的说明。数据流是数据结构在系统内传输的路径。
  数据流描述={数据流名，说明，数据流来源，数据流去向，组成:{数据结构}，平均流量，高峰期流量}

• (4)数据存储：数据流图中数据块的存储特性说明。数据存储是数据结构停留或保存的地方，一般是数据流的来源和去向之一。
  数据存储描述={数据存储名，说明，编号，流入的数据流，流出的数据流，组成:{数据结构}，数据量，存取方式}

• (5)处理过程：数据流图中功能块的说明。数据字典中只需要描述处理过程的说明性信息。
  处理过程描述={处理过程名，说明，输入:{数据流}，输出:{数据流}，处理:{简要说明}}

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

1)概要设计
也称为高层设计或总体设计，即将软件需求转化为数据结构和软件的系统结构。
概要设计包括：

• 设计软件的结构
• 确定系统由哪些模块组成
• 每个模块之间的关系

2)详细设计
也称为低层设计，即对结构图进行细化，得到详细的数据结构与算法。详细设计的任务就是为每个模块进行设计。
采用自顶向下、逐步求精的设计方式和单入口单出口的控制结构。
使用的工具包括：

• 程序流程图
• 盒图(NS流程图)
• PAD图(Problem Analysis Diagram,问题分析图)
• PDL (ProgrmDesign Language,伪代码)

3)模块结构
模块结构是指将程序或系统按照功能或其他原则划分为若干个具有一定独立性和大小的模块，每个模块具有某方面的功能。
模块是组成系统的基本单位，它的特点是可自由组合、分解和变换，系统中任何一个处理功能都可以看成一个模块。
由于模块之间的互相联系越多，模块的独立性就越少，因此，引入衡量模块独立程度的两个标准：耦合和内聚。
我们要求模块之间是**“高内聚、低耦合”。** （容易考选择题 记忆 ☆☆☆☆☆）

(1)内聚
内聚表示模块内部各代码成分之间联系的紧密程度。一个好的内聚模块应当恰好做目标单一的一件事情。
模块的内聚类型

内聚强度从高到低排列如下

(2)耦合
耦合表示模块之间联系的程度。
耦合强度从低到高排列如下

例:软件设计过程中，可以用耦合和内聚两个定性标准来衡量模块的独立程度，耦合衡量不同模块彼此间互相依赖的紧密程度，应采用以下设计原则( )，内聚衡量一个模块内部各个元素彼此结合的紧密程度，以下属于高内聚的是( )。
A.尽量使用内容耦合、少用控制耦合和特征耦合、限制公共环境耦合的范围、完全不用数据耦合
B.尽量使用数据耦合、少用控制耦合和特征耦合、限制公共环境耦合的范围、完全不用内容耦合
C.尽量使用控制耦合、少用数据耦合和特征耦合、限制公共环境耦合的范围、完全不用内容耦合
D.尽量使用特征耦合、少用数据耦合和控制耦合、限制公共环境耦合的范围、完全不用内容耦合

A.偶然内聚 B.时间内聚 C.功能内聚 D.逻辑内聚

答案： B 、 C
解析：
内容耦合耦合性最强，模块的独立性最弱，因此不应该使用内容耦合。根据题干信息，数据耦合在这里耦合性最弱，尽量使用数据耦合。
功能内聚内聚性最强，模块独立性也最强。

(3)信息隐藏与抽象
信息隐藏原则要求采用封装技术，将程序模块的实现细节(过程或数据) 隐藏起来，通过接口按要求来访问。按照信息隐藏的原则，系统中的模块应设计成“黑盒”，模块外部只能使用模块接口说明中给出的信息，例如，操作和数据类型等。模块之间相对独立，既易于实现，也易于理解和维护。
抽象原则要求抽取事物最基本的特性和行为，忽略非本质的细节，采用分层次抽象的方式可以控制软件开发过程的复杂性，有利于软件的可理解性和开发过程的管理。抽象层次包括过程抽象、数据抽象和控制抽象。

4)系统结构图
又称模块结构图，是概要设计阶段的工具，反映系统的功能实现和模块之间的联系与通信，包括各模块之间的层次结构，即反了系统的总体结构。

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

面向对象方法
面向对象 (OO)开发方法将面向对象的思想应用于软件开发过程中，指导开发活动，是建立在“对象”概念基础上的方法学。
面向对象开发方法认为客观世界是由对象组成的，对象由对象名、属性和操作(方法)组成，对象可按其属性进行分类，对象之间的联系通过传递消息来实现，对象具有封装性、继承性和多态性。

面向对象开发方法是以用例驱动的、以体系结构为中心的、迭代的和渐增式的开发过程。
面向对象的方法由OOA(面向对象分析)、OOD(面向对象设计)和OOP(面向对象编程)三个部分组成。
OOA和OOD 统一采用UML（统一建模语言）来描述并记录。

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

• 分类结构：就是一般与特殊的关系。
• 组装结构：反映了对象之间的整体与部分的关系。

1)OOA原则

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

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

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

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

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

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

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

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

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

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

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

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

面向对象设计OOD
类封装了信息和行为，是面向对象的重要组成部分，它是具有相同属性、方法和关系的对象集合的总称。在定义类时，将类的职
责分解为类的属性和方法，其中属性用于封装数据，方法用于封装行为。
设计类是OOD中最重要的组成部分，也是最复杂和最耗时的部分。在OOD 中，类分为三种类型：实体类、控制类和边界类。

1)实体类
实体类映射需求中的每个实体，实体类是指需要存储在永久存储体中的信息，例如在线教育平台系统可以提取出学员类和课程类，它们都属于实体类。
实体类对用户来说是最有意义的类，通常采用业务领域术语命名，一般是一个名词。在用例模型向领域模型的转化中，一个参与者一般对应于实体类。通常可以从SRS 中的那些数据库表(需要持久存储)对应的名词来找寻实体类。实体类一定有属性但不一定有操作。

例如： 客户、仓库 等 可以设计成实体类

2)控制类
控制类是用于控制用例工作的类，一般是由动宾结构的短语 (“动词+名词"或"名词+动词"转化来的名词，例如，用例"身份验证"对应一个控制类"身份验证器”，它提供了与身份验证有关的所有操作。
控制类将用例的特有行为进行封装，控制对象的行为与特定用例的实现密切相关，当系统执行用例的时候，就产生了一个控制对象，控制对象经常在它对应的用例执行完毕后消亡。控制类没有属性，但一定有方法(操作)。

3)边界类
边界类位于系统与外界的交接处，用于封装在用例内、外流动的信息或数据流。常见的边界类有窗体、报表、通信协议、打印机和扫描仪接口、传感器，以及与其他系统的接口。要寻找和定义边类，可以检查用例模型，每个参与者和用例交互至少要有一个边界类，边界类使参与者能与系统交互。边界类可以既有属性也有方法

4、软件测试

软件测试是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程。

• 目前，软件的正确性证明尚未得到根本的解决，软件测试仍是发现软件错误和缺陷的主要手段。
• 软件测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件产品（主要是指程序）中的错误和缺陷。

测试是对软件质量的度量：

• (1)软件测试是为了发现错误而执行程序的过程。
• (2)测试是为了证明程序有错，而不是证明程序无错误。
• (3)一个好的测试用例在于它能发现至今未发现的错误。
• (4)一个成功的测试是发现了至今未发现的错误的测试。
  软件测试只是软件质量保证的手段之一，不能单凭测试来保证软件质量。

测试的类型
软件测试分为两大类，分别为动态测试和静态测试。
1.动态测试
动态测试指通过运行程序发现错误，分为：

• 黑盒测试法
• 白盒测试法
• 灰盒测试法

(1)黑盒法
黑盒测试又称为功能测试或数据驱动测试。把被测试对象看成一个黑盒子，测试人员完全不考虑程序的内部结构和处理过程，只在软件的接口处进行测试，依据需求规格说明书，检查程序是否满足功能要求。
常用的黑盒测试用例的设计方法：

• 等价类划分
• 边界值分析
• 错误推测
• 因果图

(2)白盒法
又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。
把测试对象看做一个打开的盒子，测试人员必须了解程序的内部结构和处理过程，以检查处理过程的细节为基础，对程序中尽可
能多的逻辑路径进行测试，检验内部控制结构和数据结构是否有错，实际的运行状态与预期的状态是否一致。

常用的白盒测试用例设计方法有：

• 基本路径测试
• 循环覆盖测试
• 逻辑覆盖测试

逻辑覆盖是以程序内部逻辑为基础的测试技术，常用的有语句覆盖、判定覆盖、条件覆盖、条件判定覆盖、条件组合覆盖、路径覆盖等，发现错误的能力呈由弱至强的变化。

• 语句覆盖每条语句至少执行一次。
• 判定覆盖每个判定的每个分支至少执行一次。
• 条件覆盖每个判定的每个条件应取到各种可能的值。
• 判定/条件覆盖同时满足判定覆盖条件覆盖。
• 条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
• 路径覆盖使程序中每一条可能的路径至少执行一次。

(3)灰盒法
灰盒测试是一种介于白盒测试与黑盒测试之间的测试，它关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒测试那样详细且完整，而只是通过一些表征性的现象、事件及标志来判断程序内部的运行状态。
灰盒测试结合了白盒测试和黑盒测试的要素，考虑了用户端、特定的系统知识和操作环境，在系统组件的协同性环境中评价应用软件的设计。

静态测试
静态测试指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测。
静态分析中进行人工测试的主要方法：

• 桌前检查(Desk Checking)
• 代码审查
• 代码走查

(1)桌前检查
由程序员自己检查自己编写的程序。程序员在程序通过编译之后，
进行单元测试设计之前，对源程序代码进行分析、检验，并补充
相关的文档，目的是发现程序中的错误

(2)代码审查
代码审查是由若干程序员和测试员组成一个会审小组，通过阅读、讨论和争议，对程序进行静态分析的过程。代码审查分两步。

• 小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为评审的依据。小组成员充分阅读这些材料。
• 召开程序审查会。在会上，首先由程序员逐句讲解程序的逻辑。在此过程中，程序员或其他小组成员可以提出问题，展开讨论，审查错误是否存在。

(3)代码走查
代码走查与代码审查基本相同，其过程也分为两步。

• 把材料先发给走查小组成员，认真研究程序，再开会。
• 开会的程序与代码会审不同，不是简单地读程序和对照错误
  检查表进行检查，而是让与会者“充当”计算机。让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论使用。数据标准化、数据命名合理、文件格式转换、数据库格式转换等。

测试的阶段
根据测试的目的、阶段的不同，把测试分为：

• 单元测试
• 集成测试
• 确认测试
• 系统测试

单元测试
单元测试又称为模块测试，是针对软件设计的最小单位（模块）进行正确性检验的测试工作。目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能性能、接口和设计约束等要求，以及发现各模块内部可能存在的各种错误。

单元测试通常由开发人员自己负责。

• 单元测试要借助驱动模块（相当于用于测试模拟的主程序）和桩模块（子模块）来完成。
• 单元测试的计划是在软件详细设计阶段完成的。
• 单元测试一般使用白盒测试方法

集成测试
集成测试也称为组装测试、联合测试。它将已通过单元测试的模块集成在一起，主要测试模块之间的协作性。
从组装策略而言，可以分为一次性组装和增量式组装（包括自顶向下、自底向上及混合式）两种。

• 集成测试计划是在软件概要设计阶段完成的。
• 集成测试一般采用黑盒测试方法。

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

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

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

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

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

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

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

根据用户的参与程度，包括以下4种类型：

• (1)内部确认测试：由软件开发组织内部按软件需求说明书进行测试。
• (2) Alpha测试：由用户在开发环境下进行测试。
• (3) Beta测试：由用户在实际使用环境下进行测试。
• (4) 验收测试：针对软件需求说明书，在交付前以用户为主进行测试。

系统测试
是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。系统测试计划在系统分析阶段（需求分析阶段）完成。

系统测试的内容包括：

• 功能测试
• 健壮性测试
• 性能测试
• 用户界面测试
• 安全性测试
• 安装与反安装测试

性能测试
性能测试是通过自动化的测试工具模拟多种正常、峰值及异常负载条件来对系统的各项性能指标进行测试。
负载测试和压力测试都属于性能测试。

• 负载测试，确定在各种工作负载下系统的性能。
• 压力测试是通过确定一个系统的瓶颈或不能接收的性能点，来获得系统能提供的最大服务级别的测试。

性能测试的目的
是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，并优化软件，达到优化系统的目的。

• (1)评估系统的能力
• (2)识别体系中的弱点
• (3)系统调优
• (4)检测软件中的问题
• (5)验证稳定性和可靠性

性能测试的类型
性能测试类型包括负载测试、强度测试和容量测试等。

• (1)负载测试：指数据在超负荷环境中运行，程序是否能够承担。
• (2)强度测试：在系统资源特别低的情况下考查软件系统运行情况。
• (3)容量测试：确定系统可处理的同时在线的最大用户数。

负载压力测试
负载压力测试是在一定约束条件下（指定软件、硬件及网络环境）测试系统所能承受的并发用户数、运行时间、数据量，以确定系统所能承受的最大负载压力。

• 并发用户数是负载压力的重要体现。
• 在网络应用系统中，负载压力测试重点关注客户端、网络及服务器（包括应用服务器和数据库服务器）的性能。

测试自动化
为了提高软件测试的效率，运用既有的测试工具或开发相应的测试程序进行测试，这个过程称为自动化测试。

• (1)提高测试执行的速度
• (2)提高运行效率
• (3)保证测试结果的准确性。
• (4)连续运行测试脚本。
• (5)模拟现实环境下受约束的情况。

5、净室软件工程

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

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

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

• 完备性:对定义域中的每个元素，值域中至少有一个元素与之对应。对程序而言，每种可能的输入都必须定义，并有一个输出与之对应。
• 一致性:在值域中最多有一个元素与定义域中的同一元素对应。对程序而言，每个输入只能对应一个输出。
• 正确性:函数的正确性可以由上述性质判断。对程序而言，某项设计的正确性可以通过基于函数理论的推理来验证。

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

技术手段

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

• 2.基于函数的规范与设计
  盒子结构方法按照函数理论定义了三种抽象层次：行为视图(黑盒)、有限状态机视图(状态盒)、过程视图(清晰盒或明盒)。
  (1)黑盒。刻划系统或系统的某部分的行为。通过运用由激发得到反应的一组变迁规则，系统对特定的激发（事件）作出反应。
  (2)状态盒。以类似于对象的方式封装状态数据和服务(操作)。在这个规约视图中，表示出状态盒的输入（激发）和输出（反应）
  (3)清晰盒。在清晰盒中定义状态盒所蕴含的变迁功能，简单地说，清晰盒包含了对状态盒的过程设计。

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

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

净室软件工程的缺点

• 1)CSE 太理论化，需要更多的数学知识。其正确性验证的步骤比较困难且耗时多。CSE要求采用增量式开发、盒子结构、统计测
  试方法，普通工程师必须经过加强训练才能掌握，开发软件的成本比较高昂。
• 2)CSE 不进行传统的模块测试，这是不现实的。工程师可能对编程语言和开发环境还不熟悉，而且编译器或操作系统的Bug 也可能导致未预期的错误。
• 3)CSE毕竟脱胎于传统软件工程，不可避免地带有传统软件工程的一些弊端。

6、基于构件的软件工程

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

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

• (1)可组装：对于可组装的构件，所有外部交互都必须通过公开定义的接口进行。
• (2)可部署：软件必须是自包含的，必须能作为一个独立实体在提供其构件模型实现的构件平台上运行。构件总是二进制形式，无须在部署前编译。
• (3)文档化：构件必须是完全文档化的，用户根据文档来判断构件是否满足需求。
• (4)独立性：构件应该是独立的，可以在无其他特殊构件的情况下进行组装和部署，如确实需要其他构件提供服务，则应显示声明。
• (5)标准化：构件标准化意味着在基于构件的软件开发过程中使用的构件必须符合某种标准化的构件模型。

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

CBSE过程

• (1)系统需求概览
• (2)识别候选构件
• (3)根据发现的构件修改需求
• (4)体系结构设计
• (5)构件定制与适配
• (6)组装构件创建系统

构件组装
构件组装是指构件相互之间集成或是用专门编写的"胶水代码"将它们整合在一起来创造一个系统或另一个构件的过程。
常见的构件组装有3 种方式：
1.顺序组装
通过按顺序调用已经存在的构件，可以用两个已经存在的构件来创造一个新的构件。顺序组装适用于作为程序元素的构件或是作为服务的构件。需要特定的胶水代码，来保证两个构件的组装：上一个构件的输出与下一个构件的输入相兼容。

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

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

7、软件项目管理

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

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

1. 活动定义
2. 活动排序
3. 活动资源估算
4. 活动历时估算
5. 制定进度计划
6. 进度控制

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

工作分解的基本要求(原则)

• (1)WBS的工作包是可控和可管理的，不能过于复杂。
• (2)任务分解也不能过细，一般原则WBS的树形结构不超过6层。
• (3)每个工作包要有一个交付成果。
• (4)每个任务必须有明确定义的完成标准。
• (5)WBS必须有利于责任分配。

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

• 前导图法(单代号网络图法)

• 箭线图法(双代号网络图法)

• 1)前导图法
  前导图法(PDM)也称为单代号网络图法(AON)，使用方框或者长方形（被称作节点）代表活动，用箭头连接表示它们之间逻辑关系

下图有4个活动、7个依赖关系

• 2)箭线图法
  箭线图法(ADM)也称为双代号网络图法(AOA) ，用箭线表示工作，
  节点表示工作的逻辑关系。

• 箭线：使用箭线表示工作，箭线都需要占用时间，消耗资源。

• 虚箭线：为了正确表达工作之间的逻辑关系，而虚设的一项并不存在的工作，因此不占用资源，不消耗时间。

• 节点：反映的是前后工作的交接点，体现了各工作之间的逻辑关系。
  

• 3)网络图的绘制
  

• 4)每个活动有四个和时间相关的参数： (这个要回计算 会考选择题 ☆☆☆☆☆)

• (1)最早开始时间（ES)。某项活动能够开始的最早时间。

• (2)最早结束时间（EF)。某项活动能够完成的最早时间。EF=ES+工期估计

• (3)最迟结束时间（LF)。为了使项目按时完成，某项工作必须完成的最迟时间。

• (4)最迟开始时间（LS)。为了使项目按时完成，某项工作必须开始的最迟时间。LS=LF-工期估计

• 5)计算出工程的最早完工时间。通过正向计算（从第一个活动到最后一个活动）推算出最早完工时间，

步骤如下：

• (1) 从网络图始端向终端计算。
• (2) 第一任务的开始为项目开始。
• (3) 任务完成时间为开始时间加持续时间（工期）。
• (4) 后续任务的开始时间根据前置任务的时间和搭接时间而定。
• (5) 多个前置任务存在时，根据最迟任务时间来定。
• 6)通过反向计算（从最后一个活动到第一个活动）推算出最晚完工时间，

步骤如下：

• (1) 从网络图终端向始端计算。
• (2) 最后一个任务的完成时间为项目完成时间。
• (3) 任务开始时间为完成时间减持续时间（工期）。
• (4) 前置任务的完成时间根据后续任务的时间和搭接时间而定。
• (5) 多个后续任务存在时，根据最早任务时间来定。

总时差TF：不影响总工期的前提下，本工作可以利用的机动时间。
自由时差FF：不影响紧后工作最早开始时间的前提下，本工作可以利用的机动时间。

• 总时差=该工作最晚结束时间(LF) - 该工作最早结束时间(EF)
• 总时差=该工作最晚开始时间(LS) - 该工作最早开始时间(ES)
• 自由时差=该工作的紧后工作最早开始时间(ES)的最小值-该工作最早结束时间(EF)
  自由时差总是小于等于总时差。
  总时差为零或负的活动，就是关键活动。

记住下图： 熟练记忆 英文缩写 对应的含义
这种类似的题目 一般会给出活动工期 I 只要正确计算出各个活动的 ES、EF、LS、LF、TF、FF 基本上答案就出来了

例:
项目包含的活动如下所示，完成整个项目的工期（ ）天。不能通过缩短活动（ ）的工期，来缩短整个项目完成时间。
A.16 B.17 C.18 D.19
A. A B. B C. D D.F

答案：D 、 B
上表转换为箭线图：

正向推 A是第一个活动 所以A活动的最早开始时间 ES是0 EF 0+3=4
继续推…

其中需要注意 F活动前面有两个活动 C 和 E 且 C的EF = 9 E的EF = 11 此时F的ES取大值 即11
(很好理解 举个例子： 你要更换一部手机的电池和屏幕 但是这两个配件是你从网上分两个快递买的 电池2天能送到 屏幕3天能送到
那么你想进行手机维修 就必须等到第三天电池和屏幕都到了才能 全部更换完成 所以维修手机的最早开始时间就是取大的值 第三天)

最后一个活动的 EF 就是整个项目的工期 所以工期是19

从后往前推：
C的后续活动 有F和G F的LS = 11 G的LS=12 C的LF 取二者小的值 也就是 11
同理 A 和 E 也取 小值
（这个也很好理解 F的最晚开始时间是11 G的最晚开始时间是12 要不影响整体的工期 那么C的最晚结束时间就得是11 如果是12 就会影响F的开始）

此时我们把每个活动的 ES 、EF 、LS、 LF都求出来了

接下来算 TF 和 FF
TF(总时差) = LS - ES 或者 LF -EF (就是下图的左下角减左上角 或者 右下角减右上角)

FF(自由时差) = 该工作的紧后工作最早开始时间(ES)的最小值 - 该工作最早结束时间(EF)
（就是下图中 紧后活动的左上角 ES (如果有多个取最小值) 减 本活动的右上角 EF）


总时差为0或者为负数 的活动组成的路径 称为关键路径

至此 我们算出了 所有活动的 ES、EF、LS、LF、TF、FF 也标注出了关键路径

第一个空：
关键路径上的活动持续时间决定了项目的工期，总和就是项目工期 A、D、E、F、H 3+3+5+4+4 =19

第二个空： 只有B 不在关键路径上 所以 不能通过缩短B的工期来缩短整个项目的工期

例:
某项目包括A~G七个作业，各作业之间的衔接关系和所需时间如下表，其中，作业C所需的时间，乐观估计为5天，最可能为14天，保守估计为17天。假设其他作业都按计划进度实施，为使该项目按进度计划如期全部完成。作业C( )。
A.必须在期望时间内完成
B.必须在14天内完成
C.比期望时间最多可拖延1天
D.比期望时间最多可拖延2天

答案： D

解析：
和上个题目类似 只不过是有些活动没给工期 但是绕着弯给了 总时差和自由时差
需要使用一个公式计算出 C 的工期

工期 =( 乐观时间 + 4x(最可能时间) + 保守估计时间 ） / 6 = (5+4x14+17) /6 = 13

C的总时差2天

总时差TF：不影响总工期的前提下，本工作可以利用的机动时间。

作业C比期望时间最多可拖延2天

软件配置管理
软件配置管理(SCM)是一种标识、组织和控制修改技术。配置管理是标识和确定系统中配置项的过程，在系统整个生存期内控制这些配置项的投放和变动，记录并报告配置的状态和变动要求，验证配置项的完整性和正确性。
配置项包括：

• 与合同、过程和产品有关的文档和资料
• 源代码、目标代码和可执行代码
• 相关软件工具、库内的可重用软件、外购软件

1.配置库
配置库也称为配置项库，是用来存放配置项的工具。
配置库记录与配置相关的所有信息
配置库有3类：

• (1)开发库
• (2)受控库
• (3)产品库

2.变更控制
1)变更控制委员会
也称为配置控制委员会(CCB)，其任务是对配置项变更做出评价、审批，以及监督已批准变更的实施。CCB的成员包括项目经理、用户代表、质量控制人员、配置控制人员、测试人员。

变更控制的流程

• (1)变更申请
• (2)变更评估
• (3)变更决策
• (4)变更实施
• (5)变更验证
• (6)沟通存档

版本管理
通常有二种版本命名的方法：

• 号码版本标识
  以数字表示，如用1.0，2.0，1.2，2.1.1等表示版本号；
• 符号版本标识
  符号版本标识是将重要的版本属性有选择地给出，如:
  Windows 11、CentOS8、IDEA2024等

质量管理

1. 规划质量管理
   包括识别与该项目相关的质量标准以及确定如何满足这些标准。
2. 质量保证
   定期评价总体项目绩效，以树立项目满足相关质量标准的信心。
   3.质量控制
   监控具体项目结果以确定其是否符合相关的质量标准，并制定
   相应措施来消除导致绩效不令人满意的原因。

质量保证
质量保证指为项目符合相关质量标准，而在质量系统内部实施的各项有计划的系统活动，质量保证应贯穿于项目的始终。
质量保证分为：

• 内部质量保证：由项目管理团队、实施组织的管理层实施
• 外部质量保证：由客户和其他未参与项目工作的人实施。

质量控制
监测项目的总体结果，判断它们是否符合相关质量标准，并找出如何消除不合格绩效的方法。
对于信息系统项目，一般采用软件测试和配置管理等质量控制手段来有效控制信息系统产品质量，与传统制造行业常采用统计抽样、控制图等工具有很大区别。

软件质量管理 rowspan=“3”
质量特性包括功能性、可靠性、易使用性、时间经济性、资源经济性、可维护性和可移植性等。

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

• (1)风险管理计划编制
• (2)风险识别
• (3)风险定性分析
• (4)风险定量分析
• (5)风险应对计划编制
• (6)风险监控