1. 软市首页
  2. 软件开发

《软件工程导论》知识点期末复习整理

• 软件开发

图片来自湖南大学《软件工程导论》课程 PPT

一、软件工程概述

1 软件和硬件的不同

  • 硬件
    • 人工制造
    • 易磨损（硬件磨损后可以使用备件替换）
    • 使用标准化组件制造
    • 相对简单
    • 制造出来后一般不改变
  • 软件
    • 开发出来的
    • 易退化（需求的不断变更是软件退化的根本原因）
    • 自定义组件
    • 较为复杂
    • 开发出来结果后可能会经常改变

2 软件的概念

  • 软件 = 程序 + 数据 + 文档
    • 程序：按事先设计的功能和性能需求执行的指令序列
    • 数据：程序能正常操纵信息的数据结构
    • 文档：与程序开发、维护和使用有关的图文材料

3 软件的本质

具有产品和产品交付载体的双重作用

  • 作为产品，显示了由计算机硬件体现的计算能力，扮演信息转换的角色
  • 作为产品生产的载体，提供了操作系统、 络、软件工具和环境等的基础平台

4 软件的特点

  1. 无磨损：抽象不可触摸，潜能不受物理因素的限制（但存在退化）

    （磨损是什么

    1. 可用失效率来衡量
    2. 软件抽象不可触摸，不受物理因素的限制——软件不会磨损，但是存在软件退化现象
    3. 磨损说明了软硬件的不同 软件的缺陷暗示了设计的缺陷或将设计转化为代码过 程中产生的错误，软件维护通常要面对变更请求，比硬件维护更复杂

  2. 变更：由于易修改，很容易变得极为复杂

5 软件发展的阶段历程

5.1 第一阶段：程序设计阶段

  • 时间：计算机诞生后
  • 特点：程序设计
  • 代表产品：Micrsoft basic、unix、wps1.0
  • 软件工作：代码编写
  • 软件评估：程序设计=数据结构+算法，编程技巧

5.2 第二阶段：软件工程阶段

  • 时间： 大容量、高速度计算机和高级语言出现、操作系统发展、数据库管理系统诞生；
  • 特点：软件危机，主要表现在软件开发进度失控， 费用失控可靠性差， 软件难以维护
    • 代表产品：OS 360、美国火箭爆炸、Therac-25肿瘤放射线治疗仪
    • 软件工作：软件工程系统的、规范的、定量的工程化方法应用于软件
    • 软件评估：可读性、可理解性、可测试性和易修改性等软件质量

5.3 第三阶段：软件过程阶段

  • 时间：互联 广泛应用后
  • 特点：市场变幻莫测、需求日趋复杂、技术日新月异
  • 软件工作：流程活动+流程活动各要素 (如人员、方法、产品等)
  • 软件评估：多目标函数（软件质量，开发效率，开发成本）

6 软件神话

软件神话就是谬论：

  • 如果进度落后，那么增加多的程序员人手则可以赶上进度
  • 对目标一般的称述就足以开始构建项目
  • 可以容忍项目需求的变化，因为软件是灵活多变的
  • 一旦我们编写了一个工作程序，我们就完成任务了
  • 直到程序运行，才能评估质量
  • 对于一个成功的项目来说，唯一可交付的工作产品就是程序
  • 软件工程会让我们写太多文档，并且减缓我们的开发速度

7 软件工程的概念

  • 将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件
  • 以及上述方法的研究

7.1 软件工程方法

为构建软件提供技术上的解决方法

7.2 软件工程工具

为过程和方法提供自动化或半自动化的支持

7.3 软件工程的实践

概念、原则、方法和开发工具的集合。

8 软件过程

8.1 定义

软件过程是从软件项目需求定义开始，直至软件经使用后废弃为止的，跨越软件整个生存期内的系统开发、运行和维护等全部活动、动作和任务及相关项的总和。

8.2 内容

5个主要过程、8个支持过程和4个组织过程

  • 5个主要过程为：获取过程、供应过程、开发过程、运行过程、维护过程。
  • 4个组织过程为：管理过程、基础设施过程、改进过程、培训过程。

9 软件过程模型

参考资料：https://www.cnblogs.com/jojop/p/11801241.html

9.1 定义

软件过程模型是软件过程中全部活动生命周期结构框架的一种形式化描述，也称为软件生命周期模型或软件生存期模型。

9.2 经典软件过程模型

9.2.1 瀑布模型——惯例过程模型的一种，又叫作生命周期模型

  • 内容
    • 第一步：原型 弄清需求并探索可行性
    • 第二步：开发产品
  • 优点
    • 快速开发出可以演示的系统，方便了客户沟通。
    • 采用迭代技术能够使开发者逐步弄清客户的需求。
  • 缺点
    • 为了尽快完成原型，开发者没有考虑整体软件的质量和长期的可维护性，系统结构通常较差
    • 用户可能混淆原型系统和最终系统，原型系统在完全满足用户需求之后可能会被直接交付给客户使用。
  • 特征及适用范围：减少了需求不明确带来的风险
  • 适用场景
    • （需求不明确）客户提出了软件的一些基本功能，但是没有详细定义输入、处理和输出需求
    • 另一种情况下，开发人员可能对算法的效率、操作系统的兼容性和人机交互的形式等情况不确定
9.2.3.2 螺旋模型——惯例过程模型 中 演化过程模型 的一种（风险分析）

  • 特征
    • 加入了风险分析（与原型模型最主要的区别）
    • 迭代演化：识别每个演化层的风险
    • 自上而下
  • 优点
    • 结合了原型的迭代性质与瀑布模型的系统性和可控性，是一种风险驱动型的过程模型。
    • 采用循环的方式逐步加深系统定义和实现的深度，同时更好地理解、应对和降低风险。
    • 确定一系列里程碑，确保各方都得到可行的系统解决方案。
      始终保持可操作性，直到软件生命周期的结束。由风险驱动，支持现有软件的复用。
  • 缺点
    • 螺旋模型依赖大量的风险评估专家来保证成功。如果有较大的风险没有被发现和管理，肯定会发生问题。
    • 软件开发人员应该擅长寻找可能的风险，准确的分析风险，否则将会带来更大的风险
  • 适用场景
    • 需求不太稳定
    • 大型软件开发
    • 内部软件开发
9.2.4 喷泉模型——面向对象模型的一种

7 需求工程的内容和过程

定义：所有与需求直接相关的活动。

8 需求工程方法

需求获取的方法(11个)

  • 定义需求的开发过程
    确定需求的收集、分析、细化和核实的步骤、方法、模板。
  • 定义项目前景与范围
    前景说明所有涉众对产品目标的达成的共识；
    范围定义了需求是否属于某个特定版本的界线。
  • 确定用户群
    将可能使用产品的用户组，以避免出现某一用户群的需求被忽略的情况。
  • 选择用户代表
    为每类用户至少选择一位能代表他们需求的、有时间、有热情、有权利参与需求工作的用户代表。
  • 建立核心队伍
    把同类产品或产品前版本的用户代表召集起来，从他们那里收集目前产品的功能需求和非功能需求。
  • 确定用例
    从用户代表处收集他们使用软件完成所需任务的描述——用例，讨论用户与系统间的交互方式和对话要求。
  • 确定系统事件和响应
    列出系统可能发生的外部事件以及对每个事件所期待的响应时间。
  • 举行进一步需求获取的讨论
    专门的需求获取讨论会可以方便分析员和客户进行合作。
  • 观察用户如何工作
    观察用户执行业务的过程。画一张简单的数据流程图或业务流程图，描绘出用户什么时候获得什么数据，并怎样使用这些数据进行业务处理。
  • 检查问题 告
    客户对当前系统的问题 告及补充需求为新产品或新版本提供了大量丰富的改进及增加特性的想法。
  • 需求重用
    如果客户要求的功能与已有的某产品很相似，则可查看需求是否有足够的灵活性以允许重用一些已有的软件组件。

需求分析的方法(8个)

  • 编制关联图
    定义系统与外部实体的界限和接口
  • 创建开发原型
    当开发人员或用户不能确定需求时，可构建一个开发原型。它可使许多概念和可能发生的事更为直观明了。通过评价原型，能更好地相互理解所要解决的问题
  • 分析需求的可行性
    在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突、对外界因素的依赖和技术障碍。
  • 确定需求优先级
    应用分析方法来确定use-case、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本应包含的需求和特性。
  • 为需求建立模型
    需求的图形分析模型是SRS的极好补充说明。这样的模型包括用例图、数据流程图、实体关系图、状态变换图、对话框图、对象类及交互作用图等。
  • 编写数据字典
    通过建立数据字典，对系统用到的所有数据项和数据结构进行定义。
  • 将需求分解到子系统
    必须将包括多个子系统的复杂产品的需求分配到各个软件、硬件以及人员子系统和部件中去。
  • 应用质量功能调配（QFD）
    质量功能调配（QFD）是一种高级系统技术，它将产品功能、属性与对客户的重要性联系起来。QFD将需求分为三类：普通需求、期望需求、兴奋需求。

需求描述方法（SRS）、需求验证方法、获取知识技能方法、需求管理方法、项目管理方法（略）

3 获取需求的手段（各种方法有什么区别）

3.1 访谈

  • 挑战：需求的模糊性

  • 特别关注意料之外的需求，需求建议诱导，关键点：诱导型访谈

  • 基于快速原型的 “需求访谈”

    • 原型 – 需求建议诱导的有效形式之一

      1 概念

      • 原型是一种技术，可用它减少客户对产品不满意的风险。
      • 原型可以使新产品实在化，为使用实例带来生机，并消除人们在需求理解上的差异
      • 采用原型方法是得到客户真实意图和宝贵信息的最有效方式

      2 三个目的

      • 明确并完善需求
      • 探索设计选择方案
      • 发展为最终的产品原型

      3 开发步骤

      • 快速分析：在分析人员与用户密切配合下，迅速确定系统的基本需求
      • 构造原型：在快速分析的基础上，根据基本需求说明尽快实现一个可行的系统，并忽略最终系统在某些细节上的要求，主要考虑原型系统能够充分反映所要评价的特性
      • 运行原型：这是发现问题、消除误解、开发者与用户充分协调的一个步骤
      • 评价原型：在运行基础上考核评价原型的特性，是否满足用户的愿望，纠正过去交互中的误解与分析中的错误，增添新的要求
      • 修改(回到开始)：若原型未满足需求说明的要求，说明对需求说明存在不一致的理解或实现方案不够合理，则根据明确的要求迅速修改原型

      4 分类

      • 快速原型（抛弃型）
        1. 目的是为解决不可测性,并提高需求质量；
        2. 通过花最小的代价，采用忽略很多具体的软件构造技术、快速地建立原型，并在原型达到预期目的以后选择抛弃或者进化。
        3. 当遇到需求中的含糊性、不确定性、二义性、不完整性时，可以考虑建立抛弃式模型。
        4. 快速原型能够帮助用户和开发者想象如何实现需求并发现需求中的漏洞；还可以使用户判断出这些需求是否可以完成必要的业务过程。
      • 进化原型（渐近型）
        1. 一个进化型原型必须重视软件系统性和完整性的设计原则，它必须易于升级和优化。
        2. 从测试和使用中获得的信息将引起下一次软件原型的更新。
        3. 原型的不断增长和更新，使软件从一系列进化型原型发展为最终的产品。
        4. 进化型原型比建立抛弃型原型所花的时间和代价要多得多。

3.2 观察与挖掘

  • 挑战：需求的隐蔽性
  • 形式：现场观察，例如：与用户一起工作(敏捷开发)；挖掘用户的意图和目标收益
  • 案例：扎根蘑菇群；挖掘用户意图（弄匹马）

3.3 User Case

  • 挑战：需求的多样性

  • 从每个用户 Case 或 Story 进行各项需求评判

  • 基于用例 (User Case) 的需求获取与分析过程

    • User分类，确定没类用户的用户代表

    • Case/Story构建：基于前述访谈或观察挖掘结果，为每一类 User 构建 Case 或 Story，

    • 汇总所有 User Case 或 User Story

    • 多个 User Case 协商确定和优先级排序

      需求强度 = 潜在用户数 + 使用频率（需求的存续期 = 软件寿命）

      • 依赖关系

        • 包含关系：把一个较复杂的用例所表示的功能分解成较小的步骤，一个用例包含另一个用例

          在执行基本用例时，一定会执行包含用例部分

    五、需求验证与变更

    5.1 需求验证的任务

    很重要的一步，如果不进行在后序发现是需求错误的话，会导致成倍的代价。

    验证需求文档，发现错误并修改，需要检查：

    • 有效性检查：检查不同用户使用功能的有效性
    • 一致性检查：需求之间不应该冲突
    • 完备性检查：包括所有用户想要的功能和约束
    • 现实性检查：能够用现有技术实现

    5.2 需求验证的方法（5种）

    • 需求评审
      • 正式与非正式（审查），风险分析模型
    • 原型法
      • 首先，**确定合适原型(**见“需求获取与分析”章节)， 准备需求验证。
      • 将需求验证涉及的业务过程或场景定义出来， 以辅助需求验证过程的开展。
      • 根据已定义过程和场景，按照原型执行过程， 发现需求的缺陷、问题并记录，以待后续修正。
    • 编写测试用例
      • 在需求开发阶段不可能真正进行任何测试，因为还没有可执行的软件，然而可以以需求文档为基础编写测试用例
    • 编写用户手册
      • 系统的运行环境，硬件要求，环境配置
      • 系统功能的详细操作过程
      • 问题和故障的解决办法
    • 自动的一致性分析（如CASE工具）
      • 些自动化工具能部分支持需求定义内在的一致性和完备性检查

    需求定义是否准确地反映用户需求的验证 在目前还主要依赖于需求评审和原型示范等技术，缺乏行之有效的系统化方法

    5.3 需求签约

    签约的意义与作用

    • 软件产品最大的问题是需求与范围的不确定性、易动性和软件产品（包括中间产品） 的隐蔽性。
    • 软件需求管理和软件项目管理的有效手段 是 “签字确认” 。
    • 签约一旦生效，至少表明：
      • 1需求开发阶段结束。被确认的SRS表述了双方对项目软件 需求的了解，它是软件需求的基线，开发人员将按基线进行系统开发。
      • 2此后的需求变更，要在此基线上通过项目定义的变更过程不定期进行。以后的变更可能会使双方重新协商成本、资源和项目进度等。
    • 软件需求的签约，是权利、义务和责任的体现，是软件产品基线、变更控制、软件开发和验收的依据，是软件项目最关键的一步，也是人们最不愿面对的地方。

    5.4 需求变更管理

    • 提出了 14 项实践（技术方法 ）
      • 第 5. 结对编程
      • 第 8. 持续集成
        • 方法：提倡在一天中集成系统多次，而且随着需求的改变，要不断的进行回归测试；持续集成需要良好的软件配置变更管理工具的有效支持
        • 作用：可以使得团队保持一个较高的开发速度，同时避免了一次系统集成的恶梦
      • 第 12. 简单的设计
      • 第 13. 重构
        • 指在不改变系统行为的前提下，重新调整、优化系统的内部结构以减少复杂性、消除冗余、增加灵活性和提高性能

    3 敏捷过程之一 —— SCRUM（敏捷过程模型+人员）

    发展历史：KenSchwaber 和 Jeff Sutherland 提出

    3.1 概念

    • Scrum 是包括预定义角色和一系列实践的过程框架
    • Scrum 是迭代式增量软件开发过程，通常用于敏捷软件开发
    • 迭代：开发一部分，就提交一部分，用户就使用一部分，就反馈一部分，我们就修改一部分
    • 最有效的反馈就是当用户用这个软件（或其一部分）时给出的意见
    • 目的：一定程度上提供敏捷项目进展状况的外部可见性
    • 基本假设
      1. 外部需求模糊而难以理解
      2. 开发软件如同开发新产品
      3. 团队生存在一个快速变化且充满竞争的世界

    3.2 角色

    • 猪（全身投入项目中）
      • Product Owner 产品负责人
      • ScrumMaster Scrum 团队的服务式领导
      • Scrum Team 开发团队
    • 鸡（参与冲刺评审、计划并提供反馈）

    3.3 3种工件

    1. Product Blacklog (产品待办事项列表)

    2. Sprint Backlog (Sprint待办事项列表)

      迭代待办事项是由Scrum团队成员确定的在迭代期间完成的任务。

    3. Sprint Burn-down Chart (燃尽图)

      每天由Scrum Master 对迭代中预估的工作剩余量进行计算并绘制成图表，从而生成如下迭代燃尽图。

    3.4 5个会议

    1. Sprint计划会议（Sprint Planning Meeting）
    2. 每日站会（Daily Scrum Meeting）
    3. Sprint评审会议（Sprint Review Meeting）
    4. Sprint回顾会议（Sprint Retrospective Meeting）
    5. 产品Backlog梳理会议（ Product Backlog Refinement）（如果问的是 4 个会议就没有这个）

    七、统一过程 (Rational Unified Process, RUP)

    各种过程模型之间要做比较

    1 RUP的定义、内容及特点

    定义：统一过程（RUP/UP，Rational Unified Process）是一种以用例驱动、以体系结构为核心、迭代式增量的软件过程模型，由UML方法和工具支持，广泛应用于各类面向对象项目

    特点：RUP的开放性、通用性、完善性、多功能性和广泛的适用性

    RUP软件过程模型特点：迭代 & 增量 & 并行

    2.1 纵轴

    生命周期中的静态结构——九个核心工作流程

    • 核心过程工作流程：前 6 个
    • 核心支持工作流程：后 3 个
    • 表示方法：UML 中：协同图、时序图、活动图；RUP 中：采用活动图（交互 + 状态结果）
    • 内容：一套完整的 UML 使用指南
    • ① 业务建模：产生的主要工件 ：业务模型（业务用例模型+业务对象模型）
    • ② 需求：用例模型，用户界面模型
    • ③ 分析设计：一个设计模型
    • ④ 实现：实施模型（模型元素包括实施子系统和构件）
    • ⑤ 测试：测试模型（模型元素包括测试用例、测试过程和测试构件）+ 测试结果
    • ⑥ 部署：产品的一个版本+文档培训资料
    • ⑦ 配置和变更管理：配置管理计划、变更请求、项目存储库和工作区
    • ⑧ 项目管理：商业理由、迭代计划、风险管理计划、质量保证计划及相应的评估文档
    • ⑨ 环境：工作流程指南、工具、工具指南

    2.2 横轴

    生命周期中的动态结构——四个阶段

    • 每个阶段：由一次或多次迭代完成
    • ① Inception 先启阶段：目标：建立业务用例、确定项目的边界
    • ② Elaboration 精化阶段：目标：建立稳定的构架、编制项目计划、淘汰项目中最高风险的元素
    • ③ Construction 构建阶段：目标：所有构件和应用程序功能被开发并集成为产品、所有的功能被详尽的测试
    • ④ Transition 产品化阶段：目标：将软件产品交付给用户群体

    3 比较RUP的生命周期模型与螺旋模型的异同点

    请添加图片描述

    声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！

    上一篇 2022年9月15日
    下一篇 2022年9月15日

    相关推荐

    首页
    软件超市
    企服市场
    会员中心
    相同点：迭代特性
    重复一系列组成系统生命周期的循环
    每次循环的结束是向用户交付产品的一个运行版本