筆者平常所接觸的工作、研究等，常以專案或計畫型態存在，本篇旨在藉由介紹專案的階段、軟體開發的生命週期與流程模型，幫助大家日後在面對軟體專案開發時，能夠依據特性，如程式語言類型、時程、成本、人力及組織型態等諸多因素，選擇適合的模型，提高執行效率與品質。

軟體業的特質
軟體產業與實體產業有很大不同，軟體產品『一次生產，多次銷售』的特質，較專案導向的產品更是明顯，不像製造業需投入大量資金來建造實體生產線，才能推出產品。
軟體業的生產線就是軟體開發流程。就投資而言，軟體產品成形所需的元素為開發人員與專業知識，而此生產線只要製造一次就可以複製多次，相形之下，也突顯出軟體開發流程的重要性。軟體業在開發的過程，有三個階段很重要，取其最後一個字母，稱為 軟體的3N ：

Visio N ：洞悉使用者的未來需求。
(做產品的公司，因為使用的客群過於廣大，沒有固定範圍，確認使用者的需求也顯得格外重要。軟體公司常用焦點團體的方式，找人擔任產品的使用者，以發掘、評估產品的功能。)
Missio N ：一個Vision會被分割成許多不同的Mission來達成。
(先要有一個足夠大的Vision讓公司看見未來的營利，才會願意針對各種狀況與問題著手，才有很多Mission被分割出來。)
Actio N ：軟體3N中最實際的部份，此階段就是進行軟體開發。
專案的生命週期與階段
專案的生命週期＝努力：時間。 一開始工作量與時間皆為零，隨著時間的推移，工作付出逐漸增加而達到高峰，再逐漸減少至專案結束。專案與服務不同在於，專案一定會有結束的一天，服務則必須一直維運下去。

專案通常分成幾個階段進行：

Concept (概念)：
軟體生命週期模型
軟體開發工程師必須組合出一個包含過程、方法及工具層次的開發策略。這樣的策略經常被稱為 軟體發展生命週期模型(Software Development Life Cycle Model，SDLC) 。
軟體開發程序(Software Development Procedure)或稱為軟體工程規範(Software Engineering Paradigm)，在IEEE/EIA 12207與J-STD-016有詳盡的說明。
軟體發展生命週期模型主要描述或定義軟體開發的步驟階段，提供開發者一個系統性的流程，以成功地開發使用者所需要的軟體。這次為大家介紹七種模型：
1. 瀑布式
發展階段一段一段往下推，一定要一個階段作完才能往下做，無法平行，因此要準備的文件相當多，不適於小型專案開發。
1970年美國為了國防及航太計畫所產生的模型。
安全的開發方式。
要求許多準備文件。
較易維護也易於管理。
所需開發的時間較長。
若產品需求稍做更動，會導致後面階段也要進行更改。
適合大型專案開發。
2. 漸進式
特點：第一階段產生的結果是第二階段的需求。
每個階段的產出都是產品，所以每個階段產出都非常明顯，但完成的產品會一直因為上一階段的產出而有所變動。
將開發流程分為許多小型瀑布開發模式。
減少產品需求更動的影響。
開發成果較易顯現。
可在不同的建構版本(Build)中決定產品開發是否繼續。
3. V型
每個階段都有對等的關係，從當初的設計、開發、架構…等，都會對應到一個方法來驗證。
7. RUP
軟體工程在近代最有名且使用在物件導向是Rational統一流程(Rational Unified Process，簡稱RUP)。由Rational 公司發展，現已被IBM公司併購，有三大特點、四個階段和九個核心流程。
三大特點為：
軟體開發是一個疊代(Iteration)過程。
軟體開發是由使用案例(Use Case)驅動。
軟體開發是以構架設計(Architectural Design)為中心。
由上而下的方式(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系統分析實作 陳湘揚等/著 (博碩出版)
版權所有 © 國立台灣大學計算機及資訊網路中心 All Rights Reserved.
電話：02-33665022 或 3366-5023 傳真： 02-23637204
讀者意見信箱： ntuccepaper@ntu.edu.tw 地址：10617 臺北市羅斯福路四段一號
建議最佳螢幕解析度 1024*768