软件工程期末总结

发表于 更新于 分类于 本文字数： 5.2k 阅读时长 ≈ 5 分钟
主要的软件工程方法有传统方法学与面向对象方法学，遵循七条基本原则。软件生命周期包括定义、开发、维护和淘汰，各阶段有不同任务。软件开发模型包括瀑布、快速原型、增量、螺旋、喷泉、RUP、敏捷过程与极限编程、微软过程等。根据需求选择适当模型至关重要。

软件工程期末总结

第一章 概论

  1. 软件工程大体经历了哪几个阶段？

    软件工程大体经历了 4 个阶段，分别是：

    • 第一阶段：程序设计阶段（20 世纪 40 年代中期～ 60 年代中期）

    • 第二阶段：软件=程序+文档阶段 （20 世纪 60 年代中期～ 70 年代中期））

      • 20 世纪 60 年代中期～ 60 年代末期 （爆发软件危机）IBM-OS360
      • 20 世纪 60 年代末期～ 70 年代中期

    • 第三阶段：软件工程阶段（20 世纪 70 年代中期～ 20 世纪 90 年代中期）

    • 第四阶段：第4代技术阶段 （20 世纪 90 年代中期～至今）

      串记：20 世纪，4679，程序设计、软件程序文档、软件工程、第四代技术

  2. 软件危机在哪个阶段产生？了解软件的特点。

    20 世纪 60 年代中期～ 60 年代末期 爆发软件危机 IBM-OS360

    软件的特点：

    1. 软件是一种逻辑产品而非物理实体。
    2. 软件是一种智力产品，生产过程主要是研发，而不是硬件制造
    3. 软件不允许有误差
    4. 软件越来越复杂，今后将会更复杂
    5. 软件永不磨损，但它会退化，直至被弃用。

  3. 软件危机定义、原因以及解决途径。

    软件危机定义：

    软件开发和维护过程中遇到的一系列严重问题。

    • 如何开发软件，以满足对软件日益增长的需求;
    • 如何维护数量不断膨胀的已有软件。

    软件危机产生的原因：

    1. 与软件本身的特点有关
    2. 与软件开发与维护的方法不正确有关
    3. 与在软件开发的不同阶段进行修改需求付出的代价有关

    解决途径：

    1. 首先应该对计算机软件有一个正确的认识
    2. 充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是各类人员协同配合，共同完成的工程项目。
    3. 推广使用在实践中总结出来的开发软件的成功的技术和方法，并且研究探索更好的更有效的技术和方法。
    4. 应该开发和使用更好的软件工具

    为了解决软件危机，既要有技术措施，方法和工具，又要有必要的组织管理措施 。

    软件工程正是从管理和技术两方面研究如何更好地开发和维护计算机软件的一门新兴学科。

  4. 软件、软件工程的定义。

    软件的定义 ：

    软件是指 计算机程序 及其有关的 数据和文档 。

    • 程序 :能够完成预定功能的可执行的指令 序列。
    • 数据 :程序能适当处理的信息，具有适当 的数据结构。
    • 文档 :开发、使用和维护程序所需要的图 文资料。

    软件工程定义 :

    💡 软件工程是指导计算机软件开发和维护的一门工程学科。
    采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。

  5. 目前使用最广泛的软件工程学方法有哪两个？

    • 传统方法学
    • 面向对象方法学

  6. 软件工程的七条基本原理。

    1. 用分阶段的生命周期计划严格管理
    2. 坚持进行阶段评审
    3. 实行严格的产品控制
    4. 采用现代程序设计技术
    5. 结果应能清楚地审查
    6. 开发小组的人员应该少而精
    7. 承认不断改进软件工程实践的必要性

  7. 软件生命周期定义，各阶段的任务。

    软件生命周期定义：

    • 软件定义：问题定义、可行性研究、需求分析
    • 软件开发：设计、实现和测试
    • 软件维护：维护
    • 淘汰

    各阶段的任务：

    1. 问题定义 ：大概确定问题是什么?系统的总体目标、 规模和基本任务。
    2. 可行性研究 ：从 经济 、技术 、法律 等方面分析确定系统 是否值得开发，及时建议停止项目开发， 避免人力、物力、时间的浪费。
    3. 需求分析 ：
      • 软件人员和用户一起完全弄清用户对系统的确切要求。
      • 包括功能要求、性能要求、数据要求、资源要求…. 。
      • 通常用数据流图、数据字典和简明算法描述表示系统的逻辑模型，防止系统的设计 与用户的实际需求不相符的后果。
    4. 概要设计 ：确定系统设计方案，软件的体系结构。确定软件由哪些模块组成以及这些模块之间的相互关系。
    5. 详细设计 ：描述应该如何具体地实现系统。详细设计 每个模块，确定实现模块所需要的算法和数据结构。
    6. 软件实现阶段 ：进行程序设计(编码)和模块测试。
    7. 综合测试阶段 ：通过各种类型的测试，查出软件设计中的错误并 改正，确保软件质量;还要在用户的参与下进行验收，才可交付使用。
    8. 软件运行、维护 ：软件运行期间，通过各种必要的维护使系统改正错误、或修改扩充功能使软件适应环境变化，以便延长软件的使用寿命，提高软件的效益。每次维护的要求及修改步骤都应详细准确地记录下来， 作为文档保存。

  8. 软件开发模型有哪些？并了解各模型的特点，能够根据需求的要求选择适当的模型。

    软件开发模型：

    1. 瀑布模型
    2. 快速原型模型(Rapid Prototype Model)
    3. 增量模型
    4. 螺旋模型(Spiral Model)
    5. 喷泉模型
    6. RUP(统一过程)
    7. 敏捷过程与极限编程
    8. 微软过程

第二章 可行性研究及需求分析

  1. 可行性研究中从哪几个方面写可行性研究报告？

    1. 引言
      • 问题描述
      • 实现环境
      • 限制条件
    2. 管理概要和建议
      • 重要的研究结果
      • 说明
      • 建议
      • 影响
    3. 方案选择
      • 候选系统的配置
      • 最终方案的选择标准
    4. 系统描述
      • 系统工作范围的简要说明
      • 被分配系统元素的可行性
    5. 经济可行性
      • 经费概算
      • 预期的经济效益
    6. 技术可行性
      • 技术实力
      • 已有工作基础
      • 设备条件
    7. 法律可行性
      • 系统开发可能导致的侵权，违法和责任
    8. 用户使用可行性
      • 用户单位的行政管理，工作制度
      • 使用人员的素质
    9. 其他与项目有关的问题
      • 其他方案介绍
      • 未来可能的变化

  2. 技术可行性、经济可行性的定义。

    技术可行性：使用现有的技术能实现这个系统吗？

    经济可行性：这个系统的经济效益能超过它的开发成本吗？

  3. 需求分析需要确定目标系统的哪些具体要求？

    1. 功能需求
    2. 性能需求
    3. 可靠性和可用性需求
    4. 出错处理需求
    5. 接口需求
    6. 约束
    7. 逆向需求
    8. 将来可能提出的要求

  4. 需求分析的步骤。

    1. 获取初步需求
    2. 分析和描述系统的逻辑模型
    3. 需求评审
    4. 提交需求分析阶段文档

  5. DFD 的内容，四种基本符号的含义，画 DFD 的步骤。

    DFD 的内容:

    1. 不包含任何具体的物理元素，只描绘信息在软件中流动和被处理的情况;
    2. 只考虑系统必须完成的基本逻辑功能，不考虑如何具体实现。

    DFD 符号的基本含义：

    画 DFD 的步骤：

    1. 画出顶层 DFD:
    2. 画出各层 DFD:
    3. 画出总的 DFD:

  6. 数据字典的作用，DD 中使用的符号以及含义，能够运用规范严谨的数据字典符号进行数据定义。

    作用：

    1. 数据字典最重要的用途是作为分析阶段的工具
    2. 数据字典中包含的每个数据元素的控制信息是很有价值的
    3. 数据字典是开发数据库的第一步，而且是很有价值的一步。

    符号及含义：

    1. =意思是等价于(或定义为);
    2. +意思是和(即连接两个分量);
    3. []意思是或(即从方括弧内列出的若干个分量中选 择一个)，通常用“|”号隔开供选择的分量;
    4. {}意思是重复(即重复花括弧内的分量);
    5. ()意思是可选(即圆括弧里的分量可有可无)。

  7. 学习案例，能够分析系统的功能要求，绘制各层数据流图（顶层、0 层、1 层）。

第三章 总体设计、详细设计

  1. 了解结构化方法 SA、SD、SP 之间的关系。

    结构化方法由结构化分析（SA）、结构化设计（SD）和结构化编程（SP）三部分构成

  2. 结构化设计分为哪两个过程，概要设计的步骤，详细设计的基本任务。

    1. 概要设计（总体设计）步骤：
      1. 设想供选择的方案
      2. 选取合理的方案
      3. 推荐最佳方案
      4. 功能分解
      5. 设计软件结构
      6. 设计数据库
      7. 制定测试计划
      8. 书写文档
      9. 审查和复查
    2. 详细设计的基本任务：
      1. 为每个模块进行详细的算法设计。用某种图形、表格、语言等工具将每个模块处理过程的详细算法描述出来。
      2. 为模块内的数据结构进行设计。对于需求分析、概要设计确定的概念性的数据类型进行确切的定义。
      3. 对数据结构进行物理设计，即确定数据库的物理结构。物理结构主要指数据库的存储记录格式、存储记录安排和存储方法，这些都依赖于具体所使用的数据库系统。
      4. 其他设计：根据软件系统的类型，还可能要进行以下设计：
        1. 代码设计。为了提高数据的输入、分类、存储、检索等操作，节约内存空间，对数据库中的某些数据项的值要进行代码设计。
        2. 输入/输出格式设计。
        3. 人机对话设计。对于一个实时系统，用户与计算机频繁对话，因此要进行对话方式、内容、格式的具体设计。
      5. 编写详细设计说明书。
      6. 评审。对处理过程的算法和数据库的物理结构都要评审。

  3. 模块、信息隐蔽、局部化、模块作用域定义。

    模块定义 ：模块又称为构件，是能够单独命名并独立地完成一定功能，独立地设计、编制、调试、查错、修改和维护的程序语句的集合。例如高级语言中的过程、函数、子程序等都可做为模块。

    模块化 ：把系统按照一定的规则分割成能完成独立功能的模块，明确规定模块及其输入输出规格，使模块的界面不会产生混乱。

    信息隐蔽 ：模块所包含的信息，不允许其他不需要这些信息的模块访问，独立的模块间仅仅交换为完成系统功能而必须交换的信息。

    局部化 ：把关系密切的软件元素放在一起，局部话有利于信息隐蔽。

    模块作用域 ：是指受该模块判定影响的所有模块。受该模块内的一个判定影响的所有模块的 集合。

  4. 各种耦合、内聚的定义以及特点。

  5. 总体设计中改进软件设计提高软件质量的启发规则。

    1. 争取低耦合、高内聚（增加内聚 > 减少耦合）
    2. 模块规模适中：
      • 过大不易理解
      • 太小则接口开销过大
      • 注意分解后不应降低模块的独立性
    3. 适当控制：
      • 深度 = 分层的层数。过大表示分工过细
      • 宽度 = 同一层上模块数的最大值。过大表示系统复杂度大
    4. 高扇入低扇出
    5. 作用域在控制域内
    6. 降低接口的复杂程度：接口复杂可能表明模块独立性差。
    7. 单出单入，避免内容耦合。
    8. 模块功能可预测——相同输入必产生相同输出。反例：模块中使用全局变量或静态变量，则可能导致不可预测。

  6. 数据流图的类型。学习案例，能够分析数据流图的类型，能够基于数据流图的方法进行软件结构设计。

    数据流图的类型：

    1. 变换型数据流图

    2. 事务型数据流图

  7. 掌握详细设计各种图形工具（程序流程图、盒图、PAD 图、判定表、判定树）的特点。能够根据问题特点选择绘制。

第四章 实现和测试

  1. 程序内部的文档包括哪些？

    所谓程序内部的文档包括恰当的标识符、适当的注解、和程序的视觉组织等。

    1. 标识符：含义鲜明的名字、缩写规则一致、为名字加注解；
    2. 注解：正确性，简要描述模块的功能、主要算法、接口特点、重要数据以及开发简史或解释包含这段代码的必要性；
    3. 视觉组织：适当的阶梯形式使程序的层次结构清晰明显。

  2. 了解数据说明、语句构造、输入输出、效率规则，能够进行判断。

    1. 数据说明的原则：

      • 数据说明的次序应该标准化
      • 当多个变量名在一个语句中说明是，应该按字母顺序排列这些变量
      • 如果设计时使用了一个复杂的数据结构，则应该用注解说明用程序设计语言实现这个数据结构的方法和特点

    2. 语句构造原则：

      • 不要为了节省空间而把多个语句写在同一行
      • 尽量避免复杂的条件测试
      • 尽量减少对“非”条件的测试
      • 避免大量使用循环嵌套和条件嵌套
      • 利用括号使逻辑表达或算数表达式的运算次序清晰直观

    3. 输入输出原则：

      • 对所有输入数据都进行校验
      • 检查输入项重要组合的合法性
      • 保持输入格式简单
      • 使用数据结束标记，不要要求用户指定数据的数目
      • 明确提示交互式输入的请求，详细说明可用的选择或边界数值
      • 程序设计语言对格式有严格要求时，应保持输入格式一致
      • 设计良好的输出报表
      • 给所有输出数据加标志

    4. 效率规则：

      • 效率是性能要求，因此应该在需求分析阶段确定效率方面的要求
      • 效率是靠好的设计来提高的
      • 程序的效率和程序的简单程度是一致的，不要牺牲程序的清晰性和可读性来不必要的提高效率

      💡 效率包括：

      1. 程序运行时间

      2. 存储器效率

      3. 输入输出的效率

  3. 软件测试的目标和准则。

  4. 软件测试的步骤。

    1. 模块测试
    2. 子系统测试
    3. 系统测试
    4. 验收测试
    5. 平行运行

第五章 维护

  1. 软件维护的概念。

    所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。可以通过描述软件交付使用后可能进行的 4 项活动，具体的定义软件维护。

  2. 软件维护的类型、特点、副作用。

    软件维护的类型：

    1. 改正性维护
    2. 适应性维护
    3. 完善性维护
    4. 预防性维护

    软件维护的特点：

    1. 结构化维护和非结构化维护差别巨大
    2. 维护的代价高昂
    3. 维护的问题很多

    软件维护的副作用：

    1. 修改代码的副作用

      在使用程序设计语言修改源代码时，都可能引入错误。例如，删除或修改一个子程序、删除或修改一个标号、 删除或修改一个标识符、改变程序代码的时序关系、改变占用存储的大小、改变逻辑运算符、修改文件的打开或关闭、改进程序的执行效率，以及把设计上的改变翻译成代码的改变、为边界条件的逻辑测试做出改变时，都容易引入错误。

    2. 修改数据的副作用

      在修改数据结构时，有可能造成软件设计与数据结构不匹配，因而导致软件出错。数据副作用就是修改软件信息结构导致的结果。例如，在重新定义局部或全局常量、 重新定义记录或文件格式、增大或减小一个数组或高层数据结构的大小、修改全局或公共数据、重新初始化控制标志或指针、重新排列输入/输出或子程序的参数时，容易导致设计与数据不相容的错误。数据副作用可以通过详细的设计文档加以控制。在此文档中描述了一种交叉引用，把数据元素、记录、文件和其它结构联系起来。

    3. 文档的副作用

      对数据流、软件结构、 模块逻辑或任何其它有关特性进行修改时，必须对相关技术文档进行相应修改。否则会导致文档与程序功能不匹配，缺省条件改变，新错误信息不正确等错误。使得软件文档不能反映软件的当前状态。对于用户来说，软件事实上就是文档。如果对可执行软件的修改不反映在文档里，就会产生文档的副作用。例如，对交互输入的顺序或格式进行修改，如果没有正确地记录在文档中，就可能引起重大的问题。过时的文档内容、索引和文本可能造成冲突，引起用户的失败和不满。因此，必须在软件交付之前对整个软件配置进行评审，以减少文档的副作用。