用星十年了，对星的感激之情无法用言词来表达，相信各位星友们都深受其惠。可惜自己对星没做出任务贡献，实在惭愧。
　　言归正传吧，对于软件工程管理问题很早就在我心中了，好几次想向管理员提出来，今天实在压抑不住，先吐为快了；虽然星与其它语言程序不同，有别于其它开发工具，但星设计出来的作品与其它工具开发的作品是没有任何差异的，即是说和其它工具开发的软件一样，要面临软件工程问题。尤其是软件维护问题。
　　软件维护是软件生存周期中非常重要的一个阶段。但是它的重要性往往被人们忽视。有人把维护比喻为一座冰山，显露出来的部分不多，大量的问题都是隐藏的。平均而言，大型软件的维护成本是开发成本的4倍左右。国外许多软件开发组织把60%以上的人力用于维护已投入运行的软件。这个比例随着软件数量增多和使用寿命延长，还在继续上升。学习软件工程学的主要目的之一就是研究如何减少软件维护的工作量，降低维护成本。

1．软件维护概述

投入运行的软件需要变更的原因很多，但主要原因有：
　　① 软件的原有功能和性能可能不再适应用户的要求；

　　② 软件的工作环境改变了（例如，增加了新的外部设备等），软件也要做相应的变更；

　　③ 软件运行中发现错误，需要修改。

由于这些原因而引发的维护活动可以归纳为4种类型，如图10-25所示。

　　（1）校正性维护。把诊断、校正软件错误的过程称之为校正性维护。

　　（2）适应性维护。由于计算机技术的发展，外部设备和其他系统元素经常变更，为适应环境的变更而修改软件的活动称之为适应性维护。

　　（3）完善性维护。在使用系统过程中为满足用户提出的新功能、性能要求而进行的维护。

　　（4）预防性维护。为进一步改进可维护性、可靠性而进行的维护活动。

2. 维护的特点

软件维护的特点表现为：

　　（1）结构化维护和非结构化维护的特性

非结构化维护。用手工方式开发的软件，只有源代码，这种软件的维护是一种非结构化维护。非结构化维护是从读代码开始，由于缺少必要的文档资料，所以很难搞
清软件结构、全程数据结构、系统接口等系统内部的内涵；因为缺少原始资料的可比性，很难估量对源代码所做修改的后果；因为没有测试记录，不能进行回归测
试。

结构化维护。用工程化方法开发的软件有一个完整的软件配置。维护活动是从评价设计文档开始，确定该软件的主要结构性能；估量所要求的变更的影响及可能的结果；确定实施计划和方案；修改原设计；进行复审；开发新的代码；用测试说明书进行回归测试；最后修改软件配置，再次发布该软件的新版本。

　　（2）维护的代价

在过去的几十年中，软件维护费用逐步上升。70年代用于维护软件的费用只占软件总预算的35%～40%，80年代上升为40%～60%，到了90年代则上升为70%～80%。

软件维护的代价包括有形和无形两个部分：有形代价就是上面所提到的那些统计数字；无形代价包括：

l 当看起来合理的有关变更要求不能及时满足时，引起用户的不满；

l 由于维护时的改动，在软件中引入潜在的故障，从而降低了软件的质量；

l 当必须把软件开发工程师调去从事维护工作时，对开发工作造成的影响。

3．维护问题

　　软件维护的绝大多数问题与软件定义和软件开发阶段所采用的设计方法、指导思想、技术手段、开发工具等有直接的关系，同时与维护工作的性质也有一定的关系。

主要问题是：

　　（1）理解别人写的程序通常非常困难，而且困难程度随着软件配置成分的减少而迅速增加。如果仅有源代码而没有相关的文档，问题会更加严重。

　　（2）严格按规范化方法开发的软件系统一般不需要大的维护活动，而需要维护的软件系统却往往因为没有必需的文档或文档残缺不全，使得维护活动进展非常艰难。

　　（3）当需要对软件进行维护时，很难指望熟悉软件系统的原开发人员能全力以赴地亲临现场参与维护活动。

　　（4）绝大多数软件在设计时没有考虑将来的修改。

　　（5）软件维护不是一项吸引人的工作。最出色的、成功的维护也只不过是保证他人开发的系统能正常运行，而且维护别人开发的软件经常受挫，使得维护人员无成就感。


软件维护有以下主要任务：


　　1．维护组织机构

　　对于大型软件系统，建立一个专门的维护组织机构是必需的。即使是对较小的软件系统，也要委派一个专人负责软件维护工作，特别是收集、保存、整理维护活动的文档资料的工作是必须随时要做的。

在维护活动开始之前必须明确维护活动的审批制度。每个维护要求都要通过维护管理员转交给系统管理员去评价。系统管理员对维护申请做出评价后，由主管部门
（人）决定是否进行软件修改。接到审批的维护申请报告后，将维护任务下达给指定的维护人员，并监控维护活动有条不紊地开展。合理的组织机构和精干的维护人
员是保障维护活动顺利实施的基础。

　　2．维护报告

　　任何维护申请都应该按规范化的方式提出。通常要求用户填写维护申请表。表中必须完整地描述每个错误发生的环境，包括：输入数据、输出结果等有关信息。对于
适应性或完善性的维护要求，还应该提出一份修改说明书，提出用户希望的修改。维护申请表交维护组织后，经有关人员认真分析，并根据分析结果制定软件修改报
告，内容应包括：

　 （1）维护要求的性质；

　 （2）维护活动的优先顺序；

　 （3）计算满足维护申请表中提出的软件变更所需要的工作量；

　 （4）预计软件变更后的状况。

　　通过以上说了那么多如果大家对软件的维护有一点初步的认识的话，我就感到非常满足了，我把软件维护问题放在第一位，而不提及软件工作学的其它方面的原因，就是要抛出软件维护这块砖，来在广大星友中引出软件工程学这块无玉，从而引起对软件工作学的足够重视，并应用到自己的项目设计管理中，让自己的作品更加优秀、让“星光” 更加灿烂！

路过，关注。 抢个位置。 顺便顶下：）

写的非常不错；没有多年的经验，是写不出来的；是每个人都值得“仔细阅读与学习”的。

过奖了,呵呵

确实不错，值得学习！

不错,支持

精华文章,值得星友学习!

为了推广软件,和方便用户理解使用,你们最好出一些详细的视频带解说的教程.这样学起来就容易的多.使用者也就多,软件也就推广的快一些.使用的人一多交流的人就多人气就望.希望早一点出来你们的新教程.

我们会努力的；

初学者，先学一些简单实例，“搭建”的原理都一样，简单的会了，复杂的都可以分解成简单的，所以基础是最重要的。

路过，顺便强势插入顶!