IT專案啟示錄——來自泰坦尼克號的教訓(第三篇)(轉)
泰坦尼克的設計者儘管有許多設計方案可以選擇,但是從開始他們就遵循乘客舒適度的最佳化高於航行速度的經營戰略。他們從不懷疑能夠打破橫渡大西洋的記錄。這個戰略調整意味著船體可能是一個寬的"U"形船體而不是一個圓滑而緊湊的"V"形式船體。這種做法增加了船23%的體積,使得頭等艙、二等艙和客艙更加大更舒適,並將大大增加旅客的感受。
與今天相比,你能夠照搬你的競爭手段或使用新技術來贏得優勢並且嘗試一些與眾不同的東西,透過較好的經濟回報在市場中佔有一席之地。
作為泰坦尼克設計的一部分,設計者把商業需求改變成船的功能要求,即所謂運輸工具和殷勤款待。這些主要的功能包括根據客艙和套房、供應伙食、消遣和娛樂需求來確定艙室佈置。
同樣地,由於有形的功能容易為企業家和IT工作人員理解,所以大多數的IT專案透過這個階段相對輕而易舉地就被改變了。
如第一部分所述,由於定義的是系統運轉基本特性,那些無功能需求具有難以置信的重要性。對泰坦尼克的設計者來說,無功能需求包括檢查安全性、效能、穩定度、可靠性、維修性和環境。因此無論功能要求的規格是什麼,這些無功能需求確保了船能夠提供出當初設計的功能。
同樣地對IT專案來說,無功能需求包括可用度(類似於安全性)、可靠性和基於系統執行時間特性的系統管理。基於非執行時間特性的其他無功能需求包括可量測性、可攜帶性、維修性、環境因素以及可升級性。同樣無功能需求確保系統能夠提供所設計的功能。
為了確定無功能需求,泰坦尼克的設計者使用了一種類似"造船專家"的模型技術。這個15英尺長的模型提供了一個準模擬環境來確定邏輯和物理設計是否能夠作為船的功能進行工作。例如:功率與重量比例是否恰當,或者船如何在狂風惡浪中保持穩定?假設的故障情景被建立成模型用於確定備選的功能部件置及其它們最佳執行方式,也就是尺寸、範圍和數目。這些故障方案例如船擱淺或海岸堆積的方案或者解決包含前端或側面衝撞的方案。
同樣地,為確定無功能需求現在有許多利用的計算機輔助建模技術。為研究端到端的解決方案,流程分析模型對每一個關鍵事件處理進行高等級跟蹤,並且路徑上的各組成部分是根據其無功能的特徵,尤其是可用度來確定。另一個技術也用於確定單個或集合的組成部分(硬體或軟體)沿此路徑發生最壞情形的故障方案模型,例如:在處理流程高峰時的影響或網上攻擊。與動態測試相對應的,這種方法亦稱為"靜態"測試、“乾式執行”(dry run),或走查“walkthrough”。
泰坦尼克的設計者必須確定可用性(安全性)的特徵、做出投資選擇並且基於假設分析(what-if)的故障情況的可能性,在四個可用性等級中有效地選擇其中一個。例如:基本等級被定義為根本沒有安全裝置。這個等級是指船具有封閉艇的特性、能橫越英吉利海峽而不是公海。最高等級定義為有一整套安全裝置包括各類救生船、抽水和推進功能部件比如雙殼體、多個隔水艙、密封艙壁、電動門、碰撞充填和壓縮空氣來排水。船完全具有全速橫渡大西洋的遠洋船所有特性。
今天,我們必須確定可用性的功能部件並要做出投資選擇。有許多使用軟體和硬體技術可以改善可用性的解決方案並且防範五級故障(物理的、設計的、運算的、環境的和結構變換的)。這些技術包括從元件到容錯系統最終到堆疊的每個物體。該技術啟用"橫向可測量性"的成分並透過複製和重複以分離單獨的故障點。
最後,泰坦尼克的設計者選擇了最高階的安全性和綜合了所有最新和超前的安全技術。歸根結底,他們是在基於最新技術來建造最好的船。然而,由於董事的商業壓力,泰坦尼克的設計者開始在安全裝置上做出妥協,這些壓力明顯地來自企圖為乘客創造一流體驗的白星公司老闆Bruceismay。例如:四個防水壁吃水線以上部分只有10英尺而並沒有到達頂甲板,目的是騰出一個200尺的寬敞舞廳。同樣地,總數為48個的救生船最初設計也為了頭等艙要有廣闊的海景而漸漸變得不明顯,最終減少到低得多的16個。
同樣地,在今天的IT專案中,每天或者每週都會有上百個小的決定、這些決定被認為是服務於企業家的技術。無功能需求一般會超出大多數企業家的舒適範圍外,因此任何對無功能需求的妥協可能不會被輕易地理解。然而他們對生產過程中的解決方案施加了一個較大的影響,可能會波及整個業務的完成。
從泰坦尼克的施工階段開始,這幾乎已經太遲了。沒有人理解犯下的錯誤都是非常嚴重的。即便船的無功能需求已經被妥協、泰坦尼克決不會沉沒的信念一直存留在泰坦尼克的設計者當中。船隻所有寬闊的船體設計、船的舷弧尺寸(超出當時所建造船的最大長度50%)、使用了所有超前安全裝置和最新技術的綜合指標的完成使所有白星的工作人員認為泰坦尼克所向披靡。泰坦尼克能夠在任何情況下繼續存在,並且再大的風險也能夠克服。
在這個氛圍裡,很容易理解設計者把救生船的數目減少到了16艘,這是在所有妥協當中最大、最嚴重的。救生船當時被認為是附加的安全裝置,是泰坦尼克號要營救其他失事船上的乘客才能用上的東西。當然,泰坦尼克絕不會被認為會沉沒。
泰坦尼克是永不沉沒的觀念同樣也波及到了白星公司的市場營銷。當施工階段進行到船內部成形時,這種為了使乘客舒適明顯濫用投資的行為意味用於不被人注意的船的安全性與操作功能部件的投資被等量地用掉了。有點像今天要買一輛奢侈汽車那樣。泰坦尼克作為永不沉沒推銷給公眾並且這種觀點也已被廣泛接受。
結論
今天許多IT專案在這個設計和施工階段幾乎毫無察覺地被嚴重妥協。但是在專案完成並進行生產後,妥協的影響作為一個問題也許不明顯,可能經過許多天、月甚至年不出現。作為專案經理們必須保證象關注功能要求一樣來重視無功能需求。
前者經常被犧牲因為它們較少被看得見,並且它們的重要性對於從事商業的人們,專案領導者或決策製造者來說並不顯著。由於每週會有上百個決定產生,作為專案經理需要收集這些影響,並讓那些企業的執行者充分了解。
下一部分將講述IT專案的設計和測驗。
[@more@]
與今天相比,你能夠照搬你的競爭手段或使用新技術來贏得優勢並且嘗試一些與眾不同的東西,透過較好的經濟回報在市場中佔有一席之地。
作為泰坦尼克設計的一部分,設計者把商業需求改變成船的功能要求,即所謂運輸工具和殷勤款待。這些主要的功能包括根據客艙和套房、供應伙食、消遣和娛樂需求來確定艙室佈置。
同樣地,由於有形的功能容易為企業家和IT工作人員理解,所以大多數的IT專案透過這個階段相對輕而易舉地就被改變了。
如第一部分所述,由於定義的是系統運轉基本特性,那些無功能需求具有難以置信的重要性。對泰坦尼克的設計者來說,無功能需求包括檢查安全性、效能、穩定度、可靠性、維修性和環境。因此無論功能要求的規格是什麼,這些無功能需求確保了船能夠提供出當初設計的功能。
同樣地對IT專案來說,無功能需求包括可用度(類似於安全性)、可靠性和基於系統執行時間特性的系統管理。基於非執行時間特性的其他無功能需求包括可量測性、可攜帶性、維修性、環境因素以及可升級性。同樣無功能需求確保系統能夠提供所設計的功能。
為了確定無功能需求,泰坦尼克的設計者使用了一種類似"造船專家"的模型技術。這個15英尺長的模型提供了一個準模擬環境來確定邏輯和物理設計是否能夠作為船的功能進行工作。例如:功率與重量比例是否恰當,或者船如何在狂風惡浪中保持穩定?假設的故障情景被建立成模型用於確定備選的功能部件置及其它們最佳執行方式,也就是尺寸、範圍和數目。這些故障方案例如船擱淺或海岸堆積的方案或者解決包含前端或側面衝撞的方案。
同樣地,為確定無功能需求現在有許多利用的計算機輔助建模技術。為研究端到端的解決方案,流程分析模型對每一個關鍵事件處理進行高等級跟蹤,並且路徑上的各組成部分是根據其無功能的特徵,尤其是可用度來確定。另一個技術也用於確定單個或集合的組成部分(硬體或軟體)沿此路徑發生最壞情形的故障方案模型,例如:在處理流程高峰時的影響或網上攻擊。與動態測試相對應的,這種方法亦稱為"靜態"測試、“乾式執行”(dry run),或走查“walkthrough”。
泰坦尼克的設計者必須確定可用性(安全性)的特徵、做出投資選擇並且基於假設分析(what-if)的故障情況的可能性,在四個可用性等級中有效地選擇其中一個。例如:基本等級被定義為根本沒有安全裝置。這個等級是指船具有封閉艇的特性、能橫越英吉利海峽而不是公海。最高等級定義為有一整套安全裝置包括各類救生船、抽水和推進功能部件比如雙殼體、多個隔水艙、密封艙壁、電動門、碰撞充填和壓縮空氣來排水。船完全具有全速橫渡大西洋的遠洋船所有特性。
今天,我們必須確定可用性的功能部件並要做出投資選擇。有許多使用軟體和硬體技術可以改善可用性的解決方案並且防範五級故障(物理的、設計的、運算的、環境的和結構變換的)。這些技術包括從元件到容錯系統最終到堆疊的每個物體。該技術啟用"橫向可測量性"的成分並透過複製和重複以分離單獨的故障點。
最後,泰坦尼克的設計者選擇了最高階的安全性和綜合了所有最新和超前的安全技術。歸根結底,他們是在基於最新技術來建造最好的船。然而,由於董事的商業壓力,泰坦尼克的設計者開始在安全裝置上做出妥協,這些壓力明顯地來自企圖為乘客創造一流體驗的白星公司老闆Bruceismay。例如:四個防水壁吃水線以上部分只有10英尺而並沒有到達頂甲板,目的是騰出一個200尺的寬敞舞廳。同樣地,總數為48個的救生船最初設計也為了頭等艙要有廣闊的海景而漸漸變得不明顯,最終減少到低得多的16個。
同樣地,在今天的IT專案中,每天或者每週都會有上百個小的決定、這些決定被認為是服務於企業家的技術。無功能需求一般會超出大多數企業家的舒適範圍外,因此任何對無功能需求的妥協可能不會被輕易地理解。然而他們對生產過程中的解決方案施加了一個較大的影響,可能會波及整個業務的完成。
從泰坦尼克的施工階段開始,這幾乎已經太遲了。沒有人理解犯下的錯誤都是非常嚴重的。即便船的無功能需求已經被妥協、泰坦尼克決不會沉沒的信念一直存留在泰坦尼克的設計者當中。船隻所有寬闊的船體設計、船的舷弧尺寸(超出當時所建造船的最大長度50%)、使用了所有超前安全裝置和最新技術的綜合指標的完成使所有白星的工作人員認為泰坦尼克所向披靡。泰坦尼克能夠在任何情況下繼續存在,並且再大的風險也能夠克服。
在這個氛圍裡,很容易理解設計者把救生船的數目減少到了16艘,這是在所有妥協當中最大、最嚴重的。救生船當時被認為是附加的安全裝置,是泰坦尼克號要營救其他失事船上的乘客才能用上的東西。當然,泰坦尼克絕不會被認為會沉沒。
泰坦尼克是永不沉沒的觀念同樣也波及到了白星公司的市場營銷。當施工階段進行到船內部成形時,這種為了使乘客舒適明顯濫用投資的行為意味用於不被人注意的船的安全性與操作功能部件的投資被等量地用掉了。有點像今天要買一輛奢侈汽車那樣。泰坦尼克作為永不沉沒推銷給公眾並且這種觀點也已被廣泛接受。
結論
今天許多IT專案在這個設計和施工階段幾乎毫無察覺地被嚴重妥協。但是在專案完成並進行生產後,妥協的影響作為一個問題也許不明顯,可能經過許多天、月甚至年不出現。作為專案經理們必須保證象關注功能要求一樣來重視無功能需求。
前者經常被犧牲因為它們較少被看得見,並且它們的重要性對於從事商業的人們,專案領導者或決策製造者來說並不顯著。由於每週會有上百個決定產生,作為專案經理需要收集這些影響,並讓那些企業的執行者充分了解。
下一部分將講述IT專案的設計和測驗。
[@more@]
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7839396/viewspace-955592/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- IT專案啟示錄——來自泰坦尼克號的教訓(第二篇)(轉)
- IT專案啟示錄——來自泰坦尼克號的教訓(第四篇)(轉)
- IT專案啟示錄——來自泰坦尼克號的教訓(第八篇)(轉)
- IT專案啟示錄——來自泰坦尼克號的教訓(第九篇)(轉)
- IT專案啟示錄——來自泰坦尼克號的教訓(第十一篇)(轉)
- IT專案啟示錄——來自泰坦尼克號的教訓(第十二篇)(轉)
- IT專案啟示錄——來自泰坦尼克號的教訓(第一篇)(轉)
- IT專案啟示錄——來自泰坦尼克號的教訓(第七篇)(轉)
- IT專案啟示錄——來自泰坦尼克號的教訓(第十篇)(轉)
- 機器學習專案實戰----泰坦尼克號獲救預測(二)機器學習
- 【決策樹】泰坦尼克號倖存者預測專案
- 單人專案管理的心得和教訓專案管理
- 來自10位 IT 大牛的23條經驗教訓
- 來自10位成功IT人士的23條經驗教訓
- 2019來自網際網路職場的教訓
- 經驗&教訓分享:我的第一個機器學習專案機器學習
- XXX管理平臺系統——專案教訓
- 成功專案經理的經驗教訓——鼓勵靈活的體制和行為(轉)
- 泰坦尼克生還預測:完整的機器學習專案(一)機器學習
- 作為專案經理的7個經驗教訓總結
- Struts 開發之 血的教訓 (轉)
- 一保健品專案運作失敗的原因和啟示(轉)
- 《卓有成效的管理者》培訓分享——來自專案管理群的討論專案管理
- JavaEE 啟示錄Java
- 專案管理辦公室的未來(轉)專案管理
- 如何啟動專案?(轉)
- 自動駕駛「黑手黨」十年啟示錄自動駕駛
- 專案管理經驗談——來自專案管理群的討論專案管理
- 手把手教SVN鉤子自動更新專案
- dir 顯示目錄檔案和子目錄列表(轉)
- 從1100多個專案中吸取的教訓:為什麼軟體專案需要英雄?
- 我的第一次專案管理--一次慘痛的教訓專案管理
- 搭橋啟示錄之二:專治各種不服的ICU
- 《啟示錄》筆記筆記
- Java EE啟示錄Java
- 專案管理經驗談——來自專案管理群的討論薦專案管理
- 來自程式設計“老者”們的須時刻謹記的七大教訓金典程式設計
- python 分析泰坦尼克號生還率Python