应用数据分析 提高信息系统建设质量

□ 张光伟

一、数据分析的概念

数据分析是指用适当的统计分析方法对收集来的大量数据进行分析，提取有用信息和形成结论而对数据加以详细研究和概括总结的过程。

1.数据分析系统运维表

应用数据分析理论对信息系统运维表进行具体分析，不仅可以清晰地看到系统在运维期间存在的问题，而且能反推到系统前期建设阶段的疏漏以及后期该如何逐步修正、总结并持续优化发展。由于运维表单整体页面较大，不便查看，图1中系统运维表仅仅截取一张系统运维表的一部分。可以清楚地看到，很多分项列表用不同颜色标注，这样的表所含有的信息量对于很多其他业务来说也许仅仅是九牛一毛，但正是通过这样的一张简单的系统运维表，通过数据分析就能发现问题。只有发现问题，才能找到问题的根源，找到解决问题的方法。

图1 系统运维表

2.数据分析案例

笔者针对某平台的6个子系统自2019年1月至8月的所有数据展开统计与分析，运维数据来源是4张如图1格式一样的Excel表，分别由4个运维人员进行实时运维管理。经统计，问题总量为772条，共分为系统问题（348条）、操作问题（47条）、需求变更问题（368条）、其他问题（9条）等4类。

3.通过图表发现问题

由图表发现，系统问题和需求变更问题分别占问题总量的45%和48%，而操作和其他问题只占总问题量的6%和1%。由此可见，企业的运维成本都体现在解决系统问题和业务的需求更变问题上，可以推断，信息系统表现出的质量问题主要源于2个方面。

（1）问题分析。系统都已处于运维期，而目前需求变更问题为48%，说明系统之前的需求调研不充分，不彻底，需求分析不准确，导致系统建成后出现如此多的需求变更问题。因为每一个系统项目都有一个完整的建设周期，通常称这个过程为软件工程。其重点分为需求调研与分析（占16%）、产品设计与详细设计（占24%）、编码与单元测试（占28%）、集成与测试（占23%）、移交（占9%）等5个部分。

（2）图表解析。需求调研与需求分析在软件工程的总占比为16%，设计与测试工作分别为24%和28%，而集成测试为23%，由此可见，工作量为16%的客户需求，就需要设计与测试总共为75%的工作量，约4.7倍的关系。而这是在系统设计完全吻合需求的情况下所计算的结果。如果客户在系统移交之后还出现需求变更，意味着所有工作必须重新来过，即所有的工作都要按软件工程的顺序重新走一遍。可见，一个数量的需求更变会导致后续软件实现工作量的数倍的递增。需求变更成本与项目周期关系如图2所示。项目周期会随着需求变更成本倍增而无限延长，总之需求调研的符合度决定一个软件项目的成败。

图2 需求变更成本与项目周期关系图

二、通过数据分析发现问题

通过数据分析发现，需求调研与需求分析是软件工程最重要的组成部分。就好比销售一款产品，而你却不知道客户的需求，则销售的成功率几乎为零。例如，通过描述，软件人员理解的客户需求是一支铅笔，而当开发出来一支铅笔，客户当时觉得很好，但一段时间后他又需求是一支自动笔，此时需求变更所产生的成本与项目周期就瞬间倍增。而客户往往就是因为看到了这个是铅笔的时候，才想起铅笔要是自动出铅才更优秀。但他不知道生产铅笔跟生产自动笔需要的设备不一样，后期需求已严重偏离了前期的需求基线。那么这个时候有人就问，为什么之前不跟我说直接做成自动笔，而是先做了铅笔？我提出做自动笔就不合理吗？这个问题非常好，这正是前期的需求调研意义所在，也是软件咨询师的职责和价值的体现。因为软件咨询师必须清楚，但需求方不一定明白，生产铅笔与自动笔的不仅仅是设备差异，管理要求同样差异大，设备可视同为开发费用，而需要的铅笔精准度就好比实际业务的精细化管理。比如，当前业务本身就是粗放型管理，只适合生产铅笔，你非要提出做自动笔，那就要特别提示需求方统筹考虑是否将管理流程、原材料、设备全都换掉，而且所有管理人员是否全部培训上岗。因为用铅笔的一年级与用自动笔的三年级学生本身就需要时间不断积累和成长。可见，软件与商品的本质区别就是软件无形而商品有形。换句话说，如果需求调研时就阐明需求与实际的差异，那后续的偏离需求基线的需求就不会出现。所以，需求调研是软件建设过程中的重中之重，是需要软件咨询师或需求分析师不断的与客户进行沟通，理解并彼此确认的过程。

通过问题分析发现，系统建设的过程必须重视需求调研与需求分析过程，细化过程管理，逐步形成规范的需求调研与需求分析步骤与模板。加强客户业务需求调研与分析过程中的主观能动性，通过快速原型法确认需求后将各类文档、纪要资料形成文字并签字确认，职责分明，需求明确。建立需求基线，制定简单有效的变更控制流程。需求变更须通过申请，评估后确定精确的需求与范围的定义，将需求变更化为必然的、可控的和有益的。

调研方式与过程可通过以下描述进行：需求调研本身就是通过需求方与软件方在互相达成共识的基础上进行的，通常可以通过调研问卷、访谈、会议、头脑风暴、讨论或通过快速原型法等多种方式进行。在这个过程中，软件咨询师的角色非常重要，可能属于需求方，也可能在需求方，实际中多在需求方。通常由一个协调人充当，但其职责非常重要，既要清楚业务语言，又要有计算机软件专业背景，懂软件开发，在讨论软件与业务是否匹配时，需及时给出专业准确的解答，才可将软件设计成高度匹配业务的系统架构。但是，很多企业因为不懂软件工程，认为软件公司能解决一切问题。殊不知软件公司只精通软件开发，将软件语言转化成业务的实现是绝对的弱项。通过专业的需求调研、原型制作、需求分析、与客户需求不断匹配的需求规格撰写与确认，并通过与客户进行需求评审，一致通过后才可以进行软件产品的下一步的设计与详细设计阶段。而后续的每一步都是根据需求评审过的详细报告而进行，即一一对应的设计、测试、实施等工作的延续。所以，需求调研越充分，需求分析越彻底，软件项目越接近成功。通常经验丰富的项目经理会更重视前期的需求确认工作，加之与客户之间的时间协调，提供资料与文档等配合度，所以这个阶段时间相对会较长。

在整个运维期间，系统问题为问题总量的45%，说明系统在开发测试阶段工作存在漏洞。系统问题是系统自身存在的问题，是因为软件测试阶段的系统测试没有进行彻底，导致很多问题没有被发现，而最终到了客户手里才发现。软件测试需要两个过程，软件测试与集成测试。其工作量占比分别为28%和23%。而很多专业软件公司，为了节省成本与工期，缩减了大量的测试工作，而当技术能力与测试管控能力不够强大时，很多隐藏的系统问题却没有被发现，只能直接被推至到移交阶段，即业务验证期。由此可见，软件测试不容小觑。

三、解决措施

很多公司都是请专业的软件公司开发，但对于非专业的需求公司，根本不清楚如何限定和规范并签订软件开发的合同，不清楚如何通过签订合理的软件开发合同确保软件后期运维等问题的归属及自身利益。通过数据分析可以清楚地看到，对于软件公司开发的系统，在技术合同中应明确系统问题发生的比例，超过部分可根据具体软件开发成本协商，按比例扣款。而针对自己公司自主开发的系统，也可根据员工管理成本或绩效奖金，按系统问题发生的比例，超出部分作为绩效考核依据，酌情扣除。通常高质量的软件测试虽不能100%避免系统问题，但经过全面的系统测试后，至少能规避95%～98%以上的问题。换句话说，只允许系统出现3%左右的系统问题，而上下限浮动不能超过2%，一旦超过5%的系统问题，应采取相应的成本管理措施。

软件测试关键过程如下：软件测试环节非常关键，而单元测试对软件的最小测试单元进行的检查和验证则更为重要。要保障质量则需要大量的时间、耐心与细心。软件集成测试的重点是进行冒烟测试、集成测试、系统测试（缺陷返工，验收测试，上线评审）。每一步的测试都是需要逐一实施，层层排查系统问题，而最终确保系统可以进行下一步的移交工作。移交的工作重点就是系统试运行与客户验收。这个阶段是软件方与业务方的相互配合工作期，是通过真实的业务数据流进行系统业务验证及系统问题的排查，其工作量占比仅为9%。如果软件测试不彻底，测试工作直接跨到移交步骤，那不仅仅是增加工作量，还有程序的本末倒置所带来的更多的时间成本和人力成本的增加，所以每一步都应严格遵守或实施监督管控。

四、结语

通过以上数据分析发现，仅仅从一个列表分项（即已经建成的软件在运维期的问题分类比）便可反推到其建设期的过程状态。签订软件合同时的注意事项，整个软件建设过程应重点做什么，该如何做，明确软件实施的管理重点，这些都具有非常重要的价值和意义。