以前简单的看过CMM，也被其文档的烦琐而吓到了。还记得一个简单的比方：
CMM1:没有文档
CMM2：有文档
CMM3：有文档的文档
CMM4：有文档的文档的文档
CMM5：有文档的文档的文档的文档
我也只想着去实现一个CMM3的规模。有需求文档（2），这个需求文档由谁提出，谁在何时做了什么样的变更，在什么样的情况下什么地方可能做什么样的变化（3）。实现阶段的设计文档和开发编码文档。考虑到文档的变更，维护多套文档（包括程序）是本麻烦的。本人也常常在编码阶段觉得自己的设计有瑕疵，于是在编码阶段的实现方法就与以前的设计文档有所不同，但一般的，我都没有重视到或者说以结果为主导任务，于是把设计文档这一过程性的文档放在了末位。于是，出现的情况是设计文档和实现并不一致。这也是很多团队不做文档的理由。
需求-》设计-》伪代码-》编码。使用伪代码应该可以很好的保持设计和编码之间的联系，而所有的伪代码全部使用注释的方式写在开发的程序代码中。具体伪代码的实现可以参考《代码大全2》P218。伪代码可以作为一个设计，也可以作为一个子程序或功能的需求。把文档放在程序中，保证文档只有一份。但另外的，以任务为目的的去看别人的源代码是一大头痛的事情，以学习的目的去看优秀的简短的代码才可能是一种享受。所以，文档的撰写可以全部在程序中，但程序文档的分发却需要多种的形式，以达到不同人的需要。因此，这就要求了程序中的使用的文档必须能够被某中工具提取出来，并形成可读性文档。这类的工具包括 javadoc， phpdoc等。在需求或者设计变更，以及其他有需要时生成一次文档，文档以html格式保存，如果每次使用工具时使用的配置相同，那么，两次生成的文档是有可比性的。通过版本管理，很容易追溯文档的变更历史。这就可以形成文档（需求或设计文档）的文档（文档的变更文档）。