现代软件工程期末复习–基础知识

1. 软件工程师及软件团队

讲解了一些软件工程师的规范和团队规范

没啥看的，暂时忽略

2. 软件及其过程

什么是软件？

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

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

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

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

• 软件=程序+文档+数据，三要素

软件的特点？

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

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

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

软件的分类？

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

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

• 其中后三者为最近二十年出现的新形态

• 另外一种分类方式：是分为系统数据（位于计算机系统中最靠近硬件的一层，如操作系统、编译程序）、支持软件（支持软件的开发和维护的软件。如数据库管理系统、网络软件、软件开发环境等）、应用软件（特定应用领域专用的软件。如实时软件、嵌入式软件）

软件技术的演化？

• 第一阶段：程序设计阶段 。个体手工方式（小程序）
• 第二阶段：程序系统阶段。小组化生产，出现软件危机（软件作坊）
• 第三阶段：传统软件工程阶段。工程化的思想引入，结构化方法的发展
• 第四阶段：面向对象阶段。面向对象方法

软件危机

• 软件危机(Software Crisis)：计算机软件的开发和维护过程所遇到的一系列严重问题。（tip：反正什么开发问题都算作软件问题就玩了）

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

什么是软件工程？

• 软件工程是：①把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件； ②研究①中提到的途径

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

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

• 软件生命周期模型：

• 软件神话：关于软件及其开发过程的一些说法被人盲目相信

3.软件过程及其过程模型

• 什么是软件过程？一个为创建高质量软件所需要完成的活动、动作和任务的框架

软件过程模型

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

• 软件过程模型有那些：
  1. 写了再改模型Code-and-fix—–字面意思
  2. 瀑布模型—– 将软件生命周期划分为软件计划、需求分析、设计、实现、测试、运行和维护等阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。严格按照流程一步步来
  - 特点:阶段间具有顺序性和依赖性
  推迟实现的观点
  质量保证的观点
  - 优点：规范了
  - 缺点：1.难以应对需求变化
  2.过于理想：实际项目很少按照该模型给出的 顺序进行；
  3.风险太大：用户必须有耐心，等到系统开发完成才能见到软件；
  4.阻塞状态：开发者常常被不必要地耽搁。
  - 适用于需求稳定。外部干扰少

        3. 原型开发模型（快速原型）（演化过程模型的一种）
       - 最开始是一个原型版本发布，之后不断对原型迭代
  

1. 增量模型

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

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

   • 就像游戏中的dlc，不断迭代完善增加功能

   • 优点：提高对用户需求的响应；人员分配灵活（一个个增量看情况投入人力）；可规避技术风险（不确定的功能后面开发）

   • 缺点：加入新增量时应简单、方便；每个附加的增量并入现有的软件时，必须不破坏原来已构造好的东西；仍然无法处理需求发生变更的情况;管理人员须有足够的技术能力来协调好各增量之间的关系;难以确定所有版本共需的公用模块

        5. 螺旋模型（演化过程模型的一种）
     
      * 风险驱动的软件开发模型  
     

     采用循环的方式，逐步加深系统定义和实现的深度
     确定一系列里程碑，确保stakeholders都支持系统解决方案
     第一圈一般开发出产品的规格说明，接下来开发产品的原型系统，并在每次迭代中逐步完善，开发不同的软件版本

      * 结合了原型的迭代性质和瀑布模型的可控性、系统性特点
      * ![](/img/b/1709662792646.jpg)
      * 优点：结合了原型的迭代性质与瀑布模型的系统性和可控性，是一种风险驱动型的过程模型；等
      * 缺点：螺旋模型依赖大量的风险评估专家来保证成功。如果有较大的风险没有被发现和管理，肯定会发生问题；软件开发人员应该擅长寻找可能的风险，准确的分析风险，否则将会带来更大的风险。
        6. 专用过程模型：
     
      * 基于构件的开发—能够使软件复用
      * 形式化方法模型—注重需求的数学规格说明
      * 面向方面的软件开发—为定义、说明、设计和构建方面提供过程和方法
      * 统一过程—一种“用例驱动、以构架为中心的迭代和增量”，软件过程和统一建模语言(UML)紧密结合
     

4. 敏捷过程

什么是敏捷？

是一种从90年代开始逐渐引起广泛关注的一些新型软件开发方法。如极限编程（xp） ( Extreme Programming )和Scrum用到了敏捷

• 2001~今，正在流行

敏捷宣言

• 在瀑布模型还是主流的时代一些软件开发人员一起宣布了“反叛宣言”，制定并签署了行业历史上最重要的文件之一:敏捷宣言。
• 内容：个人和他们之间的交流胜过开发过程和工具
  可运行的软件胜过宽泛的文档
  客户合作胜过合同谈判
  对变更的良好响应胜过按部就班地遵循计划

什么是敏捷过程？

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

敏捷过程模型有：极限编程、Scrum等

极限编程XP（Extreme Programming）

• 采用迭代的交付方式，每个迭代很短（1-3周时间）。在每个迭代结束的时候，团队交付可运行的，经过测试的功能，这些功能可以马上投入使用。
• 极限编程的主要目标在于降低因需求变更而带来的成本

Scrum

• 英语意为争球
• 采用短周期迭代交付方式
• Scrum 流程包括：
  3个角色
  3个工件
  5个活动

5. 软件需求

什么是软件需求？

软件需求的三个层次：业务需求
用户需求
功能需求

• 业务需求反映了组织机构或客户对系统、产品高层次的目标要求。描述了为什么要开发系统（why）
• 用户需求描述了用户使用产品必须要完成的任务。描述了用户能使用系统来做些什么（what）
• 功能需求是需求的主体，它描述的是开发人员如何设计具体的解决方案来实现这些用户需求（how），其数量往往比用户需求高一个数量级。

软件需求的分类

• 功能需求和非功能需求。
• 功能需求描述系统预期提供的功能或服务
• 非功能需求：不直接与系统具体功能相关的需求。如产品需求/机构需求、外部需求

需求工程

应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。

需求获取技术

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

需求规格说明书

没啥说的，应该考不了

6.需求建模

基于场景的建模

你可以理解基于用例。主要步骤就是传统的步骤包括：识别参与者、识别用例、绘制用例图、编写用例描述

用例图怎么画才学过应该不会忘吧，

编写用例描述类下：

基于数据流的建模

• 一种面向数据流的传统软件开发方法

• 以数据流为中心构建软件的分析模型和设计模型

• 分为：
  结构化分析(Structured Analysis 简称SA)
  结构化设计(Structuresd Design 简称SD)
  结构化程序设计(Structured Programmin 简称SP)

• 画数据流图：画顶层图（人员，系统）、1层图（系统分解成各种功能）、2层图（再细分功能，如处理事务分解为处理入库、加工入库等）

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

一层图：

二层加工：

描写数据流图条目：

面向数据的建模方法

• 是按照用户的观点对数据建立的模型。它描述了从用户角度看到的数据，反映了用户的现实环境，而且与在软件系统中的实现方法无关。
• 数据模型中包含3种相互关联的信息：数据对象（实体）、数据对象的属性及数据对象彼此间相互连接的关系。
• 表现图形就是：实体-联系图（ER图）

7.软件设计

软件设计概念

软件的设计是将需求转变为软件陈述（表达）的过程。这种陈述是一个对软件的全局观点。系统通过逐步求精使得设计陈述逐渐接近程序代码。

• 第一步是概要设计，关注于怎么将需求转换成数据和软件框架。
• 第二步是详细设计，关注于将框架逐步求精细化为具体的数据结构和软件的算法表达。

设计概念：

抽象——数据，过程，控制
体系结构——软件的整体结构
模式——传递已验证设计方案的精髓
关注点分离——任何复杂问题在被分解为若干块后将更易处理
模块化——数据和功能的分割
（信息）隐蔽——控制接口
功能独立——单一功能和低耦合
求精——细化所有抽象的细节
方面——理解全局需求如何影响设计的机制
重构——简化设计的重组技术
面向对象的设计概念—。。。。继承、多态、类等

体系结构设计

• 两种方法：

  • 结构化设计
    数据流模型->软件结构图

  • 面向对象设计
    用例模型->分析类图->设计类图->构件图

• 结构化设计：两级分解：

  • 第一级分解是将数据流图映射成变换型的程序结构：

主控模块：完成整个系统的功能

输入流控制模块：接收所有输入数据

变换流控制模块：对内部形式的数据进行加工处理，实现输入到输出的变换

输出流控制模块：产生所有输出数据

• 第二级分解：

  1. 输入流控制模块的分解：
     从变换中心的边界开始，沿着输入通路向外移动，把输入通路上的每个加工映射成程序结构中输入流控制模块的一个低层模快

  2. 输出流控制模块的分解：
     从变换中心的边界开始，沿着输出通路向外移动，把输出通路上的每个加工映射成程序结构中输出流控制模块的一个低层模快

  3. 变换流控制模块的分解：
     把变换中心的每个加工映射成受变换控制模块控制的一个低层模块

构件设计

基本原则：高内聚，低耦合

处理逻辑的表示工具：活动图、流程图

界面设计

• 黄金规则：
  1. 把控制权交给用户
  2. 减少用户的记忆负担
  3. 保持界面一致

8.软件测试

软件测试描述

• 广义：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
• 测试是为了证明程序中有错误，而不是证明程序中无错误
• 一个好的测试用例指的是它可能发现至今尚未发现的缺陷
• 一次成功的测试指的是发现了新的软件缺陷的测试
• 设计测试用例要设计尽可能少的测试用例来发现尽可能多的错误
• 白盒测试（又称为结构测试）把测试对象看作一个透明的盒子，测试人员根据程序内部的逻辑结构及有关信息设计测试用例，检查程序中所有逻辑路径是否都按预定的要求正确地工作,白盒测试主要用于对模块的测试.
• 黑盒测试（又称行为测试）把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能需求,黑盒测试可用于各种测试
• 之后是n种测试方法，什么冒烟测试。回归测试等等
• 白盒测试是有选择地执行（或覆盖）程序中某些最有代表性路径的测试方法，所以也称为逻辑覆盖测试

黑盒测试技术

• 黑盒测试是根据程序组件的规格说明测试软件功能的方法，所以也称为功能测试
  被测对象作为一个黑盒子，它的功能行为只能通过研究其输入和输出来确定，所以又称为软件输入/输出接口测试
  黑盒测试注重于功能和数据信息域的测试

• 第一步：等价类的划分：

  • 等价类的划分有两种不同的情况：
    有效等价类：合理的，有意义的输入数据集合。
    无效等价类：不合理的，无意义的输入数据集合。

  • 不好描述直接举例吧：

• 第二步：设计测试用例：

  • 怎么说呢？有效等价类只需要被测试用例覆盖过就够了

​ 但是无效等价类则需要控制变量每个单独有 测试用例单独覆盖

例：

​

9.软件项目管理

软件质量保证(SQA)

• 提高软件质量最好的办法是：在开发过程中有效地防止工作成果产生缺陷，将高质量内建于开发过程之中。主要措施是“不断地提高技术水平，不断地提高规范化水平”，其实就是练内功，通称为“软件过程改进”。
• 软件质量：应用有效的软件过程，创造有用的产品，为生产者和使用者提供明显的价值。

风险管理

具有负面后果、人们不希望发生的事件。

风险策略：

• 被动风险策略：对风险不闻不问，直至出现问题。这时，项目团队赶紧采取行动，试图迅速解决问题

• 主动风险策略：在技术工作开始之前，就开始识别出潜在的风险，评估它们发生的概率及影响，并按重要性排序。然后，制定一个计划来管理风险

好像这一章都没啥说的

最后，本篇只包括一些基础知识，具体题目和一些重点拓展需要作者去做些题再来总结一下。