国内应用软件开发管理的探讨

2008-04-09 04:08:31来源:互联网 阅读 ()

新老客户大回馈,云服务器低至5折

随着行业生产的扩大和提高,对企业运作的管理和效率的要求也在不断提高。一个好的适合企业管理的应用软件可以给企业带来成本,人力等资源的大大减低,从而为企业带来经济效益。而企业对应用软件的需求又带来一种局面,即企业不愿为接受外面已有的应用软件来改变自己已经成型的管理方式,又确实需要进一步借助电脑的应用来提高企业的管理水平。于是企业根据自己的管理需要来开发应用软件,一旦把软件开发局限于企业内部,开发出来的应用软件质量必然受到程序员的水平和经验所限。怎么让企业利用企业内部已有程序员来更好地为企业开发性能好的应用软件呢?以下我们将从企业应用软件开发管理的角度加以探讨。

一、应用软件开发的主体程序员

应用软件发展到今天,已积累了大量好的经验值得我们学习,这里就不再赘述。由于国内企业应用软件开发程序员的水平高低不同,在这种情形下开发质量和稳定性较好的企业应用软件是比较困难的,怎样尽可能地使应用软件开发的数量和质量不受程序员技术差异的影响呢?当然不需要每一个参与该应用软件开发的程序员都具备了各项能力以后才去完成,只需系统员具备解决技术难题的能力,合理分配工作来完成。技术在进步,人类也在进步,通过完成具体工作来不断地提高各个成员的素质,在技术提高的同时,提高技术实施的水平。

例如:先进的企业生产线在没有饱和的情况下,产量和生产力会随着工人(技术水平相似)数增加而呈显著正值增加。其简单的数学图形可用图1表示。

在面向对象编程的第四代语言广泛应用的今天,在企业现有程序员的基础上,完全可以通过改进一些应用软件开发的管理方法来提高企业应用软件的开发能力。下面是我们通过实践而产生的一些观点,拿出来和同行们探讨一下。

让我们简单地假设把这种企业应用软件开发方法同生产线加工生产模式作一比较,如下图所示:

工厂生产线作业 企业应用软件开发作业

开始 开始
流水线设计 需求分析
流水线安装 信息流分析
系统员 流水线调试 数据库设计
流水线运行 应用软件开发分析
流水线维护 各种规范的定义
对象类设计及再用性封装
简单作业培训 各种定义熟悉
程序员 生产线上实习已定义的对象类使用了解
组装加工产品各种重复工作的完成
规范定义标准检查
系统员 质量检验和控制论 模块运行检查
整体品质控制检查
程序员 包装完成 系统编译运行
完成 投入使用

可以看出,一般的先进生产线,若在非饱和状态生产能力会随着员工的增加而正向线性增加。在此员工一般不需要特别培训,即一个在该生产线上工作五年的员工和一个工作一个月的员工的工作能力相差无几,因为他们的工作只是在生产线上加工,生产线的维护和改造则由技术工程人员完成,再业看看企业应用软件开发的管理方法和改进的情形。

二、企业应用软件开发的内部调节管理

在企业内部软件开发的数量和质量与程序员数量会是一个怎样的关系呢?这里假设一个各方面知识和能力都合格的程序员值数为1,单方面知识和能力合格值数0.5,那么我们可以为企业软件开发情况做一个分析:

1、理想情况为软件开发的数量和质量随着值数为1的程序员的数量变化而成正比变化:
1=1
1 1=2
1 1 1=3
1 1 1 1=4

1 1 … 1=n
这种情况解释为真空,只可能出现在一般的专业软件开发公司。在企业内部我们就不必过多分析。

2.一般情况为软件开发的数量和质量随着值数0.5的程序员的数量变化而成正比变化:
0.5=0.5
0.5 0.5<1
0.5 … 0.5=1

这种情况在企业应用软件开发中较为普遍,如果值数为0.5的程序员的知识领域是互补的,又是较为理想的,有可能在积级配合下达到甚至超过值数为1的程序员所完成的工作。如果他们的知识领域是相同的,又为这种情况下的最差组合,完成的软件数量和质量就达不到企业发展的要求。

3.较差情况为软件开发的数量和质量随着值数为小于0.5的程序员的数量增加而几乎不发生变化:
0.4=0.4
0.4 0.3=0.4
0.4 … 0.4=0.5

这种情况在企业应用软件发展初期较为普遍,即使值数小于0.5的程序员的知识领域是互补的,而且是在理想的积级配合下,达到甚至超过值数为1的程序员所完成的工作的可能性也是极小的。如果他们的知识领域是相同的,又为这种情况的最差组合,完成的软件是列加远远达不到企业发展的要求。

4.经济而又适合企业的组合(为现代企业所接纳)是必须有一名值数为1的系统分析员,加上值数低的程序员组合。怎样更好地发挥这种组合的效率,是我们议论的主题。

从图2可以看出,一个企业的软件开发程序员的值数(完成编程技术难度)高低各不相同,这是实际情况。当然我们这时是从某一个时刻静止的角度看去,随着程序员值数的增加我们以下的观点仍然成立。如果程序开发过程中的工作安排是根据各人的实际情况合理分配的,那么整个开发过程基本上会按计划逐步完成,否则会出现许多方面的问题,影响整个计划实现的进度,怎亲才算合理呢?我们知道应有软件发展到今天,其开发过程已是一个有计划的技术性团体合作的过程,在对各个程序员技术能力要标的同时,对整个开发团体的协同作战能力也是一个考验。面向对象式编程为这种团体工程提供优质保障,从管理的角度,在图2的基础上我们增加了一个企业程序员在软件开发时所应完成的技术难度线。如图3所示。

由于应用软件的开发是一个技术要求较高的工作,如图3所示,很明显如果把一些技术难度系数高于某些程序员值数的工作安排给他们,必然会使整个计划的实施受到他们工作完成的质量和数量的影响,从而使计划失去意义。怎样解决由于技术难度的分配带来的问题?传统的方法是着力于对那些值数较低的程序员进行培训,提高他们完成开发软件技术难度所需的值数。我们知道这是需要大量时间、精力和资金作保障的。同时由于人员日趋变动的社会经济的发展,企业能否认可和等待,其本身就使这种方法的实效大打折扣。我们找到了另外一种可行的方法,那就是说既然技术难度不能统一分配,我们把一般程序员所需完成工作的技术难度线降低,而把系统分析员的技术难度线增高,如图4所示。

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:面向二十一世纪的嵌入式系统综述

下一篇:开发流程中的可用性