利用形式化的软件工程文档的话，这个做法的后果是极大的浪费了时间和资源，打击了开发者的积极性。
文档的本质是什么？为什么要写文档？什么样的文档才是有用的文档。
大多数的程序员没有主动写文档的习惯，这个可以接受，因为并不是所有的文档都有用，大概九成以上的文档是实际上的多余。大家应该仔细考虑文档所处的位置和作用。
为什么不剪裁呢？
因为我们不知道哪些信息是有用的信息，所以没有办法建立“有用”的文档。
在开发工具和开发模式高度发达的今天，我们还在用“手工作坊”的方式写着文档。
我们的开发是进步了，可是我们的文档化却没有进步。
我对软件工程一直秉持着实用化的态度。这个和RUP的原则也颇为类似。
作为一种可以剪裁的软件过程方案，RUP在实际的应用上已经远远做到了我们现在还没有做到的境界。
从需求、设计、实现、编码、测试的一系列过程。我们需要的是“准确记录”，而不是文字堆砌的卷宗。
文档的本质就是“记录”，而记录的方法却有多种多样，“我们没必要用文字成篇的去描述，而一两个图形或者图像更有表现力”，UML如是说。
而我在前篇文章所说的带着一部DV去做需求，还是因为在需求的过程中需要采集需求，进而就需要记录。而文字的表达能力是有限的，你不可能把一部人性化的软件交给一叠冷冰冰的纸张。因此，我们需要广泛的采集需求的信息。这时我们是在同客户分享一种感觉，一种用软件的感觉。
说到需求的分析，用例图给了一种改进，但不是里程碑式的改进。微软的开发过程就充分的体会到这样的问题，所以提出了一些改进的措施，可能是因为微软所做的软件并不是管理系统的原因吧。
到了设计和开发，作为结构最主要的表达——图形发挥了很大的作用，目前为止应该是最丰富的表达方法。
然而我们却乱画一气……不根据变更的需求去变更设计……设计文档又成了一种形式。我在很多地方都看不到设计文档，因为这个依靠想象力和创造力的领域变化的太快，文档跟不上思维。而我们需要的是一种可以经过反复讨论的设计思路，我们需要统一的设计规范——设计模式。它告诉我们在什么样的情况下需要什么样的设计。而Gof-23模式甚至不够用，他们只是遵循了某种面向对象的原则。但是AOP是否有这样的模式呢，据我了解，是有的，只是很少有人总结。我希望很多专心于AOP的人可以像专心于OOP的那样总结出一些设计模式。
编码阶段的文档——这可能是大多数软件工程实践中最成篇累牍但是最没有用的文档了。
我所提倡的是良好的设计，良好的设计可以让编程人员（无论是专业还是非专业）对于实现可以做到一目了然。类似于一种模式，例如某个地方需要冒泡排序，我们就知道代码如何实现的。而不用考虑它是怎么实现的。设计文档就要做到这一步，能够很轻松的告诉编码者整个框架是什么，整个结构是什么，而到了具体实现需要怎么做。而到了这一步，我们所需要的文档可能很少，甚至——没有。
编码阶段一直提倡的是自文档化的代码。这样的代码不光极具可读性，而且极具格式和规范性。我们所需要的可能仅仅是一份编码规范。剩下的，交给注释吧。
或者可以说：文档即是代码，代码即是文档。这是编码文档的理想境界。但是这是需要很好设计才能做到的。而这样的设计是需要长期编码-设计，设计-编码训练才可以达到的境界。
而代码规范，便是这个阶段最重要的因素了。好的代码规范会早就高可读性的代码——这是我们不需要在编码阶段另写文档的重要原因。因为这样不光可以节省了时间和资源，还提高了代码的质量。
关于测试阶段的文档，这应该是及其重要的一环。如果是使用的RUP的软件过程，和现在通常使用的螺旋模型的话，当然类似的模型可以。这类软件要求测试对需求能够有一个反馈，这是大家常用的模型的特点。
而测试文档在这里所扮演的角色不光是记录，更多的是一种报告。包括从各种测试得出的分析及分析的对策。就像资深会计师对公司的运作情况和未来发展给出的分析一样。资深的测试人员一定会对整个软件从需求、设计、到编码有最全面的把握。
所以，测试在软件工程中有很重要的位置。而不是所谓的简简单单“质量保证”或者“验证”，因为，质量是没办法保证的。测试不可能也没有必要穷举。因此测试文档不光要找出问题，更要有清晰的思路，因为新的需求会从这份分析报告（文档）中给出。这往往是大多数测试人员忽略的一环。