(新)软件系统开发与软件工程方法_

1960
1970
1980
1990
2000
一、软件危机 2、软件危机
1）案例思考1——FAA的失败项目
20世纪80年代中期，更换空中交通控制系统已成为美国联邦航空管理局（FAA） 非常优先的任务。1989年IBM公司获得更换该系统的合同，截止期为2001年，预 计投入25亿美元。由于面临着极苛刻的需求，该软件项目是已进行的最复杂的项 目之一。例如，交通控制系统必须具备全局完整性并且每周7天，每天24小时不 能停止工作，甚至在升级时或正常维护时，也不允许有停顿时间。任何错误的数 据都会引起重大伤亡，任何停机均会导致世界范围的出行延误或潜在的危险。该 系统的反应时间不能超过2-3秒。此外，该系统设计时必须考虑到允许私人飞机 驾驶员继续使用旧设备，并要求软件能在未来移植到更新的硬件设备上。当IBM 获得该合同后，该系统的主要花费为软件开发，用于硬件的投入仅为8万美元。 1993 年，负责该项目的 IBM子公司 ——IBM联邦系统公司被IBM卖给了Loral公 司。到1994年，该系统已花费了23亿美元，但尚未提交系统的任何程序段，而此 时估算整个系统的花费将增至50亿美元。1994年底，FAA不得不承认该项目失败 并进行调查。作为调查的结果，FAA取消或修改了系统的四个主要部分。面临当 前空中控制系统存在的隐患，FAA不得不订购了一套作为权宜之计的系统，由另 一家公司开发。
一、软件危机 2、软件危机
2）软件神话
[1]管理神话 神话：通过把软件项目外包给实现强大的软件开发公司可以保证软件 的成功。
现实：再专业的软件公司，不了解客户的需求和业务流程，也不可能 顺利完成软件开发项目。
改正一个问题需付出的代价
2000 改正 一个 1000 问题 的估 计费 200 用 (美元) 20 需 求 分 析 结 构 设 计 详 编集 系 现 细 码成 统 场 设 测 测 计 试 试 5.0 2.5 改正 一个 问题 估计 的工 作量
答案只有一个：复杂性。
例:Windows95有Fra Baidu bibliotek000万行代码
Windows2000有5000万行代码
Exchange2000和 Windows2000开发人员结构
Exchange2000 Windows2000 项目经理 开发人员 测试人员 25人 140人 350人 约250人 约1700人 约3200人
第七章 软件系统开发与软件工程方法
一、软件危机 二、软件工程
一、软件危机 1、软件开发的发展历程
早期 段 第二阶段 第三阶段 第四阶段
面向批处理
多用户 分布式系统 强大的桌面系统 有限的分布 实时 嵌入“智能” 面向对象技术 自定义软件 数据库 低成本硬件 专家系统 开发者=使用者 软件产品 人工神经网络 并行计算 网络计算机
障碍是什么：难以沟通与交流。可能因误解产生错误的 需求描述。
一、软件危机 2、软件危机
软件项目为什么会失败？
软件项目失败的核心问题在哪里？
软件要解决的问题本身是复杂的
开发人员一般不是该问题领域的 专家 软件规模要求多人参与，而不同 专业领域的人的交流是困难的 软件规模使得既要理解系统整体 结构又要把握细节比较困难。
神话：软件需求是经常变更的，而这些变更可以容易的被满足，因为 软件是灵活的。 现实：软件需求确实是容易变更的，但变更的代价将随软件开发的进 度不同而有很大的差异。如果重新项目早期的问题定义，需求变化则 很容易被调节，而项目后期需求变更的代价可能是致命的。
一、软件危机 2、软件危机
2）软件神话
1995年美国的商业软件失败统计：
成功 失败 延期
一、软件危机 2、软件危机
案例思考2——遗传信息库建设 在正在建设的遗传信息库如，假设你要开发一个管理软 件。你并不是一个生物遗传方面的专家，甚至对此方面 的知识一窍不通，你该如何入手？要使该项目成功，你 认为应该有哪些保障条件？ 你的问题是什么：对遗传信息的管理 需要什么条件：了解遗传信息的表示和管理流程 如何实现：与遗传领域的专家交流。
0.5
0.05 (人天)
一、软件危机 2、软件危机
2）软件神话
[2]客户神话 神话：有了目标系统的一般性描述就可以写程序了，细节可以逐步完 善。
现实：糟糕的系统定义是项目失败的主要原因。关于问题域、功能、 行为、性能、接口、设计约束以及确认标准的形式化的、详细的描述 是必要的，这些内容只能通过客户与开发者之间的交流才能确定。
一、软件危机 2、软件危机
2）软件神话
[1]管理神话 神话：有关软件开发的理论和方法已经很丰富，有很多可用的标准与 规范，因而可以保证软件开发的顺利进行。
现实：理论与方法在大多数实践中并没有得到真正的应用。使用者并 没有对这些理论与方法建立正确的认识。
神话：已经有很多强大的开发工具和先进的计算机硬件，这些可以保 证软件开发的质量与效率。 现实：这些工具并没有得到合理的应用。 神话：如果我们落后于进度，可以通过增加人手来赶上。 现实：向一个已经延迟的项目增加人手，只会使延迟的项目更加落 后——除非项目中不需要交流。生一个孩子10个月，无论有多少人。
在《人月神话》一书中，Brooks将过去30年大型软件项目的开发比 喻为史前陷入沥青坑的巨兽。恐龙、猛犸、剑齿虎等动物在焦油中挣 扎，然而挣扎得越激烈，就陷得越快，最终都沉到了坑底。过去的大 型软件项目中，大多数开发出了可运行的系统 ——不过只有极少数满 足了目标、进度和预算的要求。表面上看起来没有任何一个单独的问 题会导致困难，每个问题都能获得解决，但这些问题纠缠和积累在一 起时，团队的行动就越来越慢，并且很难再看清问题的本质。
你认为该项目的失败反映了什么问题？失败的主要原因可能是什么？ FAA为什么选择取消和修改的方式而不是增加资源和生产力的方式？
FAA对此项目调查总结出的原因为以下几条：
•FAA并没有明确掌握某些系统功能的需求。 •制定了过于急躁的开发和实现计划（包括费用 与进度的估计） •在给定的软件复杂度下，没有考虑到开发商的 生产力，尤其是早期阶段需要投入的资源。