软件工程复习

最新推荐文章于 2024-06-22 15:59:49 发布

文子啊啊啊

最新推荐文章于 2024-06-22 15:59:49 发布

阅读量1.4k

点赞数 54

分类专栏：考试文章标签：软件工程

本文链接：https://blog.csdn.net/m0_67663465/article/details/139361064

版权

考试专栏收录该内容

3 篇文章 0 订阅

订阅专栏

软件工程复习

1 第一章：软件工程概述

软件定义：软件是计算机系统中与硬件相互依存的另一部分，它包括程序、相关数据及其说明文档。

软件=程序+数据+文档
软件危机（需求，开发进度，成本，质量）
1. 软件危机的主要表现是“已完成”的软件不满足用户的需求；
2. 开发进度不能保障；
3. 软件开发成本难以准确估算；
4. 软件产品的质量没有保证。
软件工程的概念：软件工程是采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理方法和先进软件开发技术结合起来，运用到软件开发和维护过程中，来解决软件危机。
软件工程研究的主要内容：软件工程研究的主要内容是软件开发技术和软件开发管理两个方面。
1. 软件开发技术方面主要研究软件开发方法、软件开发过程、软件开发工具和环境。
2. 软件开发管理方面主要研究软件工程管理学、软件工程经济学、软件工程心理学。
软件工程的7条基本原理：
1. ①用分阶段的生命周期计划严格管理
2. ②坚持进行阶段评审
3. ③实行严格的产品控制
4. ④采用现代程序设计技术
5. ⑤结果应能清楚地审查
6. ⑥开发小组的人员应该少而精
7. ⑦承认不断改进软件工程实践的必要性。
主流的软件开发方法
1. 结构化方法
2. 面向对象方法
1999年由ACM/IEEE-CS软件工程师道德规范和职业实践（SEEPP）联合工作组制订了《软件工程师职业道德规范》，规范含有8组由关键词命名的准则。公众、客户和雇主、产品、判断、管理、专业、同行、自身。

职业化软件工程师要注意的十大问题：

①高质量地完成任务

②遵守行业标准，不能肆意按照自己的想象来发挥

③积极帮助他人

④版权意识敏感

⑤严格遵守计划

⑥公私分明

⑦注意知识更新

⑧善于沟通

⑨遵守职业规则

⑩诚实和正直。

2 第二章：软件过程

软件过程： 软件过程是软件生命周期中的一系列相关过程。过程是活动的集合。
软件的生命周期： 可行性分析、项目计划、需求分析、总体设计、详细设计、编码测试、运行维护等阶段。

💯举例来说，假设一个团队正在开发一个新的社交媒体应用程序。他们首先会进行需求分析，了解用户的需求和期望。接下来，他们会进行设计，设计应用程序的界面、功能和架构。然后是编码阶段，开发人员根据设计文档实现应用程序的各个功能。随后是测试阶段，测试团队会对应用程序进行功能测试、性能测试和用户体验测试等。最后是维护阶段，持续修复bug、更新功能和支持用户。这个过程就是软件的生命周期，而每个阶段中进行的活动和任务则构成了软件过程。
- 软件定义
- 软件开发
- 运行维护
软件过程模型
1. 瀑布模型
  1. 需求分析
  2. 设计
  3. 编码
  4. 测试
  5. 维护
    优点：
  6. 清晰明确的阶段划分： 瀑布模型将软件开发过程分解为一系列清晰明确的阶段，每个阶段都有特定的任务和目标，有助于项目管理和进度跟踪。
  7. 适用于稳定的需求： 如果项目的需求相对稳定且明确，瀑布模型可以提供一个结构化的方法来逐步完成项目的各个阶段，确保质量和进度可控。
  8. 可控性高： 每个阶段之间有明确的交付物和检查点，开发团队可以在每个阶段结束时评估进度和质量，并进行必要的调整和改进。
  9. 文档化程度高： 在瀑布模型中，每个阶段都有相应的文档输出，例如需求规格说明书、设计文档和测试报告，有助于项目的沟通和知识传递。
    缺点：
  10. 刚性的阶段顺序： 瀑布模型要求各个阶段按照线性顺序依次执行，无法灵活应对需求变化和调整，如果在后期发现需求变更，可能需要回到早期阶段进行修改，增加了开发成本和时间。
  11. 不适合大型复杂项目： 对于大型、复杂的软件项目，往往需求不够明确和稳定，瀑布模型的刚性阶段顺序和无法快速响应变化的特点可能导致项目失败。
  12. 测试延迟问题： 在瀑布模型中，测试通常在开发完成后才进行，可能会导致在后期发现的问题和缺陷的修复成本较高，而且可能会延迟项目的交付。
  13. 客户参与度较低： 在瀑布模型中，客户往往在需求分析阶段就确定了需求，之后的开发过程很少与客户交互，可能导致最终交付的产品与客户期望不符。
    带反馈的瀑布模型：在每个活动中都可以修改前一个活动中存在的问题。
2. 快速原型模型
  1. 需求收集
  2. 构建初步原型
  3. 用户评估和反馈
  4. 修订原型
  5. 产品开发
  6. 最终测试和部署
    有点是会比较复合用户需求，确定是快速建立起来的系统结构加上连续的修改可能会导致产品质量低。
3. 增量模型：
  1. 需求分析和项目规划： 在项目开始时，团队会进行全面的需求分析，并将整个软件分解为多个可以独立开发和部署的小模块或增量。
  2. 增量开发： 选择一部分核心功能首先开发，完成后立即交付给用户。这些功能通常是用户最急需的或对业务影响最大的。
  3. 测试和验证： 每完成一个增量，就对其进行测试和验证以确保质量符合标准。此外，还需确保这个新增量与之前的增量能够良好地集成在一起。
  4. 用户反馈： 用户开始使用当前增量的功能，他们的反馈将帮助确定后续增量的优先级和调整需求。
  5. 后续增量开发： 根据初期的反馈，继续开发下一个增量，增加新功能或改进现有功能。这个过程会一直重复，直到软件的所有预定功能都已开发完毕并集成到最终产品中。
  6. 最终集成和部署： 当所有增量都完成后，进行最终的集成测试。确认软件整体表现符合用户的要求和业务的需求后，进行最终部署。
    优点是人员分配灵活，缺点是开发者和用户需要一直反复沟通
4. 螺旋模型
  1. 目标设定： 在这个阶段，确定项目的目标、选项和约束条件。这包括收集需求，定义系统的核心功能和性能目标，确定项目边界，以及制定相关策略。
  2. 风险分析： 这是螺旋模型的核心特点，每个迭代都会对潜在风险进行识别和分析。风险分析通常包括评估可能影响项目成功的技术、财务、市场或其他风险。根据风险的严重程度，开发团队可以选择最合适的方法来处理或规避风险，例如通过原型或模拟实验。
  3. 开发和测试： 在这个阶段，团队基于目前的需求和风险评估结果开发一个或多个软件产品原型。这些原型被用于验证设计决策，并对系统进行测试以确保满足用户需求。原型完成后，进行系统的集成和测试，以评估产品的功能和性能。
  4. 计划下一迭代： 在每个螺旋的最后阶段，项目团队评估到目前为止的开发工作，并计划下一阶段的迭代。这包括做出是否继续开发的决定，调整项目目标，更新项目计划，以及确定下一个迭代的预算和资源。
    优点是开发者和客户都能很好的评估每一次迭代的风险，缺点是反复的风险评估比较复杂
5. 构件组装模型：
  - 构件识别和选择： 首先，团队需要识别和选择可重用的构件，这些构件可以是已经存在的、开源的、或者由第三方供应商提供的。这些构件应该能够满足系统的功能和性能需求。
  - 构件开发和测试： 如果不存在现成的构件，团队可能需要开发新的构件。在这个阶段，开发人员编写构件的代码，并对其进行测试，以确保其质量和稳定性。
  - 构件集成和组装： 在构件开发和测试完成后，将它们集成到系统中，并组装成完整的软件产品。这可能涉及将多个构件组合在一起，并编写适当的接口和逻辑来确保它们协同工作。
  - 系统测试和验证： 一旦系统被组装完成，就需要对其进行全面的测试和验证，以确保其功能和性能符合预期。这可能包括单元测试、集成测试和系统测试等。
  - 部署和维护： 最后，将系统部署到生产环境中供用户使用，并持续进行维护和支持。在部署后可能会继续发现和修复问题，并对系统进行更新和升级。
6. 喷泉模型（面向对象软件开发）
  - 需求获取和分析： 在每个迭代周期开始时，团队与用户沟通，收集和分析当前阶段的需求。这可能涉及需求讨论会、用户故事编写等活动。
  - 设计和开发： 根据当前迭代的需求，团队进行系统设计和软件开发工作。他们采用增量式的方法，将软件功能逐步实现。
  - 测试和验收： 完成开发后，团队进行测试以验证系统的正确性和稳定性。此外，他们还将软件交付给用户，收集用户的反馈和意见。
  - 反馈和调整： 根据用户反馈和测试结果，团队进行相应的调整和改进。这可能包括修复错误、优化性能、添加新功能等。
  - 重复迭代： 上述步骤循环进行，直到软件的所有功能都得到满足，并且用户对系统的使用体验满意为止。
RUP：迭代地开发软件，管理需求，应用基于构件的构架，为软件建立可视化的模型，不断地验证软件质量，控制软件的变更
敏捷开发与极限编程

敏捷开发是一种基于价值、灵活性和协作的软件开发方法。它强调以下几个核心原则：
1. 个体和交互胜过流程和工具： 敏捷开发注重人与人之间的沟通和合作，认为良好的团队合作比严格的流程更为重要。
2. 可工作的软件胜过详尽的文档： 敏捷开发强调通过实际可工作的软件来展示价值，并尽早地向用户交付产品原型，以便及时获取反馈。
3. 客户合作胜过合同谈判： 敏捷开发鼓励开发团队与客户密切合作，以理解并满足客户需求，而不是仅仅依赖于合同规定的交付物。
4. 响应变化胜过遵循计划： 敏捷开发认识到需求在开发过程中可能会不断变化，因此鼓励灵活地响应变化，而不是固执地遵循既定的计划。
  极限编程是一种敏捷软件开发方法，其目标是提高软件开发过程中的灵活性、通信和反馈。它强调以下几个核心实践：
5. 小步快走（Small Releases）： 小步快走意味着频繁地发布新的软件版本，以便及时获取用户反馈，并及时进行调整和改进。
6. 持续集成（Continuous Integration）： 持续集成是指开发团队频繁地将代码集成到共享存储库中，并自动运行测试，以确保代码质量和稳定性。
7. 测试驱动开发（Test-Driven Development，TDD）： 在TDD中，开发人员先编写测试用例，然后编写足以通过这些测试用例的代码。这有助于提高代码质量和稳定性。
8. 重构（Refactoring）： 重构是指对现有代码进行改进和优化，以提高其可读性、可维护性和性能。
9. 简单设计（Simple Design）： 简单设计是指尽可能保持代码的简洁和清晰，避免过度设计和复杂性。

3 第三章：软件项目管理

3.1 估算软件规模

3.1.1 代码行技术

程序较小用：代码行数（loc）
程序交大时：千代码行数（kloc）

程序仅仅只是软件的一部分，这种估算方式并不合理，而且不同的高级语言编写的软件程序规模很明显不一样

3.1.2 功能点技术

功能点技术的主要步骤：

识别功能需求： 首先，需要识别和理解软件的功能需求。这通常通过需求规格说明文档、用户故事或用例来实现。功能需求可以是用户需要实现的功能，也可以是软件系统必须满足的功能。
功能分类： 将识别到的功能需求按照功能类型进行分类。常见的功能类型包括输入、输出、查询、数据维护等。分类有助于组织和管理功能点估算过程。
确定功能点计算规则： 针对不同的功能类型，确定功能点的计算规则。每个功能类型可能有不同的计算标准，例如输入功能可能按照数据元素的数量来计算，查询功能可能按照查询条件的复杂度来计算。
计算功能点数量： 根据功能点计算规则，对每个功能需求进行功能点数量的估算。这可能需要对需求进行详细的分析和理解，以确保准确地计算功能点数量。
估算开发工时： 根据功能点数量，结合团队的开发经验和历史数据，估算开发所需的工时。通常可以使用每个功能点对应的开发工时来进行估算，然后根据总的功能点数量来计算总的开发工时。
评审和调整： 对估算结果进行评审和调整，根据实际情况对功能点数量和开发工时进行修正和调整。这可能需要团队的讨论和协商，以确保估算结果的合理性和准确性。

估计源代码行：
选择多名有经验的软件工程师分别估算出程序的最小规模（a）、最大规模（b）和最有可能的规模（m），分别计算出这三个数的平均值sa、sb和sm后，再用下面的公式计算程序规模的估计值：

$L OC = (s a + 4 s m + s b) /6$

估算功能点的步骤：

步骤1：计算未调整的功能点数（UFP）

功能分类： 首先，对产品信息域的每个特性进行分类，包括输入（Inp）、输出（Out）、查询（Inq）、文件接口（Maf）和内部逻辑（Inf）。每个特性根据其复杂程度分为简单级、平均级或复杂级。
分配功能点数： 为每个特性分配功能点数，根据其等级确定功能点数。通常，一个简单级的特性分配较少的功能点，而一个复杂级的特性分配更多的功能点。例如，一个简单级的输入项可能分配3个功能点，而一个复杂级的输入项可能分配6个功能点。
计算未调整的功能点数（UFP）： 使用以下公式计算未调整的功能点数（UFP）：

$\times Inp + a2 \times Out + a3 \times Inq + a4 \times Maf + a5 \times Inf$

步骤2：计算技术复杂性因子（TCF）

技术复杂性因子（TCF）度量了软件开发过程中的14种技术因素对软件规模的影响程度。这些因素包括开发环境、开发工具、团队经验等。对每个因素进行评估，并根据其重要性分配一个权重，通常在0.5到2之间。

步骤3：计算功能点数（FP）

计算功能点数（FP）时，将未调整的功能点数（UFP）乘以技术复杂性因子（TCF）得到一个调整后的功能点数，表示软件的规模。公式如下：

$FP \times TCF$

3.2 工作量估算

3.2.1 静态单变量模型

静态：不随时间变化
单变量：一般就是代码行

常见的静态单变量模型：基本COCOMO模型

$\times K L O C^{b}$

其中：

𝐸E 表示软件开发工作量，通常以人月或人年来计量。
𝐾𝐿𝑂𝐶KLOC 是千行源代码数（Kilo Lines of Code），代表软件的规模。
𝑎a 和 𝑏b 是基于历史数据统计得出的经验常数，它们依赖于软件类型（有机型、半嵌入型或嵌入型）。

3.2.2 动态多变量模型

多变量：模型中包含了多个变量，比如代码行数、团队经验、项目风险等级、复用程度、技术新颖性等。通过考虑这些变量的综合影响，模型能够更全面地反映项目的真实情况。
动态调整：模型允许在项目执行过程中根据实际情况调整参数或重新估算，以反映需求变更、资源变动或进度偏差等动态因素对工作量的影响。
数学表达：动态多变量模型通常通过复杂的数学公式或算法来表达这些变量之间的关系，如Putnam模型中的公式 𝐾=𝐿3/(𝐶𝑘3∗𝑡𝑑4)K=L3/(Ck3∗td4)，其中 𝐿L 代表源代码行数，𝐾K 代表工作量，𝑡𝑑td 表示开发持续时间，以及其他可能影响工作量的因素。
适应性和精确性：由于考虑了多种变量，这类模型能够为不同类型的项目提供更个性化的估算，提高了估算的适应性和精确度。

3.3 进度计划

估算开发时间

估算开发时间是指根据项目任务的特性、所需工作量以及团队能力，预估完成每项任务所需的具体时间。这一步骤通常基于工作分解结构(WBS)进行，将大项目分解成小任务，然后逐个估算。
Gantt图
工程网络
估算工程进度

这是基于前面的估算和规划，给出整个工程项目从开始到结束的总体时间预估。它考虑了所有任务的时间需求和依赖关系。
关键路径

关键路径是工程网络中最长的路径，决定了项目的最短完成时间。关键路径上的任何延误都将直接影响整个项目的完成日期。
机动时间（浮动时间/松弛时间）

浮动时间是指在不影响项目总工期的情况下，某任务可以延迟的时间。非关键路径上的任务通常有浮动时间。

3.4 质量保证

3.4.1 措施

基于非执行的测试（也称为复审或评审）
基于执行的测试（即以前讲过的软件测试）
程序正确性证明

3.5 软件配置管理

版本控制
配置项管理
变更管理
构建与发布管理
配置审计与合规性
环境管理
协作支持

4 第五章：结构化需求分析

结构化分析的主要技术
结构化分析方法的实现步骤
编写需求规格说明书

4.1 结构化分析的主要技术

描述逻辑模型→数据流程图

数据流程图是描绘信息在系统中的流动和处理，不能反映控制逻辑
描述数据项和数据结构→数据字典
描述处理内容→IPO图表
描述数据实体之间关系→实体关系图

4.2 结构化分析方法的实现步骤

信息分析
回溯
补充
确定非功能需求：性能指标、接口定义、设计和实现的约束条件
复查
修正开发计划
编写需求文档

4.3 编写需求规格说明书（SRS）

必须描述软件具备的功能和性能；
必须用确定的、无二义性的、完整的语句来描述功能和性能。

软件需求规格说明书描述的内容：

软件功能
软件性能
设计限制
质量属性
外部接口

4.4 软件设计的基本概念

4.4.1 耦合和内聚

偶然内聚

模块里的语句没什么联系，只是大家刚好都要用到，于是提炼成一个模块

var getName = function(){
var result = 1 + 2; //计算1+2
console.log("hello"); //打印say hello
}

逻辑内聚

逻辑内聚就是把逻辑上做通一件事，但是方式上有区别的功能聚合在一起

比如上传用户数据：
- 上传文字数据
- 上传图片数据
  他们都是处理上传用户数据，但是处理对象和方式有所不同
时间内聚

时间内聚里的功能必须是在时间上具有强关联性的，必须是同时进行或者必须依次进行
过程内聚

过程内聚里的各部分必须都是相关的，他们依次执行共同完成一个完整的功能
通信内聚

通信内聚里的各个部分都是对“同一个对象”进行处理，及时他们做的处理可能不同
顺序内聚

其实和过程内聚有点像，更严格一点，上一个的输出必须是下一个的输入
功能内聚

功能内聚是模块设计中的一种原则，它指的是模块内部的元素（代码段、函数等）紧密地组合在一起，共同完成一个单一、明确的功能。换句话说，模块内的所有操作都直接关联并服务于该模块的主要目的，没有多余的或偏离这一中心目标的活动。这种内聚类型被认为是最高级别且最理想的内聚形式，因为它提高了代码的可读性、可维护性和可重用性。

耦合：

看例题

4.4.2 抽象

第一层次：用大白话描述任务是干啥
第二层次：讲出“要干什么”
第三层次：讲出“要怎么做”

4.4.3 信息隐藏

一个模块中所包含的信息，不允许其他不需要这些信息的模块访问。

对模块的过程细节和局部数据结构进行了屏蔽

当出现错误时能尽可能不波及软件的其他范围

4.4.4 软件结构图

A根据条件选择调用B，C，D

A循环调用B，C，D

深度和宽度以及扇入扇出的定义

4.5 软件设计原则和影响设计的因素

软件设计原则：

设计可以回溯需求
充分利用已有的模块
遵循高内聚、低耦合和信息隐藏
设计表现出规范性和一致性
容错性设计
颗粒度适当（不应太详细）
设计开始就要评估软件质量

4.6 结构化设计方法

结构化设计方法通常也叫做面向数据流的设计或面向过程的设计。

数据流程图→软件结构图

4.7 优化软件结构设计

数据流程图转换为软件结构图，应该对软件结构图进行优化。使其符合高内聚低耦合的、模块化、信息隐藏的原则。

模块功能完善化
设计功能单一和结果可预测的模块
消除重复功能，改善软件结构
模块的作用范围应在控制范围之内
模块的大小要适中
尽可能减少高扇出和高扇入的结构
将模块中相对变化较大的部分剥离出去

5 第六章

5.1 UML

构造块：基本UML建模元素、关系和图
1. 物件：建模元素本身
  1. 结构物件：UML模型中的名词，如类、接口、协作、用例、活动类、组件、节点
  2. 行为物件：UML模型的动词，如交互、状态机
  3. 分组物件：包，它用于把语义上相关的建模元素分组为内聚的单元
  4. 注解物件：注解，它附加到模型以捕获特殊信息，同黄色便笺很相像
2. 关系：把物件联系在一起，关系说明两个或多个物件时如何语义相关的
  1. 关联：描述对象之间的一组链接
  2. 依赖：事物的改变引起依赖物件的语义改变
  3. 泛化：一个元素是另一个元素的特化，而且它可以取代更一般的元素
  4. 实现：类元之间的关系，一个类元说明一份契约，另一个类元保证实现该契约
3. 图：UML模型的视图，它们展现物件的集合，“讲述关于软件系统的故事”，是可视化系统将做什么（分析级图）或者系统如何做（设计级图）的方法
  - 类图：描述类的静态结构
  - 对象图：类图的实例
  - 顺序图：消息在对象之间发送的顺序，显示对象之间的交互
  - 协作图：协作图跟顺序图相似，显示对象间的动态合作关系。除显示信息交换外，协作图还显示对象以及它们之间的关系
  - 状态图：状态图是一个类对象所可能经历的所有历程的模型图。
  - 活动图：活动图是状态图的一个变体，用来描述执行算法的工作流程中涉及的活动
  - 构件图：构件图为系统的构件建模型—构件即构造应用的软件单元—还包括各构件之间的依赖关系，以便通过这些依赖关系来估计对系统构件的修改给系统可能带来的影响
  - 部署图：部署视图描述位于节点实例上的运行构件实例的安排。
公共机制：达到特定目标的公共UML方法
1. 规格说明
2. 修饰
3. 公共分类
4. 扩展机制
架构：系统架构的UML视图
1. 用例视图
2. 逻辑视图
3. 进程视图
4. 实现视图
5. 部署视图

5.2 用例图

参与者：外部用户
用例：一个系统功能单元

粒度原则：用例要有路径，路径要有步骤。而这一切都是“可观测”的

用例文档：

5.3 类图

类名：必须唯一，首字母大写，多单词合并写，如果有包名表示为包名::类名
属性
- 公共
- 私有
- 保护
- 实现
  子类只能访问公共和保护
类别：
- 接口：只有声明没有实现
- 抽象类：不能被实例化
- 模版类：只提供一个模板，用于其他类具体实现
分类
- 边界类：数据输入输出
- 实体类：存储实体信息
- 控制类：协调用例调用顺序等
类间关系
- 关联：使用类指向被使用类
- 聚合：整体拥有局部
- 组合关系：更加强烈的拥有关系，没有整体就没有局部的那种
- 依赖：简单的调用关系，调用类指向被调用类
- 泛化：特殊指向一般
- 实现：实现指向接口
关联类：
总结：
- 当某个类被当作参数传递并且被当作结果返回的时候，或者被当作某个方法内的临时变量使用的时候,可以运用依赖关系；
- 使用关联来表示一个拥有关系，而不是整体-部分关系；
- 使用聚合来表示一个动态的整体-部分关系；
- 用组合来表示一个静态的整体-部分关系