IT项目启示录——来自泰坦尼克号的教训（第四篇）（转）

泰坦尼克的设计者有许多设计选择并遵循一项战略就是要集所有最新的和超前安全技术提供最高等级的安全性。然而，由于他们迫于商业压力，泰坦尼克的设计者开始在安全装置上做出妥协。这些压力明显地来自企图为最终乘客（头等舱）创造一流体验的白星公司老板Bruceismay。例如：四个防水壁吃水线以上部分只有10英尺而并没有到达顶甲板，目的是腾出一个200尺宽敞的舞厅。（参看第三部分）。

到了测试阶段的计划开始制订时，泰坦尼克是不可征服的观念一直存在于白星工作人员当中。事实上，这个观念也作为泰坦尼克市场推广的一部分被积极地使用。由于泰坦尼克即将完成，在交付白星公司之前，harland和wolff（造船专家）为泰坦尼克制订了测试计划。双方都必须确定泰坦尼克满足合同规定的条件和需求。测验给造船专家一个机会，可以做出任何必要的调整和避免财政罚款的风险或遭受送回船厂的更坏命运。

同样，IT解决方案也应该总是满足合同义务，这些合同义务的满足必须依赖于项目早期建立的服务等级目标。商业实际根据公司能够容忍的底线为基础确定解决方案的价格和服务水准要求（参看第二部分）。测试应该能够评估IT解决方案是怎样良好地满足服务水平情况以及识别其中任何缺陷。

制订计划一般来说包含测试计划的略述。例如，泰坦尼克毫无疑问进行了适航能力的操作测试，稳定性的检查、重量和负载细节等条目的仔细评定。其中有一项测试是用一个简单的倾斜试验，检查船的重量和重心的倾斜测试。它还提供一项统计检查。其他的测试包括迎水面码头边试验，主要目的是对主机和辅助机械装置的初步测试。匀速试验通常对满足合同条款来说是必需的，即在斜度和总载重量的特定条件下，完成对某一速度的调整。

同样,IT项目必须为IT解决方案制订整体计划测试，并且所做的测试必须对功能和无功能需求都应该有效。然而，重点将应放在具有难以置信地重要等级的无功能需求上，因为他们确定一个系统可使用的特征。测试必须是"动态"的并建立在较为早期的"静态"测试或"走查"（walkthoughs）之上。

许多IT项目虽然在单位级别上功能测试的进行地很有效，但是却没能在宏观上进行测试。这种情况的发生在一定程度上是由于模拟服务交付环境的感知成本是唯一的，导致只有局部测试不断被完成，而整体测试却没有进行。这种做法降低了成功发布的置信度。许多公司事实上开始启动IT解决方案的时候，报着要为用户或客户解决一切问题的初衷。这是一种极端危险的方法，有可能是商业陷入非常危险的严重状态。

在泰坦尼克的故事中，当泰坦尼克计划制订和检验阶段进行妥协时，同型船奥林匹克在泰坦尼克项目进行中扮演了一个及其重要的角色。泰坦尼克是1911年6月投入使用的奥林匹克号的一个翻版。白星公司认为奥林匹克的航行记录足够用于几乎相同的同型船，泰坦尼克可以不经过多方面的海上试航就可以直接开始服务。航行记录把泰坦尼克已经完全准备好了的观念印入了船主们头脑中。然而,两艘船可以进行用了进行比较的只有机械构造，而没有着眼于船员（人）或方法（过程）的准备。

过于依赖先前类似的实现方法、对事件风险和次要事件估计不足会使一个即将发生的技术风险启动，种种情况的发生都会导致IT项目可能出现相似的错误。 根据对测试目标和整体战略评估，确定所需的测试，测试目的。

以上述方法为基础进行的大量测试应该包括受力状态,性能,逆行,可靠性和运行测试。这需要为每一个测试目标分别制订测试案例：什么将被测试、它是如何被测试的、需要什么样数据、期望结果和结果。最重要的是,这些都是在测试解决方案可用性。另外，制订计划应该确定测试是在什么环境下，由谁怎样执行的，才能确保其客观性。例如：开发团体永远不应该自己测试自己的成果；测试工作应该具有自己独立的团体。

奥林匹克的航行记录并不完美的，有发生了一些严重事件。第一件事就是，奥林匹克号被12个托船牵引到北河，调度到第59号码头下锚。牵引船Hallenbeck号位于远洋班轮的船尾，那时奥林匹克的右舷螺旋桨突然倒转将Hallenbeck号卷了进去，切断它的船尾、舵和转轮舱道口。

第二件事发生在奥林匹克号第六次出航开始阶段即将驶出索伦特海峡时。当时奥林匹克号以15节的速度与皇家海军HMSHawke号巡洋舰在一个狭小航道相隔200码并行行驶，突然Hawke号强行朝着奥林匹克转变方向，与奥林匹克号正面发生碰撞并穿透了奥林匹克号的外壳。破坏是相当大：一个三角形的破洞，大小为15尺高，10尺宽和10尺深。两个最大的不透水舱飞快地被灌满水，因此所有的防水门都关闭了。但是即使任何两个隔水间朝大海打开，船也不会沉没的。难以置信地是，没有人受伤害。这是因为乘客在饭厅吃午餐，所以被切开的二等舱当时是空的。并且Hawke号配备了一个船头冲角用来缓冲碰撞和减轻破坏。

IT项目必须谨慎地关注先前项目的"航行记录"，它们执行过程的成功事例有助于确定需要学习的教训，并且理解其中一些风险。对奥林匹克来说，明显全体人员都被询问过究竟是巨大的尺寸还是新的造船技术的船导致那些事件发生。

与Hawke号碰撞之后，奥林匹克卸下了1,300名乘客，在贝尔法斯特旱船坞停止服务了六周更换钢板。在事故调查中，皇家海军专家把责任归结于比Hawke号重8倍的奥林匹克施加的强大吸力上，也就是通常所说的伯努利法则。这个事故值得注意，因为泰坦尼克在1912年离开南安普敦的时候，几乎就要发生一次碰撞。更值得注意的是船长Smith，大副Murdoch和二副Lightoller都是这两次航行中成员。事实上，白星晋升船长Smith来指挥舰队的旗舰显示了一种自信。Hawke事故一直在船长Smith心头萦绕，然而，他不断声辩自己是清白的，是Hawke号撞了奥林匹克号，因此碰撞是Hawke号船长的错。

IT项目应该按照使用规范和有关设置，严格地调查先前的解决方案是如何完成的（正常运转）和它们的操作。任何一种故障或异常必须通过事后检查严格地调查，并作为制订计划的输入项。

结论

今天许多IT项目没有为测试充分地制订计划，未能防止在解决方案中的严重妥协转换成产品。这与泰坦尼克的失败非常相似，由于轻信奥林匹克的经验，白星公司认为泰坦尼克的初次航行具有最低限度的风险。毕竟这两艘船几乎一模一样，并且船的所有者和全体人员对泰坦尼克满怀信心。然而，没有两艘船具有同样的操纵特性。白星为无计划的测试下了一个大赌注，而且横渡大西洋的泰坦尼克号上船员的人数也不足定额。当泰坦尼克进入到下一次阶段的时候，人们在观念并没有多少改变，仍然坚信船是永远不会沉没。[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/7839396/viewspace-955594/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/7839396/viewspace-955594/