领导给你一个开源项目，让你调研之后用另一种技术来实现其一模一样的功能...
更难的是，这个开源项目没有任何文档，只能自己去网上搜相关资料...
定目标、搭班子、带队伍！
目标，有了；
班子，加上我总共三个人；
带队伍，领导觉得需要一个计划！
这个计划怎么做？没有参考，对这个开源项目也不了解...
慌得一批！
网上一查：
基于WBS的工作量估算方法，是最常见的一种估算方法，也是厂商最常用的。基于WBS的工作量的估算方法，又称为由底向上法（自下而上法），通常的需要寻找类似的历史项目。
没有类似的历史项目，不要！
基于代码行（SLOC）的工作量估算，是从开发者的技术角度出发来度量软件。代码行数是软件开发者最早进行规模测量的主要方法。进行工作量估算时，先采用WBS法、类比法等统计出软件项目的代码行数，然后将代码行数转换为人天数。
这个听着靠谱，代码行数我们很容易就可以得到。
接下来，需要构建一个我们自己的将代码行（SLOC）转换成人天数的模型，因为网上的，不太适合我们，但他们的思想可以借鉴：
找到影响工作量的因子，然后数学近似化。
影响工作量的因子都有哪些？
代码行数是肯定的了。那么，是统计好整个开源项目的代码行数，然后代入公式计算？还是统计好一个文件的代码行数就计算？
显然，逐文件的统计粒度更小，所以会更加准确。
除了代码行数，技术状态和复杂程度都应该考虑在内。
技术状态，是说妨碍开发进展的限制，比如技术储备、机器性能等；
复杂程度，是说同样行数的代码，有的要复杂，有的要简单。
记代码行数为\(L\)，技术状态系数为\(T\)，复杂程度系数为\(C\)，工作量为\(W\)（单位人天），则
\(W=L*T*S\)
需要注意的是，这个W是某一个文件的。工作总量是所有文件的W累加的结果。
显然，给每个文件预估一个技术状态系数\(T\)和复杂程度系数\(C\)，费时费力。何不给某一个大的模块预估一个整体的就好，这个模块下面的所有文件都用该平均的\(T\)和\(C\)。