第1章 軟體危機與流程（摘錄）
1.1 軟體危機
著名的研究機構Standish Group曾在1995年針對全美國8000個軟體專案作了一項調查，發現超過30%的專案被取消，並且專案的預算平均超出189%。這項調查結果相當驚人，它忠實地呈現出當時的軟體專案所面臨的問題。經歸納分析，造成此種情況的主要原因有：(1)軟體公司總是在不合理的期限（Unrealistic Deadline）壓力下進行開發；(2)客戶在專案結束前要求增加新功能，或是給予不明確的需求（Vague Requirement）；(3)軟體本身非常複雜（Complex Structure）；(4)專案開發過程中具有許多不確定因素（Numerous Uncertainties）。
早期軟體專案發生嚴重問題的情況比比皆是。舉例來說[HRPL1999]，1982年美國銀行（Bank of America）想要進入信託生意的領域，因此花了18個月深入地研究及分析信託軟體系統，最後規畫以2000萬美元的預算，開發時程9個月，也就是在1984年12月底前完成該系統。然而此系統直到1987年3月都未完成，並且已耗費了6000萬美元，同時還失去了原先規畫的6億美元信託生意。最後因為此系統並不穩定，不得不放棄此系統，並將340億美元的信託帳戶轉移出去。除此之外，像是1996年發生的亞利安五號原型爆炸及波音Delta III火箭爆炸等事件，皆肇因於軟體問題。
軟體之所以會造成這些嚴重的問題，可以從Fredrick Brooks最經典的一篇論文[Bro1987]──No Silver Bullet中，得到部分的解答。他在該文中提到，軟體與生俱來的四種困境（Essential Difficulty）是造成即使到今日仍然無法找到「銀色子彈」的原因，同時也是造成軟體危機的主因：
1. 複雜性（Complexity）：軟體與現實生活中所接觸到的任何事物相比，有個很大的不同點，即軟體與生俱來的複雜性。當發展大型的軟體系統時，程式設計師動輒撰寫小至數百行程式碼的軟體元件，大至數萬行程式碼的系統關鍵模組，因此，軟體的複雜程度往往隨著程式的大小及軟體元件個數，以非線性甚至是等比級數的方式遞增。如此一來，往往導致一同發展的專案成員間溝通困難度提高、成本花費超出預算、發展時程延遲、系統進入非預期的狀態而當機，造成無法彌補的損失。
2. 易變性（Changeability）：軟體的易變性，更是所有軟體設計師的夢魘。我們很少聽說一棟大樓剛落成，屋主就隨興之所至要再大興土木來變動外觀或設計，因為這樣的調整勢必得付出相當大的代價。軟體的變動卻是大大相反，其相對於房子、車子、手機、電視等硬體的變動來得容易且快速，也因此軟體有比較大的彈性容許客戶提出調整的需求，以致軟體系統從開發到完成、從產品交付到營運維護，隨時都有可能要作變更。
3. 隱藏性（Invisibility）：軟體本身是看不到、摸不著的。人們習慣以幾何或是圖像化的方式呈現複雜或是無形的事物，幫助彼此進行溝通及思考。例如對於房子的設計，設計師會透過設計圖及模型與客戶作說明、討論；對於旅遊行程景點間的複雜路線規畫，導遊可以透過地圖幫助團員釐清方向與確認行程。軟體系統的確也可以透過圖像化的方式來表達它運作的資料流程、控制流程、系統架構、系統狀態、資料結構……等，但是軟體終究是看不見的，在溝通上無可避免地會遇到問題或阻礙，往往造成客戶的需求被誤解，或是疏漏之處不容易被發現。
4. 一致性（Conformity）：物理學家與數學家相信，宇宙中的萬物能夠如此井然有序，其背後一定有其亙古不變的規則、定律在主宰這一切的運行。然而在軟體世界中，每個軟體工程師都猶如各自軟體系統的神，他們各自創造屬於自己的系統模組及元件，如此一來，當多個軟體工程師共同協作發展軟體系統時，介面跟介面間、模組跟模組間、系統跟系統間的介接，或多或少都存在著不一致的地方，因此需要透過各種方式來轉換、處理這些有關一致性的問題。
過去幾十年來，為了解決軟體發展與品質方面的問題，人們不斷致力革新各種軟體開發技術，例如：從早期的機器語言（Machine Code）至Fortran、Pascal、Cobol、C等結構化的程式語言，再到C++、JAVA等物件導向（Object Orientation）的程式語言；或是從傳統的功能模組設計演變至物件導向設計等。除了這些技術上的努力與突破外，人們同時意識到，軟體開發流程其實對軟體的品質有舉足輕重的影響，因此許多學者提出不同的流程模式，試圖解決軟體開發常會遇到的問題。
1.1 軟體危機
著名的研究機構Standish Group曾在1995年針對全美國8000個軟體專案作了一項調查，發現超過30%的專案被取消，並且專案的預算平均超出189%。這項調查結果相當驚人，它忠實地呈現出當時的軟體專案所面臨的問題。經歸納分析，造成此種情況的主要原因有：(1)軟體公司總是在不合理的期限（Unrealistic Deadline）壓力下進行開發；(2)客戶在專案結束前要求增加新功能，或是給予不明確的需求（Vague Requirement）；(3)軟體本身非常複雜（Complex Structure）；(4)專案開發過程中具有許多不確定因素（Numerous Uncertainties）。
早期軟體專案發生嚴重問題的情況比比皆是。舉例來說[HRPL1999]，1982年美國銀行（Bank of America）想要進入信託生意的領域，因此花了18個月深入地研究及分析信託軟體系統，最後規畫以2000萬美元的預算，開發時程9個月，也就是在1984年12月底前完成該系統。然而此系統直到1987年3月都未完成，並且已耗費了6000萬美元，同時還失去了原先規畫的6億美元信託生意。最後因為此系統並不穩定，不得不放棄此系統，並將340億美元的信託帳戶轉移出去。除此之外，像是1996年發生的亞利安五號原型爆炸及波音Delta III火箭爆炸等事件，皆肇因於軟體問題。
軟體之所以會造成這些嚴重的問題，可以從Fredrick Brooks最經典的一篇論文[Bro1987]──No Silver Bullet中，得到部分的解答。他在該文中提到，軟體與生俱來的四種困境（Essential Difficulty）是造成即使到今日仍然無法找到「銀色子彈」的原因，同時也是造成軟體危機的主因：
1. 複雜性（Complexity）：軟體與現實生活中所接觸到的任何事物相比，有個很大的不同點，即軟體與生俱來的複雜性。當發展大型的軟體系統時，程式設計師動輒撰寫小至數百行程式碼的軟體元件，大至數萬行程式碼的系統關鍵模組，因此，軟體的複雜程度往往隨著程式的大小及軟體元件個數，以非線性甚至是等比級數的方式遞增。如此一來，往往導致一同發展的專案成員間溝通困難度提高、成本花費超出預算、發展時程延遲、系統進入非預期的狀態而當機，造成無法彌補的損失。
2. 易變性（Changeability）：軟體的易變性，更是所有軟體設計師的夢魘。我們很少聽說一棟大樓剛落成，屋主就隨興之所至要再大興土木來變動外觀或設計，因為這樣的調整勢必得付出相當大的代價。軟體的變動卻是大大相反，其相對於房子、車子、手機、電視等硬體的變動來得容易且快速，也因此軟體有比較大的彈性容許客戶提出調整的需求，以致軟體系統從開發到完成、從產品交付到營運維護，隨時都有可能要作變更。
3. 隱藏性（Invisibility）：軟體本身是看不到、摸不著的。人們習慣以幾何或是圖像化的方式呈現複雜或是無形的事物，幫助彼此進行溝通及思考。例如對於房子的設計，設計師會透過設計圖及模型與客戶作說明、討論；對於旅遊行程景點間的複雜路線規畫，導遊可以透過地圖幫助團員釐清方向與確認行程。軟體系統的確也可以透過圖像化的方式來表達它運作的資料流程、控制流程、系統架構、系統狀態、資料結構……等，但是軟體終究是看不見的，在溝通上無可避免地會遇到問題或阻礙，往往造成客戶的需求被誤解，或是疏漏之處不容易被發現。
4. 一致性（Conformity）：物理學家與數學家相信，宇宙中的萬物能夠如此井然有序，其背後一定有其亙古不變的規則、定律在主宰這一切的運行。然而在軟體世界中，每個軟體工程師都猶如各自軟體系統的神，他們各自創造屬於自己的系統模組及元件，如此一來，當多個軟體工程師共同協作發展軟體系統時，介面跟介面間、模組跟模組間、系統跟系統間的介接，或多或少都存在著不一致的地方，因此需要透過各種方式來轉換、處理這些有關一致性的問題。
過去幾十年來，為了解決軟體發展與品質方面的問題，人們不斷致力革新各種軟體開發技術，例如：從早期的機器語言（Machine Code）至Fortran、Pascal、Cobol、C等結構化的程式語言，再到C++、JAVA等物件導向（Object Orientation）的程式語言；或是從傳統的功能模組設計演變至物件導向設計等。除了這些技術上的努力與突破外，人們同時意識到，軟體開發流程其實對軟體的品質有舉足輕重的影響，因此許多學者提出不同的流程模式，試圖解決軟體開發常會遇到的問題。
