這一思路在軟件過程中，直接表現為里程碑和迭代的思路。我們可以想想，里程碑是不是一種制度。在需求結束的時候，我們需要需求規約文檔，風險列表等等一系列的文檔，在設計結束的時候，我們也需要另一些文檔。這種處理方式就是考核的思路。但是很多時候，這種考核起到的作用是有局限性的：
工件的設計原本是為了輔助生成最終的代碼，但是往往會演變成為了通過里程碑而設計；
里程碑的設計不能夠完全捕獲所有的問題，部分的風險被隱藏了；
難以對工作量和工作價值進行評估；
里程碑揭露問題的時間要遠遠落后于問題出現的時間；
這里對里程碑的方式做一些分析。我們對問題的理解往往是逐步深入的。在項目一開始的時候，業務和技術上都存在問題，存在不確定性和風險，這時候往往是最需要評估和驗證的。但是里程碑方式往往要求必須深入的分析需求，很多的問題并沒有得以解決，而是被悄悄的有意或無意的掩蓋了。需求畢竟不是軟件，它是一個不同人具有不同理解的模型，這時候，項目中各個角色對它的理解都不相同，但是這并不影響他們做出一致的決定－通過需求里程碑。問題到了設計階段依然存在，這時候需求階段隱藏的一些問題開始出現，導致我們不得不補充一些工作量。但是所有的問題也沒有得到解決，依然存在未知的風險。那么風險到了什么時候才會暴露出來呢？最樂觀的情況是在編碼時期發現，最悲觀的情況是在交付期發現。我們把這種過程稱為固化考核過程。 問題在哪里？除了軟件本身，模型也好、文檔也罷，都不能夠代替最后的代碼。在精益原則中，我們說，必須消除浪費。當我們在開發工件的時候，我們的浪費行為已經或多或少的出現了。
與固化考核過程相對的，我們認為存在另一種動態評估過程。里程碑或是檢查點并不是不重要。但是我們需要轉換思路，來將里程碑的實踐做的更好一些。我們上面提到說里程碑方式最大問題就在于一定要等到問題都積累起來了才解決問題，而這個時候往往已經錯過了解決問題的最佳時機。而動態評估過程的含義就是在過程進行中不斷的發現并解決問題，而不是等到問題累積到一定程度才批量解決。過程隨著環境的變化不斷的調整，以適應變化性和不確定性的需要。而里程碑實踐重在提供一個復審的機會，能夠從一個較高的層次上來評價軟件。 這種過程就是分階段開發軟件的思路，我們也可以稱呼它為迭代、螺旋、增量，都沒有關系。關鍵在于，我們需要不斷的發現導致客戶不滿意的問題，發現改進接電話的方法，發現改進做菜的方法，發現更快送貨的方法。
實現策略
文章來源于領測軟件測試網 http://www.kjueaiud.com/
