《软件工程》知识点复习总结

Posted 2021-06-30 繁凡さん

目录

• 一、软件及软件工程
• • 1. 软件的本质
  • 2. 软件危机
  • 3. 软件工程定义
  • 4. 软件生命周期
• 二、软件过程及过程模型
• • 1. 软件过程
  • 2. 软件过程模型
  • 3. 通用过程模型
  • 4. 过程流
  • 5. 过程模型
  • • 5.1 瀑布模型
    • 5.2 原型开发模型（快速原型）
    • 5.3 增量模型
    • 5.4 螺旋模型
    • 5.5 专用过程模型
    • 5.6 形式化方法模型
• 三、敏捷开发
• • 敏捷开发
  • 敏捷原则
  • 敏捷过程
  • 极限编程XP
  • Scrum
• 四、软件需求
• • 软件需求
  • 需求工程
  • 需求获取技术
• 五、需求建模
• • 需求建模概述
  • 基于场景的建模
  • 基于数据流的建模
  • 基于数据的建模
  • 面向状态的建模方法
• 六、软件设计
• 七、软件测试
• 八、软件项目管理

一、软件及软件工程

1. 软件的本质

计算机软件 指计算机系统中的程序、数据及其相关文档

三要素：

程序：按照特定顺序组织的计算机数据和指令的集合。

数据：使程序能正常执行的数据结构

文档：为了便于理解程序所需的与开发、维护和使用有关的资料

软件 = 程序 + 文档 + 数据

软件的特点

• 软件是设计开发的，而不是传统意义上生产制造的。

• 软件不会“磨损”，但会退化。

• 大多数软件还是用户定制的。

计算机软件可分为七个大类：

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

另一种分类

• 系统软件：
  位于计算机系统中最靠近硬件的一层，其它软件一般都通过系统软件发挥作用，它与具体的应用领域无关。如操作系统、编译程序等。

• 支持软件：
  支持软件的开发和维护的软件。如数据库管理系统、网络软件、软件开发环境等。

• 应用软件：
  特定应用领域专用的软件。如实时软件、嵌入式软件、科学和工程计算软件、事务处理软件、人工智能软件等。

2. 软件危机

软件危机(Software Crisis)：计算机软件的开发和维护过程所遇到的一系列严重问题。

软件危机的表现：

• 对软件开发成本和进度的估算很不准确，甚至严重拖期和超出预算；
• 无法满足用户需求，导致用户很不满意；
• 质量很不可靠，经常失效；
• 难以更改、调试和增强；
• 没有适当的文档；
• 软件成本比重上升；
• 软件开发生产率跟不上计算机应用迅速深入的趋势。

软件为什么要更新和迭代？

• 软件必须适应新的计算环境或技术的需要。
• 必须增强软件来实现新的业务需求。
• 软件必须扩展到与其他更现代的系统或数据库进行互操作。
• 必须重新构建软件，使其在网络环境中可行。

为什么会产生软件危机？

• 与软件本身的特点有关 (难于维护, 逻辑复杂)
• 与软件开发与维护的方法不正确有关

3. 软件工程定义

1993年IEEE进一步给出了一个更全面更具体的定义：

软件工程是：
（1）将系统化的、规范化、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。
（2）在（1）中所述方法的研究

《计算机科学技术百科全书》中的定义：

软件工程是应用计算机科学、数学及管理科学等原理开发软件的工程。软件工程借鉴传统工程的原则、方法，以提高质量、降低成本。其中，计算机科学、数学用于构建模型与算法，工程科学用于制定规范、设计范型(paradigm)、评估成本及确定权衡，管理科学用于计划、资源、质量、成本等。

软件工程的内容

• 软件工程是一种层次化的技术。任何工程方法必须构建在质量承诺的基础上。
• 软件工程的基础是过程。软件过程将各个技术层次结合在一起，使得合理及时地开发计算机软件成为可能。
• 软件工程方法为构建软件提供技术上的解决方法。
• 软件工程工具为过程和方法提供自动化或半自动化的支持。
  

软件工具是指能支持软件生存周期中某一阶段（如系统定义、需求分析、设计、编码、测试或维护等）的需要而使用的软件工具。

4. 软件生命周期

软件生命周期， 又称为软件生存周期，是软件从产生直到报废的整个时期。

思考

1. 什么是计算机软件？软件的特点是什么？
2. 何谓“软件危机”？
3. 主要有哪些软件工程方法？软件工程有哪三个要素？
4. 软件生命周期主要包含哪几个阶段？

二、软件过程及过程模型

1. 软件过程

• （教材）一个为创建高质量软件所需要完成的活动、动作和任务的框架 。

• （百度百科）一个为建造高质量软件所需完成的任务的框架，即形成软件产品的一系列步骤，包括中间产品、资源、角色及过程中采取的方法、工具等范畴。

通用活动

• 沟通：包含了与客户(和其他共利益者)之间大量的交流和协作，还包括需求获取以及其他相关活动。
• 策划：指为后续的软件工程工作制定计划。它描述了需要执行的技术任务、可能的风险、资源需求、工作产品和工作进度计划。
• 建模：包括创建模型和设计两方面。创建模型有助于客户和开发人员更好地理解软件需求；设计可以实现需求。
• 构建：包括编码(手写或自动生成)和测试。
• 部署：软件(全部或者完成的部分)交付到用户，用户对其进行评测并给出反馈意见。

2. 软件过程模型

• 也称 软件开发模型 或 软件生存周期模型

• 是软件生存周期中一系列有序的软件开发活动的流程，是软件开发全部活动的结构框架。

• 对一个软件的开发无论其大小，都需要选择一个合适的软件过程模型，主要根据软件的类型、规模，开发方法、开发环境等多种因素来确定。

3. 通用过程模型

4. 过程流

5. 过程模型

• 写了再改模型
• 瀑布模型
• 增量过程模型
• 演化过程模型
  • 原型开发模型
  • 螺旋模型
• 并发模型
• 基于构件的开发

5.1 瀑布模型

瀑布模型的变体–V模型

瀑布模型的特点

• 阶段间具有顺序性和依赖性
• 推迟实现的观点
• 质量保证的观点

瀑布模型的优点

• 可强迫开发人员采用规范的方法（例如，结构化技术）。
• 要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
• 严格地规定了每个阶段必须提交的文档。

瀑布模型的问题

• 难以应对需求变化：客户难以准确表达需求，软件团队很难准确理解需求。
• 过于理想：实际项目很少按照该模型给出的顺序进行；
• 风险太大：用户必须有耐心，等到系统开发完成才能见到软件；
• 阻塞状态：开发者常常被不必要地耽搁。

瀑布模型的适用场合

• 需求相当稳定，客户需求被全面的了解风险管理。
• 开发团队对于应用领域非常熟悉。
• 外部环境的不可控因素很少。
• 小型清晰的项目。

5.2 原型开发模型（快速原型）

原型开发模型的产生：

• 瀑布模型将软件生命周期划分成独立串行的几个阶段，前一个阶段没有完成便无法开始下一阶段的工作。

• 然而完整而准确的需求规格说明是很难得到的，因为：
  在开发早期用户往往对系统只有一个模糊的想法，很难完全准确地表达对系统的全面要求

• 随着开发工作的推进，用户可能会产生新的要求

• 开发者又可能在设计与实现的过程中遇到一些没有预料到的实际困难，需要以改变需求来解脱困境

原型（prototype）是预期系统的一个可执行版本，它反映了系统性质（如功能、计算结果等）的一个选定的子集。

一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型。被开发的原型应交付给客户试用，并收集客户的反馈意见，这些反馈意见可在下一轮迭代中对原型进行改进。在前一个原型需要改进，或者需要扩展其范围的时候，进入下一轮原型的迭代开发

原型开发的优点

• 快速开发出可以演示的系统，方便了客户沟通。

• 采用迭代技术能够使开发者逐步弄清客户的需求。

原型的使用策略：

• 废弃（throw away）策略
  主要用于探索型和实验型原型的开发。这些原型关注于目标系统的某些特性，而不是全部特性，开发这些原型时通常不考虑与探索或实验目的无关的功能、质量、结构等因素，这种原型通常被废丢，然后根据探索或实验的结果用良好的结构和设计思想重新设计目标系统

• 追加（add on）策略
  主要用于演化型原型的开发。这种原型通常是实现了目标系统中已明确定义的特性的一个子集，通过对它的不断修改和扩充，逐步追加新的要求，最后使其演化成最终的目标系统

原型模型— 适用情况

• 用户定义了一组一般性目标，但不能标识出详细的输入、处理及输出需求；

• 开发者可能不能确定算法的有效性、操作系统的适应性或人机交互的形式；

5.3 增量模型

• 增量模型以迭代的方式运用瀑布模型。

• 随着时间的推移，发布一系列称为增量的版本，随着每个版本的交付，逐步为用户提供更多的功能。

增量模型的使用方法

• 软件被作为一系列的增量来进行开发，每一个增量都提交一个可以操作的产品，可供用户评估。

• 第一个增量往往是核心产品：满足了基本的需求，但是缺少附加的特性。

• 客户使用上一个增量的提交物并进行评价，制定下一个增量计划，说明需要增加的特性和功能。

• 重复上述过程，直到最终产品产生为止。

增量模型的优点

• 提高对用户需求的响应：用户看到可操作的早期版本后会提出一些建议和需求，可以在后续增量中调整。

• 人员分配灵活：如果找不到足够的开发人员，可采用增量模型，早期的增量由少量人员实现，如果客户反响较好，则在下一个增量中投入更多的人力。

• 可规避技术风险：不确定的功能放在后面开发。

增量模型存在的问题

• 每个附加的增量并入现有的软件时，必须不破坏原来已构造好的东西。

• 加入新增量时应简单、方便 ——软件的体系结构应当是开放的。

• 仍然无法处理需求发生变更的情况。

• 管理人员须有足够的技术能力来协调好各增量之间的关系。

• 难以确定所有版本共需的公用模块。

5.4 螺旋模型

Boehm于1988年提出，是一种演化过程模型，主要针对大型软件项目的开发。
风险驱动的软件开发模型

采用循环的方式，逐步加深系统定义和实现的深度，确定一系列里程碑，确保stakeholders都支持系统解决方案。

第一圈一般开发出产品的规格说明，接下来开发产品的原型系统，并在每次迭代中逐步完善，开发不同的软件版本，结合了原型的迭代性质和瀑布模型的可控性、系统性特点。

螺旋模型的优点

• 结合了原型的迭代性质与瀑布模型的系统性和可控性，是一种风险驱动型的过程模型。

• 采用循环的方式逐步加深系统定义和实现的深度，同时更好地理解、应对和降低风险。

• 确定一系列里程碑，确保各方都得到可行的系统解决方案。

• 始终保持可操作性，直到软件生命周期的结束。

• 风险驱动。

螺旋模型存在的问题

• 螺旋模型依赖大量的风险评估专家来保证成功。如果有较大的风险没有被发现和管理，肯定会发生问题。

• 软件开发人员应该擅长寻找可能的风险，准确的分析风险，否则将会带来更大的风险。

5.5 专用过程模型

• 基于构件的开发 — 能够使软件复用

• 形式化方法模型 — 注重需求的数学规格说明

• 面向方面的软件开发 — 为定义、说明、设计和构建方面提供过程和方法

• 统一过程 — 一种“用例驱动、以构架为中心的迭代和增量”，软件过程和统一建模语言(UML)紧密结合

基于构件的开发

是在一定构件模型的支持下，复用构件库中的一个或多个软件构件，通过组合手段（集成）高效率、高质量地构造应用软件系统的过程。

优点：

• 充分利用软件复用，提高了软件开发的效率。

• 允许多个项目同时开发，降低了费用，提高了可维护性，可实现分步提交软件产品。

缺点：

• 缺乏通用的构件组装结构标准，风险较大；

• 构件可重用性和系统高效性之间不易协调；

• 由于过分依赖于构件，构件质量影响着最终产品的质量。

5.6 形式化方法模型

从广义上讲，形式化方法是借助数学的方法来解决软件工程领域的问题，主要包括建立精确的数学模型以及对模型的分析活动。
狭义的讲，形式化方法是运用形式化语言，进行形式化的规格描述、模型推理和验证的方法。
形式化方法原则上就是用数学与逻辑的方法描述和验证软件。
可以实现从描述到实现的自动转换。

优点

• 能够开发出无缺陷的软件

缺点

• 成本高、耗时

• 对开发人员的技术水平要求高

三、敏捷开发

敏捷开发

软件更像一个活着的植物，软件开发是自底向上逐步有序的生长过程，类似于植物自然生长

敏捷开发遵循软件客观规律，不断的进行迭代增量开发，最终交付符合客户价值的产品

敏捷价值观

• 个人和他们之间的交流胜过开发过程和工具

• 可运行的软件胜过宽泛的文档

• 客户合作胜过合同谈判

• 对变更的良好响应胜过按部就班地遵循计划

敏捷原则

1. 我们最优先要做的是通过尽早、持续交付有价值的软件来使客户满意。
2. 即使在开发的后期，也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。
3. 经常交付可运行软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 （小步快跑）
4. 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5. 围绕有积极性的个人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
6. 在团队内部，最富有效果和效率的信息传递方法是面对面交谈。
7. 可运行软件是进度的首要度量标准。
8. 提倡可持续的开发速度。责任人(sponsor)、开发者和用户应该能够长期保持稳定的开发速度。
9. 不断地关注优秀的技能和好的设计会增强敏捷能力。
10. 简单——是减少不必要工作量的艺术——是必要的
11. 最好的架构、需求和设计出自于自组织团队。
12. 每隔一定时间，团队会反省如何才能更有效地工作，并相应调整自己的行为。

敏捷过程

基于敏捷原则进行的软件开发过程，视为敏捷过程。
敏捷过程模型

• 极限编程
• Scrum
• 自适应软件开发（ASD）
• 动态系统开发方法（DSDM）
• 特征驱动开发（FDD）
• 精益软件开发（LSD）
• 敏捷建模AM
• 敏捷统一过程AUP

极限编程XP

极限编程是敏捷软件开发中应用最为广泛和最富有成效的几种方法学之一。
极限编程的主要目标在于降低因需求变更而带来的成本。
采用迭代的交付方式，每个迭代很短（1-3周时间）。在每个迭代结束的时候，团队交付可运行的，经过测试的功能，这些功能可以马上投入使用。

• XP 编码
  • 鼓励“测试驱动开发(TDD)”
  • 鼓励“结对编程”
  • 鼓励“重构”
• XP 测试
  • 每天进行集成和确认测试（持续集成）
  • “验收测试” 由客户确定，根据本次软件发布中所实现的用户故事而确定。

Scrum

• 一种敏捷开发的模型。
• 采用短周期迭代交付方式

Scrum 流程包括：
3个角色
3个工件
5个活动

Scrum中的角色

• 同项目经理类似的Scrum主管:负责维护过程和任务
• 产品负责人代表利益所有者
• 开发团队包括了所有开发人员

Scrum的工件（资料、文档）

• Product Backlog产品订单
• Sprint Backlog冲刺订单
• Burndown chart燃尽图

Scrum的活动

• Sprint冲刺
• Sprint planning meeting冲刺计划会
• Daily standup meeting每日立会
• Sprint review冲刺评审会
• Retrospective meeting回顾会议

四、软件需求

1、什么是软件需求？
2、软件需求分类
3、需求工程
4、需求获取技术
5、竞争性需求分析
6、需求规格说明书
7、案例分析

软件需求

• 用户解决问题或达到目标所需的条件和能力
• 系统或系统部件为满足合同、标准、规范或其它正式规定文档所需具有的条件和能力
• 以上条件和能力的文档说明

软件需求的三个层次:

• 业务需求
• 用户需求
• 功能需求

业务需求

业务需求(business requirement)反映了组织机构或客户对系统、产品高层次的目标要求

用户需求

用户需求(user requirement)描述了用户使用产品必须要完成的任务。

功能需求

系统分析员描述 开发人员在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。
功能需求是需求的主体，它描述的是开发人员如何设计具体的解决方案来实现这些用户需求（how），其数量往往比用户需求高一个数量级。

• 功能需求：描述系统预期提供的功能或服务

• 非功能需求：不直接与系统具体功能相关的需求。

需求工程

应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。
它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。

需求工程的基本活动

获取需求
细化(需求分析)
协商
编写需求规格说明
确认需求
需求管理

需求分析的目的:

• 说明软件的工作特征
• 指明软件和其他系统元素的接口
  规定软件必须满足的约束

需求分析的主要任务：

• 细化在前期需求工程的基础需求
• 构建一种或多种模型以描述用户场景、功能活动、类、类之间的关系、系统和类的行为、数据流等

需求获取技术

面谈
调查
观察实际业务过程
原型法
头脑风暴
场景技术

五、需求建模

需求建模的元素

• 场景模型
  出自各种系统“参与者”观点的需求

• 数据模型
  描述问题信息域的模型(用于建立数据库)

• 类模型
  表示面向对象类（属性和操作）的模型

• 数据流模型
  描述功能元素在系统中运行时怎样进行数据变换

• 行为模型
  描述系统的外部行为

需求建模概述

需求建模的总体目标:

• 描述客户需要什么；
• 为软件设计奠定基础；
• 定义在软件完成后可以被确认的一组需求。

基于场景的建模

用例：

用于表示系统所提供的服务，描述参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话（交互）。

场景：

场景是用例的实例化，从一个用例可以实例化出来多个用例场景。用例就是对全部场景的抽象。

基于数据流的建模

结构化方法概述

一种面向数据流的传统软件开发方法，以数据流为中心构建软件的分析模型和设计模型

分为：

• 结构化分析(Structured Analysis 简称SA)

• 结构化设计(Structuresd Design 简称SD)

• 结构化程序设计(Structured Programmin 简称SP)

结构化的需求分析模型：

• 功能模型（数据流模型），用来描述系统中的数据处理过程

• 行为模型（状态转换模型），用来描述系统如何对事件做出响应

• 数据模型（实体—关系模型）：用来描述系统中的数据及其之间的关系。

数据字典是模型的核心，它包含了软件使用和产生的所有数据的描述

数据流图（DFD，Data Flow Diagram）服务于两个目的：一是指明数据在系统中移动时如何被变换，二是描述对数据流进行变换的功能和子功能。

数据流图符号

Data Flow Diagram(简称DFD)：描述输入数据流到输出数据流的变换(即加工、处理)过程，用于对系统的功能建模，基本元素包括:

数据流图举例

设一个工厂采购部每天需要一张定货报表。定货的零件数据有：零件编号、名称、数量、价格、供应者等。零件的入库、出库事务由仓库管理员通过计算机终端输入给定货系统。当某零件的库存数少于给定的库存量临界值时，就应该再次定货。
数据流分析：
数据源点：仓管员（负责入库或出库事务给定货系统）；
数据终点：采购员（接收每天的定货报表）；
数据流：事务，定货报表；
数据存储：定货信息，库存清单；

数据流图的各个层次

• 顶层图（第0层）只有代表整个软件系统的1个加工，描述了软件系统与外界之间的数据流
• 顶层图中的加工经分解后的图称为第1层图(只有1张)
• 中间层图中至少有一个加工(也可以有多个)在下层图中分解成一张子图
• 处于最底层的图称为底层图，其中所有的加工不再分解成新的子图

分层数据流图示例——资格和水平考试的考务处理系统

简化的资格和水平考试的考务处理系统
分成多个级别，如初级程序员、程序员、高级程序员、系统分析员等，凡满足一定条件的考生都可参加某一级别的考试
考试的合格标准将根据每年的考试成绩由考试中心确定
考试的阅卷由阅卷站进行，因此，阅卷工作不包含在软件系统中

资格和水平考试的考务处理系统—功能需求

1．对考生送来的报名单进行检查
2．对合格的报名单编好准考证号后将准考证送给考生，并将汇总后的考生名单送给阅卷站
3．对阅卷站送来的成绩清单进行检查，并根据考试中心制订的合格标准审定合格者
4．制作考生通知单送给考生
5．进行成绩分类统计(按地区、年龄、文化程度、职业、考试级别等分类)和试题难度分析，产生统计分析表

画顶层图

• 确定源点和终点

• 确定顶层图的加工

• 确定数据流（系统的输入/输出信息）

• 确定存储

确定源点和终点：考生、阅卷站和考试中心
它们都既是源点又是终点
顶层图唯一的加工：软件系统(考务处理系统)
确定数据流：系统的输入/输出信息
输入数据流：报名单(来自考生)、成绩清单(来自阅卷站)、合格标准(来自考试中心)
输出数据流：准考证(送往考生)、考生名单(送往阅卷站)、考生通知书(送往考生)、统计分析表(送往考试中心)
额外的输出流(考虑系统的健壮性)：不合格报名单(返回给考生)，错误成绩清单(返回给阅卷站)
顶层图通常没有文件

考务处理系统顶层图

考务处理系统1层图

根据功能需求对功能进行分解：考务处理系统可分解为两部分
一、考试报名
1．对考生送来的报名单进行检查
2．对合格的报名单编好准考证号后将准考证送给考生，并将汇总后的考生名单送给阅卷站
（需要增加存储：考生名册）
二、统计成绩
3．对阅卷站送来的成绩清单进行检查，并根据考试中心制订的合格标准审定合格者
4．制作考生通知单送给考生
5．进行成绩分类统计(按地区、年龄、文化程度、职业、考试级别等分类)和试题难度分析，产生统计分析表

基于数据的建模

面向状态的建模方法

六、软件设计

七、软件测试

八、软件项目管理