|
软件为什么需要维护?
软件维护一般是在软件交付用户使用之后才进行的，一般先是面向程序的缺陷维护，再是面向设计的功能维护，以后可能是二者交替进行。 软件维护活动一般有两种形式，第一种形式是：软件的需求文档、设计文档、测试文档齐全、代码的可测试性好，在此基础之上的维护活动会很容易进行。因为对于发现的软件缺陷，维护人员会比较容易定位问题所在，而且通过复用测试用例，可以很容易的完成代码更改后的验证和确认。这种维护形式称为结构化维护，它的维护代价很小，花费的时间周期很短。 与之相对应的另一种维护形式则相反。它是以快速完成软件编码，通过软件验收测试为第一目的，不注重软件开发过程中各类文档、数据、资料的存储和维护。这样一来，在进行维护活动时，维护人员将很难快速定位缺陷所在。由于缺少足够的设计文档，使得维护人员不得不重新进行需求分析、设计、测试等活动。这样的维护活动不亚于重新开发软件，甚至由于代码的晦涩难懂，花费的代价可能还会更高。这种维护形式称为非结构化维护，它的维护代价非常高昂，维护周期也比较长。 一些管理者可能会认为虽然软件开发的数据文件资料不完整，但是软件原来的开发人员还在，他们对这个软件很熟悉，一旦需要进行维护活动，可以很快地解决问题，不用依赖那些数据文件。 可惜，这种一腔情愿的想法会被现实狠狠地击碎。现如今人员的流动性非常大，没有哪个人员会在同一个位置上，10年8年不动的。即便没有发生人员流动，一个人仅凭大脑的记忆，对一个已经开发完成一两个月以上的、功能稍微复杂一点的软件，他还能想起多少呢？ “好记性不如烂笔头”，还是保留文件记录更靠谱一些。 对于一些军用软件开发来说，软件维护的情形有些不太一样。这一类软件的交付是与设备相伴进行的，而设备的交付，会有一个很长的研制周期，三年五年都有可能。首先，很长的研制周期，意味着人员流动的概率会更高，组织应该更重视软件的维护活动。其次，这类软件的需求都是由系统分解的，在交付给用户之前软件首先要交给系统使用。所以，软件的维护活动，实际上在交付给系统之后and随设备交付给用户之前就已经进行了。这类软件要实现结构化维护，那么在交付给系统的时候，就应当已经完成了需求、设计、测试文档的存储和维护，实现了代码可测试性。 而这些设计文档的编写、评审、配置管理，代码编写规范等的要求，正是实施CMM的过程要求。所以，要实现软件的结构化维护，组织应当坚持实施CMM。 当软件组织达到CMML3以上时，由于软件过程的持续改善，对软件质量的评审和审计活动的加强，软件过程数据库作用的发挥，关于“程序上有缺陷”和“设计上功能不齐全”的情况，将会逐渐减少；即使出现了维护工作也会由于设计文档的齐全使得维护工作量很少。总之，实施CMM会有助于组织高效地完成软件维护。 真正维护工作量大的单位，就是CMMLl的软件组织，因为他们管理无序，文档不全，工作不规范，表现形式就是：人治加个人英雄主义。 参考书目：《实用软件工程》 、 微信赞赏专用通道
|
|
|
