第一章 信息化和信息系统 —需求、测试、集成

第一章 信息化和信息系统 —需求、测试、集成

需求概述：

软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。根据IEEE的软件工程标准词汇表，软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。 

1、需求层次（掌握） -P36

简单的说，软件需求就是系统必须完成的事以及必须具备的品质。

需求是多层次的，包括业务需求、用户需求和系统需求。这三个不同层次从目标到具体，从整体到局部，从概念到细节。

（1）业务需求：业务需求是指反映企业或客户对系统高层次的目标要求。通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。

（2）用户需求：用户描述的具体目标、或用户要求系统必须完成的任务，用户需求描述了用户让系统来做什么。

（3）系统需求：是指从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。

功能需求：也称行为需求，它规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要。

非功能需求：是指系统必须具备的属性或品质，又可细分为软件质量属性和（例如：可维护性、效率等）和其他非功能需求。

设计约束：也称为限制条件或补充规约；，通常是对系统的一些约束说明，例如必须采用国有自主知识产权的数据库系统，必须运行在UN IX操作系统之上等。

2、质量功能部署-QFD（了解）-P36

定义：质量功能部署（Quakity Function Deployment，QFD）是一种将客户需求转化成软件需求的技术，其目的是最大限度的提升软件工程过程中用户的满意度。为了达到这个目标，QFD将软件需求分为三大类：常规需求、期望需求和意外需求。

（1）常规需求：用户认为系统应该做到的功能或性能，实现越多用户会越满意。

（2）期望需求：用户想当然认为系统应该具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让客户感到不满。

（3）意外需求：意外需求也称兴奋需求，是用户要求范围外的功能或性能。

3、需求获取（了解）-P37

常见的需求获取方法包括：用户访谈、问卷调查、采样、情节串联版、联合需求计划等。

一个好的需求应该具有：无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户需求和期望转换为用户需求，这就是需求分析的工作。

4、SA方法进行需求分析（掌握）-P37

结构化分析SA方法进行需求分析，其建立的模型的核心是数据字典。

围绕这个核心有三个层次的模型：

（1）数据模型：一般使用实体联系图（E-R图）表示数据模型；E-R图描述实体、属性、以及实体之间的关系。

（2）功能模型：一般使用数据流图（DFD）表示功能模型；DFD从数据传递和加工的角度，利用图形符号通过逐层细分描述系统内各个部件的功能和数据在他们之间传递的情况，聊说明系统完成的功能。

（3）行为模型：一般使用状态转换图（STD）表示行为模型；STD通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为，指出作为特定事件的结果将执行哪些动作（例如：处理数据等。）

 

5、OOA方法（掌握）-P37

OOA的基本任务是运用OO的方法，对问题域进行分解和理解，正确认识其中的事物以及他们之间形成的各种联系，最终产生一个符合用户需求，并能直接反应问题域和系统功能的OOA模型和其详细说明。OOA 模型包括用例模型和分析模型；

用例模型：一种描述系统需求的方法，使用用例的方法描述系统需求的过程就是用例模型

分析模型：是描述系统的基本逻辑结构，展示对象和类如何组成系统（静态模型），以及它们如何保持通信，实现系统行为（动态模型）

6、需求规格说明书-SRS（掌握）-P37

软件需求规格说明书（SRS）是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。

SRS应该包括以下8个内容：

（1）范围：

本部分包括SRS适用的系统和软件的完整标识，包括标识号、标题、缩略词、版本号和发行号；简述SRS适用的软件系统和软件的用途，描述系统和软件的一般特性；概述系统开发、运维和维护的历史；标识项目的投资方、需方、用户承建方和支持机构；标识当前和计划的运行现场；列出其他有关的文档概述SRS的用途和内容，并描述与其使用有关的保密性和私密性的要求；说明编写SRS所依据的基线。

（2）引用文件：

列出SRS中引用的所有文档的编号、标题、修订版本和日期，还应标识不能通过正常的供货渠道获得的所有文档的来源。

（3）需求：这一部分是SRS的主体部分；详细描述软件需求。

（4）合格性规定：

定义一组合格性的方法，对于（3）部分中的每个需求，指定所使用的方法，以确保需求得到满足。

（5）需求可追踪性：

这一部分包括从SRS中每个软件配置想的需求到其设计的系统（或子系统）需求的双向可追踪性。

（6）尚未解决的问题：如果有必要，可以在这一部分说明软件需求中的尚未解决的遗留问题。

（7）注解：包含有助于理解SRS的一般信息，例如：北京信息、词汇表、原理等。

（8）附录：提供那些为便于维护SRS而单独编排的信息；

7、需求验证（了解）-P38

需求验证也称为需求确认，其活动是为了确认以下几个方面的内容：

（1）SRS正确描述了预期的、满足项目干系人需求的系统行为与特征。

（2）SRS中的软件需求是从系统需求、业务规格和其他来源中正确的推到而来。

（3）需求是完整和高质量的。

（4）需求为继续进行系统设计、实现和测试提供了足够的基础。

在实际工作中，一般通过需求评审和需求测试工作来对需求进行验证。需求评审就是对SRS的技术评审。

 

8、UML（掌握）-P39

（1）UML是一种定义良好、易于表达、功能强大且普遍使用的建模语言。从整体来看，UML的结构包括造块、规则和公共机制三个主要部分。

（2）UML用关系把事物集合在一起，主要有四个关系：-P40

①依赖：一个事物发生改变会影响到另一个事物的语义。

②关联：关联描述一组对象之间连接的结构关系。

  ③泛化：泛化是一般化和特殊化的关系，描述特殊元素的对象可替换的一般元素的对象；（类与类之间的继承）

④实现：实现是类与类之间的语义定义关系，其中一个类指定了由另一个类保证执行的契约。

9、UML2.0中的14种图（掌握）-P40

（1）类图：类图描述一组类、接口、协作和他们之间的关系。类图给出系统静态设计视图；活动类的类图给出系统的静态进程视图。

（2）对象图：对象图描述一组对象及他们之间的关系

（3）构件图：描述了一个封装的类和它的接口、端口以及由内嵌的结构和连接件构成的内部结构。

（4）组合结构图：组合结构图描述结构化类(例如：构件或类)的内部结构，包括结构化类与系统其余部分的交互点。

（5）用例图：用例图描述了一组用例、参与者及它们之间的关系。

（6）顺序图（序列图）：顺序图是一种交互图，交互图展示了一种交互，它由一组对象或者参与者以及它们之间可能发送的消息构成。交互图关注于系统的动态视图。顺序图是强调消息的时间次序的交互图。

（7）通信图：通信图也是一种交互图，它强调接收发消息的对象或者参与者的结构组织。顺序图强调的时序，通讯图强调的对象之间的组织机构关系。

（8）定时图（计时图）：定时图也是一种交互图，它强调消息跨越不同对象或者参与者的实际时间，而不仅仅只是关注消息的相对顺序。

（9）状态图：状态图描述一个状态机，它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。

（10）活动图：活动图讲进程或其他计算机结构展示为计算机内部一步步的控制流程和数据流。活动图专注于系统的动态视图，它强调对象间的控制流程。

（11）部署图：部署图描述对运行时的处理节点及在其中生存的构件配置。部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部署图。

（12）制品图：制品图描述计算机中一个系统的物理结构，制品包括文件、数据库和类似的物理比特集合。制品图通常和部署图一起使用。制品图也给出了他们实现的类和构件。

（13）包图：包图描述由模型本身分解而成的组织单元，以及它们之间的依赖关系。

（14）交互概览图：交互概览图时交互图和顺序图的混合物。

 

10、UML视图（掌握）-P41

UML对系统架构的定义时系统的组织结构，包括系统分解的组成部分，以及他们的关联性、交互机制和指导原则等提供系统设计的信息。具体来说，就是指以下5个系统视图。

（1）逻辑视图：又称设计视图，它表示设计模型种在架构方面具有重要意义的部分，即类、子系统、包和用力实现的子集。

（2）进程视图：进程视图时可执行线程与进程作为活动类的建模，他是逻辑视图的一次执行实例，描述了并发与同步结构。

（3）实现视图：实现视图对组件基于系统的物理代码的文件和构件进行建模。

（4）部署视图：部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。

（5）用例视图：用例视图是最基本的需求分析模型。

11、OOA和OOD（了解）-P42

OOA：Object-Oriented Analysis（面向对象分析方法）

OOD：Object-Oriented Design（面向对象设计）

OOA模型独立于具体实现，即不考虑具体实现有关的因素，这也是OOA与OOD的区别所在；

OOA的任务是：做什么；

OOD的任务是：怎么做；

面对对象分析阶段的核心工作是建立系统用例模型与分析模型。

12、软件架构设计-P44

12.1、软件架构风格（掌握）  【比较容易考】-P45

解决好软件的复用、质量和维护问题，是研究软件架构的根本目的。软件架构设计的一个核心问题是能否达到架构级别的软件复用，这一活动中，评估人员关注的是系统质量属性（考点）。

软件架构风格：

（1）数据流风格：包括批处理序列（顺序执行）和管道/过滤（输入输出数据流）两种风格；

（2）调用/返回风格：包括主程序/子程序、数据抽象和面向对象（对象封装），以及层次结构（分层调用）。

（3）独立构件风格：包括进程通信（消息传递、远程调用）和事件驱动（事件触发调用）的系统

（4）虚拟机风格：包括解释器（解释引擎）和基于规则（规则集）的系统。

（5）仓库风格：包括数据库系统（中央共享数据源）、黑板系统（知识源、黑板及共享数据和控制）和超文本系统（非线性交叉引用）。

12.2软件架构评估（了解） -P45

敏感点：是一个或多个构件的特性；

权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点。

从目前已有的软件架构评估技术来看，可以归纳为三类主要的评估方式，分别是基于问卷（或检查表）的方式、基于场景的方式和基于度量的方式。

基于场景的评估方式最为常用。

基于场景的方式主要包括：架构权衡分析法（ATAM）、软件架构分析法（SAAM）、成本效益分析法（CBAM）。在软件评估中，一般采用刺激、环境和影响三方面来对场景进行描述。

刺激是场景分析中解释或描述项目干系人怎么引发与系统的交互部分；

环境描述的时刺激发生时的情况；

响应是指系统如何通过架构对刺激做出反应的。

12.3、软件设计（掌握）  -P46

（1）软件设计分为结构化设计和面向对象设计。

（2）结构化设计SD是一种面向数据流的方法，它以SRS（需求规格说明书）和SA（结构化分析）阶段所产生的DFD（数据流图）和数据字段等文档为基础，是一个自顶向下、逐步求精和模块化的过程。SD分为概要设计和详细设计两个阶段。

（3）在SD中，需要遵循一个基本原则：高内聚，低耦合，模块内部高度内聚，模块与模块之间要降低耦合度。

（4）面向对象设计OOD的基本思想包括抽象、封装、可扩展性，其中可扩展性主要是通过继承和多态来实现，三大特征是封装、继承、多态。

12.3软件工程的过程管理（了解） -P48

（1）阶段式模型：阶段式模型基本沿袭CMM模型架构，仍保持4个成熟等级，但关键过程域做了一些调整和扩充。

考点：给出过程域，让选择是哪个成熟度等级

  （2）连续式模型：与阶段式模型相比，连续式模型没有与组织成熟度相关的几个阶段。连续式模型将24个过程域按照功能划分你为过程管理、项目管理、工程管理、工程和支持四个过程组。

考点：给出过程域，让选择是哪个连续式分组

这两种方法各有优缺点，均采用统一的24个子过程域，他们在逻辑上是等价的，对统一组织采用阶段式模型和连续式模型分别进行CMMI评估，得到的结论应该是相同的（考点）。

12.4 软件测试（掌握）-P49【考过案例分析】

（1）每个测试用例包括名称和标识、测试追踪、用例说明、测试的初始化要求、测试的输入、期望的测试结果、评价测试结果的标准、操作过程、前提和约束、测试终止条件。

（2）软件测试方法可分为静态测试和动态测试

静态测试：指被测试程序不在机器上运行，而是采用人工检查和计算机辅助静态分析的手段对程序进行检测；静态测试包括对文档的静态测试和对代码的静态测试，对文档的静态测试主要是以检查单的形式进行，而对代码的静态测试一般采用桌前检查（看）、代码走查（脑子里过一遍）和代码审查（互查）；

动态测试：是指在计算机上实际运行程序进行软件测试。一般采用白盒测试和黑盒测试方法

①白盒测试：

白盒测试也称为结构化测试，主要用于软件单元测试中。它的主要思想是，将程序看作成一个透明的白盒，测试人员完全清除程序的结构和算法，按照程序内部逻辑结构设计测试用例，

白盒测试方法主要有：控制流程测试、数据流测试、程序编译测试等；另外：静态测试的方法也可以实现白盒测试；例如，使用人工检查代码的方法来检查代码的逻辑问题，也属于白盒测试。白盒测试方法中，最常用的技术是逻辑覆盖，即使用测试数据运行被测试程序，考察对程逻辑的覆盖程度。主要覆盖标准有：语句覆盖、判定覆盖、条件覆盖、条件/判断覆盖、条件组合覆盖、修正的条件/判定覆盖、路径覆盖等

 

②黑盒测试：

黑盒测试也称功能测试，主要用于集成测试、确认测试、系统测试中；黑盒测试将测试看成一个不透明的黑盒，完全不考虑（或了解）程序的内部结构和处理算法。一般包括等价类划分、边界值分析、判定表、因果图、状态图、随机测试、猜错法和正交试验法等。

 

（3）软件测试分类：

①单元测试：

单元测试也称模块测试，测试的对象是可独立编译或汇编的程序模块、软件架构或OO软件中的类（统称为模块），目的是检查每个模块能否正常实现设计说明在的功能、性能、接口和其他设计约束等条件。

②集成测试：集成测试的目的是检查模块之间，以及模块和已集成的软件之间接口关系。

③确认测试：

确认测试主要用于验证软件功能、性能和其他特性是否与用户需求一致。根据用户的参与程度，分为：

内部测试：Alpha在开发环境下进行测试。

验收测试:Beta在实际使用环境下进行测试。

④系统测试：

系统测试的对象是完整的、集成的计算机系统，系统测试的目的是真是系统工作环境下，验证完整的软件配置是否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定要求。

⑤配置测试：

配置测试的对象是软件配置项，配置测试的目的是检验软件配置项与SRS（需求规格说明书）的一致性。

⑥回归测试：

回归测试的目的是测试软件变更之后，变更部分的正确和对变更需求的符合性，以及软件原有的、正确的功能、性能和其他规定的要求不损害性。

    回归测试的对象主要包括以下四个方面：

a、未通过软件单元测试的软件，在变更以后，应对其进行单元测试。

b、未通过配置测试的软件，在变更以后，首先对变更的软件进行测试，然后再进行相关的集成测试和配置测试。

c、未通过系统测试的软件，在变更以后，首先对变更的软件进行测试，然后再进行相关的集成测试、配置测试和系统测试。

d、因其他原因进行变更之后的软件单元，也首先应该对软件单元进行测试，然后再进行相关的软件测试

 

13、软件集成 （掌握）-P53

（1）企业应用集成EAI 【经常考】 

掌握表示集成、数据集成和控制集成的示意图，经常给出图让选择是哪种集成。注意集成点的位置

表示集成：集成点为界面

数据集成：集成点为中间件

控制集成：集成点为应用逻辑