“4321”小谈组态软件项目开发的时间安排

扫码手机浏览

关键词:摘要:开发一个项目,简单的说经过调研、开发、测试、维护四个大体的阶段。每个阶段的开发时间不一。笔者主要从事紫金桥组态软件的项目应用开发工作,对组态软件项目开发各阶段的时间安排小谈下自己的看法。      开发一个项目,简单的说经过调研、开发、测试、维护四个大体的阶段。每个阶段的开发时间不一。笔者主要从事紫金桥组态软件的项目应用开发工作,对组态软件项目...
  • 关键词:
  • 摘要:开发一个项目,简单的说经过调研、开发、测试 、维护四个大体的阶段。每个阶段的开发时间不一。笔者主要从事紫金桥组态软件的项目应用开发工作,对组态软件项目开发各阶段的时间安排小谈下自己的看法 。

      开发一个项目 ,简单的说经过调研、开发、测试 、维护四个大体的阶段。每个阶段的开发时间不一。笔者主要从事紫金桥组态软件的项目应用开发工作,对组态软件项目开发各阶段的时间安排小谈下自己的看法 。

      这里笔者提出“4321”的说法,也就是说40%的时间调研 ,30%的时间开发,20%的时间测试,10%的时间维护 ,这里所说的“时间 ”也可以理解为工作量。之所以这么安排时间,原因如下所述。

 40%调研

      从某种意义上说,组态软件是个半成品 ,需要用户在这个基础之上进行二次开发 。组态软件已经提供了诸如报表、曲线、历史保存 、动画连接等常用的功能模块,用户可以便捷的在这个基础之上开发出自己所需要的监控系统。

       组态软件模块式的开发环境虽然极大地方便了用户的需求,另一方面 ,组态软件的功能也是相对固定的 ,难以直接满足用户的一些特殊的需求。

       此外,从整个监控系统而言,组态软件处于上位机的位置 ,需要、模块、板卡 、仪表等硬件设备才能搭建一个完整的系统 。对于一个系统,初期往往有多种通信搭配方案,串口级联、以太网、GPRS 、数传电台 、无线射频等等。

       而且很多时候 ,在使用组态软件开发的人员,不一定是最终用户,而是系统集成商等 ,这里就面临一个双方沟通的问题。只有充分沟通了,才能确定用户的需求组态软件能否实现,选择哪些下位的硬件 ,确定具体的通信方式等 。

      如果开始调研不够认真、明晰,后期的开发从开始就可能出现了偏差,或者项目快结束了才发现有重大隐患 。比如笔者曾接触的一个项目 ,这个项目是监控生产线的设备 ,设计者想通过组态软件监控生产线上的5个PLC,通信距离大概一百多米。初步决定采用1个485串口级联的方式通信,而且已经完成了布线的工 作 ,485串口在一两百米内级联5个plc,技术上没有什么问题。可是笔者和该项目的最终用户进一步沟通后,发现用户对现场监控的响应时间要求不低 ,在1 秒以内 。显然,通过1个485串口通信级联5个plc是实现不了这个要求的。或采用多个串口,少级联设备 ,或更换通信模块,采用以太网通信等方式都可以提 高通信速度,达到用户的要求。

       很多时候最终用户不一定了解组态软件的各方面特性 ,甚至不一定了解他们自己的具体要求,边做边改边提要求的情况很常见 。只有在前期的调研清晰了,才可以最大可能的避免项目后期的重大修改。

 30%开发

      由于组态软件本身模块化的开发方式 ,一般而言 ,一个普通的项目开发时间不会太长,工作量相对不算太多。当然,很多时候 ,项目的开发进度还受到下面硬件设备进展等多种情况的影响,并不单独取决于软件本身 。这里主要是指具体开发的有效时间。

     有人可能会奇怪为何开发的时间要少于调研的时间,这里要说明的是 ,充分的调研可以在开发之前就形成了一个明晰的开发思路,对加快项目的开发时间大有帮助。如果前期调研不充分,边开发边调研 ,那么开发的周期会拖很长的 。

 20%测试

       这里笔者把测试单独提出来,而且给了比较多的时间。是因为笔者所接触的不少最终比较失败的项目,不是调研不充分 ,也并不是开发的不好,而是细节总不到位,总 是有些地方不稳定 ,有些地方不可靠 ,反复修改,修改好了这里,其他地方又坏了。用户不满意 ,不愿意付款,开发者觉得很辛苦,觉得用户挑剔 ,维护的工作量太 大,双方陷入到扯皮的境地,项目也就相对比较失败了 。

      之所以出现这个情况 ,主要原因是项目开发完后,急于验收,认为验收完了也就OK了 ,项目没有经过严格的测试 。开发一个项目不难,但是开发一个比较稳定可靠, 健壮性强的项目是不容易的。严格的测试是保证一个项目少出问题的关键环节之一。很多时候 ,开发者都只是考虑到了项目正常时的情况 ,对于用户一些非常规操作 或现场的一些特殊情况的处理没有考虑周全,导致项目看起来很好,实际运行之后漏洞百出 ,维护起来痛苦不堪 。

项目开发的时侯一般都会边做边测试的,这里所说的测试更多是指项目初步完成后的系统测试。

       关于测试方法,很多文章都有说明 ,什么单元测试、集成测试 、白盒测试、黑盒测试等等,不足而一,这里不再赘述。

没有经过严格测试的项目 ,往往都存在着或大或小的漏洞 。

10%维护

     可能很多朋友早就想说了,“10%的时间维护,太少了 ,项目有太多的时间用于维护了!”。的确,很多项目的确大量的工作用在了后期的维护,这里笔者认为 ,如何真的用了大量的时间认真调研 ,项目开发后认真测试了,当项目真正维护起来的时候,一般工作量不会太大的。之所以后期维护比较难做 ,很多问题出在之前的调 研和测试中,导致了维护工作量的增大 。当然,这里的“维护” ,并不包含软件的后期升级服务等,另一方面用户自身的技术支持力量也影响着维护的工作量。

       这里所说的“4321 ”时间安排也是个大概,并不是每个项目都要按照这个时间安排做 ,比如开发者对流程很熟悉可能前期的调研时间就少些。这里提到“4321”是为了强调一定要重视调研测试,真正的开发工作占整个项目的工作量中并不算太多的 。很多项目的开发实际走的是“1315”,也就是简单的调研 ,着急的开发,开发完了也没有进行严格测试,匆匆验收 ,最终把大量的时间用在了后期维护上。用户不满意 ,也难以再继续合作。

      根据实际情况合理的安排项目各步骤地时间,不仅可以减少项目的总体开发时间,更重要的是可以满足用户的真正要求 ,实现合作共赢 。

成功的项目,不仅可以实现客户的需求,更重要在于带来了持续的合作 。

本文转载自互联网,如有侵权,联系删除