Software Engineering

软件工程导论（第六版）学习笔记

第一章 软件工程学概述

1.1 软件危机

1.1.1 软件危机的介绍

• 软件危机的概念
  • 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
• 软件危机的典型表现
  • ① 对软件开发成本和进度的估计不准确。
  • ② 用户对 “已完成的” 软件系统不满意的现象经常发生。
  • ③ 软件产品的质量往往靠不住。
  • ④ 软件常常是不可维护的。
  • ⑤ 软件通常没有适当的文档资料。
  • ⑥ 软件成本在计算机系统总成本中所占的比例逐年上升。
  • ⑦ 软件开发跟不上计算机应用迅速普及深入的趋势。

1.1.2 产生软件危机的原因

• 客观原因
  • ① 软件是计算机系统中的逻辑部件，缺乏 “可见性”，因此管理和控制软件开发过程相当困难。
  • ② 软件维护通常意味着改正或修改原来的设计，因此软件较难维护。
  • ③ 软件规模庞大，而程序复杂性将随着程序规模的增加而呈指数上升。
• 主观原因
  • ① 存在与软件开发和维护有关的许多错误认识和做法。
  • ② 对用户要求没有完整准确的认识就匆忙着手编写程序。
  • ③ 开发人员只重视程序而忽视软件配置的其余成分（文档和数据等）。
  • ④ 软件开发人员轻视维护。

1.1.3 消除软件危机的途径

• 软件
  • 软件是程序、数据及相关文档的完整集合
  • 软件＝程序＋数据＋文档。
• 消除软件危机的途径
  • 应该对计算机软件有一个正确的认识，软件 = 程序 + 数据 + 相关文档；
  • 应该充分认识到软件开发是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。
  • 应该推广使用在实践中总结出来的开发软件的成功的技术和方法， 并且研究探索更好更有效的技术和方法。
  • 应该开发和使用更好的软件工具。

1.2 软件工程

1.2.1 软件工程的介绍

• 软件工程的概念
  • 指导计算机软件开发和维护的一门工程学科。
  • 采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来， 以经济地开发出高质量的软件并有效地维护它，这就是软件工程。
• 软件工程的本质特征
  • ① 软件工程关注于大型程序的构造；
  • ② 软件工程的中心课题是控制复杂性；
  • ③ 软件经常变化；
  • ④ 开发软件的效率非常重要；
  • ⑤ 和谐地合作是开发软件的关键；
  • ⑥ 软件必须有效地支持它的用户；
  • ⑦ 软件工程领域由具有一种文化背景的人替具有另一种文化背景的人创造产品。

1.2.2 软件工程的基本原理

• 七条基本原理
  • ① 用分阶段的生命周期计划严格管理；
  • ② 坚持进行阶段评审；
  • ③ 实行严格的产品控制；
  • ④ 采用现代程序设计技术；
  • ⑤ 结果应能清楚地审查；
  • ⑥ 开发小组的人员应该少而精；
  • ⑦ 承认不断改进软件工程实践的必要性。
• 七条基本原理的意义
  • 这七条原理是确保软件产品质量和开发效率的原理的最小集合，它们是互相独立的，而且是缺一不可的最小集合，然而这七条原理又是相当完备的。

1.2.3 软件工程方法学

• 软件工程包括技术和管理两方面的内容。
• 软件工程是技术与管理紧密结合所形成的工程学科。
• 软件工程方法学概念
  • 通常把软件生命周期全过程中使用的一整套技术方法的集合称为方法学，也称为范型。
  • 目前使用得最广泛的软件工程方法学，分别是传统方法学和面向对象方法学。
• 软件工程方法学的三要素
  • 软件工程方法学包括 3 个要素：方法、工具和过程。
• 传统方法学（生命周期方法学或结构化范型）
  • ① 定义
    • 采用结构化技术（结构化分析、结构化设计和结构化实现）来完成软件开发的各项任务，并使用适当的软件工具或软件工程环境来支持结构化技术的运用。
  • ② 优点
    • a. 把软件生命周期划分成若干相对独立、简单的阶段，便于不同人员分工协作，降低开发的困难程度；
    • b. 开发过程中采用科学的管理技术和良好的技术方法，且在每个阶段结束之前都进行严格的审查，保证了软件的质量，提高了软件的可维护性；
    • c. 大大提高了软件开发的成功率和生产率。
  • ③ 缺点
    • a. 不适用于软件规模庞大、或者对软件的需求是模糊的或会随时间变化而变化的情况。
    • b. 结构化范型技术把数据和操作人为地分离成两个独立的部分，增加了软件开发与维护的难度。
• 面向对象方法学
  • ① 定义
    • 面向对象方法是一种以数据为主线，把数据和对数据的操作紧密地结合起来的方法。
  • ② 要点
    • a. 把对象作为融合了数据及在数据上的操作行为的统一的软件构件；
    • b. 把所有对象都划分成类；
    • c. 继承性；
    • d. 对象彼此间仅能通过发送消息互相联系。
  • ③ 与传统方法学的对比
    • a. 传统方法学强调自顶向下、逐层分解、顺序开发。
    • b. 面向对象方法学强调主动地多次反复迭代地开发，保证了在各项开发活动之间的平滑过渡。
  • ④ 优点
    • a. 降低了软件产品的复杂性；
    • b. 提高了软件的可理解性；
    • c. 简化了软件的开发和维护工作；
    • d. 提高了软件的可重用性。
  • 【注意】常考面向对象方法学的基本特征：类、继承、封装、多态。结合第 9 章掌握其含义和意义。

1.3 软件生命周期组成

• 软件生命周期由软件定义、软件开发、运行维护（软件维护）组成。
• 软件定义
  • 软件定义时期通常进一步划分成 3 个阶段，即问题定义、可行性研究和需求分析。
  • 可行性研究的结果是客户作出是否继续进行这项工程的决定的重要依据
  • 需求分析阶段的重要任务，用正式文档准确记录对目标系统的需求，这份文档为规格说明书
• 软件开发
  • 通常由下述 4 个阶段组成：总体设计，详细设计（模块设计），编码和单元测试，综合测试。
  • 其中前两个阶段又称为系统设计，后两个阶段又称为系统实现。
  • 详细设计是详细设计每个模块，确定实现模块功能所需的算法和数据结构
  • 【注意】考题中常设置选项：在详细设计阶段编写代码。这是错误的， 在编码和单元测试阶段才编写代码。
  • 综合测试阶段中最基本的测试，集成测试和验收测试
• 运行和维护（软件维护）
  • 维护时期主要任务使软件持久地满足用户的需要。
  • 维护活动的分类
    • ① 改正性维护；
    • ② 适应性维护；
    • ③ 完善性维护；
    • ④ 预防性维护。

1.4 软件过程概念

• 软件过程的定义
  • 软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
• 软件过程的表示
  • 使用生命周期模型简洁地描述软件过程。
• 软件生命周期模型
  • 软件生命周期模型是软件开发的全部过程、活动和任务的结构框 架。软件生命周期模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为项目开发的基础。
  • 通常使用生命周期模型简洁地描述软件过程。
  • 软件生命周期模型规定了把生命周期划分为哪些阶段以及各个阶段的执行顺序。
• 【注意】着重掌握瀑布模型、快速原型模型、螺旋模型、增量模型、喷泉模型。

1.4.1 瀑布模型

• ① 开发流程
  • 实际的瀑布模型是带 “反馈环” 的，如图所示（图中实线箭头表示开发过程，虚线箭头表示维护过程）。
    • 
  • 【注意】传统的瀑布模型没有图中的反馈环。
    • 
• ② 特点
  • 第一，阶段间具有顺序性和依赖性；
  • 第二，推迟实现的观点；
  • 第三，质量保证的观点。
• ③ 瀑布模型的优缺点
  • a. 优点
    • 第一，可强迫开发人员采用规范的方法；
    • 第二，严格地规定了每个阶段必须提交的文档；
    • 第三，要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证；
    • 第四，对文档的约束，使软件维护变得容易一些，且能降低软件预算。
  • b. 缺点
    • 第一：瀑布模型是由文档驱动的。
    • 第二：缺乏对于需求变更和项目变化的适应性。
    • 第三：用户只有在生命周期的后期才能看到结果；
• ④ 适用范围
  • 适用于用户需求明确、完整、无重大变化的软件项目开发。

1.4.2 快速原型模型

• ① 开发流程
  • 如图所示（图中实线箭头表示开发过程，虚线箭头表示维护过程）。
  • 快速原型模型是不带反馈环的。
  • 
  • 【注意】快速原型模型弥补了瀑布模型不适用于需求动态变更的缺点， 其本质是 “快速”。
• ② 优点
  • a. 克服了瀑布模型的缺点，对于需求变更具有更好的适应性；
  • b. 开发费用低、开发周期短且对用户更友好。
• ③ 缺点
  • a. 客户与开发者对原型理解不同；
  • b. 本质是快速，没有考虑软件的总体质量和可维护性，最终产品质量较差；
  • c. 不利于开发人员的创新。
• ④ 适用范围
  • a．对所开发的领域比较熟悉而且有快速的原型开发工具；
  • b．项目招投标时，可以以原型模型作为软件的开发模型；
  • c．进行产品移植或升级时，或对已有产品原型进行客户化工作时。

1.4.3 增量模型

• ① 开发步骤
  • 增量模型也称为渐增模型，如图所示。
  • 
• ② 原理
  • 把软件产品作为多个增量构件来设计、编码、集成、测试，开发人员一个构件接一个构件地向用户提交产品。
• ③ 优点
  • a. 能在较短时间内向用户提交可完成部分工作的产品。
  • b. 逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品。
• ④ 技术难点
  • a. 要求软件体系结构必须是开放的。
  • b. 增量模型本身是自相矛盾的。
  • c. 增量模型的灵活性很容易退化为边做边改模型，从而使软件过程的控制失去整体性。
• ⑤ 风险更大的增量模型
  • 
  • 【注意】每个增量构件的开发采用瀑布模型。
• ⑥ 适用范围
  • a. 进行已有产品升级或新版本开发；
  • b. 对完成期限严格要求的产品；
  • c. 对所开发的领域比较熟悉而且已有原型系统

1.4.4 螺旋模型

• ① 基本思想
  • 可以把它看作在每个阶段之前都增加了风险分析过程的快速原型模型， 如图所示。
  • 
• ② 原理
  • 完整的螺旋模型如图所示。
  • 
• ③ 应用
  • 螺旋模型主要适用于内部开发的大规模软件项目。
• ④ 优点
  • a. 有利于已有软件的重用，有助于把软件质量作为软件开发的一个重要目标；
  • b. 减少了过多测试（浪费资金）或测试不足（产品故障多）所带来的风险；
  • c. 在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别。
• ⑤ 缺点
  • 螺旋模型是风险驱动的。要求软件开发人员具有丰富的风险评估经验和这方面的专门知识。
  • 过多的迭代次数会增加开发成本，延迟提交时间。
• ⑥ 适用范围
  • 适用于内部开发的大规模软件项目。

1.4.5 喷泉模型

• ① 开发流程
  • 图所示的喷泉模型，是典型的面向对象的软件过程模型之一。
  • 
• ② 特点
  • a. 喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。
  • b. 体现了面向对象软件开发过程迭代和无缝的特性。

1.4.6 Rational 统一过程（RUP）

• ① RUP 软件开发生命周期
  • RUP 软件开发生命周期是一个二维的面向对象的生命周期模型，如图所示。图中纵轴代表核心工作流，横轴代表时间。
  • 
• ② 核心工作流
  • 如上图纵轴所示，由上至下有九个核心工作流，前六个为核心过程工作流程，后三个为核心支持工作流程。
• ③ 工作阶段
  • a. 初始阶段。
  • b．精化阶段。
  • c．构建阶段。
  • d．移交阶段。
• ④ 特点
  • a. 采用迭代和渐增的方式开发软件。
  • b. 具有多功能性和广泛适用性。

1.4.7 敏捷过程

• 敏捷过程能够较好地适应商业竞争环境下对小型项目提出的有限资源和有限开发时间的约束。敏捷过程中最重要的是极限编程。

1.4.8 极限编程

• ① 极限编程的整体开发过程
  • 图描述了极限编程的整体开发过程。
  • 
• ② 极限编程的迭代过程
  • 图描述了极限编程的迭代开发过程。
  • 
• ③ 特点
  • a. 以极限编程为代表的敏捷过程，具有对变化和不确定性的更快速、更敏捷的反应特性；
  • b. 在快速的同时仍然能够保持可持续的开发速度。

1.4.9 微软过程

• ① 微软软件生命周期

  • 微软过程把软件生命周期划分成五个阶段，图描绘了生命周期的阶段及每个阶段的主要里程碑。
  • 

• ② 微软过程模型

  • a. 定义

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

  • b. 特点

    • 第一，适用于商业环境下具有有限资源和有限开发时间约束的项目；
    • 第二，微软过程也有某些不足之处，例如，对方法、工具和产品等方面的论述不如 RUP 和敏捷过程全面，人们对它的某些准则本身也有不同意见。

第二章 可行性分析

2.1 可行性研究的任务

• 可行性研究的目的
  • 用最小的代价在尽可能短的时间内确定问题是否能够解决。
• 可行性研究的 3 个方面
  • （1）技术可行性；
  • （2）经济可行性；
  • （3）操作可行性。
• 可行性研究的任务
  • （1）对以后的行动方针提出建议。（可行性研究最根本的任务）
  • （2）分析几种主要的候选解法的利弊，研究其可行性。

2.2 可行性研究过程

• 典型的可行性研究过程为：
  1. 复查系统规模和目标；
  2. 研究目前正在使用的系统；
  3. 导出新系统的高层逻辑模型；
  4. 进一步定义问题；
  5. 导出并评价供选择的解法；
  6. 推荐行动方针；
  7. 草拟开发计划；
  8. 书写文档提交审查。

2.3 系统流程图

• 定义

  • 系统流程图是概括地描绘物理系统的传统工具。系统流程图表达的是数据在系统各部件之间流动的情况，而不是对数据进行加工处理的控制过程。因此尽管系统流程图的符号形式相同，但是它却是物理数据流程图而不是程序流程图。

• 基本思想

  • 用图形符号以黑盒子形式描绘组成系统的每个部件（程序、文档、数据库、人工过程等）。
  • 【注意】系统流程图表达的是数据在系统各部件之间流动的情况，而不是对数据进行加工处理的控制过程。

• 符号

  • （1）以概括的方式抽象地描绘实际系统时，使用图 2-1 中列出的基本符号就足够了。

    • 
    • 【注意】这 5 种基本符号是常考点。

  • （2）需要更具体地描绘一个物理系统时，还需要使用图 2-2 中列出的系统符号。

    • 

    • 【注意】系统流程图的习惯画法是使信息在图中从顶向下或从左向右流动。

• 

2.4 数据流图概念

• （1）定义

  • 数据流图（DFD）是一种图形化技术。它描绘信息流和数据从输入移动到输出的过程中所经受的变换。

• （2）特点

  • ① 数据流图中没有具体的物理部件，只是描绘数据在软件中流动和被处理的逻辑过程。
  • ② 数据流图是系统逻辑功能的图形表示，是分析员与用户之间极好的通信工具。
  • ③ 设计时只需考虑系统必须完成的基本逻辑功能，不考虑怎样具体地实现这些功能。

• 符号

  • 如图（a）所示，数据流图有 4 种基本符号；图（b）给出了附加符号的含义。其中星号（*）表示数据流之间是 “与” 关系；加号（＋）表示 “或” 关系；⊕ 号表示只能从中选一个（互斥的关系）。
  • 
  • 数据流图有 4 种成分，源点或终点、处理、数据存储、数据流
  • 【注意】数据流中用箭头表示数据流，第 5 章的程序流程图中用箭头表示的控制流。

• 数据存储和数据流都是数据，数据存储是处于静止状态的数据，数据流是处理运动中的数据

• 例子

  • 

  • 

  • 

  • 

• 数据流图的基本目的，利用数据流图作为交流信息的工具

• 数据流图也可用于作为分析和设计的工具

2.5 数据字典

• 概念
  • （1）定义
    • 数据字典是关于数据的信息的集合，是对数据流图中包含的所有元素的定义的集合。
  • （2）数据字典的作用
    • 在软件分析和设计的过程中给人提供关于数据的描述信息
  • （3）意义
    • 数据流图和数据字典共同构成系统的逻辑模型。
• 数据字典的组成元素
  • ① 数据流；
  • ② 数据流分量，即数据元素；
  • ③ 数据存储；
  • ④ 处理。
• 定义数据的方法
  • 由数据元素组成的数据的方式 3 种基本类型：
    • 顺序（3 种基本类型）
    • 选择（3 种基本类型）
    • 重复（3 种基本类型）
    • 可选
  • 描述由数据元素组成数据的关系
    • ① = 等价于（定义为）
    • ② + 和（连接两个分量）
    • ③ [] 或（从方括号中的分量选择一个），通常用 “|” 号隔开供选择的分量
    • ④ {} 重复（重复花括号中的分量），字母数字串 = 0{字母或数字}7，允许字母或数字的长度为 0-7
    • ⑤ ( ) 选择（括号中的分量可有可无）
• 数据字典的用途
  • （1）作为分析阶段的工具（最重要）。
  • （2）数据字典中包含的每个数据元素的控制信息是很有价值的。
  • （3）数据字典是开发数据库的第一步，而且是很有价值的一步。
• 数据字典的实现
  • （1）开发大型软件系统时建议使用数据字典处理程序。
  • （2）在开发小型软件系统时建议采用卡片形式书写数据字典，如图
    • 

2.6 成本 / 效益分析

• 目的

  • 帮助客户组织负责人从经济角度判断是否继续投资于这项工程。

• 成本估计的方法

  • （1）代码行技术；
    • 每行代码的平均成本乘以行数
    • 每行代码的平均成本取决于软件的复杂程度和工资水平
  • （2）任务分解技术；
    • 总成本 = 每个任务成本之和
    • 每个任务的成本 = 人力 (以人月为单位) X 每人每月平均工资
  • （3）自动估计成本技术。
    • 采用自动估计成本的软件工具

• 成本效益分析

  • 成本与收益比较要相同时间的进行比较，现在与现在比较。

  • 计算 P 元钱在 n 年后的价值： F = P ( 1 + i ) n F=P(1+i)^n F=P(1+i)n，其中年利率为 i。

  • n 年后能收入 F 元钱，计算这些钱的现在价值： P = F / ( 1 + i ) n P=F/(1+i)^n P=F/(1+i)n。

    • 

  • 投资回收期：使累计的经济效益等于最初投资所需的时间

    • 

  • 纯收入

    • 

  • 计算投资回收率： P = F 1 / ( 1 + j ) + F 2 / ( 1 + j ) 2 + … + F n / ( 1 + j ) n P=F1/(1+j)+F2/(1+j)^2+…+Fn/(1+j)^n P=F1/(1+j)+F2/(1+j)2+…+Fn/(1+j)n

    • 其中，P 是现在的投资额；Fi 是第 i 年年底的效益（i ＝ 1，2，…，n）；n 是系统的使用寿命；j 是投资回收率。

第三章 需求分析

• 需求分析是软件定义时期的最后一个阶段，需求分析的基本任务是准确的回答 “系统必须做什么” 这个问题
• 需求分析阶段系统分析员需要写出软件需求规格说明书
• 在需求分析阶段通常建立数据模型（实体 - 联系图（ E-R 图））、功能模型（数据流图）、行为模型（状态转换图是行为模型的基础），数据字典成为把 3 种分析模型粘合在一起的 “粘合剂”，是分析模型的核心。

3.1 需求分析的任务

• 需求分析的定义
  • 需求分析是发现、求精、建模、规格说明和复审的过程。
• 需求分析的必要性
  • 为了开发出真正满足用户需求的成功的软件产品，必须知道用户的需求。
• 需求分析的任务
  • （1）确定对系统的综合要求；
    • （1）功能需求
    • （2）性能需求
    • （3）可靠性和可用性需求
    • （4）出错处理需求
    • （5）接口需求
    • （6）约束
    • （7）逆向需求
    • （8）将来可能提出的要求
  • （2）分析系统的数据要求；
    • 数据结构表示数据元素之间的逻辑关系
    • 利用数据字典可以全面准确的定义数据（不够形象直观）
    • 在描绘系统中的数据结构，使用层次方框图或 Warnier 图等图形工具。（提高可理解性）
  • （3）导出系统的逻辑模型；
    • 通常使用数据流图、实体 - 联系图、状态转换图、数据字典、主要的处理算法描述逻辑模型
  • （4）修正系统开发计划。

3.2 与用户沟通获取需求的方法

• 访谈
  • 正式访谈，系统分析员提出事先准备好的具体问题
  • 非正式访谈，分析员提出用户可以自由回答的开放性问题
• 面向数据流自顶向下求精
  • 先建立一个初步的系统功能模型，然后按照基本思想，自顶向下，逐步对顶层数据流图进行细分
  • 结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法
• 简易的应用规格说明技术
  • 进行初步访谈；
  • 开发者和用户分别写出 “产品需求”；
  • 选定会议的时间和地点，选举协调人；
  • 邀请开发者和用户双方组织的代表出席会议；
  • 列出系统环境组成部分的对象、系统将产生的对象、系统为完成自己的功能将使用的对象，列出操作这些对象或与这些对象交互的服务，列出约束条件和性能标准；
  • 共同起草完整的软件需求规格说明书
• 快速建立软件原型
  • 首先通过初步需求，快速建立一个系统原型；然后运行给用户看，用户根据原型提出自己的修改意见，最后程序开发者根据用户的建议，对原型进行修改和完善。如此反复的迭代进行，知道最终建立一个满足用户需求的软件系统为止
  • 特性：快速、容易修改
  • 快速构建和修改原型的方法和工具
    • 第四代技术
    • 可重用的软件构件
    • 形式化规格说明和原型环境

3.3 分析建模与规格说明

• 分析建模
  • （1）模型
    • 模型由一组图形符号和组织这些符号的规则组成。
    • 为了理解事物而对事物作出的抽象
    • 对事物的一种无歧义的书面描述
  • （2）建模过程
    • 结构化分析实质上是一种创建模型的活动，应从不同的角度抽象目标系统的特性。
  • 实体 - 联系图：描绘数据对象和数据对象之间的关系，用于建立数据模型的图形
  • 数据流图：描绘当数据在软件系统中移动时被交换的逻辑过程，指明系统具有的变换数据的功能，数据流图是建立功能模型的基础
  • 状态转换图：描绘了系统的各种行为模式（称为状态）和在不同状态间转换的方式，状态转换图是行为建模的基础
• 软件需求规格说明
  • 软件需求规格说明书是需求分析阶段得出的最主要的文档。

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

• 数据模型的定义
  • 概念性数据模型（信息模型）是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。
• 数据模型的构成
• （1）数据对象
  • ① 定义
    • 数据对象是对软件必须理解的复合信息的抽象。
  • ② 特点
    • a. 可以由一组属性来定义的实体都可以被认为是数据对象。
    • b. 数据对象彼此间是有关联的。
    • c. 数据对象只封装了数据而没有对施加于数据上的操作的引用。
• （2）数据对象的属性（属性）
  • 属性定义了数据对象的性质。
• （3）数据对象彼此间相互连接的关系（联系）
  • 数据对象彼此之间相互连接的方式称为联系，也称为关系。
  • 联系也可能有属性。
  • 联系可分为以下 3 种类型
    • ① 一对一联系（1：1）
    • ② 一对多联系（1：N）
    • ③ 多对多联系（M：N）
• 实体 - 联系图（E-R 图）
  • 实体 - 联系图用于建立数据模型
  • ER 图描绘的数据模型称为 ER 模型
  • ER 图的基本成分
    • E-R 图中包含了实体（数据对象）、关系和属性 3 种基本成分
    • 通常用矩形框代表实体
    • 用连接相关实体的菱形框表示关系
    • 用椭圆形或圆角矩形表示实体（或关系）的属性，并用直线把实体（或关系）与其属性连接起来。
  • 优点
    • ① E-R 模型比较接近人的习惯思维方式；
    • ② E-R 模型使用简单的图形符号来描述问题，便于用户理解。
  • ER 模型可以作为用户与分析员之间的交流工具
  • 

3.5 数据规范化

• 数据规范化减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程
• 使用范式消除数据冗余的程度

3.6 状态转换图

• 定义
  • 状态转换图（状态图）通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。
• 状态
  • （1）定义
    • 状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。
  • （2）分类
    • 状态主要有：初态（初始状态）、终态（最终状态）和中间状态。
    • 【注意】在一张状态图中只能有一个初态，而终态则可以有 0 至多个。描绘单程生命周期时需要标明初始状态和最终状态
• 事件
  • 事件是在某个特定时刻发生的事情，是对引起系统做动作或从一个状态转换到另一个状态的外界事件的抽象，是引起系统做动作或（和）转换状态的控制信息。
• 状态图的符号
  • （1）符号的表示方法
    • ① 初态：用实心圆表示。
    • ② 终态：用一对同心圆（内圆为实心圆）表示。
    • ③ 中间状态：用圆角矩形表示。可以用两条水平横线把它分成上、中、下 3 个部分。上面部分为状态的名称，这部分是必须有的；中间部分为状态变量的名字和值，下面部分是活动表。
  • （2）组成部分
    • 图给出了状态图中使用的主要组成部分和符号表示。
      • 
    • ① 活动表
      • 活动表的语法格式为：事件名（参数表）/ 动作表达式
      • 在活动表中经常使用下述 3 种标准事件：entry，exit 和 do。entry 事件指定进入该状态的动作；exit 事件指定退出该状态的动作；do 事件则指定在该状态下的动作。
    • ② 状态转换
      • 状态图中两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。
      • 状态如果由事件触发，需要在状态转换的箭头上标出触发转换的事件表达式，如果不是由事件触发 (执行完内部活动后自动触发) 则不用标明。
    • ③ 事件表达式
      • 事件表达式的语法为：事件说明 [守卫条件]/ 动作表达式，其中，事件说明的语法为：事件名（参数表）。
      • 守卫条件是一个布尔表达式
• 例子
  • 

3.7 其他图形工具

• 层次方框图

  • 层次方框图用树形结构的一系列多层次的矩形框描绘数据的层次结构。
  • 

• Warnier 图

  • Warnier 图有以下三种基本符号：
    • ① 花括号：用来区分数据结构的层次，在一个花括号内的所有名字都属于同一类信息。
    • ② 异或符号：表明一类信息或一个数据元素在一定条件下才出现。
    • ③ 圆括号中的数字：指明了这个名字代表的信息类在这个数据结构中重复出现的次数。
  • 

• IPO 图

• （1）定义

  • IPO 图是输入、处理、输出图的简称，能够方便地描绘输入数据、对数据的处理和输出数据之间的关系。

• （2）基本形式和用法

  • ① 左边的框中列出有关的输入数据；
  • ② 中间的框内列出主要的处理；
  • ③ 右边的框内列出产生的输出数据；
  • ④ 粗大箭头指出数据通信的情况。
  • 处理框中列出处理的次序暗示了执行的顺序。
  • 

• （3）改进的 IPO 图

  • 改进的 IPO 图（IPO 表）中包含某些附加的信息。如图 3-2 所示，改进的
    IPO 图中包含的附加信息主要有系统名称、图的作者，完成的日期，本图描述的模块的名字，模块在层次图中的编号，调用本模块的模块清 单，本模块调用的模块的清单，注释，以及本模块使用的局部数据元素等。
  • 

• 【注意】要区分并牢记给定图形工具可用于软件生命周期的哪一阶段，此为常考题。本节三种图形工具均可用于需求分析阶段。

3.8 验证软件需求

• 验证软件需求的正确性
  • （1）验证需求正确性的目的
    • 为了提高软件质量，确保软件开发成功，降低软件开发成本。
  • （2）进行验证的四个方面
    • ① 一致性，需求之间不能相互矛盾；
    • ② 完整性，要实现每一个需求；
    • ③ 现实性，指定的需求是在现有的硬件技术和软件技术的基础上可以实现；
    • ④ 有效性，需求可以解决用户面对的问题。
• 验证软件需求的方法
  • （1）验证需求的一致性；
  • （2）验证需求的现实性；
  • （3）验证需求的完整性和有效性。
• 用于需求分析的软件工具——PSL/PSA 系统
  • ① 定义
    • PSL 是用来描述系统的形式语言，PSA 是处理 PSL 描述的分析程序。
  • ② 功能
    • a. 描述任何应用领域的信息系统；
    • b. 创建一个数据库保存对该信息系统的描述符；
    • c. 对描述符施加增加、删除和更改等操作；
    • d. 产生格式化的文档和关于规格说明书的各种分析报告。
  • ③ 优点
    • a. 改进了文档质量，能保证文档具有完整性、一致性和无二义性，从而可以 - 减少管理和维护的费用；
    • b. 数据存放在数据库中，便于增加、删除和更改。

第五章 总体设计

• 目的
  • 总体设计的基本目的就是回答 “概括地说，系统应该如何实现” 这个问题。
• 总体设计又称为概要设计或初步设计
• 主要任务
  • （1）划分出组成系统的物理元素——程序、文件、数据库、人工过程和文档等。
  • （2）确定系统中每个程序是由哪些模块组成的，以及这些模块相互间的关系。
  • 【注意】每个物理元素的具体实现是详细阶段的任务。
• 必要性
  • 可以站在全局高度上，以较少的成本选出最佳方案和最合理的软件结构并开发出较高质量的软件系统。

5.1 设计过程

• 设计过程的两个主要组成阶段
  • （1）系统设计阶段，确定系统的具体实现方案。
  • （2）结构设计阶段，确定软件结构。
• 典型的总体设计过程
  • ①设想供选择的方案；
  • ②选取合理的方案
  • ③推荐最佳方案
  • ④功能分解
  • ⑤设计软件结构
  • ⑥设计数据库
  • ⑦制定测试计划
  • ⑧书写文档
    • 系统说明
    • 用户手册
    • 测试计划
    • 详细的实现计划
    • 数据库设计结果
  • ⑨审查和复查。

5.2 设计原理

5.2.1 模块化

• （1）定义
  • 模块化就是把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能满足用户的需求。
• （2）优点
  • ① 使软件结构清晰，不仅容易设计也容易阅读和理解。
  • ② 使软件容易测试和调试，有助于提高软件的可靠性。
  • ③ 提高软件的可修改性。
  • ④ 有助于软件开发工程的组织管理。
• 【注意】模块是构成程序的基本构件。

5.2.2 抽象

• （1）定义
  • 抽象就是抽出事物的本质特性而暂时不考虑它们的细节。
• （2）优点
  • ① 简化了软件的设计和实现；
  • ② 提高了软件的可理解性和可测试性；
  • ③ 使得软件更容易维护。
• 软件工程过程的每一步都是对软件解法的抽象层次的一次精化

5.2.3 逐步求精

• （1）定义
  • 定义为：为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。
• （2）原理
  • ① 逐步求精是一种自顶向下的设计策略。
  • ② 求精实际上是细化过程。
• 逐步求精如此重要？
  • 因为人类的认知过程遵循 Miller 法则，一个人在任何时候都只能把注意力集中在（7+2）个知识块上
• 抽象与求精是一对互补概念

5.2.4 信息隐藏和局部化

• （1）局部化定义
  • 指把一些关系密切的软件元素物理地放得彼此靠近。
• （2）信息隐藏原理
  • 使得一个模块内包含的信息（主要是实现细节）对于不需要这些信息的模块来说，是不能访问的。
• 局部化有助于信息隐藏

5.2.5 模块独立

• （1）定义
  • 开发的模块具有独立功能而且和其他模块之间没有过多的相互作用的模块，就可以做到模块独立。
  • 模块独立的概念是模块化、抽象、信息隐藏和局部化的直接结果。
• （2）模块的独立程度由两个定性标准衡量：耦合和内聚。
• （3）耦合
  • ① 定义
    • 耦合是对一个软件结构内不同模块之间互连程度的度量。
  • ② 分类
    • a. 完全独立，模块间没有任何连接；
    • b. 数据耦合，模块之间仅通过交换数据来交换信息；
    • c．控制耦合，模块之间传递的信息有控制信息；
    • d．特征耦合，传递的数据为整个数据结构，但只使用其中的一部分数据元素；
    • e. 公共环境耦合，模块之间通过公共数据环境相互作用；
    • f. 内容耦合
      • 模块访问模块内部数据
      • 模块进入另一个模块没有通过正常入口
      • 模块之间部分程序代码重叠
      • 一个模块有多个入口
    • 数据耦合 < 公共环境耦合 < 特征耦合 < 控制耦合 < 内容耦合（越低越好）
• （4）内聚
  • ① 定义
    • 内聚衡量一个模块内部各个元素彼此结合的紧密程度。
  • ② 分类
    • 偶然内聚，模块内任务的关系松散
    • 逻辑内聚，模块完成的任务逻辑上属于相同或类似的一类
    • 时间内聚，模块的任务必须在同一时间段执行
    • 过程内聚，模块内处理元素相关且按一定的次序
    • 通信内聚，模块中所有元素使用同一个输入或产生同一个的输出
    • 顺序内聚，模块中的功能必须顺序执行
    • 功能内聚，模块中所有处理元素属于一个整体，完成一个单一的功能
    • 低内聚（偶然内聚 < 逻辑内聚 < 时间内聚）
    • 中内聚（过程内聚 < 通信内聚）
    • 高内聚（顺序内聚 < 功能内聚）
• 【注意】：设计的软件尽量满足 “高内聚、低耦合” 和“高扇入、低扇出”原则。
• 模块独立性比较强的模块应该是具有高内聚性和低耦合度。
• 在进行软件结构设计时应该遵循的最主要的原理是模块独立原理；
• 自顶向下逐步求精是进行软件结构设计的常用途径；
• 抽象和逐步求精是互补的。

5.3 启发规则

• 改进软件结构提高模块独立性
• 模块规模应该适中
• 深度、宽度、扇出和扇入都应适当
  • （1）深度
    • 深度表示软件结构中控制的层数。
  • （2）宽度
    • 宽度是软件结构内同一个层次上的模块总数的最大值。宽度越大系统越复杂。对宽度影响最大的因素是模块的扇出。
  • （3）扇出
    • 扇出是一个模块直接控制的模块数目。
  • （4）扇入
    • 扇入表明有多少个上级模块直接调用它。
• 模块的作用域应该在控制域之内
  • （1）定义
    • ① 模块的作用域定义为受该模块内一个判定影响的所有模块的集合。
    • ② 模块的控制域是这个模块本身以及所有直接或间接从属于它的模块的集合。
• 力争降低模块接口的复杂程度
• 设计单入口单出口的模块
• 模块功能应该可以预测

5.4 描绘软件结构的图形工具

5.4.1 层次图

• （1）作用
  • 层次图用来描绘软件的层次结构。
• （2）符号
  • ① 矩形框代表一个模块。
  • ② 方框间的连线表示调用关系。
• 

5.4.2 HIPO 图

• HIPO 图是 “层次图加输入 / 处理 / 输出图” 的缩写。
• 在层次图里除了最顶层的方框外，每个方框都加了编号。
• 

5.4.3 结构图

• 结构图的符号表示分为两类：
• （1）基本符号
  • ① 方框代表一个模块，框内注明模块的名字或主要功能；
  • ② 方框之间的箭头（或直线）表示模块的调用关系；
  • ③ 尾部是空心圆的箭头表示传递的是数据，实心圆的箭头表示传递的是控制信息。
  • 
• （2）特殊符号
  • ① 表示当模块 M 中某个判定为真时调用模块 A，为假时调用模块 B，如图所示；
  • 
  • ② 表示模块 M 循环调用模块 A、B 和 C，如图所示。
  • 

5.5 面向数据流的设计方法

• 面向数据流的设计方法的目标：给出设计软件结构的一个系统化的途径
• 通常使用数据流图描绘信息在系统中加工和流动的情况
• 结构化设计方法是基于数据流的设计方法
• 信息流的类型
  • （1）变换流
    • 变换流具有如下特征：
      • ① 信息沿输入通路进入系统，同时由外部形式变换成内部形式；
      • ② 进入系统的信息通过变换中心，经加工处理后沿输出通路变成外部形式离开软件系。
    • 
  • （2）事务流
    • 事务流是 “以事务为中心” 的数据流，即数据沿输入通路到达一个处理 T，这个处理根据输入数据的类型在若干个动作序列中选出一个来执行。
    • 事务流完成接收输入数据、分析每个事务确定事务类型、根据事务选择活动通路的任务
    • 
• 设计过程
  • 下图说明了使用面向数据流方法逐步设计的过程。
  • 
  • 【注意】任何设计过程都不是机械的一成不变的。
• 变换分析
  • 变换分析是一系列设计步骤的总称，经过这些步骤把具有变换流特点的数据流图按预先确定的模式映射成软件结构
  • （1）适用性
    • 一般说来，如果数据流不具有显著的事务特点，最好使用变换分析。
  • （2）设计步骤
    • ① 复查基本系统模型；
    • ② 复查并精化数据流图；
    • ③ 确定数据流图具有变换特性还是事务特性；
    • ④ 确定输入流和输出流的边界，从而孤立出变换中心；
    • ⑤ 第一级分解；
    • ⑥ 第二级分解；
    • ⑦ 使用设计度量和启发式规则对第一次分割得到的软件结构进一步精化。
• 事务分析
  • （1）适用性
    • 在数据流具有明显的事务特点时，即有一个明显的事务中心时，采用事务分析方法为宜。
  • （2）设计
    • 事务分析的映射方法如图所示。
    • 
• 设计优化
  • （1）设计优化时应遵循的原则。
    • ① 应该开发能够满足所有功能和性能要求，而且按照设计原理和启发式设计规则衡量是值得接收的软件。
    • ② 应该在设计的早期阶段尽量对软件结构进行精化。
    • ③ 结构简单通常既表示设计风格优雅，又表明效率高。
    • ④ 对于时间是决定性因素的应用场合，可能需要在详细设计阶段或在编写程序的过程中进行优化。
  • （2）可以采用以下几种方法对时间起决定性作用的软件进行优化。
    • ① 在不考虑时间因素的前提下开发并精化软件结构。
    • ② 在详细设计阶段选出最耗费时间的那些模块，仔细地设计它们的处理过程（算法），以求提高效率。
    • ③ 使用高级程序设计语言编写程序。
    • ④ 在软件中孤立出那些大量占用处理机资源的模块。
    • ⑤ 必要时重新设计或用依赖于机器的语言重写上述大量占用资源的模块的代码，以求提高效率。

第六章 详细设计

• 详细设计阶段的根本目标：确定应该怎样具体地实现所要求的系统
• 详细设计阶段的任务不是具体地编写程序
• 详细设计不仅仅是逻辑上正确地实现每个模块的功能，更重要的是设计出的处理过程应该尽可能简明易懂。
• 结构程序设计技术是实现详细设计目标的关键技术，也是详细设计的逻辑基础。

6.1 结构程序设计

1. 经典定义
   • 如果一个程序的代码块仅仅通过顺序、选择和循环这 3 种基本控制结构进行连接，并且每个代码块只有一个入口和一个出口，则称这个程序是结构化的。
2. 程序设计新定义：
   • 结构程序设计方法是尽可能少用 GO TO 语句的程序设计方法。
3. 控制结构
   • （1）基本控制结构
     • 三种基本的控制结构是 “顺序”“选择” 和“循环”，它们的流程图分别为
     • 
     • 【注意】牢记三种基本控制结构，此为常考内容。
     • 3 种基本控制结构保证每个代码块单入口和单出口，结构程序设计是详细设计的逻辑基础。
   • （2）扩展的控制结构
     • DO UNTIL 和 DO CASE 的流程图分别是
     • 

• 如果只允许使用顺序、IF_THEN_ELSE 型分支、DO_WHILE 型循环这三种基本控制结构，为经典结构程序设计
• 还允许使用 DO_CASE 型多分支结构和 DO_UNTIL 型循环结构，为扩展的结构程序设计
• 如果还允许使用 LEAVE(或 BREAK) 结构，为修正的结构程序设计

6.2 人机界面设计

• 重要性
  • 人机界面设计是接口设计的重要组成部分
  • 对于交互式系统来说，人机界面设计和数据设计、体系结构设计及过程设计一样重要。
  • 人机界面的质量直接影响用户对软件产品的接受程度。
• 设计问题
  • （1）系统响应时间；
  • （2）用户帮助设施；
  • （3）出错信息处理；
  • （4）命令交互。
• 设计过程
  • 用户界面设计是一个迭代的过程，也就是说，通常先创建设计模型，再用原型实现这个设计模型，并由用户试用和评估，然后根据用户意见进行修改。
• 人机界面设计指南
  • 有助于设计者设计出友好、高效的人机界面
  • 一般交互指南
  • 信息显示指南
  • 数据输入指南

6.3 过程设计的工具

• 过程设计的工具，描述程序处理过程的工具，可以分为图形、表格、语言三类

6.3.1 程序流程图（程序框图）

• （1）符号表示
  • 程序流程图中使用的符号表示如图所示。
  • 
• （2）优点
  • 对控制流程的描绘很直观，便于初学者掌握。
• （3）缺点
  • ① 没遵循逐步求精的原则，它诱使程序员过早地考虑程序的控制流程， 而不去考虑程序的全局结构。
  • ② 程序流程图中用箭头代表控制流，因此程序员不受任何约束，可以随意转移控制。
  • ③ 程序流程图不易表示数据结构。

6.3.2 盒图（N-S 图）

• （1）特点
  • ① 功能域明确；
  • ② 不可能任意转移控制；
  • ③ 很容易确定局部和全程数据的作用域；
  • ④ 很容易表示嵌套关系，也可以表示模块的层次结构。
• （2）表示
  • 下图给出了结构化控制结构的盒图表示，也给出了调用子程序的盒图表示方法。
  • 
• （3）优点
  • ① 盒图没有箭头，因此不允许随意转移控制。
  • ② 盒图可以使程序员逐步养成用结构化的方式思考问题和解决问题的习惯。

6.3.3 PAD 图（问题分析图）

• （1）符号表示
  • PAD 图用二维树形结构的图来表示程序的控制流，下图给出 PAD 图的基本符号。
  • 
• （2）优点
  • ① 使用 PAD 符号所设计出来的程序必然是结构化程序。
  • ② PAD 图所描绘的程序结构十分清晰。
  • ③ 用 PAD 图表现程序逻辑，易读、易懂、易记。
  • ④ 容易使用软件工具将 PAD 图自动转换成高级语言源程序，提高了软件可靠性和软件生产率。
  • ⑤ 即可用于表示程序逻辑，也可用于描绘数据结构。
  • ⑥ PAD 图的符号支持自顶向下、逐步求精方法的使用。
• 【注意】PAD 图中竖线的总条数就是程序的层次数。
• 
• PAD 图是面向高级程序设计语言的，为每种常用的高级程序设计语言提供了一整套相应的图形符号

6.3.4 判定表

• （1）适用性
  • 算法中包含多重嵌套的条件选择时使用判定表。
  • 判定表能够清晰地表示复杂的条件组合与应做的动作之间的对应关系
• （2）组成
  • ① 左上部列出所有条件；
  • ② 左下部是所有可能做的动作；
  • ③ 右上部是表示各种条件组合的一个矩阵；
  • ④ 右下部是和每种条件组合相对应的动作。
  • 
  • 
  • 
• 【注意】判定表右半部的每一列实质上是一条规则，规定了与特定的条件组合相对应的动作。

6.3.5 判断树

• 判定树是判定表的变种，能够清晰地表示复杂的条件组合与应做的动作之间的对应关系
• 

6.3.6 过程设计语言

• （1）定义
  • 过程设计语言（PDL），即伪码，它是用正文形式表示数据和处理过程的设计工具。
• （2）优点
  • ① 可作为注释直接插在源程序中，有助于保持文档和程序的一致性，提高文档的质量。
  • ② 可以使用普通的正文编辑程序或文字处理系统，很方便地完成 PDL 的书写和编辑工作。
  • ③ 已经有自动处理 PDL 的程序存在，且可以自动由 PDL 生成程序代码。
• （3）缺点
  • 不如图形工具形象直观，不如判定表清晰简单。

6.4 面向数据结构的设计方法

6.4.1 Jackson 图

• （1）分类
  • Jackson 图根据程序中数据元素彼此间的逻辑关系可分为顺序结构、选择结构和重复结构 3 类，具体如下：
  • ① 顺序结构
    • 
    • 【注意】图中每个元素只出现一次，出现的次序依次是 B、C 和 D。
  • ② 选择结构
    • 
    • 【注意】在 B、C 和 D 的右上角有小圆圈做标记。
  • ③ 重复结构
    • 
    • 【注意】在 B 的右上角有星号标记。
• （2）优点
  • ① 便于表示层次结构，而且是对结构进行自顶向下分解的有力工具。
  • ② 形象直观可读性好。
  • ③ 既能表示数据结构也能表示程序结构。
• （3）缺点
  • ① 图中无法表示选择条件或循环结束条件，影响了图的表达能力，也不易直接把图翻译成程序。
  • ② 框间连线为斜线，不易在行式打印机上输出。

6.4.2 改进的 Jackson 图

• （1）表示
  • 改进的 Jackson 图。
  • 
  • （a）顺序结构：B、C、D 中任一个都不能是选择出现或重复出现的数据元素。
  • （b）选择结构：S 右面括号中的数字 i 是分支条件的编号。
  • （c）可选结构：A 或者是元素 B 或者不出现。
  • （d）重复结构：循环结束条件的编号为 i。
• （2）与层次图的比较
  • ① 层次图中的一个方框代表一个模块；而 Jackson 图中一个方框并不代表一个模块。
  • ② 层次图表现的是调用关系；而 Jackson 图表现的是组成关系。

6.5 程序复杂程度的定量度量

6.5.1 McCabe 方法

• （1）流图
  • ① 定义
    • 流图实质上是 “退化了的” 程序流程图，它仅仅描绘程序的控制流程，完全不表现对数据具体操作以及分支或循环的具体条件。
  • ② 程序流程图映射成流图
    • 下图说明了把程序流程图映射成流图的方法。
    • 
    • a. 流图中用圆表示结点，一个圆代表一条或多条语句。程序流程图中的一个顺序的处理框序列和一个菱形判定框，可以映射成流图中的一个结点。
    • b. 流图中的箭头线称为边，代表控制流。流图中一条边必须终止于一个结点，即使这个结点并不代表任何语句。
    • c. 由边和结点围成的面积称为区域，计算区域数时应包括图外部未被围起来的区域。
  • ③ PDL 翻译成流图
    • a. 基本情况
      • 下图是用 PDL 表示的处理过程及与之对应的流图。
      • 
    • b. 包含复合条件
      • 复合条件，就是在条件中包含了一个或多个布尔运算符。下图是由包含复合条件的 PDL 片段翻译成的流图。
      • 
• （2）环形复杂度
  • ① 定义
    • McCabe 方法根据程序控制流的复杂程度定量度量程序的复杂程度，度量出的结果称为程序的环形复杂度。
  • ② 计算方法
    • 环形复杂度定量度量程序的逻辑复杂度，可以用下述 3 种方法中的任何一种来计算环形复杂度：
      • a. 流图中线性无关的区域数等于环形复杂度。
      • b. 流图 G 的环形复杂度 V(G)=E-N+2，其中，E 是流图中边的条数，N 是结点数。
      • c. 流图 G 的环形复杂度 V(G)=P+1，其中，P 是流图中判定结点的数目。
• 环形复杂度 V（G）=10 是模块规模的合理上限。

6.5.2 Halstead 方法

• （1）定义
  • Halstead 方法是根据程序中运算符和操作数的总数来度量程序的复杂程度。
• （2）方法
  • ① 程序长度 N 定义（N1 为程序中运算符出现的总次数，N2 为操作数出现的总次数）：N=N1+N2；
  • ② 预测程序长度的公式（使用的不同运算符的个数 n1，不同操作数的个数 n2）：H=n1log2(n1)+n2log2(n2)；
  • ③ 预测程序中包含错误的个数的公式：E=Nlog2(n1+n2)/3000。

第七章 实现

• 通常将编码和测试统称为实现。

7.1 编码

1. 编码的定义
   • 编码是把软件设计结果翻译成用程序设计语言书写的程序。
2. 效率
   • 效率主要指处理机时间和存储器容量两个方面。

7.2 软件测试基础

• 软件测试的定义
  • 测试是为了发现程序中的错误而执行程序的过程。
• 测试的目的：
  • 在软件投入生产性运行前，尽可能多地发现软件中的错误。
• 测试的根本任务：发现并改正软件中的错误。
• 根本目标是尽可能多地发现并排除软件中潜藏的错误，最终把一个高质量的软件系统交给用户使用。
• 大型软件测试分为单元测试、集成测试和验收测试。

7.2.1 软件测试的目标

• （1）测试是为了发现程序中的错误而执行程序的过程。
• （2）好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。
• （3）成功的测试是发现了至今为止尚未发现的错误的测试。
• 【注意】测试只能查找出程序中的错误，不能证明程序中没有错误。测试的目标是发现错误，调试的任务是在测试的基础上去改正错误。

7.2.2 软件测试的准则

• ① 所有的测试都可以追溯至用户需求；
• ② 测试开始之前就制定测试计划；
• ③ 把 Pareto 原理应用到软件测试中（测试发现的 80% 很可能是由程序中的 20% 的模块造成的，怎样找出这些可疑的模块）；
• ④ 从 “小规模” 测试开始，逐步进行 “大规模” 测试；
• ⑤ 避免穷举测试（把执行路径都检查一遍，不可能做到，执行路径非常庞大）；
• ⑥ 由独立的第三方从事测试工作以达到最佳的测试效果。

7.2.3 测试方法

• （1）白盒测试
  • ① 白盒测试（结构测试，已经知道产品的内部工作过程）把程序看成装在一个透明的白盒子里，测试者完全知道程序的结构和处理算法。
  • ② 按照程序内部的逻辑测试程序，检测程序中的主要执行通路是否都能按预定要求正确工作。
• （2）黑盒测试
  • ① 黑盒测试（功能测试，已经知道产品应该具有的功能）把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程。
  • ② 黑盒测试是在程序接口进行的测试，只检查程序功能是否能按照规格说明书的规定正常使用。

7.2.4 测试步骤

• （1）单元测试（模块测试）
  • ① 定义：单元测试把每个模块作为一个单独的实体来测试，检验其正确性。
  • ② 目的：保证每个模块作为一个单元能正确运行。
  • 【注意】单元测试发现的是编码和详细设计的错误。
• （2）子系统测试
  • ① 定义：子系统测试把经过单元测试的模块放在一起形成一个子系统来测试。
  • ② 目的：着重测试模块的接口。
• （3）系统测试
  • ① 定义：系统测试是把经过测试的子系统装配成一个完整的系统来测试。
  • ② 目的：发现设计和编码的错误，并验证系统确实能提供需求说明书中指定的功能。
  • 【注意】子系统测试和系统测试都属于集成测试。
• （4）验收测试（确认测试）
  • ① 定义：在用户的参与下，把软件系统作为单一的实体，使用实际数据进行测试。
  • ② 目的：验证系统确实能够满足用户的需要。
  • 【注意】验收测试发现的是系统需求说明书中的错误。
• （5）平行运行
  • ① 定义：同时运行新开发出来的系统和将被它取代的旧系统，以便比较两个系统的处理结果
  • ② 目的：
    • 可以在准生产环境中运行新系统而不冒风险
    • 用户可以有一段熟悉新系统的时间
    • 可以验证用户指南和使用手册之类的文档
    • 能够以准生产模式对新系统进行全负荷测试，可以用测试结果验证性能指标

7.2.5 测试阶段的信息流

• 这个阶段的输入信息有：
  • 软件配置，包括需求说明书、设计说明书、源程序清单
  • 测试配置，包括测试计划、测试方案
• 

7.3 单元测试（模块测试）

• 单元测试：检测软件设计的最小单元——模块

• 单元测试主要使用白盒测试技术。

• 1. 测试重点
  • 着重从下面 5 个方面对模块进行单元测试
  • （1）模块接口；
  • （2）局部数据结构；
  • （3）重要的执行通路；
  • （4）出错处理通路；
  • （5）边界条件。
• 2. 测试方法
  • （1）代码审查；
  • （2）计算机测试。
  • 计算机测试和人工测试（代码审查）各有优缺点互相补充，缺一不可。

• 【注意】必须要为每个单元测试开发驱动软件和（或）存根软件。

7.4 集成测试

• 集成测试定义：
  • 测试和组装软件的系统化技术
  • 在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，进行集成测试。
  • 子系统测试把模块按照设计要求组装起来的同时进行测试
  • 主要目标是发现与接口有关的问题。
• 概念
  • （1）模块组装成程序的方法分类
    • ① 非渐增式测试：单独测试每个模块，最后合并所有模块进行测试。
    • ② 渐增式测试：每次测试增加一个模块。
  • （2）非渐增式测试的缺点
    • ① 把所有模块放在一起，测试者面对的情况十分复杂。
    • ② 在庞大的程序中诊断定位一个错误非常困难。
    • ③ 一旦改正一个错误之后，又会遇到新的错误，没有穷尽。
  • （3）渐增式测试的优点
    • ① 把程序划分成小段来构造和测试，比较容易定位和改正错误。
    • ② 对接口可以进行更彻底的测试。
    • ③ 可以使用系统化的测试方法。
• 渐增式测试的策略
  • （1）自顶向下集成
    • 从主控制模块（根结点）开始，沿着程序的控制层次向下移动，逐渐把各个模块结合起来，在集成过程中，可以采用宽度优先或深度优先的策略向下推进
    • 包含深度优先和宽度优先两种结合策略。
  • （2）自底向上集成
    • 从 “原子” 模块开始组装和测试，不需要存根，需要驱动程序
• 两种集成策略的比较
  • （1）自顶向下集成
    • ① 优点
      • a. 不需要测试驱动程序。
      • b．能够在测试阶段的早期实现并验证系统的主要功能。
      • c．能在早期发现上层模块的接口错误。
    • ② 缺点
      • a．需要存根程序，可能遇到与此相联系的测试困难。
      • b．低层关键模块中的错误发现较晚。
      • c．在早期不能充分展开人力。
  • （2）自底向上集成
    • ① 优点
      • a．不需要存根程序，不会遇到与存根程序相联系的测试困难。
      • b．能较早的发现低层关键模块的错误。
      • c．能在早期充分展开人力。
    • ② 缺点
      • a．需要测试驱动程序。
      • b．不能在测试阶段早期实现并验证系统的主要功能。
      • c．在早期不能发现上层模块的接口错误。
• 其他集成测试策略
  • （1）改进的自顶向下测试方法；
  • （2）混合法。
• 回归测试
  • （1）定义
    • 回归测试是指重新执行已经做过的测试的某个子集，以保证上述这些变化没有带来非预期的副作用。
  • （2）目的
    • 保证由于调试或其他原因引起的变化，不会导致非预期的软件行为或额外错误的测试活动。
  • （3）回归测试集测试用例：
    • ①检测软件全部功能的代表性测试用例；
    • ②专门针对可能受修改影响的软件功能的附加测试；
    • ③针对被修改过的软件成分的测试。

7.5 确认测试（验收测试）

• 确认测试，也称为验收测试，用户根据需求说明书进行测试
• 验收测试由最终用户而不是系统的开发者进行。
• 目标：验证软件的有效性
• 确认测试通常使用黑盒测试法。
• 确认测试的重要内容：软件配置复查
• 确认测试分为 Alpha 测试和 Beta 测试。
  • Alpha 测试：受控制环境下进行
  • Beta 测试：不受控制环境下进行

7.6 白盒测试技术

• 设计测试方案是测试阶段的关键技术问题
  • 测试方案包括具体的测试目的，应该输入的测试数据和预期的结果
  • 设计测试方案的目的：确定一组最可能发现某个错误或某类错误的测试数据
• 白盒测试主要使用于早期阶段；
• 设计白盒测试方案的技术主要有
  • 逻辑覆盖，也称为通路测试，有语句覆盖、判定覆盖、条件覆盖、判定 / 条件覆盖、条件组合覆盖、路径覆盖
  • 控制结构测试，基本路径测试和条件测试
• 逻辑覆盖
  • 一组参数过程逐渐进行越来越完整的通路测试
  • ① 语句覆盖
    • 语句覆盖的含义是选择足够多的测试数据，使被测程序中每个语句至少执行一次。
  • ② 判定覆盖（分支覆盖）
    • 判定覆盖的含义是不仅每个语句必须至少执行一次，而且每个判定的每种可能的结果都应该至少执行一次。
  • ③ 条件覆盖
    • 条件覆盖的含义是不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取到各种可能的结果。
  • ④ 判定 / 条件覆盖
    • 判定 / 条件覆盖的含义是不仅使得判定表达式中的每个条件都取到各种可能的值，而且每个判定表达式也都取到各种可能的结果。它同时满足判定覆盖和条件覆盖。
  • ⑤ 条件组合覆盖
    • 条件组合覆盖要求选取足够多的测试数据，使得每个判定表达式中条件的各种可能组合都至少出现一次。满足条件组合覆盖，也一定满足判定覆盖、条件覆盖和判定 / 条件覆盖标准。
  • ⑥ 点覆盖
    • 要求选取足够多的测试数据，使得程序执行路径至少经过流图的每个结点一次。
    • 【注意】点覆盖标准和语句覆盖标准是相同的。
  • ⑦ 边覆盖
    • 要求选取足够多测试数据，使程序执行路径至少经过流图中每条边一次。
    • 【注意】边覆盖与判定覆盖是相同的。
  • ⑧ 路径覆盖
    • 路径覆盖含义是选取足够多测试数据，使程序的每条可能路径都至少执行一次，如果程序图中有环，则要求每个环至少经过一次。
• 控制结构测试
  • （1）基本路径测试
  • 【注意】某些独立路径不能以独立的方式测试，即程序的正常流程不能形成独立执行该路径所需要的数据组合。
  • （2）条件测试
  • （3）循环测试
    • 在结构化的程序中通常只有 3 种循环，即简单循环、串接循环和嵌套循环。
    • 

7.7 黑盒测试技术

• 黑盒测试力图发现的错误：
  • ①功能不正确或遗漏了功能；
  • ②界面错误；
  • ③数据结构错误或外部数据库访问错误；
  • ④性能错误；
  • ⑤初始化和终止错误。
• 黑盒测试主要使用于后期阶段。
• 设计黑盒测试方案技术主要有，等价划分、边界值分析和错误推测。
• 等价划分
  • 把程序的输入域划分成若干个数据类，选取每个等价类中的一个典型值或任意值作为测试数据。
• 边界值分析
  • 确定边界情况，选取刚好等于、稍小于和稍大于等价类边界值的数据作为测试数据。
• 错误推测
  • 利用判定表或判定树为工具，列出输入数据各种组合与程序应做的动作之间的对应关系，然后为判定表的每一列至少设计一个测试用例。

7.8 调试

• 定义
  • 调试是在测试发现错误之后排除错误的过程。
  • 调试：定位错误，及时改正错误。
• 调试途径
  • （1）蛮干法。
  • （2）回溯法。
  • （3）原因排除法。
    • ① 对分查找法；
    • ② 归纳法；
    • ③ 演绎法。
• 【注意】务必注意测试和调试的区别。改错是调试的任务，测试的任务是发现错误。

7.9 软件可靠性

• 测试阶段的根本目标是消除错误，保证软件的可靠性
• 程序中潜藏的错误的数目，直接决定了软件的可靠性
• 基本概念
  • （1）软件可靠性
    • 软件可靠性是程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率。
  • （2）软件的可用性
    • 软件可用性是程序在给定的时间点，按照规格说明书的规定，成功地运行的概率。
  • （3）MTTF 和 MTTR
    • ① 概念
      • a. 平均维修时间 MTTR
        • 表示修复一个故障平均需要用的时间。
      • b. 平均无故障时间 MTTF
        • 表示系统按规格说明书规定成功地运行的平均时间。
    • ② 计算公式
      • 如果在一段时间内，软件系统故障停机时间分别为 t d 1 ， t d 2 ， … ， t_{d1}，t_{d2}，…， td1​，td2​，…，正常运行时间分别为 t u 1 ， t u 2 ， … ， t_{u1}，t_{u2}，…， tu1​，tu2​，…，则系统的稳态可用性为：
      • 
      • 其中：
      • 
      • （7.1）式可以变成
      • 
• 估算平均无故障时间的方法
  • （1）符号
    • ① E T E_T ET​：测试之前程序中错误总数；
    • ② I T I_T IT​：程序长度（机器指令总数）；
    • ③ τ τ τ：测试（包括调试）时间；
    • ④ E d (τ) E_d(τ) Ed​(τ)：在 0 至 τ τ τ期间发现的错误数；
    • ⑤ E c (τ) E_c(τ) Ec​(τ)：在 0 至 τ τ τ期间改正的错误数。
• （2）基本假定
  • ① 单位长度里的错误数 E T E_T ET​/ I T I_T IT​近似为常数。通常 0.5 × 1 0 − 2 0.5×10^{-2} 0.5×10−2≤ E T E_T ET​/ I T I_T IT​≤ 2 × 1 0 − 2 2×10^{-2} 2×10−2。
  • ② 失效率正比于软件中潜藏的错误数，平均无故障时间 MTTF 与剩余的错误数成反比。
  • ③ 假设发现的每一个错误都立即正确地改正了，即 E c (τ) = E d ( τ ) E_c(τ)=E_d(τ) Ec​(τ)=Ed​(τ)。
    • a. 剩余的错误数
      • 
    • b. 单位长度程序中剩余的错误数
      • 
• （3）估算平均无故障时间
  • ① 平均无故障时间与单位长度程序中剩余的错误数成反比（K 经典值为 200），即
    • 
  • ② 估算平均无故障时间的公式，可以评价软件测试进展情况。由（7.5）式可得：
    • 
• （4）估计错误总数的方法
  • ① 植入错误法
    • 假设人为地植入的错误数为 Ns，经过一段时间的测试之后发现 ns 个植入的错误，还发现了 n 个原有的错误。则估计出程序中原有错误的总数为：
    • 
    • 其中估计出程序中原有错误的总数即是错误总数 E T E_T ET​的估计值。
  • ② 分别测试法
    • 假定测试员甲乙发现有标记错误和发现无标记错误的概率相同，则可以估计出测试前程序中的错误总数为：
    • 
    • 其中，测试员甲发现的错误数为 B 1 B_1 B1​，测试员乙发现的错误数为 B 2 B_2 B2​，两个测试员发现的相同错误数为 b c b_c bc​。

第八章 维护

• 维护的基本任务：保证软件在一个相当长的时期能够正常运行
• 软件工程的主要目的就是要提高软件的可维护性，减少软件维护所需要的工作量，降低软件系统的总成本。

8.1 软件维护的定义

1. 定义
   • 软件维护是在软件已经交付使用后，为了改正错误或满足新的需要而修改软件的过程。
2. 分类
   • （1）改正性维护；
   • （2）适应性维护；
   • （3）完善性维护；
   • （4）预防性维护。

8.2 软件维护的特点

• 结构化维护与非结构化维护差别巨大
  • 结构化维护（有一个完整的软件配置）
  • 非结构化维护（内部文档不足）
• 维护的代价高昂
  • 软件维护中无形的代价有：
    • （1）软件维护的费用高昂。
    • （2）因为可用的资源必须供维护任务使用，以致耽误甚至丧失了开发的良机。
    • （3）生产率的大幅度下降。
• 维护的问题很多
  • （1）理解别人写的程序非常困难，而且困难程度随着软件配置成分的减少而迅速增加。
  • （2）需要维护的软件往往没有合格的文档，或者文档资料显著不足。
  • （3）当要求对软件进行维护时，不能指望由开发人员给人们仔细说明软件。
  • （4）绝大多数软件在设计时没有考虑将来的修改。
  • （5）软件维护不是一项吸引人的工作。

8.3 软件维护过程

• 定义
  • 维护过程本质上是修改和压缩了的软件定义和开发过程。
• 具体过程
  • （1）建立维护组织；
  • （2）书写维护报告；
  • （3）规定维护的事件流；
    • 
• （4）保存维护记录；
• （5）评价维护活动。

8.4 软件的可维护性

• 定义
  • 可维护性指的是维护人员理解、改正、改动或改进这个软件的难易程度。
• 决定软件可维护性的因素
  • （1）可理解性；
  • （2）可测试性；
  • （3）可修改性；
  • （4）可移植性；
  • （5）可重用性。
• 文档
  • （1）重要性
    • 文档是影响软件可维护性的决定因素，文档比程序代码更重要。
    • 只有和程序代码完全一致的文档才是真正有价值的文档。
  • （2）分类
    • 软件系统的文档可以分为用户文档和系统文档两类。

8.5 预防性维护

• 定义
  • 预防性维护指的是把今天的方法学应用到昨天的系统上，以支持明天的需求。
• 实质
  • 预防性维护实质上是软件再工程。

8.6 软件再工程过程

• 典型软件再工程模型
  • 典型的软件再工程过程模型如图所示。
  • 
  • 【注意】在某些情况下这些活动以线性顺序发生，但也并非总是这样。
• 六类活动
  • （1）库存目录分析；
  • （2）文档重构；
  • （3）逆向工程：分析程序，在高于源代码的抽象层次上表示程序的过程。；
  • （4）代码重构；
  • （5）数据重构；
  • （6）正向工程：不仅从现有程序中恢复设计信息，而且使用革新和改造使用信息去改变或重构现有系统。

第十三章：软件项目管理

13.1 软件项目管理总述

1. 管理

• 管理是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。

2. 软件项目管理

• 软件项目管理先于任何技术活动之前开始，并且贯穿于软件的整个生命周期之中。软件项目管理过程从一组项目计划活动开始，而制定计划的基础是工作量估算和完成期限估算。

13.2 估算软件规模

1. 代码行技术

• (1) 定义
  代码行技术依据以往开发类似产品的经验和历史数据，估计实现一个功能所需要的源程序行数。是一种比较简单的定量估算软件估摸的方法。
  (2) 方法
  ①把实现每个功能的源程序行数累加起来，可得到实现整个软件所需要的源程序行数。
  ②估计程序的最小规模 (a)、最大规模(b) 和最可能的规模(m), 分别算出这 3 种规模的平均值后，再用下式计算程序规模的估计值：(13.1)
  ③程序小时用的单位是代码行数 (LOC); 程序大时用的单位是千行代码数 (KLOC)。
  (3) 优点
  ①代码是所有软件开发项目都有的 “产品”, 而且很容易计算代码行数。
  ②有以往开发类似产品的历史数据可参考时，估计出的数值比较准确。
  (4) 缺点
  ①源程序仅是软件配置的一个成分，用它的规模代表整个软件的规模不太合理。
  ②用不同语言实现同一个软件所需要的代码行数并不相同。
  ③不适用于非过程语言。
  • (13.1)
    

2. 功能点技术

• (1) 定义
  功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。用功能点 (FP) 为单位度量软件规模。是为了克服代码行技术的缺点，提出来的新技术。
  (2) 信息域特性
  ①输入项数 (Inp): 用户向软件输入的项数，这些输入给软件提供面向应用的数据。
  ②输出项数 (Out): 软件向用户输出的项数，它们向用户提供面向应用的信息。
  ③查询数 (Inq): 一次联机输入，它导致软件以联机输出方式产生某种即时响应。
  ④主文件数 (Maf): 逻辑主文件(数据的一个逻辑组合) 的数目。
  ⑤外部接口数 (Inf): 机器可读的全部接口数量，用这些接口把信息传送给另一个系统。

13.3 工作量估算

软件估算模型使用由经验导出的公式来预测软件开发工作量，工作量是软件规模的函数，工作量的单位通常是人月 (pm)。没有一个估算模型可以适用于所有类型的软件和开发环境。

1. 静态单变量模型

2. 动态多变量模型

3.COCOMO2 模型

13.4 进度计划

1. 相关概念

• (1) 任务集合
  一个有效的软件过程应该定义一个适用于当前项目的任务集合。一个任务集合包括一组软件工程工作任务、里程碑和可交付的产品。为一个项目所定义的任务集合，必须包括为获得高质量的软件产品而应该完成的所有任务，但是同时又不能让项目组承担不必要的工作。
  (2) 项目管理者的工作
  ①目标
  定义全部项目任务，识别出关键任务，跟踪关键任务的进展状况，保证及时发现拖延进度的情况。
  ②方法
  管理者必须制定一个足够详细的进度表，以便监督项目进度并控制整个项目。
  (3) 进度安排
  ①定义
  软件项目的进度安排通过把工作量分配给特定的软件工程任务并规定完成各项任务的起止日期，从而将估算出的项目工作量分布于计划好的项目持续期内。进度计划将随着时间的流逝而不断演化。
  ②流程
  a. 在项目计划的早期，制定一个宏观的进度安排表，标识出主要的软件工程活动和这些活动影响到的产品功能。
  b. 随着项目的进展，把宏观进度表中的每个条目都精化成一个详细进度表，标识出完成一个活动所必须实现的一组特定任务，并安排好实现这些任务的进度。

2. 估算开发时间

• P312

3.Gantt 图

• (1) 例子
  假设有一座陈旧的矩形木板房需要重新油漆。这项工作必须分 3 步完成：首先刮掉旧漆，然后刷上新漆，最后清除溅在窗户上的油漆。假设一共分配了 15 名工人去完成这项工作，然而工具却很有限：只有 5 把刮旧漆用的刮板，5 把刷漆用的刷子，5 把清除溅在窗户上的油漆用的小刮刀。怎样安排才能使工作进行得更有效呢?
  (2) 优点
  ①很形象地描绘任务分解情况，以及每个子任务 (作业) 的开始时间和结束时间。
  ②容易掌握、容易绘制。
  (3) 缺点
  ①不能显式地描绘各项作业彼此间的依赖关系。
  ②进度计划的关键部分不明确，难于判定哪些部分应当是主攻和主控的对象。
  ③计划中有潜力的部分及潜力的大小不明确，往往造成潜力的浪费。

  • 图 13.1 旧木板房刷漆工程的 Gantt 图
    

4. 工程网络

• (1) 定义
  工程网络可以描绘任务分解情况以及每项作业的开始时间和结束时间，它还显式地描绘各个作业彼此间的依赖关系。
  (2) 表示
  工程网路，如图 13.2 所示。
  ①用箭头表示作业，作业通常既消耗资源又需要持续一定时间。
  ②用圆圈表示事件 (开始或结束), 事件是明确定义的时间点，并不消耗时间和资源。
  ③用虚线箭头表示虚拟作业，虚拟作业是为了显式地表示作业之间的依赖关系。
  • 图 13.2 旧木板房刷漆工程的工程网络
    

5. 估算工程进度

• P316

6. 关键路径

• (1) 定义
  由最早时刻和最迟时刻相同的事件定义了关键路径。关键事件必须准时发生，组成关键作业的实际持续时间不能超过估计的持续时间，否则工程就不能准时结束。
  (2) 特点
  ①处于关键路径之外的任务进度拖后，不会影响整个项目的完成时间。
  ②处于关键路径之中的任务进度拖后，则整个项目的完成日期就会拖后。

7. 机动时间

• (1) 定义
  不在关键路径上的作业有一定程度的机动余地一实际开始时间可以比预定时间晚一些，或者实际持续时间可以比预定的持续时间长一些，而并不影响工程的结束时间。
  (2) 计算
  一个作业可以有的全部机动时间等于它的结束事件的最迟时刻减去它的开始事件的最早时刻，再减去这个作业的持续时间：
  机动时间 =(LET) 结束 -(EET) 开始 - 持续时间
  (3) 表示
  工程网络中每个作业的机动时间写在该项作业的箭头下面的括号里，如图 13-3 所示。在制定进度计划时仔细考虑和利用工程网络中的机动时间，往往能够安排出既节省资源又不影响最终竣工时间的进度表。

13.5 人员组织

1. 必要性

• (1) 项目成功的关键合理的组织人员，使他们有效地分工协作共同完成开发工作。
  (2) 项目组组织得越好，其生产率越高，而且产品质量也越好。
  (3) 项目组具有了凝聚力，成功的可能性就大大增加了。

2. 典型的组织方式

现有的软件项目组的组织方式很多，通常，组织软件开发人员的方法，取决于所承担的项目的特点、以往的组织经验以及管理者的看法和爱好，主要有 3 种典型的组织方式。

• (1) 民主制程序员组
  ①定义
  民主制程序员组中小组成员完全平等，享有充分民主，通过协商做出技术决策。即小组成员之间的通信是平行的，如果小组内有 n 个成员，则可能的通信信道共有 n(n-1)/2 条。
  ②要求
  a. 小组的人数不能太多 (2～8 名成员为宜)
  小组规模小，可以减少通信问题、容易确定小组的质量标准、用民主方式确定的标准更容易被大家遵守、组员间关系密切、能够互相学习。
  b. 采用非正式的组织方式
  名义上有一个组长，但是他和组内其他成员完成同样的任务。在这样的小组中，由全体讨论协商决定应该完成的工作，并且根据每个人的能力和经验分配适当的任务。
  ③优点
  a. 组员们对发现程序错误持积极的态度，有助于更快速地发现错误，提高代码质量。
  b. 组员们享有充分民主，小组凝聚力高、学术空气浓厚，有利于攻克技术难关。
  ④缺点
  没有明确的权威指导开发过程，组员间将缺乏必要的协调，最终可能导致工程失败。
  ⑤适用性
  所要开发的软件的技术难度较高时，采用民主制程序员组是适宜的。

• (2) 主程序员组

  • ①定义
    主程序员组用经验多、技术好、能力强的程序员作为主程序员，同时，利用人和计算机在事务性工作方面给主程序员提供充分支持，而且所有通信都通过一两个人进行。典型的主程序员组的组织形式如图 13.5 所示。
    ②核心人员及其分工
    a. 主程序员
    既是成功的管理人员又是经验丰富、技术好、能力强的高级程序员，负责体系结构设计和关键部分的详细设计，并且负责指导其他程序员完成详细设计和编码工作。
    b. 后备程序员
    技术熟练而且富于经验，协助主程序员工作并且在必要时接替主程序员的工作。具体工作是设计测试方案、分析测试结果及独立于设计过程的其他工作。
    c. 编程秘书
    负责完成与项目有关的全部事务性工作。
    注意：图 13.5 介绍的是 20 世纪 70 年代初期的主程序员组组织结构，现在的情况已经和当时大不相同了，程序员已经有了自己的终端或工作站，他们自己完成代码的输入、编辑、编译、链接和调试等工作，无须由编程秘书统一做这些工作。
    ③特点 (优点)
    a. 专业化：该组每名成员仅完成他们擅长的工作。
    b. 层次性：主程序员指挥组员工作，并对项目全面负责
    ④缺点
    符合主程序员、后备程序员、编辑秘书标准的人才在现实社会中并不容易雇佣到。
    ⑤适用性
    采用主程序员组这种组织方式的程序一般具有以下几方面的特点：
    a. 软件开发人员多数比较缺乏经验。
    b. 程序设计过程中有许多事务性的工作。
    c. 多渠道通信很费时间，将降低程序员的生产率。

    • 图 13.5 主程序员组的结构
      

• (3) 现代程序员组

  • ①主程序员由两个人共同担任
    a. 技术负责人
    负责小组的技术活动，参与全部代码审查工作，并且对代码的各方面质量负责。
    b. 行政负责人
    负责非技术性事务的管理决策。不参与代码审查，其职责是对程序员的业绩进行评价。
    ②制定针对公共职责范围内的事务的处理方案
    ③实行分组策略
    采用分组策略，如图 13.7 所示。产品开发作为一个整体是在项目经理的指导下进行的，程序员向他们的组长汇报工作，而组长则向项目经理汇报工作。当产品规模更大时，可以适当增加中间管理层次。
    ④分散决定
    在合适的地方采用分散做决定的方法，如图 13.8 所示。这样做有利于形成畅通的通信渠道，以便充分发挥每个程序员的积极性和主动性，集思广益攻克技术难关。

    • 图 13.6 现代程序员组的结构
      

    • 图 13.7 大型项目的技术管理组织结构
      

    • 图 13.8 包含分散决策的组织方式
      

13.6 质量保证

1. 软件质量

• (1) 定义
  软件质量是软件与明确地和隐含地定义的需求相一致的程度，即软件质量是软件与明确地叙述的功能和性能需求、文档中明确描述的开发标准以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度。
  (2) 特点
  ①软件需求是度量软件质量的基础，与需求不一致就是质量不高。
  ②指定的开发标准定义了指导软件开发准则，没有遵守这些准则，会导致软件质量不高。
  ③软件满足明确描述的需求，但不满足隐含的需求，那么软件的质量是值得怀疑的。
  (3) 软件质量因素与产品活动
  ①软件质量因素
  如表 13.7 所示，列出了软件质量因素的简明定义。
  ②产品活动
  可以把产品活动 (倾向) 分为产品运行、产品修改和产品转移。
  ③关系
  软件质量因素和 3 种产品活动 (倾向) 之间的关系，如图 13.9 所示。

  • 表 13.7 软件质量因素的定义
    

  • 图 13.9 软件质量因素与产品活动的关系
    

2. 软件质量保证措施

• (1) 措施
  ①基于非执行的测试 (复审或评审): 主要用来保证在编码前各阶段产生的文档的质量。
  ②基于执行的测试 (软件测试): 在程序编写完后进行， 保证软件质量的最后一道防线。
  ③程序正确性证明：使用数学方法严格验证程序是否与对它的说明完全一致。
  (2) 参加软件质量保证的人员分类
  ①软件工程师：用先进的技术方法和度量，进行复审以及完成软件测试来保证软件质量。
  ②SQA 小组：辅助软件工程师以获得高质量的软件产品。其从事的软件质量保证活动的主要是：计划，监督，记录，分析和报告，它通过确保软件过程的质量来保证软件产品的质量。
  (3) 技术复审
  正式技术复审的优点是能较早发现软件错误，防止错误被传播到软件过程的后续阶段。包括走查和审查等具体方法。
  ①走查
  a. 走查组
  走查组由 4～6 名成员组成。成员包括负责起草文档的人、负责该文档说明的管理员、客户代表、下阶段开发组的代表、SQA 小组的代表 (作为组长)。
  b. 要点
  第一，为了能发现重大错误，走查组成员最好是经验丰富的高级技术人员。
  第二，走查组成员应根据材料并列出不理解的术语和认为不正确的术语。
  第三，走查组组长引导该组成员走查文档，力求发现尽可能多的错误。
  第四，走查的时间最长不要超过 2 小时。
  c. 方式
  第一，参与者驱动法
  参与者按照事先准备好的列表，提出他们不理解的术语和认为不正确的术语。文档编写组的代表必须回答每个质疑。
  第二，文档驱动法 (更有效)
  文档编写者向走查组成员仔细解释文档。走查组成员在此过程中针对事先准备好的问题或解释过程中发现的问题提出质疑。
  ②审查
  a. 审查组
  查组由 4 人组成，分别是组长 (既是管理人员又是技术负责人)、负责当前阶段开发工作的项目组代表、负责下一阶段开发工作的项目组代表、SQA 小组的代表。
  b. 步骤
  第一，综述
  由负责编写文档的成员向审查组综述该文档。
  第二，准备
  评审员仔细阅读文档。
  第三，审查
  评审组仔细走查整个文档。
  第四，返工
  文档的作者负责解决在审查报告中列出的所有错误及问题。
  第五，跟踪
  组长必须确保所提出的每个问题都得到了圆满的解决。
  c. 与走查比较
  第一，审查过程步数比走查多。
  第二，审查过程每个步骤都是正规的仔细划分错误类型，并把这些信息运用在后续阶段的文档审查中以及未来产品的审查中。
  d. 重要性
  审查是检测软件错误的一种好方法，利用审查可以在软件过程的早期阶段 (修改成本低的阶段) 发现并改正错误，即审查是一种经济有效的错误检测方法。
  注意：走查的步骤比审查少，没有审查正规。
  (4) 程序正确性证明
  ①定义
  正确性证明的基本思想是证明程序能完成预定的功能。应提供对程序功能的严格数学说明，然后根据程序代码证明程序确实能实现它的功能说明。
  ②方法
  a. 人工证明程序正确性
  对于评价小程序可能有些价值，但在证明大型软件的正确性时，不仅工作量太大，而且在证明的过程中很容易包含错误。
  b. 自动系统

13.7 软件配置管理

1. 相关概念

• (1) 定义
  软件配置管理是在软件的整个生命期内管理变化的一组活动。其主要任务是控制变化，同时也负责各个软件配置项和软件各种版本的标识、软件配置审计以及对软件配置发生的任何变化的报告。
  (2) 目的
  软件配置管理不同于软件维护，它的目标是使变化更正确且更容易被适应，在必须变化时减少所需花费的工作量。具体如下：
  ①标识变化；
  ②控制变化；
  ③确保适当地实现了变化；
  ④向需要知道这类信息的人报告变化。
  (3) 与维护的区别
  维护是在软件交付给用户使用后才发生的，而配置管理是在软件项目启动时就开始，并且一直持续到软件退役后才终止的一组跟踪和控制活动。

2. 软件配置

• (1) 软件配置项
  软件过程的输出信息可以分为 3 类：
  ①计算机程序 (源代码和可执行程序)。
  ②描述计算机程序的文档 (供技术人员或用户使用)。
  ③数据 (程序内包含的或在程序外的)。
  (2) 基线
  ①定义
  基线是已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变它，即基线就是通过了正式复审的软件配置项。
  ②作用
  基线有助于人们在不严重妨碍合理变化的前提下来控制变化。
  (3) 软件工具
  把特定版本的编辑器、编译器和其他 CASE 工具，作为软件配置的一部分。为防止不同版本的工具产生结果不同，应把软件工具也基线化，并且列入到综合的配置管理过程之中。

3. 软件配置管理过程

• 软件配置管理是软件质量保证的重要一环，它的主要任务是控制变化，同时也负责各个软件配置项和软件各种版本的标识、软件配置审计以及对软件配置发生的任何变化的报告，具体来说，软件配置管理主要有 5 项任务标识、版本控制、变化控制、配置审计和报告。
  (1) 标识软件配置中的对象
  ①对象分类
  a. 基本对象：是软件工程师在分析、设计、编码或测试过程中创建出来的 “文本单元”。
  b. 聚集对象：是基本对象和其他聚集对象的集合。
  ②要点
  a. 每个对象都有一组能唯一地标识它的特征：名字、描述、资源表和实现。
  b. 对象名是无二义性地标识该对象的一个字符串。
  c. 标识模式必须能无歧义地标识每个对象的不同版本。
  (2) 版本控制
  ①定义
  版本控制使用规程和工具，以管理在软件工程过程中所创建的配置对象的不同版本。
  ②目标
  借助于版本控制技术，用户能通过选择适当的版本来指定软件系统的配置。
  ③步骤
  a. 把属性和软件的每个版本关联起来。
  b. 描述一组所期望的属性 (施加到系统上的功能变化的具体类型) 来指定和构造所需要的配置。
  (3) 变化控制
  ①定义
  变化控制把人的规程和自动工具结合起来，以提供一个控制变化的机制。
  ②过程
  a. 评估该变化在技术方面的得失、可能产生的副作用、对其他配置对象和系统功能的整体影响以及估算出
  的修改成本。
  b. 根据评估结果形成变化报告，供变化控制审批者审阅。
  c. 为每个被批准的变化都生成一个工程变化命令，描述将要实现的变化，必须遵守的约束以及复审和审计的标准。
  d. 把要修改的对象从项目数据库中提取出来，进行修改并应用适当的 SQA 活动。
  e. 把修改后的对象提交进数据库，用适当的版本控制机制创建该软件的下一个版本。
  ③主要功能
  a. 访问控制：决定哪个软件工程师有权访问和修改一个特定的配置对象。
  b. 同步控制：助于保证由两名不同的软件工程师完成的并行修改不会相互覆盖。
  (4) 配置审计
  ①正式的技术复审
  正式的技术复审关注被修改后的配置对象的技术正确性。复审者审查该对象以确定它与其他软件配置项的一致性，并检查是否有遗漏或副作用。
  ②软件配置审计
  软件配置审计通过评估配置对象的那些通常不在复审过程中考虑的特征，而成为对正式技术复审的补充。
  (5) 状态报告
  ①内容
  a. 发生的事件。
  b. 做的这件事的人。
  c. 事件是发生的时间。
  d. 产生的影响。
  ②作用
  配置状态报告对大型软件开发项目的成功有重大贡献。配置状态报告通过改善所有相关人员之间的通信，帮助消除由于通信不精确、不及时所产生的严重问题。

13.8 能力成熟度模型

1. 能力成熟度模型 (CMM)

• (1) 定义
  能力成熟度模型 (CMM) 是用于评价软件机构的软件过程能力成熟度的模型。
  (2) 目的
  ①为大型软件项目的招投标活动提供一种全面而客观的评审依据。
  ②应用于许多软件机构内部的过程改进活动中。
  (3) 基本思想
  能力成熟度模型的基本思想是，由于问题是由人们管理软件过程的方法不当引起的，所以新软件技术的运用并不会自动提高软件的生产率和质量。
  (4) 作用
  能力成熟度模型有助于软件开发机构建立一个有规律的、成熟的软件过程。改进后的软件过程将开发出质量更好的软件，使更多的软件项目免受时间延误和费用超支之苦。
  (5)CMM 在改进软件过程中所起的作用
  ①指导软件机构通过确定当前的过程成熟度并识别出对过程改进起关键作用的问题，明确过程改进的方向和策略。
  ②通过集中开展与过程改进的方向和策略相一致的一组过程改进活动，软件机构便能稳步而有效地改进其软件过程，使其软件过程能力得到循序渐进的提高。
  (6) 对能力成熟度划分的原因
  ①对软件过程的改进，是在完成一个又一个小的改进步骤基础上不断进行的渐进过程。
  ②这 5 个成熟度等级定义了一个有序的尺度，用以测量软件机构的软件过程成熟度和评价其软件过程能力，这些等级还帮助软件机构把应做的改进工作排出优先次序。
  ③成熟度等级是妥善定义的向成熟软件机构前进途中的平台，每个成熟度等级都为软件过程的继续改进提供了一个台阶。

2. 能力成熟度的 5 个等级

• (1) 内容
  ①反映出软件机构为了达到从无序的、混乱的软件过程进化到有序的、有纪律的且成熟的软件过程的目的，必须经历的过程改进活动的途径。
  ②每个成熟度级别都是该软件机构沿着改进其过程的途径前进途中的一个台阶，后一个成熟度级别是前一个级别的软件过程的进化目标。
  ③每个成熟度级别中都包含一组过程改进的目标，满足这些目标后一个机构的软件过程就从当前级别进化到下一个成熟度级别。
  (2)5 个级别
  ①初始级 (1 级)
  软件过程能力是不可预测的，其软件过程是不稳定的，产品质量只能根据相关人员的个人工作能力来预测。
  ②可重复级 (2 级)
  软件项目的策划和跟踪是稳定的，已经为一个有纪律的管理过程提供了可重复以前成功实践的项目环境。
  ③已定义级 (3 级)
  无论是管理活动还是工程活动都是稳定的。软件开发的成本和进度以及产品的功能和质量都受到控制，而且软件产品的质量具有可追溯性。
  ④已管理级 (4 级)
  软件机构对软件过程和软件产品都建立了定量的质量目标，所有项目的重要的过程活动都是可度量的，软件过程在可度量的范围内运行。
  ⑤优化级 (5 级)
  软件机构能够不断地改进其过程能力，既对现行的过程实例不断地改进和优化，又借助于新技术和新方法来实现未来的过程改进。这一级的软件机构是一个以防止出现缺陷为目标的机构，它有能力识别软件过程要素的薄弱环节，并有足够的手段改进它们。