10 软件工程

软考高级信息系统项目管理师复习资料。

软件工程

• 定义
  • 将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件。
• 目标
  • 在给定成本、进度的前提下，开发出具有适用性、有效性、可修改性、可靠性、可理解性、可维护性、可重用性、可移植性、可追踪性、可互操作性和满足用户需求的软件产品。追求这些目标有助于提高软件产品的质量和开发效率，减少维护的困难。
    • 原则
      • 适用性
        • 软件在不同的系统约束条件下，使用户需求得到满足的难易程度。
      • 有效性
        • 软件系统能最有效的利用计算机的时间和空间资源。各种软件无不把系统的时/空开销作为衡量软件质量的一项重要技术指标。很多场合，在追求时间有效性和空间有效性时会发生矛盾，这时不得不牺牲时间有效性换取空间有效性或牺牲空间有效性换取时间有效性。时/空折衷是经常采用的技巧。
      • 可修改性
        • 允许对系统进行修改而不增加原系统的复杂性。它支持软件的调试和维护，是一个难以达到的目标。
      • 可靠性
        • 能防止因概念、设计和结构等方面的不完善造成的软件系统失效，具有挽回因操作不当造成软件系统失效的能力。
      • 可理解性
        • 系统具有清晰的结构，能直接反映问题的需求。可理解性有助于控制系统软件复杂性，并支持软件的维护、移植或重用。
      • 可维护性
        • 软件交付使用后，能够对它进行修改，以改正潜伏的错误，改进性能和其它属性，使软件产品适应环境的变化等。软件维护费用在软件开发费用中占有很大的比重。可维护性是软件工程中一项十分重要的目标。
      • 可重用性
        • 把概念或功能相对独立的一个或一组相关模块定义为一个软部件。可组装在系统的任何位置，降低工作量。
      • 可移植性
        • 软件从一个计算机系统或环境搬到另一个计算机系统或环境的难易程度。
      • 可追踪性
        • 根据软件需求对软件设计、程序进行正向追踪，或根据软件设计、程序对软件需求的逆向追踪的能力。
      • 可互操作性
        • 多个软件元素相互通信并协同完成任务的能力。
• 软件生命周期 Software Life Cycle,SLC
  • 是软件的产生直到报废或停止使用的生命周期。
  • 软件生存周期一般划分为： 定义及规划、需求分析、软件设计、程序编码、软件测试、运行维护。
  • 开发过程模型
    • 瀑布模型 Waterfall Model
      • 定义及规划->需求分析->软件设计->程序编码->软件测试->运行维护
    • 迭代式模型
      • 迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。
    • 快速原型模型 Rapid Prototype
      • 快速原型模型的第一步是快速建立一个能反映用户主要需求的软件模型。让用户在计算机上使用它，通过实际操作了解目标系统概貌。开发人员按照用户提出的意见快速地修改原型系统，然后再次请用户试用。一旦用户认为这个原型系统确实能满足他们的需求，开发人员便可据此书写软件需求说明，并根据这份文档开发可以满足用户需求的软件产品。
    • 螺旋模型
      • 螺旋模型包涵了四个方面的活动：制定计划，风险分析，实施工程，客户评估。分别为角坐标系的四个象限，开发过程恰好是一条螺旋线。
• 开始阶段
  • 定义及规划
• 开发阶段
  • 分析阶段
    • 这个阶段生成规格说明文档，说明软件要做什么，而没有说明如何去做。
    • 需求特性
      • 无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性
    • 需求的层次
      • 业务需求 Business requirement
        • 反映企业或客户对系统高层次的目标要求
        • 通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等
      • 用户需求
        • 用户需求使用自然语言和图形，陈述系统被期望向系统用户提供什么服务以及系统运行必须满足约束。
        • 用户需求的读者为客户方管理人员、系统最终用户、客户方工程师、合同管理者、系统架构师。
      • 系统需求
        • 系统需求是对软件系统的功能、服务和运行约束的更详细的描述。
        • 系统需求的读者为系统最终用户、客户方工程师、系统架构师、软件开发者。
        • 功能性需求
          • 陈述对系统应该提供的服务、系统应该如何响应特定的输入、系统在特定的情形中应该如何表现等。
        • 非功能性需求
          • 系统必须具备的属性或品质，可细分为软件质量属性（如：可维护性、效率）和其他非功能属性。
        • 设计约束
          • 限制条件或补充规约，通常是对系统的一些约束说明
          • 例如，必须采用国有自主知识产权的数据库系统，必须运行在UNIX操作系统之下等
    • 质量功能部署，QFD Quality Function Deployment
      • 常规需求
        • 用户认为系统应该做到的功能或性能，实现越多用户会越满意
      • 期望需求
        • 用户想当然认为系统应该做到的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意
      • 意外需求
        • 兴奋需求，是用户要求范围外的功能或性能（但通常软件开发人员很乐意赋予系统的技术特性），实现这些需求用户会很高兴，但不实现也不影响其购买的决策。
    • 需求提出
      • 需求获取
        • 用户访谈（封闭式访谈、开放式访谈）、问卷调查、采样、情节串联板、联合需求计划、人种学调查
    • 需求分析 需求描述
      • 面向过程分析，SA （机构化分析、经典分析）
        • 实现阶段使用过程式语言，分析阶段就使用面向过程分析方法。
        • 核心是数据字典
        • 数据模型
          • 实体关系图，ER图 Entity-relationship model
            • 提供了表示实体类型、属性和联系的方法，用来描述现实世界的概念模型。
            • 实体型(Entity),用矩形表示，矩形框内写明实体名； 属性(Attribute),用椭圆形表示，并用无向边将其与相应的实体连接起来； 联系(Relationship),用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体连接起来，同时在无向边旁标上联系的类型（1 : 1，1 : n或m : n）。
        • 功能模型
          • 数据流图，DFD Data Flow Diagram
            • 从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，
            • • 矩形表示数据源或数据宿（“宿”表示数据的终点）； 圆角矩形表示过程； 末端开口的矩形表示数据存储位置； 箭头表示数据流。
        • 行为模型 （状态模型）
          • 状态图 Statechart Diagram
            • 通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。此外状态转换图还指明了作为特定事件的结果系统将做哪些动作（例如，处理数据）。因此状态转换图提供了行为建模机制。
            • 状态图是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应。
      • 面向对象分析，OOA
        • 实现阶段使用面向对象语言，分析过程就使用面向对象分析
        • 用例图
          • 用例图给出了系统的用户视图，显示了用户与系统间的交互。
          • 系统—矩形—执行功能； 用例—圆角矩形—行动； 动作者是使用系统的某人或某事。
        • 类图
          • 类图(Class diagram)是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。
          • 继承关系
            • • 由子类指向父类。
          • 实现关系
            • • 有实现类指向接口
          • 依赖关系
            • • 由使用者指向被使用者。
              • 如果A指向B，则说明A中使用了B，使用方式包括A类中有B类实例化对象的局部变量。A类中有方法把B类实例化对象当做了参数，A类中有方法调用了B类中的静态方法。
          • 关联关系
            • • 由拥有者指向被拥有者。
                • 如果A指向B，则说明A类中有B类的成员变量。
          • 聚合关系
            • • 由整体指向部分。
              • 如果A指向B，则说明A类中有B类的成员变量，但是与关联关系不同，A类和B类有逻辑关系。A类是整体，B类是部分。A类由B类构成，同时B类即便不在A类中也可以单独存在。
          • 组合关系
            • • 由整体指向部分。
        • 状态图
          • 类图完成之后，就可以为类图中的每个类准备状态图。
      • 统一建模语言，UML Unified Modeling Language
        • 是一种用来进行分析和设计的图形化语言。
        • 结构
          • 构造块
            • 事物 thing
              • 结构事物（structural things）
                • 结构事物在模型中属于最静态的部分，代表概念上或物理上的元素。
                • 七种：类、接口、协作、用例、活动类、构件、节点。
              • 行为事物（behavioral things）
              • 分组事物（grouping things）
              • 注释事物（annotational things）
            • 关系
              • 关联
                • 描述一组对象之间连接的结构关系。
                • 普通关联关系的两个类处于同一层次上
                • 聚合
                  • 聚合关系是整体和个体的关系。
                  • 两个类处于不同的层次，一个是整体，一个是部分。
                  • 整体与部分之间是可分离的，他们可以具有各自的生命周期， 部分可以属于多个整体对象，也可以为多个整体对象共享。
                  • 由整体指向部分。
                • 组合 Composition
                  • 是关联关系的一种，是比聚合关系强的关联关系。
                  • 它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。
                  • (组合关系)是一种强的“拥有”关系，体现了严格的部分和整体的关系，部分和整体的生命周期一致。
                  • 由整体指向部分。
              • 依赖
                • 表现为函数中的参数(use a)，是类与类之间的连接，表示一个类依赖于另一个类的定义，其中一个类的变化将影响另外一个类。
                • 两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。
                • 由使用者指向被使用者。
              • 泛化
                • 表示类与类之间的继承关系、接口与接口之间的继承关系。
                • 一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象。
                • UML图中实现使用一条带有空心三角箭头的实线指向基类。
                • 由子类指向父类。
              • 实现
                • 表示类对接口的实现。
                • 是类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。
                • UML图中实现使用一条带有空心三角箭头的虚线指向接口。
                • 有实现类指向接口
            • 图（diagram），图是多个相互关联的事物的集合。
          • 规则
            • 规则是规则块如何放一起的规定。
          • 公共机制
            • 公共机制是指达到特定目标的公共UML方法，主要包括规格说明（详细说明）、修饰、公共分类（通用划分）和扩展机制四种。
        • 视图
          • 用户视图
            • 用例图
              • 显示用户如何与系统通信。
              • 符号
                • 系统
                  • 矩形框，框外左上角标系统名称。
                • 用例
                  • 圆角矩形。
                • 行动者
                  • 棍状轮廓。不一定是人类。
                • 关系
                  • 行动者到用例间的连线。
          • 结构视图
            • 类图
              • 表明系统的静态结构，显示类的特性和类间的关系。
              • 属性和类型
              • 方法
              • 关联
                • 关联是两个类间的概念上的关系。
                  • 一对一、一对多、多对多、多对一
              • 泛化
                • 泛化基于类间的相似性和差异性来组织类。
                  • 子类继承了它所有的超类的特性（属性和方法），但通常它有自己的一些特性（属性和方法。
          • 行为视图
            • 协作图
              • 显示对象（类的实例）间的关系。
              • 属性和值
              • 方法和操作
              • 链接
                • 对象可以使用链接与其他对象关联。
              • 消息
                • 一个对象可以向另外一个对象发送消息。
            • 状态图
              • 状态图用来表示单个对象在状态上的变化。
              • 符号
                • 状态
                  • 开始状态
                    • 实心圆
                  • 停止状态
                    • 最终状态
                  • 中间状态
                    • 椭圆或圆角矩形
                • 转换
                  • 箭头
                • 决策点
                  • 菱形
              • 事件
                • 引起状态转换的原因。事件名可在箭头线上方标出。
              • 动作
                • 用字符串表示，用来定义另外一个对象和被这个对象调用的条件。
            • 顺序图
              • 显示对象（或行动者）间在一段时间内的交互。
              • 符号
                • 行动者
                  • 棍状轮廓
                • 对象
                  • 即类的实例
                • 生命线
                  • 垂直的实线或虚线，表示顺序图中的一个个体参与者。
                • 激活
                  • 窄的实心矩形，显示一个对象在一个活动中被调用的时间，即非空闲时间。
                • 消息
                  • 带箭头的线，显示对象（行动者）间的交互。
            • 活动图
              • 显示一个复杂操作的分解或一个过程分解成一组简单的操作和过程。
              • 符号
                • 活动
                  • 圆角矩形
                • 转换
                  • 带箭头的线
                • 开始点
                  • 实心圆
                • 终止点
                  • 实心同心圆
                • 决策和融合
                  • 菱形
                • 分叉或连接
                  • 加粗的线
            • 泳道
              • 显示涉及多个对象或行动者。
          • 实现视图
            • 组件图
              • 显示软件的组成部分（组件）和它们之间的依赖关系。
              • 符号
                • 组件用左边带有两个小矩形的矩形来表示。
                • 组件的依赖用末端有箭头的虚线来表示。
            • 配置图
              • 显示通信链接的各个节点。
              • 符号
                • 节点用立方体来表示。
                • 通信联合用两个节点间的连线表示。
      • 软件规格说明书SRS (Software Requirements Specification)
        • 软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解， 使之成为整个开发工作的基础。
        • 包含硬件、功能、性能、输入输出、接口需求、警示信息、保密安全、数据与数据库、文档和法规的要求等等。
        • 内容
          • 范围、引用文件、需求、合格性规定、需求可追踪性、尚未解决的问题、注解、附录。
        • 需求验证内容
          • 正确性检查
            • 检查需求是否反映了系统用户的真是需求。
          • 一致性检查
            • 文档中的需求不应该冲突。
          • 完整性检查
            • 需求文档中的需求应当定义系统用户想要的所有功能以及约束。
          • 现实性检查
            • 确保需求可以在系统预算范围内实现。
          • 可验证性检查
            • 需求为继续进行系统设计、实现和测试提供了足够的基础。
    • 需求评审
      • 需求评审
        • 请一个评审团队系统性地分析需求，检查错误和不一致性。
      • 技术评审？？？
        • 原型化方法，开发一个可执行的系统模型，并与最终用户和客户一起使用该模型，来确认其是否满足他们的需要和期望。
      • 需求测试
        • 测试用例生成
  • 设计阶段
    • 定义系统如何完成在分析阶段所定义的需求。
    • 软件架构
      • 定义
        • 软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用（连接件），指导构件集成的模式以及这些模式的约束组成。
      • 作用
        • 软件架构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构件之间的对应关系，提供了一些设计决策的基本原理。
      • 风格
        • 数据流风格
          • 数据流风格包括批处理序列和管道/过滤器两种风格。
        • 调用／返回风格
          • 调用/返回风格包括主程序/子程序、数据抽象和面向对象，及层次结构。
        • 独立构件风格
          • 独立构件风格包括进程通信和事件驱动的系统。
        • 虚拟机风格
          • 虚拟机风格包括解释器和基于规则的系统。
        • 仓库风格
          • 仓库风格包括数据库系统、黑板系统和超文本系统。
      • 敏感点和权衡点
        • 敏感点
          • 一个或多个构件（和/或构件之间的关系）的特性。
        • 权衡点
          • 影响多个质量属性的特性，是多个质量属性的敏感点。
      • 评估
        • 基于调查问卷的方式
        • 基于场景的方式
        • 基于度量的方式
    • 软件设计
      • 方法
        • 面向过程设计 （结构化设计，SD）
          • 依据
            • 以SRS和SA阶段产生的DFD和数据字典等文档为基础。
          • 基本思想
            • 将软件设计成由相对独立且具有单一功能的模块组成的结构。
          • 阶段
            • 概要设计 总体结构设计
              • 将系统的功能需求分配给软件模块，确定每个模块的功能和调用关系，形成软件的模块结构图，即系统结构图。
            • 详细设计
              • 在概要设计中，将系统开发的总任务分解成许多个基本的、具体的任务，而为每个具体任务选择适当的技术手段和处理方法的过程称为详细设计。
          • 结构图
            • 模块符号
            • 阅读方法
              • 从上到下，从左到右。
          • 模块化
            • 耦合
              • 两个模块互相绑定紧密程度的度量。
              • 软件系统中模块间的耦合必须最小化。
              • 原因
                • 低耦合的模块有利于重用；
                • 低耦合的模块不容易在相关模块中产生错误；
                • 当系统需要修改时，低耦合的模块允许我们只修改需要改变的模块，而不会影响到不需要改变的模块。
            • 内聚
              • 内聚是程序中处理过程相关紧密程度的度量。
              • 软件系统模块间的内聚必须最大化。
          • 原则
            • 高内聚、低耦合。
        • 面向对象设计，OOD
          • 在面向对象设计中，设计阶段通过详细描述类的细节来继续。
          • 类由一组变量（属性）和一组方法组成。面向对象设计阶段列出这些属性和方法的细节。
          • 基本思想
            • 抽象、分装、可扩展。
          • 原则
            • 单一职责原则
              • 设计功能单一的类。本原则与结构化方法的高内聚原则是一致的。
            • 开放一封闭原则
              • 对扩展开放，对修改封闭。
            • 李氏（Liskov）替换原则
              • 子类可以替换父类。
            • 依赖倒置原则
              • 要依赖于抽象，而不是具体实现；针对接口编程，不要针对实现编程。
            • 接口隔离原则
              • 使用多个专门的接口比使用单一的总接口好。
            • 组合重用原则
              • 要尽量使用组合，而不是继承关系达到重用目的。
            • 迪米特（Demeter）原则（最少知识法则）
              • 一个对象应当对其他对象有尽可能少的了解。本原则与结构化方法的低耦合原则是一致的。
      • 设计模式
        • 创建型模式
          • 主要用于创建对象，包括工厂方法模式、抽象工厂模式、原型模式、单例模式和建造者模式等；
        • 结构型模式
          • 主要用于处理类或对象的组合，包括适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式和代理模式等；
        • 行为型模式
          • 主要用于描述类或对象的交互以及职责的分配，包括职责链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式等。
  • 实现阶段
    • 过程管理
      • 阶段式模型
        • 成熟度等级
          • 当组织通过了某一等级过程域中的全部过程，即意味着改组织的成熟度达到了这一等级。
          • 可管理级
            • 需求管理、项目计划、配置管理、项目监督与控制、供应商合同管理、度量和分析、过程和产品质量保证
          • 已定义级
            • 需求开发、技术解决方案、产品集成、验证、确认、组织级过程焦点、组织级过程定义、组织级培训、集成项目管理、风险管理、集成化的团队、决策分析和解决方案、组织级集成环境
          • 量化管理级
            • 组织级过程性能、定量项目管理
          • 优化管理级
            • 组织级改革与实施、因果分析和解决方案
      • 连续式模型
        • 成熟度等级
          • 过程管理
            • 组织级过程焦点、组织级过程定义、组织级培训、组织级过程性能、组织级改革与实施
          • 项目管理
            • 项目计划、项目监督与控制、供应商合同管理、集成项目管理、风险管理、集成化的团队、定量项目管理
          • 工程
            • 需求管理、需求开发、技术解决方案、产品集成、验证、确认
          • 支持
            • 配置管理、度量和分析、过程和产品质量保证、决策分析和解决方案、组织级集成环境、因果分析和解决方案
    • 软件质量
      • 软件质量因素
        • 可操作性
          • 准确性
          • 高效性
          • 可靠性
          • 安全性
          • 及时性
          • 适用性
        • 可维护性
          • 可变性
          • 可修正性
          • 适应型
          • 可测试性
        • 可迁移性
          • 重用性
          • 互用性
          • 可移植性
  • 测试阶段
    • 测试的方法
      • 静态测试
        • 桌前检查（Desk Checking）
        • 代码走查
        • 代码审查
      • 动态测试
        • 白盒测试 （结构测试）
          • 基本路径测试
            • 一种软件中每条语句至少被执行一次的方法。
          • 控制结构测试
            • 条件测试
              • 用来检查是否所有的条件都被正确设置。
            • 数据流测试
              • 基于通过模块的数据流。
            • 循环测试
              • 使用测试用例检查循环的正确性。
        • 黑盒测试 （功能测试）
          • 穷尽测试
            • 用输入域中的所有可能的值去测试软件。
          • 随机测试
            • 选择输入域的值的子集来测试。
          • 边界值测试
    • 测试的类型
      • 单元测试
        • 也称为模块测试，测试的对象是可独立编译或汇编的程序模块、软件构件或OO软件中的类。
        • 目的
          • 检查每个模块能否正确地实现设计说明中的功能、性能、结构和其他设计约束等条件，发现模块内可能存在的差错。
        • 依据
          • 软件详细设计说明书
      • 集成测试
        • 目的
          • 检查模块之间，以及模块和已集成的软件之间的接口关系，并验证已集成的软件是否符合设计要求。
        • 依据
          • 软件概要设计文档
      • 确认测试
        • 内部测试
          • 软件开发组织内部按照系统需求规格说明（SRS）进行测试。
        • Alpha测试
          • 由用户在开发环境下进行测试。
        • Beta测试
          • 由用户在实际使用环境下进行测试。
        • 验收测试
          • 针对SRS，在交付前以用户为主进行的测试。
          • 测试对象
            • 是完整的、集成的计算机系统。
          • 目的
            • 在真实的用户工作环境下，检验软件系统是否满足开发技术合同或SRS。
      • 系统测试
        • 测试对象
          • 是完整的、集成的计算机系统。
        • 目的
          • 在真实的用户工作环境下，验证完整的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求。
        • 依据
          • 用户需求或开发合同。
        • 内容
          • 功能测试
            • 一般采用黑盒测试
          • 健壮性测试
          • 性能测试
            • 响应时间、吞吐量、并发用户数、资源利用率
          • 用户界面测试
          • 安全性测试
          • 安装与反安装测试
      • 配置项测试
        • 测试对象
          • 软件配置项
        • 目的
          • 检验软件配置项与SRS的一致性。
        • 依据
          • SRS、接口需求规格说明书
      • 回归测试
        • 目的
          • 测试软件变更之后，变更部分的正确性和对变更需求的符合性，以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。
        • 测试对象
          • 未通过单元测试的软件，在变更之后，应对其进行单元测试。
          • 未通过配置项测试的软件，在变更之后，首先应对变更的软件单元进行测试，然后再进行相关的集成测试和配置项测试。
          • 为通过系统测试的软件，在变更之后，首先对变更的软件单元进行测试，然后再进行相关的集成测试、配置项测试和系统测试。
          • 因其他原因进行变更之后的软件单元，也首先应对变更的软件单元进行测试，然后再进行相关的软件测试。
    • 软件调试
      • 错误的性质
        • 错误的外部征兆远离引起错误的内部原因，对于高度耦合的程序结构，此类现象更为严重。
        • 纠正一个错误造成了另一个错误现象（暂时）的消失。
        • 某些错误征兆只是假象。
        • 因操作人员一时疏忽造成的某些错误征兆不易追踪。
        • 错误是由于分时而不是程序引起的。
        • 输入条件难以精确地再构造（例如，某些实时应用的输入次序不确定）。
        • 错误征兆时有时无，此现象对嵌入式系统尤其普遍。
        • 错误是由于把任务分布在若干台不同处理机上运行而造成的。
      • 软件调试策略
        • 蛮力法
        • 回溯法
        • 原因排除法
      • 软件调试与测试的区别
        • 测试的目的是找出存在的错误，而调试的目的是定位错误并修改程序以修正错误。
        • 调试是测试之后的活动，测试和调试在目标、方法和思路上都有所不同。
        • 测试从一个己知的条件开始，使用预先定义的过程，有预知的结果；调试从一个未知的条件开始，结束的过程不可预计。
        • 测试过程可以事先设计，进度可以事先确定；调试不能描述过程或持续时间。
    • 软件测试管理
      • 过程管理
        • 过程管理包括测试活动管理和测试资源管理。
        • 软件测试应由相对独立的人员进行。根据软件项目的规模、完整性级别和测试类别，软件测试可由不同机构组织实施。
        • 软件测试人员
          • 项目负责人
          • 测试分析员
          • 测试设计员
          • 测试程序员
          • 测试员
          • 测试系统管理员
          • 配置管理员
        • 前期工作
          • 测试合同（或项目计划）
          • 软件测试所需各种文档
          • 被测软件已受控
          • 软件源代码已正确通过编译或汇编
        • 完成条件
          • 已按合同或项目计划完成测试任务
          • 子主题
      • 配置管理
        • 应按照软件配置管理的要求，将测试过程中产生的各种工作产品纳入配置管理。
        • 由开发组织实施的软件测试，应将测试工作产品纳入软件项目的配置管理。
        • 由独立测试组织实施的软件测试，应建立配置管理库，将被测试对象和测试工作产品纳入配置管理。
      • 评审
        • 测试就绪评审
          • 测试就绪评审是指在测试执行前对测试计划和测试说明等进行评审，评审测试计划的合理性和测试用例的正确性、完整性和覆盖充分性，以及测试组织、测试环境和设备、工具是否齐全并符合技术要求等；
        • 测试评审
          • 测试评审是指在测试完成后，评审测试过程和测试结果的有效性，确定是否达到测试目的，主要对测试记录和测试报告进行评审。
• 运行维护阶段
  • 软件维护
    • 从性质上分
      • 纠错型维护
        • 纠正在开发阶段产生而在测试和验收过程没有发现的错误。
        • 错误主要包括
          • 设计错误
          • 程序错误
          • 数据错误
          • 文档错误
      • 适应型维护
        • 为适应软件运行环境改变而作的修改。
        • 环境改变主要包括
          • 影响系统的规则或规律的变化；
          • 硬件配置的变化，如机型、终端、外部设备的改变等；
          • 数据格式或文件结构的改变；
          • 软件支持环境的改变，如操作系统、编译器或实用程序的变化等。
      • 完善型维护
        • 完善性维护为扩充功能或改善性能而进行的修改。修改方式有插入、删除、扩充和增强等。
        • 主要包括
          • 为扩充和增强功能而做的修改，如扩充解题范围和算法优化等；
          • 为改善性能而作的修改，如提高运行速度、节省存储空间等；
          • 为便于维护而做的修改，如为了改进易读性而增加一些注释等。
      • 预防型维护
        • 将潜在的漏洞在发生之前就进行修复。
• 企业应用集成，EAI Enterprise Application Integration
  • 企业应用集成技术可以消除信息孤岛，它将多个企业信息系统连接起来，实现无缝集成，使它们就像一个整体一样。
  • EAI所连接的应用包括各种电子商务系统、ERP、CRM、SCM、OA、数据库系统和数据仓库等。
  • 表示集成
    • 表示集成也称为界面集成，这是比较原始和最浅层次的集成，但又是常用的集成。
    • 这种方法将用户界面作为公共的集成点，把原有零散的系统界面集中在一个新的界面中。
    • 表示集成是黑盒集成，无须了解程序与数据库的内部构造。
    • 常用的集成技术
      • 屏幕截取
      • 输入模拟技术
    • 适用情况
      • 以现有的基于终端的应用系统上配置基于PC的用户界面。
      • 为用户提供一个看上去统一，但是由多个系统组成的应用系统。
      • 当只有可能在显示界面上实现集成时。
  • 数据集成
    • 为了完成控制集成和业务流程集成，必须首先解决数据和数据库的集成问题。
    • 在集成之前，必须首先对数据进行标识并编成目录，另外还要确定元数据模型，保证数据在数据库系统中分布和共享。
    • 数据集成是白盒集成。
    • 中间件工具
      • 批量文件传输，即以特定的或是预定的方式在原有系统和新开发的应用系统之间进行文件传输；
      • 用于访问不同类型数据库系统的ODBC(Open DataBase Connectivity,开放数据库互连）标准接口；
      • 向分布式数据库提供连接的数据库访问中间件技术。
    • 适用情况
      • 需要对多种信息源产生的数据进行综合分析和决策。
      • 要处理一些多个应用喜人需要访问的公用信息库。
      • 当需要从某数据源获得数据来更新另一个数据源时，特别是它们之间的数据格式不相同时。
  • 控制集成
    • 控制集成也称为功能集成或应用集成，是在业务逻辑层上对应用系统进行集成的。
    • 控制集成的集成点存于程序代码中，集成处可能只需简单使用公开的AP1（Application Programming Interface,应用程序编程接口）就可以访问，当然也可能需要添加附加的代码来实现。
    • 控制集成是黑盒集成。
    • 实现方法
      • 远程过程调用或远程方法调用
      • 面向消息的中间件
      • 分布式对象技术
      • 事务处理监控器
    • 控制集成与表示集成、数据集成相比，灵活性更高。表示集成和数据集成适用的环境下，都适用于控制集成。由于控制集成是在业务逻辑层进行的，其复杂度更高一些。
  • 业务流程集成
    • 业务流程集成也称为过程集成，由一系列基于标准的、统一数据格式的工作流组成。
    • 当进行业务流程集成时，企业必须对各种业务信息的交换进行定义、授权和管理，以便改进操作、减少成本、提高响应速度。
    • 业务流程集成不仅要提供底层应用支撑系统之间的互连，同时要实现存在于企业内部的应用之间，本企业和其他合作伙伴之间的端到端的业务流程的管理，它包括应用集成、B2B集成、自动化业务流程管理、人工流程管理、企业门户，以及对所有应用系统和流程的管理和监控等。
  • 企业之间的应用集成
    • EAI技术可以适用于大多数要实施电子商务的企业，以及企业之间的应用集成。
    • EAI使得应用集成架构里的客户和业务伙伴，都可以通过集成供应链内的所有应用和数据库实现信息共享。也就是说，能够使企业充分利用外部资源。
    • 例如，一些企业的SCM系统可能包括交易系统，EAI技术可以首先在交易双方之间创建连接，然后再共享数据和业务过程；企业要顺利开展电子商务，可以利用EAI技术，使企业的信息系统与合作伙伴的信息系统之间能够实现无缝而及时的通信。
• 文档
  • 用户文档
    • 告诉用户如何一步一步使用软件包。
  • 系统文档
    • 系统文档定义软件本身。撰写系统文档的目的是为了让原始开发人员之外的人能够维护和修改软件包。
    • 在分析阶段收集的信息应仔细地用文档记录。
    • 在设计阶段，最终版本用到的工具必须记录在文档中。
  • 技术文档
    • 描述软件系统的安装和服务。安装文档描述软件如何安装在每台计算机上，如服务器和客户端。服务文档描述了系统如何维护和更新。
• 软件度量
  • 项目度量
  • 产品度量
  • 过程度量