软件危机的表现、产生原因以及可能的解决方案

计科4班 常亦炫 201140910401

一、软件危机概括 落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。

二、软件危机的表现

（1）软件开发成本难以控制、软件开发进度难以预测。 费用超支、进度拖延的情况屡屡发生。有时为了赶进度或压成本不得不采取一些权宜之计，这样又往往严重损害了软件产品的质量。

（2）、软件的可靠性差，产品质量无法保证。 软件是逻辑产品，质量问题很难以统一的标准度量，因而造成质量控制困难。尽管耗费了大量的人力物力，而系统的正确性却越来越难以保证，出错率大大增加。

（3）、生产出来的软件难以维护。 很多程序缺乏相应的文档资料，程序中的错误难以定位，难以改正，有时改正了已有的错误又引入新的错误。随着软件的社会拥有量越来越大，维护占用了大量人力、物力和财力。

（4）、软件成本在计算机系统总成本中所占的比例居高不下，且逐年上升。 由于微电子学技术的进步和硬件生产自动化程度不断提高，硬件成本逐年下降，性能和产量迅速提高。然而软件开发需要大量人力，软件成本随着软件规模和数量的剧增而持续上升。

（5）、软件开发生产率提高的速度远远满足不了计算机应用

迅速普及深入的需要。软件产品供不应求的状况使得人类不能充分利用现代计算机硬件所能提供的巨大潜力。

（6）、用户对产品功能难以满足。 开发人员和用户之间很难沟通、矛盾很难统一。往往是软件开发人员不能真正了解用户的需求，而用户又不了解计算机求解问题的模式和能力，双方无法用共同熟悉的语言进行交流和描述。

二、软件危机产生的原因

（1）、软件本身的特点 软件不同于硬件，它是计算机系统中的逻辑部件；软件样品即是产品，试制过程也就是生产过程；软件不会因使用时间过长而“老化”或“用坏”；软件具有可运行的行为特性，在写出程序代码并在计算机上试运行之前，软件开发过程的进展情况较难衡量，软件质量也较难评价，因此管理和控制软件开发过程十分困难；软件质量不是根据大量制造的相同实体的质量来度量，而是与每一个组成部分的不同实体的质量紧密相关，因此，在运行时所出现的软件错误几乎都是在开发时期就存在而一直未被发现的，改正这类错误通常意味着改正或修改原来的设计，这就在客观上使得软件维护远比硬件维护困难；软件是一种信息产品，具有可延展性，属于柔性生产，与通用性强的硬件相比，软件更具有多样化的特点，更加接近人们的应用问题。

（2）、软件开发人员的弱点

其一，软件产品是人的思维结果，因此软件生产水平最终在相

当程度上取决

于软件人员的教育、训练和经验的积累；

其二，对于大型软件往往需要许多人合作开发，甚至要求软件开发人员深入应用领域的问题研究，这样就需要在用户与软件人员之间以及软件开发人员之间相互通讯，在此过程中难免发生理解的差异，从而导致后续错误的设计或实现，而要消除这些误解和错误往往需要付出巨大的代价；

其三，由于计算机技术和应用发展迅速，知识更新周期加快，软件开发人员经常处在变化之中，不仅需要适应硬件更新的变化，而且还要涉及日益扩大的应用领域问题研究；软件开发人员所进行的每一项软件开发几乎都必须调整自身的知识结构以适应新的问题求解的需要，而这种调整是人所固有的学习行为，难以用工具来代替。软件生产的这种知识密集和人力密集的特点是造成软件危机的根源所在。

（3）、用户需求不明确 在软件开发出来之前，用户自己也不清楚软件开发的具体需求； 用户对软件开发需求的描述不精确，可能有遗漏、有二义性、甚至有错误； 在软件开发过程中，用户还提出修改软件开发功能、界面、支撑环境等方面的要求； 软件开发人员对用户需求的理解与用户本来愿望有差异。

（4）、缺乏正确的理论指导 缺乏有力的方法学和工具方面的支持。由于软件开发不同于大多数其他工业产品，其开发过程是复杂的逻辑思维过程，其产品极大程度地依赖于开发人员高度的

智力投入。由于过分地依靠程序设计人员在软件开发过程中的技巧和创造性，加剧软件开发产品的个性化，也是发生软件开发危机的一个重要原因。

三、软件危机可能的解决方案

（1）、努力开发容易看懂、容易使用、容易修改且容易扩充的程序。

（2）、将软件生命周期各阶段使用的软件工具有机地集合成为一个整体，形成能够连续支持软件开发与维护全过程的集成化软件支援环境，以期从管理和技术两方面解决软件危机问题。

（3）、努力建立完备的软件工业化生产体系，形成强大的软件生产能力。加快软件标准化与可重用性建设的步伐，以期在避免重复劳动，缓解软件危机。

（4）、要对程序设计方法、程序的正确性和软件的可靠性等问题进行系列的研究并且也需要对软件的编制、测试、维护和管理的方法进行研究。

（5）、加强研究软件生产的客观规律性，建立与系统化软件生产有关的概念、原则、方法、技术和工具，指导和支持软件系统的生产活动，以期达到降低软件生产成本、改进软件产品质量、提高软件生产率水平的目标。尝试建立软件生命周期的模型，发展软件开发与维护阶段适用的技术和方法，并应用于软件工程实践。

第二篇：软件维护小论文 软件工程

《软件工程小论文》

软件的易维护性差是软件维护工作量和费用激增的直接原因，因此在软件工程的各个阶段都要保证软件具有较高可维护性，从而降低软件维护成本，这是软件工程的重要目标之一。国外的统计数字表明，完善性维护占全部维护活动的50%～66%，改正性维护占17%～21%，适应性维护占18%～25%，其他维护活动只占4%左右，本文对软件维护做了比较详细的介绍。

1 软件维护的概念

1.1软件维护的定义

在软件运行／维护阶段对软件产品进行的修改就是所谓的维护。

维护的类型有四种：

1．改正性维护：在软件交付使用后，因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就叫做改正性维护。

2．适应性维护：在使用过程中，外部环境（新的硬、软件配置），数据环境（数据库、

数据格式、数据输入/输出方式、数据存储介质）可能发生变化。为使软件适应这种变化，而去修改软件的过程就叫做适应性维护。

3．完善性维护：在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。

为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下进行的维护活动叫做完善性维护。

4．预防性维护：预防性维护是为了提高软件的可维护性、可靠性等，为以后进一步改

进软件打下良好基础。预防性维护定义为：采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试。

在整个软件维护阶段所花费的全部工作量中，完善性维护占了几乎一半的工作量。软件

维护活动所花费的工作占整个生存期工作量的70%以上，这是由于在漫长的软件运行过程中需要不断对软件进行修改，以改正新发现的错误、适应新的环境和用户新的要求，这些修改需要花费很多精力和时间，而且有时会引入新的错误。

三类维护占 维护在软件生存期

总维护比例 所占比例

1.2影响维护工作量的因素

在软件的维护过程中，需要花费大量的工作量，从而直接影响了软件维护的成本。应

当考虑有哪些因素影响软件维护的工作量，相应应该采取什么维护策略，才能有效地维护软件并控制维护的成本。影响因素如下：

系统大小：系统越大，理解掌握起来越困难。系统越大，所执行功能越复杂。因而需

要更多的维护工作量。

程序设计语言：使用强功能的程序设计语言可以控制程序的规模。语言的功能越强，

生成程序的模块化和结构化程度越高，所需的指令数就越少，程序的可读性越好。

系统年龄：老系统随着不断的修改，结构越来越乱；维护人员经常更换，程序又变得越

来越难于理解。许多老系统在当初并未按照软件工程的要求进行开发，因而没有文档，或文档太少。在长期的维护过程中文档在许多地方与程序实现变得不一致，在维护时就会遇到很大困难。

数据库技术的应用：使用数据库，可以简单而有效地管理和存储用户程序中的数据，

还可以减少生成用户报表应用软件的维护工作量。

先进的软件开发技术：在软件开发时，若使用能使软件结构比较稳定的分析与设计技术，及程序设计技术，如面向对象技术、复用技术等，可减少大量的工作量。

1.3软件维护的策略

1．改正性维护：通常要生成100％可靠的软件并不一定合算，成本太高。但通过使用

新技术，可大大减少进行改正性维护的需要。这些技术包括：数据库管理系统、软件开发环境、程序自动生成系统、较高级(第四代)的语言。以及新的开发方法、软件复用、防错程序设计及周期性维护审查等。

2．适应性维护：这一类维护不可避免，但可以控制。

(1) 在配置管理时，把硬件、操作系统和其它相关环境因素的可能变化考虑在内。

(2) 把与硬件、操作系统，以及其它外围设备有关的程序归到特定的程序模块中。

(3) 使用内部程序列表、外部文件，以及处理的例行程序包，可为维护时修改程序提供方便。

3．完善性维护：利用前两类维护中列举的方法，也可以减少这一类维护。特别是数据

库管理系统、程序生成器、应用软件包，可减少维护工作量。此外，建立软件系统的原型，把它在实际系统开发之前提供给用户。用户通过研究原型，进一步完善他们的功能要求，就可以减少以后完善性维护的需要。

1.4维护成本

有形的软件维护成本是花费了多少钱，无形的维护成本有更大的影响：一些合理的修复或修改请求不能及时安排，使得客户不满意；变更的结果引入新的故障，使得软件整体质量下降；把软件人员抽调到维护工作中，干扰了软件开发工作。

软件维护的代价是降低了生产率，在做老程序的维护时非常明显。例如，开发每一行源代码耗资25美元，维护每一行源代码需要耗资1000美元。维护工作量包括生产性活动（如分析和评价、设计修改和实现）和“轮转”活动（如力图理解代码在做什么、试图判明数据结构、接口特性、性能界限等）。

维护工作量的模型：

其中M是维护中消耗的总工作量，p是上面描述的生产性工作量，K是一个经验常数，c

是因缺乏好的设计和文档而导致复杂性的度量，d是对软件熟悉程度的度量。

模型指明，如果使用了不好的软件开发方法（未按软件工程要求做），原来参加开发的人员或小组不能参加维护，则工作量（及成本）将按指数级增加。

二 软件维护活动

为了有效地进行软件维护，应事先就开始做组织工作。

A．首先建立维护的机构

B．申明提出维护申请报告的过程及评价的过程

C．为每一个维护申请规定标准的处理步骤

D．建立维护活动的登记制度以及规定评价和评审的标准。

2．1 维护机构

除了较大的软件开发公司外，通常在软件维护工作方面，并不保持一个正式的组织机构。

虽然不要求建立一个正式的维护机构，但是在开发部门确立一个非正式的维护机构则是非常必要的。

维护申请提交给维护管理员，他把申请交给某个系统监督员去评价。一旦做出评价，由修改负责人确定如何进行修改，在修改程序的过程中，由配置管理员严格把关，控制修改的范围，对软件配置进行审计。在维护之前，就把责任明确下来，可以减少维护过程中的混乱。

2．2软件维护申请报告

维护申请报告或称软件问题报告，由申请维护的用户填写。用户必须完整地说明产生错误的情况，包括输入数据、错误清单以及其它有关材料。如果申请的是适应性维护或完善性维护，用户必须提出一份修改说明书，列出所有希望的修改。维护申请报告将由维护管理员和系统监督员来研究处理。他们应相应地做出软件修改报告，指明：所需修改变动的性质；申请修改的优先级；为满足某个维护申请报告，所需的工作量；预计修改后的状况.

软件修改报告应提交修改负责人，经批准后才能开始进一步安排维护工作。

尽管维护申请的类型不同，但都要进行同样的技术工作：修改软件需求说明；修改软件设计；设计评审；对源程序做必要的修改；单元测试；集成测试( 回归测试)；确认测试；软件配置评审等。

在每次软件维护任务完成后进行情况评审，对以下问题做一总结：

(1) 在目前情况下，设计、编码、测试中的哪一方面可以改进?

(2) 哪些维护资源应该有但没有?

(3) 工作中主要的或次要的障碍是什么?

(4) 从维护申请的类型来看是否应当有预防性维护?

情况评审对将来的维护工作如何进行会产生重要的影响。

2．3维护档案记录

维护档案记录包括：程序名称、源程序语句条数、机器代码指令条数、所用的程序设计

语言、程序安装的日期、程序安装后的运行次数、与程序安装后运行次数有关的处理故障次数、程序改变的层次及名称、修改程序增加的源程序语句条数、修改程序减少的源程序语句条数、每次修改所付出的“人时”数、修改程序的日期、软件维护人员的姓名、维护申请报告的名称、维护类型、维护开始时间和维护结束时间、花费在维护上的累计“人时”数、维护工作的净收益等。

2．4维护评价

评价维护活动比较困难，因为缺乏可靠的数据。如果维护的档案记录做得比较好，可以得出一些维护“性能”方面的度量值：每次程序运行时的平均出错次数；花费在每类维护上的总“人时”数；每个程序、每种语言、每种维护类型的程序平均修改次数；因为维护，增加或删除每个源程序语句所花费的平均“人时”数；用于每种语言的平均“人时”数；维护申请报告的平均处理时间；各类维护申请的百分比。

据此可对开发技术、语言选择、维护工作计划、资源分配、以及其它许多方面做出判定。

三 程序修改的步骤及修改的副作用

3.1分析和理解程序

A． 理解程序的功能和目标；

B． 掌握程序的结构信息，即从程序中细分出若干结构成分。如程序系统结构、 控制结构、数据结构和输入／输出结构等；

C． 了解数据流信息，即涉及到的数据来源何处，在哪里被使用

D． 了解控制流信息，即执行每条路径的结果；

E． 理解程序的操作(使用)要求。

3.2修改程序

1. 设计程序的修改计划。

程序的修改计划要考虑人员和资源的安排。小的修改可以不需要详细的计划，而对于需要耗时数月的修改，就需要计划立案。

2. 修改代码，以适应变化。

3. 修改程序的副作用。

所谓副作用是指因修改软件而造成的错误或其它不希望发生的情况。副作用有三种：修改代码的副作用、修改数据的副作用、文档的副作用。

3.3重新验证程序

在将修改后的程序提交用户之前，需要进行充分的确认和测试，以保证整个修改后程序的正确性。

静态确认：修改软件，伴随着引起新的错误的危险。为了能够做出正确的判断，验证修改后的程序至少需要两个人参加。要检查：

计算机确认：在进行了以上确认的基础上，用计算机对修改程序进行确认测试：

(1) 确认测试顺序：先对修改部分进行测试，然后隔离修改部分，测试程序的未修改部

分，最后再把它们集成起来进行测试。这种测试称为回归测试。

(2) 准备标准的测试用例。

(3) 充分利用软件工具帮助重新验证过程。

(4) 在重新确认过程中，需邀请用户参加。

维护后的验收：在交付新软件之前，维护主管部门要检验：

(1) 全部文档是否完备，并已更新；

(2) 所有测试用例和测试结果已经正确记载；

(3) 记录软件配置所有副本的工作已经完成；

(4) 维护工序和责任已经确定。

四 软件可维护性

4．1 软件可维护性的定义

软件可维护性是指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度。可维护性、可使用性、可靠性是衡量软件质量的主要质量特性。软件的可维护性是软件开发阶段各个时期的关键目标。

目前广泛使用的是用如下的七个特性来衡量程序的可维护性：可理解性、可使用性、可测试性、可移植性、可修改性、效率、可靠性。而且对于不同类型的维护，这七种特性的侧重点也不相同。

在各类维护中的侧重点 ：

五 提高可维护性的方法

提高可维护性的方法很多，包括如下：建立明确的软件质量目标和优先级；使用提高软件质量的技术和工具；进行明确的质量保证审查；选择可维护的程序设计语言；改进程序的文档。

六 小结

通过对《软件工程》和一些资料的学习，我受益匪浅，对软件开发有了一个系统的了解，对一些概念也有了一定了解，虽然这只是一些理论，可能在实际工作中很少用到，但理论知识用于指导实践，亲身体验才能真正领悟软件工程的妙用。我感觉到学习这门课需要花费大量的时间来思考，从而换取宝贵的经验。学习软件工程的过程是枯燥的，但我认为若能把这些枯燥的理论学好，在将来的学习和工作中一定会大有益处。