script知识3) css知识4) 后台编程语言，仅使用到与前台界面编写相关的部分知识。5) 业务知识
通过以上分析可以看到，在编写单表的维护代码阶段是使用知识最少的一个步骤，同样的当业务产生变更时，为该处的变化所用的编码时间也比较少，而变化所花费的时间与表结构的调整所花费的时间是正比关系。这个关系将在复杂度分析时进一步说明。接下来看编写该表与其他表的业务关系代码和编写界面代码部分，这个2个阶段所使用的知识繁多，并且涉及的知识面也很广，是项目中花费时间最多的地方。但是在实际项目开发中并没有再对这两个步骤进行更细的分解的过程。
现在可以得出一个这样的结论，工作量是与所使用的知识相关的。一个业务所使用的知识点越少，所涵盖的知识面越少，那么所耗费的工作量也会越少。由此，当需要提高工作效率时，尽量少的使用知识是一种有效的手段。但是在实际情况中，并不能有效的减少知识使用种类，只能在使用知识的熟练度上下工夫，一个开发者所掌握的知识熟练度越高，那么相对的工作量也就会越少，一个知识点的入门门槛越低，那么工作量也会越少。因此，设置工作量为G，知识点入门门槛为B，B1为交给新手人员开发的知识点，知识点总数为C，P1为高级开发人数的，P2为新手人数，那么G = ( C - B )/P1 + ( B - B1 ) / P1 + B1 / P2 。
对知识点分析完后，再对业务的复杂度进行分析，知识点的应用可以看作是开发中的横切方向的话，那业务的复杂度就是开发中的纵切方向，业务的复杂度贯穿了所有的开发步骤。
在本文中，从数据的应用着手，来分析业务的复杂度。
在项目开发中，经常要遇到"类型"这样的业务点，例如职务。对于这一类业务，其主要开发时间就花费在"对于单表的增删改查"上。另一种类型的业务，其复杂度高一点，主要应用于该表需要与另一个表进行组合，然后产生一种"所属"的关系，例如权限，角色等，其主要开发时间就花费在"对于多个表的所属关系的增删改查"上。还有一种类型的业务，主要是将多个表的数据进行组合转换后输出，例如报表，CMS的模板解析等，其主要开发时间就花费在"对于多个表数据的监测和重组上"，最后一种类型的业务，主要是为数据附加上状态，例如工作流等，其主要开发时间就花费在"对于数据的不同状态的处理上"。
以上4点基本涵盖了做项目时所面对的业务。接下来，我们为这4种业务定一个权值
1.对于单表的增删改查"权值为1
2.对于多个表的所属关系的增删改查"权值为4
3.对于多个表数据的监测和重组上"权值为8
4.对于数据的不同状态的处理上"权值为16
这个权值的比值基本来自于数据的维度，1类业务是单一纬度。2类业务除了要处理多个1类业务外，还需要处理多个1类业务之间的关系。3类业务除了要处理2类业务中包含的，还需要对数据本身进行转换处理，4类业务除了要处理3类业务的，还需要处理数据的状态。后一种业务要比前一种业务多处理一种逻辑结构。
根据这个权值，来看看在项目中经常遇到的情况，以职务为例，最开始的需求就是1类业务，这个时候客户的需求变更可能如果仅限制在1类业务的需求范围内，那么如果完成职务的业务开发时间为1的话，那么修改的时间应该在<=1的开发时间内。但是，这个时候客户提出一种需求变更，他要求，职务是有从属关系