湖科大《软件工程》考点总结2024

软件的本质（定义）：

软件是能够完成预定功能和性能，并对相应数据进行加工的程序和描述数据及其操作的文档。

软件的组成：

1. 指定的集合（计算机程序），通过执行这些指令可以满足预期的特征、功能和性能需求。
2. 数据结构，使得程序可以合理利用信息。
3. 软件描述信息，它以硬拷贝和虚拟形式存在，用来描述程序的操作和利用。

软件和硬件具有完全不同的特性：

软件不会“磨损”，但是软件退化的确存在。

软件应用领域：

• 系统软件
• 应用软件
• 工程/科学软件
• 嵌入式软件
• 产品线软件
• Web/移动App
• 人工智能软件

软件工程学科的定义：

软件工程是指导计算机软件开发和维护的工程学科，将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。

软件工程学科出现的原因：

软件危机的出现。

软件工程层次图：

支持软件工程的根基在于质量关注点。

软件工程的基础是过程层。

软件工程方法为构建软件提供技术上的解决方法（如何做）。

软件工程工具为过程和方法提供自动化或半自动化的支持。

软件过程的定义：

软件过程是工作产品构建时所执行的一系列活动、动作和任务的集合。

通用过程框架：

1. 沟通。在技术工作开始之前，和客户（及其他利益相关者）的沟通与协作是极其重要的，其目的是理解利益相关者的项目目标，并收集需求以定义软件特性和功能。
2. 策划。创建软件项目计划，它定义和描述了软件工程工作，包括需要执行的技术任务、可能的风险、资源需求、工作产品和工作进度计划。
3. 建模。软件工程师需要利用模型来更好地理解软件需求，并完成符合这些需求的软件设计。
4. 构建。必须对所做的设计进行构建，包括编码和测试，后者用于发现编码中的错误。
5. 部署。软件（全部或者部分增量）交付给用户，用户对其进行评测并基于评测给出反馈意见。

普适性活动：

• 软件项目跟踪和控制。项目组根据计划来评估项目进度，并且采取必要的措施来保证项目按进度计划进行。
• 风险管理。对可能影响项目成果或者产品质量的风险进行评估。
• 软件质量保证。确定和执行保证软件质量的活动。
• 技术评审。评估软件工程产品，尽量在传播到下一个活动之前发现错误并清除。
• 测量。定义和收集过程、项目以及产品的度量，以帮助团队在发布软件时满足利益相关者的要求。同时，测量还可与其他框架活动和普适性活动配合使用。
• 软件配置管理。在整个软件过程中管理变更所带来的影响。
• 可复用性管理。定义工作产品（包括软件构件）复用标准，并且建立构件复用机制。
• 工作产品的准备和生产。包括生成产品（如建模、文档、日志、表格和列表等）所必需的活动。

 软件工程过程特征：

规范性、可适应性、灵活性。

软件工程工作的体系结构轮廓：

通用的框架活动（沟通、策划、建模、构建和部署）和普适性活动。

软件工程实践的精髓：

1. 理解问题（沟通和分析）。
2. 策划解决方案（建模和软件设计）。
3. 实施计划（代码生成）。
4. 检查结果（测试和质量保证）。

通用原则：

1. 存在价值。
2. 保持简洁。
3. 保持愿景。
4. 关注使用者。
5. 面向未来。
6. 提前计划复用。
7. 认真思考。

学习软件工程的目的和意义：

应用科学的方法和工程化的规范管理来指导软件开发。

以较低的成本开发出高质量的软件。

克服软件危机。

做好软件开发的培训工作。

软件过程定义：

在开发产品或构建系统时，遵循一系列可预测的步骤（即路线图）是非常重要的，它有助于及时交付高质量的产品。

软件过程重要性：

软件过程提高了软件工程活动的稳定性、可控性和有组织性，如果不进行控制，软件活动将变得混乱。

过程流定义：

过程流描述了在执行顺序和执行时间上如何组织框架中的活动、动作和任务。

过程流的分类：

• 线性过程流。从沟通到部署顺序执行五个框架活动。
• 迭代过程流。在执行下一个活动前重复执行之前的一个或多个活动。
• 演化过程流。采用循坏的方式执行各个活动，每一次循坏都能产生更为完善的软件版本。
• 并行过程流。将一个或多个活动与其他活动并行执行（eg：软件一个方面的建模活动可以与软件另一个方面的建模活动并行执行）。

（备注：大概看一下书上P18的图）

惯用过程模型分类：

• 瀑布模型（线性顺序模型）
• 原型模型
• 螺旋模型
• 增量过程模型
• 统一过程模型

（备注：大概了解一下书上P26的表2-1过程模型对比）

统一过程模型是一种“用例驱动、以体系结构为核心、迭代及增量”的软件过程框架，由于UML方法和工具支持。

敏捷软件工程定义：

敏捷软件工程是哲学理念和一系列开发指南的综合。这种哲学理念推崇：让客户满意且尽早的增量发布，小而高度自主的项目团队，非正式的方法，最小化软件工程工作产品以及整体精简开发。开发的指导方针强调超越分析和设计（尽管并不排斥这类活动）的发布。

敏捷软件开发宣言：

• 个人和他们之间的交流胜过开发过程和工具。
• 可运行的软件胜过宽泛的文档。
• 客户合作胜过合同谈判。
• 对变更的良好响应胜过按部就班地遵循计划。

敏捷方法的定义以及优缺点：

定义：敏捷方法是一种强调灵活性和快速响应变化的方法。

优点：包括快速迭代、灵活应变、团队协作、用户反馈等。它能够快速响应需求变化，提高开发效率和产品质量，同时也能增强团队之间的沟通和协作。

缺点：对人员要求高、管理难度大、实施成本高。

敏捷的定义：

敏捷不仅是有效地响应变更，它还意味着秉承敏捷软件开发宣言中提及的哲学理念。它鼓励采用能够使沟通（团队成员之间、技术和商务人员之间、软件工程师和经理之间）更便利的团队结构和协作态度；它强调可运行软件的快速交付而不那么看重中间产品（这并不总是好事情）；它将客户作为开发团队的一部分开展工作，以消除持续、普遍存在于多数软件项目中的“区分我们和他们的态度”；它秉承在不确定的世界里，计划是有局限性的，项目计划必须是可以灵活调整的。

敏捷原则：

通过尽快向客户交付软件来提供价值，可以获得客户满意度。为了实现这一目标，敏捷开发人员应认识到需求将发生变化。他们要经常提供软件增量，并与所有利益相关者合作，以便获取关于所交付软件的快速且有意义的反馈。敏捷团队由积极的个人组成，他们面对面交流，在有利于高质量软件开发的环境中工作。团队遵循一个流程：鼓励技术卓越和良好的设计，强调简单性，即“使不必做的工作最大化的艺术”。得到满足客户需求的可工作软件是他们的首要目标，团队工作的速度和方向必须是“可持续的”，以便使他们能够长时间有效地工作。敏捷团队是一个“自我组织团队”，能够开发结构良好的体系结构，从而实现可靠的设计并达到客户满意度。团队文化的一部分是反思如何围绕目标更有效地工作。

Scrum原则：

Scrum原则与敏捷宣言是一致的，应用Scrum原则指导过程中的开发活动，过程由“需求、分析、设计、演化和交付”等框架性活动组成。

敏捷方法：

• XP框架。极限编程（XP）包括策划、设计、编码和测试四个框架活动的规则和实践。
• 看板法。依赖六个核心实践。
• DevOps。涉及以下几个阶段，这些阶段会持续循坏，直到得到所需的产品：

1. 持续开发
2. 持续测试
3. 持续集成
4. 持续部署
5. 持续监控

软件工程师的特质：

1. 个人责任感。努力实现对同伴、其他利益相关者和管理者的承诺。为获得成功的结果，会不遗余力地做他需要做的事情。
2. 敏锐的意识。对其他团队成员、对现存软件解决方法有需求的利益相关者、掌控整个项目并能找到解决方法的管理者的需求有敏锐的意识，观察人们工作的环境，并调整自己的行为以兼顾环境和人。
3. 坦诚的。如果发现了有缺陷的设计，他会用坦诚且有建设性的方式指出错误。即使被要求歪曲与进度、特征、性能、其他产品或项目特性有关的事实，他也会选择实事求是。
4. 抗压能力。在不影响业绩的情况下很好地处理来自各个方面的压力。
5. 高度的公平感。乐于与同事分享荣誉，努力避免利益冲突并且绝不破坏他人劳动成果。
6. 注意细节。利用产品和项目已有的概括性标准（如性能、成本、质量,在日常工作基础上仔细思考，进而做出技术型决策。
7. 务实的。根据当下情景进行调整。

高效的软件团队的特征：

1. 建立目标意识。

2. 有参与意识。让每个成员都能感受到自己的技能得到了发挥，所做出的贡献是有价值的。

3. 培养信任意识。团队中的软件工程师应该相信同伴和其管理者的技术与能力。

4. 鼓励进步意识。定期审视软件工程方法并寻求改善途径。

5. 多样化的。由具备不同技能的人员组成。

需求工程的定义：

需求工程是指致力于不断理解需求的大量任务和技术。

（需求工程在设计和构件之间建立起联系的桥梁。）

需求工程包括七项任务：

1. 起始
2. 获取
3. 细化
4. 协商
5. 规格说明
6. 确认
7. 管理

第7章 需求建模——一种推荐的方法

（备注：请仔细看书P83-P105，会画顺序图、状态图、活动图等，知道图形意思及表达内容。里面包含30分的综合大题。）

完整的设计规格说明所必需的四种设计模型：

1. 数据或类的设计
2. 体系结构设计
3. 接口设计
4. 构件设计

设计概念：

1. 抽象
2. 体系结构
3. 模式
4. 关注点分离
5. 模块化
6. 信息隐蔽
7. 功能独立
8. 逐步求精
9. 重构
10. 设计类

（备注：加粗的地方是需要重点关注的点，请自行看书P111-P117或者网上查找资料。）

体系结构风格的简单分类：

1. 以数据为中心的体系结构。
2. 数据流体系结构。
3. 调用和返回体系结构。
4. 面向对象的体系结构。
5. 层次体系结构。

（备注：要知道各种体系结构风格的不同/区别，请自行看书P130-P133或者网上查找资料。）

第11章 用户体验设计

（备注：大题中有用户界面设计和接口设计，请自行看书或者网上查找资料。）

界面设计的三条黄金原则：

1. 把控制权交给用户。

• 以不强迫用户进入不必要的或不希望的动作的方式来定义交互模式
• 提供灵活的交互
• 允许用户交互被中断和撤销
• 当技能水平高时可以使交互流线化并允许定制交互
• 使用户与内部技术细节隔离开来
• 设计应允许用户与出现在屏幕上的对象直接交互

1. 减轻用户的记忆负担。

• 减少对短期记忆的要求
• 建立有意义的默认设置
• 定义直观的快捷方式
• 界面的视觉布局应该基于真实世界的象征
• 以一种渐进的方式揭示信息

1. 保持界面一致。

• 允许用户将当前任务放入有意义的环境中
• 在完整的产品线内保持一致性
• 如果过去的交互模型已经建立起了用户期望，除非有不得已的理由，否则不要改变它

软件测试步骤：

（备注：书上P219的图15-2。）

白盒测试是什么：

白盒测试有时也称为玻璃盒测试或结构化测试，是一种测试用例设计方法，它利用作为构件级设计的一部分所描述的控制结构来生成测试用例。

白盒测试有什么：

1. 基本路径测试
2. 控制结构测试

黑盒测试是什么：

黑盒测试也称行为测试或功能测试，侧重于软件的功能需求。黑盒测试使软件工程师能设计出可以测试程序所有功能需求的输入条件集。

黑盒测试有什么：

1. 接口测试
2. 等价类划分
3. 边界值分析

面向对象测试有什么：

1. 类测试
2. 行为测试

（备注：看书P224-P232，学习各种测试方法的测试步骤、目的等。）

项目进度安排基本原则：

• 划分。必须将项目划分成多个可以管理的活动和任务。
• 相互依赖性。划分后的各个活动或任务之间的相互依赖关系必须是明确的。
• 时间分配。每个要进行进度安排的任务必须分配一定数量的工作单位。此外，还必须为每个任务指定开始日期和完成日期。
• 工作量确认。每个项目都有预定人员数量的软件团队参与。
• 确定责任。进度计划安排的每个任务都应该指定特定的团队成员来负责。
• 明确输出结果。进度计划安排的每个任务都应该有一个明确的输出结果。
• 确定里程碑。每个任务或任务组都应该与一个项目里程碑相关联。

风险管理的定义：

风险管理是标识风险、评估其发生的概率、估算其影响和建立在实际发生情形下问题的应急计划，是一系列帮助软件小组理解和管理不确定性的步骤。

（本文是老师标注的重点，大家做参考就好，有些具体需要理解的问题我都写了备注，请大家看书或者自行查阅资料。）

最后，大家加油背吧，祝大家都能取得好成绩。