|
|
知识路径： > 信息系统开发的用户支持 > 对系统分析的支持 > 系统用户对系统分析的支持 > 系统用户对系统分析的支持 >
|
被考次数：1次
被考频率：低频率
总体答错率：66%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
相关知识点：2个
|
|
|
|
|
|
|
系统分析工作中需要用户提供的信息大致可以分为4类：关于组织的信息、关于人的信息、关于业务工作的信息和关于工作环境的信息。
|
|
|
|
|
|
组织的使命、目标和发展战略。具体来说，就是关于组织的使命、宗旨的总陈述，组织在未来若干年（比如5—7年内）的发展方向与目标，为实现组织整体和长远目标而制定的发展战略与主要措施。一般在大、中型组织中都有相应的正规文件、资料记载这方面的情况，而对于某些中小组织和正在进行重大调整和改革的组织，就需要由组织的现任主要决策者予以提供这类信息。
|
|
|
|
组织的结构。组织结构的信息反映了组织内部的管理体制、职能分配和各管理部门、层次之间的关系。信息系统是为实现组织的目标服务的，了解组织结构问题的重点在于组织目标与结构的关系。如果现有组织在支持组织的整体目标方面存在矛盾与冲突，就必须收集相关信息以明确问题所在。一般的组织都有组织结构图等相关资料，如果没有或资料已经过时而不符合实际情况，就必须进行修改或重建。
|
|
|
|
职能部门的目标与宗旨。职能部门是整个组织的子系统。各个班组、科室、处、部以及其固定的和临时的下属组织都有其自己的目标和宗旨。在实际情况中，往往这些下属组织的目标与宗旨并不与组织的整体目标相一致，因此，必须明确了解这些职能部门的目标是怎样符合或不符合整个组织目标的，只有对组织结构有较为深入的了解才能更好地认识系统中各类信息的内容和流向。有关职能部门的这类信息一般应该由各级职能部门的负责人予以提供。
|
|
|
|
规章制度与政策。这些资料能够反映一个组织进行业务活动的规则与指导方针，信息系统应该贯彻执行这些规章制度与政策。在实际情况中，明文规定的和实际执行的规章制度与政策可能会有所差别，因此，需要由具体负责运行、维护信息系统的管理人员、技术人员和操作人员予以提供并解释这类信息。
|
|
|
|
|
|
权利与责任。这类信息可以从组织结构图和某些正式的组织文件中体现出来一些，但往往实际的工作关系与组织结构图和文件上的规定有所差别，在某些问题的实际决策者可能与形式上的职务并不相同，而与具体的人的情况、传统和环境有着很大关系。有时这类信息可能需要保密，但必须要提供给系统建设的主要负责人，否则建立的系统就不可能反映管理者的实际需要。
|
|
|
|
岗位任务。主要是指在组织的业务工作进行过程中，每个人实际在做什么。因此系统用户除了要提供各项描述业务工作内容的文件，还要说明各种岗位的实际工作情况。
|
|
|
|
人际关系。主要是指反映了一个组织内部人们在工作中处于何种关系，如何相互协调与配合。由于在实际工作中，任何组织都有非正式的组织和人与人之间的联系渠道，信息的实际传递途径可能与组织结构图上所描述的并不一致。系统用户需要说明相关的实际情况，以促进新建信息系统对组织发展与业务工作的优化，保留合理的人际交流，消除不合理、容易引发混乱和失误的问题。
|
|
|
|
信息需求。系统用户要提供每个人、每个工作岗位的信息需求给系统分析人员，使之能够了解系统所涉及的每个人、每个岗位需要哪些信息以及目前实际能够得到哪些信息，为以后系统数据流图的建立与分析提供依据。系统用户应该帮助系统分析人员评价出哪些是必要的信息，哪些是无用的信息。
|
|
|
|
|
|
任务和工作流程。主要是指现有系统的业务处理的全过程，有关数据资料在系统中传递与变换的步骤和每一步的任务，特别是在上述过程与步骤中数据的结构和内容的变化。
|
|
|
|
进行工作的方法与程序。主要是指每个工作岗位做些什么，由哪些人做，使用什么设备，遵循什么规则，业务的作业如何安排。关于任务和工作流程的信息集中描述数据形式与内容，而这里集中描述行为和程序。
|
|
|
|
工作安排和工作量。主要是指在给定时间内完成多少工作，说明工作的高峰期和低谷期。
|
|
|
|
绩效准则。主要是指工作评价标准，这些标准不只是用于计划进度和工作量，而且包括质量、可靠性、准确性以及其他信息处理工作希望得到的指标。可以在现有系统中设置某些检测点或控制点，以了解系统表现并按特定准则进行评价。
|
|
|
|
|
|
主要是指工作场地的设施布局方面的信息与文件、表格、传输数据和人员在工作场地的设置和流动情况以及可用的公共设施、专用仪器设备等资源。
|
|
|
|
需要说明的是，以上只是对系统分析所需信息类型的一般性描述，并不是在每种情况下都要提供上述所有类型的信息，哪些方面的信息是要提供的重点内容，应该根据系统开发的目标和现有系统的实际情况而定。
|
|
|
|
|
|
（1）提供现有文件，包括组织结构图、规章制度与政策、工作方法与程序等有关手册、岗位说明、各类表格与报告、文件处理流程与工作流程图、现有系统流程图、现有信息系统的计算机程序文档、数据字典、计算机操作手册等。
|
|
|
|
（2）采取面谈的方式，即与信息系统分析人员直接面对面交谈来提供有关信息。面谈是和系统开发人员交流思想的好方法，它有助于双方建立相互信任的良好关系。面谈一般适合提供一些定性信息，而不太适合提供定量信息。可以考虑采取开调查会的方式，约定一个大多数用户都空闲的时间，通过大家的讨论互相补充所提供的信息内容。面谈的缺点是容易受到用户自身素质与工作性质的影响，可能有些用户不愿意当面发表自己的意见，或者由于交谈时间比较短，或者由于受条件限制无法多次面谈等原因，而使得面谈所提供的信息精确度较差。面谈可以采取两种方式：第一，自由式交谈，即自由提问和回答的方式；第二，结构式交谈，即按照事先准备的谈话提纲进行交谈，这种方式可以对给定问题提供较为可靠的回答，问题可以分层次。
|
|
|
|
（3）回答系统分析人员所提供的调查问卷。先由系统分析人员把需要调查的内容制成问卷式表格，然后由系统用户进行填写。调查表一般包括自由式和选择式两种，对于前者用户可以对所调查的问题进行自由回答，一般适用于中层管理干部对定性问题的回答；对于后者用户需要从几种备选答案中选择合适的答案，一般适用于具体工作人员或基层干部对哪些过程简单、规程清晰的业务问题做出回答。
|
|
|
|
（4）引导系统分析人员进行实地观察与实践，即带领系统分析员或计算机技术人员直接观察或参加现行系统的业务实践。这种方式有助于缩短用户与开发人员的距离，取得共同语言，提供的信息也比较准确、可靠，但是花费时间太多，而且有些业务不可能让系统分析人员亲自观察和动手操作。
|
|
|
|
|
|
当系统分析员建立好系统逻辑模型后，系统用户要承担对该模型的评价任务。评价的主要内部包括：第一，建立的系统逻辑模型是否全面准确地反映了组织对信息系统的整体目标与功能的要求；第二，建立的系统逻辑模型是否反映了各级人员的具体的信息需求。在评价过程中，系统用户进行逻辑模型评价的方式主要是，和系统分析人员就系统逻辑模型充分的交换意见，反复讨论，并进一步提出用户的意见和建议，并必须最终使用户和系统分析人员对系统的逻辑功能达成共识。在此过程中，一定要遵循用户直接参与的原则，这是系统分析工作成功的关键，也是今后系统设计与实施阶段用户与系统建设的其他人员相互支持与配合的基础。
|
|
|
|
在对系统逻辑模型进行评价的过程中，系统用户应该明确一个原则，就是系统分析工作追求的是有限目标。在信息系统建设中，由于用户单位各部门各类人员的信息需求和目标的多样性，往往造成有些目标和需求不一致，甚至相互冲突。例如，在工业生产企业中，生产部门常常希望销售部门能够尽早提供比较准确的产品市场需求信息，以便对产品的生产制定合理的安排，而销售部门则希望生产部门跟踪市场的变化来及时调整生产计划。而且，信息系统的建设是长期任务，不是一次项目开发就能够全部完成的。因此，在一次系统开发中，系统分析工作实现的目标是有限的，不可能把现有系统中所有问题都提出来，更不可能全部都去解决。一次系统开发只能满足用户的部分信息需求，做到各个相关用户大体满意，其他问题需要留待后续的系统开发项目再解决。所以，在系统分析中，既要明确本次系统开发项目要集中力量解决哪些问题，即“做什么”，也要清醒地认识这次开发中哪些问题暂时不去解决，即“不做什么”，明确系统开发任务的边界。信息系统各部分之间联系密切，如果系统开发的边界不明确，就可能造成系统开发任务在开发过程中不断扩展而使得主要任务难以完成。
|
|
|
|
系统用户还应该理解，所有软件功能都是有成本的，业务人员所希望的某些软件特性可能在技术上行不通，或者实现它需要付出极高的代价，而某些需求则是在试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。此外，有些问题并不需要一个信息系统的解决方案，而是需要做一些管理上的调整，或者是做一些附加的培训，或者是对当前组织进行精简。
|
|
|
