关于CMMI - 软件危机？为什么会出现软件危机？

CMMI能力成熟度模型集成评估

您当前所在位置：首页 > 服务项目 > 认证评价咨询 > CMMI能力成熟度模型集成评估

关于CMMI - 软件危机？为什么会出现软件危机？

发布时间： 2019-01-09 16:26:32

　　CMMI(Capability Maturity Model Integration For Software，软件能力成熟度模型集成)是在 CMM(Capability Maturity Model For Software，软件能力成熟度模型)的基础上发展而来的。CMMI是由美国卡耐基梅隆大学软件工程研究所(Software Engineering Institute，SEI)组织全世界的软件过程改进和软件开发管理方面的专家历时4年而开发出来，并在全世界推广实施的一种软件能力成熟度评估标准，主要用于指导软件开发过程的改进和进行软件开发能力的评估。

　　软件危机

　　在计算机系统发展的早期时代（二十世纪六十年代中期以前），通用硬件在这一时期非常普遍，但是软件却是为了每一个具体的应用而专门编写的，那个时期的软件一般都是规模比较小的一个程序，编写代码的程序员和使用者往往是同一个（或同一组）人。那么在这种个体化的软件环境下，软件设计通常是在程序员的头脑中进行的一个隐含的过程，只留下了程序，除了程序清单之外，没有其他任何的文档资料（需求分析、软件说明书等）保存下来。

　　二十世纪的六十年代中期到七十年代中期是计算机系统发展的第二代时期，这个时期的一个重要特征是出现了“软件作坊”，当时的微软就是这种软件生产方式的一个代表。此时，尽管软件的生产是作坊式生产，但还是生产了一些很有代表性的产品，使得产品软件的使用广泛起来。然而，“软件作坊”仍然沿用早期形成的个体化软件开发方法。随着计算机应用的日益普及，软件数量急剧膨胀。在程序运行时发现的错误必须设法改正；用户有了新的需求时必须相应地修改程序；硬件或操作系统更新时，通常需要修改程序以适应新的环境。上述软件维护工作，以令人吃惊的比例耗费着资源。甚至许多程序的个体化特性使它们最终成为不可维护的。“软件危机”就这样开始出现了！

　　为什么会出现“软件危机”？

　　软件不同于一般程序，它是由许多实现各自功能的程序组成的。它的一个显著特点是规模庞大。例如，美国四代宇宙飞船的软件规模呈指数增长，二十世纪七十年代末穿梭号宇宙飞船的软件包含4000万行目标代码。假设一个人一年可以开发出一个一万行的程序，为了开发一个4000万行的软件，是否集中4000人的力量一年就可以完成呢？绝对做不到！因为代码长度增加了4000倍，程序复杂程度的增加远远超过4000倍。而且如何保证每个人完成的工作合在一起确实能构成一个高质量的大型软件系统，更是一个极端复杂困难的问题，不仅涉及许多技术问题，例如分析方法、设计方法、形式说明方法、版本控制等，更重要的是必须进行严格而科学的管理。

　　软件本身独有的特点确实给开发和维护带来一些客观困难，但是人们在开发和使用计算机系统的长期实践中，也确实积累和总结出了许多成功的经验。如果坚持不懈地使用经过实践考验证明是正确的方法，许多困难是完全可以克服的，过去也确实有一些成功的范例。但是，目前相当多的软件专业人员对软件开发和维护还有不少错误观念。在实践过程中或多或少地采用了错误的方法和技术，这可能是使软件问题发展成软件危机的一个主要原因。

　　与软件开发和维护有关的许多错误认识的形成，可以归因于在计算机系统发展中，早期软件开发的个体化特点。错误认识主要表现为忽视软件需求分析的重要性，认为软件开发就是写程序，并设法使之运行，轻视软件维护等。

　　事实上，对用户要求没有完整准确的认识就匆忙着手编写程序是许多软件开发工程失败的主要原因之一。只有用户才真正了解他们自己的需要，但是许多用户在开始时并不能准确具体地叙述他们的需要，软件开发人员需要做大量深入细致的调查研究工作，反复多次地和用户交流信息，才能真正全面、准确、具体地了解用户的要求。对问题和目标的正确认识是解决任何问题的前提和出发点。

　　一个软件从定义、开发、使用和维护，直到最终被废弃，要经历一个漫长的时期。通常把软件经历的这个过程称为生命周期。软件开发最初的工作应是问题定义，然后要进行可行性研究，决定该问题是否存在一个可行的解决办法；接下来应该进行需求分析，也就是深入具体地了解用户的要求，在所要开发的系统（不妨称之为目标系统）必须做什么这个问题上和用户取得完全一致的看法。经过上述软件定义时期的准备工作才能进入开发时期，而在开发时期首先需要对软件进行设计（通常又分为总体设计和详细设计两个阶段），然后才能进入编写程序的阶段，程序编写完之后还必须经过大量的测试工作（所需的工作量通常占软件开发全部工作量的40%~50%）才能最终交付使用。所以，编写程序只是软件开发过程中的一个阶段，而且在典型的软件开发工程中，编写程序所需的工作量只占软件开发全部工作量的10%~20%。

　　另一方面还必须认识到程序只是完整的软件产品的一个组成部分，在上述软件生命周期的每个阶段都要得出最终产品的一个或几个组成部分（这些组成部分通常以文档资料的形式存在）。软件专家曾经指出：“软件是程序以及开发、使用和维护程序需要的所有文档。”这也就是对软件的定义。所以，一个软件产品必须由一个完整的配置组成，应该清除只重视程序而忽视软件配置其余成分的错误观念。

　　做好软件定义时期的工作，是降低软件成本提高软件质量的关键。如果软件开发人员在定义时没有正确全面地理解用户需求，直到测试阶段或软件交付使用后才发现“已完成的”软件不完全符合用户的需要，这时再修改就为时已晚了。

　　严重的问题是，在软件开发的不同阶段进行修改需要付出的代价是很不相同的，在早期引入变动，涉及的面较小，因而代价也比较低：而在开发中期软件配置的许多成分已经完成，引入一个变动要对所有已完成的配置成分都做相应的修改，不仅工作量大，而且逻辑上也更复杂，因此付出的代价剧增。根据美国一些软件公司统计资料，在后期引入一个变动比在早期进入相同变动所需付出的代价高2~3个数量级。

　　通过上面的论述不难认识到，轻视维护是一个最大的错误。许多软件产品的使用寿命长达10年甚至20年，在这样漫长的时期中不仅必须改正使用过程中发现的每一个潜伏的错误，而且当环境变化时（例如硬件或系统软件更新换代）还必须相应地修改软件以适应新的环境，特别是必须经常改进或扩充原来的软件以满足用户不断变化的需要。所有这些改动都属于维护工作，而且是在软件已经完成之后进行的，因此是极端艰巨复杂的工作，需要花费很大代价。统计数据表明，实际上用于软件维护的费用占软件总费用的55%~70%。

返回上一级