1. 理解问题
a. 谁将从问题的解决中获益
b. 有哪些是未知的？哪些数据/功能/特征/行为是解决问题必须的
c. 问题可以划分吗？是否可以描述更小/更容易理解的问题？
d. 问题可以图形化描述吗？可以创建分析模型吗？
2. 计划解决方案
a. 以前曾经见过类似问题吗？在解决方案中是否隐藏着熟悉的模式？是否已经有软件实现了所需要的数据/功能/特征/行为？
b. 类似问题是否解决？如果是，解决方案包含的元素是否可以复用？
c. 可以定义子问题吗？如果可以，解决方案是否适用于子问题？
d. 能用一种可以很快实现的方式来描述解决方案吗？能构建出设计模型吗？
3. 实施计划
a. 成果和计划一致吗？源码是否可以追溯到设计模型？
b. 成果的各个组成部分是否都正确？设计和代码是否经过评审？或者更进一步，算法是否经过正确性证明？
4. 检查结果
a. 成果的每个部分是否可以进行测试？是否实现了合理的测试策略？
b. 解决方案是否产生了与所要求的数据/功能/特征/行为的一致的结果？是否按照项目共利益者的需求对软件进行了确认？
核心原则
1.存在价值
思想就是给用户提用价值，软件才有价值
2.保持简洁
简洁而不是简化，结果是易维护，少出错
3.维护视图
统一项目实施的思想/架构
4.生产者要让消费者理解
做的东西要让相关的人更容易懂/使用。比如编写的代码使得维护它的人更易读
5.面向未来
软件能够适应变化。设计时常问：如果出现。。。应该怎样应付。准备所有的解决方案以解决普遍问题。同时带来的是可复用性。
6.计划复用
7.认真思考
在行动前清晰/完整的思考通常能产生更好的结果。一旦仔细思考过，能做好的可能性就变大了，而且能够获得更多如果做好的知识。如果仔细思考了，还是做错了，就会变成很有价值的经验。还能对一无所知的事物产生感性认知，这样慢慢就能找到答案。
如果能够在使用前六条原则时经过认真思考，那么潜在的收益数不胜数。