UML软件工程组织

软件开发中的弊病
CSDN dhl2001

我来抛块砖,也许是些谬论,希望看到大家的高见.

首先,本人相信,软件工程的方法,如果能够使用得好的话,可以很大地提高软件开发的效率.

但是,在实际工作中,一个单位的开发人员水平参差不齐,就我本人的经历,发现很多单位还是习惯于极其落后的手工作坊式开发.别说使用CASE工具,连程序的文档都懒得写,即使有文档,也就停留在一个非常简单的说明,例如程序某个类完成某项功能,至于该类的结构如何,各成员变量干什么,各函数干什么,你就自己琢磨去吧.

说实话,本人也很希望自己所在的开发组是一个组织有素的团体,一切按照一种有序的状态进行,然而在现实中却很难做到.很多人对于软件工程本身就很怀疑.诚然,软件工程不是万能的,但有些人却走到了另一个极端,而且在他们看来,很多软件的开发,就是几个人,按照一种很随便的简单的组织开发出来的.应该说,如果项目很小,也许软件工程的意义并不大.假如我一个人开发一个小项目,我敢打赌说我不需要任何的文档,充其量在个别复杂的函数中增加简单的注释(这是本人从小养成的坏习惯,从中学学习BASIC开始就拒绝写程序流程图,被老师说了几次,然屡教不改).但是,只要设计到两个以上的人,就需要一定的组织.

然而人们的习惯是难以改变的,本人进入一家单位后,自己是从最底层的程序员做起,糊里糊涂编了一堆代码,到最后却由于当初设计人员的失误,这些代码后来又做了很多次改动,本人犹如在一个烂泥潭里打滚,实在有些厌倦.和我一同进入单位的一个人,一开始对此极其不满,和上司说了几次,但是头们觉得写文档是额外的工作量,只要程序开发出来,能够用就行了,很少考虑进一步维护的问题.然而我们却走了几次弯路,正所谓欲速则不达.

其中一次是头们草草地决定上一个项目,而且觉得只要两个月就出来了,但是实际上半年后才开发完毕,但是开发出来的程序,一运行就需要占用大量的系统资源.根本无法推广到我们的用户那里(我们开发用的机器配置都很高,但面向的用户却还是386或486水平,遗憾的是他们设计时根本没有考虑到这一点).

另一次是一个比较简单的数据库应用,该程序仅仅是把一些收集到的一些信息全部显示出来,有一个人开发显示用的界面,另一个人开发录入信息的界面.然而由于一开始考虑得不够周到,经常发现库中缺少一些必要的项,于是又修改数据库的结构,每次结构的改变,都需要前台、后台程序做相应的修改.又是一堆烦琐的无谓的劳动.直到后来暂停下来,仔细地分析了各种可能变化的因素,才设计了一个比较好的结构,这已经一年时间过去了.

本人在学校时,软件工程的基本概念是清楚的,但却没有什么经验,而且说实话,学校里很多知识是很教条的,实际中如何运用还是不太清楚,因此刚参加工作时,本人对于单位里如此无组织的开发持观望态度,然而结果却很令本人失望.于是我开始了行动,经过一番激烈的争论,本人列举了一大堆失败的事实,终于让顶头上司意识到无组织开发的效率低下,本人也终于成了技术部门主管。然而回首这段往事,不禁感慨万千,我初步估算了一下,从我进入该单位到现在,有四分之三的工作都是重复劳动,或者是无效的劳动.

 

版权所有:UML软件工程组织