第一部份-DelphiKTop讨论区.DOC

FILENAME ch07- PAGE 1 第七章 系統分析方法 傳統的瀑布式與往復式開發流程的比較 使用UML來進行系統分析 FILENAME ch07- PAGE 18 7.1 系統開發流程 案例一 “系統如果不要一直加這些有的沒的需求，這些額外的功能，其實當初的版本都沒有問題,可是系統就是會有陸陸續續而來的額外需求,永不止休” 案例二 “我認識一個客戶他有一套幾年前使用foxpro開發的系統,,因為公司營業規模更大了,他想要改寫這套系統並增加功能,可是之前開發這套系統的程式設計師出國留學去了，你可以幫忙嗎？” 上述兩個例子可以當作本章的開頭實在是很貼切，案例一其實是筆者所認識的程式設計師常在發的牢騷，儘管是抱怨，卻非常值得來探討為什麼根據初始的需求分析進行設計的系統可以運作正常,一旦加入新的功能就會一團亂嗎？ 而第二個例子則是一個看似簡單實則不然的一個專案，假設這套使用foxpro設計的系統程式原始碼都有，且接手的程式設計師也懂foxpro，那麼就能很順利的如客戶所說改寫並在現有的架構增加新功能那麼簡單嗎？在討論這兩個問題之前，先來看看傳統的系統開發流程是怎樣的，答案其實就快呼之欲出了。 7.1.1 直瀑式方法（Waterfall） Ch07_01.tif 典型的系統開發流程幾乎就是如上圖所示，稱之為直瀑式方法。而程式設計師為什麼會抱怨加入新功能後會讓原本運作穩定的系統會增加維護上的複雜度，甚至是因為新功能影響現有功能的運作呢？造成終日在程式碼來回穿梭疲於奔命。 Ch07_02.tif 由上圖可以得知，比較遺憾的是如果為了趕時間追進度就很可能會有這樣的流程，新功能需求的切入點在『寫程式』這個環節，因此程式設計師直接面對新的需求並在程式碼中埋頭苦幹，造成了案例一的『苦主』與日俱增的抱怨，不但打擊士氣也降低生產力。而案例二的專案改良計劃，就算找了一個懂Foxpro的程式設計師來檢視現存系統的原始碼，若沒有適當的文件輔助那麼改良系統很可能會與重新開發的成本與時間不相上下。 理想的情況應該是 文件?寫程式?系統測試?系統安裝 遇到新增的功能需求則 修改文件?修改程式?系統測試?系統安裝 然而上述兩個案例可以發現文件只有在第一次系統分析時才有製作，之後的系統再分析就直接修改程式碼直接施工，因為短期來看這樣的方式最快最有效率，很有可能每次提出的新需求的修改幅度都不大，因此直接修改程式碼然後加上註解就可以交差了事，然而就長期來看一次次的小需求累積起來後，這個第N版的系統與文件所記載的第一版規格已經天差地遠了。 有些程式設計師可能會蠻自負的說： “只要我有寫註解，一定可以清楚知道全部的規格” 這樣的想法其實很危險，怎麼危險有以下兩個原因： 能保證一年後來看這些程式碼都還能記得一清二楚當初為什麼這樣設計呢？ 遇到職務調動或是離職等情況發生，新接手的人員一定能知道當初你腦袋裡面怎麼想的呢？ 直瀑式的開發流程並不是問題的根源，問題在於人們很容易在瀑布式的開發流程中把精力放在寫程式與系統測試這兩個階段，總覺得如果從系統分析階段進行再次分析會很浪費時間，因此對於系統分析與設計所投入的人力、時間都不夠，造成初次的分析與設計完成後，接下來的改良需求都沉降在程式碼撰寫與系統測試，自然造成程式設計人員負荷過重且系統開發的複雜度增加，造成成本與時間的浪費。 另外也常聽到一種說法： “如果有時間當然會做出分析文件，問題是現在我改Bug就來不及了，老闆催著要交程式,，文件，再說再說！等我有空一定做”。 非常遺憾的，有蠻多軟體公司存在著上述的情形在，其原因不外乎在開發流程上把重心放在程式設計這個階段，造成程式設計師日以繼夜加班埋頭苦幹，投入很多的心力卻無法有一個理想的成果，很是可惜。 7.1.2 往復式開發方法（Iteration） 典型的瀑布式開發流程容易讓人忽略系統分析的重要性，因此往復式的開發流程’強調系統分析與系統設計之間的聯繫，從第一次的需求產生的分析到後續的改良需求加入的分析都能與系統設計能相呼應，也就是說要修改程式碼一定要有依據，而這個依據就是再次的系統分析。 Ch03.tif 如上圖所示，系統分析的角色被大大的提升，開發流程不管是在初始階段或是後續的持續改良階段，都必須要按部就班回到系統分析然後才是系統設計。這樣的模式可以避免系統開發的重心集中在寫程式碼的階段，新的需求出現透過再次分析將上一版本的分析文件重新組織架構，進而能在系統分析的階段就能夠發現缺失，大大降低了風險，節省不必要的額外人力與時間開銷，孫子兵法有言：『多算勝，少算不勝。』其意在此。 7.1.3 OOA 第六章幫助各位初探物件導向的思考模式,，同樣的在系統分析也可以運用同樣的模式來處理，也就是OOA（Object Oriented Analysis）。 既然是系統分析，