軟體開發模型
軟體從1940年開始發展，1960年開始提出許多軟體開發的方法，而這些方法直到現在都深深影響著所有的開發人員。
一、軟體開發的困境
在領域驅動設計中，描述了如何將複雜的系統逐步地拆解，並且讓開發團隊可以在開發的過程中，不斷地與領域專家對焦。在2003年的時空背景下，許多軟體開發團隊都是採用瀑布式(Waterfall)的開發流程，許多工具和方法論都是圍繞著最根本的模型驅動開發進行著。
軟體的顧客通常會認為，軟體應該是很容易被修改的，但是很可惜的是，軟體並不那麼容易修改，特別是軟體的開發週期越是逼近預定地交付日期(Deadline)，並且已經有較高比例的開發完成度，此時，對於系統修改的成本就會變得極高。
每一位開發人員都發現到一個事實-當我們被交付日期逼得需要以加班作為我們趕上進度的手段時，內心都會暗暗悔恨：「這段程式碼在之前設計的時候，怎麼沒有好好設計?」等到完成整個專案之後，回頭省思整個開發歷程，會發現到其實自己當時設計的時候，並不知道需求會這麼變化，以致於當時設計的時候沒有思考到會需要調整的幅度這麼大。
那麼，開發人員該怎麼避免掉上述的悲劇呢?
需要修正對於軟體開發的概念 – “需求能在一開始就被釐清”。任何人都無法準確無誤地描述自己的需求，這是因為人們知道自己不要什麼，對於自己需要什麼，僅有模糊的認知；在與需求訪談人員對談的過程中，有可能會趨向配合訪談人員的進行而回答了自己其實也不是那麼認可的答案。這種種的一切，都會是阻礙了需求的傳達。
我們來舉一個例子：這世界最快的交通工具是什麼？
每個人對於這個問題都會自己心中的答案，而這個答案會和其人生經歷有關，對於長期居住在較為偏遠的深山中，那麼可能會回答：「纜車」；而居住在都市的人們，可能會回答出：「高速鐵路」。由上面的例子可以得知，人生經歷會大幅度影響問題的答案。那麼，需求訪談人員有辦法找到真正的答案嗎？很遺憾，需求訪談人員也不可能知道。
承認需求無法在一開始就能夠釐清，並且團隊能夠在開發的過程中，逐步理解顧客的需求。
二、軟體開發方法的變化
從本文上一章節中可以看到瀑布式開發，而瀑布式在早期的確是一種非常知名且行之有年的開發流程。但是隨著軟體的發展越來越蓬勃，使用者的需求不太可能再是簡單的小工具，而是希望軟體能夠提供更多的價值，因此，軟體的複雜度也隨之不斷提高。
從上圖1中可以看到，從1981年開始，程式碼的行數已經不斷地暴增，未來，將會更快的增加而不會有所趨緩，原因就如同本文上一段所描述的。那麼，軟體開發人員要如何因應這個趨勢呢？
我們已經知道需求已經無法在初期就被釐清，是否可以每隔一段時間就調整一次，讓軟體系統能夠跟上顧客的需求變化？如果軟體開發團隊將軟體開發的時間以邏輯切割的方式分拆分成多個區段，在每個區段，團隊都會和顧客確認需求，並且將更新的需求實現到軟體系統中，當然，調整程式碼是難免的，不過，團隊每一次的程式碼調整都能夠讓軟體更加貼近顧客真正的需求。
由此可知，軟體開發的方法是需要不斷地變革，那麼，軟體開發方法變革的歷程是什麼？以及我們如何從變革的趨勢中得到什麼樣的洞見？如果你也對這個議題感興趣，就請繼續閱讀下去吧。
三、軟體開發模型-瀑布式
軟體開發模型(Software Process Model) 從軟體業發展的1940開始直到1960的60年代，許多軟體開發的先驅們陸續提出各種可用的軟體開發模型。
知名的瀑布式開發其發表時間約莫是1970年，發表者則是
Winston W. Royce。瀑布式是最早強調軟體/系統開發時，應該要有完整的週期，並且必須完整地經歷週期的每一個開發階段，需要系統化的考量分析與設計的技術、時間與資源之投入等等。由於該模式強調系統開發過程需要有完整的規劃、分析、設計、測試以及檔案等管理與控制，因此，能有效地確保系統的品質。不過當初Royce提出這個開發流程模型的時候，他沒有使用瀑布式這個名詞，這個名詞反倒是後人在討論中方便描述而取的名字。(參考:Wiki)
如上圖2所示，開發中的每一個階段都是接續在上一個階段的完成之後。而這種開發模式會造成無法適應需求的變化，但是否每一個專案都會有大量的需求變化呢？事實是，某些專案的需求和目標是極度明確的，採用瀑布式開發能夠讓專案的進行變得更加順暢。
其實，Royce也知道圖2中的瀑布式開發模型太過理想化了，因此，他基於瀑布式提出更貼近實務的開發模型，其新版本的模型如下圖4所示。
當團隊發現到開發的系統有缺陷時，需要回到上面的階段進行重新調整。如上圖3看到的兩個線條較粗帶有箭頭的線條；一條是從程式設計(Program Design) 回到軟體需求(Software Requirement)；另一條則是從測試(Testing) 回到程式設計。Royce這次的改善帶來了很好的概念，只是很可惜這個概念是附加在瀑布式模型上。為什麼覺得可惜呢？因為瀑布式模型最大的成本就是回到前面的階段，每一個階段團隊都要花費巨大的成本和心力，返回到某個階段，意味著專案的成本將會大幅增加。
這個問題在 Steve McConnell 所提出的：瀑布式與鮭魚生命週期比較(Comparison of the waterfall model and the lifecycle of salmon)中，我們可以發現到有異曲同工之妙。
對於世界的改善，人們總是不遺餘力。繼 Steve McConnell 對於瀑布式的嘲諷之後，Peter DeGrace 提出了生魚片型瀑布式開發方法(Sashimi waterfall model)，其概念圖如下圖4所示：
生魚片型瀑布式，如果只是看名字，就可以知道搞Kuso這件事情不是新世代人們的行為，早期就有一堆前輩們搞得不亦樂乎。名字雖然看起來很惡搞，但是其概念可不簡單，甚至深深地影響到後續湧上的軟體開發方法論。
在生魚片型瀑布式中，最關鍵的概念就是：「每一個階段在進行的過程中，後面某些階段已經可以提前開始了，階段彼此之間會有時間上的重疊」。而這個概念催生了後續的許多開發方法論。生魚片型雖然改善了原本瀑布式大量文件的問題(注：瀑布式每一個階段的交接，都是透過大量的文件)，但是它也產生了一個問題：沒有里程碑。如果沒有里程碑會有什麼問題？專案的進度和狀況將會無法被監督，團隊中沒有人知道專案目前的進度到了哪裡。
瀑布式是循序的，如果加上迭代這個要素呢？
四、軟體開發模型-基於迭代的方法論
第一個符合且登場的就是 Frederick Phillips Brooks Jr 所提出的–雛形法(Prototype model)。這個方法的基本概念就如同它的名字，團隊先專注於開發出一個系統的雛形，並且與顧客對焦和確認這個雛形是否有符合或是滿足顧客的需求。如果這個雛形已經符合了顧客的需求，那麼開發就可以到此為止；否則，團隊將持續調整和修改這個雛形，直到符合顧客的需要。如下圖5所示：
乍看之下，雛形法非常的經濟，團隊只需要開發出足夠適合的系統就好，不會有太多的浪費。事實上，軟體開發沒有這麼單純，使用者永遠說不清楚自己的需求是什麼，他們只會挑剔這個雛形的問題，而無法準確說出自己到底要什麼，並且，採用這個模式是很難進行專案成本的評估。
1988年 Barry W. Boehm 提出了一個新的模型–螺旋模型(Spiral Model)。這個模型提出的時間很特別，1980年代是物件導向開發(Object-Oriented Development) 蓬勃發展的年代，許多物件導向程式語言都證明了採用物件導向的優勢，因此，結構化開發(Structure Development) 開始淡出，雖然這個現象並不是螺旋模型的提出而造成的，但是螺旋模型提出的時機點實在是太恰好了，難免讓人將兩者連結在一起。
螺旋模型是立基於雛形法之上；在每一次循環的開發活動開始之前，會先設定好目標，並且進行風險分析，如果分析的結果是負面的，那麼本次的開發會視情況終止或是提出因應之道。這個做法的好處是每一次開發都有著事先的計畫，並且每一次都會讓顧客參與，顧客會一直了解每一次開發的狀況。其概念如下圖所示：
通常優點也會是弱點。螺旋模型最大的優點就是會在開發活動開始之前進行風險分析，這也造成團隊是仰賴分析的結果來做出決策，如果風險分析有誤呢？
物件導向開發的崛起讓整個軟體開發產業有著很大的衝擊，因為物件導向開發期盼的是將領域問題進行分解，而不是針對解決方案，而這種思考模式的典範轉移，也開始影響了軟體開發流程。
1996年 Ivar Jacobson, Grady Booch 和 James Rumbaugh 提出了統一軟體開發過程(Rational Unified Process, RUP)。我們可將RUP以二維的角度來理解它：時間、內容。
在時間維度上，被分拆成四個階段：初始(Inception)、發展(Elaboration)、建構(Construction)和交付(Transition)。
內容則是要先將其分成兩大類：核心、輔助；在核心類中，具有六個活動：商業塑模(Business Modeling)、需求(Requirements)、分析/設計(Analysis & Design)、實現(Implementation)、測試(Test)和部署(Deplyment)。
在內容維度的輔助類中，具有三個活動：組態和變更管理(Configuration & Change Management)、專案管理(Project Management)和環境(Environment)。內容維度中的每一個活動會在不同的時間階段中，有著不同的活動量，詳見下圖：
看上圖7能夠理解RUP的總體概念，不過，下圖8會讓人更有感覺，畢竟它和大家日常生活中的開發更貼近。
將一個開發階段視為：商業塑模、需求、分析/設計、測試和部署。由於每個專案的時間點，每一個開發階段中的活動參與的程度不同，因此，如圖8中下方所描述的那樣，每次的循環開發活動的顏色填滿程度有著顯著的差異。
RUP實質上是一個開發流程的框架，很多部分它並沒有太過細節的描述，開發團隊需要藉由其它方法論來補其缺漏的部分。
另一個有趣且也添加迭代概念的軟體開發流程則是由微軟提出的- 微軟解決方案框架模型(Microsoft Solution Framework Model,MSF)。這個開發方法直到2004才為人所知，而且是微軟自己公布在自己的網站上的。MSF結合了瀑布式與螺旋模型的長處，並且強化里程碑的概念。MSF分成五個階段：設想(Envision)、計畫(Planning)、開發(Developing)、穩定(Stabilizing) 和部署(Deployment)。每一個階段的啟動都是上一個階段的完成，這一點與瀑布式的概念是一致的。
微軟的每一個產品都會區分出多個版本：Alpha、Beta、Release、RTM。每一個產品都釋出都是可用的版本，每一個版本都會經歷上述的五個階段，並且都具有商業價值。如下圖所示：
20世紀後，技術和需求開始快速成長與變化，這造成軟體業界很大的震盪，原先的方法論和手段開始難以符合時代，時程和預算屢屢失敗，這個時候，軟體業需要一個新的方法。
五、軟體開發模型-敏捷開發
先來說說敏捷開發的特性：減少每一位參與開發的人，其資訊交流的成本和時間。敏捷除了創造了改變，它也能夠回應改變。也就是這個特質，讓它的特性得以變得可能。
敏捷開發本質是一個–參與者為中心。每一位參與者在團隊中都共享同一個目標，並且可以在任一個時間點調整自己的組織，不過團隊成員人數的上限目前建議是9人。
敏捷開發有以下各種模型：
- 極限開發(Extreme Programming,XP)
- 可適應性軟體開發(Adaptive Software Development,ASD)
- 動態系統開發方法(Dynamic Systems Development Method,DSDM)
- Scrum
- 特徵驅動開發(Feature Driven Development,FDD)
- 敏捷塑模(Agile Modeling,AM)
雖然上述的幾種都是敏捷開發，但是在實現上還是有著很大的差異。敏捷開發應該已經是目前的顯學了，很多軟體公司基本上都知道可以採用這個方法來應對改變。不過更多的公司是喜歡依照它的名字來惡搞；既然是叫做敏捷，那就是可以塞很多需求，並且可以很快的產出囉？
採用敏捷開發的確會讓團隊變得更能夠面對改變，但是最根本的是它提供一個概念給開發團隊，並不是像RUP有配套一些工具給團隊使用，團隊需要自己找出合適自己團隊的工具和實際應對改變的策略。這樣看起來，敏捷開發好像有提供些什麼，又好像什麼都沒有提供。確實，如果團隊只是溺水後想要找到一根浮木，那麼敏捷開發可以讓你失望透頂。
團隊是否已經有心理準備不再有標準答案？是否已經具有不斷調整的覺悟？
如果團隊只是需要一個工具來解決自己的特定問題，那麼就只是需要找到一個好工具或是一個好顧問。決定採用敏捷開發之前，要關注的是自己團隊的狀態，而不是跟上流行強行套用敏捷開發。
五、結語
從1970的瀑布式開始，一直到近代的敏捷開發，這段的變化主要來自於技術和人們需求的激烈變化。過去可以使用瀑布式這類有著明確的操作步驟，隨著時代的前進，越來越沒有標準答案可以套用，看起來未來也會越來越趨向未知(Uncentainty)，這似乎預示軟體產業的未來是否也會隨之變得無法掌握？
其實狀況沒有想像的那麼糟糕，軟體開發方法的變革不是變得越來越未知，而是經過驗證之後不斷精煉和總結出各種法則(Rule)。開發人員依然是可以依照專案和團隊的現況選擇和調整開發方法，甚至是取各家的長處淬鍊出團隊覺得舒服，且能夠增進商業價值的開發方法。
從趨勢來看，軟體產業一直沒有改變的是共享和共學的心態，許多前輩們都不吝嗇地提供自己的經驗和想法給後人參考，本篇文章中看起來瀑布式是眾矢之的，但是瀑布式真的無法應用在現代軟體開發上嗎？其實是可以的，只要你的專案規模不大，複雜度不高，並且有著明確的目的，這讓你想到什麼類型的專案呢？我想到一個：Side Project。
軟體產業未來依然誘人，因為我們可以站在巨人的肩膀上，創造出各種產品讓生活變得更好。
