软件设计师 上午题 软件工程
软件设计师 上午题 软件工程
软件工程旨在通过工程化方法（如需求分析、设计、开发、测试和维护）高效构建高质量、可靠、可维护的软件系统。其核心目标是解决“软件危机”（如成本超支、进度延迟、质量低下等问题），平衡用户需求、技术可行性和商业可持续性。
一、软件过程
软件开发中所遵循的路线图被称之为“软件过程”，为了有效管理软件过程，人们开发了以下几种模型：
1. 能力成熟度模型（CMM）
一个软件组织在开发软件的过程中，其能力一定是一步步提高的，而CMM就是一个用来描述软件组织进化阶段的模型。它将软件过程改进分为以下五个成熟度级别：
- 初始级：该阶段的软件过程杂乱无章，几乎没有明确定义的步骤，想要完成项目必须依靠英雄式核心人物的作用。
- 可重复级：建立了基本的项目管理过程和实践，有必要的过程准则来重复以前在同类项目中的成功。
- 已定义级：管理和工程两方面的软件过程已经文档化和标准化。所有项目都采用根据实际情况修改后得到的标准软件过程来开发和维护软件。
- 已管理级：制定了软件过程和产品质量的详细度量标准，软件过程的质量都被开发人员所理解和控制。
- 优化级：加强了定量分析，有不断的反馈使得软件过程可以不断持续地改进。
2. 能力成熟度模型集成（CMMI）
CMMI是若干个过程模型的综合和改进，能够支持多个工程学科。CMMI提供了两种表示方法：
- 阶段式模型：阶段式模型的结构类似于CMM。
- 初始的：过程不可预测且缺乏控制。
- 已管理的：过程为项目服务。
- 已定义的：过程为组织服务。
- 定量管理的：过程已度量和控制。
- 优化的：集中于过程改进。
- 连续式模型：我们将软件过程中的特定领域的标准化实践集合称之为过程域，而连续式模型关注的就是过程域的能力。连续式模型中使用能力等级（CL）来评估过程域的能力：
- （未完成的）：未完成中制定的目标即为。
- （已执行的）：过程能被执行（能将可标识的输入转换为可标识的输出），但依赖个人能力，无标准化。
- （已管理的）：过程有计划、有监控，能按文档化流程执行。
- （已定义的）：过程标准化，基于组织级最佳实践，并培训团队。
- （定量管理的）：过程通过数据（如需求变更率）优化。
- （优化的）：使用量化手段持续改进过程，通过技术创新或流程再造提升效率。
二、软件过程模型
软件过程模型，亦即软件开发模型，它是软件开发全部过程、活动和任务的结构框架。
Ⅰ 瀑布模型
1. 瀑布模型
瀑布模型将软件生存周期中的各个活动规定为依照线性顺序连接的若干阶段的模型，各阶段间相互衔接，如同瀑布般逐级下落：
显然，瀑布模型很适合软件需求非常明确的模型，或者已经掌握了开发技术的软件。但是在瀑布模型中，客户必须能够完整清晰地表达他们的需求，而且需求或设计中的错误只有到了项目后期才会被发现，容易出现积重难返的现象。此外，瀑布模型也难以适应变化的需求。
2. V模型
V模型是瀑布模型的一个变体，左侧用来描述开发，右侧用来描述测试，这样就使得测试与开发能够并行设计，能够在项目早期就发现缺陷。
Ⅱ 增量模型
增量模型事实上也是瀑布模型的一个变体，它融合了瀑布模型的迭代特征。在增量模型中将总体需求分段为一系列增量产品，每个增量包含一个完整的功能子集。
如图所示，每个增量都可以分别开发并分批发布。一般来说会将软件最核心的功能包含进第一个增量当中，这样一来用户就能在整个系统开发完毕之前抢先进行使用，并给出反馈以便下一个增量发布新特征和新功能。
增量模型的困难在于需要比较长远的项目规划，否则前期开发的增量有可能造成后来增量的不稳定或者产生重新开发的成本。
Ⅲ 演化模型
演化模型是一种渐进式、迭代式的软件开发方法，通过不断反馈和优化逐步完善系统，最终交付符合用户需求的完整产品。其核心思想是：“先构建核心功能，再逐步扩展和优化”，适用于需求不明确或可能频繁变化的项目。
典型的演化模型有原型模型和螺旋模型等：
1. 原型模型
原型模型是一种通过快速构建原型（预期系统的一个可执行版本）来验证需求和设计的开发方法，其核心是“先试错，再开发”。开发团队利用工具快速制作可交互原型，由用户试用并反馈，经过多次迭代优化后，最终确定需求或直接基于稳定原型开发完整系统。
2. 螺旋模型
对于复杂的大型软件，开发一个原型往往达不到要求，那么人们就开发出了一种将瀑布模型和演化模型结合起来的模型，即螺旋模型。
和瀑布模型类似，螺旋模型将开发过程分为多个循环周期，每个周期包含需求分析、风险评估、原型开发及用户验证四个阶段，通过逐步迭代完善系统。
但是螺旋模型还支持用户需求的动态变化，其核心特点就是早期识别并控制风险，适用于复杂度高、不确定性大的项目（如军工、医疗软件）。相比瀑布模型更灵活，相比纯迭代模型更强调系统性风险管理，但成本较高且依赖专业风险评估能力。
C，瀑布模型和V模型都是都是基于明确的开发需求的开发模型，而当用户的需求不明确时就需要用原型模型不断地捕捉需求。
B，原型模型仅适用于小规模不复杂的软件，否则其原型开发也将消耗大量成本，并且难以满足需求。
DC，不再赘述。
Ⅳ 喷泉模型
喷泉模型是一种面向对象的软件开发方法，其核心特点是开发阶段的无缝迭代与回溯，强调各阶段之间的非线性交互和并行推进。与瀑布模型的线性流程不同，喷泉模型的开发活动之间不存在明显的边界，允许开发者在任意阶段根据需求动态调整（如设计时发现分析不足可回溯补充），尤其适合需求易变、需频繁重构的面向对象项目。其优势在于灵活性高、适应性强，但需严格管理文档和版本控制以避免混乱。
Ⅴ 敏捷方法
敏捷开发的总体目标是通过“尽可能早地、持续地对有价值的软件的交付”来使客户满意。在软件开发中假如灵活性之后，用户能够在敏捷方法的开发后期增加或改变需求。
敏捷方法的典型方法有以下几种：
1. 极限编程（XP）
这一部分的知识点过于琐碎，做题的时候按直觉回答即可。
2. 水晶法
水晶法认为每一个不同的项目都需要一套不同的策略。
3. 并列争求法
并列争求法使用迭代的方法，把每30天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。
4. 敏捷统一过程（AUP）
AUP采用“在大型上连续”以及“在小型上迭代”的原理来构建软件系统。它采用经典的UP阶段性活动，能够使团队为软件项目构想出一个全面的过程流。
三、需求分析
Ⅰ 软件需求
软件需求是指用户对于目标软件系统的期望，主要包括以下几个方面：
- 功能需求：考虑系统要做什么，在何时做，在何时以及如何修改或升级。
- 性能需求：考虑软件开发的技术性指标。
- 数据需求：考虑输入、输出数据的格式，接收、发送数据的频率等。
A，A为功能需求，BD为性能需求，C为数据需求。
Ⅱ 系统设计
系统设计阶段的任务就是将软件“做什么”的逻辑模型转换为“怎么做”的物理模型。系统设计的基本任务大体上可以分为概要设计和详细设计两个步骤。
1. 概要设计
概要设计的重点是设计软件系统的总体结构：其基本任务是采用某种设计方法，将一个复杂的系统按功能划分为模块，并缕清每个模块的功能、模块之间的调用关系、确定模块之间的接口和评价模块结构的质量。
2. 详细设计
- 对每个模块进行详细的算法设计。
- 对模块的数据结构进行设计。
- 对数据库的物理结构进行设计。
Ⅲ 系统测试
系统测试是为了以最少的人力和时间发现潜在的各种错误和缺陷。
1. 系统测试的基本原则
这一部分的知识点过于琐碎，做题的时候按直觉回答即可。
2. 传统软件的测试策略
有效的软件测试实际上分为4步进行，即单元测试、集成测试、确认测试和系统测试，这里我们重点了解前两步。
1）单元测试
单元测试也称为模块测试，一般在模块编写完成之后并且无编译错误后就可以进行。单元测试针对代码中最小的可测试单元（如函数、方法、类）进行隔离测试，验证其功能是否符合预期。
单元测试的主要内容为：
- 模块接口
- 局部数据结构
- 重要的执行路径
- 出错处理
- 边界条件
2）集成测试
集成测试就是把模块组合起来进行测试，因为即使所有模块都通过了测试，它们组合在一起使用之后仍然可能出现问题。我们一般采用增量式集成测试，即以小增量的方式逐步进行构造和测试，以下是一些常见的增量集成策略：
- 自顶向下测试：从系统最顶层的模块（如主控模块）开始测试，逐步集成下层模块。未集成的下层模块用桩模拟。
- 自底向上测试：从系统最底层的模块（如工具类、数据库访问层）开始测试，逐步向上组合。未集成的上层模块用驱动（Driver）调用下层。
- 回归测试：在每次集成新模块或修改代码后，重新运行已有的测试用例，确保原有功能未被破坏。
- 冒烟测试：在正式测试前，快速验证系统基本功能是否可用（如“能否启动”、“核心接口是否响应”）。
Ⅳ 测试方法
1. 黑盒测试
黑盒测试也称之为功能测试，它将整个软件看作一个看不到细节的黑盒，在完全不考虑软件的内部结构和特性的情况下，仅靠输入和输出来测试系统是否达到预期。
常见的黑盒测试技术有：
1）等价类划分
等价类划分法将程序的输入域划分为若干个等价类，然后从每个等价类中选取一个代表性数据作为测试用例，测试用例即等价于所在类的其他值，以实现用较少测试用例取得较好的测试效果。
2）边界值分析
边界值分析法是一种用来补充等价类划分法的测试用例设计技术。其出发思想是输入的边界比中间更加容易发生错误，那么就要选择等价类边界的测试用例进行测试。
C，基于等价类设计测试用例时，每个测试用例至多覆盖一个无效等价类，而选项C中包含两个无效等价类，故不是一个好的测试用例。
2. 白盒测试
白盒测试也称之为结构测试，测试人员需要了解被测系统的内部结构、实现细节和代码逻辑，通过设计测试用例来验证代码的正确性、覆盖率和执行路径。
白盒测试中最常见的技术是逻辑覆盖，它通过量化“被测代码的执行比例”来评估测试的充分性，主要的逻辑覆盖标准有以下几种：
| 覆盖标准 | 覆盖目标 | 严格性 | 适用场景 |
|---|---|---|---|
| 语句覆盖 | 每条语句至少执行一次 | ★☆☆☆☆ | 快速检查基础执行 |
| 判定覆盖（分支覆盖） | 每个分支真/假至少执行一次（针对判定结果） | ★★☆☆☆ | 一般功能测试 |
| 条件覆盖 | 每个子条件真/假至少执行一次 （针对判定条件） | ★★★☆☆ | 复杂条件表达式 |
| 判定/条件覆盖 | 分支+子条件真/假至少执行一次 | ★★★☆☆ | 平衡测试成本与效果 |
| 条件组合覆盖 | 所有条件组合至少执行一次 | ★★★★☆ | 高可靠性系统（如航天软件） |
| 路径覆盖 | 所有执行路径至少执行一次 | ★★★★★ | 关键算法或模块 |
3. McCabe度量法
McCabe度量法又称为环路度量，它认为程序的复杂性在于控制的复杂性。单一的顺序程序结构最为简单，循环和选择构成的环路越多，程序就越复杂。
McCabe度量法的基础是图论，在一个程序图上研究其中的环的个数：
其中，图G首先需要是一个强连通图，而m是图G中弧的个数，n是图G中的节点数。
四、运行和维护知识
Ⅰ 系统维护概述
软件维护是在软件已经交付使用之后为了改正错误或者满足新的需求而修改软件的过程，即软件在交付使用后对软件所做的一切改动。
1. 系统可维护性概念
提高可维护性是开发软件系统所有步骤的关键目的，系统能否被很好地维护，可以用系统的可维护性这一指标来衡量。
1）系统可维护性的评价指标
- 可理解性：指他人理解系统的结构、功能和内部过程的难易程度。
- 可测试性：诊断和测试的容易程度取决于易理解的程度，好的资料文档有利于诊断和测试。此外，在进行系统维护时，应该充分利用在系统测试阶段留下来的测试用例。
- 可修改性：模块的耦合、内聚、作用范围与控制范围的关系等都对可修改性有影响。
2） 软件文档与维护
软件文档是软件产品的一部分，没有文档的软件不能称之为软件产品。软件系统的文档可分为用户文档和系统文档两类，前者描述使用方法而不关心怎样实现，后者描述系统设计、实现和测试等各方面的内容。
此外，可维护性是所有软件都应具有的基本特点，必须在开发阶段保证软件具有可维护的特点。在软件工程的每一个阶段都应考虑并提高软件的可维护性，在每个阶段结束前的技术审查和管理复查中应该着重对可维护性进行复审。
2. 系统维护的内容及类型
我们主要讨论的是系统维护中的软件维护，即根据需求变化或者硬件环境的变化对应用程序进行部分或全部修改，一般包括以下几个方面：
- 正确性维护：改正在系统开发阶段已经发生而系统测试阶段尚未发现的错误。
- 适应性维护：指使应用软件适应信息技术变化和管理需求变化而进行的修改。
- 完善性维护：主要是针对已有的软件系统增加一些在系统分析和设计阶段中没有的规定的功能。
- 预防性维护：为了适应未来的软硬件环境的变化，主动增加预防性的新功能。
A，这道题的重点在于“进行…程序设计”，这表明了这是在系统开发阶段就发生了的，属于正确性维护。
五、软件项目管理
Ⅰ 软件项目估算
我们重点来了解以下两种成本估算模型：
1. COCOMO估算模型
COCOMO的核心思想是通过项目规模（通常以代码行数KLOC衡量）和调整因子来量化开发成本。
| 模型类型 | 适用阶段 | 输入参数 | 特点 |
|---|---|---|---|
| 基本COCOMO | 早期可行性分析 | 代码行数（KLOC）、项目类型 | 静态单变量模型 |
| 中级COCOMO | 需求分析后 | 代码行数 + 15个成本驱动因子 | 静态多变量模型 |
| 详细COCOMO | 详细设计阶段 | 分模块估算 + 阶段级成本驱动因子 | 高精度，但需详细数据 |
2. COCOMOⅡ模型
COCOMO II是经典COCOMO模型的现代化改进版本，它通过更灵活的规模估算和新增成本驱动因子，提高了成本预测的准确性。它也分为3个阶段性模型：
- 应用组装模型：在软件工程的前期阶段使用。基于对象点进行估算。
- 早期设计阶段模型：在需求已经稳定并且基本的软件体系结构已经建立时使用。基于功能点进行估算。
- 体系结构阶段模型：在软件的构造过程中使用。基于源代码行进行估算。
Ⅱ 进度管理
1. 进度安排
进度安排的常用图形描述方法有Gantt图（甘特图）和项目计划评审技术图（PERT图）：
1）Gantt图
甘特图是一种以日历为基准描述项目任务的水平条形图。
甘特图能够清晰地描述每个人物从何时开始到何时结束，以及各个任务之间的并行性。但是显然它不能清晰地反映出各任务之间的依赖关系，因此难以确定整个项目的关键所在，也不能反映计划中哪一部分最有潜力。
2）PERT图
PERT图所描绘的图景和图论中的最短路径问题有一些相似之处，但是它所表示的信息更为直观和丰富。例如可以直接从松弛时间全部0的结点中找出关键路径。
PERT图不仅给出了每个任务的开始时间、结束时间和完成该任务所需的时间，还给出了任务之间的关系，即哪些任务完成后才能开始另外一些任务，以及如期完成整个工程的关键路径。图中的松弛时间则反映了完成某些任务时可以推迟其开始时间或延长其所需完成的时间。但是，PERT 图不能反映任务之间的并行关系。
Ⅲ 风险管理
这一部分的知识点过于琐碎，答题时直接根据常识回答即可。
六、软件质量
Ⅰ 软件质量特性
讨论软件质量首先要了解软件的质量特性，我们下面来了解一下ISO/IEC 9126软件质量模型：
我们重点来关注一下可靠性、可用性和可维护性：
- 可靠性：可靠性是指一个系统对于给定的时间间隔内、在给定条件下无失效运作的概率。可以用MTTF/(1+MTTF)来度量，其中MTTF为平均无故障时间。
- 可用性：可用性是在给定的时间点上，一个系统能够按照规格说明正确运作的概率。可以用MTBF/(1+MTBF)来度量，其中MTBF为平均失效间隔时间。
- 可维护性：可维护性是在给定的使用条件下，在规定的时间间隔内，使用规定的过程和资源完成维护活动的概率。可以用1/(1+MTTR)来度量，其中MTTR为平均修复时间。
Ⅱ 软件评审
通常，软件的“质量”即为“用户满意程度”，那么为了把控软件的质量就很有必要对软件进行评审：
1. 设计质量的评审内容
在设计质量评审中，评审对象是设计阶段输出的各类交付物，目的是确保设计符合需求、标准及最佳实践。具体对象包括但不限于以下内容：
- 评审软件的规格说明是否合乎用户的要求。
- 评审软件的可靠性，即能否避免输入异常等问题所产生的失效，一旦发生问题应该更够及时恢复或者采取代替手段。
- 评审保密措施的实施情况。
- 评审软件性能是否达到所规定性能的目标值。
- 评审软件是否具有可修改性、可扩充性、可互换性和可移植性。
- 评审软件是否具有可测试性。
- 评审软件是否具有复用性。
2. 程序质量的评审内容
程序质量评审的对象是代码本身及其相关产出物，目的是确保代码的正确性、可维护性、性能及安全性。评审范围涵盖以下几个方面：
- 模块结构：
- 控制流结构。
- 数据流结构。
- 模块结构与功能结构之间的对应关系。
- 与运行环境的接口：
- 与硬件的接口。
- 与用户的接口。
- 正式的技术评审：正式的技术评审是一种由技术人员实施的程式化会议，其唯一目的是揭露质量问题。
Ⅲ 软件容错技术
容错技术，即对某些无法避开的差错，使其影响减至最小的技术，而实现容错的主要手段是冗余。通常，冗余技术分为4类：
- 结构冗余：结构冗余是最常采用的冗余技术，按工作方法可继续细分为以下三种。
- 静态冗余：通过并行部署多个相同组件，所有组件同时工作，系统通过表决机制（如多数表决）输出正确结果。
- 动态冗余：采用主备模式，主组件工作时备用组件待机，故障时通过检测机制切换至备用组件。
- 混合冗余：结合静态与动态冗余的优点，部分组件始终运行，其余组件按需激活。
- 信息冗余：通过添加额外校验数据来检测或纠正信息传输/存储中的错误，属于“数据层”冗余。
- 时间冗余：通过重复执行或延迟验证来消除瞬时错误，属于“时间层”冗余。