软件工程导论复习

---

知识点

第1章 软件工程概述

• 软件危机是指在计算机软件开发和维护过程中遇到的一系列严重问题。

  • 产生软件危机的原因与软件开发与维护的方法不正确以及软件本身的特点有关。
  • 软件不同于硬件，开发过程的管理和控制相当困难。
  • 软件不会因为使用时间过长而被“用坏”，失效通常是因为发现了开发时期引入的错误。
  • 软件规模庞大，复杂性随规模呈指数上升。
  • 软件在运行和使用期间没有硬件那样的机械磨损、老化问题。
  • 软件失效与硬件失效过程不同：硬件失效率呈浴盆曲线（磨合、调整、磨损），而软件失效率可能因多次修改（维护引入新错误）而升高。
  • 图示解释：硬件失效率曲线（浴盆曲线）与软件失效率曲线对比。硬件初期磨合调整，后期磨损老化导致失效率升高；软件没有磨损老化，但维护修改可能导致失效率波动甚至升高。
  • 软件在不同阶段修改的代价曲线：在软件生命周期中，越晚发现和修改错误，付出的代价越高。
  • 消除软件危机的途径包括：对计算机软件有正确的认识；充分认识到软件开发是各类人员协同配合的工程项目。

• 软件工程的基本原理包括：

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

• 软件工程三要素：

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

• 软件工程方法学：

  • 传统方法学（结构化范型/生命周期方法学）：采用结构化技术完成开发任务，使用软件工具支持技术运用。特点是将软件生命周期的全过程依次划分为若干阶段，顺序完成任务；每个阶段有严格的开始和结束标准。
  • 面向对象方法：把数据和行为看作同等重要，以数据为主线，把数据和对数据的操作紧密结合起来的方法。

• 典型的软件过程模型：

  • 瀑布模型：将软件生命周期划分为八个阶段：问题定义、可行性研究、软件需求分析、系统总体设计、详细设计、编码、测试和运行、维护。可归纳为三个大的阶段：软件定义、开发阶段和运行维护阶段。瀑布模型要求严格管理，坚持阶段评审，实行严格产品控制。从瀑布模型看，需求分析阶段出错对软件的影响最大。

  • 快速原型模型：快速建立可在计算机上运行的程序，完成最终产品部分功能。特点是不带反馈环，软件产品开发基本上是线性顺序进行。相邻阶段无反馈的原因是原型系统已通过用户交互验证，规格说明正确描述用户需求。

  • 敏捷开发：更符合软件开发规律，软件开发是自底向上逐步有序的生长过程。遵循软件客观规律，不断进行迭代增量开发，最终交付符合客户价值的产品。敏捷开发是价值驱动的，与传统瀑布型模式的最大区别在于持续高可视化、高可适应性，更早且持续产出业务价值，更早发现和解决风险。常用的敏捷工程方法包括Scrum、看板方法、迭代开发、极限编程等，Scrum是其中最常用的（占54%）。

  • Scrum模型

    ：

    • 角色：Scrum Master（保证团队遵守规范，帮助采纳Scrum，指导团队，保护团队，消除障碍，帮助PO，不管理团队），Product Owner（一个人担任，负责管理和排序产品待办事项表Product Backlog，估算工作量，对项目成功和ROI负责），团队（自我组织，跨职能）。
    • 过程：头脑风暴 -> PO决定实现的功能 -> 时间估计（可用扑克牌游戏） -> 冲刺（Sprint） -> 评估。
    • 冲刺（Sprint）：团队实现迭代目标的时间区间，目标是可发布的软件产品。通常1-4周，时间长度决定何时结束，而不是工作量的完成。
    • 每日站立会议（Daily Stand-up）：站立进行，固定时间地点。回答3个问题：昨天完成了哪些工作？今天计划做哪些工作？遇到了哪些障碍？用于信息沟通，不解决问题，不向任何人汇报。
    • 回顾会议（Retrospective）：仅团队成员参与。讨论做得好的地方、不好的地方、可以改进的地方。
    • 迭代评审（Sprint Review）：团队展示完成的功能并获取反馈。PO接受/不接受当前迭代。邀请所有人参与。
    • 时间盒原则。

  • 微软开发过程：每个生命周期发布一个递进的软件版本，各个生命周期持续、快速地迭代循环。微软软件生命周期模型是一种迭代模型。

第2章 可行性研究

• 可行性研究的任务：用最小的代价，在尽可能短的时间内（一般占总工作量的5%-10%）确定能否解决问题以及是否值得解决问题。目的是“做还是不做”，而非“如何去做”。

• 可行性研究的内容：从技术可行性、经济可行性、用户操作可行性、社会环境可行性等方面评价系统是否值得做，是否能做。

  • 技术可行性：在给定限制内能否设计实现必要功能性能？开发人员、软硬件资源是否具备？相关技术发展是否支持？技术解决方案实用化合理化程度？简单表述为：做得了吗？做得好吗？做得快吗？。
  • 经济可行性：度量系统解决方案的性能价格比；进行开发成本估算及效益评估，确定项目是否值得投资开发。从经济角度分析开发是否能盈利，帮助决策是否投资。
  • 用户操作可行性：用户组织的结构、工作流程、管理模式是否适合目标系统运行？现有人员素质能否胜任操作？培训时间、成本如何？.
  • 社会环境可行性：包括市场（未成熟、成熟、将要消亡）、政策（影响大）、法律（侵权、破坏等问题，合同、责任、侵权、专利法、著作权法、计算机软件保护条例）.

• 典型可行性研究过程的步骤：

  1. 确定项目规模和目标：分析员调查访问，阅读材料，定义确认规模目标，描述限制和约束。确保正在解决的问题是要解决的问题。
  2. 研究正在运行的系统（当前系统）：可能是人工或旧计算机系统。是信息的重要来源，研究其基本功能、问题、费用及对新系统要求。收集分析文档资料，实地考察，访问，描绘高层系统流程图并审查.
  3. 建立新系统的高层逻辑模型：根据对现有系统研究，明确新系统功能、处理流程、约束。使用数据流图（DFD）和数据字典（DD）概括描述数据流动和处理.
  4. 导出和评价各种方案：从技术角度提出不同实现方案。根据技术、经济、社会可行性评估，去掉不可行解法，得到可行解法.
  5. 推荐可行的方案：根据可行性研究结果决定是否值得开发。若值得，说明方案及理由。通常项目从经济上看是否合算决定是否投资。分析员对推荐方案进行成本-效益分析.
  6. 草拟开发计划：项目开发的工程进度表、所需开发人员资源、估算成本.
  7. 编写可行性研究报告，提交审查：依据研究结果形成报告。提请用户和使用部门审查，决定是否开发、是否接受方案。报告必须提出明确结论（立即开始、需具备条件/修改目标、立即终止）.

• 系统流程图：用于了解要开发项目的大概处理流程、范围和功能。概况描绘物理系统的工具。用图形符号以黑盒子形式描绘物理系统各部件，表达信息在系统各部件之间流动情况。

  • 基本符号：显示、处理、输入/输出、数据流、文档。
  • 图示例：库存清单系统流程图。描述了输入终端CRT、事务处理部件（库存清单程序）、磁盘（库存清单主文件）、磁带（订货信息）、报告生成部件（报告生成程序）、打印文档（订货报告）之间的信息流动。习惯画法是信息自顶向下或从左到右流动。复杂系统可分解到单独页面。

• 数据流图（DFD）和数据字典（DD）：共同构成系统的逻辑模型. DFD描绘逻辑模型，DD定义DFD中的元素.

  • 数据流图（DFD）：图像化系统模型，展示信息系统主要需求：输入、输出、过程、数据存储。描述对象是逻辑模型。

    • 基本符号：外部实体（源点/终点，方形），数据流（带箭头的直线，数据在部件间流动），数据存储（两道平行线或开口矩形，静止状态的数据），过程（圆或圆角矩形，对数据进行加工处理），实时连接。

    • 图示例

      ：订货系统DFD。

      • 问题分析：源点/终点（仓库管理员/采购员），处理（处理事务、产生订货报表），数据存储（订货信息、库存清单），数据流（订货报表、事务）。
      • Step1：绘制基本系统模型：用高层次DFD突出源点和终点。仓库管理员 -> 事务 -> 订货系统 -> 订货报表 -> 采购员。
      • Step2：得到功能级数据流图：细化处理事务、产生报表，引入数据存储。仓库管理员 <-> 事务（处理事务1） <-> D1库存清单；处理事务1 -> 订货信息 -> 产生报表2 <-> D2订货信息；产生报表2 -> 订货报表 -> 采购员。
      • Step3：细化到功能实现级别：进一步分解功能级DFD（二级细化）。如图2.7，将某个过程分解为更小的过程.

    • 绘制注意事项

      ：

      • 一张DFD处理多于7个时难以理解，应分层绘制（层次DFD通过编号对应上下层关系，L0不编号，L1整数编号，L2整数后一位小数）.
      • 分层细化必须保持信息连续性，细化前后对应功能的输入输出数据必须相同. 图示例：图a细化前的DFD片段（处理1.1输入a，输出b和c），图b细化后的DFD片段（1.1细化为1.1.1, 1.1.2, 1.1.3，总输入a，总输出b和c，输入输出未变）.
      • 数据存储和数据流都是数据，状态不同（存储静止，流运动）.
      • 所有数据流必须以数据处理开始或结束，每个数据处理都应有输入输出.

    • DFD成分命名要求

      ：

      • 数据流/存储：代表整体内容，不要用缺乏具体含义的名字。流入流出数据存储的数据流可同名，其他需唯一.
      • 数据处理：动宾短语描述，例如“处理事务”.

  • 数据字典（DD）：关于数据的信息集合，是对数据流图中所有被命名图形元素的定义集合. 使得每个图形元素名字都有确切解释.

    • 需要定义内容

      ：数据流、数据存储、数据处理、数据元素.

      • 数据流：来源、去向、组成、流通量.
      • 数据元素：名称、别名、取值范围、含义、数据长度、小数位数、简单描述.
      • 数据存储：数据结构及数据存放规则.
      • 数据处理：数据处理的逻辑功能和主要算法.

    • 图示例：订货报表数据流定义. 定义其名字、别名、描述、定义（组成的数据元素/流）、位置. 例子中“订货报表 = 零件编号 + 零件名称 + 订货数量 + 目前价格 + 主要供应者 + 次要供应者 + 规格”. 数据元素（零件编号、订货数量、零件名称等）也需要定义其名字、别名、描述、定义、位置. 加工（数据处理）也需要定义.

    • 由数据元素组成数据的方式：顺序（+）、选择（|）、重复（{}或m{}n）、可选（()）.

    • 数据字典中的符号表示：= (定义为), + (和), | (或), () (可选), m..n (值域), {} (重复若干次), m{}n (重复次数最少m次，最多n次).

• 成本估算：软件开发成本主要是工作量及代价，主要是人的劳动消耗。软件产品不存在重复制造，开发成本以一次性开发过程代价计算。应以计划、需求分析、设计、编码到测试全过程代价为依据。

  • 估算思路：将价格计算延迟到设计最后（可靠但不实用）；基于已完成类似项目估算（无相似项目难实施）；使用简单分解技术估算成本工作量；使用经验模型估算。

  • 常用技术

    ：代码行技术、任务分解技术、自动估计成本技术、经验统计估计模型.

    • 代码行技术：成本 = 总代码行数 × 每行的平均成本. 需确定有效源代码行数，考虑工资水平.
    • 任务分解技术：根据生命周期（如瀑布模型）分解开发工作，分别估算成本累加. 通常只估算工作量（人月PM）. 成本 = 所需总人月数 × 每人月的成本. 规模大可分解子任务累加. 图示例：典型系统开发工作量比率. 可行性研究5%，需求分析10%，设计25%，编码和单元测试20%，综合测试40%.
    • 自动估计成本技术：利用软件工具计算.
    • 经验统计估计模型：Walston-Felix模型、Putnam模型、COCOMO模型.

  • 成本/效益分析步骤：通常取软件生命周期为5年.

• 可行性研究报告提纲：引言、要求、对现有系统进行分析、所建设开发的系统、可选择的其他系统方案、所建议的系统经济可行性分析、社会因素可行性分析、可选择方案和推荐、总结.

第3章 软件需求分析

• 系统需求：比用户需求更具技术特性的需求陈述。提供给开发者或技术人员阅读，作为设计起点依据。需要对功能、性能、数据等进行规格定义。

• 用户需求、功能需求、性能需求、非功能需求、外部接口需求、约束条件等共同构成了软件需求规格说明的内容.

  • 功能需求：系统应提供的功能或服务，通常涉及用户或外部系统与该系统的交互，不考虑系统内部实现细节。例如：用户可查询选择图书，系统提供浏览器阅读文献，每次借阅有唯一标识号记录到用户账户。
  • 性能需求：系统或构件必须具有的性能特性。例如：系统在5分钟内计算出总销售税，系统在1分钟内检索出销售定单.
  • 非功能需求：包括性能需求。

• 需求分析应构建功能模型（定义软件应完成的功能）、行为模型（描述外部事件结果的软件行为）、并对模型进行分解，用层次方式展示细节.

• 需求分析的任务：需求收集、需求整理、需求建模及软件规格说明、需求评审和验证.

  • 需求收集：活动包括公司/部门/业务介绍，需求产生场景。要点分析关注点（购买阶段、购买类型、兴趣点、角色相对影响力、评价标准）. 用户画像（玩家规模/付费特征示例）. 单项需求采集模板.

  • 需求整理：分析收集的信息，形成需求库.

  • 需求建模及软件规格说明：使用模型工具构建模型.

    • 数据流图（DFD）：见第2章. DFD整合了事件表和ERD.

    • 数据字典（DD）：见第2章.

    • 实体-联系图（ER图）

      ：描述客观世界中实体、联系和属性.

      • 实体（Entity）：客观存在并相互区别的事物，用矩形框表示. 例如：学生、教师、课程. 实体有属性来刻画.

      • 属性（Attribute）：实体或联系具有的性质，用椭圆形表示. 例如：学生的学号、姓名、专业.

      • 联系（Relationship）：事物间的关联，用菱形框表示. 例如：教师与课程间的“教”，学生与课程间的“选课”.

      • 基数（Cardinality）：描述实例间的关联（一对一1:1，一对多1:m，多对多n:m），表明重复性. 图示例：ER图中的基数表示.

      • ER图绘制方法：如图3.2某校教学管理ER图. 可以是抽象符号图，也可以是具体属性列表形式.

      • ER图的实现形式：可以将实体实现为二维表（关系），属性为列，具体实例为行.

      • 数据规范化

        ：将数据的逻辑结构归结为满足一定条件的二维表. 用范式（Normal Forms）定义消除数据冗余的程度.

        • 第一范式（1NF）：所有属性都是原子值，不出现“表中有表”. 图示例：存在大量重复数据（数据冗余）的表不满足1NF.

    • 类图示例：客户订单系统的类图.

    • 关联图：描述系统高层结构的DFD，所有外部实体和进出系统的数据流画在一张图中，整个系统表示为一个过程. 例如：课程注册系统关联图.

    • 状态转换图（State Transition Diagram）

      ：描绘软件的行为. 用于描述一个特定的实体或对象响应外部事件而产生的状态变化. 由状态、事件、活动、状态变迁组成.

      • 状态：在某个特定时刻可以观测到的系统属性的集合. 用圆角矩形表示. 初态用实心圆，终态用一对同心圆表示.
      • 事件：在某个特定时刻发生的事情，引起系统做动作或从一个状态转换到另一个状态. 例如：用户移动或点击鼠标. 状态变迁通常由事件触发，在箭头线上标注事件表达式. 事件表达式语法：事件说明[守卫条件]/动作表达式.
      • 活动表：语法格式：事件名(参数表)/动作表达式.
      • 图示例：复印机状态转换图. 状态有“闲置”、“复印”、“缺纸”、“卡纸”. 事件有“复印命令”、“完成复印命令”、“发现缺纸”、“装满纸”、“发生卡纸故障”、“排除了卡纸故障”.

  • 需求评审和验证：

    • 需求验证与确认的四个方面

      ：

      • 一致性：所有需求一致，不互相矛盾.
      • 完整性：需求完整，规格说明包括用户需要的每个功能或性能.
      • 现实性：需求基本上可用现有技术实现.
      • 有效性：需求正确有效，能解决用户问题.

    • 需求验证贯穿整个软件生命周期，是质量保障活动（评审、测试）. 最重要的是保障需求同源（测试用例由测试需求来，测试需求和系统需求对应，问题单跟踪）. 图示例：需求验证V模型.

    • 需求确认步骤

      ：

      1. 非正式需求评审：项目经理内部组织，消除明显错误分歧.
      2. 正式需求评审：邀请专家用户评审文档，确保正确反映用户意愿.
      3. 获取需求承诺：开发方和客户对需求文档做书面承诺，具商业合同效果.

• 本章小结：需求分析确定系统必须具有的功能、性能. 四个阶段：需求获取、整理、建模与规格说明、验证. 需求获取方法：访谈、自顶向下求精、简易应用规格说明、快速原型. 功能模型：DFD+DD，层次图. 数据模型：DFD，DD，IPO图，层次图，ER图（及规范化1NF-3NF）. 行为模型：状态转换图. 验证：一致性、完整性、现实性、有效性.

第4章 需求分析案例实践

• 考勤系统项目背景：甲方软件公司，约100员工（多数研发），有成熟管理方法. 考勤管理：上下班打卡，外出打卡，请假（事假、病假、年假等）需领导审批. 行政部统计考勤信息，财务部据此调整薪金.

  • 出现的问题：年休假管理问题影响员工积极性；考勤统计信息有误导致薪金误扣，行政财务相互推诿；领导无法快速知晓请假外出信息，影响工作安排.
  • 高层领导意识到问题：中层领导审批不合适；请假外出信息不能快速共享. 萌生开发考勤管理系统想法.

• 分析项目目标：实施项目达到的期望结果. 从背景、合同、方案书整理出系统目标. 理解目标是需求分析关键.

  • 甲方高层目标：规范员工上下班、请假、外出行为；方便计算薪金；方便管理带薪假期.
  • 补充目标（根据经验）：共享员工请假及外出信息.

• 分析相关者（涉众/利益相关者）：

  • 第1类：系统用户.
  • 第2类：对项目有商业决策权的人（客户高层，决定付款验收）.
  • 第3类：对项目成功有影响的第三方（如提供数据接口的系统所有者）.
  • 第4类：系统会影响到的第三方.
  • 可通过组织结构图表达相关者.
  • 考勤系统中典型的相关者：普通员工（冯难敌等）、行政部员工（苏荃等）、财务部员工（关安基等）、项目经理（吴六奇等）、部门经理（韦春花等）、副总经理（韦小宝）、总经理（陈近南）.

• 分析相关者待解决的问题：在项目目标范围内，解决相关者实际问题，满足其利益关系. 是需求分析工作的根本和基础.

  • 图示例

    ：考勤系统相关者待解决的问题表格.

    • 普通员工：方便打卡、申请、查看记录（自己和他人）、避免误扣工资/减少年假、方便查看可休年假.
    • 行政部员工：方便统计（不错）、与财务接口简单、方便管理带薪假期.
    • 财务部员工：方便调整薪金（不错）、与行政部接口简单.
    • 项目经理：及时知晓组员请假、临时外出申请手续简单.
    • 部门经理：方便审批、方便了解请假外出情况以便安排工作.
    • 副总经理：方便审批、检查下级审批、方便了解全体情况以便安排工作.
    • 总经理：方便审批、检查下级审批、方便了解全体情况以便安排工作、避免考勤问题影响士气效率.

• 分析项目范围：从功能、与其他系统关系、系统地域使用范围三个角度看. 功能由待解决问题表格基本限定. 与其他系统关系和地域范围一开始基本确定.

  • 注意减少与其他系统关系（降低复杂度），限定地域范围（要求差异巨大）.
  • 考勤系统的项目范围：功能由表格限定；与其他系统关系考虑引入财务接口，但考虑到财务系统老旧，可提供符合要求的考勤统计报表作为接口. 地域范围一处办公地点，约100人，易控制.

• 思考项目成功的标准：双赢原则指导下思考具体标准.

  • 考勤系统项目成功的标准：需求全部命中，性能达预期；成本两人月内；进度1个月；质量考勤出错率不超过1%，外出请假审批有效并共享. 还可从项目成员成长、公司技术积累等分析.

• 建立模型：

  • 对象模型：描述现实世界中的“类与对象”及关系，表示系统静态数据结构. 信息来源：需求陈述、应用领域知识、常识. 是理解需求、业务重组、数据库设计基础. 信息管理系统是对人、物、概念、事情的管理，可抽象成类.

  • 动态模型

    ：考虑审批涉及多角色、多判断，用带泳道的活动图表达合适.

    • 图示例：外出审批的动态表达（活动图）. 员工提出申请 -> 部门经理审批（批准/拒绝）-> 副总经理审批（批准/拒绝）-> 总经理审批（批准/拒绝）-> 通过审批/不通过审批. 区分了<=3天和>3天的审批流程.
    • 图示例：外出审批的动态表达（状态图）. 围绕“外出申请”对象，不同阶段状态不同. 状态：待定、部门经理已批准、副总经理已批准、总经理已批准、已拒绝、通过申请、放弃申请. 事件引起状态转换.
    • 图示例：请假审批的动态表达（活动图）. 引入行政部进行审核.
    • 图示例：请假审批的动态表达（顺序图）. 描述对象间交互顺序.
    • 讨论及方案例：请假审批流程中行政部审核与领导审批的顺序问题及请假拆分问题. 方案1：行政部前置审核；方案2：行政部分解；方案3：系统自动判断分解.

  • 功能模型

    ：用用例图和用例描述表达.

    • 图示例：最终宏观用例图. 清晰说明谁用系统，用到什么功能. 用例图中的用例可增加序号方便工作. 可对宏观用例图细化.
    • 图示例：宏观用例图细化. 普通员工的用例（管理外出/请假，查看全体/自己记录，查看年假）细化为更小的用例（提出/修改/删除/查看申请，查看年假情况）.
    • 用例描述：对每个细化用例进行描述，一般采用用例表形式.
    • 图示例：用例描述格式及“提出请假申请”用例描述示例. 包含编号、名称、执行者、优先级、描述、前置条件、基本流程、结束状况、可选流程、异常流程、说明. 基本流程描述正常情况下的执行者和系统的交互. 异常流程描述出错或异常情况下的流程.
    • 难以用用例图/描述表达的需求，可用文字、表格等方式.

• 分析整理非功能性需求：主要包括软件技术架构要求和安全性、易用性、性能等要求.

  • 考勤系统的非功能性需求图示例：技术架构图. 展示了PC客户端、Web App、数据库服务器、邮件服务器、打卡机、读取打卡机数据的软件、网络连接等组件关系.
  • 非功能性需求要点：安全性（验证授权、数据传输）、易用性（避免无法验证标准，如Email通知）、性能（正常/极端情况，需列出硬件配置）、接口（尽量避免，如不可避免限制单向只读，详细定义格式要求）.

第5章 形式化方法

• 形式化技术有优点也有缺点. 比非形式化方法更精确，减少二义性，提高软件质量，但学习成本高，不直观，用户不易理解.

• 有穷状态机（Finite State Machine, FSM）：描述一个特定实体或对象响应外部事件而产生的状态变化.

  • 概念：一个系统在任一时刻只能处于有限个预先定义好的状态之一，系统从一个状态到另一个状态的转换是由特定的事件引起的. 可以用一个五元组(S, I, O, f, h)定义，其中S为状态集，I为输入字母表(事件集)，O为输出字母表(动作集)，f为转换函数(f:S×I→S)，h为输出函数(h:S×I→O或h:S→O).

  • 扩展的有穷状态机：加入谓词集P，成为六元组. 转换函数T为(S×I×P)→S. 转换规则形式：当前状态+事件+谓词=>下个状态.

  • 图示例：菜单驱动用户界面可看作FSM实现.

  • 例子

    ：电梯系统规格说明.

    • 需求：m层大厦，n部电梯，按约束C1/C2/C3移动. C1: 电梯内按钮，按下灯亮，到达楼层熄灭. C2: 每层楼（除最低最高）有上下行按钮，按下灯亮，电梯到达并向要求方向移动时灯熄灭. C3: 无请求时关门停在当前楼层.
    • 分析：电梯按钮m×n个，楼层按钮每层2个.
    • 电梯按钮的状态转换图. 按钮有发光(ON)和不发光(OFF)两个状态. 事件：按钮被按下(EBP). 谓词：电梯停在某层(V(e,f)). 转换规则形式化描述：EBOFF(e,f)+EBP(e,f)+not V(e,f)=>EBON(e,f). EBON(e,f)+EAF(e,f) =>EBOFF(e,f) (EAF: 电梯到达f层).
    • 楼层按钮的状态转换图. 按钮有开(ON)和关(OFF)状态. 事件：按钮被按下(FBP)，电梯到达某层(EAF(1...n,f)). 谓词：电梯停在某层且方向确定(S(d,e,f)). 转换规则形式化描述：FBOFF(d,f)+FBP(d,f)+not S(d,1…n,f) =>FBON(d,f). FBON(d,f)+EAF(1…n,f)+S(d,1…n,f) =>FBOFF(d,f) (d=UorD).
    • 电梯本身的状态及其转换规则更复杂.

  • 评价：优点：简单格式易书写、验证，易转变为设计/代码。可开发CASE工具直接转为源代码。比DFD精确，易于理解。缺点：大系统三元组数量迅速增长。没有处理定时需求.

• Petri网（Petri Net）：用于确定并发系统中隐含的定时问题. 也可用于设计. 特别适用于描述并发活动. Carl Adam Petri发明.

  • 概念：包含4种元素：一组位置P (圆圈表示)，一组转换T (短直线表示)，输入函数I (位置指向转换的箭头)，输出函数O (转换指向位置的箭头). 形式化结构是四元组C=(P,T,I,O).

  • 标记（marking）M：Petri网中权标(token)的分配. 位置到非负整数的映射 M: P→{0, 1, 2, …}. 带有标记的Petri网是五元组(P, T, I, O, M).

  • 启动/激发（firing）：当每个输入位置的权标数大于等于从该位置到转换的线数时，就允许转换（启动）. 转换被激发时，输入位置的权标被移出，输出位置增加权标.

  • 图示例：Petri网结构及权标分配. 展示了t1和t2的输入/输出函数. 展示了标记(1,2,0,1) 及激发后的标记变化.

  • Petri网具非确定性，数个转换达到激发条件时，任意一个都可被激发. 权标总数不是固定的.

  • 重要扩充：禁止线 (小圆圈标记的输入线).

  • 例子

    ：电梯问题. 电梯用权标代表. 楼层用位置Ff代表. 电梯中楼层f的按钮用位置EBf表示.

    • 图示例：描述电梯按钮行为的Petri网. 展示了按钮未亮（EBf无权标），按下按钮（激发转换），在EBf放置权标（按钮亮）的过程. 也展示了电梯从g层到f层，FBf和Fg上的权标移走，EBf关闭，Ff出现新权标的过程.
    • 要处理时间问题，需加入时限.

  • 评价：用于处理并发问题. 比FSM更具描述能力，可描述并发活动. 缺点：建模过程复杂. 标准Petri网是瞬时转换，现实需时间控制Petri网.

• Z语言：一种形式化规格说明语言. 基于Zermelo-Fraenkel集合论和首阶谓词演算. 可用于描述系统静态和动态方面. 使用模式（schema）描述系统状态和操作. 优点：精确，减少二义性. 可降低开发费用. 可依据Z语言用自然语言重写规格说明，更清楚正确. 缺点：学习困难（即使只学过中学数学也能编写，但不一定能证明正确性）. 用户无法理解.

第6章 软件结构设计

• 总体设计阶段主要由系统设计和结构设计组成.

• 模块化（Modularity）：把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，集成起来构成整体.

  • 模块：作为一个整体处理的一级独立的、可识别的程序指令；大型程序指令的组成部分.
  • 模块化依据：使复杂大型程序能被人的智力管理，是软件应具备的唯一属性. 根据经验 C(P1+P2)>C(P1)+C(P2)，导致“各个击破”结论，分解复杂问题成容易解决的小问题.
  • 图示例：模块化示例（子系统划分 -> 模块划分 -> 零部件 -> 关键技术）.

• 逐步求精（Stepwise Refinement）：把精力集中在与当前开发阶段最相关的那些方面，忽略目前不需要考虑的细节，留到以后考虑.

  • 抽象与求精互补：抽象忽略底层细节（过程、数据），求精揭示底层细节.

• 信息隐藏和局部化（Information Hiding and Localization）：

  • 信息隐藏：设计模块时，使得一个模块内包含的信息（过程和数据）对于不需要这些信息的模块来说不能访问. 隐藏的是模块的实现细节——“细节隐藏”.
  • 局部化：把一些关系密切的软件元素物理地放得彼此靠近. 使用信息隐藏作为模块化设计标准，有利于测试和维护.

• 模块独立（Module Independence）：每个模块完成一个相对独立的子功能，且与其他模块关系简单. 是软件结构设计应遵循的最主要原理.

  • 模块独立度量：耦合（Coupling）*和*内聚（Cohesion）. （来源未详细定义耦合和内聚的具体类型和度量方法，只提到了概念）
  • 影响模块独立性的因素：模块间的接口. 力争降低模块接口的复杂程度. 应使信息传递简单且与模块功能一致. 接口复杂或不一致是紧耦合或低内聚征兆，应重新分析独立性.
  • 作用域与控制域的处理：设计过程中发现作用范围不在控制范围内，可采用将判定上移/合并到父模块、将受判定影响的模块下移、减少高扇出结构等办法.
  • 设计单入口单出口的模块. 避免内容耦合. 单入口单出口易于理解和维护.
  • 模块功能应该可以预测：输入相同产生相同输出. 带有内部存储器的模块功能不可预测，不易理解测试维护. 模块功能不应过于局限.

• 描绘软件结构的工具：层次图和结构图（SC）. 并不严格表示模块的调用次序和时间.

  • 层次图：描绘软件结构更合适，信息较少，清晰度高.

  • 结构图（SC）

    ：包含更多信息，描绘软件结构不如层次图合适.

    • SC基本符号：模块（矩形框表示一个模块/处理功能）、调用（带箭头的线，模块A调用模块B，箭头从A指向B）、数据参数（连接线上带圆圈的短箭头，表示数据从一模块传到另一模块）、控制参数（连接线上带实心圆的短箭头，表示控制信息）.
    • SC描述的模块种类：传入（从下级模块取得数据并传送上级）、传出（从上级模块取得数据并传送到下级）、变换（从上级取得数据加工成其它形式传回上级）、协调/控制（协调管理下属模块）、源（不调用其他模块的传入模块）、漏（不调用其他模块的传出模块）.
    • SC附加符号：简单调用（A调用B和C）、选择调用（A根据判断调用B或C或D）、循环调用（A根据循环重复调用B、C等模块）.

• 基于数据流图映射的设计过程：结构化设计方法通常由DFD导出软件结构. 主要分为变换分析和事务分析.

  • 图示例：基于变换流与事务流的总设计过程. 从DFD区分事务中心和动作路径，映射成事务结构或变换结构，精化评审.

  • 变换分析

    ：将变换型DFD映射到SC.

    • 变换型DFD：包含传入、变换中心、传出部分. 传入部分从外部输入取得数据，变换中心对数据进行特定处理，传出部分将处理结果传送到外部.
    • 映射步骤：Step1 划分边界（区分传入、变换中心、传出部分）. Step2 建立初始SC图框架（顶层主控模块，第一层包括传入、传出、变换中心模块）. Step3 分解SC图的各个分支（传入、传出、变换中心分别分解）.
    • 图示例：变换型DFD到SC映射方法步骤（Step1-Step5）. 展示了如何识别DFD的传入、变换中心、传出部分；如何构建初步的SC结构，包括主模块调用传入、变换、传出模块；如何进一步分解传入分支（例如从读取数据A到生成数据C的过程分解为多个子模块）；分解传出分支（例如从数据U到写入数据W的过程分解）；分解变换中心.

  • 事务分析

    ：设计步骤大部分与变换分析相同或类似. 主要区别在于由数据流图到软件结构的映射方法. 由事务流映射成的软件结构包括一个接收分支和一个发送分支.

    • 图示例：事务流和变换流的合并结构.
    • 图示例：变换型DFD初始SC（输入模块、主加工模块）. 事务型DFD初始SC（总控调用接受模块、调度、动作模块）.

  • 设计优化：按照设计原理和启发式规则进行优化. 原则：“先动起来，再快起来”.

第7章 面向对象设计

• OOA和OOD在概念上的区别：

  • OOA（面向对象分析）：提取和整理用户需求，建立问题域精确模型的过程.
  • OOD（面向对象设计）：将OOA阶段得到的需求转变为符合成本和质量要求的、抽象的系统实现方案的过程.
  • 从OOA到OOD是逐渐扩充模型的过程. 实际开发中界限模糊.

• OO方法强调开发过程的连续性.

• OOA的基本过程（与第4章的需求分析活动类似）：了解项目背景 -> 分析项目目标 -> 分析相关者 -> 分析相关者待解决的问题 -> 分析项目范围 -> 思考项目成功标准 -> 建立对象模型 -> 建立动态模型 -> 列出执行者，分析关系 -> 建立功能模型 -> 分析整理非功能需求 -> 整理需求文档与客户确认.

• OOD包括架构设计、物理结构设计、子系统层次设计、模块设计、数据设计、界面设计. OOD阶段得到设计模型（功能模型、对象模型、动态模型）.

• 软件设计的目标：在进度、成本限制下，做出高性价比的设计.

• 架构设计是考虑“全部需求”后做出来的. 需要考虑：什么人用系统？不同人用到什么功能？哪些不确定/不具体需求点？哪些需求对技术提出要求？系统大致架构如何考虑？.

  • 考勤系统精简后的用例图（示例）.

  • 不确定的需求点示例

    ：

    • ① 如何设计“即时了解”，及时收到提醒？短信提醒、邮件提醒、或者两者同时？.
    • ② 如何设计移动设备完成请假外出申请及审批？短信、手机上网，还是通过手机APP？.
    • ③ 工作流设计复杂性？工作流定义界面如何实现？“死”的还是“活”的？自己做、开源还是买商业？.
    • ④ 权限设计？基于角色还是用户？粗粒度还是细粒度？.

• 软件设计中的常见问题：

  • 需求并非孤立的“用户故事”组成，领域模型、动态模型、功能模型贯穿多个用户故事.
  • 业务逻辑层类难分拆与用户故事/界面对应，存在交叉、共享、重用.
  • 数据操作层代码可能通用或自动生成.
  • 数据层中的表通常支撑多个用户故事.

• 软件设计的三种策略：

  • 思路1，自顶向下：先做界面，再做其他部分. 需求含糊时可按此思路. 需求驱动，需求分析驱动设计.
  • 思路2，自底向上：先设计数据库，再搭建上层建筑. 需求明确，或有成型产品参考时可按此思路.
  • 思路3，由中间到上下：先不考虑界面和数据库，先定义中间部分，再向界面和数据库扩展. 如果程序需要支持多数据库，可能考虑此思路. 设计实体类及数据层接口，再设计接口实现.

• 本章小结：软件设计的四个方面（架构、数据、接口、模块/对象设计）. 架构设计概念、类型（逻辑/物理）、表示、思想、风格、过程. 数据设计重要性（参考需求分析章）. 接口设计（参考方法中接口定义）. 模块/对象设计（提到GRASP9个模式，需掌握理解）. 三种设计策略.

第8章 详细设计

• 结构程序设计：为了实际使用方便，除了基本结构外，允许使用DO-UNTIL和DO-CASE两种控制结构.

  • 经典结构程序设计：只允许顺序、IF-THEN-ELSE型分支、DO-WHILE型循环3种基本结构.

  • 扩展的结构程序设计：除经典3种，还允许使用DO-CASE型多分支、DO-UNTIL型循环.

  • 修正的结构程序设计：再允许使用LEAVE(或BREAK)结构.

  • 五种基本结构

    ：任何复杂的程序结构都应由这五种基本结构组合而成.

    1. 顺序结构 (sequential structure).
    2. 选择结构 (selective structure). IF-THEN-ELSE型分支.
    3. 先判定型循环结构 (while-loop structure). DO-WHILE型.
    4. 后判定型循环结构 (until-loop structure). DO-UNTIL型.
    5. 多情况选择 (case structure). DO-CASE型.

• 人机界面（用户界面，UI）设计：机器和人之间的接口，在整个软件设计中越来越重要. 探讨如何让界面更具可用性，让用户有良好体验，方便完成任务.

  • 概念：用户界面（UI）和用户体验（UE）. UE指产品如何与外界联系并发挥作用，人们如何“接触”或“使用”它.

  • 设计问题

    （UI设计过程中必须提前考虑）：

    1. 系统响应时间.
    2. 用户帮助设施.
    3. 出错信息处理.
    4. 命令交互.

  • 出错信息处理属性：用用户可理解的术语描述问题；提供恢复建议；指出可能后果；伴随提示；不能责怪用户.

  • 命令交互设计问题：菜单选项是否有对应命令？采用何种命令形式（控制序列、功能键、输入命令）？学习记忆难度？忘记命令怎么办？是否可定制缩写？.

  • 设计过程

    ：

    1. 根据产品需求文档，产生线形图（原型）. （有时产品先给交互讲需求，交互做低保真原型，再写PRD）.
    2. 形成视觉风格稿（设计组会议确定风格，产出后产品提意见修改）.
    3. 设计分工，完成设计工作.
    4. 界面切图移交前端工程师开发. 包括标注图（宽高距离颜色等）、效果图（界面样子）、切图（不规则图形、ICON等）. 完成后需产品审核.

  • 人机界面设计指南

    ：一般交互指南（信息显示、数据输入、系统控制）. 信息显示指南（文字、图形、声音，位置、大小、颜色等）. 数据输入指南（用户大部分时间用于此）.

    • 一般交互指南要点：保持一致性（菜单选择、命令输入等风格一致，如wps）. 提供有意义的反馈（视觉听觉等，建立双向通信）.

• 过程设计（详细设计阶段主要工作）工具：

  • 程序流程图（Program Flow Chart, PFC）

    ：用图形符号表示算法的工具. 允许使用跳转语句使控制流离开基本结构.

    • 绘制标准：国家标准GB1525-89，与ISO5807-85一致. 图示例：标准流程图符号（与五种基本结构图形一致）. 图P125图6.3不规范，学校默认只采用五种基本图形.
    • 图示例：在一组数中找出最大数的程序流程图. 展示了顺序、判定（I<N, MAX<A[I]）、循环结构.

  • 盒图（Nassi-Shneiderman Chart, NS图）

    ：由Nassi和Shneiderman提出，不允许任意跳转语句. 完全使用基本控制结构表示程序结构.

    • 图示例：NS图基本符号（顺序、选择、循环等）.
    • 图示例：NS图基本结构（顺序、IF-THEN-ELSE、WHILE-DO、REPEAT-UNTIL、CASE）及与流程图对照.

  • PAD图（Problem Analysis Diagram）

    ：由日本日立公司提出，用二维树形结构表示程序控制流. 用PAD符号从左向右展程序逻辑.

    • 图示例：PAD基本符号（输入、输出、处理、重复、选择、子程序、定义、语句标号）.
    • 图示例：PAD图基本图式和C语言标准模式对照（顺序、选择、重复）.
    • PAD图具有良好的结构性、清晰性，适合自顶向下、逐步求精.

  • 伪代码（Program Design Language, PDL）

    ：用自然语言加结构化控制语句描述程序逻辑. 可采用结构化语言、IPO图、判定树、判定表等方式描述数据处理的逻辑功能和主要算法.

    • 基本控制结构：IF-ELSEIF-ELSE-ENDIF，IF-ENDIF (判断重复)，Do while/until/for each. 用简单陈述句表达顺序结构，避免复合语句.
    • 例子：伪代码实例：“检查订货单”.

• 面向数据结构的设计（data structured-oriented design）：Jackson等人提出. 认为流程图不是最好设计工具，应首先考虑问题结构，流程图让人考虑程序执行顺序（算法），掩盖问题结构.

  • Jackson方法用图表示数据结构，然后将数据结构映射成程序结构. 将程序结构分解为基本结构（顺序、选择、循环）.
  • 图示例：Jackson图表示基本结构（顺序、选择、循环）.

• McCabe方法：使用环形复杂度（Cyclomatic Complexity）定量度量程序的复杂程度.

  • 概念：基于程序控制流图（Flowgraph）. 将流程图、NS图、PAD图、PDL等映射成流图. 流图是简化流程图，结点表示处理，边表示控制流. 包含条件的结点称为判定节点.

  • 图示例：程序流程图映射成流图示例. NS图映射成流图示例. 复合条件的PDL映射成流图示例.

  • 计算环形复杂度V(G)的方法

    ：

    1. 流图G划分成的区域数（包含外部区域）.
    2. E - N + 2，其中E是流图中边的条数，N是结点数.
    3. P + 1，其中P是流图中判定结点的数目.

  • 环形复杂度值高表示程序复杂，不易测试和维护. 建议V(G)不超过10.

• 本章小结：详细设计主要工作是过程设计. 掌握流程图、NS图、PAD图、判断表/树、伪代码等工具. 重视人机界面设计. 了解面向数据结构设计（Jackson方法）. 使用环形复杂度度量复杂程度，掌握McCabe方法.

第9章 软件测试

• 软件测试的目标：为了发现程序中的错误而执行程序的过程，目标是发现程序中的错误. 测试不能证明程序是正确的，可能仍潜藏错误.

• 软件测试准则：

  • 所有测试应能追溯到用户需求.
  • 测试计划应在测试开始之前制定.
  • Pareto原理（二八定律）应用到软件测试（约80%错误由约20%模块引起）.
  • 从“小规模”测试开始，逐步进行“大规模”测试.
  • 穷举测试是不可能的.
  • 为达最佳效果，应由独立的第三方从事测试工作.

• 测试方法：

  • 黑盒测试（功能测试）：把程序看作黑盒子，不考虑内部结构处理过程. 在程序接口进行，测功能.
  • 白盒测试（结构测试）：把程序看成装在透明白盒子里，测试者知晓程序结构处理算法. 在程序内部进行，测逻辑. 常见的两种白盒测试方法：逻辑覆盖和路径测试.

• 测试步骤（层次性）：后一个步骤是前一个步骤的继续. 大型软件系统测试过程基本由五个步骤组成.

  • （1）单元测试（模块测试）：保证每个模块作为单元能正确运行. 发现编码和详细设计错误. 单元测试和编码同属一个阶段，主要使用白盒测试技术. 对多个模块可并行. 重点：模块接口、局部数据结构、边界条件、重要执行通路、出错处理. 可进行代码审查（人工测试源程序，其他程序员/审查小组审查，编写者讲述逻辑，对照错误清单分析记录修改）.
  • （2）集成测试：把经过单元测试的模块放在一起形成子系统来测试. 主要问题是模块间的协调和通信，着重测试模块的接口. 发现模块间接口错误，低层关键模块错误发现较晚（自顶向下）或较早（自底向上）.
  • （3）系统测试（系统集成测试）：把经过测试的子系统装配成完整系统来测试. 发现设计和编码错误，验证系统提供需求功能，动态特性符合要求. 发现软件设计错误，可能发现需求说明错误. 目的是对最终软件系统进行全面测试，确保满足需求并遵循设计.
  • （4）验收测试（确认测试）：内容与系统测试一致，用户积极参与，可能用实际数据. 目的是验证系统确实能满足用户需要. 发现需求说明书错误. 软件需求规格说明书是基础. 范围：测试所有功能/性能要求是否满足，文档是否准确完整. 测试其他要求（安全性、可移植性、兼容性、可维护性）是否满足. 需进行软件配置复查（保证配置成分齐全，质量符合要求，文档程序一致，目录编好，检验使用手册完整性正确性）.
  • （5）平行运行：同时运行新旧系统，比较处理结果.
  • 测试的层次性小结图示例. 展示了模块/单元测试、集成测试、系统测试、验收测试的输入信息（需求信息、设计信息）、测试对象、输出（测试报告）、进行阶段（编码阶段、测试阶段、甲方验收阶段）以及它们之间的依赖关系.

• 集成测试策略：

  • 自顶向下集成

    ：从主控制模块开始，沿程序控制层次向下，逐渐结合模块.

    • 实施策略：先广度后深度 或 先深度后广度.
    • 图示例：多模块程序结构图. 展示了先广度后深度、先深度后广度的组装顺序.
    • 自顶向下测试需要桩模块（Stub）. 桩模块用于代替下级模块，接收调用参数，返回固定或模拟结果，模拟下级模块功能. 图示例：先深度后广度测试时所需的桩模块示例. 展示了测试M1时需要桩模块S2,S3,S4；测试M1-M2-M5时需要桩模块S3,S4,S6,S8等.

  • 自底向上测试

    ：从软件结构最低层无下级模块的模块开始组装测试. 逐加新模块组成子系统，重复直至所有子系统组装为完整程序.

    • 自底向上测试需要驱动模块（Driver）. 驱动模块用于调用上级模块，模拟上级模块对被测模块的调用 [未直接在图中展示，但根据描述和自顶向下对桩模块的需求，可知自底向上需要驱动模块]
    • 图示例：自底向上组装顺序示例（M8->M5->M6->M2为一个群，M7->M4->M3为另一个群，最后合并测试）.

  • 混合测试方式：对上层用自顶向下，对下层用自底向上.

  • 不同集成测试策略的比较

    ：

    • 自顶向下优点：不需测试驱动，早期实现验证主要功能，早期发现上层接口错误. 缺点：需桩模块，低层关键模块错误发现晚.
    • 自底向上优缺点与自顶向下相反.

• 回归测试（Regression Testing）：集成测试中，每并入一个模块，除新测试项外，重复进行先前测试. 目的是检查修改是否引入新错误或破坏原有功能.

  • 回归测试集包括3类测试用例：检测软件全部功能代表性用例；针对可能受修改影响功能的附加测试；针对被修改过的成分的测试.

• 确认测试（Confirmation Testing）：参见验收测试.

  • Alpha测试与Beta测试

    ：针对很多客户使用的软件.

    • Alpha测试：受控环境下，用户在开发者指导下测试，开发者负责记录错误.
    • Beta测试：最终用户在自己场所测试，开发者通常不在场，不控制环境. 用户记录错误，定期交给开发者解决.

• 白盒测试技术：测试者清楚盒子内部结构和运作方式. “白盒”法是穷举路径测试，但不可能，选用少量“最有效的”测试数据尽可能完备测试.

  • 逻辑覆盖（Logic Coverage）

    ：用流程图设计测试用例. 考察判定框（选择或循环）. 按照测试有效程度由弱到强分5种覆盖标准.

    • 5种覆盖标准（由弱到强）

      ：

      1. 语句覆盖：保证源程序中每个语句至少被执行一次. 图示例：保证A∧B=T执行print语句.
      2. 判定覆盖（分支覆盖）：每个判定的每个分支至少执行一次. 图示例：保证A∧B=T和A∧B=F都被执行.
      3. 条件覆盖：每个简单条件的每个可能取值至少出现一次. 图示例：保证A=T, A=F, B=T, B=F都被执行.
      4. 判定/条件覆盖：兼顾判定覆盖和条件覆盖.
      5. 条件组合覆盖：每个判定中所有可能的条件取值组合至少执行一次.
      6. 路径覆盖：覆盖程序中所有可能的路径. （强度最强，但现实中路径数量可能是天文数字，不可行）

  • 路径测试（Path Testing）：用控制流图设计测试用例. 目标是覆盖所有独立的执行通路. 基本路径测试（Basis Path Method）是重要路径测试方法.

• 调试（Debugging）：及时改正测试过程中发现的软件错误.

  • 方法

    ：

    • 蛮干法：激活跟踪，到处写print语句找错误线索.
    • 回溯法：从小程序发现症状处开始，人工沿控制流往回追溯分析源程序. 程序规模大时路径多，不适用大规模程序.
    • 对分查找法：已知关键点正确值，在程序中点附近“注入”正确值，运行检查输出. 根据输出判断错误在前/后半部分，重复此法缩小范围.
    • 归纳法：从个别现象推断一般结论. 分析错误相关数据找可能原因，导出假设，用已有数据证明或排除.
    • 演绎法：从一般原理或前提出发，排除精化推导结论. 设想所有可能原因，用测试排除每个假设.

• 软件可靠性（Software Reliability）：在给定时间间隔内，程序按照规定条件成功运行的概率 R(t). 程序中潜藏的错误数目直接决定软件可靠性.

  • 系统的稳态可用性（Availability）：运行总时间 / (运行总时间 + 停机总时间). A = Tup / (Tup + Tdown).
  • 与平均无故障时间（MTTF）和平均维修时间（MTTR）概念相关. 稳态可用性 A = MTTF / (MTTF + MTTR).
  • 估算平均无故障时间MTTF的方法：MTTF与单位长度程序中剩余错误数成反比. 公式涉及测试前错误总数ET，程序长度IT，测试时间τ，发现错误数Ed(τ)，改正错误数Ec(τ). 单位长度程序中剩余错误数为εr(τ) = ET/IT - Ec(τ)/IT.

---

习题（AI）

软件工程 - 第1章

1. 简答题：

   产生软件危机的原因主要有哪些？

   • 参考答案： 与软件开发与维护的方法不正确有关；与软件本身的特点有关，如软件不同于硬件，开发过程管理困难，软件在运行过程中不会被“用坏”，软件规模庞大且复杂性呈指数上升；软件不会磨损，但为了克服故障、适应环境变化和用户新要求需要多次修改（维护），每次修改可能引入新的错误，导致失效率升高。

2. 填空题：

   软件在生存期中，在不同阶段进行修改，需要付出的代价曲线表明其代价是随开发阶段的推移而呈____趋势。

   • 参考答案： 上升/增加

3. 简答题：

   消除软件危机的途径有哪些？

   • 参考答案： 对计算机软件有一个正确的认识；充分认识到软件开发是各类人员协同配合，共同完成的工程项目。

4. 填空题：

   软件工程的三要素是方法、工具和____。

   • 参考答案： 过程

5. 选择题：

   在软件工程三要素中，回答“怎样做”的问题的是（）。

   • A. 方法
   • B. 工具
   • C. 过程
   • D. 原则
   • 参考答案： A

6. 简答题：

   请简述传统方法学（结构化范型）的特点。

   • 参考答案： 把软件生命周期的全过程依次划分为若干个阶段，然后顺序地完成每个阶段的任务；每个阶段的开始和结束都有严格标准，前一阶段的结束标准就是后一阶段的开始标准。

7. 填空题：

   瀑布模型将软件生命周期划分为定义、开发、和____三个大的阶段。

   • 参考答案： 运行维护阶段

8. 选择题：

   实际的瀑布模型中，当在后面阶段发现前面阶段的错误时，需要通过____返回前面的阶段进行修正。

   • A. 前馈线
   • B. 反馈线
   • C. 顺序线
   • D. 跳跃线
   • 参考答案： B

9. 简答题：

   瀑布模型的优点主要有哪些？

   • 参考答案： 可强迫开发人员采用规范的方法（例如，结构化技术）；严格地规定了每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。

10. 简答题：

    快速原型模型的主要优点是什么？为什么相邻阶段没有反馈环？

    • 参考答案： 主要优点是不带反馈环，软件产品的开发基本上是线性顺序进行的。相邻阶段没有反馈的原因是原型系统已经通过与用户交互得到验证，产生的规格说明文档正确描述了用户需求，后续阶段不会因规格说明错误而较大返工；开发人员通过建立原型系统已经学到了很多东西，设计和编码阶段错误可能性较小，减少了后续阶段改正前面错误的可能性。

11. 简答题：

    增量模型（渐增模型）的核心思想是什么？它的优点有哪些？

    • 参考答案： 核心思想是把软件产品作为一系列的增量构件来设计、编码、集成和测试。优点是能在较短时间内向用户提交可完成部分工作的产品；逐步增加产品功能可以使使用者有更充裕时间学习适应新产品，减少全新软件带来的冲击。

12. 填空题：

    螺旋模型的基本思想是，使用原型及其他方法来尽量____。

    • 参考答案： 降低风险

软件工程 - 第2章

1. 填空题：

   可行性研究的任务是用最小的代价，在尽可能短的时间内确定能否解决问题以及____。

   • 参考答案： 是否值得解决问题

2. 简答题：

   可行性研究的目的是什么？它主要从哪几个方面评价系统？

   • 参考答案： 可行性研究的目的是“做还是不做”，而非“如何去做”。它主要从技术可行性、经济可行性、用户操作可行性、社会环境可行性等方面评价系统是否值得做，是否能做。

3. 简答题：

   请简述技术可行性、经济可行性、用户操作可行性、社会环境可行性关注的内容。

   • 参考答案： 技术可行性关注在给定限制内能否设计实现必要功能性能、开发人员/软硬件资源是否具备、相关技术发展是否支持、技术解决方案实用化合理化程度。经济可行性度量解决方案性能价格比、进行开发成本估算及效益评估，确定项目是否值得投资开发。用户操作可行性关注用户组织结构、工作流程、管理模式是否适合系统运行、现有人员素质能否胜任操作及培训时间/成本。社会环境可行性包括市场、政策、法律等方面。

4. 填空题：

   可行性研究典型过程的第一步是确定项目规模和目标，最后一步是____。

   • 参考答案： 编写可行性研究报告，提交审查

5. 选择题：

   在可行性研究过程中，通过分析员对有关人员进行调查访问，仔细阅读和分析有关的材料，对项目的规模和目标进行定义和确认，清晰地描述项目的一切限制和约束的步骤是（）。

   • A. 研究正在运行的系统
   • B. 确定项目规模和目标
   • C. 建立新系统的高层逻辑模型
   • D. 导出和评价各种方案
   • 参考答案： B

6. 简答题：

   系统流程图的作用是什么？它是一种描绘物理系统还是逻辑模型的工具？

   • 参考答案： 系统流程图用于了解要开发项目的大概处理流程、范围和功能。它是一种描绘物理系统的工具。

7. 选择题：

   系统流程图的基本符号不包括（）。

   • A. 处理
   • B. 数据存储
   • C. 数据流
   • D. 文档
   • 参考答案： B (数据存储是DFD的符号，不是系统流程图的基本符号)

8. 简答题：

   数据流图（DFD）和数据字典（DD）在描述系统模型时各自的作用是什么？它们共同构成系统的哪种模型？

   • 参考答案： 数据流图（DFD）描绘系统的逻辑模型，展示信息系统的主要需求（输入、输出、过程、数据存储）。数据字典（DD）是对数据流图中所有被命名图形元素的定义集合，使得每个图形元素名字都有确切解释。它们共同构成系统的逻辑模型。

9. 填空题：

   数据字典中需要定义数据流、数据存储、数据处理以及____。

   • 参考答案： 数据元素

10. 填空题：

    在数据字典中，表示“或”的符号是____。

    • 参考答案： |

11. 填空题：

    在数据字典中，表示重复若干次的符号是____。

    • 参考答案： { }

12. 简答题：

    在可行性研究中进行成本估算时，通常使用的估算技术有哪些？

    • 参考答案： 代码行技术、任务分解技术、自动估计成本技术、经验统计估计模型。

软件工程 - 第3章

1. 简答题：

   软件需求的层次包含哪些？请列出至少5种。

   • 参考答案： 业务需求、用户需求、系统需求、功能需求、非功能需求、性能需求、约束条件、业务规则、外部接口需求。

2. 简答题：

   业务需求和用户需求有什么区别？请举例说明。

   • 参考答案：

     业务需求是客户对系统的高层次目标要求，定义项目的远景和范畴。用户需求是从用户角度描述系统功能需求与非功能需求，通常只涉及系统对外表现出的行为，不涉及系统内部特性。

     • 例如：业务需求是学校希望用计算机管理学生选课；用户需求是教务管理员希望能够增加、修改、删除课程目录和设置课程开设信息，学生希望能在学期开始前查询开设课程信息并通过校园网选课。

3. 填空题：

   ____是比用户需求更具有技术特性的需求陈述，是提供给开发者或用户方技术人员阅读的，并作为软件开发人员设计系统的起点与基本依据。

   • 参考答案： 系统需求

4. 简答题：

   功能需求和性能需求分别关注系统的什么方面？请各举一例。

   • 参考答案：

     功能需求关注系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互。性能需求关注一个系统或系统构件必须具有的性能特性。

     • 功能需求示例：用户可从图书资料库中查询或者选择其中一本书。
     • 性能需求示例：系统应该在5分钟内计算出给定季度的总销售税。

5. 简答题：

   需求分析的任务主要包括哪四个阶段？

   • 参考答案： 需求收集、需求整理、需求建模及软件规格说明、需求评审和验证。

6. 简答题：

   在需求调查时，通常会询问的三个主要问题是什么？

   • 参考答案： 要做什么（商业过程和运作是什么，理解商业功能）；怎样做（商业过程如何完成，转向新系统的方法）；需要哪些信息（信息需求是什么，定义新系统必须提供的具体信息）。

7. 简答题：

   DFD、DD、ER图和状态图在需求建模中各自的作用是什么？

   • 参考答案： 数据流程图（DFD）是一种图像化的系统模型，展示信息系统的主要需求：输入、输出、过程和数据存储，描绘系统的逻辑模型。数据字典（DD）是对数据流图中所有被命名图形元素的定义集合，对数据流图中的元素进行详细定义。实体-联系图（ER图）描绘客观世界中事物（实体）及其彼此间的联系和属性。状态图（状态转换图）描绘系统的动态行为，表示系统对外部事件的响应以及引起的状态转换。

8. 简答题：

   在绘制ER图时，实体、属性、联系通常用哪些图形符号表示？

   • 参考答案： 实体用矩形表示；属性用椭圆表示；联系用菱形表示。

9. 填空题：

   在ER图中，____表明了实体之间实例关联的重复性，例如一对一、一对多、多对多。

   • 参考答案： 基数

10. 简答题：

    验证软件需求的正确性通常从哪四个方面进行？

    • 参考答案： 一致性（所有需求必须一致，不能矛盾）；完整性（需求必须完整，包括用户需要的每一个功能或性能）；现实性（指定的需求应是基本上可以实现的）；有效性（必须证明需求正确有效，确实能解决用户问题）。

11. 简答题：

    需求验证和确认贯穿整个软件生命周期，它不是严格意义上的一个阶段，而是一系列质量保障活动。这些活动包括哪些？

    • 参考答案： 包括评审、测试，最重要的是保障需求同源。

12. 简答题：

    需求确认的步骤主要包括哪些？

    • 参考答案： 非正式需求评审、正式需求评审、获取需求承诺。

软件工程 - 第4章

1. 简答题：

   考勤系统项目背景中，在引入新的考勤管理系统之前，现有管理方式存在哪些主要问题？

   • 参考答案： 年休假管理问题影响员工积极性；考勤统计信息有误导致薪金误扣，行政财务相互推诿；请假或者外出信息不能迅速在公司范围内共享，可能导致工作上的麻烦；中层领导的某些请假审批可能不合适。

2. 简答题：

   请列出考勤系统项目的主要目标（包括甲方高层提出的和根据经验补充的）。

   • 参考答案： 规范员工的上下班、请假、外出工作等行为；方便计算员工的薪金；方便管理各种带薪假期；共享员工的请假及外出的信息。

3. 简答题：

   在软件项目中，相关者（涉众、利益相关者）可以分为哪几类？请简述每一类。

   • 参考答案： 第1类是系统的用户，即使用该系统的人。第2类是对该项目有商业决策权的人，如客户的高层领导，对项目付款、验收等有决定权。第3类是对项目的成功有影响的第三方，如提供数据接口的系统所有者。第4类是系统会影响到的第三方。

4. 填空题：

   分析相关者待解决的问题是需求分析工作的_和_。

   • 参考答案： 根本，基础

5. 简答题：

   分析项目范围通常从哪三个角度来看？在分析项目范围时应注意什么？

   • 参考答案： 功能、与其他系统的关系、系统的地域使用范围。应注意减少与其他系统的关系以降低复杂度，限定系统的地域使用范围因为不同范围要求差异巨大。

6. 简答题：

   考勤系统项目成功的标准可以从哪些方面思考和制定？请列出至少4个方面。

   • 参考答案： 需求（是否全部命中）；性能（是否达到预期）；成本（是否在预算内）；进度（是否按时完成）；质量（如考勤出错率、审批有效性）；项目成员成长；公司技术积累。

7. 简答题：

   对象模型在需求分析中的作用是什么？它的主要信息来源有哪些？

   • 参考答案： 对象模型描述现实世界中的“类与对象”及它们之间的关系，表示目标系统的静态数据结构。是准确全面理解需求、进行业务重组、数据库设计的基础。主要信息来源是需求陈述、应用领域的专业知识以及关于客观世界的常识。

8. 简答题：

   在考勤系统的案例中，动态模型主要用哪两种图来表达审批流程？它们各自的特点是什么？

   • 参考答案： 主要用活动图和状态图。活动图适合表达涉及多角色、多判断的审批流程，用泳道表示不同角色。状态图适合表达某个对象（如“外出申请”）在不同阶段的状态变化以及引起状态转换的事件。

9. 简答题：

   功能模型主要用哪两种方式来表达系统的功能？请简述用例描述（用例表）包含的主要内容。

   • 参考答案： 主要用用例图和用例描述来表达。用例描述通常采用用例表形式，包含编号、名称、执行者、优先级、描述、前置条件、基本流程、结束状况、可选流程、异常流程、说明等内容。

10. 简答题：

    非功能性需求主要包括哪两个部分？在考勤系统的案例中，非功能性需求主要关注哪些方面？

    • 参考答案： 主要包括软件的技术架构方面的要求 和安全性、易用性、性能等方面的要求。在考勤系统案例中主要关注安全性、易用性、性能、接口等方面。

软件工程 - 第5章

1. 简答题：

   非形式化方法（自然语言描述）书写的系统规格说明书存在哪些缺点？请列出至少3项。

   • 参考答案： 可能存在矛盾、二义性、含糊性、不完整性 及抽象层次混乱等问题。

2. 简答题：

   形式化方法在软件工程中的优点有哪些？请列出至少3项。

   • 参考答案： 数学能够简洁准确地描述结果，是理想的建模工具；数学可以平滑地过渡到不同的软件工程活动；数学提供了高层确认的手段。

3. 填空题：

   数据流图或实体-联系图建立模型属于____形式化技术。

   • 参考答案： 半

软件工程 - 第6章

1. 简答题：

   模块化的优点有哪些？请列出至少3项。

   • 参考答案： 软件结构清晰，易于设计、阅读和理解；使软件容易测试和调试，提高软件的可靠性；能够提高软件的可修改性；有助于软件开发工程的组织管理。

2. 填空题：

   ____思想是在认识事物、分析和解决问题的过程中，忽略那些与当前研究目标不相关的部分，将注意力集中于与当前目标相关的方面。

   • 参考答案： 抽象

3. 简答题：

   逐步求精的定义是什么？其依据是Miller法则，指的是什么？

   • 参考答案： 逐步求精是为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。依据是Miller法则，指的是一个人在任何时候都只能把注意力集中在（7±2）个知识块上。

4. 填空题：

   抽象和逐步求精是互补的过程，抽象是忽略底层细节，而求精是____底层细节。

   • 参考答案： 设计中揭示出

5. 简答题：

   信息隐藏原理要求如何设计和确定模块？应该隐藏的信息是什么？

   • 参考答案： 应该这样设计和确定模块：使得一个模块内包含的信息（过程和数据）对于不需要这些信息的模块来说，是不能访问的。应该隐藏的是模块的实现细节，即“细节隐藏”。

6. 填空题：

   ____是指把一些关系密切的软件元素物理地放得彼此靠近。

   • 参考答案： 局部化

7. 简答题：

   什么是模块独立？它包括哪两个方面？

   • 参考答案： 模块独立指每个模块完成一个相对独立的子功能，并且和其他模块之间的关系很简单。它包括内聚和耦合两个方面（资料中未直接定义内聚耦合，但提到了模块独立、接口复杂度、单入口单出口等，暗示了这些概念）。模块的高内聚和低耦合是模块独立的衡量标准。

8. 填空题：

   设计良好的软件通常具有____结构，两头小，中间大。

   • 参考答案： 瓮型

9. 简答题：

   在模块设计中，扇入和扇出分别指什么？通常认为模块的扇出数以多少为宜？

   • 参考答案： 扇入指调用该模块的上级模块的个数；扇出指该模块直接调用的下级模块的个数。模块的扇出数以3-4为好，最多不超过5-7。

10. 简答题：

    力争降低模块接口的复杂程度时，应使得信息传递简单并且和模块的功能一致。如果接口复杂或者不一致，可能是什么的征兆？

    • 参考答案： 紧耦合或者低内聚的征兆。

11. 填空题：

    设计单入口单出口的模块可以避免出现____耦合。

    • 参考答案： 内容

12. 简答题：

    模块功能应该可以预测，这意味着什么？带有内部存储器的模块功能为何不可预测？

    • 参考答案： 模块功能应该可以预测意味着只要输入的数据相同就产生同样的输出。带有内部存储器的模块功能不可预测，其功能受到内部存储器的状态影响出现不同情况，而内部寄存器上级模块不可见，此类设计不易理解和测试维护。

软件工程 - 第7章

1. 简答题：

   面向对象分析（OOA）和面向对象设计（OOD）在概念上有什么区别？

   • 参考答案： OOA是提取和整理用户需求，并建立问题域精确模型的过程。OOD是将OOA阶段得到的需求转变为符合成本和质量要求的、抽象的系统实现方案的过程。

2. 填空题：

   面向对象方法强调开发过程的____。

   • 参考答案： 连续性

3. 填空题：

   OOD阶段得到的设计模型包括功能模型、对象模型和____模型。

   • 参考答案： 动态

4. 简答题：

   架构设计是考虑“全部需求”后做出来的。在进行架构设计时，通常需要考虑哪些关键问题？请列出至少3项。

   • 参考答案： 什么人会使用这个系统；不同的人将会使用这个系统的什么功能；还有哪些不确定或不具体的需求点；哪些需求对技术提出了怎样的要求；系统的大致架构应该如何考虑。

5. 简答题：

   请简述软件设计的三种策略（思路）以及它们适用的场景。

   • 参考答案：
     • 自顶向下：先做界面，再做其他部分。适用于需求含糊时。
     • 自底向上：先设计数据库，再搭建上层建筑。适用于需求明确，或有成型产品做参考时。
     • 由中间到上下：先不考虑界面和数据库，先定义中间部分（如实体类及数据层接口），再向界面和数据库扩展。适用于程序需要支持多数据库时。

6. 填空题：

   C/S架构中客户端采用_，B/S架构中客户端采用_。

   • 参考答案： 客户端程序，浏览器 (Source 55 mentions Browser for B/S, and implies a dedicated client for C/S)

7. 简答题：

   为了克服C/S与B/S各自的缺点，发挥各自的优点，在实际应用中，通常会将二者结合起来形成混合模式。这种模式通常遵循什么原则？

   • 参考答案： 通常遵循“内外有别”的原则。例如企业内部用户通过局域网直接访问数据库服务器（C/S结构），企业外部用户通过Internet访问Web服务器/应用服务器（B/S结构）。

软件工程 - 第8章

1. 简答题：

   在设计交互式系统时，给出出错信息或警告信息应具有哪些属性？请列出至少3项。

   • 参考答案： 用用户可以理解的术语描述问题；提供有助于从错误中恢复的建设性意见；指出错误可能导致哪些负面后果，以便用户检查解决；伴随着听觉上或视觉上的提示；不能责怪用户。

2. 填空题：

   人机界面设计过程通常包括根据产品需求文档产生线形图（原型）、形成视觉风格稿、设计分工、以及____。

   • 参考答案： 界面切图移交前端工程师进行开发

3. 简答题：

   人机界面设计的一般交互指南中，保持一致性、提供有意义的反馈、允许取消绝大多数操作分别指什么？

   • 参考答案： 保持一致性指菜单选择、命令输入等风格一致。提供有意义的反馈指提供视觉听觉等反馈，保证用户和系统之间建立双向通信。允许取消绝大多数操作指在执行有较大破坏性的动作之前要求用户确认，允许取消绝大多数操作。

4. 简答题：

   人机界面设计的信息显示指南中，只显示与当前工作内容有关的信息、不要用数据淹没用户、使用一致的标记/标准缩写和可预知的颜色分别指什么？

   • 参考答案： 只显示与当前工作内容有关的信息指只展示与当前工作内容直接相关的信息。不要用数据淹没用户指应该用便于用户迅速吸取信息的方式来表示数据。使用一致的标记/标准缩写和可预知的颜色指在界面中使用统一的符号、缩写和颜色，便于用户理解和识别。

5. 简答题：

   请列出至少三种详细设计阶段常用的过程设计工具。

   • 参考答案： 流程图、NS图、PAD图、判断表、判定树、伪代码。

6. 简答题：

   McCabe方法是使用什么来定量度量程序的复杂程度？

   • 参考答案： 环形复杂度。

软件工程 - 第9章

1. 填空题：

   软件实现包括编码和____两个阶段。

   • 参考答案： 测试

2. 填空题：

   软件测试的正确定义是“为了发现程序中的____而执行程序的过程”。

   • 参考答案： 错误

3. 简答题：

   软件测试的目标是什么？是否可以通过测试证明程序是正确的？

   • 参考答案： 测试的目标是发现程序中的错误。测试决不能证明程序是正确的，即使经过最严格的测试，仍可能存在未被发现的错误。

4. 简答题：

   软件测试有哪些准则？请列出至少3项。

   • 参考答案： 所有测试都应该能追溯到用户需求；应该远在测试开始之前就制定出测试计划；把Pareto原理（二八定律）应用到软件测试中；从“小规模”测试开始，逐步进行“大规模”测试；穷举测试是不可能的；为了达到最佳测试效果，应该由独立的第三方从事测试工作。

5. 简答题：

   请简述黑盒测试和白盒测试的区别。

   • 参考答案： 黑盒测试（功能测试）把程序看作一个黑盒子，完全不考虑内部结构和处理过程，在程序接口进行测试，测功能。白盒测试（结构测试）把程序看成装在透明白盒子里，测试者完全知道程序的结构和处理算法，在程序内部进行测试，测逻辑。

6. 简答题：

   大型软件系统的测试过程通常包括哪几个步骤（层次）？这些步骤的目的是什么？

   • 参考答案：

     通常包括单元测试（模块测试）、集成测试、系统测试、验收测试（确认测试）和平行运行 等五个步骤。

     • 单元测试：保证每个模块作为一个单元能正确运行，发现编码和详细设计错误。
     • 集成测试：把单元测试过的模块组合测试子系统，着重测试模块接口。
     • 系统测试：把测试过的子系统组装成完整系统测试，验证需求功能和动态特性，发现设计和需求错误。
     • 验收测试：在用户参与下使用实际数据测试，验证系统满足用户需要，发现需求说明错误。
     • 平行运行：同时运行新旧系统比较结果。

7. 选择题：

   从测试阶段角度，正确的测试顺序是（）。

   • A. 单元测试、系统测试、集成测试、确认测试
   • B. 单元测试、集成测试、系统测试、确认测试
   • C. 确认测试、集成测试、系统测试、单元测试
   • D. 确认测试、系统测试、集成测试、单元测试
   • 参考答案： B

8. 填空题：

   回归测试的目的是测试____，确保修改没有引入新的错误或导致已有功能失效。

   • 参考答案： 在修改软件之后进行的测试 (Source 71 mentions regression test after modification)

9. 简答题：

   确认测试（验收测试）的目标是什么？进行确认测试的基础是什么？

   • 参考答案： 目标是验证软件的有效性，验证系统确实能够满足用户的需要。基础是软件需求规格说明书。

10. 简答题：

    Alpha测试和Beta测试分别是在什么环境下进行的？参与人员通常是谁？

    • 参考答案： Alpha测试是在一个受控的环境下，由用户在开发者的指导下进行测试。Beta测试是由最终用户在自己的场所进行，开发者通常不在场，也不能控制应用环境。

11. 简答题：

    黑盒测试技术中，等价划分和边界值分析的基本思想是什么？

    • 参考答案： 等价划分是将程序的输入域划分成若干等价类，从每个等价类中选取一个代表性数据作为测试用例。边界值分析是对输入或输出等价类的边界值进行测试。

12. 简答题：

    什么是调试？它和测试有什么区别？

    • 参考答案： 调试是在测试发现错误之后排除错误的过程。测试是为了发现错误，调试是为了排除错误。

13. 简答题：

    调试有哪些常用途径（方法）？请列出至少2种。

    • 参考答案： 蛮干法、回溯法、原因排错法（对分查找法、归纳法和演绎法）。

软件工程小测

请用2-3句话简要回答以下问题：

1. 什么是软件危机？
2. 软件工程的三要素是什么？
3. 瀑布模型的主要特点有哪些？
4. 可行性研究的主要任务是什么？
5. 数据流图（DFD）中的四种基本符号是什么？
6. 什么是数据字典（DD），它与数据流图有什么关系？
7. 需求分析阶段的主要产出是什么？
8. 什么是模块独立？它如何度量？
9. 白盒测试和黑盒测试的主要区别是什么？
10. 软件测试的根本目标是什么？

答案 Key

1. 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题，表现为成本和进度失控、软件质量差、难以维护等。
2. 软件工程的三要素是方法、工具和过程，它们都必须围绕质量开展。
3. 瀑布模型的主要特点包括阶段间具有顺序性和依赖性、推迟实现的观点和强调质量保证。
4. 可行性研究的主要任务是用最小的代价和最短的时间确定项目能否解决问题以及是否值得解决，即回答“做还是不做”的问题。
5. 数据流图的四种基本符号是外部实体、数据流、数据存储和加工（或称数据处理）。
6. 数据字典是关于数据的信息集合，对数据流图中包含的所有元素进行定义；它与数据流图共同构成系统的逻辑模型，数据流图描述结构，数据字典描述细节。
7. 需求分析阶段最主要的产出是软件需求规格说明书（SRS）。
8. 模块独立是指每个模块完成一个相对独立的子功能，并且和其他模块之间的关系很简单；它通常用内聚（模块内部联系紧密程度）和耦合（模块之间连接紧密程度）来度量。
9. 白盒测试考虑程序的内部结构和处理过程，用于测试程序逻辑；黑盒测试将程序看作黑盒子，不考虑内部结构，用于测试程序功能。
10. 软件测试的根本目标是为了发现程序中的错误而执行程序的过程，即发现程序中的错误。

软件工程论述题

1. 详细阐述软件危机产生的原因及其消除途径，并结合实际案例说明软件工程在解决软件危机中的作用。
2. 比较分析瀑布模型、增量模型和敏捷过程这三种软件过程模型的特点、优缺点及适用场景。
3. 深入探讨可行性研究的各个方面（技术、经济、操作、社会环境），说明在实际项目可行性分析中应如何进行权衡和决策。
4. 详细阐述需求分析的各个阶段（获取、整理、建模、评审验证）及其主要任务，并结合实际项目说明有效的需求获取和管理对项目成功的重要性。
5. 解释数据流图和数据字典的概念及作用，并通过一个简单的示例说明如何利用它们来构建系统的逻辑模型。
6. 详细阐述软件总体设计的基本原理（模块化、抽象、逐步求精、信息隐藏、模块独立），并说明如何在设计过程中应用这些原理来提高软件质量。
7. 分析内聚和耦合这两种度量模块独立性的指标，结合不同内聚和耦合类型，说明如何通过优化模块的内聚和耦合来构建高质量的软件结构。
8. 详细阐述单元测试、集成测试、系统测试和验收测试这四个主要的测试层次，说明它们在软件测试过程中的作用、侧重点及相互关系。
9. 比较分析白盒测试和黑盒测试常用的技术（如路径测试、等价分类、边界值分析等），并说明在实际测试工作中应如何结合使用这些技术来提高测试效率和覆盖率。
10. 论述软件调试的重要性，并详细介绍几种常用的调试途径（蛮干法、回溯法、原因排错法），说明它们各自的优缺点及适用范围。

关键术语词汇表

• 软件工程 (Software Engineering): 指导计算机软件开发和维护的工程学科，采用工程的概念、原理、技术和方法以经济地开发高质量软件并有效维护。
• 软件危机 (Software Crisis): 在计算机软件的开发和维护过程中所遇到的一系列严重问题。
• 软件过程 (Software Process): 为了获得高质量软件所需要完成的一系列任务的框架，规定了完成各项任务的工作步骤。
• 瀑布模型 (Waterfall Model): 一种线性的顺序软件过程模型，严格按照分析、设计、编码、测试、维护等阶段依次进行。
• 原型模型 (Prototyping Model): 通过快速开发原型来获取用户需求并降低开发风险的软件过程模型。
• 增量模型 (Incremental Model): 将软件产品作为一系列增量构件来开发，逐步交付可工作产品的软件过程模型。
• 螺旋模型 (Spiral Model): 结合了原型模型和瀑布模型的特点，强调风险分析的软件过程模型。
• 可行性研究 (Feasibility Study): 在软件生命周期早期进行的分析，确定项目能否解决问题以及是否值得解决。
• 技术可行性 (Technical Feasibility): 评估在给定限制内能否设计和实现系统的必须功能和性能。
• 经济可行性 (Economic Feasibility): 评估系统解决方案的性能价格比，以及开发项目是否值得投资。
• 用户操作可行性 (Operational Feasibility): 评估用户组织的结构、工作流程、管理模式及人员素质是否适合目标系统的运行。
• 数据流图 (Data Flow Diagram, DFD): 一种图形化的系统模型，描绘信息流和数据加工功能。
• 数据字典 (Data Dictionary, DD): 关于数据的信息集合，对数据流图中包含的所有元素进行定义。
• 成本/效益分析 (Cost/Benefit Analysis): 从经济角度分析新系统开发是否能盈利，帮助投资决策。
• 需求分析 (Requirement Analysis): 准确回答“系统必须做什么？”，确定系统必须具有的功能、性能等。
• 软件需求规格说明书 (Software Requirement Specification, SRS): 需求分析阶段的主要产出文档，完整、准确、具体地描述系统需求。
• 功能需求 (Functional Requirement): 系统应该提供的功能或服务。
• 非功能需求 (Non-functional Requirement): 系统必须具有的性能特性（如性能、可靠性、可用性等）。
• 用例图 (Use Case Diagram): 描述系统为使用系统的用户完成的一个单一用途或功能，以及系统用户（参与者）的角色。
• ER图 (Entity Relationship Diagram): 描绘现实世界中的实体、属性和联系的概念性数据模型工具。
• 数据规范化 (Data Normalization): 将数据的逻辑结构归结为满足一定条件的二维表，减少数据冗余。
• 总体设计 (Overall Design / High-level Design): 回答“概括地说，系统应该如何实现”，规划系统的宏观结构和组成。
• 模块化 (Modularity): 将复杂的软件系统分解为模块。
• 抽象 (Abstraction): 在认识事物、分析和解决问题的过程中，忽略与当前研究目标不相关的部分。
• 逐步求精 (Stepwise Refinement): 为了集中精力解决主要问题而尽量推迟对问题细节的考虑。
• 信息隐藏 (Information Hiding): 使得一个模块内包含的信息对于不需要这些信息的模块来说是不能访问的。
• 模块独立 (Module Independence): 每个模块完成一个相对独立的子功能，并且和其他模块之间的关系很简单。
• 内聚 (Cohesion): 模块内部各个部分之间联系的紧密程度。
• 耦合 (Coupling): 模块之间相互连接的紧密程度。
• 结构图 (Structure Chart, SC): 描绘软件的层次结构，模块之间的调用关系以及传递的数据和控制信息。
• 伪码 (Pseudo-code): 用介于自然语言和程序设计语言之间的形式描述程序逻辑。
• 盒图 / N-S图 (Nassi-Shneiderman Diagram, N-S Diagram): 一种不允许违背结构程序设计精神的图形工具，用嵌套的矩形框表示程序结构。
• 判定表 (Decision Table): 清晰地表示复杂的条件组合与应做的动作之间的对应关系。
• 判定树 (Decision Tree): 用树形结构表示复杂的条件组合与应做的动作之间的对应关系。
• 实现 (Implementation): 包括编码和测试两个阶段。
• 编码 (Coding): 将软件设计结果翻译成程序设计语言书写的程序。
• 软件测试 (Software Testing): 为了发现程序中的错误而执行程序的过程。
• 静态测试 (Static Testing): 在程序不执行的情况下进行的测试，如代码评审。
• 动态测试 (Dynamic Testing): 在程序执行的情况下进行的测试。
• 黑盒测试 (Black-box Testing): 又称功能测试，不考虑程序内部结构，测试程序功能。
• 白盒测试 (White-box Testing): 又称结构测试，考虑程序内部结构和处理过程，测试程序逻辑。
• 单元测试 (Unit Testing): 对程序中独立可验证的最小单位进行的测试。
• 集成测试 (Integration Testing): 测试连接起来的模块，发现与接口相关的错误。
• 系统测试 (System Testing): 将经过集成的软件系统作为整体进行的全面测试。
• 确认测试 (Validation Testing): 又称验收测试，验证系统是否满足用户需求，通常由用户进行。
• 调试 (Debugging): 在测试发现错误之后排除错误的过程。
• 软件可靠性 (Software Reliability): 软件在规定条件下、规定时间内无故障运行的概率。

学习辅导习题

第2章 结构化分析

本章涉及了需求分析、数据流图（DFD）、实体联系图（ERD）、形式化方法和成本估算等内容，与您的PPT中关于DFD、ERD、需求验证和成本估算等内容相关。

1. ** 估算软件规模、工作量和选择估算模型？说明你选择的理由。**
   • 题目： 假设要求开发一个软件，满足社会对软件日益增长的需求，开发成本是以一次性开发过程所花费的代价来计算的。估算软件规模、工作量和选择估算模型？说明你选择的理由。
   • 答案： 软件开发成本主要是指软件开发过程中所花费的工作量及相应的代价，其中主要是人的劳动 的消耗，因此，软件产品开发成本的计算方法不同于其它物理产品的成本的计算。软件产品不存在重复制造过程，它的开发成本 是以一次性开发过程所花费的代价来计算的。因此软件成本估算，应以软件计划、需求分析、 设计、编码到测试的软件开发全过程所花费的代价为依据。常用的软件成本估算技术有：代码行技术、任务分解技术、自动估计成本技术和经验统计估计模型。根据题目给出的条件，可以采用经验统计估计模型进行估算，因为题目中没有提供已完成的类似项目作为参照（无法用基于 已完成的类似项目进行估算），任务分解技术和自动估计成本技术没有足够的 信息进行估算，代码行技术需要知道程序代码行数，而这需要更详细的设计结果。
2. ** 说明形式化说明技术的适用范围。**
   • 题目： 说明形式化说明技术的适用范围。
   • 答案： 形式化说明技术，又称规格说明技术，它是用来精确地定义软件系统行为的技术. 形式化方法特别适合于安全攸关的和对可信性要求很高的软件系统的开发，例如，航空航天、核电站、医疗设备、金融系统等领域的软件系统.
3. ** Lookup 操作的 Z 规格说明** (这是一个包含 Z 语言示例的问题，与PPT中提及的形式化方法相关)
   • 题目： Lookup 操作的 Z 规格说明如图 2.9 所示。 [ ] 为什么要在此规格说明中提出，查表结果保持 t 不变呢？
   • 答案： 查表操作并不会改变原有的数据表 T，也就是说，查表操作是一种只读操作. 因此，在 Z 规格说明中，我们要求查表操作的执行结果保持数据表 T 不变. 具体来说，在 Z 规格说明中，我们用 t' 表示查表操作后的二维数组，用 t? 表示查表操作前的二维数组. 为了表示查表操作不改变数据表，我们可以在 Z 规格说明中加入 t' = t? 的约束条件. (注：此答案解释的是数据表 T/t 未变，与Z规格说明中的符号标记可能略有出入，但核心是说明了数据结构未被修改的性质).

第3章 结构化设计

本章涵盖了结构化设计原则、图形工具（层次图、结构图）、面向数据流的设计方法（变换分析、事务分析）、人机界面设计和过程设计工具（流程图等），与您的PPT中关于结构化设计、DFD到SC映射、人机界面设计和过程设计工具等内容紧密对应。

1. ** 叙述描绘软件结构的图形工具及其用途。**
   • 题目： 请叙述描绘软件结构的图形工具及其用途。
   • 答案： 描绘软件结构的图形工具主要有层次图和结构图. 层次图用来描绘软件的层次结构. 结构图用来描绘软件的模块结构和模块之间的相互调用关系，也包括模块之间的控制流和数据流.
2. ** 叙述面向数据流的设计方法。**
   • 题目： 请叙述面向数据流的设计方法。
   • 答案： 面向数据流的设计方法是一种系统化的、以变换功能为基础的设计方法. 其基本思想是把数据流图映射成软件模块结构. 它包括变换分析和事务分析两种方法.
3. ** 比较变换分析与事务分析的异同点。**
   • 题目： 试比较变换分析与事务分析的异同点。
   • 答案： 变换分析与事务分析的共同点是都把数据流图映射成软件模块结构. 不同点是变换分析适用于变换型数据流图，事务分析适用于事务型数据流图. 变换分析把变换型数据流图映射成具有传入部分、变换中心和传出部分的模块结构；事务分析把事务型数据流图映射成具有事务中心和若干事务处理路径的模块结构.
4. ** 叙述应该考虑的人机界面设计问题。**
   • 题目： 叙述应该考虑的人机界面设计问题。
   • 答案： 应该考虑的人机界面设计问题很多，主要包括信息显示、数据输入和系统整体控制等方面. 例如，如何减少用户的输入动作，如何保持信息显示和数据输入之间的一致性，是否允许用户自定义输入，交互是否灵活并可调整，是否让用户控制交互流，是否提供帮助信息，是否消除冗余输入等. (注：此答案主要侧重数据输入指南，完整的界面设计指南还包括信息显示和一般交互等方面).
5. ** 叙述过程设计的工具及其用途。**
   • 题目： 叙述过程设计的工具及其用途。
   • 答案： 过程设计的工具包括程序流程图、盒图、PAD 图、判定表、判定树和过程设计语言等. 程序流程图用来描述程序的控制流; 盒图用来描述程序的模块结构和控制流; PAD 图用来描述程序的结构化程序; 判定表和判定树用来描述复杂的条件逻辑; 过程设计语言用来描述程序的处理过程.

第4章 结构化实现

本章重点介绍了软件测试的各个阶段（单元测试、集成测试、系统测试、验收测试）及其目标，与您的PPT中关于软件测试的内容直接对应。

1. ** 叙述单元测试的重点。**
   • 题目： 叙述单元测试的重点。
   • 答案： 单元测试集中检测软件设计的最小单元——模 块. 单元测试的重点在于检查模块接口、局部数据结构、重要的执行路径、出错处理以及边界条件，保证每个模块作为一个单元能够正确运行. 在这个测试步骤中所发现的往往是编码和详细设计 的错误.
2. ** 叙述集成测试的策略。**
   • 题目： 叙述集成测试的策略。
   • 答案： 集成测试的策略主要有大爆炸集成、自顶向下集成、自底向上集成和混合集成.
3. ** 叙述系统测试的重点。**
   • 题目： 叙述系统测试的重点。
   • 答案： 系统测试 / 系统集成测试是：把经过测试的子 系统装配成一个完整的系统来测试. 系统测试的重点在于对整个系统进行全面的测试，包括功能测试、性能测试、可靠性测试、安全性测试、安装与配置测试、兼容性测试以及文档测试等. 此测试中发现的往往是软件设计中的错误，也 可能发现需求说明中的错误.
4. ** 叙述验收测试的重点。**
   • 题目： 叙述验收测试的重点。
   • 答案： 验收测试是在用户积极参与下进行的，而且可能主要使 用实际数据进行测试. 验收测试的重点在于验证系统确实能够满足用户的需要，在这个测试步骤中发现的往往是系统需求说明书中的错误. 验收测试也称为确认测试.
5. ** 为什么软件测试是软件开发的重要阶段？**
   • 题目： 为什么软件测试是软件开发的重要阶段？
   • 答案： 软件测试是软件开发的重要阶段，因为：① 测试可以发现软件中的错误，是提高软件质量的重要手段. ② 测试可以验证软件是否满足用户需求. ③ 测试可以帮助开发人员改进设计和编码. ④ 测试可以为软件的发布提供依据.

第6章 面向对象方法

本章介绍了面向对象的基本概念（对象、类、属性、服务、消息）、面向对象分析、面向对象设计以及不同模型之间的关系，与您的PPT中关于类图、用例图、顺序图、状态图以及OO模型等内容相关。

1. ** 用面向对象开发软件...与结构化...生命周期有何不同...？这种差异带来了什么后果？**
   • 题目： 用面向对象方法开发软件，与结构化方法开发软件相比，软件的生命周期有何不同？这种差异带来了什么后果？
   • 答案： 面向对象方法开发软件与结构化方法开发软件在软件生命周期模型上没有本质区别，都可以采用瀑布模型、螺旋模型、迭代模型等. 但面向对象方法强调在整个生命周期中反复迭代和演化，可以在早期引入对象概念，使得开发过程更加平滑. 这种差异带来了以下后果：面向对象方法更容易适应需求变化；面向对象方法更容易实现软件重用；面向对象方法更容易管理复杂性.
2. ** 什么是对象？它与传统的...有何异同？**
   • 题目： 什么是对象？它与传统的程序数据结构有何异同？
   • 答案： 对象是对客观事物的抽象，是现实世界中的实体在计算机系统中的表示. 对象是面向对象方法的核心概念，具有状态、行为和标识. 对象与传统的程序数据结构不同点在于，对象封装了数据（属性）和对数据的操作（服务/方法），而传统的数据结构只包含数据. 对象与传统的数据结构也有共同点，它们都是数据的集合.
3. ** 试用面向对象方法分析图 6.2 所示的圆和椭圆类，并建立它们的模型。** (图 6.2 显示了圆和椭圆类的属性和操作)
   • 题目： 试用面向对象方法分析图 6.2 所示的圆和椭圆类，并建立它们的模型。
   • 答案： 圆和椭圆是现实世界中的事物，可以作为对象. 圆有圆心坐标和半径两个属性，有画圆、显示、隐藏等服务. 椭圆有中心坐标、长半轴和短半轴等属性，有画椭圆、显示、隐藏等服务. 圆和椭圆都是图形，可以抽象出图形类. 圆是椭圆的一种特殊情况，圆和椭圆之间存在继承关系. 圆和椭圆都可以通过消息传递进行交互. (注：此答案描述了对象、属性、服务以及类之间的继承关系，是面向对象模型的重要组成部分).

第7章 面向对象分析

本章详细介绍了面向对象分析的过程，包括需求描述、建立对象模型、动态模型和功能模型，并提到了用例图和状态图，与您的PPT中提及的用例图、状态图以及OO分析建模相关。

1. ** 用例图是从用户的视角来描述系统的功能...**
   • 题目： 用例图是从用户的视角来描述系统的功能，因此，必须包含用户关心的所有关键功能。
   • 答案： 正确. 用例图是从用户的视角来描述系统的功能，它描述了系统为用户提供的服务. 用例图必须包含用户关心的所有关键功能，以便用户能够理解和确认系统的需求.
2. ** 状态图应该描述给所有可能的状态转换...**
   • 题目： 状态图应该描述给所有可能的状态转换，图中每条弧都需要有一个引起状态转换的事件，从开始状态 (初态) 到每个结束状态 (中间状态) 以及从每个结点到最终结点 (终态) 都必须有一条路径。
   • 答案： 正确. 状态图描述了对象的动态行为，它表示对象所有可能的状态以及在事件发生时对象从一个状态到另一个状态的转换. 状态图中的每条弧都表示一个状态转换，并且必须有一个引起转换的事件. 状态图必须包括起始状态和终止状态，并且从起始状态到终止状态必须有一条路径.
3. ** 从非正式分析方法中可以找出下列名词作为对象的候选者：病人、医生、护士、药品、病房、病历、预约、收费、报告、科室、医院等。**
   • 题目： 从非正式分析方法中可以找出下列名词作为对象的候选者：病人、医生、护士、药品、病房、病历、预约、收费、报告、科室、医院等。
   • 答案： 从非正式分析方法中可以找出下列名词作为对象的候选者是正确的方法，但并非所有名词都是有效的对象. 需要根据对象的定义和选择对象的准则，对这些候选对象进行筛选和提炼. 例如，病人、医生、护士、病历、预约等可能是有效的对象，而药品、病房、收费、报告等可能是对象的属性或服务.
4. ** 请给出牙科诊所管理系统的功能模型。**
   • 题目： 请给出牙科诊所管理系统的功能模型。
   • 答案： 牙科诊所管理系统的功能模型主要包括以下活动（过程）：病人挂号、医生诊病、护士配药、病人缴费、病历管理、药品管理、预约管理、排班管理、报表生成等. (注：功能模型描述的是系统提供的功能或服务).
5. ** 画出牙科诊所管理系统的状态图。**
   • 题目： 画出牙科诊所管理系统的状态图。
   • 答案： 牙科诊所管理系统的状态图如图 7.5 所示. 该状态图描述了病人预约的状态变化. 主要状态包括：开始、输入病人信息、处理预约信息、返回确认信息、进行预约、结束. (图 7.5 示意图: 开始 -> 输入有效名字及可能的预约 -> 处理日常事务 -> 返回确认信息 -> 进行预约 -> 结束 输入无效名字 -> 非法名字，按姓名或日期查询，打印工作安排，取消预约 -> 处理日常事务)

第8章 面向对象设计

本章讨论了面向对象设计的原则、启发式规则、软件重用以及设计优化等，与您的PPT中可能提及的OO设计原则和方法相关。

1. ** 描述人机界面设计的五个步骤。**
   • 题目： 描述人机界面设计的五个步骤。
   • 答案： 用户界面设计是一个迭代的过程. 也就是说，通常先创建设计模型，再用原型实现这个设计模型. 然后由用户试用和评估，根据用户的意见进行修改，直至满意为止. (注：虽然题目问的是五个步骤，但学习辅导中描述的是一个迭代的设计过程).
2. ** 在面向对象分析阶段建立的对象模型如何映射成面向对象设计？**
   • 题目： 在面向对象分析阶段建立的对象模型如何映射成面向对象设计？
   • 答案： 在面向对象分析阶段建立的对象模型可以直接映射成面向对象设计中的类图 . 对象模型中的对象可以映射成类，对象的属性映射成类的属性，对象提供的服务映射成类的方法 . 对象之间的关系 (如关联、继承、聚集等) 也直接映射成类之间的关系.
3. ** 如何识别对象之间的关系？**
   • 题目： 如何识别对象之间的关系？
   • 答案： 识别对象之间的关系主要通过分析需求说明书中的名词短语和动词短语，以及对象之间的交互和协作来实现. 常见的对象之间的关系有关联、继承、聚集和依赖等.
4. ** 如何进行对象设计优化？**
   • 题目： 如何进行对象设计优化？
   • 答案： 对象设计优化主要包括：减少对象之间的耦合，提高对象之间的内聚，优化对象之间的消息传递，优化对象的数据结构和算法等. 优化的目标是提高软件的性能、可维护性和可重用性.