能力等级	特点
初始级别	杂乱无章，有时甚至很混乱，几乎没有明确定义的步骤，项目的成功完全依赖个人的努力和英雄式核心人物的作用。
可重复级别	建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功。
已定义级	管理和工程两方面的软件过程已经文档化、标准化，并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来开发和维护软件。
已管理级	制定了软件过程和产品质量的详细度量标准。对软件过程和产品质量都有定量的理解和控制。
优化级	过程的量化反馈和先进的思想，新技术持续地改进。

能力成熟度模型集成（CMMI）

CMMI：若干过程模型的综合和改进，不只软件，支持多个工程学科和领域的、系统的、一致的过程改进框架。

两种表示方法

阶段式模型：类似于CMM，关注组织的成熟度
连续式模型：关注每个过程域的能力，一个组织对不同的过程域可以达到不同的能力等级。

阶段式模型成熟度等级模型：

阶段式模型成熟度等级描述
能力等级	特点	关键区域过程
初始级	过程不可预测且缺乏控制
已管理级	过程为项目服务	需求管理、项目计划、配置管理、项目监督与控制、供应商合司管理、度量和分析、过程和产品质量保证
已定义级	过程为组织服务	需求开发、技术解决方案、产品集成、验证、确认组织级过程焦点、组织级过程定义、组织级培训、集成项目管理、风险管理、集成化的团队、决策分析和解决方案、组织级集成环境
定量管理	过程已度量和控制集中于	组织过程性能、定量项目管理
优化级	过程改进和优化	组织级改革和实施、因果分析和解决方案

例题 1.【2022年】以下关于软件维护的叙述中，正确的是( )

A. 工作量相对于软件开发而言要小很多

B. 成本相对于软件开发而言要更低

C. 时间相对于软件开发而言通常更长

D. 只对软件代码进行修改的行为

解析：系统出现问题时，运维的工作量会很大。A错误。可能有好多期运维，成本不一定比软件开发低。B错误。运维是整个软件运行的维护。D错误。选C。

2. 【2009年】软件能力成熟度模型(CMM)的第4级(已管理级)的核心是( )。

A. 建立基本的项目管理和实践来跟踪项目费用、进度和功能特性

B. 组织具有标准软件过程

C. 对软件过程和产品都有定量的理解和控制

D. 先进的新思想和新技术促进过程不断改进

解析：参考上面CMM等级描述表格。选C。

5.2 软件过程模型

软件过程模拟：软件开发全部过程、活动和任务的结构框架。

5.2.1 瀑布模型（Waterfall Model）

经典的生命周期模型，般将软件开发分为：可行性分析(计划)、需求分析、软件设计(概要设计、详细设计)、编码、测试、运行维护几个阶段。以文档作为驱动。

瀑布模型模式:

从上一项开发活动接收该项活动的工作对象作为输入。
接收输入后，实施该项活动应完成的工作内容。
给出该项活动的工作成果，作为输出传给下一项开发活动。
对该项活动的实施工作成果进行评审。若评审通过，则进入下一项开发活动；否则返回前一项甚至更前项的活动。

优点：容易理解，管理成本低，强调开发的阶段性早期计划级需求调查和产品测试，适合于软件需求明确的软件项目的模型。

不足：需求提出到看到成果的周期长，不能演示系统的能力。对项目风险的控制能力弱。

e.g. 乙方接甲方，若甲方改需求，那么乙方工作就会因为再次评审等工作而时间变长，成本相应增加。

瀑布模型变种——V模型

左边的线是开发活动，分别代表了需求建模（需求分析）、概要设计、详细设计、编码。

右边的线是测试活动，分别代表了单元测试、集成测试、系统测试与验收测试。

特点如下:

单元测试主要针对编码过程中可能存在的各种错误进行验证。

集成测试主要针对详细设计中可能存在的各种错误进行验证。

系统测试主要针对概要设计，检查系统作为一个整体是否可以有效地运行。

验收测试主要是针对需求建模、需求分析，通常由业务专家或者用户进行，以确认产品能真正符合用户业务上的需要。

V模型用于需求明确和需求变更不频繁的情形，突出测试和开发生命周期各阶段的结合。

5.2.2 增量模型（Incremental Model）

融合了瀑布模型的基本成分和原型实现的选代特征

假设可以将需求分段为一系列增量产品，每一增量可以分别开发。

增量之间有优先级，首先要开发核心模块功能，第一个增量是它的核心，而后与用户确认后开发下一个增量，优先级高的增量（服务）最先交付。

特点：由于不是从系统整体角度规划各个模块，每一次增量的模块划分可能没有延续性，因此不利于模块划分。难点在于如何将客户需求划分为多个增量。与原型不同的是增量模型的每一个增量版本都可以作为独立的作品，而原型的构造一般是为了演示。

5.2.3 演化模型

原型模型（Prototype Model）

适用于：用户需求不清，或经常变化；系统规模不大也不太复杂。

目的：快速、低成本地构建模型，迅速开发出让用户可以看得见的系统框架，使对计算机不熟悉地用户根据这个框架提出自己需求和改进意见。

原型模型：第一步交流，然后创建一个快速原型，使项目干系人与未来的用户通过原型进行交互，再经过讨论和分析，弄清楚系统的需求，在原型的基础上开发出用户满意的产品。

原型法认为在很难一下子全面准确地提出用户需求的情况下，原型应当具备的特点如下:

实际可行。
具有最终系统的基本特征。
构造方便、快速，造价低。
它对用户需求是动态的、逐步纳入的。

螺旋模型

结合了瀑布模型和演化模型结合，强调了风险分析，特别适用于大型、复杂度高风险高的系统。

将开发过程分为几个螺旋周期，具有周期性重复的螺旋线状，每个螺旋周期大致和瀑布模型相符合。每个螺旋周期分为如下4个工作步骤：制定计划、风险分析、实施工程和客户评估。

5.2.4 喷泉模型

以用户需求为动力，以对象作为驱动的而模型，适合于面向对象的开发方法。

使开发过程具有迭代性和无间隙性。迭代性：开大活动常常需要重复多次，在迭代过程中不断完善软件系统。

特点

各个阶段无明显界限，开发人员可以同步进行。
优点：提高软件项目的开发效率，节省时间。
不足：由于模型在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，不利于项目管理。要求严格管理文档，加大审核难度。

5.2.5 基于构件的开发模型（Component-based Development Model）

构件：一个完整的、可单独使用的软件包。

利用预先保证的构件来构造应用系统。

构件可以是组织内部开发的构件，也可以是商品化成品软件构件。

特点：增强了复用性，在系统开发过程中会构建一个构件库，供其他系统复用，因此可以提高可靠性，节省时间和成本。

5.2.6 形式化方法模型

建立在严格数学基础上。

主要活动：生成计算机软件形式化的数学规格说明。

5.2.7 统一过程模型（UP）

“用例和风险驱动，以架构为中心，选代并且增量”的开发过程，由UML方法和工具支持。

迭代：将整个软件开发项目划分为许多个小的“袖珍项目”，每个“袖珍项目”都包含正常软件项目的所有元素：计划、分析和设计、构造、集成和测试，以及内部和外部发布。

统一过程模型包括4个阶段：初始阶段、精化阶段、构建阶段、移交阶段。

初始阶段：生命周期目标。
精化阶段：生命周期架构。
构建阶段：初始运作功能。
移交阶段：产品发布。

每次迭代产生包括最终系统的部分完成的版本和任何相关的项目文档的基线，通过逐步迭代基线之间相互构建，直到完成最终系统。

每个迭代中有5个核心工作流：

需求工作流：捕获系统应该做什么的，
分析工作流：精化和结构化需求的，
设计工作流：在系统构架内实现需求
实现工作流：构造软件
测试工作流：验证实现是否如期望那样工作的。

统一过程的典型代表是RUP(Rational UnifiedProcess)。RUP是UP的商业扩展，完全兼容 UP但比 UP 更完整、更详细。

5.2.8 敏捷方法（Agile Development）

总体目标：通过“尽可能早地、持续地对有价值的软件的交付”使客户满意。通过在软件开发过程中加入灵活性，敏捷方法使用户能够在开发周期的后期增加或改变需求。

以人为核心、迭代、循序渐进的开发方法，强调程序员团队与业务专家之间的紧密协作、面对面沟通（认为比书面文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。

敏捷软件开发宣言

个体和交互胜过过程和工具
可以工作的软件胜过面面俱到的文档
客户合作胜过合同谈判
响应变化胜过遵循计划

敏捷过程的典型方法有很多，每一种方法基于一套原则，这些原则实现了敏捷方法所宣称的理念(敏捷宣言)：极限编程(XP)、水晶法(Crystal)、并列争求法(Scrum)、自适应软件开发(ASD)、敏捷统一过程AUP)

极限编程（XP）

轻量级（敏捷）、高效、低风险、柔性、可预测的、科学的软件开发方式。

由价值观、原则、实践和行为4个部分组成，彼此相互关联，并通过行为贯穿于整个生存周期。

4大价值观：沟通、简单性、反馈和勇气。

5个原则：快速反馈、简单性假设、逐步修改、提倡更改和优质工作。

12个最佳实践：

结对编程:一个程序员开发，另一个程序员在一旁观察审查代码，能够有效的提高代码质量共同对代码负责。

自适应开发:强调开发方法的适应性。侧重为软件的重要性提供最根本的基础，并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。

水晶方法：每一个不同的项目都需要一套不同的策略、:约定和方法论

并列争求法SCRUM：迭代的增量化工程。把每段时间（30天）一次的选代成为一个“冲刺”，并按需求的优先级别来实现产品，多个自组织和自治的小组并行地递增实现产品。

软件过程模型概述

类型
瀑布	结构化放大

5.3 需求分析

5.3.1 软件需求

软件需求：用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。

IEEE定义：软件需求指用户解决问题或达到目标所需要的条件或能力，时系统或系统部件要满足合同标准、规范或其它正式规定文档所需具有的条件或能力，以及反应这些条件或能力的文档说明。

需求来源

可以来自于用户(实际的潜在的)、用户的规约、应用领域的专家、相关的技术标准和法规；

可以来自于原有的系统、原有系统的用户、新系统的潜在用户；

甚至还可以来自于竞争对手的产品。

软件需求的分类

按照多层次分类，软件需求包括业务需求、用户需求和系统需求。这三者是从目标到具体，从整体到局部，从概念到细节。

业务需求：反映企业或客户对系统高层级的目标要求（高层级需求）。e.g. 产品一天能支撑一千万交易额。

用户需求：描述用户的具体目标，用户想要什么，以及要这些做什么（用户需求）

系统需求：从系统的角度说明软件的需求，包括功能需求、非功能需求、设计约束等

功能需求：是指系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作。
非功能需求：是指产品必须具备的性能或品质，例如，可靠性、存储容量限制，容错性等。
设计约束：也称为限制条件、补充规约，通常是对解决方案的一些约束说明，例如，某系统必须采用国有自主知识版权的数据库，必须运行在UNIX系统之下，等等。

质量功能部署(Quality Function Deployment,QFD)：一种将用户要求转化成软件需求的技术。目的是最大限度提升软件工程过程中用户满意度。把用户对产品的需求进行多层次的演绎分析，转化为产品的设计需求、工程部件特征、工艺要求、生产要求，用来指导产品设计并保证产品的质量，是一种以用户为导向的质量管理工具。

按照QDF将软件需求分为三类

常规需求：系统应该做到的功能或性能，实现的越多，用户越满意。
期望需求：用户认为系统应该做到，但是不能正确表达的功能，没有实现会让用户不满意。
意外需求：用户要求范围外的功能或性能，开发人员控制，实现会高兴，不实现也没关系。

例题：某软件公司正在承担开发一个文字处理器的任务。在需求分析阶段，公司的相关人员整理出一些相关的系统需求。其中，”找出文档中的拼写错误并提供一个替换项列表来供选择替换拼错的词“属于（1），“显示提供替换词的对话框以及实现整个文档范围的替换”属于（2），“用户能有效地纠正文档中的拼写错误”属于（3）。（每个选项可以多次使用）
A. 业务需求 B. 用户需求 C. 功能需求 D. 性能需求

解析：

（1）描述用户想要具体实现的需求，技术人员难以直接跟着这条需求做开发。因此是用户需求，选B。

（2）对有文字处理相关经验的人看到此需求知道具体怎么做。因此是功能需求，选C。

（3）更倾向于描述所期望的最终结果，而不是用户期待的具体的功能或操作（没有具体说明如何纠正，怎么算“有效”）。因此是业务需求，选A。

5.3.2 需求分析原则

必须能够表示和理解问题的信息域。
必须能够定义软件将完成的任务。
必须能够表示软件的行为（作为外部事件的结束）。
必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节。
分析过程应该从要素信息移向细节信息。

通过应用这些原则，分析人员将能系统地处理问题。检查信息域可以更完整地理解功能，通过模型可以更简洁地交流功能和行为的特征，应用抽象与分解可减少问题的复杂度。

5.3.3 需求工程

需求工程：是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。

细分为6个阶段：需求获取、需求分析与协商、系统建模、需求规约、需求验证和需求管理。

需求开发：包括需求获取、需求分析、编写规约（系统规格说明书）和需求验证4个阶段。

需求开发的4个阶段:
在需求开发阶段需要确定产品所期望的用户类型、获取每种用户类型的需求、了解实际的用户任务和目标,以及这些任务所支持的业务需求。
同时还包括分析源于用户的信息、对需求进行优先级分类、将所收集的需求编写成为软件规格说明书和需求分析模型，以及对需求进行评审等工作

1. 需求获取

What：应该搜集什么信息。
Where：从什么地方搜集这些信息。
How：用什么机制或者技术来搜集这些信息。

常见的需求获取方式有：用户访谈、问卷调查、采样、情节串联版、联合需求计划等。

用户访谈：一对一进行访谈，适合于针对有代表性的用户。其形式分为结构化（提前列好访问内容）和非结构化（根据用户反应调整问题）两种。

问卷调查：设计问题、制作成用户调查问卷、下发填写、整理分析。适合用户面广、用户需要灵活时间进行回馈。

采样：采用统计分析技术，从目标总体中选择出样本集的过程。可以是随机抽样，或非随机抽样。适合用于大量用户信息或者数据信息采集分析，最终得出需求的场景。

情节串联板：一系列图片，通过这些图片来讲故事。

联合讨论会：通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求。

需求记录技术：任务卡片、场景说明、用户故事等。

例题在多种需求获取方式中，（1）方法具有良好的灵活性，有较宽广的应用范围，但存在获取需求时信息量大、记录较为困难、需要足够的领域知识等问题。（2）方法基于数理统计原理，不仅可以用于收集数据，还可以用于采集访谈用户或者是采集观察用户并可以减少数据收集偏差。（3）方法通过高度组织的群体会议来分析企业内的问题，并从中获取系统需求。（每个选项可以多次使用）

A.用户访谈 B.问卷调查 C.联合需求计划 D.采样

解析：（1）问卷调查的问题固定，且题量不能太多，所以信息量不大。用户访谈可以深入挖掘，但记录困难，需要用笔记录并慢慢沉淀，且需要足够知识才能谈下去，激发有用信息。选A。（2）采样是基于数据统计，选D。(3)高度组织且内部—>联合需求计划。

2. 需求分析

需求分析：一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性。

需求分析人员：杂乱无章、真假难辨的用户要求和期望—>真正的用户需求—>系统需求—>需求规约（需求规格说明书）。
需求分析:逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型 )。

需求分析的任务:
绘制系统上下文范围关系图
创建用户界面原型分析需求的可行性
确定需求的优先级
为需求建立模型
创建数据字典
使用QFD(质量功能部署)

3. 系统建模

常用的分析方法：面向数据流的结构化分析方法(SA)和面向对象的分析方法(OOA)。

结构化分析方法：自顶向下、逐步分解、分析的核心是数据字典。

结构化分析围绕数据字典建立三种模型：数据模型、功能模型、行为模型

数据模型：常用实体关系(E-R)图描述实体、属性，以及实体间的关系。
功能模型：常用数据流图(DFD dataflow diagram)，从数据传输加工的角度，用图形符号描述数据在系统间的传递情况。
行为模型：又称状态模型，常用状态转换图(STD state transform diagram)描述系统状态和引起系统状态转换的事件，表示系统行为指出作为特定事件的结果将执行哪些动作。

数据流图

数据流图：可以分层，根据层级数据流图分为顶层数据流图、中层数据流图和底层数据流图。除顶层数据流图外，其他数据流图从零开始编号。

顶层数据流图：只含有一个加工表示整个系统，输出数据流和输入数据流为系统的输入数据和输出数据，表明系统的范围，以及与外部环境的数据交换关系。
中层数据流图：对父层数据流图中某个加工进行细化，而它的某个加工也可以再次细化，形成子图。中间层次的多少，一般视系统的复杂程度而定。
底层数据流图：其加工不能再分解的数据流图，其加工称为“原子加工”。

例题

1. 结构化分析方法中，数据流图中的元素在（）中进行定义。

A.加工逻辑 B.实体联系图 C.流程图 D.数据字典

答案：D

2. 下列关于结构化分析方法的数据字典加工逻辑的叙述中，不正确的是()。

A. 对每一个基本加工，应该有一个加工逻辑。

B. 加工逻辑描述输入数据流变换为输出数据的加工规则。

C. 加工逻辑必须实现加工的数据结构和算法。

D. 结构化语言，判定树和判定表可以用来表示加工逻辑。

答案：C

3. 绘制分层数据流图(DFD)时需要注意的问题中，不包括（）。

A. 给图中的每个数据流、加工、数据存储和外部实体命名。

B. 图中要表示出控制流。

C.一个加工不适合有过多的数据流。

D.分解尽可能均匀。

答案：B

4. 需求规约

软件需求规约（也叫需求定义、软件需求规格说明书SRS），是需求分析任务的最终产物，通过建立完整的信息描述详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。

需求规约作为用户和开发者之间的一个协议，在之后的软件工程各阶段发挥重要的作用。

软件需求规约中通常包含以下内容:

引言。陈述软件目标，基于计算机的系统语境。
信息描述。详细描述软件必须解决的问题，记录信息内容、信息流和信息结构。
功能描述。描述解决问题所需要的每个功能。其中包括为每个功能说明一个处理过程；叙述设计约束；叙述性能特征；用一个或多个图形形象地表示软件的整体结构和软件功能与其他系统元素间的相互影响。
行为描述。描述作为外部事件和内部产生的控制特征的软件操作。
校验标准。描述检验系统成功的标志，即对系统进行什么样的测试，得到什么样的结果，就表示系统已经成功实现了。检验标准是“确认测试”的基础。
参考书目。包含了对所有和该软件相关的文档的引用，其中包括其他的软件工程文档、技术参考文献厂商文献和标准。
附录。包含了规约的补充信息，表格数据、算法的详细描述、图表和其他资料。

需求定义方法

严格定义也称为预先定义，需求的严格定义建立在以下的基础假设之上：所有需求都能够被预先定义。开发人员与用户之间能够准确而清晰地交流。采用图形(或文字)可以充分体现最终系统。

原型方法，迭代的循环型开发方式。需要注意的问题：并非所有的需求都能在系统开发前准确的说明。项目干系人之间通常都存在交流上的困难，原型提供了克服该困难的一个手段。特点:需要实际的、可供用户参与的系统模型。有合适的系统开发环境。反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法。

5. 需求验证（需求确认）

目的：作为需求开发阶段工作的复查手段，检查需求功能的正确性、完整性和清晰性，是否能够反映用户的意愿。

对需求规约进行评审和测试，包括两个步骤

需求评审：正式评审和非正式评审。
需求测试：设计概念测试用例。

由于需求的变化往往使系统的设计和实现也跟着改变，所以由需求问题引起系统变更的成本比修改设计或代码错误的成本高得多。因此，评审应指定专门的人员负责，并按规程严格进行。除分析人员之外，还要有用户，开发部门的管理者，软件设计、实现、测试人员参加。

需求验证通过后，要请用户签字确认，作为验收标准之一，此时，这个需求规格说明书就是需求基线，不可以再随意更新，如果需要更改必须走需求变更流程。

在需求验证之后，对遗漏的补充以及对错误理解的更正是不可避免的，因此需要进行需求管理。

需求验证内容:

系统定义的目标是否与用户的要求一致。
系统需求分析阶段提供的文档资料是否齐全;文档中的描述是否完整、清晰、准确地反映了用户要求。
被开发项目的数据流与数据结构是否确定且充足。
主要功能是否已包括在规定的软件范围之内，是否都已充分说明。
设计的约束条件或限制条件是否符合实际。
开发的技术风险是什么。
是否详细地制定了检验标准，它们能否对系统定义进行确认

6. 需求管理

软件需求管理：是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动，对需求工程所有相关活动的规划和控制。换句话说，需求管理就是一种获取、组织并记录系统需求的系统化方案，以及一个使用户与项目团队对不断变更的系统需求达成并保持一致的过程。

需求跟踪

在需求管理中，每个需求被赋予唯一的标识符，一旦标识出需求，就可以为需求建立跟踪表，每个跟踪表标识需求与其他需求或设计文档、代码、测试用例的不同版本间的关系。

特征跟踪表，记录需求如何与产品或系统特征相关联。
来源跟踪表，记录每个需求的来源。
依赖跟踪表，描述需求间如何关联等。

需求跟踪的目的：为了建立和维护从用户需求开始到测试之间的一致性与完整性，确保所有的实现是以用户需求为基础，所有的输出符合用户需求，并且全面覆盖了用户需求。

需求跟踪方式：

正向跟踪：以用户需求为切入点。检查《需求规约》中每个需求是否都能在后继工作产品中找到对应点。——用户原始需求是否都实现了。需求—>被满足？
逆向跟踪：检查设计文档、代码、测试用例等是否都能在《需求规约》中找到出处。——软件实现的是否都是用户要求的。功能—>用户需求？

状态跟踪

整个项目过程中，要始终跟踪需求状态即变更情况。

变更控制

主要关心需求变更中的需求风险管理

带有风险的做法：无足够用户参与、忽略了用户分类、用户需求的不断增加、模棱两可的需求、不必要的特性、过于精简的SRS、不准确的估算。

变更产生的原因：外部环境的变化、需求和设计做的不够完整、新技术的出现、公司机构重组造成业务流程的变化。

变更控制委员会CCB：也称为配置控制委员会，其任务是对建议的配置项变更做出评价、审批，以及监督已经批准变更的事实。

变更控制的内容有:

需求变更需要经过正式评估来决定是否批准
保持项目计划与需求的同步
以可控制的方式将需求变更融入项目中
估计变更需求产生的影响，并协商新的约定

版本控制

使项目团队和用户达成共识，定义需求基线（即通过了评审的需求规约）。下次如果需求变更需求，就需要安装流程来一步步进行。

例题（）是关于需求管理正确的说法

A. 为达到过程能力成熟度模型第二级，组织机构必须具有3个关键过程域。

B.需求的稳定性不属于需求属性。

C.需求变更的管理过程遵循变更分析和成本计算、问题分析和变更描述、变更实现的顺序。

D.变更控制委员会对项目中任何基线工作产品的变更都可以做。

答案：D

5.4 系统设计

目的：为系统指定蓝图，在各种技术和实施方法中权衡利弊，精心设计，合理使用各种资源，最终勾画出新系统的详细设计方案。

主要内容：新系统总体结构设计、代码设计、输入设计、输出设计、处理过程设计、数据存储设计、用户界面设计和安全控制设计等。

系统设计方法

面向数据流的结构化设计方法（SD）。
面向对象的设计方法（OOD）。

基本原理：抽象化；自顶而下，逐步求精；信息隐蔽；模块独立(高内聚、低耦合)

系统设计原则：保持模块的大小适中；尽可能减少调用的深度；多扇入（对模块的上级调用，复用程度高）、少扇出（下级模块逻辑较复杂）；单入口、单出口；模块的作用域应该在模块之内;功能应该可预测。

5.4.1 概要设计

1）设计软件系统总体结构

基本任务用某种设计方法，将系统按功能划分成软件模块，确定每个模块的功能和调用关系;确定模块之间的接口，即模块之间传递的信息;评价模块结构的质量。形成模块的模块结构图，即系统结构图。

软件系统的质量及一些整体特性都在软件系统总体结构的设计中决定。

2）数据结构即数据库设计

（1）数据结构的设计。逐步细化的方法也适用于数据结构的设计。在需求分析阶段，已经通过数据字典对数据的组成、操作约束和数据之间的关系等方面进行了描述，确定了数据的结构特性，在概要设计阶段要加以细化，详细设计阶段则规定具体的实现细节。在概要设计阶段，宜使用抽象的数据类型。
（2）数据库的设计。数据库的设计是指数据存储文件的设计，主要进行以下几方面设计。

概念设计。在数据分析的基础上，采用自底向上的方法从用户角度进行视图设计，一般用E-R模型来表述数据模型。 E-R 模型既是设计数据库的基础，也是设计数据结构的基础。
逻辑设计。E-R 模型是独立于数据库管理系统(DBMS)的，要结合具体的 DBMS 特征来建立数据库的逻辑结构。
物理设计。对于不同的 DBMS,物理环境不同，提供的存储结构与存取方法各不相同。物理设计就是设计数据3模式的一些物理细节，如数据项存储要求、存取方法和索引的建立等。

3) 编写概要设计文档

文档主要有概要设计说明书、数据库设计说明书、用户手册以及修订测试计划。

4) 评审

对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计方法的可行性，关键的处理及内外部接口定义的正确性、有效性、各部分之间的一致性等都-一进行评审。

5.4.2 详细设计

对每个模块进行详细的算法设计，用某种图形、表格和语言等工具将每个模块处理过程的详细算法描述出来。
对模块内的数据结构进行设计。
对数据库进行物理设计，即确定数据库的物理结构。
其他设计。a)代码设计：提高数据的输入、分类、存储和检索等操作，节约内存空间，对数据库中某些数据项的值要进行代码设计。b)输入/输出格式设计 c)用户界面设计。
编写详细设计说明书。
评审处理过程的算法和数据库的物理结构。

例题

1. 系统设计是根据系统分析的结果，完成系统的构建过程。系统设计的主要内容包括( )；系统总体结构设计的主要任务是将系统的功能需求分配给软件模块，确定每个模块的功能和调用关系，形成软件的( )
A.概要设计和详细设计 B.架构设计和对象设计 C.部署设计和用例设计 D.功能设计和模块设计
A.用例图 B.模块结构图 C.系统部署图 D.类图

答案： A，B

以下关于软件系统模块结构设计的叙述中，正确的是()

A.当模块扇出过大时，应把下级模块进一步分解为若干个子模块

B.当模块扇出过小时，应适当增加中间的控制模块

C.模块的扇入大，表示模块的复杂度较高

D.模块的扇入大，表示模块的复用程度高

解析：

一个模块的扇出是指该模块直接调用的下级模块的个数，扇出大表示模块的复杂度高，需要控制和协调过多的下级模块。扇出过大一般是因为缺乏中间层次，应当适当增加中间层次的控制模块；扇出过小时可以把下级模块进一步分解成若干个子功能模块，或者合并到它的上级模块中去。一个模块的扇入是指直接调用该模块的上级模块的个数。扇入大表示模块的复用程度高。

设计良好的软件结构通常顶层扇出比较大，中间扇出比较小，底层模块则有大扇入。

5.6 运行和维护知识

5.6.1 系统转换

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

直接转换：在确定新系统运行无误时立刻启用新系统，终止旧系统运行，风险大。节省人员、设备费用。一般适用于一些处理过程不太复杂、数据不太重要的场合。
并行转换：新旧系统并行工作一段时间，经过一段时间的考验以后，新系统正式替代旧系统，风险较小。它的主要特点是安全、可靠，但费用和工作量都很大，因为在相当长的时间内系统要新、旧两套并行工作。对于较复杂的大型系统，它提供了一个与旧系统运行结果进行比较的机会，可以对新旧两个系统的时间要求、出错次数和工作效率给予公正的评价。
分段转换：分期分批逐步转换，是直接和并行转换的集合，将大型系统分为多个子系统，依次试运行每个字系统，成熟一个子系统就转换一个子系统。同样适用于大型项目，只是更耗时，而且现有系统和新系统间混合使用，需要协调好接口等问题。

数据转换与迁移：将数据从旧数据库迁移到新数据库中。有三种方法:系统切换前通过工具迁移、系统切换前采用手工录入、系统切换后通过新系统生成。

5.6.2 系统维护概述

系统可维护性概念

系统的可维护性可以定义为维护人员理解、改正和改进这个软件的难易程度，可维护性是所有软件都应具有的基本特点，必须在开发阶段和其他软件工程阶段保证软件具有可维护的特点。其评价指标如下：

可理解性。指别人能理解系统的结构、界面、功能和内部过程的难易程度。模块化、详细设计文档、结构化设计和良好的高级程序设计语言等都有助于提高可理解性。
可测试性。诊断和测试的容易程度取决于易理解的程度。为此，开发人员在系统设计和编程阶段就应尽力把程序设计成易诊断和测试的。此外，在进行系统维护时，应该充分利用在系统测试阶段保存下来的测试用例。
可修改性。诊断和测试的容易程度与系统设计所制定的设计原则有直接关系。模块的耦合、内聚、作用范围与控制范围的关系等都对可修改性有影响。

系统维护的内容及类型

系统维护主要包括硬件维护、软件维护和数据维护。

软件维护：根据需求变化或硬件环境的变化对应用程序进行部分或全部修改，其包含内容如下:

正确性维护：是指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。
适应性维护：是指使应用软件适应信息技术变化和管理需求变化而进行的修改。
完善性维护：是指对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。
预防性维护：为了改进应用软件的可靠性和可维护性，为了适应未来的软/硬件环境的变化，应主动增加预防性的新的功能，以使应用系统适应各类变化而不被淘汰。

5.6.3 系统维护

按评价的时间与信息系统所处的阶段的关系又可从总体上把广义的信息系统评价分为以下三种：

立项评价：指信息系统方案在系统开发前的预评价，即系统规划阶段中的可行性研究。
中期评价：项目开发中期每个阶段的阶段评审，或者项目在开发中途遇到重大变故，评价是否还要继续。
结项评价：系统投入正式运行后，了解系统是否达到预期的目的和要求而对系统进行的综合评价。

系统评价的指标

从信息系统的组成部分出发，信息系统是一个由人机共同组成的系统，所以可以按照运行效果和用户需求（人）、系统质量和技术条件（机）这两条线索构造指标。
从信息系统的评价对象出发，对于开发方来说，他们所关心的是系统质量和技术水平; 对于用户方而言，关心的是用户需求和运行质量；系统外部环境则主要通过社会效益指标来反映。
从经济学角度出发，分别按系统成本、系统效益和财务指标3条线索建立指标。

5.8 软件质量

5.8.1 软件质量特性

软件质量管理：对软件开发过程进行独立的检查活动，主要由质量保证、质量规划和质量控制构成。

软件质量保证：是指为保证软件系统或软件产品充分满足用户要求的质量而进行的有计划、有组织的活动其目的是生产高质量的软件

软件质量模型：SO/EC9126 软件质量模型， McCal软件质量模型

ISO/IEC 9126软件质量模型

由三个层次组成：第一层为质量特性，第二层是质量子特性，第三层是度量指标。

出题形式：选择。给某一个质量特性的描述，判断此特性/此特性的子特性。

例题

1. 【2019年】在ISO/IEC 9126软件质量模型中，软件质量特性()包含质量子特性安全性
(A)功能性 (B)可靠性 (C)效率 (D)可维护性

答案：A

【2018年】在ISO/IEC 9126软件质量模型中，可靠性质量特性是指在规定的一段时间内和规定的条件下，软件维持在其性能水平有关的能力，其质量子特性不包括()
(A)安全性 (B)成熟性 (C)容错性 (D)易恢复性

答案：A

【2019年】从减少成本和缩短研发周期考虑，要求嵌入式操作系统能运行在不同的微处理器平台上，能针对硬件变化进行结构与功能上的配置。该要求体现了嵌入式操作系统的()
(A)可定制性（B）实时性（C) 可靠性（D)易移植性

答案：A

Mc Call 软件模型质量

5.8.2 软件质量保证

软件质量保证是软件质量管理的重要组成部分。软件质量保证主要是从软件产品的过程规范性角度来保证软件的品质，主要活动包括：质量审计（包括软件评审）和过程分析。

3个要点

满足用户需求
遵循开发准则
满足某些隐含需求（e.g. 可理解性，可维护性，未明确写在需求中）

7个任务

应用技术方法:把软件质量设计到产品中而非事后保证
正式的技术评审
测试软件
标准的实施:遵循标准
控制变更
度量：收集软件度量
记录保存和报告

5.8.3 软件评审

两个必要

设计质量：设计规格说明书符合用户要求。
程序质量：程序按照设计规格说明所规定的情况正确执行。

设计质量的评审：对象是在需求分析阶段产生的软件需求规格说明、格说明，以及在软件概要设计阶段产生的软件概要设计说明书等。

程序质量的评审：从开发者的角度进行评审，与开发技术直接相关。它是着眼于软件本身的结构、与运行环境的接口以及变更带来的影响而进行的评审活动。

5.8.4 软件容错技术

容错软件4种定义：

在一定程度上，

对自身错误的作用具有屏蔽能力
从错误状态自动恢复到正常状态
在错误发生时完成预期功能
具有容错能力

容错的一般方法

冗余：对于实现系统规定功能来说是多余的资源。

加入冗余，可能使系统的可靠性提高。

4种主要冗余

结构冗余
信息冗余
时间冗余
冗余附加技术

（1）结构冗余：通过在系统中添加额外的便件或饮件来提高系统的可靠性和容错能力。分为静态、动态和混合冗余三种类型。

静态冗余：在系统中添加多个相同的组件，通过表决和比较来选择正确的输出。例如，在航空航天领域中，多个发动机可以通过表决和比较来确保系统的可靠性。
动态冗余：在系统中添加多个相同的组件，但是只有一个组件在工作，其他组件处于待机状态。当工作组件发生故障时，备用组件会立即接管工作。例如，在服务器领域中，多个硬盘可以通过RAID 技术实现动态冗余，以提高数据的可靠性。
混合冗余：将静态和动态冗余技术结合起来使用。例如，在核电站中，反应堆控制系统可以采用混合几余技术，以确保系统的可靠性

（2）信息冗余：通过在数据中添加额外的信息来提高数据的检错和纠错能力。这种冗余通常采用校验码原理，即通过对数据进行某种运算来生成校验码，并将校验码附加到数据中。当数据传输或存储时，如果校验码与数据不匹配，则说明数据可能发生了错误。

校验码原理:校验码原理是指通过对数据进行某种运算来生成校验码，并将校验码附加到数据中。常见的校验码：循环冗余校验码(CRC)、汉明码等。例如，在 USB 接口中，数据传输时会使用 CRC 校验码来检测数据是否发生了错误。

（3）时间冗余：通过额外的时间延迟来提高系统的容错能力。通常采用重复执行的方式，即当系统出现错误时，会重复执行相同的操作，直到操作成功为止。如果重复执行多次仍然失败，则说明系统可能出现了严重的故障。

重复执行：当系统出现错误时，会重复执行相同的操作，直到操作成功为止。例如在计算机系统中，当硬盘读取数据时出现错误时，操作系统会尝试多次读取数据，直到读取成功为止。
回滚：当系统出现错误时，会将系统状态恢复到之前的某个时间点，以避免错误的影响，例如，在数据库系统中，如果某个事务执行失败，可以使用回滚操作将数据库状态恢复到事务开始之前的状态。

（4）冗余附加技术：为实现结构、信息和时间冗余技术所需的资源和技术，包括程序、指令、数据、存放和调动它们的空间和通道等。

5.9 软件度量

外部属性：面向管理者和用户，可直接测量，一般为性能指标（成本、效益、开发人员生产率）

内部属性：软件产品或软件过程本身的属性。

软件度量有两种分类方法:

面向规模的度量、面向功能的度量和面向人的度量
生产率度量、质量度量和技术度量

软件复杂度的度量方法：McCabe度量法，又称为环路复杂度，假设有向图中有向边数为m,节点数为n，则此有向图的环路复杂度为m-n+2
注意m和n代表的含义不能混淆，可以用一个最简单的环路来做特殊值记忆此公式，另外，针对一个程序流程图，每一个分支边(连线)就是一条有向边，每一条语句(语句框)就是一个顶点。

还有一种更加简单的算法：封闭空间数量+1

例题：采用McCabe度量法计算下图的环路复杂性为（）

解析：8个有入度的带箭头的边，6个节点，因此环路复杂度为8-6+2 = 4；3个封闭空间，复杂度为3 + 1 = 4

解析：13个边，11个节点，复杂度为4；有3个封闭空间，复杂度为3 + 1 = 4。

项目管理

范围管理

在进行项目计划之前，应该首先进行项目定义，也就是定义项目范围，其中包括建立产品的目的和范围、可选的解决方案、技术或管理的约束等。

范围管理是确定在项目内要干什么和不干什么，当然由此界定的项目范围在项目的全生命周期内可能因种种原因而变化，项目范围管理也要管理项目范围的这种变化。

产品范围和项目范围

产品范围：产品或者服务所应该包含的功能。产品范围是否完成，要根据产品是否满足了产品描述来判断。产品范围描述是项目范围说明书的重要组成部分，因此，产品范围变更后，首先受到影响的是项目的范围。
项目范围是指为了能够交付产品，项目所必须做的工作。项目范围的定义是产生项目管理计划的基础。判断项目范围是否完成，要以范围基准来衡量。项目的范围基准是经过批准的项目范围说明书、WBS和WBS词典。

项目范围的管理过程：

规划范围管理（编制范围管理计划）。对如何定义、确认和控制项目范围的过程进行描述。
定义范围 。详细描述产品范围和项目范围，编制项目范围说明书，作为以后项目决策的基础，其输入包括：项目章程、项目包范围管理计划、组织过程资产、批准的变更申请。
创建工作分解结构(WBS)。将项目整体或者主要的可交付成果分解成容易管理、方便控制的若干个子项目或工作包，子项目继续分解为工作包，这些工作包的综合是项目的所有工作范围。形成一个自上而下的分解结构。定义项目边界，有助于防止需求蔓延。
确认范围。正式验收已完成的可交付成果。
范围控制。监督项目和产品的范围状态、管理范围基准变更。

WBS如下表所示：

进度管理

进度管理：采用科学的方法，确定进度目标，编制进度计划和资源供应计划，进行进度控制，在与质量、成本目标协调的基础上，实现工期目标。

进度管理基本原则:

划分：项目必须被划分成若干可以管理的活动和任务。
相互依赖性：划分后的各个活动或任务之间的相互依赖关系必须是明确的，
时间分配：必须为每个被调度的任务分配一定数量的工作单位（如若于人天的工作量）。
工作量确认：每个项目都有预定数量的人员参与。
确定责任：安排了进度计划的每个任务都应该指定特定的团队成员来负责，
明确输出结果：安排了进度计划的每个任务都应该有一个明确的输出结果。
确定里程碑：每个任务或任务组都应该与一个项目里程碑相关联。

进度管理过程

活动定义：确定完成项目各项可交付成果而需要开展的具体活动。
活动排序：识别和记录各项活动之间的先后关系和逻辑关系。
活动资源估算：估算完成各项活动所需要的资源类型和效益。
活动历时估算：估算完成各项活动所需要的具体时间。
进度计划编制：分析活动顺序、活动持续时间、资源要求和进度制约因素制订进度计划。
进度控制：根据进度计划开展项目活动，如果发现偏差，则分析原因或进行调整。

活动资源估算方法

自下而上。把复杂活动分解为更小的工作，以便于资源估算。
自顶而下。参照以前完成的项目所耗费的总成本（或总工作量）来推算。
差别估算。将待开发项目与一个或多个已完成的类似项目进行比较。
专家判断。项目专家对以往类似项目和对本项目的判断。
替换方案确定。
公开的估算数据。有些公司定期公开一些生产率或人工费率数据。
估算软件。

COCOMO模型：常见软件规模估算方法。以代码行估算每个程序员工作量、累加的软件成本。按其详细程度可以分为三级：

基本COCOMO模型：静态单变量模型，用一个已估算出来的原代码行数（LOC）为自变量的经验函数计算软件开发工作量。 $E = a (KLOC)^b$ ，其中KLOC为目标代码行数，E是工作量。开发时间为 $D = c * E^d$
中间COCOMO模型：静态多变量模型，在基本COCOMO模型的基础上，再用设计产品、硬件、人员、项目15种影响软件工作量的因素调整工作量的估算。 $E = a (KLOC)^b EAF$ ，其中EAF是影响因子
详细COCOMO模型：包括中间COCOMO模型的所有特性，将团建系统模型分为系统、子系统和模块3个层次，更进一步考虑了软件工程中每一步骤（如分析、设计）的影响。

COCOMOⅡ模型：以软件规模作为成本的主要因素，考虑多个成本驱动因子。包括三个阶段性模型，应用组装模型、早期设计阶段模型和体系结构阶段模型。包含三种不同规模估算选择：对象点、功能点和代码行。

进度安排的常用图形描述方法

Gantt图：体现任务历时和并行性。

项目计划评审技术（PERT）：体现任务之间的依赖性。

关键路径法

关键路径：项目的最短工期，从开始到结束时间最长的路径。进度网络图中可能有多条关键路径。因为活动会变化，关键路径也在不断变化中。

关键活动：关键路径上的活动，最早开始时间 = 最晚开始时间。

通常，每个节点的活动会有如下几个时间：

最早开始时间（ES）某项活动能够开始的最早时间。
最早结束时间（EF）某项活动能够完成的最早时间。EF=ES+工期
最迟结束时间（LF）为了使项目按时完成，某项活动必须完成的最迟时间。
最迟开始时间（LS）为了使项目按时完成，某项活动必须开始的最迟时间。LS=LF-工期。

这几个时间通常作为每个节点的组成部分，如图所示

顺推：最早开始ES = 所有前置活动最早完成EF的最大值；最早完成EF=最早开始ES+持续时间

逆推：最晚完成LF=所有后续活动最晚开始的最小值；最晚开始LS=最晚完成LF-持续时间。

总浮动时间：在不延误项目完工时间且不违反进度制约因素的前提下，活动可以从最早开始时间推迟或拖延的时间量，就是该活动的进度灵活性。正常情况下，关键活动的总浮动时间为零。

总浮动时间 = 最迟开始LS - 最早开始ES 或最迟完成LF-最早完成EF 或关键路径-非关键路径时长。

自由浮动时间 : 是指在不延误任何今后活动的最早开始时间且不违反进度制约因素的前提下，活动可以从最早开始时间推迟或拖延的时间量。

自由浮动时间 = 今后活动最早开始时间的最小值-本活动的最早完成时间

例题进度安排的常用图形描述方法有Gantt图和PERT图。Gantt图不能清晰地描述 (1 )；PERT图可以给出哪些任务完成后才能开始另一些任务。下图所示的PERT图中，事件6的最晚开始时刻是（2）。
A.每个任务从何时开始   B.每个任务到何时结束
C.每个任务的进展情况   D.各任务之间的依赖关系
A.0    B.3 C.10 D.11

答案：

（1）D

（2）找出关键路径，求最短工期：2+2+5+6 = 15；确定事件6以后的工作需要多长时间：1+4 = 5。事件6最晚开始时间 = 最短工期-之后需要的时间 = 10。选C。

成本管理

陈本管理包括：

成本估算：估算方法包括自顶而下的估算、自底而上的估算和差别估算法，以及专家估算、类推估算、算式估算。
成本预算：把估算的总成本分配到项目的各个工作包，简历成本基准计划以衡量绩效。应急储备和管理储备。
成本控制：保证各项工作再各自的预算范围内进行。

成本类型：

可变成本：随着生产量、工作量或时间而变的成本为可变成本。可变成本又称变动成本。
固定成本：不随生产量、工作量或时间的变化而变化的非重复成本为固定成本。
直接成本：直接可以归属于项目工作的成本。如项目团队差旅费、工资、项目使用的物料及设备使用费等
间接成本：来自一般管理费用科目或几个项目共同担负的项目成本所分摊给本项目的费用。如税金，额外福利和保卫费用等。
机会成本：是利用一定的时间或资源生产一种商品时，而失去的利用这些资源生产其他最佳替代品的机会。泛指一切在做出选择后其中一个最大的损失。
沉没成本：是指由于过去的决策已经发生了的，而不能由现在或将来的任何决策改变的成本。沉没成本是一种历史成本，对现有决策而言是不可控成本，会很大程度上影响人们的行为方式与决策，在投资决策时应排除沉没成本的干扰。

学习曲线：重复生成产品时，产品的单位会随着产量的扩大呈现规律性递减。估算成本时，也要考虑此因素。

软件配置管理

用于整个软件工程过程。

主要目标：标识变更、控制变更、确保变更正确地实现，报告有关变更。

SCM：一组管理整个软件生存周期中各阶段变更的活动，在系统的整个生命周期中维持配置的完整性和可跟踪性

配置项：GB/T11457-2006对配置项的定义为："为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待”。

以下内容都可以作为配置项进行管理：外部交付的软件产品和数据、指定的内部软件工作产品和数据、指定的用于创建或支持软件产品的支持工具供方/供应商提供的软件和客户提供的设备/软件

典型配置项：项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入配置管理。

每个配置项的主要属性有 : 名称、标识符、文件状态、版本、作者、日期等

配置项可以分为基线配置项和非基线配置项两类。基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包项目的各类计划和报告等。

所有配置项的操作权限应由CMO(配置管理员)严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向PM、CCB及相关人员开放。

配置项的状态可分为"草稿"，"正式"和"修改"三种。配置项刚建立时，其状态为"草稿"。配置项通过评审后，其状态变为"正式"。此后若更改配置项则其状态变为"修改"。当配置项修改完毕并重新通过评审时，其状态又变为"正式":

配置项版本号

处于“草稿”状态的配置项的版本号格式为0.Y.Z，YZ的数字范围为01~99 。随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。
处于"正式"状态的配置项的版本号格式为X.Y，X为主版本号，取值范围为1~9。Y为次版本号，取值范围为0~9。配置项第一次成为"正式"文件时，版本号为1.0。如果配置项升级幅度比较小，可以将变动部分制作成配置项的附件，附件版本依次为 1.0，1.1,….当附件的变动积累到一定程度时，配置项的Y值可适量增加，Y值增加一定程度时，X值将适量增加。当配置项升级幅度比较大时，才允许直接增大X值。
处于"修改"状态的配置项的版本号格式为X.Y.Z。配置项正在修改时，一般只增大Z值。X，Y值保持不变。当配置项修改完毕，状态成为正式时，将Z值设置为0，增加XY值。参见上述规则(2)

配置项版本管理：在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”，所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。

配置基线（常简称为基线）由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项被"冻结"不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。

基线通常对应于开发过程中的里程碑，一个产品可以有一个或多个基线。交付给外部顾客的基线一般称为发行基线(Release)，内部开发使用的基线一般称为构造基线(Build)

一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。

对于每一个基线，要定义下列内容：建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。在项目实施过程中，每个基线都要纳入配置控制，对这些基线的更新只能采用正式的变更控制程序。

建立基线还可以有如下好处:

基线为开发工作提供了一个定点和快照。（出了问题，回到基线，重新查找问题即可）。
包新项目可以在基线提供的定点上建立。新项目作为一个单独分支，将与随后对原始项目（在主要分支上）所进行的变更进行隔离。
当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法（回退）。
可以利用基线重新建立基于某个特定发布版本的配置，以重现已报告的错误。

配置数据库：存放配置项并记录与配置项相关的所有信息，时配置管理的有力工具。主要作用：

记录与配置相关的所有信息，其中存放受控的软件配置项是很重要的内容。
利用库中的信息评价变更的后果，这对变更控制有着重要的意义。
从库中可提取各种配置管理过程的管理信息。

使用配置库可以帮助配置管理员把信息系统开发过程的各种工作产品包括半成品或阶段产品和最终产品管理得并并有条，使其不致管乱、管混、管丟。如Git

配置数据库可以分开发库、受控库、产品库3种类型。

开发库，也称为动态库、程序员或工作库，用于保存开发人员当前正在开发的配置实体，如 :新模块、文档、数据元素或进行修改的已有元素。动态中的配置项被置于版本管理之下。是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无需对其进行配置控制，因为这通常不会影响到项目的其他部分。可以任意的修改。
受控库，也称为主库，包含当前的基线加上对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。可以修改，需要走变更流程。
产品库，也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。一般不再修改，真要修改的话需要走变更流程。

例题项目配置管理中，产品配置是指一个产品在其生命周期各个阶段产生的各种形式和各种版本的文档、计算机程序、部件及数据的集合。该集合中的每一个元素称为改产品配置中的一个配置项，（）不属于产品组成部分工作成果的配置项。

A. 需求文档 B. 设计文档 C. 工作计划 D. 源代码

解析：选C。配置项是构成产品配置的主要元素，配置项主要有以下两大类：（1）属于产品组成部分的工作成果：如需求文档、设计文档、源代码和测试用例等；（2）属于项目管理和机构支撑过程域产生的文档：如工作计划、项目质量报告和项目跟踪报告等。

软件质量是指反映软件系统或软件产品满足规定或隐含需求的能力的特征和特性全体。软件质量管理是指确定质量方针、目标和职责并通过质量体系中的质量计划、质量控制、质量保证和质量改进来使其实现的所有管理职能的全部活动;
软件质量管理主要包括以下过程:

质量规划：识别项目及其产品的质量要求和标准，并书面描述项目将如何达到这些要求和标准的过程。
质量保证：一般是每隔一定时间(例如，每个阶段未)进行的，主要通过系统的质量审计(软件评审)和过程分析来保证项目的质量。
质量控制：实时监控项目的具体结果，以判断它们是否符合相关质量标准，制订有效方案，以消除产生质量问题的原因。

风险管理

风险管理：对项目风险进行认真的分析和科学的管理，能够避开不利条件、少受损失、取得预期的结果并实现项目目标的，能够争取避免风险的发生或尽量减小风险发生后的影响。但是，完全避开或消除风险，或者只享受权益而不承担风险是不可能的。

风险识别：识别出项目中已知和可预测的风险，确定风险的来源、产生的条件、描述风险的特征以及哪些项目可以产生风险形成一个风险条目检查表。

风险定性分析：对已经识别的风险进行排序，确定风险可能性与影响、确定风险优先级、确定风险类型。

风险定量分析：进一步了解风险发生的可能性具体有多大，后果具体由多严重。包括灵敏度分析、期望货币价值分析、决策树分析、蒙特卡罗模拟。

风险应对计划编制：对每一个识别出来的风险来分别制定应对措施，这些措施组成的文档称为风险应对计划。包括消极风险(避免策略、转移策略、减轻策略) 和积极风险（开拓、分享、强大）。

风险监控: 监控风险计划的执行，检测残余风险，识别新的风险，保证风险计划的执行，并评价这些计划对减少风险的有效性

从宏观上来看，风险可以分为项目风险、技术风险和商业风险，

项目风险是指潜在的预算、进度、个人(包括人员和组织)、资源、用中和需求方面的问题以及它们对项目的影响。项目复杂性、规模和结构的不确定性也构成项目的(估算)风险因素。项目风险威胁到项目计划，一旦项目风险成为现实，可能会拖延项目进度，增加项目的成本。
技术风险是指潜在的设计、实现、接口、测试和维护方面的问题。此外，规格说明的多义性、技术上的不确定性、技术陈旧、最新技术(不成熟)也是风险因素。技术风险威胁到待开发系统的质量和预定的交付时间。如果技术风险成为现实，开发工作可能会变得很困难或根本不可能。
商业风险威胁到待开发系统的生存能力，主要有以下5种不同的商业风险：1.市场风险：开发的系统虽然很优秀但不是市场真正所想要的。2.策略风险：开发的系统不再符合企业的信息系统战略。3.销售风险：开发了销售部门不清楚如何推销的系统。4.管理风险：由于重点转移或人员变动而失去上级管理部门的支持。6预算风险：开发过程没有得到预算或人员的保证。

项目风险：作用于项目上的不确定的事件或条件，既可能产生威胁，也可能带来机会。

通过积极和合理的规划，超过90%的风险都可以进行提前应对和管理。
风险应该尽早识别出来，高层次风险应记录在章程里
应由对风险最有控制力的一方承担相应的风险。
承担风险程度与所得回报相匹配原则，承担的风险要有上限。

风险的属性:

随机性：风险事件发生及其后果都具有偶然性(双重偶然)，遵循一定的统计规律。
相对性：风险是相对项目活动主体而言的。承受力不同，影响不同。风险承受力影响因素：收益大小（收益越大，越愿意承担风险; 投入大小（投入越大，承受能力越小）;主体的地位和资源(级别高的人能承担较大的风险)。
可变性：条件变化，会引起风险变化。包括性质、后果的变化，以及出现新风险。

风险的分类

按后果的不同：纯粹风险（无任何收益）和投机风险（可能带来收益）
按风险来源：自然风险(天灾)和人为风险(人的活动，又可分为行为风险、经济风险、技术风险、政治和组织风险等)。
按是否可管理：可管理(如内部多数风险)和不可管理(如外部政策)，也要看主体管理水平。
按影响范围划分，局部风险(非关键路径活动延误)和总体风险(关键路径活动延误)
按后果承担者划分 :业主、政府、承包商、投资方、设计单位、监理单位、保险公司等。
按可预测性：已知风险（已知的进度风险）、可预测风险(可能服务器故障)、不可预测风险（地震、洪水、政策）。

组织管理

组织结构模式：项目型（项目经理绝对领导）、职能型（部门领导为主）、矩阵型（二者结合，权力分割不同）

程序设计小组的组织方式

主程序员制小组：主程序员全权负责，后援工程师必要时能替代主程序员，适合大规模项目。
民主制小组：成员之间地位平等，任何决策都是全员参与投票，适合于项目规模小，开发人员少采用新技术和确定性较小的项目。
层次式小组：两个层次，一名组长领导若干个高级程序员，每个高级程序员领导若干个程序员)。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/酷酷是懒虫/article/detail/900386

软件设计师备考 | 第五章 软件工程基础知识_软件设计历史文档集索引表

5.1 软件工程概述

5.1.2 软件工程基本原理

5.1.3 软件生存周期

1. 可行性分析与项目开发计划

2. 项目开发计划需求分析

3. 概要设计

4. 详细设计

5. 编码

6. 测试

7. 维护

5.1.4 软件过程

能力成熟度模型（CMM）

能力成熟度模型集成（CMMI）

5.2 软件过程模型

5.2.1 瀑布模型（Waterfall Model）

瀑布模型变种——V模型

5.2.2 增量模型（Incremental Model）

5.2.3 演化模型

原型模型（Prototype Model）

螺旋模型

5.2.4 喷泉模型

5.2.5 基于构件的开发模型 （Component-based Development Model）

5.2.6 形式化方法模型

5.2.7 统一过程模型（UP）

5.2.8 敏捷方法（Agile Development）

极限编程（XP）

软件过程模型概述

5.3 需求分析

5.3.1 软件需求

软件需求的分类

5.3.2 需求分析原则

5.3.3 需求工程

1. 需求获取

2. 需求分析

3. 系统建模

4. 需求规约

5. 需求验证（需求确认）

6. 需求管理

需求跟踪

状态跟踪

变更控制

版本控制

5.4 系统设计

5.4.1 概要设计

1）设计软件系统总体结构

2）数据结构即数据库设计

3) 编写概要设计文档

4) 评 审

5.4.2 详细设计

5.6 运行和维护知识

5.6.1 系统转换

5.6.2 系统维护概述

系统可维护性概念

系统维护的内容及类型

5.6.3 系统维护

5.8 软件质量

5.8.1 软件质量特性

ISO/IEC 9126软件质量模型

Mc Call 软件模型质量

5.8.2 软件质量保证

3个要点

7个任务

5.8.3 软件评审

5.8.4 软件容错技术

容错软件4种定义：

容错的一般方法

5.9 软件度量

项目管理

范围管理

进度管理

成本管理

软件配置管理

风险管理

组织管理

软件设计师备考 | 第五章软件工程基础知识_软件设计历史文档集索引表

5.2.5 基于构件的开发模型（Component-based Development Model）

4) 评审