信息系统项目管理师学习笔记2——信息化与信息系统2

1.4 软件工程

1.4.1 需求分析

1.需求层次

1. 业务需求：指反映企业或客户对系统高层次的一个目标追求，通常来自项目投资人、购买产品的客、客户单位的管理人员、市场营销部门或产品策划部门等。
2. 用户需求：用户需求描述的是具体的目标，或者用户要求系统必须能完成的任务，也就是说，用户需求描述了用户能用系统来做什么。通常采用用户访谈和调查问卷等方式，对用户使用的场景进行调整，从而建立用户需求。
3. 系统需求：是指从系统的角度来说明软件的需求，包括功能需求，非功能需求的设计约束。

2.质量功能部署

定义：质量功能部署（QFD）是一种将用户需求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。

分类：

1. 常规需求：用户认为系统应该实现的功能或性能，实现越多用户越会满意。
2. 期望需求：用户想当然以为系统应具备的功能和性能，但并不能正确认识自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感动不满意。
3. 意外需求：也称为兴奋需求，是用户要求范围外的功能或性能。

3.需求获取

需求获取方法：

1. 用户访谈
2. 调查问卷
3. 采样
4. 情节串联板：使用工具向用户说明或演示系统如何适合企业的需要，并说明系统将如何运转
5. 联合需求计划：通过高度组织的群体会议来分析企业内的问题，并获取需求的过程，相对成本较高，但十分有效。

4.需求分析

需求特性：

1. 无二义性
2. 完整性
3. 一致性
4. 可测试性
5. 确定性
6. 可跟踪性
7. 正确性
8. 必要性

需求分析工作：分析人员把杂乱无章的用户要求和期望转换为用户需求。

分析方法：

1. 结构化分析（SA）：建立的模型的核心式数据字典；**三个层次的模型
2. 面向对象分析（OOA）：用例模型；分析模型

**三个层次的模型：

1. 数据模型：E-R图
2. 功能模型：数据流图（Data Flow Diagram）DFD
3. 行为模型（状态模型）：状态图（State Transform Diagram）STD

5.软件需求规格说明书

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

SRS包括内容：

1. 范围
2. 引用文件
3. 需求
4. 合格性规定
5. 需求可追踪性
6. 尚未解决的问题
7. 注解
8. 附录

6.需求验证

定义：需求验证也称为需求确认

需求验证确认的内容：

1. SRS正确描述了预期的、满足项目干系人需求的系统行为与特性。
2. SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。
3. 需求是完整和高质量的
4. 需求的表示在所有地方都是一致的
5. 需求为继续进行系统设计、实现和测试提供了足够的基础

需求验证的方法：

1. 需求评审：对SRS进行技术评审
2. 需求测试

7.UML

定义：UML是一种定义良好，易于表达、功能强大且普遍适用的建模语言。

1）UML的结构

1. 构造块
2. 规则
3. 公共机制

2）UML中事物的关系

1. 依赖：一个事物发生改变会影响到另外一个事物的语义。
2. 关联：关联描述一组对象之间连接的结构关系。
3. 泛化：泛化是一般化和特殊化的关系，描述特殊元素的对象可替代的一般元素的对象。
4. 实现：实现是类与类之间的语义定义关系，其中一个类指定了由另外一个类保证执行的契约。

3）UML2.0中的图

非交互图：

• 类图：描述一组类、接口、协作、和它们之间的关系，类图给出系统静态设计视图，活动类的类图给出了系统的静态进程视图。

• 对象图：对象图描述一组对象及他们之间的关系。

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

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

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

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

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

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

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

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

• 交互概览图：交互概览图是活动图和顺序图的混合物。

交互图：

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

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

3. 定时图（计时图）：一种交互图，他强调消息跨越不同对象或参与者的实际时间，而不仅仅是关心消息的相对顺序。
   4）UML视图

4. 逻辑视图：逻辑视图也称为设计视图，它表示设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用实例实现的子集。

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

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

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

8. 用例视图：用例视图是最基本上的需求分析模型。

8.面向对象分析

1. OOA：Object-Oriented Analysis 面向对象分析方法
2. OOD：Object-Oriented Design 面向对象设计
3. OOA与OOD的区别：OOA模型独立于具体实现，即不考虑具体实现有关的因素，这也是OOA与OOD的区别所在，OOA的任务是“做什么”，OOD的任务是“怎么做”
4. 面对对象分析阶段的核心工作是：建立系统用例模型与分析模型
5. **类与类的关系

**类与类的关系：

1. 关联关系：关联提供了不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起。
2. 依赖关系：两个类A与B，如果B的变化可能会引起A的变化，则称类A依赖类B。
3. 泛化关系：泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。
4. 共享聚集：共享聚集关系通常简称聚合关系，它表示类之间的整体与部分的关系，其含义是“部分”可能同时属于多个“整体”，“部分”与“整体”的生命周期可以不相同。
5. 组合聚集：组合聚集关系通过组合关系，它也是表示类之间的整体与部分的关系。与聚合关系的区别在于，组合关系中的“部分”只能属于一个“整体”，“部分”与“整体”的生命周期相同，“部分”随着“整体”的创建而创建，也随着“整体”的消亡而消亡。

1.4.2 软件架构设计

1.软件结构风格

定义：软件架构设计的一个核心问题是能否达到架构级的软件复用，也就是说，能否在不同的系统中，使用同一个软件架构。
分类：

1. 数据流风格：数据流风格包括批处理序列和管道/过滤器两种风格。
2. 调用/返回风格：调用/返回风格包括主程序/子程序、数据抽象和面向对象，以及层次结构。
3. 独立构件风格：独立构件风格包括进程通信和事件驱动的系统。
4. 虚拟机风格：虚拟机风格包括计时器和基于规则的系统。
5. 仓库风格：仓库风格包括数据库系统、黑板系统和超文本系统。

2.软件结构评估

敏感点：是一个或多个构件的特性。
权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点。
评估方式分类：
1）调查问卷（检查表）方式
2）基于场景的方式：

1. 分析方法：1.架构权衡分析法（ATAM）；2.软件架构分析法（SAAM）；3.成本效益分析法（CBAM）
2. 对场景进行描述：刺激：刺激是场景中届时或描述项目干系人怎么引发与系统的交互部分；环境：环境描述的是刺激发生时的情况；响应：响应是指系统如何通过架构对刺激做出反映的。

3）基于度量的方式

1.4.3 软件设计

1.结构化设计（SD）

定义：是一种面向数据流的方法，它以SRS和SA阶段所产生的DFD和数据字段等文档为基础，是一个自顶向下、逐步求精和模块化的过程。
阶段：概要设计；详细设计
遵循的基本原则：高内聚，低耦合：模块内部高度内聚，模块与模块之间需要降低耦合度

2.面向对象设计（OOD）

基本思想：抽象，封装，可扩展性：其中可扩展性主要是通过集成和多态来实现
三大特征：

1. 继承
2. 封装
3. 多态

3.设计模式

定义：就是前任经验的总结，它使人们可以方便地复用成功的软件设计
按处理范围分类：类模式；对象模式
按目的和用途：

• 创建型：主要用户创建对象
• 结构型：用于处理类或对象的组合
• 行为型：用于描述类或对象的交互以及职责的分配

1.4.4 软件工程的过程管理

定义：软件过程是软件生命周期中一些列相关活动，即用于开发和维护软件相关产品的一系列活动。
CMMI：能力成熟度模型集成（Capability Mathturity Model Integration），它融合了多种模型，形成了组织范围内过程改进的单一集成模型，其主要的目的是消除不同模型之间的不一致性和重复，降低基于模型新型改进的成本。
两种表示方法：

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

1.4.5 软件测试及其管理

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

1.测试方法（后面详解）

2.测试类型（后面详解）

3.面向对象测试

4.软件调试

1.软件调试策略

• 蛮力法
• 回溯法
• 排除法

2.调试与测试区别

1. 测试的目的是找出存在的错误，而调试的目的是定位并修改程序以修正错误。
2. 调试是测试之后的活动，测试和调试在目标、方法和思路上都有所不同。
3. 测试从一个已知的条件开始，使用预先定义的过程，有预知的结果；调试是从一个未知的条件开始，结束的过程不可预计。
4. 测试过程可以事先设计，进度可以事先确定；调试不能描述过程或持续时间。

5.软件测试管理

1. 过程管理：过程管理包括测试活动管理和测试资源管理。软件测试应有相对独立的人员进行。
2. 配置管理：应按照软件配置管理的要求，将测试过程中产生的各种工作产品纳入配置管理。
3. 评审：测试过程中的评审包括测试就绪评审和测试评审。

1.4.6 软件集成技术——企业应用集成EAI

1.表示集成

藐视集成也称为界面集成，是黑盒集成。

表示集成同城应用于一下几种情况：

1. 在现有的基于终端的应用系统上配置基于PC的用户界面。
2. 为用户提供一个看上去统一，但是由多个系统组成的应用系统。
3. 当只有可能在显示界面上实现集成时。

2.数据集成

数据集成是白盒集成。

3.控制集成

控制集成也称为功能集成或应用集成，是在业务逻辑层对应系统进行集成，控制集成是黑盒集成

4.业务集成

业务集成也称为过程集成，这种集成超过了数据和系统，它由一些列的基于标准的，异同的数据格式的工作流组成。

5.企业之间的应用集成

• EAI技术可以使用于大多出需要实施电子商务的企业，以及企业之间的应用集成。EAI使得应用集成框架里的客户和业务伙伴都可以通过集成供应链内的所有应用和数据库实现信息共享。
• 能够使企业充分利用外部资源。