软件工程导论

× 8.7k words × 30 minutes

01 概述

软件（ Software）是计算机系统中与硬件相互依存的另一部分，它是包括程序（Program） ，数据（Data）及其相关文档（ Document）的完整集合。

1
Software = Program + Data + Document

1-1 背景

1-1-1 发展问题

  • 软件日益复杂

    • 逻辑复杂：远远高于硬件的逻辑复杂度
    • 开发复杂：成本难以估算、进度难以控制、人员素质要求、质量得不到保证

  • 成本增加

image-20211106150531182

  • 风险增加

  • 维护困难

    • 维护形式多样化【改正性：修改故障；完善性：增加功能；适应性：移植】
    • 维护成本越来越高、维护带来的问题

1-1-2 软件危机

  • 成本高
  • 软件质量得不到保证
  • 进度难以控制
  • 维护非常困难

1-1-3 软件工程

把软件当作一种工业产品，要求 “采用工程化的原理与方法对软件进行计划、开发和维护 ”。

Definition

The establishment and use of sound engineering principles (methods) in order to obtain economically software that is reliable and works on real machines. (1968- Fritz Bauer)

软件工程就是建立和使用一套合理的工程原理，从而经济地获得可靠的、可以在实际机器上高效运行的软件。

Software engineering. (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1). (IEEE(The Institute for Electrical and Electronic engineers) Std 610-1990.）

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

Engineering is the systematic application of scientific knowledge in creating and building cost-effective solutions to practical problems in the service of mankind.

Software engineering is that form of engineering that applies the principles of computer science and mathematics to achieving cost-effective solutions to software problems.

Summary

软件工程是应用计算机科学、数学及管理科学等原理开发软件的工程。它借鉴传统工程的原则、方法，以提高质量，降低成本为目的。

1-2 软件过程模型

软件生命周期的每一阶段都有明确的任务，把规模大、结构复杂、管理复杂的软件开发变得容易控制和管理。

各个阶段的活动如何衔接，开发过程中采用什么样的策略，应遵守什么样的规定和制约，将这些活动框架（忽略不必要的细节）用一种模型表示出来，称为软件过程模型（或软件开发模型或软件生命周期模型）

image-20211106152030733

1-2-1 瀑布模型（Waterfall Model）

瀑布模型也称为线性顺序模型，在20世纪80年代以前，瀑布模型一直是唯一被广泛采用的生命周期模型。

image-20211106152110149

特点

  • 提供了软件过程模型的基本框架。
  • 强调了每一阶段活动的严格顺序。
  • 质量保证：以经过评审确认了的阶段工作产品（文档）驱动下一阶段的工作，便于管理。
  • 是一种整体开发模型，程序的物理实现集中在开发阶段的后期，用户在最后才能看到自己的产品。

缺点

  • 阶段间具有顺序性和依赖性。
  • 推迟实现。
  • 传统的瀑布模型过于理想化。事实上，人在工作过程中不可能不犯错误。

实际模型

image-20211106152421188

1-2-2 原型模型（Prototype Model）

在用户不能给出完整、准确的需求说明，或者开发者不能确定算法的有效性、操作系统的适应性或人机交互的形式等许多情况下，可以根据用户的一组基本需求，快速建造一个原型（可运行的软件），然后进行评估，进一步精化、调整原型，使其满足用户的要求，也使开发者对将要做的事情有更好的理解。

image-20211106152742290

特点 / 缺点

  • 为使原型尽快工作，没有考虑软件的总体质量和长期的可维护性。
  • 为演示，可能采用不理想的选项成为系统的组成部分。
    • 不理想成分：操作系统、编程语言、低效率算法
  • 开发过程不便于管理。

有效使用

建造原型仅是为了定义需求，之后就被抛弃（或被部分抛弃），实际的软件在充分考虑了质量和可维护性之后才被开发。

1-2-3 增量模型（Incremental Model）

是一种渐进地开发逐步完善的软件版本的模型。早期的版本实现用户的基本需求，并提供给用户评估的平台。

image-20211106153759136

反复的应用瀑布模型的基本成分和原型模型的迭代特征，每一个线型过程产生一个“增量”的发布或提交，该增量均是一个可运行的产品。

image-20211106154013175

优点

  • 短时间内向用户提交可完成部分的产品
    • 分批、逐步地向用户提交产品
    • 从第一个构件交付之日起，用户就能做一些有用的工作
  • 整个软件产品分解成许多个增量构件
    • 开发人员可以一个构件一个构件地逐步开发。
  • 用户有充裕时间学习适应新产品
    • 减少一个全新的软件可能给客户组织带来的冲击
  • 需要更精心的设计
    • 在设计阶段多付出的劳动将在维护阶段获得回报

困难

  • 增量构件不得破坏原产品
  • 软件体系结构必须开放，新构件加入必须简单方便
  • 开发人员既要把软件系统看作整体。又要看成可独立的构件，相互矛盾。
  • 多个构件并行开发，具有无法集成的风险。

适用情况

  • 客户能够接受分阶段交付
  • 工期紧且可分阶段提交或者对目标、环境不熟悉
  • 用户可参与到整个软件开发过程中
  • 软件开发组织自己应该拥有较好的类库、构件库

软件企业开发大型项目时，一般还是采用增量模型，因为可以根据轻重缓急，逐个实现子系统。

1-2-4 螺旋模型（Spiral Model）

螺旋模型的基本思想是降低风险。结合了瀑布模型和快速原型模型，加入风险分析。

软件风险是任何软件开发项目中都普遍存在的实际问题，项目越大，软件越复杂，承担该项目所冒的风险也越大。

image-20211106154908794

优点

  • 对可选方案和约束条件的强调有利于已有软件的重用
    • 有助于把软件质量作为软件开发的一个重要目标
  • 减少了过多测试（浪费资金）或测试不足（产品故障多）所带来的风险；
  • 更重要的是，在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别

缺点

  • 风险驱动
    • 需要丰富的风险评估经验和专门知识，否则风险更大
  • 要求用户参与阶段评估
  • 过多的迭代次数增加了开发成本，延迟了提交时间

适用情况

  • 内部开发的大规模软件项目：方便中止
    • 但是如果风险分析费用接近整个项目的预算，则风险分析是不可行的
  • 不确定因素很多，很多东西开始无法计划的情况

Summary

四种模型总结
瀑布模型历史悠久、广为人知，它的优势在于它是规范的、 文档驱动的方法；这种模型的问题是，最终开发出的软件产品 可能并不是用户真正需要的。
快速原型模型正是为了克服瀑布模型的缺点而提出来的。它通过快速构建起一个可在计算机上运行的原型系统，让用户试用原型并收集用户反馈意见的办法，获取用户的真实需求。
增量模型具有可在软件开发的早期阶段使投资获得明显回报和较易维护的优点，但是，要求软件具有开放的结构是使用这种模型时固有的困难。
风险驱动的螺旋模型适用于内部开发的大型软件项目，但是，只有在开发人员具有风险分析和排除风险的经验及专门知识时，使用这种模型才会获得成功。

1-3 软件工程知识体系

软件工程知识体系（Software Engineering Body of Knowledge, SWEBOK）

image-20211106155852709

1-4 软件工程师职业素养

ACM / IEEE 职业道德准则

  1. 公众感——软件工程人员应始终与公众利益保持一致。
  2. 客户与雇主——软件工程人员应当在与公众利益保持一致的前提下，满足客户与雇主的最大利益。
  3. 产品——软件工程人员应当保证他们的产品及其相关附件达到尽可能高的行业标准。
  4. 判断力——软件工程人员应当具有公正和独立的职业判断力。
  5. 管理——软件工程管理者和领导者应当拥护并倡导合乎道德的有关软件开发和维护的管理方法。
  6. 专业——软件工程人员应当增进符合公众利益的专业的诚信和名誉
  7. 同事——软件工程人员应当公平地对待和协助每一位同事。
  8. 自己——软件工程人员应当毕生学习专业知识，倡导合乎职业道德的职业活动方式。
  • Communication skills
  • Honesty/Integrity
  • Teamwork skills
  • Interpersonal skills
  • Motivation/Initiative
  • Strong work ethic

02 方法与工具

软件工程方法学包含3个要素：方法、工具和过程。

  • 方法 — 完成软件开发的各项任务的技术方法，回答“怎样做”的问题；
  • 工具 — 为运用方法而提供的自动的或半自动的软件工程支撑环境；
  • 过程 — 为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。

2-1 方法

软件工程方法学分类：

  • 传统方法学（结构化软件工程方法）
  • 面向对象方法学

2-1-1 结构化方法

SA，SD，SP方法相互衔接，形成了一整套开发方法，称为结构化分析与设计技术。

结构化分析方法（Structured Analysis）

–> 结构化设计方法（Structured Design）

–> 结构化程序设计方法（Structured Program）

image-20211107155227091

特点

  • 自顶向下、逐步求精
  • 功能的分解与抽象
  • 符合人们的思维逻辑
  • 面向数据、面向过程、面向功能、面向数据流

不足

  • 处理过程和数据分离
  • 可重用性和可修改性差

2-1-2 面向对象方法

为克服传统软件工程方法复用性和可维护性差及难满足用户需要等缺点。

提倡运用人类的思维方式，从现实世界中存在的事物出发来构造软件。

以对象为中心，以类和继承为构造机制，来设计和构造相应的软件系统。

image-20211107155216827

对象

  • 类的实例
  • 属性 - 静态
  • 操作 - 动态

类

对象的抽象

封装

  • 隐藏内部私有属性、实现
  • 提供接口

继承

类间的层次关系，可使子类对象自动拥有父类对象的全部属性和操作

多态

父类的属性、操作被子类继承后，可有不同的实现机制

消息

对象发出的服务请求。

对象间的联系

  • 一般与特殊
  • 整体与部分
  • 实例连接——通过对象的属性来表现对象之间的依赖关系
    • Eg. 学生类和课程类之间存在 “学习”联系，这种联系是通过类中“课程编号”等属性建立
  • 消息连接——从请求者指向接受者

2-2 工具

主要是UML，统一建模语言（Unified Modeling Language）。

UML是用于描绘软件蓝图的标准语言，是一个通用的可视化建模语言。

特点

  • 标准统一
  • 面向对象
  • 可视化
  • 独立于过程

2-2-1 UML主要构成

image-20211107161744008

  • 事务（Things）：具有代表性的成分的抽象(结构、行为、组织、辅助)
  • 关系（Relationships）：事务之间的联系
  • 图（Diagrams）：事务和关系的可视化表示

2-2-2 图

图名称 图定 图性质
1 类图 一组类、接口、协作及它们的关系 静态图
2 对象图 一组对象及它们的关系 静态图
3 用例图 一组用例、参与者及它们的关系 静态图
4 顺序图 一个交互，强调消息的时间顺序 - 动态图
5 协作图 一个交互，强调消息发送和接受的对象的结构组织 - 动态图
6 状态图 一个状态机，强调对象按时间排序的行为 - 动态图
7 活动图 一个状态机，强调从活动到活动的流动 - 动态图
8 构件图 一组构件及关系 静态图
9 配置图 一组结点及它们的关系 静态图

image-20211107162025754


03 软件立项

就是在市场调查研究的基础上，分析立项的必要性（是否有市场前景）和可能性（是否有能力实现），并具体列出系统的功能、性能、接口和运行环境等方面的需求，当前客户群和潜在客户群的情况，以及投入产出分析，然后再编写立项建议书，并对它进行评审，评审通过后才算正式立项。

image-20211107164641529

3-1 立项建议

  • 目的：立项建议小组进行产品构思、立项调查和可行性分析，撰写相应文档并申请立项。
  • 角色与职责：立项建议小组实施本规程的所有活动
  • 启动准则：立项建议小组已经成立
  • 输入：与目标产品有关的任何信息
  • 主要步骤：（迭代进行）
    • 第一步：产品构思
    • 第二步：立项调查
    • 第三步：可行性分析
    • 第四步：撰写文档
    • 第五步：申请立项
  • 输出：《可行性分析报告》、《立项建议书》以及调查报告等文档
  • 结束准则：立项建议小组按照指定的模板撰写了《可行性分析报告》和《立项建议书》，并做了内部审查（消除拼写、排版等错误）。
  • 度量：立项建议小组统计工作量和上述文档的规模，将来汇报给项目经理。

3-1-1 产品构思

立项建议小组首先要在宏观层面上搞清楚“开发什么”、“怎样开发”、“怎样赚钱”等重大问题，即产品构思。

提炼后，最终写在《立项建议书》中。

3-1-2 立项调查

为产品构思和可行性分析提供充分的、有价值的信息。

主要内容有：市场调查；政策调查；同类产品调查；竞争对手调查；用户调查。

3-1-3 可行性分析

从各个方面去综合对比分析，对比成功或者失败的可能性有多大？值不值得立项？

市场可行性分析

分析市场发展历史与发展趋势，判断本产品处于市场的什么发展阶段。

政策可行性分析

有无政策“支持”或者“限制”；有无地方政府（或其它机构）的“扶持”或者“干扰”。

技术可行性分析

有限时间内完成功能的可行性，软件质量，开发效率等。

成本效益分析

开发成本【硬件、软件、开发、施工、培训成本+其他费用】

运营成本【人员费用、网络/服务器费用、维修费用、消耗品】

SWOT分析

强项（Strengths）弱项（Weaknesses）机会（Opportunities）威胁（Threats）

3-1-4 申请立项

image-20211107171335053

3-2 评审

立项建议小组把《立项建议书》、《可行性分析报告》递交给有决策权的机构领导。

一般地，立项评审委员会由机构领导、各级经理、市场人员、技术专家、财务人员等组成。委员会按少数服从多数原则投票决定是否同意立项（此时机构领导只是一名委员，不具有一票否决权）。

步骤

  • 第一步 评审准备。| 评审会议的时间、地点、设备和参会人员名单，材料。
  • 第二步 举行评审会议。
    • 主席宣讲本次评审会议的议程、重点、原则、时间限制等。
    • 立项建议小组陈述《立项建议书》的主要内容。
    • 评审委员会提出疑问，立项建议小组解答。双方应当对有争议的内容达成一致的处理意见。
    • 记录员记录答辩过程的重要内容（问题、结论、建议等）。
  • 第三步 评估。每个评审委员会根据“立项评审检查表”评估该项目。
  • 第四步 评审会议决议。评审委员会给出评审结论和意见。半数以上赞同，则结论为“同意立项”。
  • 第五步 机构领导终审。

3-3 筹备

  • 签订合同的方法与文档
  • 招标与投标
  • 下达任务的方法与文档

04 需求分析

任务：1) 深入描述软件的功能和性能；2) 确定软件设计的约束和与其他系统元素的接口细节；3) 定义软件其他有效性需求。研究一种无二义性的表达工具。

image-20211108085454016

需求分析的过程

image-20211108090411108

4-1 需求获取

需求的类型

功能需求；非功能需求；环境需求；用户界面需求；

此外还包括，可靠性需求、安全保密需求、可移植性、可维护性等方面需求。

4-1-1 需求的层次

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

各组成部分之间的关系

image-20211108091353022

4-1-2 获取方法

调查研究

① 与用户交谈，向用户提出问题。

② 参观用户的工作流程，观察用户的操作。

③ 向用户群体发放调查问卷表。

④ 与同行、专家交谈，听取他们的意见。

⑤ 分析已经存在的同类软件产品，提取需求。

⑥ 从行业标准、规则中提取需求。

⑦ 从Internet上搜索相关资料。

4-2 需求分析/建模

结构化分析方法；面向对象分析方法 ；原型方法。

4-2-1 结构化分析

自顶向下，逐步求精（逐层分解）；面向数据流。DFD

image-20211108092403569

  • DD | 数据字典：系统所涉及的各种数据对象的总和
  • ER图 | 描述数据对象间的关系、构建软件的数据模型
  • DFD图 | 指明系统中数据和数据流是如何流动和变换的
  • STD图 | 状态-变迁图：指明系统在外部事件的作用下将如何动作，表明系统的各种状态及其变迁

4-2-1-1 DFD

从数据传递和加工的角度，以图形的方式刻画信息流和数据从输入到输出的移动变换过程。

image-20211108093528153

分层DFD

image-20211108093659220

实例

image-20211108095824762

4-2-1-2 ER

数据建模

image-20211108095933088

4-2-1-3 STD

状态转移图

image-20211108100325503

4-2-2 面向对象分析

功能模型；对象模型；动态模型。

image-20211108101834046

  • 功能模型：指明系统应该“做什么” | 用例图
  • 对象模型：描述静态结构，定义做事情的实体 | 类图
  • 动态模型：描述交互过程，规定什么时候做 | 状态、顺序、协作、活动

分析过程

image-20211108102626977

4-2-2-1 用例建模

又称功能建模。

由用例图建立系统模型，有助于客户理解系统，帮助开发人员、测试人员、文档人员开展后续工作。

4-2-2-2 对象模型

描述系统的静态结构。

构成系统的类和对象的属性、操作，及他们间的关系。

  • 确定、定义类
  • 建立关联
    • 分类关系（归纳/一般与特殊关系）
    • 组成关系（组合/整体与部分关系）
    • 对象属性之间的静态的联系
    • 对象行为的动态联系

医院病房监护系统类图

image-20211108111121098

4-2-2-3 动态模型

对象及其关系的改变。

状态图；事件追踪图（顺序图/时序图）；协作图；活动图。

4-2-2-4 举例

面向对象的分析方法和步骤（举例）

  1. 分析使用场景 (Use Case)
  2. 标识类和对象
    • 名词作为候选对象类
    • 排列名词并分类对象
    • 筛选候选的对象类
  3. 画对象类图
  4. 组织类结构（继承、聚合关系）
  5. 定义主题（子系统）
  6. 画Sequence顺序图（轨迹图）
  7. 画Collaboration协作图
  8. 画State Transition状态转移图

4-2-3 原型方法

用户和软件开发人员之间进行的一种交互过程。需求不确定性高。快速、易于修改。

  • 废弃型
  • 追加型 / 演化型

image-20211108112150192

4-3 文档/评审/管理

需求规格说明；需求验证与评审；需求管理。

4-3-1 需求规格说明

软件需求规格（SRS，Software Requirement Specification）是需求分析阶段的最终所需交付的成果。

是客户、管理者、分析工程师、测试工程师、维护工程师交流的标准和依据。

描述了系统的数据、功能、行为、性能需求、设计约束、验收标准、以及其他与需求相关的信息。

分类：用户需求和系统需求。

实例

image-20211108113125374

4-3-2 需求验证与评审

在需求规格说明完成之后，对需求规格说明文档进行的验证活动。

目标：尽可能暴露问题。

image-20211108113355509

评审

  • 非正式评审
  • 正式评审

流程

image-20211108113449033

image-20211108113440077

4-3-3 需求管理

管理产品和产品构件的需求。一些需求的改进是合理的且不可避免。控制项目范围的扩展。

image-20211108113626785


05 软件设计

将用户需求准确转化为软件设计模型与文档的方法。

image-20211108120437502

  • 从工程管理的角度，可以将软件设计分为概要设计阶段和详细设计阶段。
  • 从技术的角度，传统的结构化方法将软件设计划分为体系结构设计、数据设计、接口设计和过程设计4部分。
  • 面向对象方法则将软件设计划分为体系结构设计、类设计/数据设计、接口设计和构件级设计4部分。

image-20211108121602037

5-1 设计任务

  • 体系结构设计：体系结构设计定义软件的主要结构元素及其之间的关系。
  • 类设计：对分析阶段的类模型细化，转化为设计类的实现及软件实现所要求的数据结构。
  • 数据设计：根据需求阶段建立的实体—关系图确定软件的文件系统结构及数据库的表结构。
  • 接口设计：描述UI，软件和硬件、其他系统、用户的外部接口，以及各种构件之间的内部接口。
  • 构件级设计：将软件体系结构的结构元素变换为对软件构件的过程性描述。
  • 过程设计：确定软件各组成部分内算法及数据结构，描述各种算法。

5-2 设计准则

  • 性能准则 | 系统速度和空间的需求
  • 可靠性准则 | 对减少系统崩溃/造成危害所做的努力程度
  • 成本准则 | 开发、配置、维护、管理系统和培训用户成本
  • 维护准则 | 开发后改变系统的困难程度
  • 最终用户准则 | 从用户视点出发所需的属性

5-3 设计原理

5-3-1 抽象

忽略事物间细微差别，将共同性质抽取出来。

  • 控制抽象 | 通过清晰的控制流程和部件间的接口，实现对复杂软件的分解，降低软件复杂度
  • 过程抽象 | 将处理过程抽象成函数或方法，通过参数列表不同来实现具体化应用
  • 数据抽象 | 数据库的表及表的字段，或类及类的属性

5-3-2 逐步求精

集中精力解决主要问题而尽量推迟对问题细节的考虑。实际上是细化过程，在抽象的基础上实现细节。

5-3-3 模块化

由边界元素限定的相邻的程序元素。

过程、函数、子程序等，都可作为模块。模块是构成程序/软件的基本构件。

数量需要适当

image-20211108153329938

特点

  • 信息隐藏 | （数据与过程）
  • 局部化 | 与信息隐藏密切相关，关系密切的软件元素物理地放得彼此靠近
  • 独立性 | 具体的子功能，高内聚低耦合

耦合 模块间相互连接/依赖的紧密程度；内聚 模块内各元素间结合的紧密程度。

5-3-3-1 耦合

尽可能松散耦合；模块间联系简单，发生在一处的错误传播到整个系统的可能性就很小。

① 非直接耦合/完全独立 No Direct Coupling

两个模块中的每一个都能独立地工作而不需要另一个模块的存在。

image-20211108160603767

② 数据耦合 Data Coupling

通过参数表交换数据，交换简单数据（而不是控制参数、公共数据结构或外部变量）。

是松散耦合，模块间独立性较强。

image-20211108160653481

③ 控制耦合 Control Coupling

模块彼此间传递的信息中有控制信息。增加了理解和编程的复杂性。

image-20211108161104160

去除办法

  • 判定上移到调用模块中
  • 被调用模块分成子模块
④ 公共耦合 Common Coupling

通过一个公共数据环境相互作用。

公共耦合的复杂程度随耦合模块的个数增加而显著增加。

image-20211108161545041

⑤ 内容耦合 Content Coupling

耦合程度最高。

image-20211108161821165

尽量使用数据耦合；少用控制耦合；限制公共耦合的范围；完全不用内容耦合。

5-3-3-2 内聚

理想内聚的模块只做一件事情。

① 巧合/偶然内聚 Coincidental Cohesion

模块内各部分间无联系或联系非常松散。例：模块M中的三个语句没有任何联系。

image-20211108162232993

可理解性差，可修改性差；模块是不可重用的。

② 逻辑内聚 Logical Cohesion

几种相关功能（逻辑上相似的功能）组合在一个模块内。

image-20211108162414417

多个操作的代码互相纠缠在一起，即使局部功能的修改有时也会影响全局，导致严重的维护问题。

解决办法：模块分解，如上图读记录和写记录模块分开，判定上移。

③ 时间内聚 Temporal Cohesion

模块包含的任务必须在同一段时间内执行。

如：初始化系统模块、系统结束模块、紧急故障处理模块等。

image-20211108162637451

④ 过程内聚 Procedural Cohesion

模块内处理元素相关，且必须以特定次序执行。

通过程序流图设计软件时得到的往往是过程内聚的模块。

image-20211108162939515

⑤ 通信内聚 Communicational Cohesion

模块中所有元素都使用同一个输入数据和（或）产生同一个输出数据。

比过程内聚更好。

image-20211108163124757

⑥ 顺序内聚 Sequential Cohesion

模块中各组成部分密切相关且必须顺序执行。

前一处理部分的输出就是下一处理部分的输入。

⑦ 功能内聚 Functional Cohesion

所有处理元素属于一个整体，完成一个单一的功能。

  • 模块可重用，应尽可能重用；
  • 可隔离错误，维护更容易；

image-20211108163356610

5-4 设计过程

5-4-1 软件体系结构设计

详见软件体系结构。

银行储蓄系统设计示例

Step01 DFD复查/精细化

image-20211108164734046

Step02 确定DFD变换特性

变换流 or 事务流

通过对精化后的数据流图进行分析，可以看到整个系统是对存款及取款两种不同的事务进行处理，因此具有事务特性。

Step03 确定I/O流边界

image-20211108164923972

Step04 一级分解

image-20211108164945906

Step05 二级分解

image-20211108165044214

Step06 精细化

image-20211108165153127

各子模块分别精细化，图过大省略。

5-4-2 数据设计

数据库设计

  • 组织结构 | 网状数据库、层次数据库、关系数据库、面向对象数据库、文档数据库、多维数据库等
  • 结构化设计方法中，容易将分析阶段建立的ER模型映射到关系数据库中

文件设计

适用于文件存储的情况

  • 数据量较大的非结构化数据，如多媒体信息。
  • 数据量大，信息松散，如历史记录、档案文件等。
  • 非关系层次化数据，如系统配置文件。
  • 对数据的存取速度要求极高的情况。
  • 临时存放的数据。

5-4-3 过程设计

使用图形工具、表格工具、语言工具（伪码）等来描述过程的细节。

示例

  • 程序流图
  • N-S图（盒状图）
    • image-20211108165932400
  • 问题分析图（PAD）
    • image-20211108165944828
  • 过程设计语言（PDL）
  • 判定表

5-4-4 用户界面设计

Human Computer Interface，简称HCI；User Interface，简称UI

接口设计包括

  • 模块或软件构件间的接口设计；
  • 软件与其他软硬件系统之间的接口设计；
  • 软件与人（用户）之间的交互设计。

06 软件实现

编码


07 软件测试

软件测试

  • 狭义上：测试是对软件产品质量的检验和评价

  • 广义上：测试是软件产品生存周期内所有的检查、评审和确认活动

基本概念

  • testing | 通过执行程序，暴露潜在的错误
  • debugging | 消除软件故障，保证可靠运行

测试 vs 纠错

image-20211108200439125

测试的特点

  • 挑剔性 | 抱着程序有错的目的进行
  • 复杂性 | 设计合适的用例需要细致和高度的技巧
  • 不彻底性 | 只能证明错误的存在，不能证明错误不存在
  • 经济性 | 有选择地测试，经济性

测试的原则

  • 尽早且不断测试
  • 用例应由 测试输入数据 和 预期输出结果 组成
  • 程序员避免测试检查自己的程序
  • 测试时应包括合理和不合理的输入条件
  • 注意集群现象
  • 排除随意性
  • 对每一测试结果全面检查
  • 妥善保存测试计划，形成报告

测试的对象

并不局限于程序测试。软件测试应贯穿于软件定义与开发的整个期间。

需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档（需求规格说明、概要设计规格说明、详细设计规格说明以及源程序）都是测试的对象。

image-20211108201426823

7-1 测试的过程模型

V W H X

V模型

image-20211108201504842

W模型

双V模型组成

image-20211108201600325

H模型

image-20211108201636697

X模型

image-20211108201652589

7-2 测试的方法分类

是否要执行软件

  • 动态测试
  • 静态测试

是否针对内部结构

  • 黑盒测试
  • 白盒测试

image-20211108202212871

7-2-1 静态测试

人工检测（代码评审）和计算机辅助静态分析。

人工

  • 桌面检查：程序员对源文件代码进行分析、检查并补充相关文档，发现程序中错误的过程
  • 走查：程序员和测试员组成的审查小组通过逻辑运行程序发现问题的过程
  • 代码审查：程序员和测试员组成的审查小组通过阅读、讨论、分析技术对程序进行静态分析的过程

计算机辅助

静态分析器在机器上以自动方式进行检查

7-2-2 黑盒测试

等价类划分法；边界值分析法；错误推测；因果图。

7-2-2-1 等价类划分法

选择少量有代表性的输入数据，来揭露尽可能多的程序错误。

将输入数据域按有效的或无效的（也称合理的或不合理的）划分成若干个等价类——有效等价类 + 无效等价类。

原则

  • 取值范围（e.g. input在0-100之间）
    • 有效等价类：0≤ x ≤100
    • 无效等价类：x<0 and x>100
  • 有限数值（e.g. 三角形的边数）
    • 有效等价类 x = 3
    • 无效等价类 x < 3 and x > 3
  • 下拉值（e.g. “职称”的值是初级、中级或高级）
    • 有效等价类 初级，中级，高级3个
    • 无效等价类 其他任何职称
  • 规则（Pascal变量标识符是以字母开头的串）
    • 有效等价类 以字母开头的串
    • 无效等价类 以数字/符号……开头的串
  • 输入值类型（e.g. 日期）
    • 有效等价类 日期类型的数据
    • 无效等价类 非日期类型数据

示例

image-20211108203501060

7-2-2-2 边界值分析法

程序往往在处理边界情况时发生错误。一般与等价类划分结合起来，将测试边界情况作为重点目标。

选取正好等于、刚刚大于或刚刚小于边界值的测试数据。

原则

  • 范围 0-100
    • 范围的边界 -1，0，100，101
  • 值的个数 3
    • 2，3，4
  • 对输出同样适用边界值（e.g. ouput: 0-10000）
    • input满足output为-1，0，999，10000的情况

示例

设某公司要打印2001～2005年的报表，其中报表日期为6位数字组成，其中，前4位为年份，后两位为月份。

Step 1. 划分等价类

image-20211108204122247

Step 2. 对有效等价类设计用例覆盖

image-20211108204306744

Step 3. 为每个无效等价类至少设计一个用例

image-20211108204409645

7-2-2-3 错误推测法

凭直觉和经验推测某些可能存在的错误，针对这些可能设计用例

7-2-2-4 因果图

略

7-2-3 白盒测试

逻辑覆盖法

语句覆盖；判定覆盖；条件覆盖；判定—条件覆盖；条件组合覆盖；路径覆盖。

7-3 测试步骤

综合策略

  • 在任何情况下都应使用边界值分析法。
  • 必要时用等价类划分法补充一些测试用例。
  • 再用错误推测法补充测试用例。
  • 检查上述测试用例的逻辑覆盖程度，如未满足所要求的覆盖标准，再添加测试用例。
  • 如需求说明中含有输入条件的组合情况，则一开始就可使用因果图法。

工作流

image-20211108210033681

步骤

image-20211108210102134

【完】

Categories: Software Engineering
dark
sans