系统分析与设计考点

系统分析与设计

第一章 系统分析与设计入门

系统开发生命周期（System Development Life Cycle，SDLC）是指这样的一个过程，包括： 理解信息系统对业务需求的支持，设计系统、构建系统，以及把系统移交给用户。
SDLC分为四个阶段：计划、分析、设计、实现。
- 计划阶段是理解为什么要创建信息系统和确定项目团队将如何来开发它的基本过程，要确定系统的业务价值、进行可行性分析和制订项目计划。
- 分析阶段说明此系统由谁来用、用作什么、在哪里用，以及什么时候用这些问题，要提出分析策略、收集信息和构建一组分析模型。
- 设计阶段确定系统将如何运作，涉及硬件、软件和网络基础设施，要完成物理设计、架构设计、界面设计、数据库和文档规格以及程序设计。
- 实现阶段要创建、安装和维护系统。

系统开发方法论是指以规范化方法实现SDLC，可分为以过程为中心的方法论、以数据为中心的方法论和面向对象方法论。
结构化设计：瀑布式开发、并行开发；
快速应用开发：阶段性开发、原型开发、抛弃原型开发；
敏捷开发：XP（极限编程）；
选择方法论需要考虑的问题：
- 用户需求的清晰度；
- 技术的熟悉程度；
- 系统复杂度；
- 系统可靠性；
- 短时间进度；
- 进度可见性；

系统分析员需要的技能类别：技术、 业务、分析、人际交往、管理和道德修养。
分析员分类：业务分析员、系统分析员、基础设施分析员、变更管理分析员。

第二章 项目启动

项目启动：项目启动是组织创建和评估新系统最初目标和预期的时间点。此过程的第一步是通过开发该系统的需求来确定系统的业务价值。下一步是由分析员进行可行性分析，确保项目在技术、组织、经济上的可行性。如果可行，系统将会被批准，开始项目开发。

系统需求：系统需求是指描述创建系统的业务原因和系统预期带来的价值的文档。大多数包括五个元素：
- 项目发起者：发起项目的人或组织；
- 业务要求：发起项目的与业务相关的原因；
- 业务需求：系统所能提供的业务能力；
- 业务价值：系统将为组织创建的收益；
- 特殊问题：与系统实现以及项目决策有关的一些特殊方面或约束。

可行性分析：分析与所提议的系统的风险相关的内容，包括：
- 技术可行性：关注系统是否能被创建的问题。
- 经济可行性：关注系统是否应该创建的问题，
- 组织可行性：评估系统将在多大程度上被用户接受，以及如何融入到组织的日常运转中。

技术可行性的主要内容：
- 用户和分析员对应用的熟悉程度；
- 对技术的熟悉程度；
- 项目规模；
- 新系统与组织内现有技术的兼容性；

经济可行性分析的步骤：
1. 确定花费和收益。主要包括开发费用、操作费用、有形收益、无形收益等。
2. 给花费和收益赋值。
3. 确定现金流。一般计算累计净现金流，即到某年为止累计的所有收益与费用的差。
4. 确定投资回报率。投资回报率（ROI）指的是投资在项目上的钱所赚取的平均回报比率，计算方法为用项目的净收益（总收益-总费用）除以总费用。
5. 确定平衡点。平衡点指的是公司从净现金流中回收它对项目的原始投资所需要的年数。计算方法为（1）确定累计现金流的数字由负变正的年份n（2）（第n年的净现金流 - 到第n年底累计的净现金流） / 第n年的净现金流 + n - 1。
6. 确定净现值。现值考虑了金钱的时间价值。净现值NPV = 现值总收益 - 现值总费用。如果NPV大于0，项目在经济上就是可行的。

项目选择：一旦可行性分析完成后，报告将与修订过的系统需求一起交给审定委员会，由委员会来决定是否批准该项目、取消该项目或推迟决策。

第三章 项目管理

项目管理：项目管理就是计划和控制待开发的系统，使其在特定时间范围内，以最低的成本完成正确功能的过程。项目经理的主要职责就是管理众多任务以及协调各个角色之间的关系。

项目管理的原理是在三个重要的要素之间进行权衡：系统大小、完成项目的时间、项目成本。

估算项目规模的方法：
1. 经验法：用计划阶段花费的时间除以一个行业标准比例来推测整个项目所需的时间。
2. 功能点法：分为三步：（1）项目经理根据新系统需要的代码行数估算系统大小。（2）把估算结果转换成开发这个系统所需的人月数。（3）根据项目从开始到完成的月数制定估算时间表。

工作计划：一个动态进度表，它会记录跟踪项目过程中所需完成的各种任务，并根据任务完成情况做出适当的调整。

工作计划信息可以使用甘特图或PERT图展示。甘特图主要描述任务的持续时间，PERT图主要描述任务的依赖关系。

关键路径：从项目起始到项目结束过程中最长的路径。

人员配备：包括确定项目需要多少人，每个项目成员的角色，为团队设定一个汇报程序，根据项目的需要发挥每个人的特长。

项目协调活动：将有效的开发实践放在合适的位置以及转移风险。

协调项目活动的三种技术：
- 计算机辅助软件工程（CASE）：一类自动控制软件，能自动化所有或部分开发过程。
- 标准：项目团队在开发过程中必须遵循的正式准则和方针。
- 文档：包括整个SDLC过程中所有任务的详细信息，即项目历史记录。

第四章 需求确定

as-is system：当前系统，不一定是计算机操纵的。
to-be system：新系统，基于更新的需求。

需求：陈述系统必须要做的事或者系统必须具备的特征。业务需求解释系统是做什么的，系统需求描述系统应当如何运作。功能需求直接关系着要面对的过程或者它必须包含的信息，非功能需求关系着系统必须具有的特性，比如性能和可用性。

分析阶段需要创建需求定义、用例、过程模型、数据模型等可交付物。

需求分析的基本过程：
1. 理解现有系统；
2. 确定要改进的地方；
3. 开发新系统的需求；

需求分析技术：
- 业务过程自动化（BPA）：使用计算机技术做某些事情时保持基本的业务操作本质不变。问题分析和根本原因分析是两种通用的BPA活动。
- 业务过程改进（BPI）：要做出一些改进，可以更好地利用技术带来的新机会或模仿竞争对手正在做的事情。时限分析、基于活动的代价和非正式基准是三种通用的BPI活动。
- 业务过程再工程（BPR）：改变组织运作的一些基本方式。结果分析、技术分析和活动消除是险种通用的BPR活动。

需求收集技术：
- 面谈：与一个或多个人碰面并问他们问题。面谈过程有5个基本步骤：选择访问对象，设计面谈问题，准备面谈活动，进行面谈，以及面谈后续工作。
- 联合应用开发（JAD）：让项目团队、用户和管理人员一起工作来确定系统的需求。
- 问卷：用在需要调查大量的人所掌握的信息和观点的情况。
- 文档分析：复查现有的文件并检查系统本身。
- 观察：查看过程如何被执行。

第五章 用例分析

用例：一个用例包含了构造部分过程模型所需的全部信息，它以一种非正式的、简单的方式来表达。一个用例有一个名称、编号、重要性级别、概要描述、主要参与者、触发事件、主要的输入输出和执行用例所需要的主要步骤列表。通过审查功能需求能够确定用例。

第六章 过程建模

数据流图（Data Flow Diagram, DFD）是一种最为常用的过程建模技术，它以图形的方式描述系统业务流程以及系统内的数据传递。
数据流图的基本元素：
- 过程：为特定业务原因而执行的活动或功能。每个过程至少有一个名称（动名词短语）、一个描述、一个编号、一个输入数据流（没有输入不可能产生输出）和一个输出数据流（没有输出代表该过程什么都没有做）。
- 数据流：单个数据或是信息的逻辑集合。每个数据流至少有一个名称（名词）、一个描述、以及开始于或结束于一个过程。
- 数据存储：以某种方式存储的数据集合。每个数据存储至少有一个名称（名词）、一个编号、一个输入数据流、一个输出数据流。
- 外部实体：位于系统范围之外但与系统产生交互的人、部门或其他系统。每个外部实体至少有一个名称、一个描述。

DFD图的层次结构一般分为上下文图、0层DFD图、1层DFD图。

常见的DFD图错误：
- 没有过程移动的数据流（外部实体到外部实体、外部实体到数据存储等）。
- 没有输入或输出的数据存储。
- 双向移动的数据流。
- 没有输入或输出的过程。
- 输入和输出的数据流名相同。

第七章 数据建模

实体关系图（Entity Relationship Diagram, ERD）是一幅显示业务系统中数据创建、存储和使用的图。

实体关系图的基本元素：
- 实体：数据模型中的基本构造模块，是人物、地点、事件等类型的数据，代表拥有多个实例或事物的一类东西。
- 属性：从实体中捕获到的各种类型的信息，通常会将实体名称的某些形式作为前缀衔接到属性前，使其能清楚地表示它属于哪个实体。一个或多个属性可以作为标识符，这些属性可以唯一标识实体中的实例。
- 关系：实体之间的关联。关系有两个属性：基数和模态。基数指的是父实例对子实例的比例，可以是1：1、1：N、M：N。模态指的是子实体的一个实例能否在没有相关父实体的实例的情况下存在。

创建实体关系图的步骤：
1. 确定实体。
2. 为每个实体添加适当的属性。
3. 绘制实体间的线条用于表示它们是如何互相关联的。

实体类型：
- 独立实体：可以在没有其他实体帮助下存在的实体。这些实体都拥有由自身属性创建的标识符
- 依赖实体：子实体需要父实体的属性去唯一标识一个实例，这种情况下子实体被称为依赖实体，它的标识符最少由一个父实体的属性表示。
- 关联实体：为了帮助捕获存在于另外两个实体之间的关系的信息。

规范化：
- 第一范式（1NF）：不包含重复的属性。
- 第二范式（2NF）：满足第一范式，且除标识符外的属性必须依赖整个标识符，而不能是部分依赖。
- 第三范式（3NF）：满足第二范式，且没有属性依赖非标识符属性（即不存在传递依赖）。

第八章 转换到设计

设计活动的主要输入：分析阶段确定的需求。
设计阶段最主要的可交付物：系统规格，包括物理过程模型、物理数据模型、架构设计、软硬件规格、界面设计、数据存储设计和程序设计。

构建系统的方法：
- 内部开发定制系统。优点：能够灵活且有创造性地解决业务问题，能在公司内部建立技术性的和功能性的知识。缺点：消耗人工。
- 购买系统软件包并配置它。优点：节约人工，更加高效。缺点：可能无法满足所有需求，需要创建工作区来满足。
- 外包。优点：节约人工。缺点：可能危及公司机密信息，对将来发展不利。

影响获取策略的因素：
- 业务需要：独特的业务需要选择内部开发；通用的业务需要选择购买软件包；非核心的业务需要选择外包。
- 内部经验：有功能性和技术性经验选择内部开发；有功能性经验选择购买软件包；不存在经验选择外包。
- 项目技术：想要开发内部技术选择内部开发，否则选择购买软件包或外包。
- 项目管理：内部开发需要较高的项目管理能力和被证实的方法论。否则应选择购买软件包或外包。
- 时间约束：如果时间是一个约束因素，那么应当首先考虑购买软件包。内部开发需要有较为灵活的时间约束。利用外包创建系统所需的时间取决于系统和外包商的资源。

选择一个获取策略的方法：可选矩阵通过列出若干候选方法的可用信息，使得各方法很容易进行比较，帮助项目团队做出这个决定。需求建议书、信息需求书、引用需求书都是收集有关可选方案的精确信息的方法。此时，项目团队会决定由谁来完成设计阶段中的各个部分，以及使用哪个软件包。

第九章 架构设计

软件系统可划分为四种基本功能：数据存储、数据访问逻辑、应用逻辑、表示逻辑。有三种基本的架构能够把这些功能分配到不同的计算机上：
- 基于服务器的架构：服务器完成所有的功能。
- 基于客户端的架构：客户端负责表示逻辑、应用逻辑和数据访问逻辑，服务器负责数据存储。
- C/S架构：客户端负责表示逻辑，服务器负责数据存储和数据访问逻辑。其中，在瘦C/S架构中，服务器执行应用逻辑；在胖C/S架构中，服务器和客户端共同负责应用逻辑。

两层C/S架构中有两组计算机：一个客户端和一组服务器。三层C/S架构中有三组计算机：客户端、一组应用服务器、一组数据库服务器。

选择架构考虑的因素：
- 基础设施费用。
- 开发工作量。
- 开发难度。
- 界面容量。
- 控制和安全性。
- 可扩展性。

架构设计：架构设计指定了架构的各个方面及其所使用的硬件和软件的布局。
设计架构时需要考虑的四种重要的非功能需求：
- 操作性需求：指定了系统完成任务所需的操作环境及其随时间可能的改变，如技术环境、系统集成、可移植性和可维护性。
- 性能需求：中心是性能问题，如系统速度、容量、可用性与可靠性。
- 安全性需求：防止信息系统崩溃和数据丢失的能力，如访问控制、加密与验证、病毒控制等。
- 文化与政治需求：针对使用系统的不同国家所特有的需求（多语言、用户制定、未声明的术语和法律）。

硬件与软件规格：硬件与软件规格是用来描述需要什么样的硬件和软件来支持应用的文档。当创建文档时，要列出需要用于支持系统的硬件。然后，尽可能详细地对其进行描述，再记录运行于每个硬件构件的软件，和所有伴随的费用，如技能培训、维护和延长保证以及许可协议。项目团队与采购部门将一起工作来获得硬件和软件。

第十章 用户界面设计

用户界面设计原则：
- 布局：为不同目的而使用的屏幕和文档的组织区域。用户界面设计的首要元素是屏幕、表格或报表的布局，它通常通过矩形描述，而且其顶部用于导航，中间区域用于输入和输出，而底部是状态栏。
- 内容提示：界面使用户通过最小努力了解它包含的信息的能力。
- 审美学：设计赏心悦目的界面。
- 用户经验：设计用户界面时，要考虑到用户的计算机水平。大多数界面应该被设计来支持新手/初学者用户和有经验的用户。
- 一致性：通常涉及一个计算机系统的界面，以便于同一个系统的所有部分都以相同方式工作。
- 使用户投入最小化：所有界面都应该要方便用户，例如通过只需不多于3次的点击就能从主菜单到达执行操作。

用户界面设计过程：
1. 使用场景开发：描述了用户执行操作的普遍使用模式。
2. 界面结构设计：创建对界面基本结构进行定义的界面结构图（Interface Structure Diagram, ISD），显示系统所有界面以及它们之间是如何连接的。
3. 界面标准设计：界面标准是跨越系统中所有屏幕、表格和报表的基本设计元素。
4. 界面设计原型：界面设计原型是一个实体模型或是对计算机屏幕、表格或报告的模拟。常用的方法有故事版、HTML原型和语言原型。
5. 界面评估：目标是了解如何改进界面设计。有启发式评估、走查式评估、交互式评估、正式可用性测试等方法。

导航设计的首要原则：错误预防、简化错误恢复、使用一致的语法顺序。

导航控制的类型：代码、菜单、直接操作。

消息：系统响应用户以及通知其关于交互状态的一种方式。常见的消息类型有错误消息、确认消息、确定消息、延迟消息和帮助消息。

输入设计：输入设计的目标是简单并轻松地为系统捕获精确的信息，基本原则有恰当地使用在线式和批处理，捕获源头数据和最少化击键。

输出设计：输出设计的目标是把信息呈现给用户以便他们能毫不费力地准确理解它，基本原则有了解报表用法、管理信息负荷量、歧视最小化。

第十一章 程序设计

结构图：结构图包括所有的在程序高层必须包含的功能构件，它们被排列在一个图里面，其排列顺序代表构件之间的命令和控制关系。
有两种基本的排列或结构方式将结构图中的模块连接起来：
- 事务结构：包括一个控制模块，它调用可执行独立任务的下属模块。少量传入，大量传出。
- 转换结构：通过一系列下属模块将输入转变成输出，而控制模块描述转换的发生。大量传入，少量传出。

建立结构图的步骤：
1. 确定高层模块，然后分解成较低的层次。
2. 在模块间添加控制连接（如循环、条件等连接）。
3. 在模块间添加耦合，模块间可以互相传送信息。
4. 复查结构图，直到没有问题产生为止。

结构图设计原则：
- 第一，构建高内聚的模块，这样每个模块只执行一个功能。
- 第二，模块不应该是相互依赖的而应是松耦合的，模块间应该用好的耦合方式连接起来。
- 最后，结构图应该显示高扇入低扇出，说明一个模块应该有多个控制模块，以及较少的下属模块。

程序规格：分析员对独立的模块进行的详细描述，包括程序信息、事件、输入输出、伪代码。

第十二章 数据存储设计

数据存储格式的两种基本类型：文件和数据库。

文件是被优化以执行某一特定处理事务的数据电子序列，种类：
- 主文件：储存重要的业务信息。
- 查找文件：包含用于验证主文件字段的静态值。
- 事务文件：临时存储那些用于主文件修改的信息。
- 审计文件：存储在数据发生改变时记录之前和之后的数据特征，以便当数据的整体性被质疑时可进行审计。
- 历史文件：存储已经完成的、系统已不需要的处理事务。

数据库是对在某一方面相互关联的信息组的集合，而数据库管理系统（DBMS）是创建和操作这些数据库的软件。种类：
- 遗留数据库：使用陈旧的、可能已经过时的技术，不会被用于开发新系统。
- 关系数据库：基于表的集合。能高效地支持简单类型。
- 面向对象数据库：包含用对象类所表示的数据和过程。适合存储复杂数据。
- 多维数据库：将预算的数量信息存储在维度的交叉点上。适合存储聚集的量化信息。

优化关系型数据库的两个主要维度：
- 存储效率的维度。规范化，去除冗余数据。
- 访问速度的维度。去规范化。将冗余数据重新放回。

除此之外，还可以通过聚类（将相似记录存储在邻近存储介质上）以及建立索引（一张小型表，直接指向某些匹配查询要求的记录）来提高速度。

第十三章 转换到实现

管理编程的几项任务：
- 管理编程过程：包括分配编程任务、协调各个活动、管理编程进度。
- 测试：包括编写测试计划、单元测试（确保单个程序或模块按照预定的程序规格完成其功能）、集成测试（评估一组模块或程序能否准确无误地运行）、系统测试（确保所有的程序和模块可以准确无误地执行）、验收测试（确定系统已经完成，并且系统的开发完全符合其业务需求，包括alpha测试（使用准备好的数据）与beta测试（使用真实数据））。
- 文档开发：包括系统文档（帮助程序员和系统分析员更好地理解应用软件、开发系统、维护系统，一般在开发前创建）与用户文档（帮助用户操作系统，一般在开发过程中创建）。

用户文档包括三种：
- 参考文档：当用户想要学习如何执行一个指定功能时使用。
- 程序手册：说明怎么样去执行业务任务。
- 用户指南：教给用户如何使用系统的主要构件。

第十四章 实施到新系统的转换

变更是一个分为三步的过程：解冻、变革和再冻结。

选择转换策略需要考虑的因素：
- 转换类型：分直接转换、并行转换。
- 转换位置：分引导转换、阶段转换、同时转换。
- 转换模块：分整个系统转换、模块化转换。

实现后活动：实现后活动的目的是使新系统的使用制度化，即使它成为完成业务过程正规的、可接受的和常规的方式。

三个关键的实现后活动：支持（在使用系统时提供援助）、维护（继续精炼和改进系统）和项目评估（分析项目以了解哪些活动得到了很好的执行，应该重复使用，哪些活动应当在将来项目中改进）。

第十五章 对象基础

类是用来定义和创建特定实例或者对象的通用模板。

对象是一个类的实例，每个对象有描述关于此对象信息的属性。

方法实现一个对象的行为。

封装：把过程和数据合并成一个完整实体（对象）。

信息隐藏：只公开使用一个软件模块所需要的信息给模块的使用者。

多态：不同的对象类可以对同样的信息做不同的解释。

动态绑定：将对象的类型确定延迟到运行时间的一种技术。

用任何一个面向对象开发方法来开发系统必须：（1）用例驱动（2）以架构为中心（3）迭代和增量。

四种基本的UML图：用例图、类图、时序图、行为状态机图。

用例图用来说明系统主要功能以及不同与之交互的用户。

用例图基本元素：
- 参与者：一个人或与其他系统交互并能从中得到利益的系统。
- 用例：系统将要执行的，会用某种方式给一个参与者带来利益的主要过程。
- 关联关系：用例通过关联关系与参与者连接在一起，用来显示参与者与哪些用例交互。
- 系统边界：用例被包含在系统边界内，划分了图中哪些属于系统内部，哪些属于系统外部。

创建用例图的步骤：
1. 确定用例。
2. 画出系统边界。
3. 放用例在图上。
4. 确定参与者。
5. 添加关联关系。

类图显示了系统中不随时间而变的类和这些类之间的关系。

类图基本元素：
- 类：存储和管理系统中的信息。包括属性列表和方法列表，可见性包括public(+)、protected(#)、private(-)。方法类型有Constructor（创建对象实例）、query（获取信息）、update（修改信息）三种。
- 关联：表示类与类之间的关联。可以添加基数表示数量，可以添加小实心三角表示关联的方向性。
- 泛化和聚合：泛化指一个类继承另一个类。用指向父类的空心箭头表示。聚合指一个类实际由其他类组合而成，聚合类一端有个菱形，同时与它的各个部分用直线相连。

创建类图的步骤：
1. 确定类。
2. 确定属性和方法。
3. 建立类之间的关联。

时序图是一个动态模型，用来演示参与用例中的类的实例和它们之间所传递的消息。

时序图基本元素：
- 参与者：处于系统外部且从系统中获益的人或系统。
- 对象：通过收发消息参与到序列中。
- 生命线：表示对象在序列中的生命周期。
- 控制焦点：穿插于生命线中间的扁长的矩形，标识对象何时发送或者接收消息。
- 消息：在一个对象和另一个对象间传递的消息。
- 对象销毁：当对象需要销毁时，在其生命线的末端会用一个X加以标记。

行为状态机图显示了某个类的实例在其不同生命周期的状态，它会因对象响应事件而发生改变。

行为状态机图基本元素：
- 状态：描述某个特定时间点的对象的值的集合，它描绘了对象生命周期内满足特定条件、执行某些动作、或等待事务发生的点。状态用圆角矩形表示，初始状态用实心圆表示，最终状态用一个套着实心圆的圆表示。
- 事件：触发状态改变的事情。写在转换箭头上面。
- 转换：表示对象从一个状态转变到另一个状态。