1.5 相关软件的失败案例

在详细介绍软件体系结构之前，让我们一起先了解一些软件开发过程的失败案例。这些失败的案例都是没有遵循软件工程或软件体系结构而造成的。

1.5.1 瑞典船的故事

本故事跟软件并没有直接关系，然而它给人们带来的启示，可以帮助软件系统的成功编制。在17世纪上半叶，作为北欧新教势力的代表，瑞典的军事力量达到鼎盛时期。1625年，号称“北方飓风”的瑞典国王古斯塔夫·阿道夫斯二世（GustavsII Adolphus）决心建造一艘史无前例的巨型新战舰——“瓦萨”（VASA）号战舰。“瓦萨”号战舰在当时确实是一艘令人望而生畏的战舰，其舰长70米，载员300人，拥有三层甲板并装有64门重炮，火力强大。然而，当时的设计师并没有设计如此大战舰的经验。设计师不敢违抗国王的命令，只能借鉴原有中型战舰的设计原则设计瓦萨战舰。

经过几年，这艘巨大的战舰终于完工。在斯德哥尔摩的王宮前，“瓦萨”号战舰举行了盛大的下水典礼。一声令下，战舰扬帆起航，乘风前进。然而，巨大的战舰并没有带来胜利的凯旋。船刚驶出船坞不久，摇晃了一下，便向左舷倾斜，海水从炮孔处涌入船舱，战舰迅速翻入水中，几分钟后，这艘雄伟战舰的处女航，也是唯一的一次航行结束了。

国王如何处置船的相关设计师，已经无从考证。现今“瓦萨”号战舰被打捞上来，静静地停放在博物馆，成为人们的一个警示。这次事故的发生并非偶然，究其原因包括设计师经验、国王的催促、船体的比例等因素。由于设计师自身的知识水平有限，采用的技术手段建造如此大船存在一定的困难。国王对该船的急迫，使得该船的工期缩短，没有太多时间进行验证、实验。传统的小船与大船之间的比例关系并非直接成比例放大，采用借鉴设计原则没有问题，但是不能直接照搬。

同样，在软件设计开发过程中，如何合理利用设计师经验、技术是一个重要问题。另外，合理地安排项目进度、进行软件验证等，也是软件开发中的重要组成部分。在软件设计中，需要有良好的原则、模式对软件整体进行规划。软件体系结构可以在理论和实践中对相关的风险进行一行一定的预测，从而降低项目返工的可能性。

1.5.2 集团通信业务系统项目

某公司应约开发一套集团通信业务项目，该集团通信项目要求实现集团内部的短号呼叫、语音信箱、群呼、短消息群发等功能。开发小组包括了多个事业部的人员，担任该项目的项目经理低估了该项目的协调难度以及该项目的时间成本。在项目开发过程中，该项目经理未能建立统一的项目跟踪管理系统，在项目功能的划分上存在着责任不清、接口过多等问题。从而导致了该项目沟通成本过大，各个部门的人员对自身需要完成的任务互相推诿，从而使得开发过程变得极为漫长。在临近验收时，各个子系统的功能仍未开发完成。最终，项目延期了多次，且项目代码的质量较差。可以说本项目的失败是因为没有按照软件工程的要求进行管理造成的。

软件工程与软件体系结构的课程将为项目开发和质量保障提供良好的支持。一个良好的项目经理必然需要了解软件开发规律，对项目过程中可能遇到的风险、项目中成员的知识储备等问题负责，从而降低整个项目的执行风险，最终保障项目的质量并按时交付。时间计划是软件开发中重要的组成部分，如何在项目执行之前对项目所需的时间进行规划，是需要长期软件开发的经验。软件质量是直接导致项目成功与否的关键，软件质量的影响因素包括软件的分析、设计、开发、集成等多个环节。如何从软件设计之初就保障软件的质量正是软件体系结构课程需完成的任务。

1.5.3 邮政信息管理系统的开发

某公司开发一套邮政信息管理系统，该项目需建立一个用于邮政业务的监督和管理的系统，从而提高邮政的服务效率。由于需求方自身对相关监督、管理等功能的要求并不明确，使得该公司在未明确详细需求的情况下，便开始对项目进行开发。实现方由于对行业知识的缺乏及设计人员水平的低下，不能完全理解客户的需求说明，而又没有加以严格的确认，以想当然的方法进行系统设计，导致结的果是推倒重来。另外，该项目的项目经理对整个项目的工作量估算有误，他未综合考虑开发的阶段、人员的生产率、工作的复杂程度、历史经验等多方面因素，而是简单地基于过去的某次成功经验，直接对工时进行了估算。再者，开发计划并不充分，开发计划没有指定里程碑或检查点，也没有规定设计评审期，最终导致该项目无法正常按时交付。

针对上述软件出现的问题，一定程度上可以通过学习软件体系结构进行规避或者克服。例如，需求的变更是每个项目都会出现的现象，如何在软件设计之初为变更的需求提供预留或预期，是软件体系结构中可修改性的要求。

针对工数估算过少的问题，可通过软件体系结构及软件工程的知识，对项目功能自顶向下的分解，以及对关键质量属性的代价分析得出具体的软件代价。同样，开发计划的分析也可通过对各个模块质量属性、功能的完成难度等得出。