金融信息管理概论(六)

系统开发方法系统开发方法------开发信息系统所需要的步骤开发(20%)分析/设计35%编码15%测试50%维护(80%)生命周期法项目定义:论证建设一个新信息系统的必要性系统分析:系统调查,分析原有问题,找出解决方案系统设计:生成系统设计的逻辑说明书和物理说明书编写程序系统安装:测试,培训和转换实施与评价生命周期法的特点和局限强调计划性,排斥不确定型;强调分工,强调合作;强调标准化和规范化适合于开发那些能够需求容易定义,结构化程度高的大型事务处理系统和管理信息系统过于耗费资源,周期长,工作量大缺乏灵活性不适合开发那些需求不明确的系统原型法(1)抓住用户最基本的需求(2)开发出一个原型系统(3)将原型交付用户使用,启发用户提出新的要求(4)按新的要求改进原型,然后再交付用户使用重复(3)和(4),直到用户满意原型法的使用场合与局限性适合于需求不确定和解决方案不明确的系统开发(如决策支持系统)适合于开发信息系统的最终用户界面优点是提高最终用户的满意度,开发周期短,成本低不适合开发大的信息系统,批处理系统和含有大量计算的系统测试和文档常常被忽略,系统难以进行维护运行的效率比较低利用软件包开发预先编制的,能完成一定功能的,供出售和出租的成套的软件系统需要开发的系统功能是多数组织都要用到的一些通用功能组织内缺少开发人员开发的系统属于微机系统利用软件包开发的优缺点缩短开发时间可以得到比较好的维护减轻组织内部对系统开发的阻力功能较为简单难以满足特殊要求实施的费用随客户化工作量的增大而上升选择软件包开发要考虑的因素功能:满足?需要修改?不支持?灵活性:客户化?方便?友好性:使用?培训?环境要求:硬件,软件?数据库和文件结构的要求安装和维护的承诺:难度?人员需要?升级?文档:完整?容易?供应商状况价格软件包开发系统的步骤系统分析系统设计编程,调试,转换运行与维护最终用户开发最终用户在没有专家的帮助下,自行开发应用系统第四代开发工具使应用程序的编写越来越容易好处是开发周期短,用户满意缺点是因为缺乏正规化控制而具有风险(没有文档,难以维护;开发者离开后无法继续使用等)信息系统的外包将企业的信息中心交给外面专门的部门优点是:经济,服务质量好,可预见性好,灵活,有效利用人才,盘活资产缺点:信息转入他人之手系统开发方法的选择考虑项目的通用性考虑项目的规模和影响考虑项目的结构通用,结构化程度高,规模大------软件包不通用,结构化低,规模不大------原型法不通用,影响范围小-------最终用户开发不通用,规模大,结构化高-----生命周期法系统分析可行性分析系统调查:访问;发调查问卷信息需求分析系统分析报告:可行性报告;组织机构图;业务流程图;数据流程图;用户需求分析;新系统模型可行性分析技术可行性经济可行性操作可行性方案:维持原系统不变;改进原系统;开发新系统数据流程图实体存储流向处理系统分析案例问题的提出分析现有系统提出新系统目标提出新系统模型现有系统贷款申请批准(分部申请,分部和总部审核,总部批准,建帐,分部支付,建章)偿付处理(分部,总部偿付,分部总部分别修改账户)拖欠分析结算会计系统(总部夜间运行)存在问题贷款批准过程花费时间长80%偿付在分部,20%在总部.一半丢失了凭单,总部的“已偿还证明”常送错过期偿付引起的处理瓶颈(总部44人)过多的文书工作“坏帐”不能及时发现,数据不是最新的现金流通问题新的系统方案废除“已偿付证明”建立拖欠剖析图及时得到现金流动信息系统目标经营目标系统目标三天内完成贷款认可程序。为分部建立分散的贷款申请请筛选和决策制定责任，设计分布式的数据库（信贷历史，拖欠贷款），分部访问数据库制定决策。一年内将拖欠率由2.5%降至2%。制作一个精确度更高的拖欠剖析图，确定高潜在拖欠账户；在贷款申请表格中提供更多的数据减少维护重复文件，处理APRs，处理迟付款项相关的文书工作花销强制所有的支付都通过分部完成；在任何支付催单生成之前，要提供支付的标价。一年内削减50%的短期借款成本提供一个现金流量表系统，了解流动现金的状况。不引入净成本的前提下提供一个轻松的账单支付程序每晚处理30,000笔帐单，每笔账单的平均成本为50美分系统设计系统的技术配置方案系统的总体设计代码设计数据库和文件设计输入输出设计程序说明书测试计划系统设计过程中用户的参与------需求不明确的用户参与要多一些系统实施编写程序:可靠性,可维护性,可理解性和效率系统测试和实况考试(试运行),用户培训和系统转换运行和维护•20%修正程序错误•20%用户数据,文件,报告和软件硬件的改变•60%为满足用户的需要而重新改写程序系统转换平行转换策略------新老系统并存,同时运行一段时间------风险最小直接转换策略------新系统完全取代老系统------风险最大典型引路转换策略------在一个有限区域运行新系统,逐步取代分阶段转换------按功能分阶段转换信息系统的成败实例信息系统的成败标准信息系统成败的原因系统开发和运行各阶段可能出现的问题信息系统项目管理信息系统质量保证作业加州DMV系统升级DMV系统运行了二十五年,跟踪5000万个司机驾照和机动车情况,每年收税52亿原系统用汇编语言(第二代语言)开发,维护困难;在司机注册文件中添加社会保险号码需用18人年的编程量87年订立新的升级计划:关系数据库;容错机;第四代语言;CASE工具项目组未能及时掌握开发工具的使用7年投资4400万,项目未能成功,若使系统能使用需再用1亿美元和4年时间DMV系统管理记录司机和机动车信息;信息技术关系数据库容错机COBOL4GLsCASE工具组织(结构)地区主管办公室司机信息系统提供决策支持快速更新解决方案改进服务水平,降低维护费用竞争挑战业务量的扩大某化工厂管理信息系统85年某化工厂决定研制管理信息系统接受委托大学进行可行性分析,认为应先研制一些子系统.但厂长决定开发中等规模的信息系统项目研制工作有条不紊地进行:系统调研;人员培训;总体规划;购置设备和软件;业务调整87年9月系统运行,暴露一些问题系统问题得到解决,但企业环境发生变化系统陷入瘫痪,以失败告终系统遇到问题手工系统和计算机应用系统同时运行,加重管理人员负担仓库管理员不愿使用材料代码,也不明白为什么这样做计算机制定的材料定购计划优于计划员的计划,计划员抗拒使用厂长需要的某些信息无法提供企业环境的变化厂长调离厂外开发人员撤离,技术问题时有发生市场变化新上任厂长对信息系统不重视掌握软件开发和维护技术的人员调离某化纤厂信息系统管理计划库存管理财务信息技术微型机数据库以太网组织计划库存管理工作过程企业文化信息系统解决方案降低成本提高效率竞争挑战竞争对手信息系统的失败未能开发成功:如伦敦股票市场和DMV系统弃置不用:如某化纤工厂管理信息系统未达到预定目标或未按照预定方式使用成功的信息系统高水平的系统应用用户满意用户愿意使用预定的目标降低成本或提高利润信息系统成败的原因用户的参与和影响开发过程中管理支持的程度项目的复杂度和风险开发过程中的管理的质量用户的参与和影响用户参与系统开发的好处:可以使系统符合用户实际工作的需要;对系统实施采取积极的态度用户对问题的理解也可能是狭隘的,或看不到信息技术所能提供的机会用户---设计者的沟通差别:使用不同的“语言”用户不理解设计者的意图会使系统无法真正满足需要管理支持管理方面的支持会使用户和开发者认识到系统的重要性.保证项目足够的经费和资源管理者怎样对待这个系统,他的下属就会怎样对待这个系统项目的复杂度和风险项目的规模:项目越大------花销大,参与人员多,时间长,影响的部门多-----风险越大项目的结构:结构化程度越高-----用户需求明确,固定不变-----风险越小技术水平:采用成熟的技术-------风险小技术经验:开发人员技术经验越多------风险越小项目实施过程的管理支持一个缺乏有效管理的项目会导致如下后果:•花销大大超出预算•时间比预想的要长•技术问题使系统性能较低•没有获得预想的收效由于对项目缺乏了解而盲目乐观项目成本可用“人月”计算,项目进度则不能-------任务时有序相关的,不是孤立的,需要沟通和训练不能及时发现问题系统分析阶段的风险问题未能很好地定义,系统实施目标模糊,资源不足,系统收益无法衡量没有规划,没有检查标准人员组成不当信息服务人员所承诺的系统性能无法达到需求分析建立在现有系统不完整的文档之上或对九系统的研究不充分用户拒绝帮助开发人员收集信息系统分析员缺乏与用户沟通的技巧系统设计阶段的风险设计方案反映了技术人员的偏见,没有反映用户的意见系统只能满足当前需要,缺少灵活性没有分析系统变化可能带来的组织影响功能说明没有形成文档系统编程阶段的风险低估了编程所需的时间和花销程序员没有拿到完整的程序说明没有充分的时间进行程序的逻辑设计程序员没有按照结构化程序设计和面向对象程序的思想开发程序(程序不规范)程序文档不完全资源(如机时)不够系统测试阶段的风险低估了测试所需的时间和成本项目组没有测试计划用户没有参与测试过程,没有提供样本数据项目组没有测试的验收标准,管理人员未签字认可系统转换阶段的风险系统转换,特别是数据转换没有充分的时间在转换进行前,没有进行人员培训,准备不充分系统和用户文档不完全没有性能评价的标准,没有进行性能评价系统维护工作不充分项目管理项目是具有以下特性的系统活动:•限于一次的过程•具有明确的完成目标,并以此决定其价值•具有技术上的不确定性项目使许多人为了一个目标从各自独立的角度而进行工作的过程项目管理:计划,控制和沟通•关于进度,资源分配的周密计划•及时发现异常和进度迟缓的原因,采取适当的控制对策•注意与用户和领导沟通项目管理人对用户的责任:明确与用户的约束事项;确保和用户的密切关系;取得用户的理解对项目组的责任:提高士气;明确评价标准;平衡任务的分配;缓冲作用对经营者(领导)的责任:提供充分的信息;帮助领导进行有意义的决策项目是由人来完成的------给与推动,自己不作别人的工作重视计划------进度表,里程碑,形成按部就班,前后吻合的计划,计划中贯穿主要精神郑重考虑用户------不嫌弃与“讨厌的用户”交流用户---设计者沟通差别用户的关心设计者的关心信息系统能否提供我工作需要的信息;我能到这项数据需要多长时间我把这些数据输入系统需要操作员为我做什么系统的操作怎样符合日常业务计划存储主文件需要多少磁盘空间,最有效率的方法是什么完成这项功能需要多少行程序代码运行这个系统是怎样减少CPU的处理时间我们应该是用什么样的数据库管理系统信息系统的质量保证满足设计说明书,不一定满足用户的真正要求维护阶段的噩梦------60%的工作要根据用户需要重新改写系统软件臭虫和缺陷质量保证工具选择适当的开发方法重视测试阶段传统的质量保证工具:业务流程图;数据流程图;程序流程图等新的质量保证工具:CASE工具;面向对象方法