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@]