RUP2 第1章 最好的軟體開發實務經驗

[mic64]

第一部分 流程

第1章 最好的軟體開發實務經驗
作者：Grady Booch
本章提供最好的軟體開發實務經驗，並說明Rational 統一流程的相關背景
知識。
軟體的價值
軟體是現代企業發展、政府運作、社會大眾溝通的原動力。它幫助我們以過
去無法想像的方式和型態去產生、擷取並觀察資訊。在全球各地，軟體快速進步
對全球經濟快速成長居功偉厥。從個人角度看，軟體密集式（Software-intensive）
產品除了拯救病人、讓不會說話的人發出聲音、讓殘障人士行動自如，還讓他們
有更多機會與一般人競爭。從這些觀點看，軟體是現代世界不可或缺的一環1。
對軟體專業人士而言，全球經濟對軟體的依賴性增加是件好消息。為了因應
社會所需，用科技完成的軟體密集式（Software-intensive）系統越來越大、複雜
和廣泛，當然也更重要。
壞消息是系統越大、複雜、廣泛和重要時，從事軟體工業的我們在軟體開發
知識方面也益發不足。把新技術帶入舊系統會產生許多技術和組織的問題。問題
越來越複雜的因素是企業不斷要求增加生產力並改善品質，卻更希望用最短的時
程開發和配置。訓練有素的開發人員永遠供不應求。
最後結果是設定軟體組態和維護軟體都變得很難，而且越來越難。不用說，
期待以可重複、可預期的方式建構高品質的軟體更是難上加難。
軟體開發問題的症狀與主因
有許多軟體開發專案都失敗了，而且不同專案有不同的失敗原因。還好，從
這些專案中我們可以找出相同的症狀並加以歸類2,3：
.. 無法準確了解使用者需要
.. 無法處理需求的改變
.. 模組（Module）間無法配合
.. 軟體很難維護或擴充
.. 太慢發現專案的嚴重瑕疵（Defect）
.. 軟體品質低落
1 Grady Booch, “Leaving Kansas,” IEEE Software 15(1), January-February 1998, pp.32-35.
2 Caper Jones, Patterns of Software Systems Failure and Success. London： International
Thompson Computer Press, 1996.
3 Edward Yourdon, Death March ： Managing “Mission Impossible” Projects. Upper Saddle
River, NJ： Prentice Hall, 1997.

.. 無法接受軟體效能
.. 團隊成員彼此妨礙，不知道誰改了什麼、什麼時候改、改那裡和為什麼
改
.. 不可信賴的建構並發表（Build-and-release）流程
不幸的是改善症狀並不能消災。例如太慢發現專案的嚴重瑕疵祇是大問題的
症狀而已，問題可能是主觀的專案狀態評價和不一致的專案需求、設計（Design）
與實作（Implementation）。
雖然專案有不同的失敗原因，不過很顯然地大多是因為下面幾項原因：
.. 特別的需求管理（Requirement Management）
.. 模稜兩可和不精確的溝通方式
.. 脆弱的架構（Architecture）
.. 很難處理的複雜性
.. 不一致的需求、設計和實作
.. 測試不足
.. 不客觀的專案狀態評價
.. 沒有克服風險
.. 失去控制的改變延遲
.. 自動化不足
最好的軟體實務經驗
如果能克服前述這些原因，不但可以消除症狀，還能有更多優勢，以可重複、
可預期的方式來開發和維護軟體。
這就是最好的軟體實務經驗：它們是商業上被證實可行的軟體開發方式。使
用它們可以解決軟體開發的問題主因4。稱為”最好的實務經驗”，不是說可以
準確測量它們的價值，而是因為它們已經廣被業界的成功組織採用。這些最好的
實務經驗包括：
1. 以反覆式開發方式（Iterative Development）去開發軟體
2. 管理需求
3. 以元件為基礎（Component-based）的架構
4. 視覺式模型製作軟體（Visually Model Software）
5. 持續驗證軟體品質
6. 控制軟體的改變
4 請參考軟體程式經理網(Software Program Manager’s Network)中最好的實務經驗，http ：
www.spmn.com.

用反覆式方法開發軟體
一般軟體開發流程是依照瀑布式生命週期（Waterfall LifeCycle），如圖1－1
所示。在這種方法，開發流程從需求分析（Requirement Analysis）、設計、寫程
式、到單元測試（Unit Testing）、子系統測試（Subsystem Testing）、系統測試（System
Testing）都是以線性（Linear）方式進行。
這種方法的主要問題是：它把風險（Risk）的時間點往前推，因此解決早期
錯誤的成本會很高。如果一開始主要的需求設計（Requirement Design）有瑕疵，
而且太慢發現設計的瑕疵，會導致經費大增甚至取消專案。Tom Gilb 說得好，”
如果你不主動攻擊專案風險，那麼它們反過來會攻擊你”5。瀑布式方法（Waterfall
Approach）容易隱藏專案實際風險，發現時通常已經太慢了。
圖 1-1 瀑布式生命週期
5 Tom Gilb, Principles of Software Engineering Management. Harlow, UK： Addison-Wesley,
1988, p.73.

圖 1-2 漸進的、反覆式流程
除了瀑布式方法（Waterfall Approach），漸進的、反覆式流程（Iterative Process）
是另一種選擇，如圖1－2 所示。這種方法的基礎是Barry Boehm 螺旋模型（Spiral
Model）6，它在生命週期初期找出風險，此時可以以有效、及時的方法去克服風
險。這種方法會持續發掘、創造和實作，在每次反覆（Iteration）強迫開發團隊
以可預測、可重複的方式，完成專案的工作成果。
以反覆式方法開發軟體可以解決許多軟體開發問題：
1. 在生命週期初期明顯發現嚴重錯誤所在，此時還可能來的及反應。
2. 這種方法鼓勵使用者回饋（Feedback），找出系統真正需求。
3. 強迫開發團隊把焦點放在專案重大議題，避免跟專案真實風險無關的議
題。
4. 持續不斷地測試，客觀評估專案狀態。
5. 需求、設計和實作的不一致性（Consistence）可以早期發現。
6. 團隊的工作負荷，尤其是測試團隊，可以平均分散在整個專案生命週
期。
7. 團隊可以活用所學，不斷改善流程。
8. 在整個專案生命週期，專案的關係人（Stakeholder）可以得知專案狀態
的具體事實。
6 Barry W. Boehm, “A Spiral Model of Software Development and Enhancement,” IEEE
Computer, May 1988, pp. 61-72.

管理需求
管理軟體密集式（Software-intensive）系統需求時，最大挑戰為需求是動態
的：在整個軟體專案生命，你必須假設它們是會改變的。而且，找出系統真實需
求是持續的過程，這對系統的財務與技術目標有很大影響。除了最平凡的系統
外，我們不太可能在開發前完整描述系統需求。的確，隨著新系統或系統演進，
使用者對系統需求的了解也會跟著改變。
需求代表系統必須符合的條件或能力。主動的需求管理包含三個活動
（Activity）：引導出系統需要的功能和限制、把它們加以組織和把它們放進文件；
估計需求的改變和評估它帶來的衝擊；追蹤並把所有的取捨與決定放進文件。
管理專案需求可以解決許多軟體開發的問題：
1. 建立有紀律的需求管理（Requirement Management）方法。
2. 以定好的需求為基礎進行溝通。
3. 排定需求優先順序、過濾並追蹤它們。
4. 預計達成功能和效能的客觀評估。
5. 更早發現不一致。
6. 如果有適當的支援工具，就可以儲存系統需求、屬性和軌跡，而且還可
以自動連結外部文件。
以元件為基礎（Component-based）的架構
視覺化、詳述、建構軟體密集式（Software-intensive）系統和紀錄文件都需
要從不同觀點看整個系統。每位關係人－終端使用者（End-user）、分析師
（Analyst）、開發人員、系統整合人員（System Integrator）、測試人員（Tester）、
技術寫作人員（Technical Writer）和專案經理（Project Manager）都會給專案帶來
不同的議題，而且在不同軟體生命時期，每個人看系統的方式也不同。系統架構
可能是最重要的產出文件，它用來管理不同觀點，並且在整個生命週期，我們用
它控制系統以漸進的、反覆式方法開發。
系統架構（System Architecture）裡面包含下面幾項重大決定：
.. 軟體系統的組織
.. 選擇結構元素和它們之間需要的介面（Interface）
.. 用元素間的合作（Collaboration）描述結構元素的行為
.. 結合結構元素和行為元素形成更大的子系統（Subsystem）
.. 指引組織的架構風格（Architectural Style）：元素、元素間的介面、合作
（Collaboration）和合成（Composition）
軟體架構（Software Architecture）不止跟結構與行為有關，同時也會跟用法、

功能性（Functionality）、效能、彈性、再使用性（Reuse）、可理解性、財務與技
術的限制與取捨和審美觀考量等等相關。
設計一個有彈性的架構很重要，因為它可以很經濟地提昇再使用性
（Reuse）、清楚劃分開發團隊工作、把容易改變的硬體與軟體相依性（Dependency）
獨立出來，改善可維護性（Maintainability）。
對軟體架構（Software Architecture）來說，以元件為基礎（Component－based）
的開發方式是一種很重要的開發方法，它讓各種商業元件（Component）得以再
使用（Reuse）或客製化（Customization）。Microsoft 的COM、物件管理協會（Object
Management Group）的CORBA 和Sun Microsystem 的企業JavaBeans （EJB）都提
供被廣泛支援而且普遍的平台，我們可以在這些平台上建立以元件為基礎的架
構。如圖1－3 所示，元件擴大再使用的規模，使得系統可以由現有零件、協力
廠商提供的現成（Off-the-Shelf）零件、解決特定領域問題的零件或整合其它零件
的零件組成。
為了搭配反覆式開發方式（Iterative Development），以元件為基礎（Component
－based）的架構必須不斷改善系統架構。每次反覆都必須產生一個可執行的架
構，並且測量、測試、評估它是否符合系統需求。這種方式讓開發團隊持續降低
專案的最重要風險。
以元件為基礎（Component－based）的開發方式解決許多軟體開發問題：
1. 使用元件可以很容易形成有彈性的架構。
2. 模組化（Modular）清楚隔離系統中容易改變的元素。
3. 採用標準化框架（Framework）（例如COM+、CORBA、EJB）和業界提
供的元件可提升再使用性（Reuse）。
4. 元件提供一個自然的組態管理（Configuration Management）基礎。
5. 視覺式模型製作工具（Visual Modeling Tool）替以元件為基礎（Component
－based）的開發工作提供自動化。

圖 1-3 以元件為基礎的軟體架構
視覺式模型製作軟體（Visually Model Software）
模型是簡化的真實事物，這裡所指的真實事物是從特定觀點完整描述一個系
統，如圖1－4 所示。模型製作（Modeling）過程讓我們更了解系統；建複雜系統
的模型是因為我們無法理解整個系統。
模型製作（Modeling）很重要，因為它讓開發團隊可以把系統架構的結構和
行為加以視覺化、詳述、建構並製作文件（Documenting）。使用標準的模型語言
（Modeling Language），例如UML，開發團隊成員可以向其它成員明白傳達他們
的決定。
視覺式模型製作工具（Visual Modeling Tool）讓管理模型變得更加方便，它
可以根據需要隱藏或顯示細節。也可以維護系統工作成果間的一致性
（Consistence）：系統需求、設計和實作。簡言之，視覺式模型製作（Visual Modeling）
可以增進開發團隊管理複雜軟體的能力。

圖 1-4 從各種觀點製作系統模型
如果結合反覆式軟體開發實務經驗，視覺式模型製作（Visual Modeling）可
以幫你發現並評估架構的改變，並且傳達改變給整個開發團隊。如果有正確的工
具幫忙，在每次反覆後，你可以把模型和原始碼（Source Code）同步。
視覺式模型製作（Visual Modeling）解決許多軟體開發問題：
1. 使用案例（Use Case）和情節（Scenario）可以明白詳述行為。
2. 模型可以清楚表示軟體設計。
3. 非模組化（Modular）和不具彈性的架構可被顯現出來。
4. 可根據需要隱藏細節。
5. 清楚的設計可以更快顯示出矛盾。
6. 應用程式的品質從好的設計開始。
7. 視覺式模型製作工具（Visual Modeling Tool）支援UML 模型。
持續驗證軟體品質
如圖1－5 所示，配置後才發現並修正軟體問題，比事先發現要多付出一百
倍到一千倍的代價。因此，持續評估系統的功能性（Functionality）、可靠性
（Reliability）、應用效能和系統效能品質就顯得很重要。

圖 1-5 修正瑕疵的成本
驗證系統功能代表大量的測試活動，包括為每個主要情節（Scenario）和表
達系統行為的事物作測試。我們可根據什麼情節失敗，那裡、那些情節和相關程
式碼無法運作來