Shuyx Blog

简体中文

English

简体中文

English

日夜模式

🗂️ 文章分类： 考试  
🏷️ 文章标签： 软考  
📝 文章创建时间： 2025-03-31
🔥 文章最后更新时间：2025-10-26

[toc]

软件设计师笔记05_软件工程基础_精简考点 ​

科目一考试中占2-5分左右。

ruankao_2025-11-05_160927_874.png

软件工程概述 ​

  • 软件工程的基本要素：方法、工具、过程。

软件生存周期 ​

一个软件产品或软件系统要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为软件生存周期。

软件生存周期包括以下七个方面：

  1. 可行性分析与项目开发计划。这个阶段主要确定软件的开发目标及其可行性。参与该阶段的人员有用户、项目负责人、系统分析师。产生的文档有可行性分析报告、项目开发计划。
  2. 需求分析。该阶段的任务不是具体的解决问题，而是要确定软件系统要做什么，确定软件系统的功能、性能、数据和界面等要求，从而确定系统的逻辑模型。参与该阶段的人员有用户、项目负责人、系统分析师。产生的文档主要是软件需求说明书。
  3. 概要设计。该阶段开发人员把确定的各项功能需求转换成需要的体系结构。概要设计就是设计软件的结构，明确软件由哪些模块组成，这些模块层次结构是怎样的，调用关系是怎样的，每个模块的功能是什么。参与该阶段的人员有系统分析师、软件设计师。产生的文档主要是概要设计说明书。
  4. 详细设计。该阶段的主要任务是对每个模块的功能进一步详细、具体的描述。参与该阶段的人员有软件设计师、程序员。产生的文档主要是详细设计文档。
  5. 编码。把每个模块的控制结构转换成计算机可接受的程序代码，即写成某种特定程序设计语言表示的源程序清单。
  6. 测试。测试是保证软件质量的重要手段。参加测试的人员通常是另一部门（或单位）的软件设计师或系统分析师。产生的文档主要是软件测试计划、测试用例、测试报告。
  7. 维护。软件维护是软件生存周期中时间最长的阶段。软件已交付且正式投入使用后，便进入维护阶段。对软件进行修改的原因包括：①运行中发现隐含的错误而需要修改；②为了适应变化的（或变化后的）工作环境而修改；③需要对软件功能进行扩充、增强而进行的修改；④为将来软件维护活动做预先准备。

能力成熟度模型（CMM） ​

能力成熟度模型（CMM） 是对软件组织进化阶段的描述，随着软件组织定义、实施、测量、控制和改进其软件过程，软件组织的能力经过这些阶段逐步提高。

通过该能力成熟度模型可以较容易地确定软件过程的成熟度并识别其软件过程执行中的薄弱环节，确定对软件质量和过程改进最为关键的几个问题，从而形成对其过程的改进策略。

能力成熟度模型（CMM）将软件过程的改进分为五个成熟度级别。

ruankao_20250512160548.png

速记

  • 初始级：制度缺乏，混乱无序，依赖个人管理。
  • 可重复：建立基本管理制度。
  • 已定义：文档化，标准化。
  • 已管理：有对应的测量指标。
  • 优化级：基于工具，持续改进软件过程，质量稳步改进。

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

CMMI 是若干过程模型的综合和改进，是支持多个工程学科和领域的、系统的、一致的过程改进框架，能适应现代工程的特点和需要，能提高过程的质量和工作效率。

CMMI 提供了两种表示方法：阶段式模型和连续式模型。

  1. 阶段式模型。结构类似于 CMM，它关注组织的成熟度。
  2. 连续式模型。关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力等级（简称 CL）。

CMMI 中包括六个过程域能力等级。

  • CL0（未完成的）：过程域未执行或未得到CL1中定义的所有目标。
  • CL1（已执行的）：其共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标。
  • CL2（已管理的）：其共性目标是集中于已管理的过程的制度化。所有工作任务和工作产品都被监控、控制、和评审。
  • CL3（已定义级的）：其共性目标集中于已定义的过程的制度化。过程是按照组织的裁剪指南从组织的标准过程中裁剪得到的，还必须收集过程资产和过程的度量，并用于将来对过程的改进。
  • CL4（定量管理的）：其共性目标集中于可定量管理的过程的制度化。使用测量和质量保证来控制和改进过程域，建立和使用关于质量和过程执行的质量目标作为管理准则。
  • CL5（优化的）：使用量化（统计学）手段改变和优化过程域，以满足客户的改变和持续改进计划中的过程域的功效。

软件开发方法 ​

  • 原型化开发方法：适合需求不清晰，需求变化大且规模不太大时采用。
  • 结构化开发方法：适合需求明确或需求变化不大。
  • 面向对象开发方法：更好的复用性，关键在于建立一个全面、合理、统一的模型，分析、设计、实现三个阶段界限不明确。

软件过程模型 ​

典型的软件过程有瀑布模型、增量模型、演化模型（原型模型、螺旋模型）、喷泉模型、基于构件的开发模型和形式化方法模型等。

瀑布模型 ​

瀑布模型的开发流程如同瀑布一般，一步一步的走下去，直到最后完成项目开发。

瀑布模型包括需求分析、设计、编码、测试、运行与维护共5个阶段。

如图所示 ruankao_20241022153258.png

  • 瀑布模型的优点：容易理解、成本低、强调开发的阶段性早期计划及需求调查和产品测试
  • 瀑布模型的缺点：只适用于需求明确或者二次开发(需求稳定)，当需求不明确时，最终开发的项目容易产生错误，有很大的缺陷。

V 模型 ​

V模型是瀑布模型的一个变体。如图所示。

ruankao_20241022153613.png

V 模型的特点是增加了很多轮测试，并且这些测试贯穿于软件开发的各个阶段，不像其他模型都是软件开发完成后测试，很大程度上保证了项目的准确性。

增量模型 ​

增量模型：首先开发核心模块功能，而后与客户确认。之后再开发次核心模块的功能，即每次开发一部分功能，并与客户需求确认。最终完成项目开发，优先级最高的服务最先交付

增量模型也具有瀑布模型所有的优点。

ruankao_20241022153858.png

  • 增量模型的优点：可交付的第一个增量版本所需要的成本和时间很少，所承担的风险不大。由于很快发布了第一个版本，因此可减少客户需求的变更。
  • 增量模型的缺点：若客户需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发或重新发布；管理发生的成本、进度和配置的复杂性可能会超出组织的能力。

演化模型 ​

在开发过程中，软件开发人员需要一种专门应对不断演变的软件产品的过程模型。而演化模型是迭代的过程模型，特别适用于对软件需求缺乏准确认识的情况。

典型的演化模型有原型模型和螺旋模型等。

原型模型 ​

原型模型：即快速原型开发，原型模型针对的就是需求不明确的情况，首先快速构造一个功能模板，演示给客户看，并按用户要求及时修改，中间再通过不断的演示与客户沟通，最终设计出项目，就不会出现与客户要求不符合的情况，采用的是迭代的思想。

原型模型如图所示。 ruankao_20241022154358.png

螺旋模型 ​

螺旋模型是将瀑布模型和演化模型结合起来，加入了两种模型均忽略的风险分析，弥补了这两种模型的不足。

因此螺旋模型是针对需求不明确的项目，与原型模型类似，但是增加了风险分析，这也是其最大的特点。

螺旋模型强调风险分析，使用户、开发人员对演化层出现的风险有所了解，从而作出反映。因此，螺旋模型适合用于庞大、复杂、高风险的系统。

螺旋模型如图所示。 ruankao_20241022154510.png

螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合，每个螺旋周期分为如下4个工作步骤。

  1. 制订计划：确定软件目标，选定实施方案，明确项目开发的限制条件。
  2. 风险分析：对所选方案进行分析，识别风险，消除风险。
  3. 实施工程：实施软件开发，验证阶段性产品。
  4. 用户评估：评价开发工作，提出修正建议，建立下一个周期的开发计划。

喷泉模型 ​

喷泉模型：是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。使开发过程具有迭代性和无间隙性。

喷泉模型如图所示。 ruankao_20251026213925.png

  • 优点：喷泉模型的各个阶段没有明显的界线，开发人员可以同步进行。其优点是可以提高软件项目的开发效率，节省开发时间。
  • 缺点：这种模型要求严格管理文档，使得审核的难度加大。

各个软件过程模型总结 ​

瀑布模型：需求明确，如同瀑布一般，按阶段一步一步完成。

V模型：瀑布模型的变体。在瀑布模型的各个阶段上添加多轮测试。很大程度上保证了软件的准确性。强调测试贯穿项目始终，而不是集中在测试阶段。是一种测试的开发模型。

增量模型：瀑布模型的变体。先开发核心功能，后开发附加功能。一个增量一个增量的开发。特点是可以很快发布了第一个版本。

演化模型：针对的就是需求不明确的情况。

  • 原型模型：采用快速迭代的思想。只适合小型软件系统的开发。
  • 螺旋模型：在原型模型的基础上加上了风险分析。适合用于庞大、复杂、高风险的系统。

喷泉模型：适合于面向对象的开发方法,可复用。使开发过程具有迭代性和无间隙性。

ruankao_20250513160613.png

统一过程模型 ​

统一过程的四个技术阶段及其产品：

  • （1）起始阶段：专注于项目初创活动。
  • （2）精化阶段：在理解了最初领域范围之后，需要进行需求分析和架构演进。
  • （3）构建阶段：关注系统的构建，产生实现模型。
  • （4）移交阶段：关注软件提交方面的工作，产生软件增量。

敏捷开发 ​

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

敏捷开发方法，包括极限编程（XP）、水晶法（Crystal）、并列争球法（Scrum:）和自适应软件开发（ASD）等。

总结

  • 极限编程XP 是一种轻量级的软件开发方式。由价值观、原则、实践和行为4个部分组成。
  • 水晶法Crystal 认为每一个不同的项目都需要一套不同的策略、约定和方法论。
  • 并列争球法Scrum 使用迭代的方法，并按需求的优先级来实现产品。
  • 敏捷统一过程(AUP)采用“在大型上连续”以及在“在小型上迭代”的原理来构建软件系统。

系统设计 ​

概要设计主要包括:

  • ①软件系统总体结构设计;
  • ②数据结构及数据库设计;
  • ③编写概要设计文档(概要设计说明书、数据库设计说明书、用户手册及修订测试计划);
  • ④评审。

详细设计主要包括:

  • ①对每个模块进行详细设计;
  • ②对模块内部的数据结构进行设计;
  • ③对数据库进行物理设计，即确定数据库的物理结构:
  • ④其他设计(代码设计、输入/输出设计、用户界面设计);
  • ⑤编写详细设计说明书;
  • ⑥评审。

项目活动图 里程碑 ​

真题案例

2018年下半年

某软件项目的活动图如下图所示，其中顶点表示项目里程碑，连接顶点的边表示包含的活动，边上的数字表示活动的持续时间（天），则完成该项目的最少时间为（ ）天。活动FG的松驰时间为（ ）天。

ruankao_20250512143939.png

  • A 20
  • B 37
  • C 38
  • D 46

完成该项目的最少时间由活动图中的最长路径决定。

其中路径 A-D-F-H-J ：10+8+18+10=46 。因此完成该项目的最少时间为46天。

某个活动的松弛时间 = 最长路径的天数 - 包含该活动的最长路径的天数。

活动 FG 所在路径中的最长路径为A-D-F-G-J ，其长度为 10+8+3+7=28 （天）。

完成该项目的最少时间为46天。所以活动 FG 的松弛时间为 46 - 28 = 18 （天）。

真题案例

2023年上半年

下图是一个软件项目的活动图，其中顶点表示项目里程碑，连接顶点的边表示活动，则里程碑（ ）在关键路径上,关键路径长度为（ ）

ruankao_20250512145216.png

  • A B
  • B E
  • C G
  • D I

关键路径就是完成该项目的最长路径，也是完成该项目的最少时间的路径。

如图可知：A-C-E-H-J-K 所在路径是最长路径。该路径完成时间为23天。因此里程碑E在关键路径上。关键路径长度为23

软件测试 ​

  • 白盒测试技术的各种覆盖方法中，（ 语句覆盖 ）具有最弱的错误发现能力。
  • 软件产品的 Alpha 测试和 Beta 测试属于（ 确认测试 ）。

单元测试 ​

单元测试也称模块测试，在模块编写完成且编译无误后进行，侧重于模块中的内部处理逻辑和数据结构。

单元测试环境如图所示。 ruankao_20241022164056.png

集成测试 ​

集成测试就是把模块组合起来进行测试。即使所有的模块都通过了测试，在集成之后，仍然可能出现问题。

另外，单个模块的误差可以接受，但模块组合后，可能会出现误差累积，最后累积到不能接受的程度。

集成测试通常有以下两种方法：

  • （1）非增量集成：分别测试各个模块，再将这些模块组合起来进行整理测试。
  • （2）增量集成：以小增量的方式逐步进行构造和测试。

常用的增量集成策略包括：自顶向下集成测试、自底向上集成测试、回归测试、冒烟测试等

测试方法 ​

软件测试的测试方法分为静态测试和动态测试。

  1. 静态测试：是指被测程序不在机器上运行，采用人工检测和计算机辅助静态分析的手段对程序进行测试，包括人工检测、计算机辅助静态分析。
    • 人工检测：是指通过人工阅读、分析程序代码、设计测试用例等方式，发现程序中的错误和缺陷。
    • 计算机辅助静态分析：是指利用计算机程序对程序代码进行分析，发现程序中的错误和缺陷。
  2. 动态测试：是指通过运行程序发现错误，一般采用黑盒测试和白盒测试。
    • 黑盒测试：也称功能测试，在不考虑软件内部结构和特性的情况下，测试软件的外部特性。
    • 白盒测试：也称结构测试，根据程序的内部结构和逻辑来设计测试用例，对程序的路径和过程进行测试，检查是否满足设计的需要。

黑盒测试 ​

黑盒测试又称功能测试。完全不考虑（或不了解）软件的内部结构和处理算法，它只检查软件功能是否能按照软件需求说明书的要求正常使用。

常用的黑盒测试技术包括等价类划分、边界值分析、错误推测和因果图等。

白盒测试 ​

白盒测试按照程序内部逻辑测试程序，检验程序中每条通路是否按预定要求正确工作。

典型的白盒测试方法包括：静态测试、动态测试。其中静态测试包括：代码检查法、静态结构分析法、静态质量度量法。

语句覆盖测试 和 路径覆盖测试 ​

  • 语句覆盖：语句覆盖是指设计足够的测试用例，使得程序中的每条语句至少被执行一次。语句就是代码。
  • 路径覆盖：路径覆盖是指设计足够的测试用例，覆盖程序中所有可能的判断条件路径。路径就是判断条件。

项目管理 ​

甘特图（Gantt Chart） ​

Gantt图：又称为横道图，横轴表示时间，纵轴表示活动，以时间顺序表示活动，能反应活动间的并行关系，但无法反应活动之间的依赖关系。

ruankao_20251026224902.png

Gantt图能清晰地描述每个任务从何时开始，到何时结束，任务的进展情况以及各个任务之间的并行性。但是它不能清晰地反映出各任务之间的依赖关系，难以确定整个项目的关键所在，也不能反映计划中有潜力的部分。

PERT图 ​

PERT图：类似于前趋图，是有向图，反应活动之间的依赖关系，有向边上标注活动运行的时间，但无法反应活动之间的并行关系

ruankao_20251026225058.png

PERT图不仅给出了每个任务的开始时间、结束时间和完成该任务所需的时间，还给出了任务之间的关系，即哪些任务完成后才能开始另外一些任务，以及如期完成整个工程的关键路径。

图中的松弛时间则反映了完成某些任务时可以推迟其开始时间或延长其所需完成的时间。但是，PERT图不能反映任务之间的并行关系。

软件维护 ​

  • 更正性维护：针对真实存在并已经发生的错误进行的维护行为。
  • 预防性维护：针对真实存在但还未发生的错误进行的维护。
  • 适应性维护：指使应用软件适应信息技术变化和管理需求变化而进行的修改。企业的外部市场环境和管理需求的不断变化也使得各级管理人员不断提出新的信息需求。
  • 完善性维护：扩充功能和改善性能而进行的修改。对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。

软件风险管理 ​

风险的特性：具有不确定性，可能会造成损失。

风险的类别：

  • 项目风险涉及到各种形式的预算、进度、人员、资源以及客户相关的问题，并且可能导致项目损失。
  • 技术风险涉及到技术相关的可能会导致项目损失的问题。
  • 商业风险与市场因素相关。
  • 社会风险涉及到政策、法规等因素。

风险曝光度的公式 = 错误出现率(风险出现率) X 错误造成损失(风险损失)。

软件质量 ​

ISO/IEC9126 软件质量模型 ​

在 ISO/IEC9126软件质量模型 中，软件质量模型由三个层次组成，第一层为质量特性，第二层为质量子特性，第三层为度量指标。

如图所示 ruankao_20250402172124.png

ISO/IEC 9126模型中，基本特性为6个：功能性、可靠性、易使用性、效率、可维护性和可移植性。

  • 功能性：适合性、准确性、互操作性、安全保密性。
  • 可靠性：成熟性、容错性、易恢复性。
  • 易用性：易理解性、易学性、易操作性。
  • 效率：时间特性、资源利用性。
  • 维护性：易分析性、稳定性、易测试性、易改变性。
  • 可移植性：适应性、易安装性、一致性、易替换性。

常考知识点

  • 软件维护的工作量比开发阶段的工作量大
  • 在ISO/IEC软件质量模型中，易使用性的子特性不包括（ 易分析性 ）。
  • 软件可维护性是一个系统在特定的时间间隔内可以正常进行维护活动的概率。用MTTF和MTTR分别表示平均无故障时间和平均故障修复时间，则软件可维护性计算公式为（ 1/(1+MTTR) ）
  • 系统的可维护性指标：可理解性、可测试性和可修改性。

McCabe度量法 ​

  • McCabe环路复杂度。有两种方式求出。
    • 公式法：先将程序的流程图转换为有向图。然后使用公式 V(G)= m - n + 2 。其中 m 是程序图中边的数量，n 是节点数量。
    • 区域法：先数出图中封闭环的个数。环形复杂度等于封闭环个数+1。

真题案例

若采用McCabe度量法计算环路复杂性，则对于下图所示的程序图，其环路复杂度为（ ）。

ruankao_20250514111327.png

考点：McCabe 度量法计算环路复杂度。

解法1 公式法

解题思路：McCabe 度量法计算环路复杂度公式为 (V(G)=e - n + 2) ，其中 e 是程序图中边的数量，n 是节点数量 。

由于图为有向图，因此从图中数出节点数 (n = 9) ，边数 (e = 11) ，代入公式可得 (V(G)=11 - 9 + 2 = 4) 。

解法2 区域法

程序图的环路数等于由程序图中封闭的区域数量加上 1。

如图图中封闭的区域数量为3。因此 环路复杂度 = 3 + 1 = 4

真题案例

对下图所示的程序流程图采用McCabe度量法计算其环路复杂度为（ ）。

ruankao_20250514113816.png

解法1 公式法

先将程序流程图转换为有向图。然后根据公式  V(G)= m - n + 2 。m为边数，m为节点数。得到环路复杂度。

如图  V(G)= 15 - 12 + 2 = 5

解法2 区域法

如图程序流程图的封闭环路数量为 6.因此该图的环路复杂度为6+1=7

真题案例

采用McCabe度量法计算下列程序图的环路复杂性为（）。

ruankao_20250514152906.png

环形度量采用封闭环个数+1的方式进行计算最简单也是最保险的方式。上图可以直接看出存在3个封闭环回路，整个环形复杂度就是3+1 = 4

注意：封闭环个数不计算重叠的。

真题 ​

  • 以下软件产品中，属于图像编辑处理工具的软件是（ Photoshop ）。

  • 某个项目在开发时采用了不成熟的前沿技术，由此而带来的风险属于（ 技术 ）风险。

  • 软件开发过程中，需求分析阶段的输出不包括（ 软件体系结构图 ）。

  • 由8位成员组成的开发团队中，一共有（ 28 ）条沟通路径.

    • 如果是采用有主程序员的沟通方式，只要7条路径。
    • 如果是无主程序员的沟通方式。计算7+6+5+4+3+2+1，结果是28。

  • 软件详细设计阶段的主要任务不包括（ 模块之间的接口设计 ）。

  • 信息系统的文档是开发人员与用户交流的工具。在系统规划和系统分析阶段,用户与系统分析人员交流所使用的文档不包括（ 用户使用手册 ）。

  • 正式技术评审的目标是（ 发现软件中的错误 ）。

  • 以下关于各类文档撰写阶段的叙述中，不正确的是（ 测试计划必须在测试阶段撰写 ）。

  • 下列活动，（ 针对系统特点，考虑并确定系统开发平台与程序设计语言 ）不属于需求开发活动的范畴。

  • 能力成熟度模型集成（CMMI）是若干过程模型的综合和改进。连续式模型和阶段式模型是CMMI提供的两种表示方法，而连续式模型包括6个过程域能力等级，其中（ CL5（优化的） ）使用量化（统计学）手段改变和优化过程域，以应对客户要求的改变和持续改进计划中的过程域的功效。

  • 能力成熟度模型集成(CMMI)是若干过程模型的综合和改进。连续式模型和阶段式模型是CMMI提供的两种表示方法。连续式模型包括6个过程域能力等级( Capability Level,CL)，其中（ CL1(已执行的) ）的共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品,以实现支持过程域的特定目标。

  • 若用户需求不清晰且经常发生变化，但系统规模不太大且不太复杂，则最适宜采用（ 原型化 ）开发方法，对于数据处理领域的问题，若系统规模不太大且不太复杂，需求变化也不大，则最适宜采用（ 结构化 ）开发方法。

  • 统一过程模型是一种“用例和风险驱动，以架构为中心，迭代并且增量”的开 发过程，定义了不同阶段及其制品，其中精化阶段关注（需求分析和架构演进）。

  • 关于螺旋模型，下列陈述中不正确的是（ 可以快速的提供一个初始版本让用户测试 ）。

  • （ 瀑布 ）开发过程模型最不适用于开发初期对软件需求缺乏准确全面认识的情况。

  • 喷泉模型是一种适合于面向（ 对象 ）开发方法的软件过程模型。该过程模型的特点不包括（ 开发活动之间存在明显的界限 ）。

  • 某企业拟开发一个企业信息管理系统，系统功能与多个部门的业务相关。现希望该系统能够尽快投入使用，系统功能可以在使用过程中不断改善。则最适宜采用的软件过程模型为（ 演化（迭代）模型 ）。

  • 以下关于快速原型模型优点的叙述中，不正确是（ 适用于大型软件系统的开发 ）。

  • （ 很容易将客户需求划分为多个增量 ）不是增量式开发的优势。

  • 螺旋模型综合了__瀑布模型和演化模型___的优点，并增加了这两种模型忽略的风险分析。

  • 确定软件的模块划分及模块之间的调用关系是（ 概要设计 ）阶段的任务。

  • 敏捷开发方法Scrum的步骤不包括（ Refactoring ）。

  • 以下关于极限编程(XP) 中结对编程的叙述中，不正确的是（ 编码速度更快 ）。

  • 以下关于极限编程（XP）的最佳实践的叙述中，不正确的是（ 编写完程序之后编写测试代码 ）。

  • 优化模块结构时，（ 使模块功能完整， 消除重复功能，改善软件结构，避免或减少模块之间的病态连接）是适当的处理方法。

  • 在软件开发过程中，系统测试阶段的测试目标来自于（ 需求分析 ）阶段。

  • 白盒测试技术的各种覆盖方法中，（ 语句覆盖 ）具有最弱的错误发现能力。

  • 在设计测试用例时，应遵循（ 不仅要设计有效合理输入，也要包含不合理、失效的输入 ）原则。

  • 在软件系统交付给用户使用后，为了使用户界面更友好，对系统的图形输出进行改进，该行为属于（ 改善性 ）维护。

  • 以下关于软件测试的叙述中，正确的是（ 一个成功的测试能发现至今未发现的错误 ）。

  • 以下关于进度管理工具Gantt图的叙述中，不正确的是 （ 能清晰地确定影响进度的关键任务 ） 。

  • 针对“关键职员在项目未完成时就跳槽”的风险，最不合适的风险管理策略是（ 临时招聘具有相关能力的新职员 ）。

  • 在进行软件开发时，采用无主程序员的开发小组，成员之间相互平等;而主程序员负责制的开发小组，由一个主程序员和若干成员组成，成员之间没有沟通。在一个由8名开发人员构成的小组中，无主程序员组和主程序员组的沟通路径分别是（ 28和7 ）。

    • 无主程序员组的开发小组，每两十开发人员之间都有沟通路径，因此，8人组成的开发小组沟通路径为完全连通无向图的边数，即 7+6+5+4+3+2+1
    • 主程序员组中，除了主程序员外的每个开发人员只能和主程序员沟通，因此8人组成的开发小组的沟通路径8-1=7。

  • 工作量估算模型COCOMO II的层次结构中,估算选择不包括（ 用例数 ）。

软件质量

  • 按照 ISO/IEC 9126 软件质量度量模型定义，一个软件的可靠性的子特性包括（ 容错性和易恢复性 ）。
  • 软件可维护性是一个系统在特定的时间间隔内可以正常进行维护活动的概率。用MTTF和MTTR分别表示平均无故障时间和平均故障修复时间，则软件可维护性计算公式为（ 1/(1+MTTR) ）。
  • 在ISO/IEC软件质量模型中，可移植性是指与软件可从某环境行移到另一环境的能力有关的一组属性，其子特性不包括（ 测试性 ）。
  • 在对程序质量进行评审时，模块结构是一个重要的评审项，评审内容中不包括（ 数据结构 ）。
  • 在ISO/IEC9126软件质量模型中，软件质量特性（ 功能性 ）包含质量子特性安全性。
  • 在IS0/IEC软件质量模型中，易使用性是指与使用所需的努力和由一组规定或隐含的用户对这样使用所作的个别评价有关的一组属性，其子特性不包括（ 易分析性 ）。
  • 在ISO/IEC 9126软件质量模型中，可靠性质量特性是指在规定的一段时间内和规定的条件下，软件维持在其性能水平有关的能力，其质量子特性不包括（ 安全性 ，可移植性 ）。
  • （ 易理解性 ）不属于软件质量特性中的可移植性。
  • （ 功能与模块之间的对应关系 ）不属于软件设计质量评审。
  • 在设计中实现可移植性设计的规则不包括（ 可使用特定环境的专用功能 ）
  • 软件质量属性中，（ 吞吐量 ）是指软件每分钟可以处理多少个请求。
  • 系统可维护性的评价指标不包括（ 可移植性 ）。
  • 系统可维护性是指维护人员理解、改正、改动和改进软件系统的难易程度，其评价指标不包括（ 一致性 ）。
  • 将每个用户的数据和其他用户的数据隔离开，是考虑了软件的（ 功能性 ）质量特件。

Released under the MIT License.

Copyright © 2017-2025 present shuyx