Chinaunix首页 | 论坛 | 博客
  • 博客访问: 944755
  • 博文数量: 134
  • 博客积分: 7443
  • 博客等级: 少将
  • 技术积分: 1411
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-10 20:18
文章分类

全部博文(134)

文章存档

2012年(7)

2011年(29)

2010年(16)

2009年(6)

2008年(18)

2007年(58)

分类: 项目管理

2007-02-10 21:02:48

1    对软件维护的误解
软件维护常被工程人员误解为“系统维护”,即维护系统的正常运行。认为软件开发和软件维护是互相独立的两个工作。其实,软件维护是软件开发过程的组成部分。一个新版本的产品发布到现场之后,软件维护开始了,软件维护既是这次版本开发过程的继续,又是下一个产品版本开发周期的开始。
 
软 件维护不只是维护系统的运行。更重要的是,发现和解决软件产品的缺陷,找到改进产品的新思路。绝对完美的程序并不存在,对任何设计或任何代码,总能找到改 进的方法。软件开发必将是一个长期的、反复的过程。产品被使用的经历对产品的改进至关重要,许多时候,只有一个产品真正被使用了,我们才知道本来我们要创 造的什么东西。这也是原型化方法被提出和流行的原因。
 
如果一个产品,很长时间没有变化,经常不是因为这个产品太完美了,没有需要改进的地方;而是因为太滥被丢弃了,或者这个产品太专用,不能添加新的功能或用于新的环境下。
 
2    工程人员在软件维护中的责任。
工程人员在软件维护中担任重要的角色。工程人员在软件维护过程中的作为,实际上是对软件开发过程的参与。软件开发过程是一个长期的过程,在这个过程中,工程人员和开发人员有相同的目标,就是生产高质量地软件产品。当前,我们特别强调,工程人员在工程实施、项目验收中责任。却忽略了工程人员,在整个软件开发过程中的角色。
 
工程人员也是开发人员。
 
在部门里面,经常出现这样的局面:工程人员打来电话说:“我们明天都要验收了,怎么这个模块转不起来了!”。大家好像都有这种体会:越到关键时刻,越出问题,其实这是因为,我们只在关键时刻到来之前,才认真的去使用软件,才认真的去发现问题。 经常是,研发那边发布了程序,工程人员就装一下,一看运行了就可以了,直到“关键时刻”到来之前,才会再想起来去看看。有的时候,甚至在初验的前一天,才 去安装一个新的模块。出现问题后,就开始抱怨开发人员的质量。我要说:最终的软件,应该是工程人员和开发人员共同的产品,工程人员尽早地,准确地报告产品 的问题,就是对最终产品质量的促进。
 
下面是对工程人员地一些建议。
1.认真学习开发发布地产品。阅读文档,参加部门组织地培训。许多优秀的工程人员,对整个系统地了解比开发人员都全面(不必深入但要全名)。不要一副架势:“我不知道你们是怎么回事,反正是没有数据,你要给我解决。”而是使用所知知识,积极的协助解决问题。
 
2.工程人员不止要报告产品的问题,还要报告产品改进的建议。使用的经历难道没有激发你对产品改进的创意?既便是报告问题,也不是简单地想开发人员要一份解决办法,想一下是否可以通过产品改进,今后不必再面对这个问题。
 
3.软 件问题的报告,BUG的发现和处理,是一个很不精确的过程,经常被偶然性误导,浪费大量的时间。特别是,部门的条件有限,不能模拟各个项目现场复杂的环 境。这种情况下,解决问题的第一步,就是设法重现这个问题,找到问题重现的规律。这个规律,对开发人员的指导意义那是相当的大。并且,如果你不能重现问 题,你如何确定,开发人员真的把这个问题给解决了。
 
4.在初验到来的时期内,反复的使用软件,尝试不同的配置选项。以全名测试的策略,让程序的问题尽早的出现。现在有一种态度:“现在系统运行的好好得,可不敢乱动了。”结果到验收得时刻到了,你不得不动得时候,问题就出现了。
 
5.问题出现后,不要忙着责备。许多现场习惯使用这种对开发人员得责备来缓解工作得压力。无论谁得责任,这是你要免对得问题――也许,有一点让你放心,你不是独自面对。
阅读(1947) | 评论(1) | 转发(0) |
0

上一篇:在linux上安装quake

下一篇:反应堆模式

给主人留下些什么吧!~~

chinaunix网友2009-06-15 12:00:21

说的不错,我的工作也是类似的,我是做开发的,经常有工程人员在现场给我反馈。