软件设计师-第五章(软件工程)

软件工程

软件工程基本原理

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

软件生存周期

1. 可行性分析与项目开发计划
   • 目标：确定软件开发目标及可行性
   • 输出：可行性分析报告、项目开发计划
2. 需求分析
   • 目标：确定软件系统要做什么，以及它的功能、性能、数据和界面等要求，从而确定系统的逻辑模型。
   • 输出：软件需求说明书
3. 概要设计
   • 目标：明确软件中的模块、模块的层次结构、模块的调用关系和功能。明确数据库结构
   • 输出：概要设计说明书
4. 详细设计
   • 目标：明确模块的控制结构
   • 输出：详细设计说明书
5. 编码
   • 目标：将过程描述转变为程序代码
   • 输出：某种特定语言的源代码
6. 测试
   • 目标：保证软件质量
   • 输出：软件测试计划、测试用例、软件测试报告
7. 维护

能力成熟度模型-CMM

能力等级	特点
初始级	软件过程的特点是杂乱无章，有时甚至很混乱，几乎没有明确定义的步骤，项目的完成全依赖个人的努力和英雄式核心人物的作用。
可重复级	建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功。
已定义级	管理和工程两方面的软件过程已经文档化、标准化，并综合成整个软件开发组织的标准软件过程。 所有项目都采用根据实际情况修改后得到的标准软件过程来开发和维护软件。
已管理级	制定了软件过程和产品质量的详细度量标准。软件过程的产品质量都被开发组织的成员所理解和控制。
优化级	加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。

能力成熟度模型-CMMI

1. 能力成熟度模型集成-CMMI
   • 是若干过程模型的综合和改进，不仅仅是软件，而是支持多个工程学科和领域的、系统的、一致的过程改进框架，
     能适应现代工程的特点和需要，能提高过程的质量和工作效率。
2. CMMI两种表示方法：
   • 阶段式模型：类似于CMM，它关注组织的成熟度。
   • 连续式模型：关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力等级。

阶段式模型成熟度等级描述如下：

能力等级	特点	关键过程区域
初始级	过程不可预测且缺乏控制
可重复级	过程为项目服务	需求管理、项目计划、配置管理、项目监督与控制、供应商合同管理、度量和分析、过程和产品质量保争
已定义级	过程为组织服务	需求开发、技术解决方案、产品集成、验证、确认组织级过程焦点、组织级过程定义、 组织级培训、集成项目管理、风险管理、集成化的团队、决策分析和解决方案、组织级集成环境
已管理级	过程已度量和控制	组织过程性能、定量项目管理
优化级	集中于过程改进和优化	组织级改革和实施、因果分析和解决方案

软件过程模型

瀑布模型(SDLC)

瀑布模型是一个经典的生命周期模型，一般将软件开发分为：可行性分析(计划)、需求分析、软件设计(概要设计、详细设计)、编码、测试、运行维护几个阶段。

瀑布模型是以文档作为驱动、适合于软件需求很明确的软件项目模型。
瀑布模型特点：

1. 从上一项开发活动接收该项活动的工作对象作为输入。
2. 接收输入后，实施该项活动应完成的工作内容。
3. 给出该项活动的工作成果，作为输出传给下一项开发活动。
4. 对该项活动的实施工作成果进行评审。若评审通过，则进入下一项开发活动；否则返回前一项甚至更前项的活动。

瀑布模型变种-V模型

V模型：从整体上来看，就是一个V字形的结构，由左右两边组成。

1. 左边的线分别代表了需求建模(需求分析)、概要设计、详细设计、编码。
2. 右边的线分别代表了单元测试、集成测试、系统测试与验收测试。

V模型的特点如下：

1. 单元测试主要针对编码过程中可能存在的各种错误进行验证。
2. 集成测试主要针对详细设计中可能存在的各种错误进行验证。
3. 系统测试主要针对概要设计，检查系统作为一个整体是否可以有效地运行。
4. 验收测试主要是针对需求建模、需求分析，通常由业务专家或者用户进行，以确认产品能真正符合用户业务上的需要。
5. V模型用于需求明确和需求变更不频繁的情形。
6. V模型中突出的是测试和开发生命周期各阶段的结合。

原型模型：

模型模型：第一步是交流、然后创建一个快速原型，能够满足项目干系人与未来的用户之间通过原型进行交互，
再通过与相关干系人进行充分的讨论和分析，最终弄清楚当前系统的需求，进行了充分的了解之后，在原型的基础上开发出用户满意的产品。

原型法认为在很难一下子全面准确地提出用户需求的情况下，原型应当具备的特点如下：

1. 实际可行。
2. 具有最终系统的基本特征。
3. 构造方便、快速、造价低。
4. 它对用户需求是动态的、逐步纳入的。

增量模型

增量模型：增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，它假设可以将需求分段为一系列增量产品，
每一增量可以分别开发。增量之间是需要有优先级的，首先要开发核心模块功能，第一个增量是它的核心，
而后与用户确认后开发下一个增量，优先级高的增量（服务）最先交付。
特点：由于不是从系统整体角度规划各个模块，每一次增量的模块划分可能没有延续性，因此不利于模块划分。
难点在于如何将客户需求划分为多个增量。与原型不同的是增量模型的每一个增量版本都可以作为独立的产品，而原型的构造一般是为了演示。

螺旋模型

1. 是一个演化过程模型，它将原型实现的迭代特征与瀑布模型中控制的和系统化的方面结合起来。
   在螺旋模型中，软件开发是一系列的增量发布。
2. 螺旋模型将瀑布模型和演化模型结合起来，强调了风险分析，特别适用于大型、复杂度高、风险高的系统。
3. 螺旋模型将开发过程分为几个螺旋周期，具有周期性重复的螺旋线状，每个螺旋周期大致和瀑布模型相符合。
   每个螺旋周期分为如下4个工作步骤：制定计划、风险分析、实施工程和客户评估。

喷泉模型

喷泉模型：是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。
使开发过程具有迭代性和无间隙性。
特点

• 喷泉模型的各个阶段没有明显的界限，开发人员可以同步进行。
• 其优点是可以提高软件项目的开发效率，节省开发时间**。
• 由于喷泉模型在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，不利于项目的管理。
  此外，这种模型要求严格管理文档，使得审核的难度加大。

统一过程(UP)模型

是一种用例和风险驱动，以架构为中心，迭代并且增量的开发过程，由UML方法和工具支持。
迭代的意思是将整个软件开发项目划分为许多个小的袖珍项目，每个袖珍项目都包含正常软件项目的
所有元素：计划、分析和设计、构造、集成和测试，以及内部和外部发布。

统一过程模型包含4个阶段：初始阶段、精化阶段、构建阶段、移交阶段。

1. 初始阶段：生命周期目标。
2. 精化阶段：生命周期架构。
3. 构建阶段：初始运作功能。
4. 移交阶段：产品发布。

每次迭代产生包括最终系统部分完成的版本和任何相关的项目文档的基线，通过逐步迭代基线之间相互构建，
直到完成最终系统。在每个迭代中有5个核心工作流：捕获系统应该做什么的需求工作流，精化和结构化需求的分析工作流，
在系统架构内实现需求的设计工作流，构造软件的实现工作流，验证实现是否如期望那样工作的测试工作流。
统一过程的典型代表是RUP（Rational Unified Process）。RUP是UP的商业扩展版，完全兼容UP，但比UP更完整、更详细。

类型	特点
瀑布模型	结构化方法。容易理解、管理成本低、需求明确、文档齐全、风险控制弱
V模型	瀑布模型的变体，开发与测试结合。
原型模型	原型方法。也叫快速原型模型，属于演化模型。适合需求不明确、经常变化的项目
增量模型	瀑布模型和原型模型的结合体。一个增量是核心。如增量不确定管理成本会增加。
螺旋模型	属于演化模型。瀑布模型和原型模型的结合体。适合大型、复杂、有风险的项目。
喷泉模型	面向对象方法。复用好、开发过程无间隙、节省时间。
统一过程UP模型	用例驱动、架构为中心、迭代、增量。

软件需求

软件需求-定义

1. 软件需求：是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。
2. IEEE中定义是：软件需求指用户解决问题或达到目标所需要的条件或能力，是系统或系统部件要满足合同、
   标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。
3. 需求来源：
   • 可以来自于用户（实际的潜在的）、用户的规约、应用领域的专家、相关的技术标准和法规；
   • 可以来自于原有的系统、原有系统的用户、新系统的潜在用户；
   • 甚至还可以来自于竞争对手的产品。

软件需求-分类

软件需求的分类：软件需求就是软件必须完成的事以及必须具备的品质。
需求事多层次的，包括业务需求、用户需求和系统需求，这三者是从目标到具体，从整体到布局，从概念到细节。

1. 业务需求：反映企业或客户对系统高层级的目标要求（高层级需求）
2. 用户需求：描述用户的具体目标，用户想要什么，以及要这些做什么（用户需求）
3. 系统需求：从系统的角度说明软件的需求，包括功能需求、非功能需求、设计约束等
   • 功能需求：是指系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作。
   • 非功能需求：是指产品必须具备的性能或品质，例如，可靠性、容错性等。
   • 设计约束：也称为限制条件、补充规约，通常是对解决方案的一些约束说明，
     例如，某系统必须采用国有自主知识版权的数据库，必须运行在UNIX系统之下，等等。
4. 质量功能部署（Quality Function Deployment,QFD）: 是一种将用户要求转化成软件需求的技术。
   目的是最大限度提升软件工程过程中用户满意度。
5. 质量功能部署也叫质量功能展开是指把用户对产品的需求进行多层次的演绎分析，转化为产品的设计需求、工程部件特征、工艺要求、生产要求。
6. QFD：将软件需求分为三类，分别是
   • 常规需求：系统应该做到的功能或性能，实现的越多，用户越满意。
   • 期望需求：用户想当然人为系统应该做到，但是不能正确表达的功能，没有实现会让用户不满意
   • 意外需求：用户要求范围外的功能或性能，开发人员控制，实现会高兴，不实现也没关系

需求工程

1. 需求工程：是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。
   需求工程可以细分为需求获取、需求分析（包括系统建模）、需求规约、需求验证以及需求管理5个阶段。
   • 需求开发：包括需求获取、需求分析、编写规约（系统规格说明书）和需求验证4个阶段。
   • 需求管理：通常包括定义需求基线、处理需求变更及需求跟踪等方面的工作
2. 需求开发的4个阶段：
   • 在需求开发阶段需要定义产品所期望的用户类型、获取每种用户类型的需求、了解实际的用户任务和目标，以及这些任务所支持的业务需求。
   • 同事还包括分析源于用户的信息、对需求进行优先级分类、将所收集的需求编写称为软件规格说明书和需求分析模型，以及对需求进行评审等工作。

需求获取

1. 需求获取：是一个确定和理解不同的项目干系人的需求和约束的过程。在需求获取的过程中，主要解决需求问题。要想做好需求调查，必须清楚地了解三个问题。

   • What:应该搜集什么信息。
   • Where：从什么地方搜集这些信息。
   • How:用什么机制或技术来搜集这些信息。

2. 常见的需求获取方式有：用户访谈、问卷调查、采样、情节串联版、联合需求计划等

   • 用户访谈：一对一进行访谈，适合于针对有代表性的用户。其形式分为结构化和非结构化两种。
   • 问卷调查：设计问题、制作成用户调查问卷、下发填写、整理分析。适合用户面广、用户需求灵活时间进行回馈
   • 采样：采用统计分析技术，从目标总体中选择出采样本集的过程。可以是随机抽样，也可以是非随机抽样。适合用于大量用户信息或者数据信息采集分析，最终得出需求的场景。
   • 情节串联板：一系列图片，通过这些图片来讲故事。
   • 联合讨论会：通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求。
   • 需求记录技术：任务卡片、场景说明、用户故事等。

需求分析

1. 需求分析：一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性。
   需求分析人员需要把杂乱无章、真假难辨的用户要求和期望转化为真正的用户需求，最终再将用户需求转化为系统需求，形成最终的需求规约（需求规格说明书）。
2. 需求分析：逐步细化所有的软件功能，找出系统各个元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，
   剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型（做什么的模型）。
3. 需求分析的任务：
   • 绘制系统上下文范围关系图
   • 创建用户界面原型
   • 分析需求的可行性
   • 确定需求的优先级
   • 为需求建立模型
   • 创建数据字典
   • 使用QFD（质量功能部署）
4. 目前，已存在的多种需求分析方法引用了不同的分析策略，通常用的分析方法有以下两种：
   • 面向数据流的结构化分析方法（SA）。
   • 面向对象的分析方法（OOA）。
5. 结构化分析方法的特点是：自顶向下、逐步分解、分析的核心是数据字典。
6. 结构化分析应该建立三种模型：数据模型、功能模型、行为模型：
   • 数据模型：通常实体关系（E-R）图描述实体、属性，以及实体间的关系；
   • 功能模型：常用数据流图（DFD data flow diagram），从数据传输加工的角度，用图形符号描述数据在系统间的传递情况；
   • 行为模型：又称状态模型，常用状态转换图（STD state transform diagram）描述系统状态和引起系统状态转换的事件，

     表示系统行为，指出作为特定事件的结果将执行哪些动作

数据流图：是可以分层的，根据层级数据流图分为顶层数据流图、中层数据流图和底层数据流图。
出了顶层数据流图外，其他数据流图从零开始编号。

• 顶层数据流图只含有一个加工表示整个系统；输出数据流和输入数据流为系统的输入数据和输出数据，
  表明系统的范围，以及与外部环境的数据交换关系。
• 中层数据流图是对父层数据流图中某个加工进行细化，而它的某个加工也可以再次细化，
  形成子图；中间层次的多少，一般视系统的复杂程度而定。
• 底层数据流图是指其加工不能再分解的数据流图，其加工称为原子加工。

需求规约

1. 软件需求规约：也叫需求定义、软件需求规格说明书SRS，是需求分析任务的最终产物，通过建立完整的信息描述、

   详细的功能和行为描述、性能需求和设计约束的说明、适合验收标准，给出对目标软件的各种需求。

2. 需求规约作为用户和开发者之间的一个协议，在之后的软件工程各阶段发挥重要的作用。
3. 软件需求规约中通常包含以下内容：
   • 引言。引言陈述软件目标，在基于计算机的系统语境内进行描述。
   • 信息描述。信息描述给出软件必须解决的问题的详细描述，记录信息内容、信息流和信息结构。
   • 功能描述。功能描述用来描述解决问题所需要的每个功能。其中包括为每个功能说明一个处理过程；叙述设计约束；叙述性能特征；用一个或多个图形形象地表述软件的整体结构和软件功能与其他系统元素间的互不影响。
   • 行为描述。行为描述用于描述作为外部事件和内部产生的控制特征的软件操作。
   • 校验标准。检验标准描述检验系统成功的标志，即对系统进行什么样的测试，得到什么样的效果，就表示系统已经成功实现了。检验标准是确认测试的基础。
   • 参考书目。参考书目包含了对所有和该软件相关的文档的引用，其中包括其他的软件工程文档、技术参考文献、厂商文献和标准。
   • 附录。附录包含了规约的补充信息，表格数据、算法的详细描述、图表和其他资料。
4. 需求定义方法：
   • 严格定义也称为预先定义，需求的严格定义建立在以下的基础假设之上；所有需求又能够被预先定义。开发人员与用户之间能够准确而清晰地交流。采用图形（或文字）可以充分体现最终系统。
   • 原型方法，迭代的循环型开发方式，需要注意的问题：并非所有的需求都能在系统开发前准确的说明。项目干系人之间通常都存在交流上的困难，原型提供了克服该困难的一个手段。

     特点：需要实际的、可供用户参与的系统模型。有合适的系统开发环境。反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法。

需求验证

1. 需求验证：也称为需求确认，目的是与用户一起确认需求无误。对需求规约进行评审和测试，包括两个步骤：
   • 需求评审：正式评审和非正式评审。
   • 需求测试：设计概念测试用例。
2. 需求验证作为需求开发阶段工作的复查手段，其目的是要检验需求功能的正确性、完整性、和清晰性，是否能够反映用户的意愿，
   由于需求的变化往往使系统的设计和实现也跟着改变，所以由需求问题引起系统变更的成本比修改设计或代码错误的成本高得多。
   因此，为保证软件需求定义的质量，评审应指定专门的人员负责，并按规程严格进行。出分析人员之外，还要有用户，开发部门的管理者，软件设计、实现、测试人员的参加。
3. 需求验证通过后，要请用户签字确认，作为验收标准之一，此时，这个需求规格说明书就是需求基线，不可以再随意更新，如果需要更改必须走需求变更流程。
4. 需求验证也不可能发现所有的需求问题。在需求验证之后，对遗漏的补充以及对错误理解的更正使不可避免的，因此需要进行需求管理。
5. 需求验证内容：
   • 系统定义的目标是否与用户的要求一致。
   • 系统需求分析阶段提供的文档资料是否齐全；文档中描述是否完整、清晰、准确地反映了用户要求。
   • 被开发项目的数据流与数据结构是否确定且充足。
   • 主要功能是否已包括在规定的软件范围之内，是否都已充分说明。
   • 设计的约束条件或限制条件是否符合实际。
   • 开发的技术风险是什么。
   • 是否详细地制定了检验标准，他们能否对系统定义进行确认。

需求管理

1. 软件需求管理：是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动，对需求工程所有活动的规划和控制。
   换句话说，需求管理就是一种获取、组织并记录系统需求的系统化方案，以及一个**使用户与项目团队对不断变更的系统需求达成并保持一致的过程。

2. 在需求管理中，每个需求被赋予唯一的标识符，一旦标识出需求，就可以为需求建立跟踪表，每个跟踪表标识需求与其他需求或设计文档、代码、测试用例的不同版本间的关系。

   • 特征跟踪表，记录需求如何与产品或系统特征相关联；
   • 来源跟踪表，记录每个需求的来源；
   • 依赖跟踪表，描述需求间如何关联等。

3. 这些跟踪表可以用于需求跟踪。在整个开发过程中，进行需求跟踪的目的是为了建立和维护从用户需求开始到测试之间的一致性与完整性，
   确保所有的实现是以用户需求为基础的，所有的输出符合用户需求，并且全面覆盖了用户需求。

版本控制

版本控制：使项目团队和用户达成共识，定义需求基线。通过了评审的需求规约（需求说明书）就是需求基线，下次如果需求变更需求，就需要按照流程来一步步进行。

需求跟踪

1. 需求跟踪有两种方式：正向跟踪和逆向跟踪。
   • 正向跟踪以用户需求为切入点，检查《需求规约》中的每个需求是否都能在后继工作产品中找到对应点；
     简单来说，就是用户原始需求是否都实现了。
   • 逆向跟踪**检查设计文档、代码、测试用例等工作产品是否都能在《需求规约》中找到出处。简单点说，就是软件实现的是否都是用户需要的
2. 状态跟踪：整个项目过程中，要始终跟踪需求状态即变更情况

系统设计

1. 系统设计的主要目的就是为系统指定蓝图，在各种技术和实施方法中权衡利弊，精心设计，合理地使用各种资源，最终勾画出新系统的详细设计方案。
2. 系统设计的主要内容包括新系统总体结构设计、代码设计、输出设计、输入设计、处理过程设计、数据存储设计、用户界面设计和安全控制设计等。
3. 系统设计方法：
   • 面向数据流的结构化设计方法（SD）。
   • 面向对象的设计方法（OOD）。
4. 系统设计基本原理：抽象化；自顶而下，逐步求精；信息隐蔽；模块独立（高内聚，低耦合）。
5. 系统设计原则：保持模块的大小适中；尽可能减少调用的深度；多扇入、少扇出；单入口、单出口；模块的作用域应在模块之内；功能应该使可预测的。

概要设计

1. 设计软件系统总体结构：
   • 概要设计的基本任务就是软件系统总体结构，是将系统的功能需求分配给软件模块，确定每个模块的功能和调用关系，形成软件的模块结构图，即系统结构图。
   • 其基本任务是采用某种设计方法，将一个复杂的系统按功能划分模块；确定每个模块的功能；确定模块之间的调用关系；确定模块之间的接口，即模块之间传递信息；评价模块结构的质量**。
   • 软件系统总体结构的设计是概要设计关键的一步，直接影响到下一个阶段详细设计与编码的工作。软件系统的质量及一些整体特性都在软件系统总体结构的设计中决定。
2. 数据结构及数据库设计：
   • 数据结构的设计：逐步细化的方法也适用于数据结构的设计。在需求分析阶段，已经通过数据字典对数据的组成、操作约束和数据之间的关系等方面进行了描述，确定了数据的结构特性，
     在概要设计阶段要加以细化，详细设计阶段则规定具体的实现细节。在概要设计阶段，宜使用抽象的数据类型。
   • 数据库的设计：数据库的设计是指数据存储文件的设计，主要进行以下几方面设计。
     • 概念设计：在数据分析的基础上，采用自底向上的方法从用户角度进行视图设计，一般用E-R模型来表述数据模型。E-R模型即是设计数据库的基础，也是设计数据结构的基础。
     • 逻辑设计：E-R模型是独立于数据库管理系统（DBMS）的，要结合具体的DBMS特征来建立数据库的逻辑结构。
     • 物理设计：对于不同的DBMS，物理环境不同，提供的存储结构与存储方法各不相同。物理设计就是设计数据模式的一些物理细节，如数据项存储要求、存取方法和索引的建立等。
3. 编写概要设计文档：文档主要有概要设计说明书、数据库设计说明书、用户手册以及修订测试计划。
4. 评审：对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计方法的可行性，关键的处理及内外部接口定义的正确性、有效性、各部分之间的一致性等都一一进行了评审。

详细设计

详细设计的基本任务：

1. 对每个模块进行详细的算法（逻辑）设计，用某种图形、表格和语言等工具将每个模块处理过程的详细算法描述出来。
2. 对模块内的数据结构进行设计。
3. 对数据库进行物理设计，即确定数据库的物理结构。
4. 其他设计。根据软件系统的类型，还可能要进行以下设计。
   • 代码设计:为了提高数据的输入、分类、存储和检索等操作，节约内存空间，对数据库中某些数据项的值要进行代码设计。
   • 输入/输出格式设计。
   • 用户界面设计。
5. 编写详细设计说明书
6. 评审：对处理过程的算法和数据库的物理结构都要评审。

系统设计的结果是一系列的系统设计文件，这些文件是物理实现一个信息系统（包括硬件设备和编制软件程序）的重要基础。

系统测试

意义和目的

• 系统测试的意义:系统测试是为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试。
• 系统测试的目的:就是希望能以最少的人力和时间发现潜在的各种错误和缺陷
• 信息系统测试应包括软件测试、硬件测试和网络测试。硬件测试、网络测试可以根据具体的性能指标进行，此处所说的测试更多的是指软件测试。
• 系统测试是保证系统质量和可靠性的关键步骤，是对系统开发过程中的系统分析、系统设计和实施的最后复查。根据测试的概念和目的，在进行信息系统测试时应遵循以下基本原则。

原则

根据测试的概念和目的，在进行信息系统测试时应遵循以下基本原则。

1. 应尽早并不断地进行测试。测试不是在应用系统开发完之后才进行的，测试应贯穿在开发的各个阶段，应尽早纠正错误，消除隐患。
2. 测试工作应该避免由原开发软件的人或小组承担，测试工作应由专门人员来进行。
3. 在设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期输出结果
4. 在设计测试用例时，不仅要设计有效、合理的输入条件，也要包含不合理、失效的输入条件。
5. 在测试程序时，不仅要检验程序是否做了该做的事，还要检验程序是否做了不该做的事。
6. 严格按照测试计划来进行，避免测试的随意性。
7. 妥善保存测试计划、测试用例，作为软件文档的组成部分，为维护提供方便。
8. 测试例子都是精心设计出来的，可以为重新测试或追加测试提供方便。

测试过程

1. 制订测试计划。在制订测试计划时，要充分考虑整个项目的开发时间和开发进度以及 一些人为因素和客观条件等使得测试计划是可行的。测试计划的内容主要有测试的内容、进度安排、测试所需的环境和条件、测试培训安排等。
2. 编制测试大纲。测试大纲是测试的依据，它明确、详尽地规定了在测试中针对系统的每一项功能或特性所必须完成的基本测试项目和测试完成的标准。
3. 根据测试大纲设计和生成测试用例，产生测试设计说明文档。其内容主要有被测项目、输入数据、测试过程和预期输出结果等。
4. 实施测试。测试的实施阶段是由一系列的测试周期组成的。在每个测试周期中，测试人员和开发人员将依据预先编制好的测试大纲和准备好的测试用例对被测软件或设备进行完整的测试。
5. 生成测试报告。测试完成后要形成相应的测试报告，主要对测试进行概要说明，列出测试的结论，指出缺陷和错误。5另外，给出一些建议，如可采用的修改方法，各项修改预计的工作量及修改的负责人员。

测试策略

1. 单元测试。单元测试也称为模块测试。单元测试侧重于模块中的内部处理逻辑和数据结构。测试的对象是可独立编译或汇编的程序模块、软件构件或面向对象软件中的类(统称为模块)，测试依据是软件详细设计说明书。

2. 集成测试。目的是检查模块之间，以及模块和已集成的软件之间的接口关系，并验证已集成的软件是否符合设计要求。测试依据是软件概要设计文档。

   • 自顶向下集成测试。自顶向下集成测试是一种构造软件体系结构的增量方法。
   • 自底向上集成测试。自底向上集成测试就是从原子模块(程序结构的最底层构件)开始进行构造和测试。
   • 回归测试。回归测试有助于保证变更不引入无意识行为或额外的错误。回归测试可以手工进行，方法 是重新执行所有测试用例的子集，或者利用捕捉/回放工具自动执行。
   • 冒烟测试。冒烟测试是一种常用的集成测试方法，是时间关键项目的决定性机制，它让软件团队频繁地对项目进行评估。

3. 确认测试。主要用于验证软件的功能、性能和其他特性是否与用户需求一致。根据用户的参与程度，通常包括以下类型:

   • 内部确认测试:主要由软件开发组织内部按照SRS进行测试。
   • a测试:由有代表性的最终用户在开发者的场所进行。用户在开发环境下进行测试，且在受控的环境下进行。
   • B测试:用户在实际使用环境下进行测试，B测试是在不被开发者控制的环境下软件的“现场”应用。接到B测试的问题报告之后，开发人员对软件进行修改，然后准备向最终用户发布软件产品。
     • 客户验收测试:针对需求规约，在交付前以用户为主进行的测试。其测试对象为完整的、集成的计算机系统。验收测试的目的是，在真实的用户工作环境下，检验软件系统是否满足开发技术合同或SRS。
       验收测试的结论是用户确定是否接收该软件的主要依据。除应满足一般测试的准入条件外，在进行验收测试之前，应确认被测软件系统已通过系统测试。

4. 系统测试。测试对象是完整的、集成的计算机系统;测试的目的是在真实系统工作环境下，验证完成的软件配置项是4否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求。测试依据是用户需求或开发合同。主要内容包括:

   • 恢复测试。恢复测试是一种系统测试，通过各种方式强制地让系统发生故障，并验证能否按照要求从故障中恢复过来，并在约定的时间内开始事务处理，而且不对系统造成任何伤害。
   • 安全性测试。安全性测试验证建立在系统内的保护机制是否能够实际保护系统不受非法入侵。
   • 压力测试。压力测试要求以非正常的数量、频率或容量等方式执行系统。
   • 性能测试。性能测试用来测试软件在集成环境中的运行性能。在测试过程中的任何步骤都可以进行性能测试。
   • 部署测试也被称为配置项测试。测试对象是软件配置项。测试目的是检验软件配置项与SRS的一致性。测试的依据是SRS。在此之间，应确认被测软件配置项已通过单元测试和集成测试。

测试方法

1. 软件测试方法分为静态测试和动态测试
   静态测试是指被测试程序不在机器上运行，而是采用人工检测和计算机辅助静态分析的手段对程序进行检测，包括对文档的静态测试和对代码的静态测试。对文档的静态测试主要以检查单的形式进行，而对代码的静态测试，包括桌面检查、代码审查、代码走查的方式。
   使用这种方式能够有效的发现30%-70%的逻辑设计和编码错误。

   • 人工检测。人工检测不依靠计算机而是依靠人工审查程序或评审软件，包括代码检查、静态结构分析和代码质量度量等。
   • 计算机辅助静态分析。利用静态分析工具对被测试程序进行特性分析，从程序中提取一些信息，以便检查程序逻辑的各种缺陷和可疑的程序构造。

2. 动态测试是指通过运行程序发现错误。在对软件产品进行动态测试时可以采用黑盒测试法和白盒测试法。

   • 黑盒测试也称为功能测试，在完全不考虑软件的内部结构和特性的情况下，测试软件的外部特性。常用的黑盒测试技术有等价类划分、边界值分析、错误推测和因果图等。
   • 白盒测试也称为结构测试，根据程序的内部结构和逻辑来设计测试用例，对程序的路径和过程进行测试，检查是否满足设计的需要。白盒测试常用的技术是逻辑覆盖、循环覆盖和基本路径测试。

测试用例设计

常用的黑盒测试技术有等价类划分、边界值分析、错误推测和因果图等。
等价类划分:将程序的输入域划分为若干等价类，然后从每个等价类中选取一个代表性数据作为测试用例。

1. 等价类划分有两种不同的情况:有效等价类和无效等价类。

   • 有效等价类:满足需求的数据集合。
   • 无效等价类:不满足需求的数据集合。

2. 等价类测试用例的设计原则:

   • 设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止;
   • 设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。

3. 边界值分析 将每类的边界值作为测试用例，边界值一般为范围的两端值以及在此范围之外的与此范围间隔最小的两个值。也就是选取正好等于、刚好大于、刚好小于边界的值作为测试数据

   • 上点:边界上的点(正好等于)
   • 离点:距离上点最近的点(刚好大于、刚好小于)
   • 内点:范围内的点(区间范围内的数据)

4. 错误推测:没有固定的方法，凭经验而言，来推测有可能产生问题的地方，作为测试用例进行测试。错误推测法的思想是根据经验列举出可能出现问题的清单，根据清单分享问题可能原因，推测发现缺陷。
   适合的场景:

   • 时间紧任务量大时，根据之前项目类似经验找出易出错的模块重点测试。
   • 时间宽裕通过该方法列出之前出现问题较多的模块再次复测。.

5. 因果图:由一个结果来反推原因的方法，具体结果具体分析，没有固定方法。

---

白盒测试常用的技术是逻辑覆盖、循环覆盖和基本路径测试。

逻辑覆盖:考察用测试数据运行被测程序时对程序逻辑的覆盖程度，主要的逻辑覆盖标准有语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖6种。

1. 语句覆盖。是指选择足够的测试数据，使被测试程序中的每条语句至少执行一次。语句覆盖对程序执行逻辑的覆盖很低，因此一般认为它是很弱的逻辑覆盖。
2. 判定覆盖。是指设计足够的测试用例，使得被测程序中的每个判定表达式条件的真假分支都要覆盖一次，因此判定覆盖也称为分支覆盖。判定覆盖要比语句覆盖更强一些。
3. 条件覆盖。是指构造一组测试用例，使得每一判定语句中每个逻辑条件的各种可能的值至少满足一次。
4. 判定/条件覆盖。是指设计足够的测试用例，使得判定中每个条件的所有可能取值(真/假)至少出现一次，并使每个判定本身的判定结果(真/假)也至少出现一次。
5. 条件组合覆盖。是指设计足够的测试用例，使得每个判定中条件的各种 可能值的组合都至少出现一次。满足条件组合覆盖的测试用例是一定满足判定覆盖、条件覆盖和判定/条件覆盖的。
6. 路径覆盖。是指覆盖被测试程序中所有可能的路径。
7. 循环覆盖:执行足够的测试用例，使得循环中的每个条件都得到验证。
8. 基本路径测试法:是在程序控制流图的基础上通过分析控制流图的环路复杂性，导出基本可执行路径集合，从而设计测试用例。设计出的测试用例要保证在测试中程序的每一条独立路径都执行过，即程序中的每条可执行语句至少执行一次。此外，所有条件语句的真值状态和假值状态都测试过。路径测试的起点是程序控制流图。程序控制流图中的结点代表包含一个或多个无分支的语句序列，边代表控制流

软件维护

系统转换是指:新系统开发完毕，投入运行，取代现有系统的过程，需要考虑多方面的问题，以实现与老系统的交接，有下三种转换计划:

1. 直接转换:就是在确定新系统运行无误时立刻启用新系统，终止旧系统运行，风险很大。这种方式很节省人员、设备费用。一般适用于一些处理过程不太复杂、数据不太重要的场合。
2. 并行转换:是新旧系统并行工作一段时间，经过一段时间的考验以后，新系统正式替代旧系统，风险较小。它的主要特点是安全、可靠，但费用和工作量都很大，因为在相当长的时间内系统要新、旧两套并行工作。对于较复杂的大型系统，它提供了一个与旧系统运行结果进行比较的机会，可以对新旧两个系统的时间要求、出错次数和工作效率给予公正的评价。当然，由于与旧系统并行工作，消除了尚未认识新系统之前的紧张和不安。
3. 分段转换:分期分批逐步转换，是直接和并行转换的集合，将大型系统分为多个子系统，依次试运行每个字系统，成熟一个子系统就转换一个子系统。同样适用于大型项目，只是更耗时，而且现有系统和新系统间混合使用，需要协调好接口等问题。
4. 数据转换与迁移:将数据从旧数据库迁移到新数据库中。有三种方法:系统切换前通过工具迁移、系统切换前采用手工录入、系统切换后通过新系统生成。

---

系统的可维护性可以定义为维护人员理解、改正、改动和改进这个软件的难易程度，可维护性是所有软件都应具有的基本特点，必须在开发阶段和其他软件工程阶段保证软件具有可维护的特点。其评价指标如下:

1. 可理解性。指别人能理解系统的结构、界面、功能和内部过程的难易程度。模块化、详细设计文档、结构化设计和良好的高级程序设计语言等都有助于提高可理解性。
2. 可测试性。诊断和测试的容易程度取决于易理解的程度。为此，开发人员在系统设计和编程阶段就应尽力把程序设计成易诊断和测试的。此外，在进行系统维护时，应该充分利用在系统测试阶段保存下来的测试用例。
3. 可修改性。诊断和测试的容易程度与系统设计所制定的设计原则有直接关系。模块的耦合、内聚、作用范围与控制范围的关系等都对可修改性有影响。

---

系统维护主要包括硬件维护、软件维护和数据维护
软件维护:软件维护主要是指根据需求变化或硬件环境的变化对应用程序进行部分或全部修改，其包含内容如下:

1. 正确性维护:是指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。
2. 适应性维护:是指使应用软件适应信息技术变化和管理需求变化而进行的修改。
3. 完善性维护:是指对已有的软件系统 增加一些在系统分析和设计阶段中没有规定的功能与性能特征。
4. 预防性维护:为了改进应用软件的可靠性和可维护性，为了适应未来的软/硬件环境的变化，应主动增加预防性的新的功能，以使应用系统适应各类变化而不被淘汰。

---

1. 按评价的时间与信息系统所处的阶段的关系又可从总体上把广义的信息系统评价分成立项评价、中期评价和结项评价。
   • 立项评价:指信息系统方案在系统开发前的预评价，即系统规划阶段中的可行性研究。
   • 中期评价:项目开发中期每个阶段的阶段评审，或者项目在开发中途遇到重大变故，评价是否还要继续
   • 结项评价:系统投入正式运行后，了解系统是否达到预期的目的和要求而对系统进行的综合评价。
2. 系统评价的指标
   • 从信息系统的组成部分出发，信息系统是一个由人机共同组成的系统，所以可以按照运行效果和用户需求(人)、系统质量和技术条件(机)这两条线索构造指标。
   • 从信息系统的评价对象出发，对于开发方来说，他们所关心的是系统质量和技术水平; 对于用户方而言，关心的是用户需求和运行质量;系统外部环境则主要通过社会效益指标来反映
   • 从经济学角度出发，分别按系统成本、系统效益和财务指标3条线索建立指标。

软件质量

软件质量：是指反映软件系统或软件产品满足规定或隐含需求的能力的特征和特性全体。
软件质量管理：是指对软件开发过程进行独立的检查活动，由质量保证、质量规划和质量控制3个主要活动构成。
讨论软件质量首先要了解软件的质量特性，目前已经有多种软件质量模型来描述软件质量特性，例如ISO/EC9126软件质量模型和McCall软件质量模型。

各质量特性和质量子特性的含义如下：

1. 功能性：与一组功能及其指定的性质的存在有关的一组属性，是指满足规定或隐含需求的那些功能
   • 适合性：与对规定任务能否提供一组功能以及这组功能是否适合有关的软件属性。
   • 准确性：与能够得到正确或相符的结果或效果有关的软件属性。
   • 互用性：与其他指定系统进行交互操作的能力相关的软件属性。
   • 依从性：与软件服从有关标准、约定、法规及类似规定的软件属性。
   • 安全性：与避免对程序及数据的非授权故意或意外访问的能力有关的软件属性。
2. 可靠性：与**在规定的一段时间内和规定的条件下软件维持在其性能水平有关的能力。
   • 成熟性：与由软件故障引起时效的频率有关的软件属性
   • 容错性：与在软件错误或违反指定接口的情况下维持指定的性能水平的能力有关的软件属性。
   • 易恢复性：与在故障发生后，重新建立其性能水平在恢复直接受影响数据的能力，以及为达到此目的所需的事件和努力有关的软件属性。
3. 易使用性：与为使用所需的努力和由一组规定或隐含的用户对这样使用所做的个别评价有关的一组属性。
   • 易理解性：与用户为理解逻辑概念及其应用所付出的劳动有关的软件属性。
   • 易学性：与用户为学习其应用（例如操作控制、输入、输出）所付出的努力相关的软件属性。
   • 易操作性：与用户为进行操作和操作控制所付出的努力有关的软件属性。
4. 效率：在规定的条件下，与软件的性能水平与所用资源量之间的关系有关的软件属性。
   • 时间特性：与响应和处理时间以及软件执行其功能时的吞吐量有关的软件属性。
   • 资源特性：与软件执行其功能时，所使用的资源量以及使用资源的持续时间有关的软件属性。
5. 可维护性：与进行规定的修改所需要的努力有关的一组属性。
   • 易分析性：与为诊断缺陷或失效原因，或为判定待修改的部分所需努力有关的软件属性。
   • 易改变性：与进行修改、排错或适应环境变换所需努力有关的软件属性。
   • 稳定性：与修改造成未预料效果的风险有关的软件属性。
   • 易测试性：为确认经修改软件所需努力有关的软件属性。
6. 可移植性：与**软件可从某一环境转移到另一环境的能力有关的一组属性。
   • 适应性：与软件转移到不同环境时的处理或手段有关的软件属性。
   • 易安装性：与在指定环境下安装软件所需努力有关的软件属性。
   • 一致性：使软件**服从与可移植性有关的标准或约定的软件属性。
   • 易替换性：与一软件在该软件环境中用来替代指定的其他软件的可能和努力有关的软件属性。

软件容错技术

提高软件质量和可靠性的技术大致可分为两类：

1. 避错技术，即在开发的过程中不让差错潜入软件的技术；
2. 容错技术，即对某些无法避开的差错，使其影响减至最小的技术。

软件容错技术：容错就是软件遇到错误的处理能力，实现容错的手段主要是冗余，冗余是指对于实现系统规定功能是多余的那部分资源，
包括硬件、软件、信息和时间。由于加入了这些资源，有可能使系统的可靠性得到较大的提高，包括四种冗余技术：

1. 结构冗余
2. 信息冗余
3. 时间冗余
4. 冗余附加技术

软件度量

软件度量用于对产品及开发产品的过程进行度量，软件的两种属性：

1. 外部属性：指面向管理者和用户的属性，可直接测量，一般为性能指标，比如成本、效益、开发人员的生成率。
2. 内部属性：指软件产品本身的属性，如可靠性、可维护性等，只能间接测量。

软件度量有两种分类：

1. 第一种分类：是将软件度量分为面向规模的度量、面向功能的度量和面向人的度量；
2. 第二种分类：是将软件度量分为生产率度量、质量度量和技术度量

软件复杂度的度量方法：McCabe度量法，又称环路复杂度，具体的求法为：假设有向图种有向边数为m，节点数为n，
则此有向图的环路复杂度为m - n + 2
注意：m和n代表的含义不能混淆，可以用一个最简单的环路来做特殊记忆此公式，另外，针对一个程序流程图，每一个分支边（连线）就是一条有向边，每一条语句（语句框）就是一个顶点。
还有一种更加简单的算法：封闭空间数量+1或者是判断数+1