••软件工程••第1章软件危机与开发过程第1章软件危机与开发过程软件产业发展至今已有数十个年头，其间经历了不断的技术创新和开发过程的改进，使得该项产业愈加重要，并成为日常生活中其他产业的重要运作核心。不论是金融、航空、制造、医疗，还是运输等行业，都实现了一定程度的信息化，并使用软件系统或产品来协助日常工作的运行。对于许多组织而言，由于软件错误而造成的计算机死机或系统崩溃，经常会造成难以弥补的损失。遗憾的是，这样的例子处处可见，并且不曾间断。软件过程对于组织的重要性，就如同算法对子程序运行一般。合适的算法可以提高运行的效率，不合适的算法则不仅无法提高效率，而且会浪费组织资源的使用率。软件开发过程牵涉到的是更为复杂的人、事、物，而算法则是纯粹的机器代码执行。本章将介绍构成软件过程(SoftwareProcess)的基本活动，以及几种在软件与系统产业界常用的软件过程。软件开发过程主要是描述开发软件系统所牵涉到的相关活动，以及如何循序渐进地执行这些活动。不同的系统、组织及开发，其管理工具所采用的流程都有可能不同。例如：有些系统适合采用按部就班的方式，从分析、设计、实现、测试到移交逐步地进行；有些系统则适合采用反复循环的方式，不断地重复执行分析、设计、实现、测试等活动。本章共分3节：第1节分析软件危机与造成软件危机的原因，第2节介绍基本的软件开发活动，第3节探讨常见的软件开发模型。本章的学习重点如下：软件危机与造成软件危机的原因软件开发过程的基本概念瀑布模型统一过程模型极限编程模型1.1软件危机著名的研究机构StandishGroup曾在1995年针对全美国8000个软件项目做了一项调查，调查中发现超过30%的项目被取消，并且项目的预算平均超出189%。这些数字相当惊人，它如实地反映出那个时期软件项目的现况及问题。造成此种情况的主要原因经归纳分析有：1)软件公司总是在不合理的期限(UnrealisticDeadline)压力下进行开发；2)客户在项目结束前要求增加新功能，或是给予不明确的需求(VagueRequirements)；3)软件本身非常复杂(ComplexStructure)；4)项目开发过程中具有许多不确定因素(NumerousUncertainties)。早期软件项目发生严重问题的情况比比皆是。例如[HRPL1999]，1982年，美国银行(BankofAmerica)想要进入信托领域，因此花了18个月深入地研究及分析信托软件系统，最后准备以2000万美元的预算开发该系统，开发时间长达9个月，预计在1984年12月底前完成该系统。然而此系统直到1987年3月都未完成，并且已耗费6000万美元，同时还失去了原先所规划的6亿美元的信托生意。最后，此系统因为不稳定而不得不放弃，只能将其信托账户转移出去。类似上述的案例数不胜数。其他的如1996年发生的亚利安五号原型爆炸及波音DeltaIII火箭爆炸等事件，都是源于软件问题。而软件之所以会造成这些严重的问题，可以从FredrickBrooks最经典的一篇论文[Bro1987]NoSilverBullet中得到部分解答。FredrickBrooks在该文中认为，软件与生俱来的四种特性(EssentialDifficulty)是造成直至今日仍然无法找到“银弹”的原因，同时也是造成软件危机的主要原因：复杂性(Complexity)：软件与现实生活中接触到的任何事物相比，有一个很大的不同点，就是软件与生俱来的复杂性。当开发软件系统时，程序设计人员动辄必须编写小至数百行程序代码的软件组件、大至数万行程序代码的系统关键模块，因此，其复杂程度往往随着程序的大小及软件组件的个数，以非线性的方式、甚至是级数的方式递增。这往往导致一同开发的项目成员之间沟通困难程度提高、成本花费超出预算、交付时间延迟、系统进入非预期中的状态等而死机等，造成无法弥补的损失。易变性(Changeability)：软件的易变性，更是所有软件设计师的梦魇。我们很少听说一栋大楼刚落成，屋主就要根据自己的意愿再大兴土木来变动外观或设计，因为众所周知，这样的调整必然要付出相当大的代价。而软件正好相反，软件的变动，相对于房子、车子、手机、电视等硬件的变动来说，更加容易且快速，因此，通常为了满足客户的需求，成功的软件系统从开发到完成、从产品交付到运营维护，随时都有可能要变更。隐藏性(Invisibility)：软件本身是看不到、摸不着的。人们总是对复杂或隐藏的事物以几何或抽象的方式来具体描绘，以最大程度地帮助彼此进行沟通及思考。例如：对于房子的设计，设计师会借助设计图和模型来与客户进行沟通讨论；对于旅游行程景点间的复杂路径规划，可以通过地图来帮助我们理清方向并交换意见。而软件系统同样也可以