传统工程往往先做容易的事情，以期望看到实际的进展；现代工程总是着手先去解决需求，用例，构件和风险中的关键问题，这也是RUP架构为核心这条重要原则的本质，架构设计往往关注的是系统关键用例和关键接口，而不是系统中容易实现功能的描述。

在过去30多年中，软件工程领域总结了很多软件生命周期中关于2/8原则的经验和教训，这也是风险管理的一个重要视角。

 

1.80%的工程活动是由20%的需求消耗的。这个应该包含了原始需求收集，需求调研，需求分析，需求开发等各个需求阶段的活动。从用户有一个想法要转变为一个实际可以拿来开发实现的软件需求是一个需要大量工作量的漫长过程。传统的瀑布模型追求需求完全定义清楚很难满足现在快速开发要求，现代工程关注的重点是对系统架构和设计有重点影响的关键20%需求的确定和细化，而其它一些非关键需求和细枝末节的东西则可以后期通过不断迭代来进行细化。

 

2.80%的软件成本是由20%的构件引起的。谈到这里更看出了简单的用代码行来估计软件成本方法的局限性，一个关键构件的前期设计和思考可能会耗费大量时间，而产出的代码行可能并不大。编码者随意粘贴拷贝代码的毛病却产出了更多的代码量。对于复杂的系统必须舍得投入充足的时间来优先考虑和设计系统中的关键构件，特别是对于全新系统，架构设计的时间越短，后期的风险越大。当你面对后期重构可能导致整个系统推倒重来的决策时候，可能已经回天乏术了。

 

3.80%的错误是由20%的构件引起的。简单容易的构件或功能是很少引入过多的BUG的，而对于存在复杂逻辑的一些关键构件往往则会引起系统80%的错误和BUG。只有关键构件稳定了，整个系统才可能真正的健壮和稳定。

 

4.80%的软件废品或返工是由20%的错误引起的。对于系统中关键构件的变更一定要优先的进行设计和变更，项目一到后期这种变更的影响面越大。特别是那些在系统中高度复用的构件。

 

5.80%的资源(执行时间,磁盘空间和内存)是由20%的构件消耗的。因此应该优先设计性能关键的构件，使得工程的可靠性，可变性和成本效率的平衡在生命周期的前期得到解决。

 

6.80%的进展是由20%的人来完成的。现代工程畅导的是在前期需求和架构设计阶段只需要投入足够少的人来完成整个系统中重要和核心的工作，而后期的详设和编码阶段再投入足够多的人加快进度。项目需要确保在前期投入的需求和架构人员的促使化团队是最优秀的人员。