第一篇:02 论信息系统开发的变更控制
论信息系统开发的变更控制
摘要:
2004年10月,我作为项目的总负责人对本人所在的某大型三甲医院的信息管理系统进行了建设。在建设过程中为避免各种变更带来的影响,我建立了严格的变更控制流程,根据变更涉及的部门组建临时变更控制委员会,对各种变更需求进行分析评估,并跟踪批准的变更,进行变更结果的反馈;采用VSS工具进行了有效的变更管理,避免了版本管理上的混乱。最后,在总结经验教训的基础上提出了在变更控制委员会下建立变更控制小组,以便高效地处理普通变更需求;同时建议在用户操作界面开发的过程中采用快速原型化的方法加强与用户的沟通,避免重复开发。整个项目于2006年5月通过总体验收,按期、高质量地完成了建设任务,同年底被评为湖南省2006年信息化建设百家优秀案例。项目的成功很大程度上归功于对变更的有效控制和管理。
正文:
某医院作为全省最大的综合性医院,年门诊量180万人次,年出院5万人次,原有手工业务模式造成了医院就医流程不合理、工作效率低下、无法实现科学的量化管理等突出问题。为了解决上述问题,医院于2004年爪月与某重点高校及其所属某软件公司三方签署了合作协议及开发合同。借助高校的技术优势,合作建设医院信息系统,以下简称HIS。
我作为医院信息中心的主任,被任命为该合作项目的总负责人,担任项目的规划、设计、开发、实施等方面的管理工作。
该HIS项目建设的主要内容分三部分:一是对医院原有手工流程的优化改造,建立计算机网络环境下的医疗业务模式。二是按照卫生部《医院信息系统功能规范》的要求进行临床诊疗、药品管理、经济管理、综合管理与统计分析、外部接口五大部分,包括医护工作站、药库药房管理、输血管理、手术麻醉管理、挂号收费,住院结算、设备仓库管理、经济核算、病案统计、院长查询与分析、医保接口等共32个子系统的开发,涉及医院所有的管理、医疗和后勤保障部门。三是在不影响医院业务秩序的情况下进行部分新旧系统的切换和新系统的上线实施工作。系统采用三层C/S体系架构,数据库0rac1e9i,开发工具Powerbui1er8.0,采用两台 5670小型机作数据库服务器,两台570做应用服务器。
该项目需求分析阶段的任务最为艰巨。不仅要调研清楚相关部门的业务内容和系统要实现的功能,而且要进行医院网络环境下的业务流程设计。由于大多数部门没有接触过相关的计算机业务系统,无法提供明确完整的业务需求,更不用说帮助设计业务流程了。我在需求分析阶段,以医院信息中心的工作人员为主,凭借对医院业务的了解和计算机知识的掌握,以卫生部医院信息系统功能规范为基础,对各部门显性需求进行了收集,并对没有提出的隐
性需求进行了挖掘,同时结合兄弟医院成功的系统业务流程,设计出了相对合理的网络业务流程。
在本项目开发的过程中,可能引起需求和开发变更的因素主要包括:(1)已确认的业务流程的变更:由于医院在项目建设之前没有基于网络环境下的业务应用经验,并且大型医院的管理和业务流程都有自己的特殊之处,无法照搬其它医院的模式,因此在系统设计开发完毕试运行期间,可能会根据实际情况调整系统流程。(2)对操作界面的变更需求:由于在需求说明书中只是对操作界面风格进行了笼统的要求,程序员在编码时对界面内容的安排和交互方式的实现方面一般根据个人的习好进行设计,没有过多地从用户操作的角度和实际业务状况进行考虑。而且用户往往在程序开发完毕进行试用时才对操作界面提出异议,并要求修改。这也是在软件开发的过程中经常出现的问题。(3)用户随着对信息系统的接触和了解,会不断产生一些新的想法和需求。
医院信息系统HIS被业内公认为最复杂的信息系统之一,其复杂性表现之一就是变更的频繁。系统的变更控制不是为了控制变更的发生,而是对变更进行科学有效的管理,避免造成系统开发的混乱。我在本次的HIS项目建设过程中,主要通过制定和执行严格的变更控制流程,对各种变更需求进行分析评估,跟踪批准的变更,进行变更结果的反馈,并及时更新配置库中相关内容。
针对该项目规模较大以及可能出现的频繁变更,为了明确变更需求和便于管理,我要求所有变更请求必须要以书面的形式提交到项目组。接到变更申请后,我根据需求涉及的部门,针对本次需求成立临时变更控制委员会,CCB由我(项目总负责人)、开发经理(校方公司人员)、医院相关部门负责人(参加人员不固定,根据变更涉及的部门进行调整)、质量管理员(医院信息中心资深工程师)、配置管理员(公司提供了一个专职人员)组成,在门诊系统试运行的过程中,不少医生和科主任提出不在医生处打印处方,改为病人缴费后,直接到药房取药时打印处方,并提出了不少这样做的好处(减少医生打印处方的环节、节省打印机投入、防止“跑方”)。在接到书面变更申请后,我立即成立了针对本次变更需求的临时变更控制委员会,进行该变更需求的讨论和评估。在会上大家从政策法规、流程的可行性、病人可接受的程度等方面进行了全面细致的分析,最后达成了一致:认为在医生站取消处方的打印首先不符合卫生部处方管理规定中要求的必须存有纸质处方,并且医生必须在处方上确认签名。同时病人在取药时才见到处方,在一定程度上侵犯了病人的知情权和去医院外药店买药的权利。基于上述分析,虽然医生取消处方打印对医院有不少好处,但为了保障病人的权利和方便就医,同时也为了严格遵守卫生部的处方管理规定,决定不进行本次需求的变更。会后,以书面的形式将本次评审的结果和理由通知了相关的科室和医生,并与之进行了面对面的沟通。申请者很顺利地接受了评审结果,同时也避免了由于盲目变更造成的负面影响。
而对于经评审批准的变更,我会根据变更产生的影响程度,适当调整项目的进度和成本基线,并通知相关干系人。同时以书面的形式下达变更指令,进行变更的实施,并要求做好
变更记录。在变更处理完成后,经测试通过,及时将版本予以更新和发布。
在HIS项目日常的变更管理中,使用了VSS6.0工具进行了项目的变更控制管理。由于在此之前我本人对配置管理工具比较陌生,负责开发的公司方推荐了他们在日常配置管理中使用的VSS工具,并派了一名配置管理员协助我进行管理。由于VSS功能强大,操作简单,我很快掌握了使用方法。在项目的建设过程中,VSS在变更管理、版本控制和发布等方面发挥了很大的作用。配置管理员根据我的要求,为项目组每个人建立了访问帐户和权限。每次需求变更评审通过后,我都会通知设计开发人员在开发库中进行文档和程序的修改。修改完毕测试通过后,由配置管理员负责将本次修改后的程序和相关文档在受控库中进行归档处理和版本升级。对于在运行的系统,还要在产品库中及时升级版本并予以发布。通过VSS的使用和规范的管理,在整个开发过程中,从未出现修改混乱和版本失控的现象。
在项目建设的过程中,虽然变更控制委员会发挥了重要的作用,但确无法预防诸如在程序完成后,用户提出的操作界面的修改等问题。因此在今后的软件开发中,在界面设计上尽量采用原型化的方法,随时与用户沟通,提出改进意见,避免重复开发。同时建议在变更控制委员会下建立变更控制小组,对于某些不涉及流程和关键业务的变更需求,由变更控制小组直接负责审核处理,并将处理结果及时上报给CCB,这样可大大提高项目的决策和工作效率。
截至2006年5月该HIS项目通过医院组织的两次阶段性验收和一次总体验收,项目如期、高质量地完成了建设任务,系统运行稳定,获得了各部门的一致好评。同年底,该项目被评为湖南省2006年信息化建设优秀案例。项目的成功在很大程度上归功于对变更的有效管理和控制。
第二篇:信息系统开发
信息系统开发是一个社会过程
信息系统建设的困难不仅来自技术方面,还来自企业内外环境。影响信息系统成败的有体制、政策、法规、观念、技术等多种因素。技术不是唯一因素,甚至不是主要因素。
在相当长的一段时间里,开发信息系统的过程中,用户和开发人员双方误解,用户认为开发是技术人员的事,开发人员因为用户陈述清楚他们的需求,由此开发系统,其它的不要干预。当完成系统开发,用户提出“你开发的系统不是我所要的系统”,延误开发时间,浪费资源,或者因维护困难而使系统短命。
信息系统建设的实践,使人们越来越重视社会人文因素对信息系统建设的影响。信息系统是人机交互系统,其开发、维护都离不开入的参与。信息系统开发过程本质上是一个社会过程。从社会行动观点看,信息系统开发是人类活动的协调序列,是多种参与者的协作过程。在信息系统开发过程中,用户、系统管理者、系统分析员、技术专家、程序员等参与者相互联系,相互影响。他们的通力合作,是系统建设成功的基础。但是,由于这些人员知识背景、经历不同,影响彼此沟通。通信的误解是系统成功的隐患。更重要的是,信息系统建设不可避免地要改变某些业务流程乃至组织机构,这将影响某些部门和人员的工作方式、权力关系,引起部门之间、人员之间的利益冲突。有人会担心丢掉自己熟悉的工作,感到自己的传统地位和能力受到威胁;由于缺乏计算机知识,有人感到难以适应现代信息系统的运行。这些担心,常常造成系统开发的阻力。
信息系统不只是单纯的计算机系统,而是辅助企业管理的人机系统。人是信息管理的主体。由于人的作用是一种高级而复杂的因素,有人参与并由人控制决策的社会系统,往往会使本应理性的行为变得富有感情、丰富多彩。离开了人,再好的计算机系统,也不过是价格昂贵的装饰品而已。把信息系统的开发、应用、管理看作纯技术过程,许多问题永远得不到解决。只有从更深层次探讨,重视非技术因素,才有可能解决长期困扰人们的“软件危机”。
第三篇:系统开发成本控制论文
一、Z公司开发G系统的成本控制策略
G系统的开发具有非常强的动态性,这大大增加了成本控制的难度。因此,成本控制的具体落实需要配合动态管理才能实现。软件开发类项目的动态性特征往往来自于两方面:第一方面是开发过程中的需求变更,这种变更所引起的成本变动牵连较广,因此其动态控制需要通过细致的变更跟踪来实现;第二方面是系统错误,因为在发现上具有很强的滞后性,往往要在测试阶段才能发现,所以很难通过预期型的成本控制手段来处理,而且也做不到完全消除,只能通过种种手段尽可能地降低其发生率。
二、Z公司开发G系统的成本控制问题
(一)成本控制观念落后问题
Z公司目前已经建立起了成本控制观念,但由于更新相对较慢,所用的成本控制观念已经较为落后,难以满足G系统开发的成本控制需求。具体来说,Z公司对成本控制的观念仍集中在成本节省上,虽然对成本控制有一定的认识,但将其看作一个相对独立的系统,既缺乏对市场的调研和结合市场需求的控制策略,也没有考虑到成本控制与软件质量的平衡,最终导致成本控制的能效低下,没有发挥出自己应有的作用。该问题与我国软件项目的人员构成有一定关系,以Z公司的G系统开发为例,实际负责开发的人员大多是纯粹的技术人员,经济观念非常薄弱,对成本控制的认识也较为粗浅,而项目管理人员虽然对成本控制的认识比较到位,但往往担心过多强调成本控制会挫伤开发人员积极性,放任自流的现象比较严重。这种成本观念的不统一导致了成本控制的松散现象。
(二)成本控制措施老旧问题
Z公司目前使用的成本管理系统是基于成本会计系统运作的,控制措施失于单一,而且更新缓慢,无法跟上当下的市场形势和控制需求。尤其是在产品资产归属和成本预算方面,没有有效的成本控制措施,前者往往存在归属划分混乱现象,由于软件产品自身的特殊性,其作为专利产品既具有无形性又具有流动性,如果没有明确的控制策略,归属纠纷在所难免;后者由于过多依赖会计系统,所以成本控制非常粗略,对各种细节预算估计不足,最终体现为成本控制的动态化程度过低。基于上述原因,传统的成本控制措施急需进行拓展和更新。
(三)成本控制体系残缺问题
目前来看,虽然Z公司已经拥有了成本控制体系,但这个体系并不完整,其主要的缺陷包括两方面:第一方面在于控制体系的单线运行机制。如前文所述,成本控制包括多个模块,各个模块之间存在着诸多的横向联系,现有的成本控制体系只以单线串联全部的控制模块,忽略了这些横向联系,在实际运作中自然就会出现一些空白和缺漏,体系的整体运作也容易产生滞涩。第二方面在于成本控制的主要执行者并未独立出来,成本控制工作基本完全由项目内部人员包办。这种完全的内部控制既降低了成本控制的专业化程度,也无法保证其客观性和实效性。
三、Z公司开发G系统的成本控制措施
(一)计划阶段的控制措施
对软件开发项目来说,成本控制在计划阶段可以分作三个模块,应针对这三个模块的不同特点选择不同的具体控制措施。第一模块是针对人工成本进行的控制,包括了成本分析、成本预算、成本监控三部分。其中成本分析是基础,具体措施是对比整体人工成本和计划阶段的人工成本,以此寻求最佳标准,找到调节方式。成本预算是主体,具体措施同样是对比分析,但对比对象是总体项目与明细项目。成本监控是后续准备,需要建立专门的监控机制保证成本控制措施的落实。第二模块是针对系统成本进行的控制。具体来说,在计划阶段需要从成本源头和成本运用两方面着手,一方面提高G系统的市场价值,降低成本在市场价值中所占的比例,另一方面要梳理预计的开发流程,对其中可能造成成本超标的部分进行合并,以便于后续的动态控制。第三模块是针对设计成本进行的控制。为了实现对G系统开发这一项目的成本控制,需要专门的成本控制系统,而设计该控制系统本身也需要成本,所以必须在计划阶段进行考量。从实际设计经验来看,该部分的成本控制需要从可预见成本和不可预见成本两方面入手,其中不可预见成本是可预见成本的5%到10%左右。该控制系统的具体结构示意图。
(二)执行阶段的控制措施
执行阶段的G系统开发成本可以分为三类,分别是人工费用、材料费用、其它费用。其中人工费用是指执行阶段支付给项目相关人员的薪酬、津贴等,在进行控制时要注意控制措施的细化,由于软件开发中不同工作模块的人员在工作性质上有一定差异,所以费用的计算方法、发放模式也都有所区别。因此,有必要针对每一位人员、每一笔人工费用订立详细的记录表格,根据实际情况随时调整,以实现针对人工费用成本的动态控制。材料费用是指在开发G系统时所必须购置的各种软硬件设备花费、设备的维护费用等直接花费。这些费用相当繁杂,而且其中有相当一部分具有突发性、临时性,成本控制比较困难。因此要完善执行阶段材料费用的审核机制,相关支出务必要先审核,后报批,以避免无意义支出。此外,该部分的费用与计划阶段的诸多设计有很大关联,在实行成本控制时要注意二者结合比照进行。其它费用是指执行阶段的各类间接费用,比如房租水电、项目开发人员的保险、福利等。这些费用虽然不与G系统的开发直接相关,但由于其是整个项目组的正常运作所必须的,所以也属于项目成本控制的范畴。通常情况下,该部分的成本控制只会规定间接费用的可调度区间,具体来说,间接费用的额度不可超过总成本的10%。
四、结束语
软件开发作为高新技术产业的一部分,长期以来都有重质量、轻成本的倾向,这种现象虽然对系统软件的开发水平提升有很大的好处,但在越来越激烈的市场竞争下,对项目的主导企业是非常不利的。因此,Z公司在开发G系统时,将成本控制的地位提升至与开发质量等同是符合市场形势,也是符合公司发展需要的,具有很强的经济价值和社会意义,有必要进一步发展和推广。
第四篇:信息系统开发流程规范
信息系统开发流程规范
(内部讨论稿)
总则
为明确信息系统开发流程,清楚各阶段工作内容和工作目标,特制订本规范。本规范主要从系统规划、系统整体管理、系统需求分析、系统设计、系统编码与测试、系统内部实施、系统整体评价及系统内部验收八个方面说明公司对信息系统开发流程的主体要求。对实际信息系统的开发,开发流程可根据系统的规模与要求进行合理的剪裁。
本规范适用于软件开发部、软件项目部、系统集成开发部、系统集成项目部进行信息系统开发工作。
信息系统开发流程
一、信息系统规划,完成信息系统立项和总体解决方案。
[1] 申请立项部门依据《立项控制规程》,提交与信息系统立项有关的书面或电子文档,立项部门申请信息系统项目立项。信息系统项目立项主要从市场方面、技术方面及行业导向方面三个方面进行考虑。
[2] 立项部门的上级部门或领导按《评审验收规程》组织业务专家、市场人员、技术人员等人员完成对信息系统立项相关文档的评审和检查工作,形成立项评审结论。评审结论包括合格和不合格两种,合格的可以进入下一阶段,不合格的需要说明不合格的具体原因,不能进入下一阶段。[3] 根据信息系统立项的相关文档,生成信息系统的《总体解决方案》文档。文档中一般包括系统范围和目标、系统总体功能结构图、系统网络拓扑图、系统部署方案、系统实施计划、系统费用概算等。
二、信息系统整体管理,建立项目管理章程。
[4] 建立基本的信息系统项目管理章程,指定信息系统项目的项目经理(产品经理、负责人),完成项目启动。
[5] 项目经理组织人员制定初步的项目管理计划,计划内容可包括项目最终目标、项目阶段性目标、项目进度计划、项目预算、变更流程和变更控制委员会、人力资源计划、项目风险、项目采购计划等。
[6] 依据《配置管理规程》和《变更控制规程》形成配置管理系统和变更控制系统,成立变更控制委员会。
[7] 项目经理指导和管理项目的执行过程,包括项目完成情况、项目进度、项目质量、项目变更情况等。
三、信息系统需求分析,完成《需求分析》文档。
[8] 项目经理组织人员完成信息系统相关资料收集和需求详细调查工作,完成信息系统业务流程分析和数据流分析。
[9] 分析信息系统目标,确定信息系统项目边界,完成项目范围定义和项目内容分解。
[10] 项目经理组织人员完成项目《需求分析》文档的编写,并提交上级部门申请评审。测试设计是否算需求?
[11] 上级部门按《评审验收规程》组织业务专家、市场人员、技术人员、测试人员等人员完成对《需求分析》文档的评审和检查工作,形成评审结论。评审结论包括合格和不合格两种,合格的可以进入下一阶段,不合格的需要说明不合格的具体原因,不能进入下一阶段。
四、信息系统设计,完成《系统设计》文档。
[12] 项目经理制定系统设计阶段的项目工作计划,确定该阶段的检查点和里程碑。项目经理向上级提交工作计划,上级部门按《评审验收规程》完成对工作计划的评审,形成评审结论。评审结论包括合格和不合格两种,合格的可以进入下一阶段,不合格的需要说明不合格的具体原因,不能进入下一阶段。
[13] 项目经理组织人员编写《系统设计》文档,文档内容一般包括物理配置方案设计(客户机、服务器、网络、数据库等)、功能结构详细设计、主要系统功能流程设计、主要系统功能数据处理流程设计、系统外部接口说明和定义等。
[14] 项目经理向上级部门提交《系统设计》文档,申请评审。上级部门按《评审验收规程》组织技术人员完成对《系统设计》文档的评审和检查工作,形成评审结论。评审结论包括合格和不合格两种,合格的可以进入下一阶段,不合格的需要说明不合格的具体原因,不能进入下一阶段。
五、信息系统编码与测试,完成系统编码和单元测试。
[15] 项目经理组织人员按《软件编码规范》完成信息系统的代码编写。[16] 项目经理组织人员按《测试规程》完成信息系统的单元测试工作,单元测试一般由模块编码人员进行自我测试。
六、信息系统内部实施,完成系统试运行和集成测试。
[17] 项目经理组织人员搭建系统运行环境,按项目要求完成信息系统的安装部署工作。
[18] 项目经理组织人员按《测试规程》完成信息系统的集成测试工作,生成系统测试报告和结论。
七、信息系统整体评价,生成项目总结报告、技术白皮书。
[19] 项目经理组织人员编写信息系统相关的技术性文档,如技术白皮书。[20] 项目经理编写项目总结报告,包括功能评价、应用评价等。
八、信息系统内部验收,生成验收报告。
[21] 信息系统内容建设完成后,项目经理根据《评审验收规程》编写项目验收申请报告,并提交上级申请验收。
[22] 上级部门根据验收申请、系统测试报告和结论及需求分析等相关文档,组织人员按《评审验收规程》进行信息系统内部验收,形成验收结论,完成验收报告。验收报告包括合格和不合格两种,验收合格可以将信息系统交付项目部进行实施,不合格的不能交付项目部。
信息系统开发流程图
开始信息系统产品立项项目立项文档项目立项评审结论项目总结解决方案未通过,重新编写立项评审通过项目启动,确定项目经理制定项目管理计划项目管理计划配置控制系统变更控制系统项目经理组织编写需求分析需求分析文档需求评审结论未通过需求评审通过项目经理更新项目计划信息系统开发计划开发计划评审结论未通过计划评审通过项目经理组织系统设计未通过,不给予立项设计评审通过编码和单元测试信息系统代码未通过系统设计文档设计文档评审结论试运行和集成测试(可多轮)信息系统测试结论测试结论通过项目总结报告项目总结报告技术白皮书未通过内部验收报告未通过验收评审通过交付项目部结束
第五篇:信息系统开发名词解释答案
系统的可维护性:是指对系统进行维护的难易程度的度量,其中包括有:①可理解性:指为外来读者理解系统的结构、接口、功能和内部过程的难易程度。②可测试性:指为系统进行诊断和测试的难易程度。③可修改性:指对系统各部分进行修改的难易程度。
数据词典是:DFD中所有成分的定义和解释的文字结合,其描述的主要内容有:数据流、数据元素、数据存储、加工、外部项等。
系统测试:是管理信息系统开发的一个重要而漫长的阶段/是保证系统质量与可靠性的最后关口/是对整个系统开发过程包括系统分析、系统设计和系统实现的最终审查。系统的可测试性:表现为对系统进行诊断和测试的难易程度。
系统方法的整体性原则:系统是相互联系、相互作用的诸要素的综合体。一个特定的系统具有的功能与目标,不是各组成部分功能与目标的简单相加,而是各部分按一定秩序相互作用的结果。系统方法的基本点是从整体目标和功能出发,正确处理系统各组成部分之间的相互联系和相互作用,是解决复杂系统各类问题的关键所在。数据类:指支持企业过程所必需的逻辑上相关的数据。基本加工:数据流图中所有不进一步分解的加工,称为基本加工。
结构化程序设计基本思想:把整个系统开发过程分成若干阶段,每阶段进行若干活动,每项活动应用一系列标准/规范/方法/技术,完成一或多个任务,形成符合给定规范产品。
数据流图:是使用少数几种符号综合地反映出信息在系统中的流动、处理和存储情况的流程图,是一种能全面地描述信息管理系统逻辑模型的主要工具,是系统分析人员与用户进行交流的有效手段。继承性:是类层次结构中,超类和子类之间共享数据的操作方法的机制。
系统评价:从广义上理解,是贯穿系统整个生命周期各个阶段的重要决策手段和工作环节,从狭义上理解,为系统投入运行以后的评价。系统转换:指以新开发的系统替换旧的系统,并使之投入使用的过程。
管理信息系统:指为实现组织的整体目标,对管理信息进行系统地、综合地处理,辅助各级管理决策的计算机软件硬件、通信设备,规章制度及有关人员的统一体。系统的总体结构:指整个系统由哪些部分组成,以及各部分在物理上、逻辑上的相互关系,包括硬件部分和软件部分。
数据加密:为了防止存储介质的非法拷贝、被窃,以及信息传输线路的被窃听而造成机要数据的泄密,在系统中应对机要数据采取加密存储和加密传输等安全保密技术措施。结构化方法:指信息系统的一种开发方法,其主要含义是一组规范的步骤、准则和工具来进行开发工作。
管理信息系统规划:制作MIS的发展战略;确定组织的主要信息需求,形成MIS的总体结构方案;安排项目开发计划,制定系统建设的资源分配计划。
CSF法:即关键成功因素法,就是那些必须经常得到管理人员关注的活动区域,对这些区域的运行情况要经常不断地进行度量,并提供这些度量信息以供决策使 单元测试:也称模块测试。单元是程序最小的独立编译单位。确认测试:确认测试是进一步检查软件是否符合软件需求规格说明书的全部要求。
MIS战略集:MIS战略集的元素构成MIS战略规划的要素,由系统目标、系统约束和系统设计战略组成。
黑盒测试:黑盒测试也称功能测试,是将软件看作黑盒子,在完全不考虑程序的内部结构和特性的情况下,测试软件的外部特征。
试述信息系统分布式结构的主要优点:可以根据应用需要和存取方便配置信息资源;利于发挥用户的主动性、积极性,提高了系统的应变能力;系统扩展方便;系统健壮性好。缺点:信息资源分散,开发维护管理标准难以统一;不同地域的系统有时有冲突,管理协调困难;安全保密措施难以统一实施。
试述管理信息系统生命周期的意义及阶段划分:管理信息系统产生发展、成熟和更新换代的过程称为管理信息系统的生命周期。可分为四大阶段:系统规划、系统开发、系统运行与维护和系统更新。系统开发阶段又可分为系统分析、系统设计与系统实施三个阶段。
试述系统开发的结构化方法的基本思路是把整个系统开发过程分成若干阶段,每个阶段进行若干活动,每项活动用一系列标准、规范、方法、技术完成一个或多个任务,形成符合给定规范的产品。结构化方法的主要原则有:用户参与原则;“先逻辑、后物理”、严格划分工作阶段原则;自项向下原则;成果描述标准化原则。简述系统总体结构设计的基本内容:系统的总体结构是指整个系统由哪些部分组成,以及各部分在物理上、逻辑上的相互关系,包括硬件部分和软件部分。即包括系统的总体布局设计,软件系统总体的设计,数据存储的总体结构设计。简述系统设计的特点:系统设计工作的环境是管理环境和技术环境的结合。
简述在采用生命周期法开发系统过程中用户的主要作用:生命周期法中用户是系统建设者主要组成之一。用户的作用是不断明确和细化对系统功能需求,对各个阶段的成果从用户的角度进行审核与验收,提供系统建设必要资源,协调信息系统与组织各部门的关系。
简述编写数据词典的基本要求:对数据流图上各种成分的定义必须明确,易理解、唯一;命令、编号与数据流图一致,必要时可增加编码,方便查询检索,维护和统计报表。符合一致性与完整性的要求,对数据流图上的成分定义与说明无遗漏项。格式规范,风格统一,文字精炼,数字与符号正确。
BSP实现的主要步骤/定义企业目标/定义企业过程/定义数据类/定义信息系统总体结构。
简述数据流图的基本组成:外部项(外部实体);加工(数据加工);数据存储
简述管理信息系统集中式结构的主要优点:信息资源集中,便于管理和统一规范;专业人员可以集中使用,便于组织和培训;信息资源利用率高;便于实施系统安全措施简述决策支持系统的特点:决策支持系统自创有较强的人机交互功能;决策支持系统的信息基础不但包括直接反映企业内、外部环境、条件的数据。简述数据流图绘制的主要原则:明确系统界面;自须向下逐层扩展;合理布局;数据流团只反映数据流向,数据加工和逻辑意义上的数据存储;数据流图绘制过程,就是系统的逻辑模型的形成过程,必须始终与用户密切配合。
简述什么是系统的可修改性和影响可修改性的因素:系统的可修改性:表现为对系统各部分进行修改的难易程度。影响可修改性的因素:系统的模块化程度;模块之间的耦合、内聚、控制域与作用域的关系;数据结构的设计。