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