浅谈软件开发定律系列之1:10:100定律
1:10:100定律：需求错误导致的成本是修复程序错误成本的100倍。
定理解析：1:10:100定律更加形象的说明每个开发阶段，修复问题所花费的成本。 比如在需求阶段，可能修复一个问题的成本是1，那么在开发阶段，修复问题的成本就是10，在发布阶段，修复一个问题的成本就是100。
针对这个定律，如果问题越早发现，则成本越小，抛出了三个问题：
一、我们有哪些措施预防需求的错误？
二、我们有哪些措施发现需求的错误？
三、我们的质量成本是如何分布的？ 一、预防需求的错误，目前流行的是原型法
----------------以下摘自百度百科---------------
原型法的基本思想
是在投入大量的人力，物力之前，在限定的时间内，用最经济的方法开发出一个可实际运行的系统模型，用户在运行使用整个原型的基础上，通过对其评价，提出改进意见，对原型进行修改，统一使用，评价过程反复进行，使原型逐步完善，直到完全满足用户的需求为止。
原型法定义
原型法是指在获取一组基本的需求定义后，利用高级软件工具可视化的开发环境，快速地建立一个目标系统的最初版本，并把它交给用户试用、补充和修改，再进行新的版本开发。反复进行这个过程，直到得出系统的“精确解”，即用户满意为止。
原型法的工作步骤
利用原型法进行信息系统的设计过程中，分四步进行：首先快速分析，弄清用户/设计者的基本信息需求；然后构造原型，开发初始原型系统；之后，用户和系统开发人员使用并评价原型；最后系统开发人员修改和完善原型系统。
----------------以上摘自百度百科---------------
原型法是一种很好的工具，包括我们自己，在对内部提需求，甚至自己家里装修的时候，一开始都没有办法描述清楚自己的需求，只有软件出来，房间的3D图出来，才能理清楚自己的想法。所以装修的3D模型图，就是一种典型的原型法。 但是在实际的执行中，原型法用的好不好，还看公司执行的力度。比较推荐的沟通需求的做法，是三次闭环。
第一次闭环：客户描述需求，然后需求人员当场复述，第一次闭环。
第二次闭环：构图完成界面原型图，然后和客户构图闭环。建议是原型图+人机交互步骤表格的方式，进行闭环。
步骤 人（操作）机器（反应） 1 点击“登录”按键 2 连接数据库进行用户名密码效验 3 成功登录 显示主页界面 4 …… …… ……
第三次闭环：软件有α版本后，用最终原型和基本实现的功能，和客户进行第三次闭环。
备注：在预防需求的错误时，需要考虑沟通成本。考虑到如果拜访客户需要飞机往返，此类的成本还是较大。这部分的投入是否能立竿见影的见效，是关系到成本和产出的统计分析，目前该阶段拿出数据来较为困难。 二、 如何发现需求的问题 依赖于同行评审，同行评审（包括需求评审、设计架构评审、代码评审、测试设计策略、测试用例、后续的各种发布说明等林林总总）是非常耗成本的，占总成本的1/4。这点在很多公司做不到。但往往是忽略了评审，导致暴露问题的阶段滞后，最后的结论就是修复问题的成本由1，变成10，最后会变成100。
关于评审，大体有三种模式：
2.1、写文档的水平高，评审人水平一般 此类的评审倾向于培训，主要目的是培养新人，让新人熟悉业务，起到传帮带的作用。
2.2、写文档和评审人水平差不多 大家的意见各执一词，谁也说服不了谁。一般而言，技术上的方案肯定不止一种。当谁也说服不了谁的时候，就要提交技术经理，由技术经理评定到底选择那一种方案。
2.3、写文档的水准低于评审人 比如部门经理作为评审人参与到评审过程中。这种也是指导，不过是反向的指导。 实际上，评审是非常耗工时的事情，这里面还有很多细节，暂时不展开。
如果评审是第一步，那么评审遗留问题的闭环则是第二步，也是最重要的一步。每个团队都有自己跟踪遗留问题的方法，简单的说，自己的测试团队，关于事物跟踪的方法，大概推行了半年多，才能基本做到遗留问题的闭环，这是知难行易的一步，具体的分析在此略过。
评审的结果有三种，需要一个量化的指标，或者一个详细的检查评定表来判定结果：
1、通过。
2、需要修改，修改后再次评审（有关键检查项不过）
3、需要修改，修改后可直接发布（无关键项、有轻量级的问题） 关于同行评审：
高水平的同行，肯定自己的业务工作很多。如果公司制度制定不好时，请同行评审的阻力比较大。比如单一产品线管理模式，或者强矩阵模式。很多公司是通过制度保证的同行评审：如果你挂公司内的高级工程师、专家、资深专家头衔并匹配相关福利待遇时，必须承担自己的工作义务：每年带多少人、每年讲多少课、每年评审多少次等。 关于沟通：
这点对市场人员的要求较高，能否有效的沟通，把话听明白，把话说明白，是需要慢慢的磨练的。如果是新人培养，员工成长的成本太大。建议有资深想转行的研发体系管理人员担任，最方便。关于沟通的方法，在前面已经说过。
关于评审，说道可执行性，就要提到分级控制： 不分级控制，中间流通的关键点太多，任务串行，很容易导致效率低下：比如有一个问题，修复花了十分钟，组长审核20分钟，技术经理审核20分钟。加起来50分钟，太麻烦。
如果能分级控制，用检查表分类，什么改动不需要评审，什么改动需要组长评审，什么改动需要技术经理评审，这样就会优化过程时间，提高效率。 三、质量成本分布 整体而言，针对1:10:100定律，质量成本的分布很值得思考。
扪心自问，很多公司在测试投入和返工投入的成本很大，而在同行评审投入、沟通投入、培训投入的成本太少。更直接点说，根本没有关注，或者战略舍弃了在同行评审、沟通、培训的投入。
所以这肯定是一个系统级别的问题，需要系统级别的解决方案。