Krilo 的筆記本

搶救軟體專案大作戰隨記:

使用者對於需求的表達是零散的，導出完整而正確的需求結構，是資訊人員應該具備的專業能力。

鄭炳強強調：「需求分析不只是資料搜集的工作。」純粹資料搜集的結果，就是一項需求對應一個功能，但若理解需求背後是解決何種問題，那麼也許只要10個功能就可以滿足100項需求。「報表」或「功能」只是滿足需求的「手段」而非目的，如果沒有了解背後的意義，就如同瞎子摸象，透過局部的印象，拼裝架構零散的系統，不僅事倍功半，而且開發出四不像的系統。

需求頻繁改變，很可能是因為始終沒有「搔到癢處」，需求分析不只是知道功能該如何運作（How），更要知道為什麼要這樣做（Why），才不會反客為主，被客戶牽著鼻子走。掌握領域知識（Domain Knowledge），贏得客戶的信任，就能主導專案的走向。所有的需求回溯到源頭，該掌握的是產業的精髓，知道客戶的痛才能對症下藥，否則頭痛醫頭、腳痛醫腳，只是治標不治本，才會如此的勞民又傷財。


通過CMMI的評鑑提升「流程」品質，並不代表能夠解決「軟體」品質的問題，軟體開發有許多層面是CMMI無法規範的地方，例如設計的優劣，CMMI以「驗證」與「確認」兩個流程領域控制品質，必須仰賴同仁審查（Peer Review）發現問題並提出改善。

但如果大家只是擔任「橡皮圖章」的角色矇混過去，或者根本不具發現問題的「能力」，CMMI便只是幫助企業很有效率地開發產出不良的產品。

叡揚技術發展辦公室經理楊東城舉例：「以工廠為例，流程只是製程，如果產品本身不對，品質再好也沒用。」開發軟體的製程有很多學派，CMMI是評估製程品質的參考，提醒我們製程的每個階段都不能偏廢。
但是如果只把焦點放在製程的管理，而不思考產品本身的內容，那麼只會以更有效率的方式，產出不對的產品。因此重點應該回歸到「人」的身上，CMMI無法取代人的創意、分析、設計與溝通的能力，以及長久累積的領域知識。如果遵循CMMI只是套招式學皮相，不過是花拳繡腿；「心法」與「內功」的強化，才是招招致勝的根本關鍵。


TCS採用RUP方法論，共分為3個往覆式開發流程（Iteration）分批完成，先開發核心的功能讓東森購物確認，再陸續補足其餘的部分，達到「及早發現，及早治療」的目的，以降低專案的風險。