🌈 个人主页：十二月的猫-CSDN博客
🔥 系列专栏： 🏀软件开发必练内功_十二月的猫的博客-CSDN博客

💪🏻 十二月的寒冬阻挡不了春天的脚步，十二点的黑夜遮蔽不住黎明的曙光 

目录

1. 前言

2. 简答题练习

2.1 传统"瀑布模型"的主要缺陷是什么？试说明造成缺陷的主要原因

2.2 试简单论述OO测试的基本特点及困难之处

2.3 试述设计用户界面应考虑的问题

2.4 影响现代软件工程开发实践的关键要素是什么

2.5 模块间的各种内聚关系

2.6 模块间的各种耦合关系

2.7 需求获取的过程

2.8 测试的过程

2.9 功能测试指导性原则

2.10 软件质量因素

2.11 COCOMOⅡ（一种估算方法）

2.12 软件危机

3. 总结

---

 

1. 前言

在进入本篇文章前，大家可以按需求看看另几篇文章：

【软件工程】第一章·软件工程概述-CSDN博客

【软件工程】第二章·软件过程（过程与生命周期建模）-CSDN博客

【软件工程】第三章·计划和管理项目（详解活动图计算关键路径、最早开始时间、最晚开始时间、冗余时间）-CSDN博客

【软件工程】第四章·需求分析-CSDN博客

【软件工程】第五章·设计体系结构-CSDN博客

【软件工程】第六章·考虑对象（UML、UML在软件开发中的应用、面向对象方法的软件开发）-CSDN博客

【软件工程】第八章·单元/集成测试程序-CSDN博客

【软件工程】第九章·系统测试（因果图全解析）-CSDN博客

这几篇文章将让你对软件工程有一个整体的脉络，并在细节上有一定的把控🐮🐮

本文参考书籍：软件工程 第4版（ [美] 莎丽·劳伦斯·弗里格（Shari Lawrence Pfleeger））

---

本系列为【软件工程】知识讲解部分的延续，重点在于【软件工程】的习题考点的总结归纳。因为是习题考点，因此不同学校存在侧重点不同的情况，本系列仅仅针对山东大学考生，大家可以选择性学习。 

---

2. 简答题练习

2.1 传统"瀑布模型"的主要缺陷是什么？试说明造成缺陷的主要原因

主要缺陷： 

1. 瀑布模型的开发像瀑布从上到下进行，且不可迭代。
2. 瀑布模型是文档驱动。
3. 瀑布模型要求用户和开发人员在早期都需要充分且完全的考虑需求和设计问题。

造成缺陷的原因：

1. 软件开发是一个创造的过程，不是一个制造的过程。因此难免存在开发变动，该模型无法处理实际开发中的重复开发现象。
2. 文档转化困难。瀑布模型中每一个过程结束都严格需要一个里程碑（上交物），这些文档没有统一的格式，因此彼此转化比较困难（例如需求文档转化为设计文档）。
3. 软件开发中处理理解的非常充分的少数问题外，用户与开发人员在早期都无法很深入理解需求/设计方法，因此软件开发需要在迭代中进行。

2.2 试简单论述OO测试的基本特点及困难之处

OO测试的基本特点：

1. 面向对象测试用例的充分性。在传统测试中，系统改变时，我们可以针对改变的部分生成测试用例，并使用新测试用例加上原有测试用例作为最终的测试用例，这满足测试用例的充分性；但是在面向对象中，一旦系统发生变化，就要全部重新生成测试用例。
2. 面向对象测试趋于小粒度。将本来存在于构件内部的复杂性转移到构件之间的接口上，这意味着在面向对象测试中，单元测试更容易但是集成测试更加复杂。
3. 面向对象测试和传统测试都主要集中在：需求分析和验证、源代码分析和覆盖、测试用例的生成

OO测试的困难之处：

1. 需求验证缺乏工具支持（往往只能人工完成）。
2. 测试用例难以使用测试工具来生成。因为面向对象类与类之间的逻辑关系很复杂，测试工具难以明白。
3. 传统测试方法（如环路复杂度）在评价OO系统的规模和复杂性时，效果不好。
4. 对象交互是OO系统复杂性的根源，因此难以有较为完美的测试方法。

2.3 试述设计用户界面应考虑的问题

1.  通用因素：外观（系统向用户传输信息的外观特征）、思维模型（数据、功能、任务的组织与表示）、模型导航规则（怎样在数据、功能、活动和角色中移动及切换）、隐喻（可识别和学习的基本术语、图像和概念等）、感觉
2. 文化因素：需要考虑使用系统人的信仰、价值观、传统等。两种解决方法：a.使用无偏见设计，排除特定性文化的参与；b. 采用定制页面，使不同用户看到不同页面
3. 个性因素：为不同爱好的人选择不同的备选界面

2.4 影响现代软件工程开发实践的关键要素是什么

时间、预算、软件运行环境、软件开发环境、瀑布模型的不可预测性。

1. 商业产品投入市场的时间紧迫性。
2. 预算上的改变：更低硬件成本，更高开发、维护成本。
3. 功能强大的桌面计算的可用性。
4. 图形化用户界面的出现。
5. 广泛的局域网和广域网技术。
6. 面向对象技术的采用以及其有效性。
7. 瀑布模型的不可预测性。

2.5 模块间的各种内聚关系

1. 偶然内聚：模块各部分不相关，只为方便或偶然性原因放入同一模块。 比如强行放入一个类中没有任何关系的方法。
2. 逻辑内聚：模块中各部分只通过代码的逻辑结构相关联， 会共享程序状态 和代码结构，但相对于数据、功能和目标的内聚比较弱。比如因为有相同的某一个计算步骤 而放在 一起的两个没有关系的计算。
3. 时间内聚：部件各部分要求在同一时间完成或被同一任务使用而形成联系。 比如初始化模块中需要完成变量赋值、打开某文件等工作。
4. 过程内聚：要求必须按照某个确定的顺序执行一系列功能，模块内功能组合在一起只是为了确保这个顺序。其与时间性内聚相比优点在于其功能总是涉及相关 活动和针对相关目标，如写数据->检查数据->操作数据这一过程
5. 通讯内聚：各部分访问和操作同一数据集，如将来自于同一传感 器的所有不相干数据取出这一模块
6. 顺序内聚：各部分有输入输出关系，操作统一数据集，并且操作有顺序 。
7. 功能内聚：理想情况，各部分组成单一功能，且每个部分对功能都是必须的，每个元素执行且只执行设计功能，如一个简单的输出程序。
8. 信息内聚：功能内聚的基础上调整为数据抽象化和基于对象的设计。

2.6 模块间的各种耦合关系

耦合直观体现：模块间的消息传递

1. 非耦合：模块相互之间没有信息传递，如两个毫无关系的方法，但是一般 完全没有耦合是不现实的。
2. 数据耦合：模块间传递的是数据值，这是最受欢迎的一种耦合。如一个数值被当 做参数传递给另一个模块，这个数值在另一个模块中只会参与计算而非控制。
3. 特征耦合：使用一个复杂的数据结构进行模块间传递消息，并且传递的是该数据结构本身。比如将一个数组传递给另一个模块，数组仅用于计算而非控制
4. 控制耦合：一个模块通过传递参数或返回代码来控制另一个模块的活动。
5. 公共耦合：不同模块可以从公共数据存储区来访问和修改数据。
6. 内容耦合：一个模块实际上修改了另一个模块，被修改的模块完全依赖于修改他的模块。可能的情况有：一个模块修改另一个模块内部数据项或代码，或分支转移到另一个模块。如 goto 语句。

2.7 需求获取的过程

1. 原始需求获取：客户给出的需求
2. 问题分析建模：理解需求并通过建模或模型化方式进行描述
3. 规格说明书草稿：利用符号描述系统将定义规范化表示
4. 需求核准：开发人员与客户进行核准
5. 软件需求规格说明书：SRS

2.8 测试的过程

1. 单元测试：将每个程序构件与系统中的其他构件隔离，对其本身进行测试。
2. 集成测试：验证系统构件是否能够按照系统和程序设计规格说明中描述的那样共同工作的过程。
3. 功能测试：对系统进行评估，以确定集成的系统是否确实执行了需求规格说明中描述的功能，其结果是一个可运转的系统。
4. 性能测试：测试系统的软硬件性能是否符合需求规格说明文档。其结果是一个确认的系统。
5. 验收测试：确定系统是按照用户的期望运转的。
6. 安装测试：确保系统在实际环境中按照应有的方式运转。
7. 系统测试：功能测试、性能测试、验收测试和安装测试统称为系统测试。

2.9 功能测试指导性原则

高独预法停不改：高独想要干预法律，让他停止，他也不改。

1. 高故障检测概率。
2. 使用独立于设计人员和开发人员的测试人员。
3. 了解期望的动作和输出。
4. 既要测试合法输入，也要测试不合法输入。
5. 指定停止测试标准
6. 不能修改系统

2.10 软件质量因素

1. 产品质量：用户从产品功能、失效等外部特性看待产品质量，如果产品有足够的功能，并且易于使用或者虽然难以使用，但是其功能值得付出，用户就认为产品质量高；开发者从产品的设计原则、设计模式、故障等内部特征来看待产品质量，如果产品设计好，内部故障少则认为产品质量高。
2. 过程质量：a.过程质量包括开发和维护质量。b.过程质量和产品质量一样重要。c.过程质量低则产品质量不会高。
3. 商业环境背景下的质量：a. 前面讲的都是技术价值，技术价值和商业价值存在区别与联系。b.商业价值是软件与商业环境的战略导向的匹配程度。c.目标是将技术价值和商业价值统一起来。

2.11 COCOMOⅡ（一种估算方法）

核心思想：

COCOMOⅡ是一种工作量估算法，将软件开发分为三个阶段，不同阶段的估算方法不同。

1. 阶段一（原型阶段）：通过构建原型解决高风险问题，如用户界面、系统交互和技术成熟度等。此时对最终产品规模了解较少，因此使用应用点来估算项目规模。

2. 阶段二（早期设计阶段）：项目开发已经开始推进，设计人员研究不同的体系结构和操作概念。尽管信息比第一阶段多，但仍不足以准确估算工作量和工期。此阶段使用功能点来测量项目规模。

3. 阶段三（后体系结构阶段）：开发工作已开始，且已获取更多信息。在此阶段，可以使用功能点或代码行来进行规模估算，并较容易估算相关的成本因素。

2.12 软件危机

估用质文成产：软件开发中，李明成本估算不准，导致用户相当不满意。同时，产品质量很差，在用户提出修改时，李明发现开发文档丢了，这使得整个成本大大提升，并且软件开始生产效率低于用户需求。

定义：软件开发和维护过程中遇到的一系列问题

表现：

1. 估算不准确：Estimate inaccurate
2. 用户不满意：User dissatisfaction
3. 质量不可靠：Quality unreliable
4. 文档缺失，维护困难：Documentation missing
5. 成本上升：Cost increases
6. 生产力滞后：Productivity lag

3. 总结

本文到这里就结束啦~~，本文是【软件工程】系列的练习题部分。

目前【软件工程】系列的知识讲解部分已经完成：

【软件工程】第一章·软件工程概述-CSDN博客

【软件工程】第二章·软件过程（过程与生命周期建模）-CSDN博客

【软件工程】第三章·计划和管理项目（详解活动图计算关键路径、最早开始时间、最晚开始时间、冗余时间）_体系运行各过程时间一览表-CSDN博客

【软件工程】第四章·需求分析-CSDN博客

【软件工程】第五章·设计体系结构-CSDN博客

【软件工程】第六章·考虑对象（UML、UML在软件开发中的应用、面向对象方法的软件开发）-CSDN博客

 【软件工程】第七章·编写程序-CSDN博客

【软件工程】第八章·单元/集成测试程序-CSDN博客

【软件工程】第九章·系统测试（因果图全解析）-CSDN博客 

到这里【软件工程】系列的知识讲解就更新完毕🎢🎢🎢

如果觉得对你有帮助，友友们可以点个赞，收个藏呀~