CMM的基于活動的度量方法和瀑布過程的有次序的、基于活動的管理規范有非常密切的聯系，更適合瀑布型的開發過程。而CMMI相對CMM更一步支持迭代開發過程和經濟動機推動組織采用基于結果的方法：開發業務案例、構想和原型方案;細化后納入基線結構、可用發布，最后定為現場版本的發布。

　　雖然CMMI保留了基于活動的方法，它的確集成了軟件產業內很多現代的最好的實踐，因此它很大程度上淡化了和瀑布思想的聯系。

　　在CMMI模型中在保留了CMM階段式模式的基礎上，出現了連續式模型，這樣可以幫助一個組織以及這個組織的客戶更加客觀和全面的了解它的過程成熟度。同時，連續模型的采用可以給一個組織在進行過程改進的時候帶來更大的自主性，不用再象CMM中一樣，受到等級的嚴格限制。

　　這種改進的好處是靈活性和客觀性強，弱點在于由于缺乏指導，一個組織可能缺乏對關鍵過程域之間依賴關系的正確理解而片面的實施過程，造成一些過程成為空中樓閣，缺少其他過程的支撐。兩種表現方式(連續的和階段的)從他們所涵蓋的過程區域上來說并沒有不同，不同的是過程區域的組織方式以及對成熟度(能力)級別的判斷方式。

　　CMMI模型中比CMM進一步強化了對需求的重視。在CMM中，關于需求只有需求管理這一個關鍵過程域，也就是說，強調對有質量的需求進行管理，而如何獲取需求則沒有提出明確的要求。在CMMI的階段模型中，3級有一個獨立的關鍵過程域叫做需求開發，提出了對如何獲取優秀的需求的要求和方法。CMMI模型對工程活動進行了一定的強化。

　　在CMM中，只有3級中的軟件產品工程和同行評審兩個關鍵過程域是與工程過程密切相關的，而在CMMI中，則將需求開發，驗證，確認，技術解決方案，產品集成這些工程過程活動都作為單獨的關鍵過程域進行了要求，從而在實踐上提出了對工程的更高要求和更具體的指導。