CIYAWASAY

此篇為我這學期高等軟體工程的期末報告，內容為軟體開發流程的研究 (pdf)

---

好方法；壞方法

軟體開發是怎麼一回事？

如果我們想開發一個軟體，到底應該要怎麼做呢？書籍上告訴我們要先去做需求的蒐集，再去分析這些需求，建立軟體的架構，經過高階與細部的設計後，用程式語言去把它實作出來，通過測試之後就可以去部署來使用了。

但是真的每個軟體都這樣子搞的嗎？開發一個小畫家跟開發一套PhotoShop的開發流程在這其中的每個過程中都應該是差異很大的吧。尤其是現在的軟體形形色色，每天在用的作業系統、瀏覽器、MSN、多媒體程式是軟體，你開一個網頁，網頁中的Flash、Javascript是跑在你這個客戶端瀏覽器上的軟體，而你連過去的伺服端也要跑一些伺服器、網站應用程式、資料庫等軟體。不說電腦，你的手機、iPod、電子錶、健保卡裡面都有軟體。這些軟體有大有小，功能也是變化萬千，怎麼樣去開發它們自然也會是不一樣的。

硬體科技進步神速，電腦與行動科技越來越普及化，也因為網路的興起，全球化的現象日益顯著。為了讓這些硬體發揮其最大的效益，軟體的功能需要更多的創新、更強大的功能、能夠帶來更大的商機。在這同時也讓軟體開發的規模越來越大，越來越複雜、也越來越令軟體開發人員頭痛了。

我們有什麼方法能選擇？

軟體開發除了追求其正確性、使用效能、穩定性、安全性之外，還要考慮到軟體開發的速度、重用性、可維護性、整合性、管理性等。

所以我們要進行軟體開發，就必須要有軟體開發的流程。這流程能夠把跟此專案有關的利害關係人（像是專案經理、架構師、設計師、開發人員、管理人員及客戶等等），加上使用相關設備與財物組織起來，以某種形式的組織架構、程序、方法論、技術與管理控制方法，投入於特定領域的軟體生產工作。

說到流程，就會很直覺地想到常常拿出來被人家詬病的瀑布式（waterfall）流程、還有當紅敏捷（agile）陣營的eXtreme Programming（XP）與物件導向大師們所發展出來的Rational Unified Process（RUP）。

瀑布式流程

瀑布式流程並不適用於大多數的軟體開發早已不是新聞，它的存在可能只是為了提供某一個負面名詞來讓人使用。因為軟體界有一句真理名言叫做：「永遠不變的就是一定會變」，現在的世界變化太快了，想當然軟體變化地會更快，畢竟抹平世界的十大推土機裡面每台都是跟資訊科技有關的技術。變化是我們沒有辦法去預測的，所以我們不能用瀑布式這種一去不回的開發流程，而要改用迭代式的開發流程，用短周期進行開發，才能去適應不同的變化。

RUP

RUP是一種流程架構，它主要是用來作為一個與UML相互配合的流程，在這個架構底下你要使用笨重的或是敏捷的流程都可以。它有初始（inception）、詳述（elaboration）、建構（construction）、轉換（transition）四個階段，還有邏輯（logical）、實作（implementation）、程序（process）、配置（deployment）、使用案例（use case）這4+1個觀點。

敏捷開發流程

敏捷型的開發流程有相當多種，其中包括最引人矚目的XP，還有水晶（Crystal）方法系列、適應性軟體開發方法（Adaptive Software Development，ASD）、SCRUM、功用驅動開發方法（Feature Driven Development，FDD）、動態系統開發方法（Dynamic System Development Methods，DSDM）等等。雖然有這麼多種敏捷方法，但它們都共同具有下列的核心價值觀：

• 個人及互動勝於流程與工具
• 可用的軟體勝於詳盡的文件
• 與客戶合作勝於合約談判
• 回應變化勝於墨守計畫

我們可以看出敏捷開發的著重點是擺在適應性與以人為主的理念上的，但我認為要應用敏捷型的開發流程，不僅僅是要知道它與其它流程的異同而已，最基本的原則、樣式、還有它專有的實務都是非常重要，缺一不可。

如何設計？

軟體開發最大的問題就在於一切都是設計過程的一部份，寫程式是一部份，測試與除錯也是，一般大家所說的軟體設計也還是設計的一部份。

現在是物件導向的時代，所以物件導向的基本原則就是軟體設計上的考量要點。有學過物件導向的人都知道，物件導向包含了封裝、繼承、多型、以訊息傳遞等等的要素。但是要如何應用這些要素來將物件導向的特點發揮到淋漓盡致就是要靠這些設計原則【見附錄A：物件導向設計原則】了。

而設計模式（design pattern）也就是運用了這些物件導向設計原則所形成的。但是目前在不同領域的設計模式越來越多，除了四人幫的23個設計模式之外，大型的企業級架構像是J2EE都有自己的一堆設計模式，甚至還有許多反模式（anti-pattern）的出現。

其實運用設計模式也不完全都是優點，引進設計模式到軟體設計中會造成架構的複雜化，反而失去了簡單性的優點，所以說不要強把設計模式加到自己的系統中，最好是讓它們在系統演進的過程中自然顯現出來比較好。

如何極致？

XP是敏捷開發流程中最受到大家所重視的，原因在於推廣XP理念的人物都是當代軟體業舉足輕重的大師級人物，像是Kent Beck、Martin Fowler等等。

XP本身不但提供了一套流程，其主要的價值觀包括了：

• 溝通（communication）
• 回饋（feedback）
• 簡單性（simplicity）
• 勇氣（courage）

也包含了一些編程實務、開發者實務、事務實務【見附錄B：XP實務】。

搞得好？搞不好？

團隊的大小會影響應該使用的開發流程，每種流程都會有其侷限性，像是XP就明白地表示其適用在十人以下的專案中，如果開發團隊有一百人，完全採用XP是不適合的，必定要去做一些調整。

我認為在應用任何一種開發流程之前，都需要先藉由一些較為小型、容易的專案開始練習，或是先由專家來帶領整個團隊進行開發。沒有經驗的管理者、開發者若只是隨便買本書、看看網站上的說明，沒有經過使用該流程的專業訓練，就照本宣科，感覺上好像真的採用該流程，但是骨子裡可能就不是那麼一回事了。

拿測試驅動式開發方法來說好了，它主要的規定有三：

• 只有在單元測試失敗後，才能寫實際程式。
• 單元測試如果已經寫到讓實際程式不能通過，就不能再寫單元測試。
• 若實際程式已通過單元測試，就不能寫實際程式。

我看過Kent Beck所寫的那本Test-Driven Development By Example，裡面的第一章就是他舉一個實際運用測試驅動式開發方法的範例，雖然說他是遵守了一些看似簡單的規定來進行程式編寫，但老實說一般人如果沒有學習過相關的知識、沒有去習慣此種開發方式，是不太可能會這樣子去寫程式的。

況且許多的實務都是需要相互配合才能算是正確、有效的使用。就像測試驅動開發也必須配合重構的手法才不會讓程式的架構崩潰。是不是每個人都會使用重構呢？要聞出程式碼的壞味道就已經不是很容易了，重構手法林林總總那麼多項，更何況要應用它們來把程式原本不好的架構重構到好的架構。況且重構不太可能手動去進行，一定要搭配一個好的、容易使用的、方便的整合開發環境才有辦法，所以說開發者還必須要熟悉所有他們會使用到的工具。必須要的工具像是單元測試的架構（JUnit）、整合開發環境（Eclipse、JBuilder…）、版本控管軟體（CVS、Subversion）、建構的工具（Ant、Make…）等等，如此高的門檻可能不是一般人能夠輕易跨過的。

所以說XP是非常重視經驗的，另外如果開發人員沒有一種對於軟體開發設計的狂熱，很可能就沒有辦法應用XP，原因在於並非每個人都熱衷於實踐XP的實務。像是有人喜歡搞孤僻、或是喜歡混水摸魚，他就不太可能喜歡搭檔編程。又或是兩個人的程式設計能力相差太大，高手寫的程式另外一個新手看不懂，那麼高手是要跟新手有耐心地講解還是就不理會新手自己寫呢？

UML有幫助嗎？

目前UML已成為軟體設計過程中主要的塑模工具，每個開發流程都會需要使用到它，但這不代表UML是一個很完美的表示方法，軟體系統中的各個元件、行為、還有它們彼此間互動的關係，很難只用幾張圖就表達了一切。現在有一種模型驅動架構（Model-Driven Architecture）的技術，就是想要讓開發者在設計完一些鉅細靡遺的架構圖後，整個系統就差不多出來了。這是一個不錯的理想，不過可行性卻還是讓很多人懷疑。

目前UML的版本已經到了2.0，總計有13種圖。但是基本上沒有什麼人會想要把所有的規格都弄清楚，即使真的有人畫了一張包含了全部細節的圖，也不會有人想要去看。這也是為什麼在所有單純針對UML所寫的書裡面，賣得最好的是Martin Fowler所寫不到兩百頁的UML Distilled，而不是那些厚厚的UML規格書。並不是每個流程都很需要大量的文件，像是XP就不會，所以說如果要使用UML，不一定要使用完整的UML，而是採用需要的部份就好。

結論

沒有什麼方法是絕對好的或是絕對壞的，一切都要針對個別團隊、專案開發的需求去調適。有許多使用XP、RUP這類熱門流程的專案失敗了，但也有使用瀑布式開發而成功的例子。微軟是全世界最大的軟體公司，他們所使用的開發流程是他們自己根據經驗弄出來的MSF（Microsoft Solutions Framework）開發流程，還是需要在一開始根據專案的種類、人員的多寡來進行調適的。

所以我們可以發現這些流程之間都會有一些異同點，沒有任何一種在所有的情形下都是最好的，能讓專案成功的方法就是好方法。

附錄A：物件導向設計原則

應用於類別設計的原則：

• 單一職責原則（Single Responsibility Principle，SRP）
  類別變更的原因應僅只有一種。
• 開放封閉原則（Open Closed Principle，OCP）
  軟體實體（如類別、模組、函式等等）對於擴充應保持開放性，而對修改應維持封閉性。
• Liskov替代原則（Liskov Substitution Principle，LSP）
  子型別必需可替換父型別。
• 相依性反向原則（Dependency Inversion Principle，DIP）
  抽象概念不應該相依於細節；而細節應該相依於抽象概念。
• 介面分割原則（Interface Segregation Principle，ISP）
  用戶不應被迫相依於他們用不到的函式，介面隸屬於客戶，而非遷就於繼承階層。

應用於套件內聚力的原則：

• 復用改版同等原則（Release Reuse Equivalency Principle，REP）
  復用的單元相等於版本的單元。
• 共同封閉原則（Common Closure Principle，CCP）
  套件內的所有類別對同類的變更具有相同的封閉性，也就是對套件造成影響的變更會影響套件中的所有類別，然而不會影響其他的套件。
• 共同復用原則（Common Reuse Principle，CRP）
  套件內的所有類別總是一起被復用，如果你復用了套件中的某個類別，就等於是復用了所有類別。

應用於套件耦合度的原則：

• 無循環相依原則（Acyclic Dependencies Principle，ADP）
  套件的相依關係圖中不存在任何循環路徑。
• 穩定相依原則（Stable Dependencies Principle，SDP）
  以穩定取決相依的方向。
• 穩定抽象原則（Stable Abstractions Principle，SAP）
  套件應該既抽象又穩定。

附錄B：XP實務

• 整體團隊
  XP專案的所有貢獻者，包括開發人員、業務分析師、測試人員等等，都是團隊的成員，一同在開放的空間裡工作，大幅而明顯可見的圖表及其他表示了專案進度的証明，散亂地貼在牆壁上。
• 規劃遊戲
  規劃是不斷持續而漸進的工作，以兩週為週期，針對未來兩週內，開發人員預估候選功能的開發成本，而客戶以開發成本與業務價值為考量，從這些需求中挑選出將被實作的功能。
• 客戶測試
  除了挑選要實作的功能，客戶也針對每個被挑選出來的功能，定義自動化的驗收來證明這些功能是可運作的。
• 簡單設計
  開發團隊維持系統的設計恰恰滿足系統目前所需具備的功能，讓這個設計成果順利通過所有的測試、沒有任何重複、充分表達設計者所展現的所有概念，而且包含的程式碼越少越好。
• 搭檔編程
  所有軟體產出皆由兩位程式員共同建構，兩人比肩而坐，共用一部電腦。
• 測試驅動式開發方法
  程式員在很短的開發週期中，先加入系統缺失的測試，然後再想辦法讓它能正常運作。
• 設計改良
  不要讓系統毀於劣質的程式碼，盡量保持程式碼既簡潔又清晰明確。
• 持續整合
  開發團隊隨時對系統做全面性的整合。
• 程式共享
  任何的編程搭檔都可在任意時刻著手改善任何的程式碼。
• 編程標準
  系統中所有程式碼看起來就像出自同一個優秀的程式員之手。
• 隱喻
  團隊勾勒出程式當如何運作的共同願景。
• 持久穩定的步調
  團隊是為長久運作的。成員們努力工作，用可持續不斷的步調，以跑馬拉松而非短程衝刺的心態來對待專案，使自己能保存活力。

我從國小就常常自己一個人跑到光華商場逛
小時候很愛玩電腦遊戲
這裡對我來說簡直就是個天堂
最新的遊戲總是會最先在這裡開始賣
最新的雜誌也能很快在這裡買到
八德路上還有一家叫「熱血少年」的中古買賣店
更是我經常去尋寶的地方
我也去賣過一些遊戲(雖然賣到的錢都很少...)

光華商場的特產就是大補帖
這在我國中國小那段時間更是熱門
一片650MB的光碟總是能塞下市價不知道多少錢的最新熱門軟體
管你用的到用不到
有了一片大補帖
你的電腦就不怕要燒錄沒燒錄、要防毒沒防毒、要影像處理沒影像處理、要文書編輯沒文書編輯了

也記得當時這些補帖商
只要有人從目錄上看到要的
他們就會以十分純熟的技術把那些依照標籤分類好的光碟從一些讓你異想不到的地方拿出來
像是商場裡面的飲料販賣機下面、旁邊不起眼的紙箱裡面等等
不過有些大補帖真的太補了
裡面被放了一堆病毒
也讓大家的重灌經驗相當地豐富

後來因為軟體、遊戲的資料量越來越大
一片大補帖很難裝得下
而且網路也發達了
P2P軟體就是大家的大補帖
販賣大補帖這種行業在光華商場也早消失了
現在賣的好像都是A片之類的東西...

光華商場即將要爆炸拆除
昨天也看到很多像我一樣去拍個幾張照片留念的
商場樓上左邊第一家的報價單
不理會旁邊有警察依然會叫你買無碼A片的青少年
樓下舊書攤一疊疊老舊到沒什麼人要買的書籍與光碟牆上18禁影片的強烈對比
狹窄的通道、擁擠的人潮、怪異的氣味
都要在一瞬間灰飛煙滅成為歷史與回憶了

雖然舊的商場就要消失
附近的光華商圈依然是購買資訊產品的首選
還是期待重建以後能夠有更好、更漂亮的環境 :)

swanky-巨蟹座(6.22-7.22)

2006年是巨蟹座奮發圖強，贏得成就的一年。

整體運：☆☆☆☆☆

巨蟹座2006年運勢很旺，有強大的外力支持，使你各方面都很順利。然而，由於「定之克羅諾斯」和「魅之巫肯那斯」，以及玄秘之星「艾希絲」同時在你的星宮內，讓你的心思繁瑣、性情不定，但是對實際面的妨礙並不大。因為木星的扶持，以及天王星遙遙相拱，形成金三角的助力，巨蟹座運勢上揚，應該算是最幸運的星座吧，只要你能定下心來集中精神，好好把握住大好時機，就能夠達成許多目標和成就！

功課學業運：☆☆☆☆

你的課業狀況將莫名其妙地好起來，2006年巨蟹座的好運，大部分呈現在這些方面。在學成績傑出，或者考試上榜順利升學，或者論文過關，或者出國有成。這些都可能有快速進展，要趕緊配合時機，趁現在完成這些課題吧。

工作職場運：☆☆☆☆

這一年巨蟹座生活多采多姿，工作上也是閒不下來的。有很多事情會找上門來，是有利的CASE那就非常好，雖然也有一些勞煩你的事推托不掉，但也能幫你增添人脈。令人安心的是，許多事務的進行都很順暢，能夠完滿地達成。

金錢理財運：☆☆☆

巨蟹座2006年的財運並不平穩，有沒有錢不是問題，是你有很多要忙的事情分心，更主要的問題是會很勞累。而且被火星干擾，會有破費的傾向，在理財規劃上，常見準備不及的現象，且缺乏因應措施，容易混亂或拖延。這些現象都造成財運的美中不足，但收入來源都沒有大問題，整體還算過得去。

戀愛婚姻運：☆☆☆☆

巨蟹座這一年運勢很旺，而這些好運可以說主要集中在愛情方面，所以如果錯過了的話，就比較感受不到這些好運了。可能會有突如其來的驚喜，無論是事件或人物的出現。

有伴侶的你：兩人關係持續熱烈或親密，也很有可能邁向新的階段，良好的互動使彼此都很愉快。

單身的你：也有不錯的對象會自動出現，只看你自己的感覺，對宮的智神星會幫助你如何挑選，要怎麼取捨，控制權在你這一方喔！

---

shumi-水瓶座(1.21-2.19)

2006年是水瓶座嘗盡冷暖，閱歷豐富的一年。

整體運：☆☆☆

海王星在水瓶座之中，同時受到木星和火星的限制，生活上衝擊不小。所幸火星在二月份之後就過去了，然而木星卻一直干擾水瓶座，加上對宮的土星壓境，呈現出欲振乏力的景況。而凱龍星在水瓶座中發酵，你的內心有不少迷惘，在這時候甚至讓你困在自己的思緒當中。

穀神星自三月後全年在星宮內徘徊，也是影響今年運勢的重要星體，為你帶來滋潤和支助，也是你心靈的主要慰藉。

功課學業運：☆☆

這一年水瓶座在學業上的表現普通，因為心思很難集中在無趣的功課上，時常分心去想一些其它的事。除非是自己喜愛或有興趣的範圍，才有可能投注多一點精神。對於想要深造或晉級的人來說，選擇自己專精的領域，成功獲勝的希望會增加許多。

工作職場運：☆☆☆

這一年木星鎮守你的職業宮位，其實事業成效和名聲都還算不錯，但也因此背負了精神上的壓力，背後還要擔心和解決檯面下的問題，可能使得你心力交瘁，然而為了面子還是得撐下去。你會開始質疑自己在事業方面的理想和目標，甚至懷疑生活與人生的價值。

金錢理財運：☆☆

天王星在水瓶座的財運宮位上，一直以來你的財務都起伏變化，2006年這樣的現象仍然不減，需要注意的是，你能夠得到的資助不少，但需要開銷的地方可能更多，所以總結仍是虧損了不少。你的經濟狀況，有一些長期性的問題，需要從根源去解決。

戀愛婚姻運：☆☆☆

這一年裡，水瓶座似乎可說嘗盡了人情冷暖，穀神星對為你帶來滋潤和照顧，然而土星在對宮的壓制，使你的人際關係受限，而火星更為你帶來人情世故上的嚴苛考驗。

有伴侶的你：在戀愛中，你覺得很受傷，卻也能得到補償或幸福，還原心中最真實的感覺而前行，不要受外在的限制與捆綁了。

單身的你：你面臨許多不同的機會與對象，若即若離或恩怨牽扯，鼓起勇氣來理清關係，或者確認一下彼此緣分吧！

---

我很想知道什麼叫做「你的課業狀況將莫名其妙地好起來」...

2005-09-23：ASE

programmer tool：

1. debugger
2. version control
3. profiler(效能評估)
4. memory checker (memory leak detection, array boundary checking)
5. oxygen (software visualization) free
6. programming style / bad coding checker(static analysis)
7. unit testing(white box testing), visual test
8. check security(static analysis tools)

http://www.swebok.org/
Tom DeMarco：與熊共舞

2005-11-01：CAI

brandon-hall(顧問公司，公司內部的e-Learning)

• LCMS
• LMS Report
• KM(偏管理)

MGT：

• vision(看得到的目標)
• criteria
• support

Design：

• motivation
• content

大學LMS：BlackBoard、WebCT
LCMS：

1. 組合內容
2. 處理多種格式
3. reuse
4. workflow
5. version control

• Authoring
• Simulation
• PowerPoint轉換
• Test

incentive - 誘因
executives - 長官
gospel - 福音
tenet - 教義
edification - 涵養

2005-11-07：數位學習的介面、策略與教材設計(淡江大學教育科技系，李世忠教授兼系主任)

數位學習(e-Learning)要素

1. 硬體
2. 系統平台
3. 介面(一致性)
4. 教師
5. 方法與策略
6. 教材
7. 評量
8. 學習策略

The Interview With God

2005-11-18：ASE

Defensive Programming

• alpha testing-在公司內部測
• beta testing-給使用者測

• Assertion-不可預測
• Error Handling-可預測
  1. Return a netural value
  2. Substitute the next piece of valid data
  3. Return the same answer as the previous value
  4. Substitute the closest legal value
  5. Log a warning message to a file
  6. Return an error code
  7. Call an error processing routine/object
  8. Display an error message wherever the error is encountered
  9. Handle the error in whatever way works best locally
  10. Shut down

Software reuse (module)

1. procesure, function
2. template (STL, Standard Template Library)
3. class library(繼承)
4. component (高層次reuse) visual development
5. plugin

Large scale C++ Design
OCP：開放性-開放擴充；封閉性-封閉修改

2005-12-02：ASE

reuse

• 繼承+new method：增加新功能
• metohd overriding
• template
• framework (design pattern)
• component
• library
• 直接改source

C++：class寫在.h檔，給別人include

2005-12-30：ASE

Advancement of Software Process
Spiral Model：Plan→Prototype→Coding→Testing→...

• Rational Unified Process(RUP) - 大於20人
• Feature-Driven Development(FDD) - 10~40人
• Extreme Programming(XP) - 3~12人

CMM

多年前我在車站附近的音響店買了生平買過最貴的頭戴式耳機audio-technica ATH-PRO5 V
雖然說音質沒有話說
但可能是因為我頭太大
戴久了耳朵就會開始痛
上面的塑膠皮也掉地差不多了
所以一直好想換一個
終於在今天shumi幫我達成願望啦 :)
不過這應該也是shumi買過最貴的禮物吧! :P

今天跑到開封街上的品嘉
之前在網路上打聽了一陣子
好像是比較便宜、服務也不錯
但總是覺得買一臺好幾千塊的耳機感覺挺敗家的...
在店外頭探頭探腦了一會兒才敢進去 @@

老闆拿出一系列的AD300、AD500、AD700給我試聽 (不敢再拿AD900、AD1000了...)
其實我的耳朵也不是特別靈
雖然每款耳機樣子都差不多
一款就是比一款貴
試聽的時候也是感覺數字比較大的好像真的比較不賴
但是要一項項列出來卻是沒有辦法
不過戴久了不會不舒服
而且外型、顏色看起來很漂亮、超有質感的
這樣就我就很滿足啦!
年紀輕輕還是不要太奢侈好囉 :P

很久以前看到Godiva寄來的電子報有介紹這款chocolixir
就深深的吸引了我
一直好想去喝喝看
但還不是所有的Godiva專賣店都有賣這個chocolixir喔~
在誠品旗艦店開張之前
全台灣可只有天母有賣呢!

昨天跟shumi去誠品旗艦店逛
逛到樓下的美食區時
我從很遠的地方就發現了那裡的Godiva專賣店
沒想到居然有賣這個我盼望已久的chocolixir飲料
當然是二話不說
買一杯純黑巧克力喝看看囉~

Godiva果然不愧是巧克力界的扛霸子
比那個什麼星巴克賣的星冰樂好喝太多啦! (雖然也是貴很多...)
光是奶油上面淋的巧克力醬就徹底擊敗星冰樂了
飲料中那濃濃的巧克力味也是讓人回味無窮
加上散佈在裡面的巧克力碎片
喝下一口就已經徹底征服了我
也為我的2005年打下一個最甜美的句點 :)

新的一年又來到啦!
祝大家新年快樂!
狗年行大運 :)