软件工程期末复习

软件工程期末复习

第一章 概论

软件：程序+数据+文档

软件工程三要素：过程、方法、工具

软件危机：计算机软件开发、运行、维护过程中所遇到的一系列严重问题，质量差、周期长、难维护、难以复用、成本高

软件危机出现的原因：

• 缺乏正确的理论指导

• 开发人员与用户缺乏充分交流：需求不明确

• 对软件开发过程缺乏整体认识：忽视文档管理、不重视测试

• 缺乏有效一致的质量评价标准

软件生命周期：计划阶段——需求分析阶段——设计阶段——实现阶段——测试阶段——运行和维护阶段
软件开发生命周期：需求分析——设计与规划——编码实现——测试——发布交付——维护和升级

软件工程的基本原则：

• 确定性：所有概念表达确定、无歧义、规范

• 一致性：使用一致的概念、符号、术语

• 完备性：可以完全实现系统所要求的功能

• 可验证性：易于检查、测试、评审，确保系统的正确性

软件开发过程模型

软件过程：为了获取高质量的软件所需完成的一系列任务的框架，它规定了完成任务的各个任务步骤

传统的瀑布模型：线性的、无反馈的、与用户无反馈、无交互的

瀑布模型：

特点：

• 具有顺序性，上一阶段的输出是下一阶段的输入
• 整体规划与控制，项目启动时需要进行完整的规划与设计
• 适用于大型、稳定的项目，瀑布模型要求稳定、项目范围固定、技术可靠，时间充裕的大规模软件开发项目

优点：

• 可以有反馈

• 可强迫开发人员采用规范的方法（结构化方法）

• 严格规定了每个阶段必须提交的文档

• 要求每个阶段交出的产品都必须经过质量检测

缺点：

• 缺乏灵活性，难以适应需求变化块的软件开发
• 早期存在的问题往往到交付时才会发现，维护代价大

增量模型：

特点：

• 融合瀑布模型的基本成分和演化模型的迭代特征
• 复杂功能划分为多个等级或分组
• 重视集成测试
• 适用于需求经常变更的软件开发
• 能有计划的管理技术风险，如早期增量版本中避免采用未成熟的技术

缺点：

• 成本高
• 集成测试时间较长
• 增强构建必须不破坏原本的产品
• 软件体系结构必须开放

快速原型模型：

可以在获取了一组基本的需求后，通过快速分析构造出该软件的一个初始可运行版本，称之谓原型
演化模型的开发过程就是从构造初始的原型出发，逐步将其演化成最终软件产品的过程

特点：

• 线性顺序的，不带反馈环
• 连续的修改可能导致软件质量不高
• 要有一个产品原型，一定程度上限制了开发人员的创新
• 但是开发出的产品基本能满足用户的需求

螺旋模型：

特点：

• 是瀑布模型和演化模型的结合，并增加了风险分析
• 是一种面向风险驱动的软件开发过程模型
• 螺旋模型每旋转一圈，表示开发出了一个更为完善的软件版本
• 四个象限

敏捷过程的四个简单价值观声明（重要）：

• 个体和交互胜过过程和工具

• 可以工作的软件胜过面面俱到的文档

• 客户合作胜过合同谈判

• 响应变化胜过遵循变化

  

常见的图形描述（软件开发中） ：用例图 类图 状态转换图 程序流程图 数据流图（DFD）

第二章 系统工程

可行性分析

• 技术可行性
  • 开发风险分析
  • 资源分析
  • 相关技术的发展
• 经济可行性
  • 开发/运行的成本与效益
  • 度量系统解决方案的性能价格比
• 操作可行性
  • 用户使用可能性
  • 时间进度可行性
  • 组织和文化上的可行性
• 社会可行性
  • 侵权等问题

相关图：数据流程图、数据字典，二者共同构成系统的逻辑模型

数据流图（重要）

• 描述信息流和数据从输入移动到输出的过程和变化
• 数据流图中没有任何物理部件
• 描绘数据在软件中流动和处理的逻辑过程

第三章 需求分析

结构化的开发方法：需求分析的结构化分析遵循的准则

• 必须理解并描述问题的信息域，建立数据模型
• 必须定义软件应完成的功能，建立功能模型
• 必须描述作为外部事件结果的软件行为，建立行为模型
• 必须对描述信息、功能和行为模型进行分解，用层次的方式展示细节

实体-联系图（ER）

• 用来建立数据模型的工具

数据对象：是对软件必须理解的符合信息的抽象

复合信息：具有一系列不同性质或属性的事物

第四章 形式化说明技术

如何保证软件需求的正确性？

• 一致性：需求一致
• 完整性：需求完整
• 现实性：需求应该是现有技术可以实现的
• 有效性：证明需求是正确有效的

第五章 总体设计

总体设计相关图：层次图、HIPO图、结构图

概念：概要设计，确定软件的结构以及各组成成分(子系统或模块)之间的相互关系

必要性：

• 站在全局角度上，减少成本
• 从较抽象的层次上分析对比多种可能的实现方案，选择最佳方案

分为两个阶段：

• 系统设计阶段
• 结构设计阶段

详细设计：确定模块内部的算法和数据结构，产生描述各模块程序过程的详细文档

详细设计相关图：程序流程图、盒图、判定表/树、PAD图

设计原理或软件工程方法基本原则（重要）

• 模块化
• 抽象
• 逐步求精
• 信息隐藏和局部化
• 模块独立

耦合：程序结构中各个模块之间相互关联的度量，它取决于各个模块之间接口的复杂程度、调用模块的方式

内聚：一个模块内部元素在功能上相互关联的强度

程序流程图

N-S图

PAD

第六章 软件测试

为什么要进行维护和测试（重要）：

• 测试
  • 确保软件在实际使用时能达到预期的功能和性能
  • 尽早发现并解决问题，从而降低软件出现问题和安全漏洞的风险
• 维护
  • 有助于确保软件在长期运行期间能够保持稳定和高效的状态

软件测试的目的

• 测试时一个为了发现错误而执行的程序
• 一个好的测试用例是指肯能找到迄今为止尚未发现的错误的测试用例
• 一个成功的测试是指揭示了迄今为止尚未发现的错误的测试

软件测试的基本准则（重要）

• 所有测试都应可追溯到客户需求
• 在测试工作开始前就进行测试计划
• 测试中发现的80%的错误可能来自于20%的程序代码
• 测试应该从“小规模”逐步转向“大规模”
• 穷举测试不可能
• 为达到最有效的测试，应由独立的第三方来承担测试

黑盒测试和白盒测试

• 测试用例的设计是软件测试的关键所在
• 设计尽可能少的测试用例，发现尽可能多的错误
• 设计最有可能发现软件错误的测试用例，同时避免发现错误效果相同的测试用例
• 测试用例的设计方法大体分为：黑盒测试和白盒测试
  • 白盒测试：结构测试，将测试对象视为透明盒子，根据程序内部的逻辑结构及有关信息设计测试用例
    • 程序模块中的所有独立路径至少执行一次
    • 对所有逻辑判定的取值都至少测试一次
    • 在上下边界及可操作范围内运行所有循环
    • 测试内部数据结构的有效性等
  • 逻辑覆盖测试：白盒测试的一种具体应用
    • 语句覆盖：每个语句执行一次
    • 判定覆盖：每个判定的真假分支都执行一次
    • 条件覆盖：每个判定的每个条件的可能取值至少执行一次
      • 条件覆盖不一定包含判定覆盖
      • 判定覆盖也不一定包含条件覆盖
    • 判定/条件覆盖：同时满足判定覆盖和条件覆盖
    • 条件组合覆盖：所有可能的条件取值组合至少执行一次
    • 路径覆盖
  • 黑盒测试：功能测试，检验程序的各个功能是否能正常使用

测试策略：常见的是将测试分为单元测试、集成测试、确认测试和系统测试

各种图(重要)

• 可行性研究

  • 数据流图或数据流程图DFD（重要）：便于实现、采用逐步细化的扩展方式；便于使用

  

  

  

  • 数据字典

  

  eg1：某宾馆的电话服务如下：可以拨分机号和外线号。分机号从7201到7209；拨外线需要先按9，然后是市话号码或长话号码；长话号码是由区号和市话号码组成的；区号是44、55中任意一个号码；市话号码是由局号和分局号组成的；局号可以是455、466、888、552中任意一个号码；分局号是长度为4的数字串。请写出在数据字典中，电话号码的数据条目的定义及组成。

  电话号码 = [分机号|外线号]

  分机号 = [7201 | 7202 | 7203 | 7204 | 7205 | 7206 | 7207 | 7208 | 7209]

  外线号 = 9+[市话号码|长话号码|]

  长话号码 = 区号 + 市话号码

  区号 = [44 | 55 ]

  市话号码 = 局号 + 分局号

  局号 = [455|466|888|552]

  分局号 =4{数字}4

  数字 =[0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ]

• 需求分析

  • 实体联系图（E-R图）

  

  • 状态转换图

• 总体设计时描绘软件结构

  • 层次图

  

  • HIPO图

  

  • 结构图

  

• 过程设计的工具（重要），根据PDL/伪码画程序流程图、盒图、判定表

  • 程序流程图：结构不受控制、不利于精益求精，不易表示数据结构

    

  • 盒图

    

  • PAD图：竖线总条数是程序的层次数

    

    

  • 判定表：与程序设计语言一起考

    

  • 判定树：与过程设计语言一起考