维护如何做

从我们的发展来看，两类：A最终用户，合同甲方接手处理，但交付内容不够完整，即使甲方维护，也需要提供必要的资料；B最终用户，不可能有能力接手，但是不会了解维护的连续性，自以为想要什么时候维护，增量开发，就可以。

从软件工程学的角度的来讲，软件维护费用日益上升，目前已达到整个开发费用的80%。就这个数字我们可以看出软件维护工作的重要性，但是遗憾的是我们许多软件开发公司往往忽略了它的重要性，或者明知道它的重要性却对如何做好软件维护工作不得其门。

典型问题：

1、深刻理解原开发人员的编程思想通常相当困难。

2、软件人员的流动性，使得软件维护时很难与原开发人员沟通。 =====>difficult to keep since there is no big buget for maintain software

3、没有文档或文档严重不足。

4、软件设计时，欠考虑软件的可修改性，可扩展性。=====>Use one common tech

5、频繁的软件升级，要追踪软件的演化变得很困难，使软件难以修改。

People thoughts:

maintainence, 认为其没有创造性，体现不了自身的水平与价值。

每个有思想的程序员都希望把新程序看成是自己第二生命。

软件维护是一个长期的过程，我们公司很多领导没有耐性，习惯不了长跑。

怎样从技术上确保软件维护可行性呢？

1、借鉴先进管理经验、根据实际情况制定符合自身发展的企业标准和维护组织。

建立维护组织：一般软件公司没有专门的维护机构，除非大型软件公司。

维护机构成员一般包括：配置管理员、维护控制员、系统管理员、一般维护工作人员。

2、  制定计划、坚持评审：

根据软件开发需求和公司情况制定切实可行的计划。维护工作不应该采用“头痛医头，脚痛医脚”的零打碎敲的方法，而应当有计划有步骤地统筹安排。认真做维护工作报告，及时发现问题解决问题。维护报告应包括的内容：该维护任务的范围，所需资源，确认的要求，维修费用及维修进度安排。

坚持评审，在软件开发各个阶段的评审过程中分别考虑它们的可维护性。

需求评审：对将来可能要完善和修改的部分应加以说明，如讨论可移植性问题时应考虑系统接口对软件可维护性带来的影响。

设计评审：数据设计、体系结构设计、过程设计及接口设计是否易于修改；

编码评审：强调编程风格和内部文档；

测试：在软件正式交付使用前，每个测试步骤都应对预防性维护作出提示。

3、  编写软件维护文档：

很多时候我们在解决了问题之后，便自以为事情已经了结，其实这个时候我们还有一项重要的工作没有完成——编写软件维护文档。软件维护文档包括：软件问题报告、软件变动记录、软件维护记录。这样当下次我们再需要修改时，便可以很快的找到问题的原因，减少我们从繁多的代码中去寻找Bug。