什么是軟件發(fā)展的生命周期？就是將邏輯性的系統(tǒng)概念，發(fā)展成可以實作的系統(tǒng)設(shè)計文件后，以撰寫程式碼的方式實現(xiàn)，接著交付布建、測試運行，最后進入運行維護的發(fā)展步驟。

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

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

1. Visio N：洞悉使用者的未來需求。
   (做產(chǎn)品的公司，因為使用的客群過于廣大，沒有固定范圍，確認使用者的需求也顯得格外重要。軟件公司常用焦點團體的方式，找人擔(dān)任產(chǎn)品的使用者，以發(fā)掘、評估產(chǎn)品的功能。)

2. Missio N：一個Vision會被分割成許多不同的Mission來達成。
   (先要有一個足夠大的Vision讓公司看見未來的營利，才會愿意針對各種狀況與問題著手，才有很多Mission被分割出來。)

3. Actio N：軟件3N中最實際的部份，此階段就是進行軟體開發(fā)。

專案的生命周期與階段
專案的生命周期＝努力：時間。一開始工作量與時間皆為零，隨著時間的推移，工作付出逐漸增加而達到高峰，再逐漸減少至專案結(jié)束。專案與服務(wù)不同在于，專案一定會有結(jié)束的一天，服務(wù)則必須一直維運下去。

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

1. Concept(概念)：

1. 搜集資料

2. 確認需求

3. 建立目標(biāo)

4. 分析風(fēng)險

5. 提出建議

6. 獲得核準(zhǔn)

2. Development(發(fā)展)：比較接近規(guī)劃階段(Planning)；

1. 建立團隊

2. 決定范疇

3. 擬定計畫

4. 分解任務(wù)

5. 排定時程

3. Implementation(執(zhí)行)：真正開始進行程式碼撰寫；

1. 帶動團隊

2. 建立資訊

3. 執(zhí)行任務(wù)

4. 采購物品

5. 控制成本

6. 掌握品質(zhì)

4. Termination(結(jié)束)：這是最后階段，會產(chǎn)出結(jié)案報告，經(jīng)驗是否能傳承，全看結(jié)案報告是否能達成下列事項：

• 把當(dāng)初的規(guī)劃與最后結(jié)案的情況做比對，確認是否都達成預(yù)計的目標(biāo)。

• 統(tǒng)計花了多少時間與成本。

• 將上述資料整理分析，累積增長經(jīng)驗，使日后評估更精確。

• 評估的方法有很多，經(jīng)驗累積后，才能找出最適合的法則。

此階段主要活動為：

1. 完成任務(wù)

2. 審查結(jié)果

3. 移轉(zhuǎn)責(zé)任

4. 結(jié)案報告

5. 經(jīng)驗學(xué)習(xí)

6. 解編歸建

專案都會分階段執(zhí)行，完成第一階段再進行第二階段，以此類推直到完成。分階段的意義在于，如果在每個階段進行過程中，遇到最壞的狀況或無法解決的問題，都可以有喊停的機會，不致于一直錯下去，到無法挽回的地步。

軟件生命周期模型
軟件開發(fā)工程師必須組合出一個包含過程、方法及工具層次的開發(fā)策略。這樣的策略經(jīng)常被稱為軟體發(fā)展生命周期模型(Software Development Life Cycle Model，SDLC)。
軟件開發(fā)程序(Software Development Procedure)或稱為軟體工程規(guī)范(Software Engineering Paradigm)，在IEEE/EIA 12207與J-STD-016有詳盡的說明。
軟件發(fā)展生命周期模型主要描述或定義軟體開發(fā)的步驟階段，提供開發(fā)者一個系統(tǒng)性的流程，以成功地開發(fā)使用者所需要的軟件。這次為大家介紹七種模型：

1. 瀑布式
發(fā)展階段一段一段往下推，一定要一個階段作完才能往下做，無法平行，因此要準(zhǔn)備的文件相當(dāng)多，不適于小型專案開發(fā)。

• 1970年美國為了國防及航太計畫所產(chǎn)生的模型。

• 安全的軟件開發(fā)方式。

• 要求許多準(zhǔn)備文件。

• 較易維護也易于管理。

• 所需開發(fā)的時間較長。

• 若產(chǎn)品需求稍做更動，會導(dǎo)致后面階段也要進行更改。

• 適合大型專案開發(fā)。

2. 漸進式
特點：第一階段產(chǎn)生的結(jié)果是第二階段的需求。
每個階段的產(chǎn)出都是產(chǎn)品，所以每個階段產(chǎn)出都非常明顯，但完成的產(chǎn)品會一直因為上一階段的產(chǎn)出而有所變動。

• 將開發(fā)流程分為許多小型瀑布開發(fā)模式。

• 減少產(chǎn)品需求更動的影響。

• 開發(fā)成果較易顯現(xiàn)。

• 可在不同的建構(gòu)版本(Build)中決定產(chǎn)品開發(fā)是否繼續(xù)。
  　

3. V型
每個階段都有對等的關(guān)系，從當(dāng)初的設(shè)計、開發(fā)、架構(gòu)…等，都會對應(yīng)到一個方法來驗證。

• 改良自傳統(tǒng)瀑布式。

• 對品管是最有助益的方式。

• 確保所開發(fā)的產(chǎn)品符合設(shè)計規(guī)格。

• 承襲傳統(tǒng)瀑布式缺點，需求更動即造成后續(xù)影響。

4. 原型快速開發(fā)
與瀑布式近似，但每個階段都有強烈的回饋(feedback)，瀑布式與其不同在于它是很嚴謹?shù)逆i住每個階段。

• 軟件需求上的溝通確認較容易。

• 較適合專業(yè)開發(fā)模式。
  　

5. 螺旋型
將瀑布模型的最終結(jié)果導(dǎo)回源頭，成為一個往復(fù)式的圓圈，使整個流程具備回饋與檢驗機制，這就是螺旋模型(Boehm，1988)。
改善傳統(tǒng)瀑布式的需求更動影響缺點，結(jié)合風(fēng)險管理與原型快速發(fā)展的觀念。

• 將開發(fā)目標(biāo)、替代方案、限制的項目列出。

• 分析是否有其他方法，同時找出存在風(fēng)險并加以解決。

• 進行開發(fā)、測試、審查的步驟。

• 進行下一個階段的計畫。
  　

6. 極限型
適合Web應(yīng)用方案，不適用大型專案(因大型專案在模型圖中會有很多箭頭進出)，這也是個強調(diào)回饋的模型，若采用此方式會造成需求不停變動，大型專案要一開始就清楚明確定義出需求，確定后就不宜更改。

Kent Beck 于1996年提出的理論，具有下列特點：

• 溝通(Communication)

• 簡潔(Simplicity)

• 回饋(Feedback)

• 勇氣(Courage)

注意事項：此模型并未要求準(zhǔn)備詳細的文件，對于專案開發(fā)而言是很難接受這樣的開發(fā)模式。

7. RUP
軟件工程在近代最有名且使用在物件導(dǎo)向是Rational統(tǒng)一流程(Rational Unified Process，簡稱RUP)。由Rational 公司發(fā)展，現(xiàn)已被IBM公司并購，有三大特點、四個階段和九個核心流程。
三大特點為：

1. 軟件開發(fā)是一個疊代(Iteration)過程。

2. 軟件開發(fā)是由使用案例(Use Case)驅(qū)動。

3. 軟件開發(fā)是以構(gòu)架設(shè)計(Architectural Design)為中心。

采瀑布式改良過的階段開發(fā)流程：

1. 起始階段(Initial phase)：進行可行性研究，定義專案大小及涵蓋范圍，評估專案所需的能力、時程與經(jīng)費，及資訊系統(tǒng)預(yù)期達到之效益，了解商業(yè)模型及需求。

2. 精細規(guī)劃階段(Elaboration phase)：擬定專案計畫、系統(tǒng)特性與架構(gòu)?確認商業(yè)模型及需求，進行系統(tǒng)分析與設(shè)計。

3. 建構(gòu)階段(Construction phase)：建構(gòu)產(chǎn)品并進行單元、整合測試。

4. 移轉(zhuǎn)階段(Transition phase)：將產(chǎn)品分批交付給客戶驗收測試，并進行使用者訓(xùn)練。

現(xiàn)實環(huán)境的軟體開發(fā)模式

1. 由上而下的方式(Top-Down Apporach)
   此方式也稱為架構(gòu)式開發(fā)，使用開放的架構(gòu)思考，將產(chǎn)品的需求列出，利用WBS(Work Breakdown Structure)的方法將各個需求分散成為不同的功能，每個功能再細分為規(guī)格。這種方式開發(fā)出的產(chǎn)品在延展性及穩(wěn)定度較佳，但相對所需的開發(fā)時程和準(zhǔn)備功夫也較長。

2. 由下而上的方式(Bottom-Up Approach)
   通常使用這種方式是基于市場競爭考量，此法亦稱為組合式開發(fā)，所采用的方式就是以目前所擁有的資源及技術(shù)進行快速組合成為產(chǎn)品。這種開發(fā)模式雖快速但他不是基于一個架構(gòu)性的思考，因此所開發(fā)的產(chǎn)品在延展性及穩(wěn)定度較差，而且產(chǎn)品需求是經(jīng)由組合方式產(chǎn)生的，所以部份需求會與使用者的實際需求有所差異，當(dāng)然伴隨而來的是教育使用者的額外費用。

結(jié)語
上述對各種不同軟體開發(fā)流程做簡略的介紹說明，但大多數(shù)都是以傳統(tǒng)瀑布式為主軸，并加以改良。但就軟體產(chǎn)品的組成觀點來看，其實只有兩種方式：
1. 架構(gòu)式開發(fā)
2. 組合式開發(fā)
無論選擇哪種模式，在開發(fā)過程中，都必須設(shè)立不同的里程碑，或是檢查點；例如像Pre Alpha、Alpha…等的名稱都是流程中的里程碑。在每個里程碑時最好用REDC(Review、Evaluate、Discussion、Conclusion)方法來檢查目前的進度，再進行下一階段的開發(fā)流程。
軟件開發(fā)在現(xiàn)實生活中困難重重，建議先建構(gòu)基礎(chǔ)的軟件開發(fā)模型，再進行較大范圍的系統(tǒng)開發(fā)。若是開發(fā)人數(shù)較少的團隊，不建議開發(fā)Multi-Domain、Multi-Language、Multi-Skill、Multi-Model的軟件，這樣只會增加團隊執(zhí)行上的困難度。