系统分析案例

系统分析案例论软件系统分析的办法和方略当一种软件项目摆在人们面前时，进行系统的分析是首当其冲的,正如我们的一句古语:三思而后行。因此，无论做任何事都应考虑与否故意义以及它的可行性。在过去，人们将“软件”与“程序”、“开发软件”与“编程序”划等号，粗略的进行预计和设计软件产品势必会影响软件的质量和生产效率。然而现在，随着信息化产业的发展，软件公司的增多,特别是当面对某些大中型的软件项目，对软件生命周期的各个环节进行系统具体的分析将更加重要,并且会提高软件的质量和效率。一、软件系统开发无论动物、植物，作为一种完整的事物,都有它的生命周期、或者说它的轨迹。作为先进高科技的产物---软件产品,自然也不例外。这期间,要通过一系列的过程,例如,开发者首先要考虑它的可行性,与否能解决现在问题或是将来与否能有更大的发展,固然要有具体的规划和设计,要形成书面的文档统计下来,方便开发员之间的交流。另首先核心的是能否满足顾客的需求,由于判断开发出来的软件与否成功的原则之一就是看它有无实用性。之后便是一系列的实施,例如程序设计,系统测试,以及接下来的后续工作---维护与修改工作。软件生命周期的各个环节将软件系统开发大致分为四个阶段，用图示的方式体现出来即普通所说的“瀑布模型”，如图：二、系统分析系统分析是软件生命周期的一种核心环节，其目的是将对计算机应用系统的需求转化成实际的物理实现。然而实际面太多，增加了软件分析的复杂度，那么终究在系统分析的过程中需要考虑那些因素呢？1、系统目的。在考虑系统目的时，应更多的侧重于系统的最后目的考虑，由于一种系统不可能在最初就是完美的，要为系统留些余地。2、系统参加者。在整个项目中，要考虑有哪些方面参加了系统，这些参加者人可能在系统建设中起重要作用，他们采用什么样的态度将会对系统有一定的影响。另外，还要理解各参加者的初衷是什么。3、明确的评价原则。最佳从参加的各方面都进行考虑，要懂得他们对这个系统与否有一种明确的评价原则。4、系统开发计划的完善度。计划表要有明确的阶段，每一阶段要有具体的完毕计划，以及对阶段完毕状况进行的评价。固然尚有诸多因素值得考虑，能够根据面对的项目的不同而变化,譬如与软件开发人员的交流等等。三、开发内容开发软件系统最为困难的部分，就是精确阐明开发什么。这就需要在开发的过程中不停的与顾客进行交流与探讨,使系统更加详尽,精确到位。这就需要拟定顾客与否需要这样的产品类型以及获取每个顾客类的需求。需求类型涉及三个:1、业务需求（businessrequirement）反映了组织机构或客户对系统、产品高层次的目的规定，它们在项目视图与范畴文档中予以阐明。2、顾客需求(userrequirement)文档描述了顾客使用产品必须要完毕的任务，这在使用实例文档或方案脚本阐明中予以阐明。3、功效需求(functionalrequirement)定义了开发人员必须实现的软件功效，使得顾客能完毕他们的任务，从而满足了业务需求。总之，无论是商业性或非商业目的的产品，都应含有完整的阐明书,以避免发生状况时引发不必要的损失。四、分析设计和系统方案在考虑完各方面的实际因素后，就要对项目进行总体的分析设计。简朴的讲，总体设计需要拟定的内容应当涉及：1、系统需要实现哪些功效；2、开发使用什么软件，在什么样的硬件环境；3、需要多少人，多少时间；4、需要遵照的规则和原则有哪些。普通状况下，在总体设计出来后，就需要给客户一种系统的方案。如果在客户需求不是十分明确的状况下提交方案，往往和实际制作后的成果会有很大差别。因此应当尽量获得客户的理解，在明确需求并总体设计后提交方案，这样对双方都有益处。而方案则应涉及下列几个部分：1.客户状况分析；2.系统需要实现的目的和目的；3.系统各个模块与构造；4.使用软件，硬件和技术分析阐明；5.开发时间进度表；6.维护方案；7.制作费用。总之，总体设计阶段是以比较抽象概括的方式提出理解决问题的方法；而具体设计阶段的任务，也就是把解法具体化。具体设计重要是针对程序开发部分来说的，但这个阶段的不是真正编写程序，而是设计出程序的具体规格阐明。这种规格阐明的作用很类似于其它工程领域中工程师经常使用的工程蓝图，它们应当包含必要的细节，例如：程序界面、表单、需要的数据等，程序员能够根据它们写出实际的程序代码；而至于后续的工作,就有程序员来完毕编写程序,系统测试员来完毕测试,尚有之后的维护和修改。五、运用方略伟人有治国的方略,商人有致富的财路,巧妇有理家的本领,鹤发童颜的老人有长生的秘诀。在进行软件开发系统分析时，也要本着某些方略：1．“简朴—复杂—简朴”。这是技术型分析人员经常碰到的状况，认为分析出错综复杂的关系，花哨的图表才干显示出分析水平高，其实，分析经常要经历"简朴-复杂-简朴"的过程，前一种简朴体现为分析人员"认为简朴"；随着分析的进一步，原觉得简朴的问题会越来越复杂；最后，通过概括、消化、分解，使得需求简朴明了。2．软件复用技术。新开发的软件，要从一开始就考虑其可演化性，方便后来的再工程和构件提取。随着软件复用技术的不停发展，从头开始的软件大量减少，使用的遗产系统对应增多,这就避免了重复的工作,使得已完善的模块遗传下去。3．模块化概念。模块化能够增强系统的独立性，使耦合度减少，实现“高内聚-松耦合”。对于模块的内部，使其高度集中，而模块与模块间的联系相对减少，这样使系统各模块独立的进行运转。任何雄才伟略的人都能纵观全局,有一览众山小之气魄。若想有杰出的成果必然要有对事物进行总的分析的能力,这就涉及与否着眼于久远利益,与否能对其较好的管理掌控。系统并不是简朴的计算机替代手工劳作的一种方式，它是一种高于现实的管理模式。因此,系统分析是软件开发过程中必不可少的一种环节，它为高质量软件产品的开发奠定了基础。教学目的：通过对系统分析的过程进行叙述，让学生从全局把握系统开发的流程，理解其中的重点，难点，目的，规定；为后来分析设计信息系统打下基础思考题：系统开发有哪些典型的办法？结合本案例谈谈系统分析的过程是如何的，要注意哪些问题？请你结合小组软件实验，谈谈你系统分析的思路，分析报告的内容？IT系统“起死回生”的管理台风“麦莎”72小时狂袭中国百余都市，瞬间变化了千万人的生活；从美国“9.11”事件、日本神户大地震到东南亚海啸；从9月中国银行收付系统忽然死机到去年北京首都机场系统瘫痪误机6,000人；再到花旗银行近来丢失390万客户信息的“数据门事件”，直至6月9日北京恒泰证券股票交易系统出现故障迫使股民望“红”兴叹?在这不拟定的信息化年代，啸聚而来的“天灾人祸”不仅给政府、商业机构甚至个人直接造成巨大生命财产损失，也对信息化时代各类组织机构赖以生存和运转的IT系统与业务持续性管理（BusinessContinuityManagement，简称“BCM”5月底，国务院信息工作办公室网络与信息安全组组长王渝次在中国首届灾难恢复行业高层论坛上指出：“在信息网络化时代，没有灾难备份与业务恢复计划的公司，在遭遇灾难事件时经常不堪一击，甚至可能随时崩溃。”脆弱的系统本次会议得到了银行、保险、制造等数十行业200多名IT主管、业界灾难备份专家及政府主管的主动响应。大家齐聚广东南海的目的，就是共商一种“小概率”但又“高风险”的热点问题：公司重要信息系统在遭受各类天灾人祸打击之后，如何快速恢复并维持业务的持续性管理能力。与会的公司高管们非常清晰，王渝次的话并不是危言耸听。根据顾能公司（Gartner）的调查数据，在经历大型灾难事件而造成系统停运的公司中，有五分之二左右的公司再也没有恢复运行，剩余的公司中也有靠近三分之一在两年内破产了。但是，“9.11”相比较之下，我国的金融机构防灾抗难意识及能力却极其脆弱，有时仅以一人之力就能够彻底破坏整个系统。8月，发生了一起令中国银行刻骨铭心的事件：中国银行利川支行一名营业部主任对银行信息系统进行消亡性破坏后，携款潜逃，造成银行数据丢失，业务陷入瘫痪状态。应对多个灾难与紧急事件，公司需要提前推行业务持续性管理。但是需要澄清的是，恢复并维持业务的持续性管理中，灾难备份（Backup）与恢复（Recovery）是两个完全不同的概念。进行灾难备份的公司，在遭遇灾难后，未必能够快速恢复，尽管前者对IT基础设施、信息技术与环境同样含有较高的规定，但公司要想在遭受灾难打击之后快速“起死回生”，涉及人员、流程、组织等非IT的业务持续管理计划、整体预案以及应急响应系统才是核心中的核心。而国内相称数量的公司和机构，重视系统的备份，却无视了尤为核心的灾难之后业务的恢复能力建设。“BCM本质上是一种管理范畴内的问题。”据国内第一位也是现在唯一获得国际CBCP认证的灾难备份专家、万国数据服务有限公司（称“GDS公司”）副总裁汪淇介绍，国际灾难备份与恢复行业已形成相称完备的BCM（或称之为“BCP”）理论体系和办法论。化解集中的风险深圳发展银行是国内首家实现了生产中心（业务系统）数据逻辑大集中和与灾难备份及业务持续管理系统同时建设的公司。深圳发展银行科技部总经理刘政权坦言，深圳发展银行之因此领先同行实施BCM系统，首先是由于把脉到BCM系统正在逐步成为国际金融通用规则的趋势，譬如在英国，业务持续管理规划已经成为公司上市的一种必要条件；另首先是由于银行业数据大集中下潜藏的巨大风险。数据集中也意味着风险的集中。在深圳发展银行全行业务依赖于深圳一地单点解决的状况下，一旦深圳的电脑数据中心发生灾难，其全国范畴中的全部分支机构几乎全部业务都将瘫痪。这将造成巨大的经济损失，且不说客户流失、名誉受损，甚至尚有可能会因此引发社会的不安定。通过对业务风险与冲击影响的具体评定，深圳发展银行选用了复合等级的灾难备份方案—对核心业务系统采用“零数据丢失”的最高等级数据热备份方案；而对于某些辅助业务则采用了比较经济的第二级备份方案，在灾难备份中心保存最新的磁盘、磁带，并且定时进行更换。该系统自5月投入运行以来，涉及数据、数据解决能力、网络在内的整个核心业务解决系统已通过多次切换复制，重新恢复业务流程演习，成果令人振奋。刘政权说：“一旦遭遇灾难冲击，只要1个小时，我们的备份系统就能够顺利切换到灾备中心的系统开展正常作业。”业务持续性管理（BCM）公司通过灾难备份中心构建BCM系统，不仅着眼于IT系统的备份与恢复，更重要的是涉及隐含于其中的、涉及公司整体生命周期的一种业务持续性管理方略与应急响应计划。教学目的：通过对本案例，使学生理解与信息系统有关的安全机制，在系统设计中能结合公司实际状况，进行数据备份与恢复子系统的设计，理解设计的有关原则。思考题：1、公司对信息系统安全设计有如何的规定，试分析？2、保障公司信息系统的安全要做好哪些方面的管理？2、上网调查我国信息系统安全的现状如何，举例阐明？千万元工程的陨落—ERP实施亲历记九十年代末，我当时所在的一家出名的软件开发商在一家大型制造公司获得了一项国家863CIMS项目，ERP被列为其中的一部分，另外尚有CAD、CAPP、PDM系统，整个CIMS系统投入近千万。本人作为ERP的实施顾问，参加了该项目的全过程，在长达一年半的实施过程中，对ERP有了更深的认识。特别是对ERP在国企中的实施有深切的认识和切肤之痛，从中发现不少问题，而正是这些问题直接造成了实施的失败。一、项目背景这是一家产值八亿的机械制造公司，职工7000人，技术人员600人。组织构造为5个事业部、20个处室、9个分厂、1个科研所，还附属有医院、小学、托儿所、招待所等社会福利机构。九十年代中以来，公司连年亏损，好在树大根深，尚未大伤元气。近来，由于国防订货激增，产品一时间供不应求。但由于管理粗放，成本节节攀高，产值虽大，效益却很普通。这是公司准备上ERP的动因之一。开发商则是一家新兴的软件公司，有大概120人的开发人员。近年来，仿照一家出名的外国软件开发出了自已的ERP软件，而这个项目则是开发商的第三个大型项目。该项目经国家立项，列入863CIMS计划（并得到国家一定金额免费拨款）。因此，项目资金来源为：自筹+上级主管拨款+国家拨款。二、实施过程中的问题国外有关ERP实施的阶段划分是有道理的，只有每一种阶段的工作都做好了，才干确保ERP的实施成功。现在我就结合这个程序来分析我的亲身经历的ERP实施。1.领导培训ERP系统被视为一把手工程，对公司高层领导的培训是一项目十分重要的工作。而实际状况是如何做的呢？应当说开发商从一开始就十分重视对公司一把手的工作，但不是进行先进管理理念方面的导入，而是把大量的精力放在了公关上了。这个价值近千万元的项目居然不进行招标，各家公司各显神通，种种手段不一而足。只请了一位机械制造专家作了CIMS原理的专项讲演，而没有对ERP的理念作任何形式的导入工作，这就从一开始为项目的失败埋下了祸根。因素：首先，开发商实施队伍尚未完善，笔者作为唯一含有开发经验和管理经历的实施顾问，既要从事开发工作，又要主持多个项目的实施，困难是很大的。国内的ERP软件也是近来几年才出现的事，开发商特别缺少既懂当代制造业管理又含有较高计算机水平的复合型人才。开发商主观上认为自己在公关活动中的工作足以确保后续工作的顺利进行，也不乐旨在这方面投入太大的人力、物力，尽量减少成本开支。除了搞了一次讲座外，就没有搞过管理理论方面的培训了。另首先，公司领导上ERP项目的动机复杂。既想通过ERP提高管理水平，又有攀比跟风以及更深的不为人知的动机。公司的各级管理人员对此也是心知肚明，因此上下都对ERP项目缺少应有的信心和工作热情。2.需求分析开发商的需求分析工作也极为马虎。仍然是出于确信自己的公关投入能够确保项目成功（这里开发商理解的成功就是收到项目款），开发商尽量地减少成本开支，前期的系统规划工作基本上是为了应付立项报批而做的，对二次开发基本没有什么意义。3.BPR在这个项目的实施过程中，无论是开发商还是顾客都没有提出来要进行公司管理流程再造的工作。作为实施顾问，笔者曾提出过对公司工作流程进行改善的建议，但却泥牛入海，恨无消息。并且在我们进驻公司的时候，公司刚完毕了对组织机构的调节。其组织构造仍然是高耸的非人格化的机械构造，我们就是在这样的管理环境下，开展ERP的实施工作的。4.项目组织从形式上成立了三级项目组织，公司一把手出任领导小组组长，核心小组、各部门项目组也有重量级人物出任组长。但事实上，一把手虽说是组长，但从头到尾只参加过两次会议，说某些的官话、套话走人。而其它负责人对ERP知识极为欠缺，信息中心主任（项目的具体负责人）虽说是计算机大专毕业，但极少钻研业务。5.实施计划由于CIMS涉及多个系统，计划的组织工作极为繁重，头绪极多。但整个计划极为概略，只有一种粗线条的时间表，各系统分头进行，互不沟通。加之在发包项目时，CAD、CAPP、PDM系统包给另一家驰名的软件开发商，不同的软件开发商所用的开发工具不一、工作方式各异，协调起来十分困难，经常出现混乱，并且开发出来的系统与我们的ERP系统不能有效集成，形成互无联系的信息孤岛。6.培训工作我们组织了对各部门的操作员培训班，从计算机的基本知识开始进行了系统的培训，并进行了较为严格的考试，合格的颁发了上岗证。参加培训的是一线基层的女工，她们体现出了较高的学习热情，经常主动加班学到深夜。但培训面不宽，没有进行持续扩大的培训，但各级管理人员没有参加，这直接影响了实施工作。7.数据准备公司布置了全厂的库存盘存，对库存账、物进行了一次较为彻底的清查。但由于公司数年来实施的是粗放的生产管理方式，系统规定的某些基础数据，公司没有完整的统计，因此仍不能达成系统的规定。例如，各零部件的制造提前期、采购提前期没有一种精确的数据，特别是采购提前期没有历史统计资料，也没有制造经济批量和采购经济批量的概念。我们不得不亲自整顿浩如烟海的数据，进行分析勉强拟定出每次订货成本、库存成本，从而为制订出经济制造批量、经济采购批量打下了基础。另外，该厂诸多零部件的工艺原则、成本原则、损耗原则均制订于七十年代，早已不能适应现在的市场状况。8.二次开发由于没有对公司业务流程进行重组，我们不得不对软件作了较大的修改。在实施早期，我们坚持规定公司的业务流程按ERP的规定进行改造，双方暴发了激烈的争执。通过一段时间的僵持，开发商的老板给发来我们训示：顾客是上帝，顾客要我们怎么办就怎么办，不要再进行无谓的争执了。于是，我们只有谨遵上帝的意愿，对软件进行了较大辐度的修改，使ERP软件带上了浓重的国企特色。三、管理冲突上面所述问题直接造成了两种管理模式的冲突。1.观念之争在实施过程中，我们始终处在先进与实用的观念之争的中心。公司对笔者先进的管理理念和丰富的实践经验是必定的，但又说他们那一套虽不先进但却是实用的、有效的。支持他们的理由就是按ERP的模式重组生产，将会给已经超负荷的生产运转体制带来混乱。事实上，正是由于公司延续三十年不变的管理体制才使得公司不能应付新世纪的挑战；正是由于旧的生产管理体制才使公司不得不进行低效益的超负荷运转。这不可能应付市场日益严峻的挑战，总有一天会不负重荷、彻底崩溃。如果等到公司完全丧失竞争力，再来进行重组时，可能为时已晚。为了说服他们，笔者对公司的生产模式给他们做了具体的分析，明确指出其中的问题。数年来，该公司的生产模式是计划目的或订货合同目的查半成品库库存数下达各分厂的月生产计划各车间生产调度指令各车间自拟物料需求计划生产处审批分厂审批各车间执行。从这里能够看出，在下达生产计划时，传统的办法使公司生产计划制订者只考虑一种影响因素，即制订计划这个时点上立刻能够用于装配成品的半成品库存数。而其下层的物料库存数量则不在公司生产计划制订者考虑之内，而是交给下级分厂或车间自行决定，由于各部门之间信息不能共享，加之出于多个本身利益考虑，下级提出的物料需求计划经常出现多报、漏报的现象，很不精确。且以上库存数据均为静态数据，没有考虑到即将达成的物料数量。计划的环节多，审批烦琐，对市场的变化反映缓慢。另外传统的生产管理模式没有进行生产能力计算，只是粗略地凭经验预计，没有制订出具体生产能力需求计划。以上这些工作虽说对他们有所触动，然而囿于体制，公司难以对业务流程进行根本性的再思考和再设计。2.利益之争即便是没有进行BPR，没有出现权责利益再分派的大震荡。但ERP项目仍给公司各级管理人员带来了利益之争。由于这次项目的决定上，主管生产的副厂长在系统选型时被排除在外，其它领导对项目决定的方式也存在不满，因此始终对实施ERP采用消极态度。而各车间、分厂的管理者则有诸多人紧张ERP系统的实施使他们对下面的管理太过透明，不利于运用权谋来治理下属，故而也采用了消极观望的态度。3.粗放与精确之争根据ERP的原理，我们要对制造的各环节进行精确的控制。以α产品为例，该产品的BOM由十七层共127个物料构成。其中有制造件、委外加工件和采购件，有的制造件工序达成几十道之多。有关如何制订产品的BOM，我们与生产管理部门暴发了激烈的争执。最先，我们和公司有关人员研究决定，根据α产品的零件表把BOM划分为十七层共127个物料，生产管理部门起初由于对ERP的工作原理不甚了了，也没有提出反对意见。但在实践中一经施行，上下暴发出一片反对声。公司长久以来始终管理粗放，工序多、流程长、环节多，制造加工过程常有多个损耗，发生差错又经常上推下卸。车间与车间之间、各车间与分厂之间、分厂与总厂之间的统计数字长久不一致，通过多次大规模人工清查，仍然查不清因素。整个制造的过程宛如一种黑箱，主管生产的领导只懂得从源头投入了多少原材料，最后产出了多少成品；而中间损耗的详情不清晰，如具体损耗在哪一种部门、哪一种工序、损耗多少、因素是什么、负责人是谁不甚了了。公司的领导极想通过ERP系统来控制生产的全过程，搞清上述问题。那么要做到这一点，就必须把BOM层次分得尽量细，固然就规定对BOM上每一层次的物料进行控制，规定每一种负责人每天录入收到原料数、加工完毕数、加工损耗数、未加工完毕数、检查合格数、加工损耗因素等数据。生产线上的每个环节、每个负责人都处在受控状态，这固然与原有随意、散漫的工作模式大相径庭。于是，从生产管理部门的管理人员到生产线上的工人都以种种理由拒不执行。一种荒唐可笑的理由竟是ERP系统的工作模式产生控制单据过多，浪费纸张。这首先固然有两种管理模式更迭带来的必然振荡，而更有各级利益的深刻冲突。作为公司的高层领导固然但愿通过ERP系统更有效地对下面的工作状况进行监督，而中下层的管理人员、工人固然不乐意接受这种单方面的监督。高层与中下层之间、中下层与工人之间原本就存在深刻的矛盾冲突，而ERP系统的实施在某种程度上加剧了这一冲突。这也是没有事先进行BPR所带来的一种明显的恶果，如果事先进行了合理的管理改善，把各方的利益结合起来，就不会造成这种普遍反对的成果。面对来自中下层的强烈反对，国有公司的管理弱点暴露无遗，高层领导也不敢强行推行。最后，由开发商与公司的领导商讨后裁定，适宜减少层次，减少控制环节。于是α产品的BOM构造层降为9层86个物料。4.采购方针之争根据ERP的管理思想，应当在需要的时间向需要的部门提供需要数量