開發系統人力已經不足，但破於無奈又先掉人來寫文件，造成寫系統的人越來越少，寫系統的人減少當然賺得錢也減少，而主管看到賺得錢減少誤以為是接太少案子，於是又接入更多的案子，我將之現象稱為project thrashing。
在memory中一旦採用虛擬記憶體，可能發生因為頁面缺失(page fault)的次數增加，造成I/O time上升，故cpu idle time提升。當cpu idle time太高時，OS會誤以為引入的process太少造成cpu idle time提升，為了降低cpu idle time將引入更多的process，這種誤判將造成頁面缺失的情況更加嚴重，此一情形謂之『thrashing』(中文稱為：猛移現象或輾轉現象)。
軟體發展也有好幾十年了，CMMI的崛起更加確定了系統文件化後能帶來的效益。當然CMMI不只是foucs在文件化，但不能不承認的是過程中要產生出一系列的文件，從WBS、系統需求規格、系統設計規格、測試文件、細部程式規格書、操作或使用手冊。這些文件的產生也就是希望在未來能：更輕易的瞭解並維護系統、提高軟體品質、降低軟體危機的問題。
當許多軟體公司投入CMMI，大力的推行各式各樣的文件化標準作業流程時，不管你正推行著level幾的等級，大部分的主管總要求的是"一定要產生出某某文件"，但細想到底什麼才是系統的重點，做好系統還是做好文件？
很多人會說沒有好的流程、好的文件化哪來好的系統，但相對的當你還沒有好的系統，卻一直因為客戶的dead line產出A文件、B文件...等，試問在系統都還沒做完時，交系統使用操作手冊的意思是？最主要的原因是避免被罰款吧。再者，很多案子接到手只剩兩三個月可以開發，如果將大部分的時間拿來寫交付文件，只有少部分的時間進行程式撰寫動作，品質我想也很難以提昇吧。文件固然重要，但他的存在是要輔助系統便於日後的維護，所以主角當然是系統，如此本末倒置的作法將使得程式人員越來越沒有成就感，相對的就慢慢形成了工作滿兩三年就要從痛苦的深淵跳走，進入到另一家公司，又大環境下都一樣，所以也只是開始進入另一個痛苦的深淵而已！
當上述情況一再出現將產生一連串惡性循環：原本開發系統人力已經不足，但破於無奈又先掉人來寫文件，造成寫系統的人越來越少，寫系統的人減少當然賺得錢也減少，而主管看到賺得錢減少誤以為是接太少案子，於是又接入更多的案子，這種情形發生在memory叫做thrashing，所以發生在project時，就把他稱為project thrashing好了...。
留言列表
