系统分析复习.docx
《系统分析复习.docx》由会员分享，可在线阅读，更多相关《系统分析复习.docx（15页珍藏版）》请在冰豆网上搜索。
系统分析复习
第一章
1、软件的概念：
软件是一种逻辑实体，而不是具体的物理实体
软件（software）是计算机系统中与硬件（hardware）相互依存的另一部分，它包括程序（program）、相关数据（data）及其说明文档（document）。
其中：
程序－－按事先设计的功能和性能要求执行的指令序列；数据－－使程序能正常操操纵信息的数据结构；文档－－与程序开发、维护和使用有关的图文材料
2、软件的特点软件的生产与硬件不同；软件没有明显的制造过程。
一旦研制开发成功，就可以大量拷贝同一内容的副本。
软件对硬件和环境有着不同程度的依赖性。
这导致了软件移植的问题。
软件的开发至今尚未完全摆脱手工作坊式的开发方式，生产效率低。
软件是复杂的，而且以后会更加复杂。
软件工作牵涉到很多社会因素。
软件的运行和使用期间，没有硬件那样的机械磨损，老化问题
3、软件的分类：
1.基于软件功能：
系统软件（OS，DBMS）u支撑软件（各种软件开发包等）u应用软件（各种MIS系统）
2.基于软件工作方式：
实时处理软件分时软件交互式软件批处理软件
3.基于软件规模：
微型软件小型软件中型软件大型软件甚大型软件超大型软件
4、系统开发的生命周期：
系统开发生命周期（SoftwareDevelopmentLifeCycle，SDLC）是指这样的一个过程，包括：
理解信息系统对业务需求的支持，设计系统，构建系统，以及把系统移交给用户。
计划、分析、设计、实现
各阶段的任务及结束标志
计划阶段是理解为什么要创建信息系统和确定项目团队将如何来开发它的基本过程。
计划阶段由2个步骤组成：
1）在项目启动期间，要确定系统给组织带来的业务价值。
主要通过技术可行性、经济可行性、组织可行性分析来完成。
2）项目批准后，进入项目管理。
分析：
分析阶段说明此系统由谁来用，用作什么，在哪里用，以及什么时候用这些问题。
在此阶段，项目团队调查现有系统，确定可改进的地方，以及开发新系统的方案。
主要步骤如：
1）开发分析策略来指导项目团队工作
2）收集需求
3）分析结果，系统方案和模型组合成系统建议书
设计：
设计阶段确定系统将如何运行，涉及硬件、软件和网络基础设施；将要使用的用户界面，窗口、窗体和报表；所需的专用程序、数据库和文档。
具体步骤如下：
1）创建设计策略
2）开发系统的基本架构设计，描述要用到的软、硬件和网络设施
3）开发数据库和文档规格
4）开发程序设计规格，定义需要编写的程序和每个程序确切要做的事情
实现阶段是SDLC的最后阶段，是系统实际构建阶段。
主要步骤如下：
1）系统构建2）系统安装3）建立系统的支持计划
5、系统开发方法：
结构化和面向对象
结构化：
（1）、瀑布式开发
每个阶段都是在前一阶段完成的基础之上才进行。
优点：
系统中编程之前就已确定；项目进行期间变动不大。
缺点：
编程之前需要充分的设计；需求的变动无法及时得到解决。
（2）、并行开发：
在概要设计完成之后分成多个子系统，然后分别进行设计和实现，最后再组合成一个系统。
优点：
提高了项目开发的效率。
缺点：
子项目间可能会相互影响；项目中加入了子项目的集成。
（3）、快速应用开发（RapidApplicationDevelopment，RAD）是指结构化方法的基础上创建，用于解决结构化方法中的编程之前需要充分设计和在开发过程中需求变更无法得到及时响应的缺点，使用RAD，可以使系统的部分功能更快的开发并提交给用户。
遵循RAD的方法主要有：
过程为中心，数据为中心，面向对象。
（4）、敏捷开发（AgileDevelopment）是一种新兴的开发方法，它是以编程为中心，注重简化过程，强调迭代式的开发。
遵循敏捷开发的方法主要有：
极限编程（eXtremeProgramming，XP），Scrum和动态系统开发方法（DynamicSystemsDevelopmentMethod，DSDM）
开发方法的选择主要考虑以下因素：
u用户需求的清晰度技术的属性程度系统复杂度系统可靠性项目的时间进度要求项目的进度可见性
6、文档项目文档包括所有的可交付物，有关该项目的历史记录。
常见的文档：
可行性研究报告；各种计划需求分析系统各种设计程序代码，测试脚本，数据库脚本等各种分析报告
第二章
需求分析1、可行性分析：
可行性分析主要用于辅助组织决定是否继续项目开发的依据，主要从技术、经济和组织三个方面进行分析，并综合成可行性研究报告，在项目启动阶段的末期交付给审定委员会。
技术可行性分析，即系统可以被IT团队成功的设计、开发和安装运行的程度。
主要从以下几个方面进行分析：
用户和分析员对业务应用的熟悉程度对项目开发所用到的技术的熟悉程度所要开发的项目的规模系统与其他系统的兼容性。
经济可行性分析，确定与项目相关的财务风险，确定是否值得开发新系统。
经济可行性分析步骤如下：
确定花费和收益给花费和收益指定数值定义现金流估算项目的经济价值：
回报期，平衡点，净现值无形的费用和收益：
例如客户服务的改进，社会价值的提高，企业形象的提高等。
2、系统需求是指描述创建系统的业务原因和系统预期带来的价值的文档。
系统需求包括的元素：
项目发起者，业务要求，业务需求，业务价值，其他方面的要求和约束
第三章
1、根据计划阶段确定项目的规模：
在一般的业务应用系统中，计划阶段花15%时间，分析阶段20%时间，设计阶段35%时间，实现阶段30%时间。
因此可以根据计划阶段所花的时间来估算其他阶段所需要的时间，进而得到整个项目的估算
时间。
缺点：
每个项目都是其特殊性，并不与这个典型的时间分配一致。
根据功能点：
基于功能点估算项目规模，需要先估算出项目所需的代码行，根据代码行估算所需的时间。
2、项目工作计划是用来管理列在工作分解结构（WorkBreakdownStructure，WBS）中的任务的一种机制，是项目经理管理项目的主要工具。
在项目工作计划中还体现了：
里程碑任务期限当前任务状态任务相关性里程碑
3、wbs项目管理使用的工具：
1）甘特图可以体现如下信息：
任务所需时间人力资源分配任务的先后时间关系任务的提早或延迟并发性
2）PERT图：
网状图形工具，与甘特图不同，PERT很好的体现了任务之间的依赖关系，PERT还可以计算出项目的关键路径和关键事件。
3）估算求精
4、团队的构建（掌握）：
使用合理的人员激励方式：
慎用金钱激；使用内在激励；认可；成就；工作本身的吸引力；责任感；工作晋升；新技术的学习机会
避免冲突的策略：
清晰定义项目计划；确保项目团队理解该项目对某个组织机构的重要性；创建详细的操作流程并与项目成员进行沟通；创建项目章程；创建超前的进度计划；预测项目的其他优势和可能的影
5、了解CASE工具：
计算机辅助软件工程（CASE）是一种自动生成全部或部分开发进程的策略软件。
使用CASE可以：
更好的完成和转换任务；集中开发信息并可图形化呈现；减少维护费用；提高软件性能和强化规则。
第四章：
重点：
1、需求的概念：
需求就是陈述系统必须要做的事或者系统必需具备的特征。
1）需求分为功能需求和非功能需求。
功能需求与系统必须执行的过程或必须包含的信息有直接关系。
非功能需求指的是系统必须具备的行为属性，如性能、安全性和可用性等。
功能需求：
面向过程—系统必须执行的过程和完成的任务；面向信息—系统必须包含的信息；
2）在分析阶段，从业务员角度出发，关注的是业务用户的要求，因此也称为业务需求（用户需求）；在设计阶段，主要从开发人员角度出发描述，称为系统需求。
特征，及其收集需求的技术的优缺点
2、需求的特征：
描述系统必须实现的功能；描述系统必需具备的特征；在分析阶段关注用户的要求；需求在项目的不同阶段会发生改变；
典型的非功能性需求：
1）性能表示为满足用户的需要而要求系统展示的性能－－吞吐量、响应时间
2）信息表示有关用户的信息，形式为内容、时间性、正确性和格式－－需要
输入和输出是什么，数据存储在什么地方等，对外接口
3）经济表示系统对减少开支或增加收益的需要－必须减少开支的是什么，预算限度是多少
4）控制表示系统必须在其中运行的环境以及必须提供的安全类型和程度－－访问控制，对数据的特殊处理（脱机备份等）
5）效率表示系统以最低成本产生输出的能力－－在过程中有必须消除的重复步骤，用其资源的方式中存在降低成本的方法吗
6）服务表示使系统可靠、灵活和可扩充的需要－不同类型的用户，培训、相关文档资料
3、收集需求的技术及其优缺点：
面谈，问卷，观察现场，联合应用开发，文档分析
1）面谈：
面谈通过直接、面对面的交互获取需求。
这种方式可以用来实现以下目标：
发现事实、验证事实、澄清事实、激发热情、让最终用户参与、确定需求以及征求想法和观点。
面谈的缺点：
面谈耗时，费用高；面谈的成功极大地取决与采访者的个人的能力；面谈可能会由于被采访者的地理位置功；面谈有两种类型：
结构化面谈和非结构化面谈。
非结构化面谈的特点是涉及一般性的问题，被采访者可以引导谈话过程。
这种方式容易偏离主题，采访者需要及时的引导。
结构化面谈要求采访者询问一套专门设计用于从被采访者处获取特定信息的问题，根据被采访者的回答，采访者将提出额外的问题（计划的问题或非计划的问题）以进一步深入。
准备是面谈成功的关键，面谈之前如果没有很好的准备，那么面谈就无法获得满意的结果。
在面谈之前最好准备一份面谈指南，安排好提问的问题，每个问题的时间，在什么地方可能需要进一步的提问等.在面谈的过程中，需要注意以下事项：
假定答案存在或不存在;提示线索;使用行话;显示个人偏见;谈论而不是聆听;对有关主题和被采访者的情况作出假定;使用录音－聆听能力差的表现;
2）问卷：
问卷调查表可以使分析员从一大群人那里收集到事实，同时保持统一的答复。
尤其是当需要面对大量的人时，其他调查研究技术都不可能有如此有效的得到结果。
问卷调查表的优点：
大多数的调查表可以被快速的回答；
调查表提供了一种可以以相对廉价的方式从大量的人中收集数据；
调查表可以匿名填写，因此更能得到真实的数据；回答可以快速的表格化和分析；
问卷调查表可以使分析员从一大群人那里收集到事实，同时保持统一的答复。
尤其是当需要面对大量的人时，其他调查研究技术都不可能有如此有效的得到结果。
问卷调查表的缺点：
回答者的数量经常较低；无法保证个人会回答或进一步回答所有问题；调查表往往不灵活；没有机会立即澄清对问题的含糊或不完全的回答；
制作问卷调查表：
确定必须收集什么事实和观点以及你应该从谁那里收集；根据需要的事实和观点，确定是采用自由格式还是固定格式；编写问题，确保问题中没有反映个人的偏好和观点；在小样本中进行测试，发现问题及时修正；进行调查；
3）联合应用开发：
一对一的面谈需要使用大量的时间，使用小组会议的形式进行面谈就可以解决这个问题。
JAD就是采用小组会议的形式来获取需求。
一般来说，一个成功的JAD需要负责人、主持人、用户和管理员、记录员、参与系统开发建设的其他相关人员等角色的参与。
第五章：
1、重点用例分析（10分）DFD（10分）、类图（10分）
2、建模原则（了解）建模的原则：
选择建立什么样的模型对如何发现和解决问题具有重要的影响；每个模型可以有多种表达方式；最好的模型总是能够切合实际；孤立的模型是不完整的。
任何好的系统都是由一些几乎独立的模型拼凑出来的。
UML建模（知道）背景：
1994年10月，Rational公司的Booch和Rumbaugh决定将其Booch方法和OMT方法综合成一个新的建模语言，并于1995年10月公布了UnifiedMethod0.8。
1995年秋季，Jacobson及其OOSE方法加入Rational公司，决定将OOSE方法与UnifiedMethod进行综合，更名为UML，并分别于1996年6月和10月公布了UML0.9和UML0.91。
1996年，DEC、HP、I-Logix、Intellicorp、IBM、ICON、MCI、Microsoft、Oracle、Rational、会，于1997年1月推出了UML1.0，并向OMG申请将其作为一种标准语言。
1997年9月产生了UML1.1，11月被OMG正式采纳。
1999年6月，OMG发布了UML1.3。
1999年7月，UMLRealTime随RoseRealTime推出。
2001年9月，OMG发布了UML1.4。
2004年4月，OMG发布了UML1.5。
2005年7月，OMG发布了UML2.0。
用例：
描述了一系列执行的活动所产生的一些输出结果。
每个用例描述了外部用户如何来触发系统必须响应的事件。
在事件驱动模型中，系统的一切行为都被认为是对某个触发事件的响应。
相关：
用例是由外部用户触发；每个用例只描述单独的任务，而不能描述多个任务；用例必须产生一个对用户有意义的结果；场景（Scenario）是用例的一个执行实例，是例执行；过程中的一条实际路径，一个用例可能会包含多个场景；
UML中的用例视图只能反映出两类信息：
1）哪些外部用户会和统发生交互
2）系统需要实现哪些功能特性
基本信息：
1）每个用例都有一个名称、编号和简要描述。
为了明确标识某些用例在整个系统中的相对重要性，需要使用优先级来表示。
用例（usecase）是一个行为上相关的步骤序列，代表的是一个相对完整的业务任务。
UML中的用例是动作步骤的集合。
动作（action）是系统的一次执行（能够给某个参与者输出结果值）。
与参与者通信，或进行计算，或在系统内工作都可以称作动作。
用例应支持多种可能发生的动
作，每个动作由许多具体步骤实现。
2）用例的元素：
参与者是存在于系统之外并与系统交互的人或事。
所谓“与系统交互”指的是参与者向系统发送消息，从系统中接收消息，或是在系统中交换信息。
参与者是一个群体概念，代表的是一类能使用某个功能的人或事，参与者不是指某个个体。
3）输入和输出每一个用例的主要输入、输出连同其来源和目的都要进行描述。
它包括所有可能的输入输出，而不仅仅是用来通常用的部分。
建造用例是一个逐渐提炼的过程，用例在分析的过程中可以逐步的完善。
4）细节：
用例需要描述详细的步骤和它们所使用到的输入和输出，这些步骤就是用例中所执行的活动。
第六章
1、活动图的概念：
活动图（activitydiagram）显示了组成复杂过程的步骤序列，如工作流或算法。
活动图是对系统的行为进行建模，活动图是把系统的一项行为表示成一个可以由计算机、人或其他执行者执行的活动，通过给出活动中的各个动作以及动作之间的转移关系来描述系统的行为。
2、活动图与流程图的区别：
流程图着重描述处理过程，它的主要控制结构是顺序、分支和循环，各个处理之间有严格的顺序和时间关系；而活动图描述的则是对象活动的顺序关系所遵循的规则，它着重表现的是系统的行为，而非系统的处理过程。
活动图能够表示并发活动的情形，而流程图做不到。
活动图是面向对象的，而流程图是面向过程的。
3、使用活动图的目的：
描述一个操作执行过程中（操作实现的实例化）所完成的工作（动作）；描述对象内部的工作；显示如何执行一组相关的动作，以及这些动作如何影响它们周围的对象；显示用例的实例是如何执行动作以及如何改变对象状态；说明一次业务活动中的工人（角色）、工作流、组织和对象是如何工作的。
4、活动图的组成：
1）动作是构成活动的基本单位，它是原子的、不可中断的，并在动作完成后通过完成转换转向另一个状态。
动作的特点：
动作是原子的，不可以分解成更小单位；动作是不可中断的；动作是瞬时完成的行为；动作可以有入转换，至少有一条出转换；动作不能有入口动作和出口动作；在一张活动图中，动作允许出现多次；2）活动是由一系列动作构成的，是对一项系统行为的描述。
活动的特点：
活动可以分解成其他子活动或动作；活动的内部活动可以用另一个活动图来表示；活动可以有入口动作和出口动作，还可以有内部转移；3）动作流4）条件是让转移修改任何工作流的方向所必须的。
5、顺序图：
顺序图（SequenceDiagram，时序图，序列图）详细描述对象间传送消息的时间顺序，它表示用例中的行为顺序。
顺序图它详细而直观地表现了一组相互协作的对象在执行一个（或少量几个）用例时的行为依赖关系，以及操作和消息的时序关系。
类图对对象之间的消息（交互情况）表达不够详细；详细说明对消息的表达虽然详细，但不够直观；顺序图既详细又直观，但通常只能表示少数几个对象之间的交互。
2）活动对象：
活动对象可以是系统的参与者或任何有效的系统对象。
在活动图中对象的标记如下图所示。
将对象置于时序图的顶部意味着在交互开始的时候对象就已经存在了，如果对象的位置不在顶部，那么表示对象是在交互的过程中被创建的。
生命线是一条垂直的虚线，表示时序图中的对象在一段时间内的存在。
每个对象的底部中心的位置都带有生命线。
生命线是一个时间线，从时序图的顶部一直延伸到底部，所用的时间取决于交互持续的时间。
对象与生命线结合在一起称为对象的生命线，对象的生命线包含矩形的对象图标以及图标下面的生命线。
如果对象在图中被创建，那么对象符号画在创建它的消息上，否则画在任何消息箭头上。
如果对象在图中被撤销，那么用“×”表示撤销。
消息定义的是对象之间某种形式的通信，它可以激发某个操作、唤起信号或导致目标对象的创建或撤销。
消息是两个对象之间的单路通信，从发送方到接收方的控制信息流。
消息可以用于在对象间传递参数。
消息可以是信号，也可以是调用。
在UML中，消息使用箭头来表示，箭头的类型表示了消息的类型。
6、类图：
是描述类、接口、协作以及他们之间关系的图，用来显示系统中各个类的静态关系。
属性和操作
2）分析类的类型：
实体类：
用于对必须存储的信息和相关行为进行建模
边界类：
用于软件产品和它的参与者之间的交互行为建模
控制类：
用于对复杂的计算和算法建模
3）类的属性的可见性：
Public：
以＋表示Private：
以－表示Protected:
以＃
4）类间的关系：
常用的类之间的关系有4种，分别是表示对象之间结构关系的关联关系，表示类之间一般和特殊关系的泛化关系，表示类之间使用关系的依赖关系，以及表示类中规格说明和实现之间的关系的实现关系。
a）关联关系的类型：
普通关联关系递归关系聚合关系组合关系
7、数据流图
过程模型是表示业务系统运行的一种形式化方法，它演示了系统执行的过程或活动，以及数据在它们之间是如何流动的。
数据流图（DataFlowDiagram，DFD）是以图形的方式描述系统业务流程以及系统内数据传递的一种技术。
2）数据流图基本元素：
a）过程是为特定业务原因而执行的活动或功能。
过程可以是人工或计算机化的。
每个过程必须至少有一个输入数据流和一个输出数据流。
B）
数据流是单个数据或是一些信息的逻辑集合。
数据流和过程是一起出现的，每个数据流总是从一个过程流出或流入一个过程，箭头显示了数据流入或流出的方向。
C）数据存储是以某种方式存储的数据集合。
数据存储构成数据模型的起始点，是过程模型和数据模型的主要连接点。
D）外部实体是位于系统范围之外但与正在被研究的系统交互的人、组织部门或是其他系统，外部实体与用例中的主要参与者相对应，外部实体为系统提供数据或从系统获取数据，并且形成了系统的边界。
（矩形）
第6章（5）
数据字典（简答题）
符号
含义
例子
=
被定义为
+
与
x=a+b，则表示x由a和b组成
[,][|]
或
x=[a,b]或x=[a|b]，则表示x由a或由b组成
{}
重复
x={a}，则表示x由0个或多个a组成
m{}n
重复
x=3{a}8，则表示x中至少出现3次a,最多出现8次
（）
可选
x=（a），则表示a在x中出现,也可不出现
*…*
注释
表示在两个*之间的内容为词条的注释
…
连接符
month=1..12表示month可取1到12中任意一个值
例：
手机号=1+[[3,5]+[0…9],47,8+[2,7,9]]+8{0…9}
学号=入学年份+学院代码+专业代码+班级代码+座号
入学年份={00…99}学院代码=30
第7章
设计阶段的活动主要是：
（了解）
♦确定合适的系统获取策略
♦设计系统的架构
♦选择软硬件
♦设计系统人机接口
♦从逻辑模型到物理模型的转换
♦设计能完成系统过程的程序
♦从逻辑数据模型到物理数据模型的转换
♦设计数据存储方案
♦编写最终的系统规格
常见的设计错误有：
（掌握）
减少设计时间；需求蔓延；过于依赖技术和工具；在项目中间阶段更换工具。
构造新的应用系统的方式：
（理解）
1.定制开发
优点
缺点
灵活
符合现有的技术和标准
提高组织内部人员的技能水平
需要大量的时间和精力
可能无法短时间内完成
对技术、技能的要求较高
一般需要比较大的投入
面临项目失败的风险
2.购买软件包
优点
缺点
由于有相同或相似的业务需求而不必全新开发
购买软件包可以节省时间和成本
现成的软件包无法完全适用
组织无法提高开发能力和技能水平
3.第三方外包开发
优点
缺点
可以实现组织内技术无法完成的系统
可以节省时间和成本
机密信息泄密的风险
无法控制系统的后续开发
失去技术能力提高的机会
原则：
保持与外包商之间的沟通通畅u在签订合同前详细说明并稳定需求
视外包关系为合作关系u仔细选择供应商、开发者或服务提供者
指派一个人去管理与外包商的关系u不要外包所不清楚的东西
强调灵活的需求、长期的关系和短期的合同
影响设计策略的因素
1.业务需求
对于通用的业务需求，并且有比较成熟的技术解决方案，使用定制应用程序比较容易。
对于独特的或专用的需求，则选择开发系统。
一般来说，如果业务需求不是公司策略的关键元素，可以选择外包。
2.项目技能
在项目中应用的技能既可以是技术性（如开发语言）的，也可以是功能性（如电子商务）的，不同设计方案的选择取决于这些技术在公司策略中的重要性。
3.项目管理
定制应用程序要求有较强的项目管理和被证实的方法论。
在项目进展过程中，项目可能受到来自各个方面因素的影响，如果没有较强的项目管理能力则项目很可能就面临困难。
购买和外包软件也同样需求项目管理，而且这种管理更多的来自于组织外部的沟通和交流。
4.时间约束
当项目存在时间的约束时，首先应该寻找一个已经建立和经过测试的系统。
但利用外包来创建一个系统的时间取决于系统和外包商的资源，如果服务提供者没有提供合适的服务，那么采用外包来解决所花费的资源可能与定制开发一样。
第8章（综合应用）
常用的软件体系结构
1.主机/终端
2.文件/服务器
3.客户/服务器结构（C/S）
客户机（Client）和服务器（Server）都是独立自主的系统，它是一类按新的应用模式运行的分布式计算机系统。
在这个应用模式中，用户只关心完整地解决自己的应用问题，而不关心这些应用问题由系统中哪台或哪几台计算机来完成。
优点
缺点
开放系统
可以有效利用资源，提高可靠性
较高的系统性能
管理困难
开发环境复杂
实现比较困难
4.浏览器/服务器结构（B/S）
优点
缺点
具有分布性特点，可以随时随地进行查询、浏览等业务处理。
业务扩展简单方便，通过增加网页即可增加服务器功能。
维护简单方便，只需要改变网页，即可实现所有
升级会员 