在软件维护中如何实施软件工程?(mycode)

[mycode]

在正常的开发中，将人员划分成需求分析、设计开发、测试等,一般都是可以理解的。
但当软件进入维护期时,人员又该如何划分?
如果还按开发时进行划分,当用户有新的问题,有大有小，也许就是加一个小功能,也许会扩展出一个系统.此时应该由谁去和用户了解这种情况?
如果用户又只是在操作时,出现了一点小问题,又该谁和用户打交道?
由于在事先,你是不知道用户会有什么要求,所以不知道该由谁去打交道!

如果软件进入维护期,还按开发时对人员进行划分,又会造成人力资源的浪费.如果不按开发时划分,不能保证维护人员有足够的能力完成软件的维护任务.如果软件维护的人员减少,提高软件维护人员的能力,也就意味着还要付出更多的薪水,成本又增加了.到底怎么才是合理的人员安排,工作流程安排?

[WindowsMe]

当时开发人员必须留出一个来主持项目的实施和维护，如果系统修改，正常是要先修改文档，再修改程序。将修改存档记录。

维护一个项目组成员带新人就成，新人都是先从维护和文档，再到一线的，如果是实施的话，看你公司对这套产品有什么计划了

[青润]

我个人感觉，如果你说“如果不按开发时划分,不能保证维护人员有足够的能力完成软件的维护任务.”，那么就只能说明你们的开发过程并不够规范，无法达到当某一个人离开这个项目的时候，其他人可以在短时间内接替他的剩余工作的要求，也就是说：你们的软件开发过程的规范性上有问题。
一个开发过程规范的软件，应该是在其中任何一个人离开项目后，一个具有相同素质的人可以在短时间内完全接替前一个人的工作。
我个人认为：你应该考虑增加一些开发中的文档型工件，提高对软件开发复用性和可回溯性的要求。

[Jack_Loo]

目前在国内很少有在维护阶段保留开发人员的做法，主要原因是成本问题。
但应用程序通常在维护阶段会由客户提出修改要求，经过方案可行性论证通过后，成立新版本程序的开发组，由这个开发组来完成维护工作，许多公司好象都是由新人来做的。新版本完成后，小组就解散。

[mycode]

谢谢几位给出的很好的建议！
软件系统在进行维护期时的工作流程应该是怎么样的?
需求变更控制->设计变更->编码->测试->版本控制->投入使用。
如果采用这样一套方法,再加上前几位所说的。这种维护的角色该如何划分,如何与开发时的角色相关联。如前所述的方法,留下的人员有足够的能力完成好吗？

[mycode]

up

[Jack_Loo]

只要你有需求文档，所有的功能设计文档，所有的程序设计文档，所有的测试文档，新人也完全可以完成这项工作。

[mycode]

涉及到文档了。但我觉得就算是有全部的文档,但文档中有些内容是肯定不会写上去的,但实际中却需要解释的,新手看了这样的文档,怎么可能会？
如在某个行业的基础常识.这种内容是不会写进需求文档里。

[mycode]

没有按软件开发规范来做,也就不会遇上我这样的问题了.
软件开发规范的重要性和必要性,我就不多说了。

[青润]

我觉得软件开发规范也不一定都是合理的，因为总有一个限度，一个公司所承接的项目不可能都是十分相近的（比如说规模、时间、资金等等等等），大的项目和小的项目肯定是有很多差别的，因此对于一个公司的规范来说，也应该有比较强的伸缩性，再加上公司所能够提供的环境、时间、资金和人力（这些部分将影响这个规范的一些具体实施）等等。
一般来说，在中国，没有个三五年是不可能建立一套很合理的规范的，国外的很多大公司已经在规范上作了多年，有些甚至是几十年，所以，千万不要盲目引进和应用。

[snowtop105]

我是在企业做软件的，由始到终参与整个开发过程，
最后还要负责维护。没有按软件开发规范来做。
通常是写一部分用一部分，通常根据用户的需求来做。

[mycode]

我同意qingrun(青润)的说法,没有个三五年是不可能建立一套很合理的规范.
但规范还是需要去引进,实施.关键是看怎么样才能适合自己的需要.
我现在的做法是,先开始按规范来实施一个小项目,但并不怎么解释规范,在做的过程中,只去保证项目最终结果。再来讨论总结项目过程中发现的问题,再根据规范上所说的,项目组来理解讨论,如何通过规范来解决此类问题.这样,项目会愉快的去执行规范。由此慢慢建立自己的规范。

[milchcow]

我也同意qingrun(青润)的说法，但是规范肯定是要的，不然的话永远都做不大。