領測軟件測試網
在實施
CMMI的過程,理解CMMI模型的難點之一是理解模型,模型理解不深不透,就無法正確地判斷是否達到了模型的要求,可能做了很多投入產出不成比例的活動,造成資源的浪費。在理解了模型之后,更大的困難在于如何在企業里推廣CMMI模型。舉個很簡單的例子,按CMMI模型的要求,項目組應該進行
估算:估算任務和
工作產品的屬性以及工作量等,對于
軟件開發,任務和工作產品的屬性就是規模、復雜度、復用率等。CMMI模型只講了要“做什么”,沒有講“為什么”、也沒有講“怎么做”。企業可以定義本組織認可的估算模型以解決怎么做的問題,但是,對于項目組的成員來講,他們已經習慣了原來的作業方式,比如:只估計工作量,不估算規模。他們不清楚為什么這么做,如果讓他們改變原來的策劃過程,沒有策略、沒有方法,只靠
培訓與行政的約束幾乎是不可能的,需要推廣者利用各種辦法以促使執行者能夠從被動實施轉化為主動實施,從而形成習慣,自覺自愿的實施。再比如,很多企業有決策的活動,但是大的決策都不是在項目立項之后做的,而是在立項之前由高層經理組織各方面的人員討論、確定產品的
技術路線,如何確保這樣的決策采用結構化的決策方法呢?體系的推廣者可以定義過程,但是對高層經理的約束如何落實呢?這就不是CMMI模型本身可以解決的。
SEI推薦了IDEAL作為過程改進的過程模型,該模型和PDCA的思想是類似的,是一種循環上升的、持續改進的過程模型,是一種宏觀的過程模型,并沒有給出具體的措施。在推行過程改進的時候,需要推廣人員創造地尋找一些策略與方法去推廣體系。典型的一些策略與方法舉例如下:
例一:“測試先行”。在管理基礎薄弱的軟件企業里面,通過加強軟件測試,可以直觀地發現很多問題,從而使大家認識到質量的重要性,認識到進行過程改進的重要性,事實勝于雄辯;另一方面也減少了用戶發現錯誤的概率。
例二:“缺陷分析”。對于客戶反饋的缺陷、自己測試出的缺陷可以進行深入的原因分析,通過連續詢問多個“為什么”發現問題的根源,從而能夠從根本上采取措施、解決問題。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
TAG:
cmmi
CMMI
改進
模型
軟件測試