软考笔记（九）高级系统架构师/分析师：软件工程与项目管理

目录

软考官网 报名通道

软考架构师笔记（一）：计算机系统基础

软考架构师笔记（二）：计算机网络基础与信息安全

软考架构师笔记（三）：操作系统基础

软考架构师笔记（四）：企业信息化与系统规划

软考架构师笔记（五）：系统需求工程 需求分析

软考架构师笔记（六）：数据库

软考架构师笔记（七）：系统分析 系统设计

软考架构师笔记（八）：系统架构

软考架构师笔记（九）：软件工程与项目管理

软考架构师笔记（十）：系统测试 维护 稳定性

信息系统开发方法

1，结构化系统分析与设计方法（SSA&D）

基本思想是：用系统的思想，系统工程的方法，按用户至上的原则，结构化、模块化、自顶向下对信息系统进行分析与设计；

严格区分工作阶段，每阶段有任务和结果；强调系统开发过程的整体性和全局性；系统开发过程工程化，文档资料标准化。

自顶向下的开发方式，适用于那些需求明确，但技术难度不大的系统开发

面向数据流的方法

结构化方法使用的主要分析设计工具是“程序流程图、数据流程图等”

2，原型方法

基本思想是：凭借着系统分析人员对用户要求的理解，在软件环境支持下，快速地给出一个实实在在的模型（或称为原型、雏形），然后与用户反复协商修改，最终形成实际系统。

适用于需求不明确的情况。

3，面向对象的开发方法（OO）

出发点和基本原则是：尽可能模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界、解决问题的方法与过程；更好的复用性；关键在于建立一个全面、合理、统一的模型；分析、设计、实现三个阶段，界限不明确。

 

4，面向服务的开发方法 SOA

以粗粒度、松散耦合和标准的服务为基础，加强了系统的可复用性和可演化性

企业信息工程

信息工程方法认为，与企业的信息系统密切相关的三要素是：企业的各种信息、企业的业务过程和企业采用的信息技术

信息工程自上而下地将整个信息系统的开发过程划分为四个实施阶段，分别是信息规划阶段、业务领域分析阶段、系统设计阶段和系统构建阶段。

信息系统生命周期

软件工程开发模型

开发模型主要包括：

• 瀑布模型
• 演化模型
• 增量模型
• 迭代模型
• 螺旋模型
• 快速原型
• 喷泉模型
• V模型

瀑布模型是将软件生存周期各个活动规定为依线性顺序连接的若干阶段的模型。它包括可需求分析、设计、编码、测试、运行和维护。

瀑布模型的优点是：容易理解，管理成本低，强调开发的阶段性早期计划及需求调查和产品测试。不足之处是：客户必须能够完整、正确和清晰地表达他们的需要，需求或设计中的错误往往只有到了项目后期才能够被发现。

增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，它假设可以将需求分段为一系列增量产品，每一增量可以分别地开发。该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。而瀑布模型难以适应这种需求的不确定性和变化，于是出现了快速原型这种新的开发方法。原型是预期系统的一个可执行版本，反映了系统性质的一个选定的子集。一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型。

螺旋模型将瀑布模型和演化模型结合起来，加入了两种模型均忽略的风险分析，弥补了这两种模型的不足。螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有了解，继而做出应有的反应。因此特别适用于庞大、复杂并且具有高风险的系统。与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高软件的适应能力，并且为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发的风险。

瀑布模型：

• 瀑布模型是一个特别经典的，老套的周期模型。工序简化，将功能实现和设计分开。便于分工协作。
• 一般情况下将软件开发周期分为计划、需求分析、概要设计、详细设计、编码以及单元测试、测试、运行维护等几个阶段。
• 瀑布模型的周期是环环相扣的。每个周期中交互点都是一个里程碑，上一个周期的结束需要输出本次活动的工作结果，本次的活动的工作结果将会作为下一个周期的输入。这样，当某一个阶段出现了不可控的问题的时候，就会导致返工，返回到上一个阶段，甚至会延迟下一个阶段。
  自上而下、相互衔接的固定次序

优点:

(1)为项目提供了按阶段划分的检查点。
(2)当前一阶段完成后，您只需要去关注后续阶段。
(3)可在迭代模型中应用瀑布模型。
增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。

缺点:

(1)在项目各个阶段之间极少有反馈。
(2)只有在项目生命周期的后期才能看到结果。
(3)通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
(4)瀑布模型的突出缺点是不适应用户需求的变化。

 

V模型：

• V模型从整体上看起来，就是一个V字型的结构，由左右两边组成。
• 左边的下划线分别代表了需求分析、概要设计、详细设计、编码。
• 右边的上划线代表了单元测试、集成测试、系统测试与验收测试。
• 看起来V模型就是一个对称的结构，它的重要意义在于，非常明确的表明了测试过程中存在的不同的级别，并且非常清晰的描述了这些测试阶段和开发阶段的对应关系。

 

优点：相对于瀑布模型，V模型测试能够尽早的进入到开发阶段。
缺点：虽然测试尽早的进入到开发阶段，但是真正进行软件测试是在编码之后，这样忽视了测试对需求分析，系统设计的验证，时间效率上也大打折扣。
明确标注了测试过程中存在不同的测试类型，明确表示出了开发阶段与测试各阶段的对应关系。

原型化模型：

• 过程：
• 第一步就是创建一个快速原型，能够满足项目干系人与未来的用户可以与原型进行交互
• 再通过与相关干系人进行充分的讨论和分析，最终弄清楚当前系统的需求
• 进行了充分的了解之后，在原型的基础上开发出用户满意的产品
• 在实际的项目过程中，借助于组织过程资产以及快速模型软件，一般在需求分析的时候，就可以建立一些简单的原型，例如在第一家YH公司中，因为是“行业软件提供商”，所以拥有各个地域的行业解决软件方案，惯用的伎俩就是将其他地市的项目拿到本次项目实施地，作为原型化模型。原型化模型是极具意义的项目实践。

在系统开发中，原型是系统的一个早期可运行的版本，它反映最终系统的部分重要特性。从原型是否实现功能来分，可分为:水平原型和垂直原型两种。

水平原型也称为行为原型，用来探索预期系统的一些特定行为，并达到细化需求的目的。水平原型通常只是功能的导航，但未真实实现功能。水平原型主要用在界面上。

垂直原型也称为结构化原型，实现了一部分功能。垂直原型主要用在复杂的算法实现上。

从原型的最终结果来分，可分为抛弃式原型和演化式原型。

抛弃式原型也称为探索式原型，是指达到预期目的后，原型本身被抛弃。抛弃式原型主要用在解决需求不确定性、二义性、不完整性、含糊性等。

演化式原型为开发增量式产品提供基础，逐步将原型演化成最终系统，主要用在必须易于升级和优化的场合，适合于Web项目。

螺旋模型：

• 尤其重视风险分析阶段，特别适用于庞大并且复杂，非常高风险的项目。
• 通常螺旋模型由四个阶段组成：制定计划、风险分析、实施工程和客户评估。螺旋模型中，发布的第一个模型甚至可能是没有任何产出的，可能仅仅是纸上谈兵的一个目标，但是随着一次次的交付，每一个版本都会朝着固定的目标迈进，最终得到一个更加完善的版本。

构件组装模型CBSD模型

基于构件的软件开发（Component Based Software Development，CBSD）模型是利用模块化方法，将整个系统模块化，并在一定构件模型的支持下，

复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程。基于构件的开发模型融合了螺旋模型的许多特征，本质上是演化型的，开发过程是迭代的。

基于构件的开发模型由软件的需求分析和定义、体系结构设计、构件库建立、应用软件构建、测试和发布5个阶段组成。

统一过程 RUP模型

 

UP/RUP把一个项目分为4个不同的阶段：

初始阶段

（1）项目蓝图文档（核心需求，关键特性，主要约束）
（2）用例模型
（3）项目计划

细化阶段

（1）完成架构设计
（2）淘汰高风险元素

构造阶段

（1）UML 设计模型
（2）测试用例

交付阶段

（1）可运行的软件产品
（2）用户手册
（3）用户支持计划

用例驱动， 以架构为中心，迭代和增量

喷泉模型：

（fountainmodel,(面向对象的生存期模型,OO模型)）

喷泉模型与传统的结构化生存期比较，具有更多的增量和迭代性质，生存期的各个阶段可以相互重叠和多次反复，而且在项目的整个生存期中还可以嵌入子生存期。就像水喷上去又可以落下来，可以落在中间，也可以落在最底部。

RAD模型：

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

采用RAD模型的软件通过大量使用可复用构件，采用基于构件的建造方法赢得快速开发。如果需求理解得好且约束了项目的范围，随后是数据建模、过程建模、应用生成、测试及反复。

设计思想：

（1）让用户更主动地参与到系统分析、设计和构造活动中来。
（2）将项目开发组织成一系列重点突出的研讨会，研讨会要让项目投资方、用户、分析员、设计人员和构造人员一同参与。
（3）通过一种迭代的构造方法加速需求分析和设计阶段。
（4）让用户提前看到一个可工作的系统。

是构件组装模型（CBSD）+ 瀑布模型

构建 库 就是抽取 共性部分形成模块组件

软件工程开发方法

主要包括：

开发方法主要包括：

• 迭代开发方法
• 快速应用开发
• 构件组装模型/基于构件的开发方法
• 统一过程/统一开发方法
• 模型敏捷开发方法
• 模型驱动的开发方法
• 基于架构的开发方法

敏捷方法：

基本原则：

短平快的会议
小型版本发布
较少的文档
合作为重
客户直接参与
自动化测试
适应性计划调整
结对编程
测试驱动开发
持续集成
重构

 

极限编程（XP）：敏捷开发的典型方法之一，是一种轻量级（敏捷）、高效，低风险、柔性、可预测的、科学的软件开发方法，它由价值观、原则、实践和行为4个部分组成。其中4大价值观为沟通、简单性、反馈和勇气。

水晶法（Crystal）：水晶方法体系与XP一样，都有以人为中心的理念，但在实践上有所不同。水晶方法体系考虑到人们一般很难严格遵循一个纪律约束很强的过程，认为每一种不同的项目都需要一套不同的策略、约定和方法论。因此，与XP的高度纪律性不同，水晶方法体系探索了用最少纪律约束而仍能成功的方法，从而在产出效率与易于运作上达到一种平衡。也就是说，虽然水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遵循它。

并列争球法（Scrum）：用迭代的方法，其中把每30天一次的迭代称为一个“冲刺”，并按需求的优先级来实现产品。多个自组织和自治小组并行地递增实现产品。协调是通过简短的日常会议来进行的

自适应软件开发（ASD）：ASD的核心是三个非线性的、重迭的开发阶段：猜测，合作与学习。

 

逆向工程：

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

参考：https://www.jianshu.com/p/3069f9c5a17e

 

CMMI

CMMl成熟度级别为五个成熟度级别，每一级是一个层次，作为继续进行过程改进的基础。

（1）成熟度级别1级：初始级。该级别过程是随意且混乱的，组织不能提供稳定的环境支撑这些过程。组织的成功依赖于内部人员的能力，且组织有过渡承诺的倾向。

（2）成熟度级别2级：已管理级。该等级的过程是按照方针和计划执行的过程，雇佣有技能的人，有充分资源，有干系人参与，有监督和控制等。

（3）成熟度级别3级：已定义级。处于这个级别时，项目的过程得到清晰的说明与理解，并以标准、规程、工具与方法的形式进行描述。与能力等级2级相比，3级采用的项目标准是从组织标准中剪裁过来的，2级适用于特定项目而3级适用于特定的组织，同时3级的过程描述比2级更为严谨，过程得到了更积极的管理。

（4）成熟度级别4级：已量化级。组织与项目建立了质量与过程性能的量化目标并将其用作管理项目的准则。成熟度级别4级和3级的区别是，4级对于过程性能的可预测性高。

（5）成熟度级别5级：持续优化级。5级关注于通过增量式的与创新式的过程与技术改进，不断地改进过程性能。4级与5级的区别是，在4级别时关注子过程层面的绩效，5级则是关注整体绩效。

项目可行性分析

可行性是指在企业当前的条件下，是否有必要建设新系统，以及建设新系统的工作是否具备必要的条件。也就是说，可行性包括必要性和可能性。参考国家标准《计算机软件文档编制规范》（GB/T8567-2006），在信息系统建设项目中，可行性研究通常从经济可行性、技术可行性、法律可行性和用户使用可行性四个方面来进行分析，其中经济可行性通常被认为是项目的底线。

1.经济可行性经济可行性也称为投资收益分析或成本效益分析，主要评估项目的建设成本、运行成本和项目建成后可能的经济收益。多数项目只有建设成本能控制在企业可接受的预算内的时候，项目才有可能波批准执行。而经济收益的考虑则非常广泛，可以分为直接收益和间接收益、有形收益和无形收益，还可以分为一次性收益和非一次性收益、可定量的收益和不可定量的收益等。要注意的是，在系统开发初期，由于用户需求和候选系统方案还没有确定，成本不可能得到准确的估算。因此，此时的经济可行性分析只能大致估算系统的成本和收益，判断信息系统的建设是否值得。

2.技术可行性技术可行性也称为技术风险分析，研究的对象是信息系统需要实现的功能和性能，以及技术能力约束。技术可行性主要通过考虑以下问题来进行论证：
（1）技术：现有的技术能力和信息技术的发展现状是否足以支持系统目标的实现。
（2）资源：现有的资源（例如，掌握技术的员工、企业的技术积累、构件库、软硬件条件等）是否足以支持项目的实施。
（3）目标：由于在可行性研究阶段，项目的目标是比较模糊的，因此技术可行性最好与项目功能、性能和约束的定义同时进行。在可行性研究阶段，调整项目目标和选择可行的技术体系都是可以的，而一旦项目进入开发阶段，任何调整都意味着更多的开销。需要特别指出的是，技术可行性绝不仅仅是论证在技术手段上是否可实现，实际上包含了在当前资源条件下的技术可行性。例如，开发一个计算机操作系统对于美国微软公司来说，这是可行的，但对其他绝大多数企业来说，这都是不可行的。投资不足、时间不足、预设的开发目标技术难度过大、没有足够的技术积累、没有熟练的员工可用、没有足够的合作企业和外包资源积累等都是技术可行性的约束。实践证明，如果只考虑技术实现手段而忽视企业当前的资源条件和环境，从而对技术可行性分析得出过于乐观的结果，将会对后期的项目实施导致灾难性后果。对于技术的选择，有的企业钟情于新技术，有的则喜欢使用成熟的技术。具体要根据项目的实际情况（例如，开发环境、开发人员的素质、系统的性能要求等）进行决策，但通常的建议是尽可能采用成熟的技术，慎重引入先进技术。IT业界流行的谐语”领先一步是先进，领先两步是先烈”讲的就是对技术的选择原则。

3.法律可行性法律可行性也称为社会可行性，具有比较广泛的内容，它需要从政策、法律、道德、制度等社会因素来论证信息系统建设的现实性。例如，所开发的系统与国家法律或政策等相抵触，在政府信息化的领域中使用了未被认可的加密算法，未经许可在产品中使用了其他企业的被保护的技术或构件等，这样的项目在法律可行性上就是行不通的。

4.用户使用可行性用户使用可行性也称为执行可行性，是从信息系统用户的角度来评估系统的可行性，包括企业的行政管理和工作制度、使用人员的素质和培训要求等，可以细分为管理可行性和运行可行性。
（1）管理可行性。管理可行性是指从企业管理上分析系统建设可行性。主管领导不支持的项目一般会失败，中高层管理人员的抵触情绪很大，就有必要等一等，先积极做好思想工作，创造条件。另外，还要考虑管理方法是否科学，相应的管理制度改革的时机是否成熟，规章制度是否齐全等。
（2）运行可行性。运行可行性也称为操作可行性，是指分析和测定信息系统在确定环境中能够有效工作，并被用户方便使用的程度和能力。例如，ERP系统建成后的数据采集和数据质量问题，企业工作人员没有足够的IT技能等。这些问题虽然与系统本身无关，但如果不经评估，很可能会导致投入巨资建成的信息系统却室无用处。运行可行性还需要评估系统的各种影响，包括对现有IT设施的影响、对用户组织机构的影响、对现有业务流程的影响、对地点的影响、对经费开支的影响等。如果某项影响会过多改变用户的现状，需要将这些因素作进一步的讨论并和用户沟通，提出建议的解决方法。否则，系统一旦建成甚至在建设过程中，就会受到用户的竭力反对，他们会抵制使用系统。

 

软件开发环境

软件开发环境（Software Development Environment，SDE）是指支持软件的工程化开发和维护而使用的一组软件，由软件工具集和环境集成机制构成。

软件开发环境应支持多种集成机制，如平台集成、数据集成、界面集成、控制集成和过程集成等。软件开发环境应支持小组工作方式，并为其提供配置管理。环境的服务可用于支持各种软件开发活动，包括分析、设计、编程、调试和文档等。较完善的软件开发环境通常具有多种功能，如软件开发的一致性与完整性维护、配置管理及版本控制、数据的多种表示形式及其在不同形式之间的自动转换、信息的自动检索与更新、项目控制和管理，以及对开发方法学的支持。软件开发环境具有集成性、开放性、可裁减性、数据格式一致性、风格统一的用户界面等特性，因而能大幅度提高软件生产率。集成机制根据功能的不同，可划分为环境信息库、过程控制与消息服务器、环境用户界面3个部分。
（1）环境信息库：软件开发环境的核心，用于存储与系统开发有关的信息，并支持信息的交流与共享。其中主要存储两类信息，一类是开发过程中产生的有关被开发系统的信息，如分析文档、设计文档和测试报告等；另一类是环境提供的支持信息，如文档模板、系统配置、过程模型和可复用构件等。

（2）过程控制与消息服务器：实现过程集成和控制集成的基础，过程集成是按照具体软件开发过程的要求进行工具的选择与组合；控制集成使各工具之间进行并行通信和协同工作。

（3）环境用户界面：包括环境总界面和由它实行统一控制的各环境部件及工具的界面。统一并具有一致性的用户界面是软件开发环境的重要特征，是充分发挥环境的优越性、高效地使用工具并减轻用户的学习负担的保证。

 

模块内聚耦合问题

耦合表示模块之间联系的程度。紧密耦合表示模块之间联系非常强，松散耦合表示模块之间联系比较弱，非耦合则表示模块之间无任何联系，是完全独立的。模块的耦合类型通常分为7种，根据耦合度从低到高排序如下表所示。

---

项目管理

范围管理

范围计划编制-> 范围定义->创建WBS->范围确认->范围控制

范围管理就是要确定项目的边界，也就是说，要确定哪些工作是项目应该做的，哪些工作不应该包括在项目中。这个过程用于确保项目干系人对作为项目结果的产品或服务，以及开发这些产品所确定的过程有一个共同的理解。

WBS 工作分解结构（把项目整体或者主要的可交付成果分解成容易管理、方便控制的若干个子项目，子项目需要继续分解为工作包。

持续这个过程，直到整个项目都分解为可管理的工作包，这些工作包的总和就是项目的所有工作范围。创建WBS的目的是详细规定项目的范围，建立范围基准。具体来说，其主要目的和用途如下：
①明确和准确说明项目范围，项目组成员能够清楚地理解任务的性质和需要努力的方向。
②为各独立单元分派人员，规定这皆人员的相应职责，可以确定完成项目所需要的技术和人力资源。
③针对各独立单元，进行时间、费用和资源需求量的估算，提高估算的准确性。
④为计划、预算、进度安排和费用控制奠定共同基础，确定项目进度测量和控制的基准。
⑤将项目工作与项目的财务账目联系起来。
⑥清楚地定义项目的边界，便于划分和分派责任，自上而下将项目目标落实到具体的工作上，并将这些工作交给项目内外的个人或组织去完成。
⑦确定工作内容和工作顺序。可以使用图形化的方式来查看工作内容，任何人都能够清楚地辨别项目的阶段、工作单元，并根据实际进展情况进行调节和控制。
③估计项目整体和全过程的费用。
④有助于防止需求蔓延。当用户或其他项目干系人试图为项目增加功能时，在WBS中增加相应工作的同时，也就能够很容易地让他们理解，相关费用和进度也必须要做相应的改变。

时间管理

.时间管理的过程包括活动定义、活动排序、活动的资源估算、活动历时估算、制定计划和进度控制。

前导图法（单代号网络图，PDM）

一文搞懂什么是单代号网络图！

• 结束-开始的关系（F-S型）
• 结束-结束的关系（F-F型）
• 开始-开始的关系（S-S型）
• 开始-结束的关系（S-F型）

关键路径法

关键路径法是在制订进度计划时使用的一种进度网络分析技术，

关键路线法沿着项目进度网络路线进行正向与反向分析，从而计算出所有计划活动理论上的最早开始与完成日期、最迟开始与完成日期，不考虑任何资源限制
总时差（松弛时间）：在不延误总工期的前提下，该活动的机动时间。活动的总时差等于该活动最迟完成时间与最早完成时间之差，或该活动最迟开始时间与最早开始时间之差

自由时差：在不影响紧后活动的最早开始时间前提下，该活动的机动时间。

• 对于有紧后活动的活动，其自由时差等于所有紧后活动最早开始时间减本活动最早完成时间所得之差的最小值
• 对于没有紧后活动的活动，也就是以网络计划终点节点为完成节点的活动，其自由时差等于计划工期与本活动最早完成时间之差

对于网络计划中以终点节点为完成节点的活动，其自由时差与总时差相等。此外，由于活动的自由时差是其总时差的构成部分，所以，当活动的总时差为零时，其自由时差必然为零，可不必进行专门计算

甘特图

优点：甘特图直观、简单、容易制作，便于理解，能很清晰地标识出直到每一项任务的起始与结束时间，一般适用比较简单的小型项目，可用于WBS的任何层次、进度控制、资源优化、编制资源和费用计划。
缺点：不能系统地表达一个项目所包含的各项工作之间的复杂关系，难以进行定量的计算和分析，以及计划的优化等。

 

PERT图

PERT总结

求项目 关键路径，松弛时间

关键路径能够完成整个项目的最长路径，

松弛时间，一个任务能够空闲，歇息的时间，在不影响总工期的前提下

①最早开始时间（某段工程开始点之前最长的输入流之和）， 
②最晚开试（关键路径-开始点到最后整个工程最后结束点的距离）， 
③最早结束（某段工程结束点之前最长的输入流之和）， 
④最晚结束（关键路径-该结束点到整个工程最后结束点的距离）

松弛时间=最晚开始-最早开始②-①
松弛时间=最晚结束-最早结束④-③

松弛时间=关键路径-所求活动在的最长路径

成本管理

成本估算，成本预算，成本控制

 

软件质量管理

软件配置管理

软件配置管理（Software Configuration Management，SCM）是指通过执行版本控制、变更控制的规程，以及使用合适的配置管理工具，来保证所有配置项的完整性和可跟踪性。

软件配置管理中，每一项配置变更都要在配置状态报告中进行详细的记录。在配置状态报告中，需要对每一项变更进行详细的记录，

包括：发生了什么？为什么会发生？谁做的？什么时候发生的？会有什么影响？整个配置状态报告的信息流如下图

如上图所示，每次新分配一个配置项，或者更新一个已有配置项或配置项标识，或者一项变更申请被变更控制负责人批准，

并给出了一个工程变更顺序时，在配置状态报告中就要增加一条变更记录条目；

一旦进行了配置审核，其结果也应该写入报告中。配置状态报告可以放在一个联机数据库中，以便开发人员或者维护人员对它进行查询或修改。此外，在配置状态报告中，新记录的变更应当及时通知给管理人员和其他项目干系人。

主要目标是标识变更，控制变更，确保变更正确地实现，报告有关变更。SCM是一组管理整个软件生存期各阶段中变更的活动。软件配置管理的内容包括版本控制、变更控制及过程支持