监理公司管理系统 | 工程企业管理系统 | OA系统 | ERP系统 | 造价咨询管理系统 | 工程设计管理系统 | 签约案例 | 购买价格 | 在线试用 | 手机APP | 产品资料
X 关闭
长沙OA信息化

当前位置:工程项目OA系统 > 泛普各地 > 湖南OA系统 > 长沙OA系统 > 长沙OA信息化

浅谈信息系统开发中的差错放大及其治理

申请免费试用、咨询电话:400-8352-114

AMTeam.org

浅谈信息系统开发中的差错放大及其治理

陈书勤

常言道:“差之毫厘失之千里”,意指原本一点些微的差异由于未及时得到校正,到头来造成了巨大的偏差。其实,在信息系统软件开发中就常常出现这种由小变大的差错,究其原因主要是在系统开发各个阶段中产生的大小错漏未及时消除,逐级累积放大所致,其严重后果往往是造成系统软件的潜在致命硬伤,不及时发现迟早会造成用户的巨大损失。下面进一步分析系统差错放大的成因、危害和治理措施。

1、信息系统开发各阶段的差错原因溯源和诊断

在信息系统软件开发所必经的需求分析、软件设计、软件编程、系统测试等开发过程中,每个阶段都不可避免地因人为或非人为因素产生一些错误并带到下一阶段中,这些错漏又往往因未及时处理而造成无穷的后患,下面就简单地依次逐级进行差错原因溯源和诊断:

1)在需求分析阶段:由于用户可能对自己的业务叙述以及对系统软件的需求等背景内容不够系统和完善,加之信息系统开发商理解上的偏差,形成包含了错误需求的“需求分析报告”。这种错误包括误解与遗漏,造成随之展开的设计、编程上的逐级错上加错。

2)在软件设计阶段:因为对需求理解的偏差,加上设计本身考虑不周,导致含有错误的“设计报告”出台,根据这种设计方案所展开的编程同样会错上加错。

3)在软件编程阶段:因为对设计思路、意图、方案、规划等基本思想的理解偏差,加上编程本身的疏忽,“程序代码”中往往会错误和漏洞百出。

4)在系统测试阶段:总会有一些“潜伏的错误”没能及时发现,而能够发现的错误在交付期迫近的情况下又不能修改,可能是因为某一模块修改工作量太大,没有修改时间;也可能是因为工作量虽小,但模块修改涉及范围太大,轻易难改,即使是修改也常常越改越乱。
由此这般致使在正式交付的软件中就潜伏了很多错误,造成了软件的“硬伤”,如此差错逐级积累和放大,其危害后果是不言而喻的。

2、信息系统软件开发的差错放大及其对系统开发商的冲击

系统编程员一定都有这种体会:花费了近半个月的功夫、用了九牛二虎之力所编出的程序联机测试时趴了窝,穷究其原因才发现罪魁祸首简单到只不过是一条语句或一个变量的“小错误”,但是错误却是在编程开始时早就埋伏下来了的。

系统开发者也一定都有这样的体验:在系统开发的每个阶段都会把上一阶段文档的要求成倍或成数量级的放大成现阶段的文档,例如1个“用户需求”常常可能需要10条“设计”语句才能展开,1条“设计”语句非得需要10段“程序”才能实现,1段“程序”往往需要10种“测试”组合才能让人感到踏实。同理,差错错漏也同样被不幸地逐级进行放大,致使早期的低级错误,在软件开发后期往往会铸成大错,对用户造成无法估量的损失。

虽然IT业内的系统开发商普遍视“防患于未然、有错必纠”为基本工作原则和职业道德准则,但繁杂的修改返工却让开发商付出沉重代价。因系统差错的“放大效应”,致使越到开发后期,系统软件修改返工所造成以成本、质量和效率三要素所体现的代价就越大:

①在成本上:由于修改返工造成总开发时间和单位开发时间上的延长,直接体现为人、财、物投入的增加;②在质量上:修改软件很少会推倒重来,而往往会进行软件“打补丁”式的补救,却常常常是悉心的修改反而又引入了令人意想不到的新错误,真是一波未平一波又起,刚摁下葫芦又起了瓢;③在效率上:修改返工中若不增加开发人员,则必将导致增加绝对开发时间,使实际开发效率骤降。若增加开发人员,则会因新员工不熟悉原工作流程或由于6人以上的修改返工小组中人际交流时间的激增,而降低了单位时间的开发效率。

差错放大导致的修改返工常常导致管理信息系统软件开发的实际工期严重拖延。更严重的是造成用户与系统开发商之间的反目,使系统开发商的信誉扫地,甚至危及其生存。

3、传统软件工程在克服差错放大问题上的常见误区及其治理

为克服差错放大所造成的软件危机,IT业内于20世纪80年代末期推出了按工程化方式组织管理软件开发的“软件工程”,向广大开发商提供了包括分析、设计、编程、测试方法等软件开发规范的技术手段和包括项目式、专业式、矩阵式管理等模式的标准化现代管理手段。但是,传统的软件工程应用在克服差错放大方面仍然不理想。这主要是因为传统的系统分析设计方法所基于的软件工程方法论所存在的致命误区。下面就分别剖析这些误区:

1)误区之一:“唯技术论与软件至上说”

过去,许多纯技术派和理论派人士,习惯于按照传统的思维,凌驾于用户之上,单纯从技术角度考虑问题,严重脱离生产管理实际闭门造车,全然忘记了信息系统软件必须从实践中来到实践中去的基本道理,忽视了系统必须服务于客户的根本理念。很难想象运行模式与用户的管理模式大相径庭管理软件会有什么实际意义。其实对于系统软件来说,其结构也就正体现了有关原理组成部分的包容关系;软件的流程也恰恰体现了这些组成部分的交互过程;软件的数据则体现了进行这些交互过程所产生的具体信息。俗称为“建模”的软件系统分析设计方法就是在虚拟的软件世界中建立现实世界的应用模型,完全是一个软件反映应用的“镜像”建立过程,是一个虚实结合的辨证过程。

在实践中,我们既不能将管理信息化看成是简单的手算变电算的陈旧软件开发模式,也不能武断地认为只有用先进的管理软件才能改变用户的落后管理模式。实际应用中却是由用户最终根据自身的需要来选择和确定管理模式的计算机化方向。如果系统开发商不能从企业的实用角度看问题,而是一味地逼企业应用所谓“先进软件”,就会陷入两难境地。在信息化建设过程中,企业好比是“病人”,软件商好比是“药商”,管理咨询顾问好比是“医生”。“病人”(企业)需要专科“医生”(管理顾问)进行检查诊断(现状分析)、开药方(管理模式改良方案),“药商”(软件商)再照方(需求)制造相应的药品(软件)。

可以说,软件商依靠的是软件制造技术,管理顾问遵循的是现代管理规范,管理系统软件则是企业管理制度的e化。软件商决不能只一味深钻技术,还要全面理解与掌握用户的实际业务知识,只有这样才能保证为用户量体裁衣,开发出符合管理实际需求的用户系统。

2)误区之二:“顺从迎合论与需求用户决定说”

现实中人们往往都将软件失败归因于需求分析不准,却没有搞清造成“不准”的根本原因。其实正是传统软件工程方法论中过分依赖于通过直接询问用户来确定用户对系统的需求,才是需求分析误差的根源。因为,处于非专业化层面、对信息化系统不十分熟悉的广大用户常常无法条理清晰、完整准确地阐述出自己的要求;而系统开发商也往往受到对用户的业务流程及管理模式不理解或不熟悉的限制,无法正确地把握住用户的真实需求,但是开发商由于急于拉到用户订单,生怕放走了到口的“肥肉”,就经常会发生要么一味迎合用户并非完全准确真实的“需求条件”,做出一付所谓“客户至上”、“唯客户需求马首是瞻”的姿态,要么只是象征性地就用户的不合理需求提出轻描淡写的“暗示”或无足轻重的“警示”,实际上却不坚持正确的观点,到头来也是迎合了用户的要求。这些都是系统开发商极其不负责任的态度,实际上是在知错瞒报。正是因为开发商自知理亏,所以只要所谓的用户需求有变,就只好“曲义迎合”用户,将系统软件修改的补丁摞补丁,根本无法按时交付,让满怀期盼的系统用户从可以理解到可以忍受直至忍无可忍,最终导致双方“反目成仇”。

那么恰当的做法如何呢?答案是:系统开发商应该强化对用户业务流程的理解,全面深入地了解用户的原有业务,尽量以用户的视角考虑系统问题,尊重用户的需求但不迎合其中不合理的部分。必须明确用户对软件的需求主要有功能、过程、数据需求。从大量本土化系统开发成功案例可以看出,系统开发商应从以下几个方面描述用户的业务管理模式,并由此而得出用户的实际需求:

①以组织结构为线索,按层次描述企业部门、岗位、工作职责、工作步骤的组成情况,罗列出每个人的本职工作;

②以业务种类为线索,按环环紧扣模式描述每个业务种类的具体业务流程,这些流程体现了部门间的、人之间的业务往来情况:

③以工作交接为线索,沿着相关的业务流程,收集相应的业务数据(单据与报表),详尽描述这些数据的内容及其之间的关系。

④在包括业务分析和需求定义两个过程的需求分析中,特别应突出业务分析的重要性,应将业务分析过程分离出来,成为独立的阶段。也就是将系统软件的开发流程细分为业务分析——需求定义——总体设计——详细设计——编码——测试——维护等7个阶段。
⑤正视国内企业因为整体管理水平低下而且业务流程普遍因处于成长期而易于变动的现实,也就是对企业频繁发生的并非由于新业务带来的需求变化要事先预计和预留接口。

3)误区之三:“分工精细论与各开发阶段独立说”

通常人们都将信息系统软件的开发阶段精细划分为业务分析、需求定义、总体设计、详细设计、编码、测试、维护等阶段,业内普遍认为阶段划分和工作分解越精细越好,而且常常每个开发阶段采用各自独特的描述方法。

在系统开发的建模方法上,传统上主要采用结构化生命周期建模法和面向对象建模法两种。然而在实践中开发商常常会发现虽然分工十分精细、阶段也十分细化,可仍旧是错漏频出。这主要是由于系统开发各个阶段的文档具有自己其各自独特的表达形式,造成了各阶段文档衔接的“两层皮”现象严重,致使错误乘虚而入,产生了软件的差错积累与放大效应。

针对上述问题,目前国内主要采用系统化、实用化的计算机辅助软件工程(CASE)建模方法加以解决,CASE法集成了结构化生命周期建模法和面向对象建模法两种方法的优点,提供了从业务模型推导需求模型的手段,在此模型的基础上,通过建模技术自动生成软件模型,保证在将企业的业务模型,即组织结构、业务流程、业务信息这三方面的内容描绘得全面、透彻基础上,强调系统开发的业务分析和需求分析阶段的重要性,能够实时自动查错纠错,从而更有效地降低系统软件的错漏,作到防患于未然。

4、结束语

上面我们系统分析了信息系统开发中差错放大的成因、危害及治理,说一千道一万,是希望能够找出一条适合于国内企业的信息系统开发的理想途径,通过完善的业务建模避免差错,防止其逐步放大与扩散,使企业信息化的建设顺利成功地实现。在这一过程中,开发商、用户之间必须端正思想,本着科学务实的态度,建立良好的协作机制,才真正有可能开发出为管理实际服务的信息化系统,达到开发商和用户双赢的理想结局。

发布:2007-03-25 10:08    编辑:泛普软件 · xiaona    [打印此页]    [关闭]
相关文章:
长沙OA系统
联系方式

成都公司:成都市成华区建设南路160号1层9号

重庆公司:重庆市江北区红旗河沟华创商务大厦18楼

咨询:400-8352-114

加微信,免费获取试用系统

QQ在线咨询