需求執行方式

from [矇矇的秘密基地]

圖1、循序式的開發流程
一般軟體人員，不習慣模糊不清、不確定性，所以需求的分析，一定要到某一個階段，待所謂的 “規格” 明確後，才會進入下一個開發的階段；凡事要求明確、單一的答案，所以關於比較創新性、沒有絕對標準答案的設計與嘗試，往往不敢踏前，因為很容易被 “Challenge”，卻又惶恐於如何 “自圓其說”，來勇於表達自身的看法與觀點；另一個更現實的問題是，”組織” 本身就是要求軟體開發如同硬體代工業製程般的「軟體工程」模式，每一個人都是 “螺絲”，接受明確的指令，不需要多想、多思考、多創新性，安份地做完局部自身的工作即可。

I&I (Iteration and Incremental) 的開發模式

圖2、反覆式(Iteration)及漸增性(Incremental)的開發方式

這樣有何好處？ 開發時間是否會縮短？ 其實並沒有，反而一開始開發時間會拉長，慢慢習慣這樣的開發模式後，才能倒吃甘蔗般，效率會提升上來。反覆式最大的好處就是在於提早可以揭露潛藏的風險(Risk)，而儘早處理掉。如果軟體開發人員必須要在數個月等需求分析、設計的階段過後才開始實作程式碼，一旦發現問題，要再回頭去修正，則必須花費相當長的時間來做修正；另外因為開發人員之間可以在一個 Iteration 期間內就可以看到具體的結果(可執行的程式碼)，他們可以維持良好的注意力在實際結果上，也能很快得到工作上的回饋(Feedback)，當過程中有小錯誤，開發人員可以回頭去修正，時間不會離得太遠。

.....

從需求分析、結構設計到系統的實做(同時就會涵蓋到上述三個觀點)，是要快速循環、走過一遍的。再次強調，每個 Iteration 的開發週期是以 “週” 為單位，最晚不得超過 2 週。如果將每一個功能單位(使用案例或功能點)規劃為三個Iteration，每一個循環要作的事可能是：

Iteration #1：確認使用案例所要完成的目標(Goal)，建立結構與程式碼框架，找出從分析至實作的風險因子，建立溝通的管道。
Iteration #2：將實現使用案例的細節部分補足，包括規則、流程、欄位明細與資料型態等。
Iteration #3：作例外處理(Exception Handling)的考量與實現。

 

目前我的作法是
需求分析階段 =>針對最主要的流程撰寫虛擬碼=>撰寫程式執行=>檢視狀況=>調整規格
目前都還滿順利的

但,需求分析階段真的有點長.. 我都快做不完了...  ><"
應該可以考慮用EA的反向工程功能了.