作者：傅潔瑩 / 臺灣大學計算機及資訊網路中心程式設計組
什麼是軟體發展的生命週期？就是將邏輯性的系統概念，發展成可以實作的系統設計文件後，以撰寫程式碼的方式實現，接著交付佈建、測試運行，最後進入運行維護的發展步驟。
前言
筆者平常所接觸的工作、研究等，常以專案或計畫型態存在，本篇旨在藉由介紹專案的階段、軟體開發的生命週期與流程模型，幫助大家日後在面對軟體專案開發時，能夠依據特性，如程式語言類型、時程、成本、人力及組織型態等諸多因素，選擇適合的模型，提高執行效率與品質。
軟體業的特質
軟體產業與實體產業有很大不同，軟體產品『一次生產，多次銷售』的特質，較專案導向的產品更是明顯，不像製造業需投入大量資金來建造實體生產線，才能推出產品。
軟體業的生產線就是軟體開發流程。就投資而言，軟體產品成形所需的元素為開發人員與專業知識，而此生產線只要製造一次就可以複製多次，相形之下，也突顯出軟體開發流程的重要性。軟體業在開發的過程，有三個階段很重要，取其最後一個字母，稱為軟體的3N：
-
VisioN：洞悉使用者的未來需求。
(做產品的公司，因為使用的客群過於廣大，沒有固定範圍，確認使用者的需求也顯得格外重要。軟體公司常用焦點團體的方式，找人擔任產品的使用者，以發掘、評估產品的功能。)
-
MissioN：一個Vision會被分割成許多不同的Mission來達成。
(先要有一個足夠大的Vision讓公司看見未來的營利，才會願意針對各種狀況與問題著手，才有很多Mission被分割出來。)
-
ActioN：軟體3N中最實際的部份，此階段就是進行軟體開發。
專案的生命週期與階段
專案的生命週期＝努力：時間。一開始工作量與時間皆為零，隨著時間的推移，工作付出逐漸增加而達到高峰，再逐漸減少至專案結束。專案與服務不同在於，專案一定會有結束的一天，服務則必須一直維運下去。
專案通常分成幾個階段進行：
1. Concept(概念)：
-
蒐集資料
-
確認需求
-
建立目標
-
分析風險
-
提出建議
-
獲得核准
2. Development(發展)：比較接近規劃階段(Planning)；
-
建立團隊
-
決定範疇
-
擬定計畫
-
分解任務
-
排定時程
3. Implementation(執行)：真正開始進行程式碼撰寫；
-
帶動團隊
-
建立資訊
-
執行任務
-
採購物品
-
控制成本
-
掌握品質
4. Termination(結束)：這是最後階段，會產出結案報告，經驗是否能傳承，全看結案報告是否能達成下列事項：
- 把當初的規劃與最後結案的情況做比對，確認是否都達成預計的目標
- 統計花了多少時間與成本。
- 將上述資料整理分析，累積增長經驗，使日後評估更精確
- 評估的方法有很多，經驗累積後，才能找出最適合的法則。
此階段主要活動為：
-
完成任務
-
審查結果
-
移轉責任
-
結案報告
-
經驗學習
-
解編歸建
專案都會分階段執行，完成第一階段再進行第二階段，以此類推直到完成。分階段的意義在於，如果在每個階段進行過程中，遇到最壞的狀況或無法解決的問題，都可以有喊停的機會，不致於一直錯下去，到無法挽回的地步。
軟體生命週期模型
軟體開發工程師必須組合出一個包含過程、方法及工具層次的開發策略。這樣的策略經常被稱為軟體發展生命週期模型(Software Development Life Cycle Model，SDLC)。 軟體開發程序(Software Development Procedure)或稱為軟體工程規範(Software Engineering Paradigm)，在IEEE/EIA 12207與J-STD-016有詳盡的說明。 軟體發展生命週期模型主要描述或定義軟體開發的步驟階段，提供開發者一個系統性的流程，以成功地開發使用者所需要的軟體。這次為大家介紹七種模型：
1. 瀑布式
發展階段一段一段往下推，一定要一個階段作完才能往下做，無法平行，因此要準備的文件相當多，不適於小型專案開發。
-
1970年美國為了國防及航太計畫所產生的模型。
-
安全的開發方式。
-
要求許多準備文件。
-
較易維護也易於管理。
-
所需開發的時間較長。
-
若產品需求稍做更動，會導致後面階段也要進行更改。
-
適合大型專案開發。
2. 漸進式
特點：第一階段產生的結果是第二階段的需求。
每個階段的產出都是產品，所以每個階段產出都非常明顯，但完成的產品會一直因為上一階段的產出而有所變動。
V型
每個階段都有對等的關係，從當初的設計、開發、架構…等，都會對應到一個方法來驗證。
-
改良自傳統瀑布式。
-
對品管是最有助益的方式。
-
確保所開發的產品符合設計規格。
-
承襲傳統瀑布式缺點，需求更動即造成後續影響。
4. 原型快速開發
與瀑布式近似，但每個階段都有強烈的回饋(feedback)，瀑布式與其不同在於它是很嚴謹的鎖住每個階段。
-
軟體需求上的溝通確認較容易。
-
較適合專業開發模式。
螺旋型
將瀑布模型的最終結果導回源頭，成為一個往復式的圓圈，使整個流程具備回饋與檢驗機制，這就是螺旋模型(Boehm，1988)。
改善傳統瀑布式的需求更動影響缺點，結合風險管理與原型快速發展的觀念。
-
將開發目標、替代方案、限制的項目列出。
-
分析是否有其他方法，同時找出存在風險並加以解決。
-
進行開發、測試、審查的步驟。
-
進行下一個階段的計畫。
6. 極限型
適合Web應用專案，不適用大型專案(因大型專案在模型圖中會有很多箭頭進出)，這也是個強調回饋的模型，若採用此方式會造成需求不停變動，大型專案要一開始就清楚明確定義出需求，確定後就不宜更改。
Kent Beck 於1996年提出的理論，具有下列特點：
-
溝通(Communication)
-
簡潔(Simplicity)
-
回饋(Feedback)
-
勇氣(Courage)
注意事項：此模型並未要求準備詳細的文件，對於專案開發而言是很難接受這樣的開發模式。
7. RUP
軟體工程在近代最有名且使用在物件導向是Rational統一流程(Rational Unified Process，簡稱RUP)。由Rational 公司發展，現已被IBM公司併購，有三大特點、四個階段和九個核心流程。
三大特點為：
-
軟體開發是一個疊代(Iteration)過程。
-
軟體開發是由使用案例(Use Case)驅動。
-
軟體開發是以構架設計(Architectural Design)為中心。
採瀑布式改良過的階段開發流程：
-
起始階段(Initial phase)：進行可行性研究，定義專案大小及涵蓋範圍，評估專案所需的能力、時程與經費，及資訊系統預期達到之效益，了解商業模型及需求。
-
精細規劃階段(Elaboration phase)：擬定專案計畫、系統特性與架構•確認商業模型及需求，進行系統分析與設計。
-
建構階段(Construction phase)：建構產品並進行單元、整合測試。
-
移轉階段(Transition phase)：將產品分批交付給客戶驗收測試，並進行使用者訓練。
現實環境的軟體開發模式
-
由上而下的方式(Top-Down Apporach)
此方式也稱為架構式開發，使用開放的架構思考，將產品的需求列出，利用WBS(Work Breakdown Structure)的方法將各個需求分散成為不同的功能，每個功能再細分為規格。這種方式開發出的產品在延展性及穩定度較佳，但相對所需的開發時程和準備功夫也較長。
-
由下而上的方式(Bottom-Up Approach)
通常使用這種方式是基於市場競爭考量，此法亦稱為組合式開發，所採用的方式就是以目前所擁有的資源及技術進行快速組合成為產品。這種開發模式雖快速但他不是基於一個架構性的思考，因此所開發的產品在延展性及穩定度較差，而且產品需求是經由組合方式產生的，所以部份需求會與使用者的實際需求有所差異，當然伴隨而來的是教育使用者的額外費用。
結論
上述對各種不同軟體開發流程做簡略的介紹說明，但大多數都是以傳統瀑布式為主軸，並加以改良。但就軟體產品的組成觀點來看，其實只有兩種方式：
1. 架構式開發
2. 組合式開發
無論選擇哪種模式，在開發過程中，都必須設立不同的里程碑，或是檢查點；例如像Pre Alpha、Alpha…等的名稱都是流程中的里程碑。在每個里程碑時最好用REDC(Review、Evaluate、Discussion、Conclusion)方法來檢查目前的進度，再進行下一階段的開發流程。
軟體開發在現實生活中困難重重，建議先建構基礎的軟體開發模型，再進行較大範圍的系統開發。若是開發人數較少的團隊，不建議開發Multi-Domain、Multi-Language、Multi-Skill、Multi-Model的軟體，這樣只會增加團隊執行上的困難度。
參考資料
[1]. 中華民國資訊軟體協會 軟體測試流程 莊孫文
[2]. 軟體工程：物件導向程式設計與UML系統分析實作 陳湘揚等/著 (博碩出版)