管理信息系统复习重点.docx
《管理信息系统复习重点.docx》由会员分享，可在线阅读，更多相关《管理信息系统复习重点.docx（19页珍藏版）》请在冰豆网上搜索。
管理信息系统复习重点
信息系统（IS）:
是人、数据、过程和信息技术之间相互作用，收集、处理、存储和提供支持企业运作信息的集合体。
Informationtechnology信息技术：
是计算机技术和电信技术相结合的产物。
MIS=IS+Management（Business）管理信息系统是信息系统在管理领域的应用，是利用信息技术对管理问题的解答。
支持操作层的系统——运作级信息系统：
事务处理系统（TPS）
支持知识层的系统——知识工作信息系统：
通信和协作系统（CCS）、专家系统（ES）办公自动化系统（OAS）
支持管理层的系统——管理人员信息系统：
管理信息系统（MIS）、决策支持系统（DSS）
支持战略层的系统——主管信息系统：
经理信息系统（EIS）
TPS:
用来处理和记录为从事商务活动所必要的日常事务的计算机系统。
ES:
捕捉技术专业人员的专业知识（知识库），然后模拟这些专业知识为非专家服务的信息系统。
MIS:
服务于管理层，为规划、控制、决策提供日常统计分析和预测报告的信息系统。
MIS为组织内管理人员观察、控制组织的的运行提供支持。
DSS：
利用模型和综合数据支持半结构化和非结构化决策的信息系统。
DSS为组织的决策提供信息和方案支持。
EIS:
服务于组织的战略层，帮助高层经理人决策，主要利用图形和通讯来支持非结构化问题决策的信息系统。
关联人员stakeholder：
利益相关者，包括技术和非技术人员。
Informationworkers信息工作者（信息工人）：
指在工作中涉及到创造、收集、处理、分发和使用信息的人。
Knowledgeworkers知识工作者：
其工作基于专业化知识的人。
五大关联人员：
系统分析员和项目经理、系统所有者、系统用户、设计人员、构造人员。
Internalusers：
Clericalandserviceworkers（办事员和服务人员）Technicalandprofessionalstaff（技术、专业人员）Supervisors,middlemanagers,andexecutivemanagers主管和各层经理
Externalusers：
Customers、Suppliers、Partners、Employees。
Remoteusers远程用户：
不在办公地点，仍需访问信息系统的用户。
Mobileusers移动用户：
位置经常变化，仍需从任意地点访问信息系统的用户。
系统分析员：
研究组织存在的问题和需求，确定人员、数据、过程和信息技术如何最大化的为企业做出贡献。
programmer/analyst（oranalyst/programmer）程序员/分析员
businessanalyst：
业务分析员专注于系统分析和设计中的非技术方面。
系统分析员既懂业务又懂计算机技术。
系统分析员（解决问题的人）解决的问题:
Problems：
（实际存在的问题）Opportunities：
（发展的机会）Directives：
（强制指令）
系统分析员所需技能：
有效的信息技术知识、计算机编程经验、商务知识、解决问题能力、良好的沟通能力、良好的处理人际关系、灵活性和适应能力、人格和职业道德。
业务驱动力：
经济全球化、电子商务和电子业务、安全和隐私、CollaborationandPartnership（协作与合伙经营）KnowledgeAssetManagement（知识产权管理）ContinuousImprovementandTotalQualityManagement（持续过程改进和全面质量管理）BusinessProcessRedesign（业务流程重组）
KAM:
Data对事物的客观描述、记录。
Information数据被处理后对人有意义（消除不确定性），成为信息。
Knowledge接收者对数据、信息的进一步提炼、验证成为知识。
技术驱动力：
网络和因特网、移动和无线技术、对象技术、CollaborativeTechnologies（协作技术）EnterpriseApplications（企业应用软件）
对象技术：
一种软件技术，采用了封装数据和行为的对象来定义系统。
优点：
1对象是可复用（reusable）的，减少开发时间、节约成本2对象是可扩展（extensible）的，减少维护、改进软件的成本3OO语言：
C++,Java,等
Agiledevelopment（敏捷开发）是一个包括不同工具和技术的工具箱，可以从中选出最合适的工具或技术来解决在系统分析中遇到的问题。
4类协作技术：
电子邮件、即时消息、群件、工作流。
EnterpriseApplicationIntegration（EAI）企业应用集成：
用来链接应用软件以支持应用软件之间的数据和信息流的过程和技术。
Middleware–中间件用来在不同应用系统之间转换和路由数据的软件（通常是购买）
系统启动：
产生一个业务问题陈述和项目计划，确定要用技术方案解决的问题的范围、.目标、进度和预算。
系统分析：
产生系统用户对业务问题方案的业务需求、预期和优先级的陈述
系统设计：
产生对应实现业务需求的方案的技术蓝图和规格说明
系统实现：
按照技术体系结构和规格说明，产生业务问题的软硬件技术方案
Owners和Users关注系统的三个业务目标：
增加业务知识、改进业务过程和服务、增强业务沟通和协作（与技术无关、与业务相关）
Designers和Builders关注系统的三个技术目标：
数据库技术支持企业积累和使用业务知识、软件技术支持（自动化）业务过程和服务、接口技术支持业务通信和协作。
IS关注的三个维度（视角）:
Knowledge—业务知识来自数据和信息Process—（业务过程实现企业目标）Communication—（交互）
ViewsofPROCESS:
Systemowners’viewBusinessfunction–销售、生产、服务、发货、验收、会计。
Systemusers’viewBusinessprocesses–业务过程是对业务事件的响应。
Processrequirements–描述一个新系统的业务过程如何完成，常用活动，数据流，工作流的方式。
常由一些策略和规程得来。
Policy：
一系列约束业务过程的规则Procedure：
一步步实现业务的指令和逻辑。
Workflow（工作流）–theflowoftransactionsthroughbusinessprocessestoensureappropriatechecksandapprovalsareimplemented。
通过业务过程以确保适当的检查和批准得以实现的事务流。
Systemdesigners’view技术选择受到软件框架标准的限制。
应用程序：
基于计算机设计语言的可以被机器读取的表示，表示了软件过程可以做什
系统开发过程：
是一组活动、方法、最佳实践、交付成果和自动化工具、系统开发的关联人员用它们来开发和维护信息系统及软件。
CapabilityMaturityModel（CMM）–能力成熟度模型框架帮助组织改善其系统开发过程的成熟度，包括五个等级：
Level1—初始级:
软件过程是混乱无序的,没有一定的标准,成功依靠的是个人的才能和经验。
开发过程不可预测，不可重复。
Level2—可重复级:
建立了基本的项目管理过程。
按部就班地设计功能、跟踪费用,根据项目进度表进行开发。
对于相似的项目，可以重用以前已经开发成功的部分。
Level3—已定义级:
使用一个标准的开发过程，软件开发的工程活动和管理活动都是文档化、标准化的，所有项目的开发和维护都遵循这个标准。
Level4—已管理级:
建立了可度量的质量和生产率目标。
对软件过程和产品质量有定量的理解和控制。
Level5—优化级:
在第四级的基础上，持续的监督和改进。
系统生命周期：
系统开发阶段+系统运行和维护阶段。
系统开发方法：
结构化快速应用开发（ArchitectedRAD）动态系统开发方法（DSDM）联合应用开发（JAD）信息工程（IE）快速应用开发（RAD）Rational统一开发过程（RUP）结构化分析与设计极限编程（XP）
系统开发基本原理：
让用户参与、使用一套问题解决步骤、确立开发阶段和开发活动、在开发过程中记录文档、建立标准、管理过程和项目、将信息系统视为重要投资、不必害怕取消和返工、分而治之、设计系统时应该考虑到增长和变化。
成本效益：
是在开发、维护和运行信息系统的成本和从系统中获得效益之间去的平衡。
系统开发项目的启动原因：
问题、机会、指示。
指导委员会：
系统所有者和信息技术主管组成的管理机构，他给候选的系统开发项目排序并批准相应项目。
ThePIECESProblem-Solving：
P性能、I信息、E经济、C控制、E效率、S服务
系统开发8个阶段：
范围定义、问题分析、需求分析、逻辑设计、决策分析、物理设计、构造和调试、安装和发布。
范围定义阶段：
回答两个问题：
1.这个项目值得考虑么？
2.确定项目的范围、目标、约束和限制条件以及所需的项目参与者、预算和进度。
范围定义：
通过记录初始范围，为控制（预算和进度）的范围蔓延建立一条基线。
输入：
工作陈述：
管理层和用户团体之间的开发或提升某个信息系统的合约。
交付物：
问题陈述：
是对问题、机会、和指示的描述和分类，也可能包括约束条件和对解决方案的一个初始视图。
问题分析阶段：
输出：
“系统改进目标”，这些目标同时也是新系统的评价标准。
菱形检查点，决定项目是取消（问题不值得解决）还是进入下一个阶段。
需求分析阶段：
系统需要为用户提供何种功能、Whatdatamustbecapturedandstored?
性能需求、需求的优先级。
交付物：
业务需求陈述
逻辑设计：
Systemmodel–apictureofasystemthatrepresentsrealityoradesiredreality。
系统模型有利于系统分析员、用户、所有者、设计者之间进行沟通交流。
交付物：
逻辑设计模型和规格说明。
决策分析：
（技术可行性）（运行可行性）（经济可行性）（进度可行性）（风险可行性）
交付物：
系统建议方案。
物理设计和集成：
两种物理设计的极端情况（通常是两种的结合）完全按照规格说明设计、按原型设计。
交付物：
物理设计模型和规格说明、设计原型、重新设计业务过程。
构造和测试阶段：
Software、Databases、UserandSystemInterfaces、Hardware、Networks
交付物：
功能系统。
安装和发布：
（交付）、（培训）、（文档）、遗留系统数据导入、系统切换的策略。
交付物：
运行系统
系统运行和维护：
Systemsupport：
辅助用户、修正软件缺陷、恢复系统（病毒、错误操作）、调整系统适应新需求。
跨生命周期活动：
Fact-finding（调查研究）（文档记录和演示汇报）可行性分析）（项目管理和过程管理）
Fact-finding：
调研、面谈、调查表、会议、抽样等。
Waterfalldevelopmentapproach瀑布方法，一个阶段结束另一个阶段开始，部分阶段有重叠。
Iterativedevelopmentapproach迭代开发：
完成足够的分析、设计和实现尽快投入运行，以便发布下一个版本，直到整个系统所有部分实现。
Model-drivendevelopment（MDD）–强调绘制模型以可视化地分析问题、定义业务需求以及设计信息系。
过程建模、数据建模、对象建模。
优点：
1需求说明往往更全面、详细和文档化。
2使用图形比语言更容易验证需求和设计。
3设计更合理、稳定，因为它们是基于模型的，在构造前被全面分析过。
4首次构造的成功率大。
不足：
1消耗大量时间；2模型仅能达到和用户一样的需求理解程度；3图形不是软件，降低了用户在项目中的主要参与程度；4、MDD呆板、不灵活。
RAD基本思想：
1让系统用户更主动地参与到分析、设计和构造活动中来；2组织一系列重点突出的研讨会让所有者、用户、分析员、设计人员和构造人员一同参与；3通过迭代和构造方法加速需求分析和设计阶段；4使用户更早的看到一个可工作的系统；5原型最后会进化成最终的信息系统。
Prototype一个小规模的，有代表性的的可工作的模型。
反映了信息系统的用户需求或建议设计。
RAD重点是缩短开发应用软件的时间，所以合并阶段加速，简化个阶段交付物，成为“初始的”，因为随着项目进展会改变。
优点：
1适用于用户需求不确定或不明确的项目。
2鼓励用户和管理层主动参与，项目得到更多支持。
3看到可工作的基于软件的方案更快。
4在原型中错误能更早发现。
5迭代方法显的更自然，因为开发过程中变化是必然的。
不足：
1RAD鼓励编码、实现和修改，这增加了运行、支持和维护系统的费用；2因为简化问题分析，原型可能解决了错误的问题；3可能不鼓励分析员考虑其他更有价值的方案；4参与者不愿抛弃原型，认为损失时间和精力；5对速度的重视会对质量造成影响，因为原型中可能充满了不合理的捷径。
商用应用软件开发路线：
建议申请书、报价申请书、差距分析（购买软件不能满足哪些需求）优点：
1更快的实现系统；2许多企业没有人力和专业知识进行内部开发；3应用软件供应商可以不断投资改进软件；4同行业许多企业的功能相似性多于差异性。
不足：
１如果软件供应商停止供应，会失去技术支持和未来改进；２为了适应软件须改变原有业务流程，这会带来阻力.
增量实现策略（混合策略）：
ＭＤＤ和ＲＡＤ的组合。
选择开发路线在范围定义阶段决定并记入工作陈述。
ＣＡＳＥ工具：
作图工具、字典工具、设计工具、质量管理工具、文档记录工具、设计和代码生成工具。
３类自动化工具用于系统开发：
ＣＡＳＥ计算机辅助系统建模；ＡＤＥ应用环境开发；项目和过程管理器。
正向工程：
系统模型生成初始软件或数据库代码；逆向工程：
相反
加速分析法：
（获取原型、快速架构分析）；需求获取：
（调查研究技术、联合需求计划）
业务重构法；敏捷方法。
Systemsanalysis–是一种问题解决技术，它将一个系统分解成各个组成部分，研究各个部分如何工作、如何交互，以实现系统目标。
Systemsdesign–是对系统设计的补充，它将系统的组成部分重新装配成一个完整系统（希望得到一个改进的系统）。
这可能增加、删除和改变原始系统的某些部分。
1.分析重点是对问题和需求的调查研究，获取需求，并不提出解决方案2.设计强调满足需求的解决方案（软件和硬件），而不是如何实现。
范围定义阶段任务：
１列出问题和机会；２协商项目初步范围；３评估项目价值；４计划项目进度与章程；５汇报项目计划。
交付成果：
项目章程。
问题陈述：
问题、机会或指示
紧迫性
可见性
年收益
优先级
建议的方案
问题分析阶段任务：
１研究问题领域；２分析问题和机会；３分析业务过程；４确定系统改进目标；５修改项目计划；６汇报调查结果和建议。
问题分析矩阵（因果分析事例）
因果分析是一种研究问题以确定其原因及结果的技术。
ＤＥＭＯ
需求分析阶段定义一个系统的业务需求，回答问题：
“用户需要什么，想从新系统中得到什么？
”任务：
１定义需求；２排列需求的优先次序（使用时间盒技术）；３修改项目计划；４交流需求陈述。
交付物：
业务需求陈述。
功能需求：
描述一个系统必须提供的活动和服务。
包括输入、输出、过程、存储数据。
非功能需求：
描述一个满意系统的其他特征、特点和约束条件。
ｅｇ：
性能、易学易用性、预算、开支和开支节省等。
逻辑设计阶段任务：
１.１立功能需求的原型；１.２结构化功能需求；２验证功能需求；３定义验收测试用例。
交付物：
系统模型或原型
决策分析阶段任务：
１确定候选方案；２分析候选方案；３比较候选方案；４修改项目计划；５推荐一个系统方案。
ＤＥＭＯ
以用户为中心的开发–重点是理解关联人员的需求。
Use-casemodeling–使用业务事件、发起事件的人，以及系统如何响应这些事件，来建模系统功能的过程。
用例建模来源于面向对象建模技术，但该技术在非对象开发方法中也比较流行，因为它被广泛认为是定义、记录和理解信息系统功能需求的最佳实践。
用例建模优点：
1提供了一个捕捉用户需求的工具；2将系统分解成更易于理解（掌控）的小块；3提供了与用户及其它关联人员进行交流的工具；4提供了确定、分配、跟踪、控制和管理系统开发活动（尤其是增量和迭代开发）的手段；5为定义测试计划和测试用例提供基础；6为用户文档和系统开发文档提供基准；7提供了需求跟踪的工具；8提供确定数据对象和实体的起点；9提供了用户和系统接口的说明；10提供了驱动系统开发的一个框架。
用例是一系列行为上相关的步骤（场景），既可以是自动的也可以是手工的，其目的是完成一个单一的业务任务。
（在需求阶段定义，并在整个生命周期中细化）
包括两部分：
Use-casediagram：
用例图Use-casenarrative：
用例描述
一个用例所描述的场景可能包含一个或多个需求。
Actor–需要同系统交互以交换信息的任何事物。
Temporalevent–asystemeventtriggeredbytime。
Theactoristime。
Association（关联关系）有箭头的表示参与者发起用例；没箭头的表示参与者是接受者。
UseCaseExtendsRelationship（扩展关系）
Extensionusecase–一个用例可能包含多个步骤的复杂功能，使得用例难以理解。
为了简化，将较复杂的步骤提取成专门用例，成为扩展用例，它与原用例间是扩展关系。
一个用例可有多个扩展用例，扩展用例不能被其他用例调用。
带箭头实线/虚线，起点扩展用例、终点被扩展用例。
使用（包含）关系Abstract–多个用例包含相同的功能步骤，把公共步骤提取成抽象用例，降低冗余，代表某种形式的“复用”。
抽象用例可以被其它用例调用，箭头指向抽象用例。
依赖关系DependsOn–决定用例开发的顺序，箭头指向依赖的用例。
继承关系Inheritance当多个参与者共享同样的行为时（发起相同的用例），可以将这些公共行为分配给一个新的抽象参与者，减少与系统的通信。
其它参与者可以继承此抽象参与者。
需求用例建模过程（构造需求用例的目的是提取和分析需求信息，模型表示用户需要什么，不涉及如何构造和实现）Steps：
（1、确定业务参与者2确定业务需求用例3构造用例模型图4记录业务需求用例描述（首先在高层记录，再扩展。
）
BusinessRequirementsUseCase业务需求用例：
（捕捉与用户的交互，并没有技术和实现细节）一个系统可能包含许多用例，在需求分析阶段，出于时间和经费的考虑，我们仅粗略关注最关键、最复杂的用例，常称为基本用例（EssentialUseCase）
Usecases通常使用动词词组命名（i.e.提交订单）
Use-casemodel可以驱动整个系统开发过程。
完成需求用例后，项目经理和系统分析员可以用需求用例安排项目计划。
决定用例重要性：
分级和评估用例、确定用例依赖关系。
用例分级和评估矩阵：
决定用例优先级。
首先开发最重要用例。
用例的依赖关系图优点：
系统事件的图形化表示有利于对系统功能的理解；有利于确定遗漏的用例；通过描述哪个用例更关键并需要最高优先权，有助于推动项目管理。
数据建模的方法步骤：
1获取实体；2构造上下文数据模型；3构造基于键的数据模型；
4构造具有完整属性的数据模型；5构造完全描述的模型；6构造一个称为规范化的过程分析完成的数据模型的可适应性和灵活性。
Datamodeling：
组织和记录系统的数据技术。
ERD
Entity–是我们需要收集数据和存储数据的人、地点、对象、事件或概念的类。
Compoundattribute（组合属性）Relationship关系（双向的）
键：
一个属性或一组属性，对每个实体实例具有唯一的值，又称标书符。
Concatenatedkey（组合键）Candidatekey（候选键）Alternatekey（替代键）–acandidatekeynotselectedtobecometheprimarykey.
Cardinality基数：
定义了一个实体相对于另一个关联实体的某个具体知的最小和最大值。
Degree（维度）参与关系的实体数量。
recursiverelationship递归关系
关联实体：
一个从多个其他实体继承其主键的实体。
非确定性关系–每个参与关系的实体都有各自独立主键的关系。
虚线符号。
确定性关系–父实体贡献其主键成为子实体主键的一部分。
实现符号。
非特定关系：
是一个实体的多个实例同另一个实体的多个实例相关联的关系，多对多
通过关联实体分解多对多关系，且关联实体为子实体。
Generalization（泛化）：
将几类公共的属性组合成独立的实体。
Supertype超类----从实体中抽出部分公有属性形成实体超类。
Subtype实体子类继承实体超类的公有属性。
实体超类和实体子类是一对一关系通过继承实体超类的属性，可以减少实体子类的属性，降低全部属性总数。
公共属性集中在实体超类中，方便维护。
好的数据模型：
简单，基本无冗余，灵活的可适应性。
Normalization规范化
数据—地点—CRUD矩阵
过程建模步骤：
1构件内外关联图（contextdiagram）说明系统与其环境的接口；2进行事件划分，将事件组织成功能分解图（functionaldecompositiondiagram）；创建事件响应和用例清单；４绘制事件图（eventdiagrams）；５将事件图合并成系统图（systemdiagram）；６绘制基本数据流程图（primitivedataflowdiagrams）；７使用数据结构（datastructures）和过程逻辑（procedurallogic）描述基本数据流和过程。
使用数据—过程—ＣＲＵＤ矩阵同步数据模型和过程模型；过程分布：
过程—位置—关联矩阵
Processmodeling–组织和记录系统过程的技术。
（DFD）–一种描述数据通过系统的流程以及系统实施的工作或处理过程的过程模型。
DFD成为业务流程重组（businessprocessredesign）的工具
外部代理/实体：
系统的边界和范围名词。
DataStores（数据存储）datastore描述的是静止的数据，而dataflow描述的是运动的数据。
（depictedonanERD）数据存储同步了数据模型和过程模型ERD中每个实体都应该有一个数据存储（包括关联实体和弱实体）名词。
系统模型最简单的过程模型是基于输入、输出和系统本身（被看做一个过程）
过程建模帮助我们理解系统如何与外界进行交互。
用动词+名词进行命名
分解图Decompositiondiagram–描述系统分解的工具，也称层次图。
过程的命名取决于它在分解图中的位置
Function（功能）–较高层次的名词命名：
订单管理，材料管理Event（事件）中等细节的：
必须作为一个整体完成的逻辑单元。
如：
处理客户订单，响应订单查询；Elementaryprocess（基本过程、原子过程）：
为完成一个事件响应所需的离散的详细活
升级会员 