信息系统项目管理师(高级)知识点 - 3

写在前面的话：本来觉得这么手打一下回顾回顾或者作为预习还挺好的，通过实践表明，除了浪费时间以外一点用处也没有=- -，第一个长篇连载到此完结，哈哈哈XD

• 软件工程

1. 需求分析 业务需求：反映企业或客户对系统最高层次的一个目标追求 用户需求：描述用户的具体目标，或者用户要求系统必须能完成的任务 系统需求：从系统角度说明软件的需求，包括功能需求、非功能需求以及设计约束
2. 质量功能部署（QFD） QFD是一种将用户需求转化为软件需求的技术，目的是最大限度的提升软件工程过程中用户的满意度，QFD将软件需求分为三类：常规需求、期望需求、意外需求 -- 常规需求：用户认为系统应该实现的功能或性能 -- 期望需求：用户想当然以为系统应当具备的功能或性能 -- 意外需求：也成为兴奋需求，是用户要求范围外的功能或性能
3. 需求分析 常用的需求获取方法包括：用户访谈、调查问卷、采样、情节串联版、联合需求计划等。一个好的需求必须具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等，因此需求分析的工作指的是将用户要求和期望转换为用户需求
4. SA方法进行需求分析 结构化分析方法SA进行需求分析的核心是数据字典 模型： 数据模型：实体联系图（ER图），描述实体、属性以及实体之间的关系 功能模型：数据流图（DFD），从数据传递和加工的角度，利用图形符号通过逐层细分描述系统内各部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能 行为模型：状态转换图（STD），通过描述系统的状态和引起系统状态转换的事件来表示系统的行为，指出作为特定事件的结果或执行的动作
5. 需求规格说明书（SRS） SRS是需求开发活动的产物，规定SRS因当包含的内容为： -- 范围 -- 引用文件 -- 需求 -- 合格性规定 -- 需求可跟踪性 -- 尚未解决的问题 -- 注解 -- 附录
6. 需求验证 也称为需求确认，其活动是为了确认： -- SRS正确描述了预期的、满足项目干系人需求的系统行为与特征 -- SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导出来的 -- 需求是完整和高质量的 -- 需求的表示在所有地方都是一致的 -- 需求为继续进行系统设计、实现和测试提供了足够的基础 在实际工作中，一般通过需求评审和需求测试对需求进行验证。需求评审就是对SRS进行技术评审
7. UML UML是一种定义良好、易于表达、功能强大且普遍使用的建模语言。UML的结构包括造块、规则和公共机制三个部分，UML通过关系将事物集合在一起，主要有四个关系： -- 依赖，表现为函数中的参数（use a），是类与类之间的连接，表示了一个类依赖于另一个类的定义，其中一个类的变化会影响另外一个类 在UML图中使用一条带有箭头的虚线指向被依赖的类

依赖

-- 关联，表现为变量（has a），是类与类之间的连接，它使一个类知道另一个类的属性和方法 在UML图中使用一个直线表示两个类之间的关联关系

关联

-- 泛化，表示类与类之间的继承关系、接口与接口之间的继承关系，是一般化与特殊化的关系，描述特殊元素的对象可以替换一般元素的对象 在UML图中使用一条带有空心三角箭头的实线指向基类

泛化

-- 实现，表示类对接口的实现，是类与类之间的语义定义关系，其中一个类制定了由另外一个类保证执行的契约 在UML图中使用一条带有空心三角箭头的虚线指向接口

实现

1. UML2.0-14种图 -- 类图：描述了一组类、接口、协作以及它们之间的关系，类图给出系统静态设计视图，活动类的类图给出了系统的静态进程视图 -- 对象图：描述了一组对象及其之间的关系 -- 构件图：描述了一个封装类及其接口、端口以及由内嵌的构件和连接件构成的内部结构 -- 组合结构图：描述了结构化类（如：构件和类）的内部结构，包括结构化类与系统其余部分的交互点 -- 用例图：描述一组用例、参与者及其之间的关系 -- 顺序图（序列图）：是一种交互图，展示了一种交互，由一组对象或参与者及其之间可能发送的消息构成。关注于系统的动态视图，是强调消息的时间次序的交互图 -- 通信图：也是一种交互图，强调收发消息的对象或参与者的结构组织。顺序图强调时序，通信图强调对象之间的组织结构关系 -- 定时图（计时图）：也是一种交互图，强调信息跨越不同对象或参与者的实际时间，而不仅仅只关心消息的相对顺序 -- 状态图：描述了一个状态机，由状态、转移、事件和活动组成，状态图给出了对象的动态视图 -- 活动图：将进程或计算机其他结构展示位计算内部一步步的控制流与数据流，专注于系统的动态视图，强调对象间的控制流程 -- 部署图：描述对运行时的处理节点及在其中生存的构件配置，给出了架构的静态部署图，通常一个节点包含一个或多个部署图 -- 制品图：描述计算机中一个系统的物理结构，制品包含文件、数据库以及类似的物理比特集合。制品图通常与部署图一起使用，制品也给出了他们实现的类和构件 -- 包图：描述由模型本身分解而成的组织单元以及它们之间的依赖关系 -- 交互概览图：是交互图与顺序图的混合物，可以把交互概览图理解为细化的活动图,在其中的活动都通过一些小型的顺序图来表示；也可以将其理解为利用标明控制流的活动图分解过的顺序图
2. UML视图 -- 逻辑视图：也成为设计视图，表示设计模型在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集 -- 进程视图：是可执行线程与进程作为活动类的建模，它是逻辑视图的一次执行用例，描述了并发与同步结构 -- 实现视图：对组成基于系统的物理代码的文件和构件进行建模 -- 部署视图：将构件部署到一组物理节点上，表示软件到硬件的映射和分布结构 -- 用例视图：是最基本上的需求分析模型
3. OOA与OOD OOA：Object-Oriented Analysis，面向对象分析方法 OOD：Object-Oriented Design，面向对象设计 OOA模型独立于具体实现，不考虑具体实现的有关因素，是与OOD模型的区别所在，OOA关注“做什么”，OOD关注“怎么做”，面向对象分析阶段的核心工作是建立系统用例模型和分析模型
4. 软件架构风格 -- 数据流风格：包括批处理序列（顺序执行）和管道/过滤器（输入输出数据流）两种风格 -- 调用/返回风格：包括主程序/子程序（过程调用）、数据抽象与面向对象（对象及封装）以及层次结构（分层调用） -- 独立构件风格：包括进程通信（消息传递、远程调用）和事件驱动（事件触发调用）的系统 -- 虚拟机风格：包括解释器（解释引擎）和基于规则（规则集）的系统 -- 仓库风格：包括数据库系统（中央共享数据源）、黑板系统（知识源、黑板以及共享数据和控制）和超文本系统（非线性交叉引用）
5. 软件架构评估 敏感点是一个或多个构件的特性，权衡点是影响多个质量属性的特性，是多个质量属性的敏感点，可以归纳为三类：基于调查问卷（检查表）的方法、基于场景的方式和基于度量的方式
6. 软件设计 分为结构化设计和面向对象设计，结构化设计SD是一个面向数据流的方法，它以SRS和SA阶段所产生的DFD与数据字段等文档为基础，是一个自顶向下、逐步求精、模块化的过程，SD分为概要设计和详细设计两个阶段。SD需要遵循的一个基本原则是高内聚，低耦合，模块内部高度内聚，模块与模块之间需要降低耦合度，面向对象设计OOD的基本思想是抽象、封装、可扩展性，其中可扩展性主要是通过继承和多态来实现，其三大特征是封装、继承、多态
7. 软件工程的过程管理 -- 阶段式模型

-- 连续式模型

这两种方法均采用统一的个过程域，它们在逻辑上是等价的，对同一组织采用阶段式模型和连续式模型分别进行CMMI评估，得到的结论应该是相同的

1. 测试 -- 每个测试用例应该包括名称和标识、测试追踪、用例说明、测试的初始化要求、测试的输入、期望的测试结果、评价测试结果的准侧、操作过程、前提和约束、测试终止条件 -- 软件测试方法可分为静态测试和动态测试，静态测试是指被测试程序不在机器上运行，而是采用人工检测和计算机辅助静态分析的方法对程序进行检测。静态测试包括对文档的和对代码的静态测试，对文档的静态测试主要是以检查单的形式进行，而对代码的静态测试一般采用桌前检查、代码走查和代码审查 -- 动态测试实是指在计算机上实际运行程序进行软件测试，一般采用白盒测试和黑盒测试方法
2. 白盒测试 也被称为结构测试，主要用于软件单元测试。主要思想是：将程序看做一个透明的白盒，测试人员完全清楚程序的结构和算法，按照程序内部逻辑结构设计测试用例 方法主要有：控制流测试、数据流测试和程序变异测试等此外，使用静态测试的方法也可以实现白盒测试。最常用的技术是逻辑覆盖，及使用测试数据运行被测试程序，考察对程序逻辑的覆盖程度，主要的覆盖标准有语句覆盖、判定覆盖、条件覆盖、条件/判定覆盖、条件组合覆盖、修正的条件判定覆盖和路径覆盖等
3. 软件测试 黑盒测试也成为功能测试，主要用于集成测试、确认测试和系统测试中。黑盒测试将测试看作是一个不透明的黑盒，完全不考虑（或不了解）程序的内部结构和处理算法，一般包括等价类划分、边界值分析、判定表、因果图、状态图、随机测试、猜错法和正交验证法等 软件测试可分为：单元测试、集成测试、系统测试、配置项测试、回归测试、确认测试等类别： -- 单元测试，单元测试也称为模块测试 -- 集成测试，集成测试的目的是检查模块之间，以及模块和已集成的软件之间的接口关系 -- 确认测试，确认测试主要用于验证软件功能，性能，和其他特性是否与用户需求一致，根据用户的参与程度，分为内部测试与验收测试 -- 系统测试，系统测试的对象是完整的、集成的计算机系统，系统测试的目的是在真实系 统工作环境下，验证完整的软件配置项是否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求 -- 配置项测试，配置项测试的对象是软件配置项，配置项测试的目的是检验软件配置项与 -- 回归测试，回归测试的目的是测试软件变更之后，变更部分的正确和对变更需求的符合 性，以及软件原有的、正确的功能、性能和其他规定的要求不损害性
4. 回归测试 回归测试的对象主要包括以下四个方面： -- 未通过软件单元测试的软件，在变更以后，应对其进行单元测试 -- 未通过配置项测试的软件，在变更以后，首先对变更的软件进行测试，然后再进行相关 -- 未通过系统测试的软件，在变更之后，首先对变更的软件进行测试，然后再进行相关的 -- 因其他原因进行变更之后的软件单元，也首先应对变更的软件单元进行测试，然后再进 行相关的软件测试
5. 企业应用集成EAI EAI可以包括表示集成、数据集成、控制集成和业务流程集成等多个层次和方面，也可以在多个企业之间进行应用集成 -- 表示集成：也称界面集成，是比较原始和最浅层次的集成，是常用的集成，是黑盒集成，这种方法将用户界面作为公共的集成点，把原有零散的系统界面集中在一个新的界面中。无须了解程序与数据库的内部构造。常用的集成技术主要有屏幕截取和输入模拟技术 表示集成通常应用于以下几种情况： o 在现有的基于终端的应用系统上配置基于PC的用户界面 o 为用户提供一个看上去统一，但是由多个系统组成的应用系统 o 当只有可能在显示界面上实现集成时 -- 数据集成：是白盒集成，有很多不同的中间件工具可以用于数据集成。例如，批量文件传输、0DBC(开放数据库互连)标准接口、数据库访问中间件技术等。数据集成比表示集成要更加灵活。 通常在以下情况下，将会使用数据集成： o 需要对多种信息源产生的数据进行综合分析和决策 o 要处理一些多个应用喜人需要访问的公用信息库 o 当需要从某数据源获得数据来更新另一个数据源时，特别是它们之间的数据格式不相同 时 -- 控制集成：也称为功能集成或应用集成，在业务逻辑层上对应用系统进行集成的。是黑盒集成。集成处可能只需简单使用公开的API(应用程序编程接口)就可以访问，当然也可能需要添加附加的代码来实现控制集成与表示集成、数据集成相比，灵活性更高。表示集成和数据集成适用的环境下，都适用于控制集成。但是，由于控制集成是在业务逻辑层进行的，其复杂度更高一些 -- 业务流程集成：也称为过程集成，这种集成超越了数据和系统，它由一系列基于标准的、统一数据格式的工作流组成。它包括应用集成、B2B集成、自动化业务流程管理、人工流程管理、企业门户，以及对所有应用系统和流程的管理和监控等。当进行业务流程集成时，企业必须对各种业务信息的交换进行定义、授权和管理，以便改进操作、减少成本、提高响应速度 -- 企业之间的应用集成：EAI技术可以适用于太多数要实施电子商务的企业，以及企业之间的应用集成。EAI使得应用集成架构里的客户和业务伙伴，都可以通过集成供应链内的所有应用和数据库实现信息共享。能够使企业充分利用外部资源
6. 表示集成

表示集成示意图

1. 数据集成

数据集成示意图

1. 控制集成

控制集成示意图