背诵
背诵
系统分析和需求工程
需求获取
需求获取方法
- 用户访谈
- 优点是灵活，应用范围广；
- 缺点是记录困难，时间有限，对系统分析师要求高（ 沟通技巧 、领域知识 、丰富的经验 ）。
- 问卷调查：用户多，无法一一访谈。关键在于制作好的调查表，
- 优点是广撒网，代价小，信息真实（允许匿名），结果好统计；
- 缺点是缺乏灵活性。用户不重视，无法对问题进行展开回答并了解细节
- 采样：从种群中系统地选出有代表性的样本集的过程，通过认真研究所选出的样本集，可以从整体上揭示种群的有用信息。样本数量=0.25*(可信度因子/错误率)²
- 优点：是提高了数据收集的效率降低了成本，减少数据收集偏差（使用了数理统计原理）；
- 缺点：样本规模的确定依赖于期望的可信度和已有的先验知识，很大程度上取决于系统分析师的主观因素。 对系统分析师个人的经验和能力依赖性很强
- 情节串联板：一系列图片，通过这些图片来讲故事。
- 优点是给用户直观的演示，交互性强，生动；
- 缺点是花费时间多，效率低（ 需求获取的速度大大降低 ）。
- 联合需求计划( JRP ) : 是一个通过高度组织的群体会议来分析企业内的问题并获取需求的过程，它是联合应用开发（JAD） 的一部分。用小组工作会议来代替大量独立的访谈
- 优势：用户参与度高、消除分歧（ 各方对需求不明确 ）
- 成本较高、需要有较高议组织能力
需求分析
需求分析的工作：把杂乱无章的用户要求和期望转化为用户需求
需求分析的任务
- 绘制系统上下文范围关系图
- 创建用户界面原型
- 分析需求的可行性
- 确定需求的优先级
- 为需求建立模型
- 创建数据字典
- 使用QFD（质量功能部署）
方法的对比
SA方法关注于功能的分层和分解，这非常符合人们自上而下、逐步分解问题直到可解决的自然思考方式。SA方法本身隐含着几个基本假设，即问题域是可定义的、问题域是有限的、通过有限的步骤总可以将复杂问题分解到可解决的程度。
OOA方法则遵循完全不同的思维方式，它基于抽象、信息隐藏、功能独立和模块化这些基本理念对系统进行分析。OOA方法首先对问题域的事物的“外在表象”进行观测，然后在逻辑世界中模拟出一个对应的逻辑对象，“断定”该对象和现实事物是一致的。随后，观测到的对象被记录入对象集合，观测到的行为和表象被记录入对象关系模型和对象行为模型。
数据流图
DFD是SA 方法中的重要工具，是表达系统内数据的流动并通过数据流描述系统功能的一种方法
DFD的主要作用
- DFD 是理解和表达用户需求的工具，是需求分析的手段。由于DFD 简明易懂，不需要任何计算机专业知识就可以理解它，因此，系统分析师可以通过DFD 与用户进行交流。
- DFD 概括地描述了系统的内部逻辑过程，是需求分析结果的表达工具，也是系统设计的重要参考资料，是系统设计的起点。
- DFD 作为一个存档的文字材料，是进一步修改和充实开发计划的依据。
数据字典
数据字典是在DFD 的基础上，对 DFD 中出现的所有命名元素都加以定义，使得每个图形元素的名字都有一个确切的解释。DFD 和数据字典等工具相配合，就可以从图形和文字两个方面对系统的逻辑模型进行完整的描述。数据字典中一般有6 类条目，分别是数据元素、数据结构、数据流、数据存储、加工逻辑和外部实体
作用：
- 按各种要求列表。
- 相互参照，便于系统修改
- 由描述内容检索名称
- 一致性检验和完整性检验
状态转换图
STD 通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为。STD 还指出了作为特定事件的结果将执 行哪些动作
业务系统是数据驱动的，适合使用DFD 。
控制系统是事件驱动的，适合行为STD
流程图
- 流程图着重描述处理过程，它的主要控制结构有：顺序型、选择型、 WHILE 循环型（当型循环）、UNTIL 循环型（直到型循环）和多分支选择型，各个处理过程 之间有严格的顺序和时间关系。
- 流程图只能表达顺序执行过程， 不能表示并发
- 活动图可以有多个结束状态 ，流程图只有一个
用例模型
第一步：识别参与者【参与者：用户、组织、外部系统、时间】
第二步：合并需求获得用例
第三步：细化用例描述 （ 用例名称、简要说明、事件流、非功能性需求、前置条件和后置条件、扩展点、优先级 ）
第四步：调整用例模型(可选步骤) 【关系包括：包含关系、扩展关系、泛化关系】
用例关系
包含关系【使用关系】：从多个用例中提取公共行为，提取出来的公共用例称为抽象用例，而把原始用例称为基本用例
扩展关系：一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例。
泛化关系：当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。子用例继承了父用例所有的结构、行为和关系。
分析模型
建立流程
第一步：定义概念类
- 阅读和理解需求文档或用例描述。
- 筛选出名词或名词短语，建立初始类清单(候选类)。
- 将候选类分成三类，分别是显而易见的类、明显无意义的类和不确定类别的类。
- 舍弃明显无意义的类。
- 小组讨论不确定类别的类，直到将它们都合并或调整到其他两个类别，并进行相应的操作。
第二步：确定类之间的关系
第三步：为类添加职责
- 类的职责包括两个方面的内容，一个是类所维护的知识，即成员变量或属性；另一个是类能够执行的行为，即成员方法或责任
第四步：建立交互图
- 使用uml的顺序图、活动图、通信图
第五步：分析模型的详细程度问题
类之间的关系
关联关系。关联提供了不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起
依赖关系。两个类A 和 B , 如果B 的变化可能会引起A 的变化，则称类A 依 赖于类B 。
泛化关系。泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系
聚合关系（共享聚合）。 表示类之间的整体与部分的关系。 整体与部分生命周期可以不同。
组合聚集（ 组合关系 ），表示类之间的整体与部分的关系 。 整体与部分生命周期相同。
实现关系。实现关系将说明和实现联系
需求定义
需求定义：把这些需求形成文档，作为系统后续开发的基础
有两种需求定义的方法， 分别是严格定义方法和原型方法
严格定义方法：需求的严格定义建立在以下的基本假设之上：
- 所有需求都能够被预先定义。
- 开发人员与用户之间能够准确而清晰地交流。
- 采用图形(或文字)可以充分体现最终系统。
原型方法，迭代的循环型开发方式，需要注意的问题
- 并非所有的需求都能在系统开发前被准确地说明。
- 项目干系人之间通常都存在交流上的困难，原型提供了克该服困难的一个手段。
- 需要实际的、可供用户参与的系统模型。有合适的系统开发环境。
- 有合适的系统开发环境
- 反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法。
需求规格说明书
内容：范围；引用文件；需求；合格性规定；需求可追踪性；尚未解决的问题；注解；附录。
作用（自己编的）：
- 并作为验收依
- 开发用于验证系统的测试用例；
- 项目经理使用它作为制定项目计划
- 为下一步的系统设计提供指导
需求验证
其活动是为了确定以下几个方面的内容：
S R S 正确地描述了预期的、满足项目千系人需求的系统行为和特征。
S R S 中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。
需求是完整的和高质量的。
需求的表示在所有地方都是一致的。
需求为继续进行系统设计、实现和测试提供了足够的基础
需求变更
需求变更流程
需求跟踪
需求跟踪是将单个需求和其他系统元素之间的依赖关系和逻辑联系建立跟踪，这些元素包括各种类型的需求、业务规则、系统架构和构件、源代码、测试用例，以及帮助文件等。
正向跟踪是指检查SRS 中的每个需求是否都能在后继工作成果中找到对应点；
反向跟踪也称为逆向跟踪，是指检查设计文档、代码、测试用例等工作成果是否都能在SRS 中找到出处
UML
静态图
| 类图 | 类图描述一组类、接口、协作和它们之间的关系 | 类图给出了系统的静态设计视图 活动类的类图给出了系统的静态进程视图 |
| 对象图 | 对象图描述一组对象及它们之间的关系。 对象图描述了在类图中所建立的事物实例的静态快照 |
给出系统的静态设计视图或静态进程视图 |
| 构件图 | 构件图描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构 | 表示系统的静态设计实现视图 |
| 组合结构图 | 组合结构图描述结构化类（例如，构件或类）的内部结构 ， 包括结 构化类与系统其余部分的交互点 | |
| 部署图 | 描述对运行时的处理节点及在其中生存的构件的配置 | |
| 制品图 | 描述计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合 | |
| 包图 | 描述由模型本身分解而成的组织单元，以及它们之间的依赖关系 |
交互图 ， 交互图专注于系统的动态视图，
| 顺序图 | 它由一组对象或参与者以及它们之间可能发送的消息构成。强调消息的时间次序 | |
| 通信图 协作图 |
它强调收发消息的对象或参与者的结构组织 | 顺序图强调的是时序， 通信图强调的是对象之间的组织结构 |
| 定时图 | 强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺序 | |
| 交互概览图 | 交互概览图是活动图和顺序图的混合物 |
其他 动态视图
| 状态图 | 状态图描述一个状态机，它由状态、转移、事件和活动组成， 它对于接口、类或协作的行为建模尤为重要， 而且它强调事件导致的对象行为 |
对反应式系统建模 |
| 活动图 | 活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流 它对系统的功能建模和业务流程建模特别重要 强调对象间的控制流程 |
|
系统设计
结构化设计
概要设计又称为系统总体结构设计，它是系统开发过程中很关键的一步，其主要任务是将系统的功能需求分配给软件模块，确定每个模块的功能和调用关系，形成软件的模块结构图，即系统结构图。
详细设计：为每个具体任务选择适当的技术手段和处理方法 ，为每个模块设计实现的细节
系统结构图（StructureChart, SC ) 又称为模块结构图，它是软件概要设计阶段的工具，反映系统的功能实现和模块之间的联系与通信，包括各模块之间的层次结构，即反 映了系统的总体结构。
- SC 组成： 模块、模块之间的调用关系、模块之间的通信、辅助控制符号 （条件调用、循环调用）
- 分类：变换型、事务型、混合型
结构化设计原则 ：
- 模块独立性原则 （ 高内聚、低耦合）
- 保持模块的大小适中
- 扇入/扇出系数合理 （多扇入，少扇出）
- 深度和宽度均不宜过高
面向对象设计
在系统设计过程中，类可以分为三种类型：实体类、边界类和控制类
实体类映射需求中的每个实体，实体类保存需要存储在永久存储体中的信息
控制类是用于控制用例工作的类
边界类用于封装在用例内、外流动的信息或数据流
面向对象设计的原则：
单一职责原则 降低类的粒度，每个类只负责单一职责
开放-关闭原则 对扩展开放，对修改封闭
- 对扩展开放，有新的需求或变化时，可以对现有模块进行扩展
- 对修改封闭，意味着类一旦设计完成，尽量不要对类尽任何修改
里氏替换原则 子类可以替换父类
依赖倒置原则：要依赖于抽象，而不是具体实现；针对接口编程，不要针对实现编程
接口隔离原则：使用多个专门的接口比使用单一的总接口要好
组合重用原则：要尽量使用组合，而不是继承关系达到重用目的
最少知识原则 :一个对象应当对其他对象有尽可能少的了解
可行性分析
可行性研究通常从 经济可行性、技术可行性、法律可行性和用户使用可行性4 个方面来进行分析，其中经
济可行性通常被认为是项目的底线
**经济可行性 ** （投资收益分析、成本效益分析）主要评估项目的建设成本、运行成本和项目建成后可能的经济收益。
技术可行性 （ 技术风险分析 ）， 研究的对象是信息系统需要实现的功能和性能，以及技术能力约束。现有的技术能否足以支持系统目标的实现，现有资源(员工，技术积累，构件库，软硬件条件)是否足以支持项目的实施。
法律可行性 （社会可行性），需要从政策、法律、道德、制度等社会因素来论证信息系统建设的现实性
用户使用可行性 （ 执行可行性 ）是从信息系统用户的角度来评估系统的可行 性，包括企业的行政管理和工作制度、使用人员的素质和培训要求等，可以细分为管理可行性和运行可行性
管理可行性 是指从企业管理上分析系统建设可。主要考虑：主管领导的支持程度、中高层管理人员的抵触情绪、还要考虑管理方法是否科学，相应的管理制度改革的时 机是否成熟，规章制度是否齐全等
运行可行性。（ 操作可行性 ） 是指分析和测定信息系统在确定 环境中能够有效工作，并被用户方便使用的程度和能力
RUP
统 一 过 程 是一个通用过程框架，可以用于种类广泛的软件 系统、不同的应用领域、不同的组织类型、不同的性能水平和不同的项目规模。
RUP是 用例 驱动的、以体系结构为中心的、迭代和增量的软件开发过程
初始阶段的任务：是为系统建立业务模型并确定项目的边界
细化阶段的任务是分析问题领域，建立完善的架构，淘汰项目中最高风险的元素
在构建阶段，要幵发所有剩余的构件和应用程序功能，把这些构件集成为产品，并 进行详细测试
移交阶段
基于构件的软件工程
基于构件的软件工程是一种基于分布对象技术、强调通过可复用构件设计与构造软件系统的软件复用途径。CBSE强调构件是购买而非重新构造。
系统需求概览
识别候选构件
根据发现的构件修改需求
体系结构设计
构件定制与适配
组装构件，创建系统
可组装型：对于可组装的构件，所有外部交互必须通过公开定义的接口进行。同时它还必须对自身信息的外部访问。
可部署性：软件必须是自包含的，必须能作为一个独立实体在提供其构件模型实现的构件平台上运行。构件总是二进制形式，无须在部署前编译。
文档化；构件必须是完全文档化的，用户根据文档来判断构件是否满足需求。
独立性：构件应该是独立的，应该可以在无其他特殊构件的情况下进行组装和部署，如确实需要其他构件提供服务，则应显示声明。
标准化：构件标准化意味着在 CBSE过程中使用的构件必须符合某种标准化的构件模型