请帮我估计一下，可以吗？
程序打算用C++开发，请用过C++开发的兄弟和有经验的朋友帮忙估计一下每个模块的代码行，多谢！
数据控制系统
数据库设计
数据交换格式设计
数据读取模块
数据存储模块
数据导入模块
数据导出模块
数据安全性、完整性、一致性校验模块
数据备份模块
基本财务管理系统
现金管理系统
贵重物品管理系统
物品资金转换系统
账户管理系统
货币管理系统
资金流转管理系统
对帐平帐系统
借贷管理系统
图表支持系统
财务分析系统
数据备份系统
与其它系统数据接口设计
资金透支风险管理系统
外汇管理系统
外汇牌价图表显示模块
外汇买卖历史记录模块
账户管理模块
数据备份模块
与internet连接接口设计
基金股票管理系统
股票基金价格实时图表显示模块
股票基金买卖控制模块
股票基金买卖历史记录
账户管理模块
数据备份模块
与internet连接接口设计
与其它股票软件（如金龙）接口设计
账簿管理系统
账户管理模块
收支明细图表显示模块
数据备份模块
财务分析与建议模块
现有各种账户、信用卡、存款、贷款的资金管理模块
信息服务系统
用户订制新闻、显示新闻模块
理财投资计划与分析模块
重大支出助理模块
日记与提醒模块
借贷款记录模块
与internet连接的接口设计
数据共享设计
固定资产及贵重物品管理系统
固定资产管理模块
贵重物品管理模块
仓库、保险库、租用保险库管理模块
买卖、拍卖估价模块
物品流动记录模块
产品升级版本预留接口设计
CS与BS模式转换接口
数据格式设计
网络连接设计
在线升级、更新数据设计
与银行、证券交易所同步账户
数据格式设计
网络接口预留设计
网络安全设计
问题点数：50、回复次数：29Top
1 楼ghthlz（涛涛）回复于 2003-12-04 01:31:02 得分 0
这是我们的课程设计，家庭理财系统Top
2 楼BirdGu（鲲鹏）回复于 2003-12-04 08:02:19 得分 0
写个程序，对每个模块在500到2000之间产生一个随机数。
无聊Top
3 楼ghthlz（涛涛）回复于 2003-12-04 12:00:36 得分 0
这是软件开发初期的规模估计。每个公司都是追求利润的，如果不知道人月和开发时间，那么
怎么去控制开发成本。如果想做一个产品或项目的项目经理盲目的去开发，肯定不会控制进度
的。如果是程序员来看当然是一件很无聊的事情。呵呵。我还是感谢楼上，因为你给我了一个
大致的范围。我因为是第一次按照CMM进行软件估计，所以一点概念没有。Top
4 楼ozzzzzz（希望敏捷）回复于 2003-12-04 13:19:07 得分 10
ghthlz(涛涛)
看来给你上点基础课还是有必要的，不然你就不能明白为什么 BirdGu(鲲鹏) 会说无聊。
我先抛开CMM的垃圾不谈（要是不垃圾，你也就不用来问我们这些最讨厌CMM的人怎么预估项目规模了）。
首先使用代码行预估和判断软件规模是一种愚蠢的行为（不是说你，你去了解一下现在什么国家的企业喜欢玩这个就知道了）。实际上现在有一种技术叫－－refactoring，而这个技术的最大一个作用就是把你的代码行降低，提高你的代码的清晰度可提供更好的内部结构。你这个时候会认为一个前面的个5k的代码比这个3.5k的代码花费了更大的资源于时间吗？其次代码行会随着你设计的思路不同而差别巨大，这个你应该可以理解。不同的语言以及不同的工具间的代码行标准也差别巨大，比如是不是用成品控件，是不是用现成的代码框架。实际上国际国内早就不以代码行来估计和测算项目的规模，前段时间人们流行用的是功能点，现在很多人又去搞用例点，总之用到的是一些以功能需求为标准的测量手段。
其次你就是知道了代码行，你也一样不能规划进度。说实在的你现在的做法就是在盲目开发，预测和估计都是要建立在数据的基础上的，也就是要建立在以前的开发过程中得到的数据基础上的。如果你没有这些数据，那么就需要凭经验估计，而人和人的经验差别巨大，所以估计的差别也就会巨大。同时我觉得知道提前人月是最没有用的一个数据，不然也不会有一本《人月神化》。你最大的误解可能在于你似乎认为知道了总代码行，然后和日代码行之类的一运算就可以得到总耗时，这显然是一种对于软件开发规律的无知。
对待这些无聊的作业，我会选择一个先给答案，然后倒推过程的方法解答。
其实你这个帖子是不符合我定的社区规矩的，因为你来找我们给你写作业，这里是我们讨论工作的地方，写作业这样的事情需要自己解决。我只是看到你的问题很典型，所以随便说几句，让大家对一些基本概念有些认识。Top
5 楼ghthlz（涛涛）回复于 2003-12-05 02:24:51 得分 0
学习中..................
我是打算这样的“最大的误解可能在于你似乎认为知道了总代码行，然后和日代码行之类的一运算就可以得到总耗时”。因为我没有更好的解决方案，那么如果要避免盲目开发使项目可预测，尤其对这种没有历史数据的，难道就没有只能凭经验了吗？
《人月神话》我是看了，但我不认为一文不值，至少里面讲的还是有些道理的。我想为了避免盲目性可否ozzzzzz(希望敏捷) 介绍一些书籍，让我理解一些有用的基础知识。
声明：我并不是为了完成作业才来这的，我也是想探讨问题和研究问题的。如果我在这里真正问到了我想学的知识，我当然会问的。Top
6 楼ozzzzzz（希望敏捷）回复于 2003-12-05 05:20:13 得分 0
不知道谁家的汽车又在叫，烦啊，睡觉不成。
人月神化不是不是一文不值，而是非常有价值。但是你还没有看明白到底说了什么。但是你至少应该明白人和月不能互换。而实际上明白了这个很多事情就可以明白个八九。
首先你可以查一下功能点和用例点，用例点可能不好找，但是功能点绝对是到处都有资料的。其实也就是计算出项目的功能点数，这就是项目的规模。而大概的完成日期则是可以和前期收集的完成功能点的速度向运算得出。用例点也是类似。
而我推荐一个直观的方法，有经验的人可以使用这个简单的方法。你首先设想的一个基本功能，完成这个你应该化多少时间你应该心里有数。然后按照这个基本功能和项目中的其他功能对比，从而估算出各个功能的大概开发时间。把这些功能所耗时间相加，再乘以一个修正因子，就是项目时间。这个修正因子和个人经验相关，要不断摸索产生。
而实际先现代企业开发产品已经基本不会这样估算一个时间了。他们首先会列出一个功能类表，把功能划分优先级。然后更加市场情况确定一个上市日期，或者由客户确定一个交货日期。然后由优先基本最高的开始依次开发。当项目进行中会不断调整这个优先次序，并且在产品发布前确定到底要包括那些功能，舍弃那些功能。这样作就必须对需求进行切实的管理，并且要有迭代作保证。
而作为初学者，我推荐学习功能点的方法，计算简单，并且工具也很多。Top
7 楼trinter（张三）回复于 2003-12-05 10:04:59 得分 0
版主您好，我是涛涛的同学，我们一起做这个作业，这次我是我们小组的项目经理。
我们因为都没有做过项目估计，所以开始也搞不懂，觉得使用专家法，每个人去估计
一下，比较容易些。而在估计时，根据我做的产品WBS计划，感觉找功能点不是很好找。
如果用代码行，因为我们会在后面的过程中逐步完善，不停更新估计，所以可以在积累
经验的过程中，应该可以尽量达到比较准确。毕竟我们几个以前也没有一起合作过，对
整个小组来说，是没有那些可以使用的比例系数或是参数的。
不过您说的功能点法，我觉得我们小组可以回去讨论，如果大家有兴趣，在交完作业后
可以重新使用功能点法做一次。
做为新手，需要请教的很多，望不吝赐教Top
8 楼BirdGu（鲲鹏）回复于 2003-12-05 10:27:37 得分 10
你们这个作业的目的究竟是什么啊？是仅仅进行估计呢，还是最后要把这些系统都做出来？Top
9 楼ozzzzzz（希望敏捷）回复于 2003-12-05 12:47:33 得分 0
如果你们真的是要学习一下，我建议你们几种方法都有用。然后你们可以对比他们各自的不同，找到各自的优缺点。
而开始的测算需要一些参数，可以凭空想象。这没有关系，当你开始开发以后，你们可以逐渐根绝实际情况调整那些数据，慢慢会得到一个比较好的结果，不要急。
如果作业就是估算，那么就没有什么意义。随便搞一个数据回去交差就完了。我们这些人为什么估计项目规模准确一些，其实没有什么，就是因为我们的经验多，并且我们还不断的把平时得到的数据分析，不断修改自己的估算体系。不要着急慢慢来，开始的时候要保守一点，毕竟程序员都是乐观的。Top
10 楼ghthlz（涛涛）回复于 2003-12-05 13:04:18 得分 0
我们以前做了立项报告，现在正在准备评估报告，以后还要做项目计划、任务分配和十大风险
清单。实际上并不是真正的系统的开发，应该说软件项目管理。我们是5个人小组讨论完成作业，因为我们都不是很懂，所以想和大家探讨，同时学习才是我们真正的目的。
Top
11 楼zxl_l（凌龙）回复于 2003-12-05 13:20:40 得分 10
程序用C++开发,使用功能点，操作（如录入）功能、报表各约需多少工作日可依据各人的能力进行自己评估，这样可计算出开发小组约需的工作量。开发小组人员能力不同结果不会一样。你们是做作业可能不需对需求及迭代进行切实的管理或不知如何管理，这就是为什么招工是要有实际项目经验。Top
12 楼BirdGu（鲲鹏）回复于 2003-12-05 13:58:36 得分 0
如果要使用功能点的方法，楼主所提供的信息是远远不够的。事实上无论使用哪种估计方法，楼主目前所提供的信息都是不足以得到有意义的估计的，除非是有过类似项目的丰富开发经验，看到模块的名字就能大致理解其包含的需求，从而根据以前项目的经验得到大致的估计。
由于你们都是学生，因此不可能有类似项目的开发经验。因此无论你们用什么方法，都不会比我建议的产生随即数的方法——也就是瞎猜的方法更有可能接近实际情况。Top
13 楼ozzzzzz（希望敏捷）回复于 2003-12-05 14:21:46 得分 0
你们的做法很不合适。脱离实际的项目管理不会对于你们的学习有任何好处。学习这些以经验为基础的东西，必须以实际操作为基础。
其实评估关键不是评估工期，而是评估其商业价值，技术实现风险。而规模和工期的具体数据，不应该在这个时候就去估算。因为你们现在面对的还是单一小型项目，如果遇到大型项目和大量小型项目同时评估（实际工作中基本都是对多种方案共同评估），你们这样的做法就需要大量的资源。而实际上多数方案最后都不会被通过，而且也根本就不用考虑规模和进度，就已经被淘汰了。而最后一般情况下只会对最有商业价值，最容易实现的项目作具体深入的分析。
这之后才会用到我上面说的那些方法。而项目计划现在基本都是以满足某种功能需求或者提交某种符合一定标准的产品为里程碑，而不是以代码的数量为标准。而风险列表，也不能选择什么十大，而是要把所有以及发现的风险都添加到其中。然后对其进行评估，找到先后顺序，并且判断风险发生条件和风险转化为实际事件的标志。然后在项目进行过程中定期，或者持续的对其进行调整维护。
而如果不去具体实践，基本上这些东西你们都学不到什么。写写报告容易，真的去实施就难了。Top
14 楼rockrabbit（rockrabbit）回复于 2003-12-05 17:43:00 得分 0
一个家庭理财系统，似乎有点像企业ERP系统阿。Top
15 楼scalene（南瓜汤）回复于 2003-12-05 19:28:06 得分 0
做什么作业，TSP吗？Top
16 楼zhaoxichao（小西）回复于 2003-12-05 19:50:50 得分 10
我想说的一点是楼主说的“按照CMM进行软件估计”，而 ozzzzzz(希望敏捷) 指出“CMM的垃圾”
其实CMM只是一个过程并没有指定方法，CMM说项目在进行计划的时候应该要估计，并没有指出要用什么方法去估计，可以采用delphi、类比、功能点估计、特征估计还有各种估计模型等等
当然如果是agile development就可能反对计划估计了^_^Top
17 楼BirdGu（鲲鹏）回复于 2003-12-05 20:06:05 得分 0
agile development反对计划估计？呵呵Top
18 楼zhaoxichao（小西）回复于 2003-12-05 20:28:54 得分 0
过程论者强调的是估计的准确性，以此作为计划的基础，同时也强调计划的完善和周密和遵循计划，以此作为跟踪监督的基础，如CMM的SPP和SPTO
而敏捷论强调的是对变更的相应，构架计划时候注重灵活和适应，只对近期计划强调仔细，远期的计划需要不断的精华，这样对规模估计相对来说要求没有那么高，更注重相对性，我从来没有看到那个人去估计素材实现要多少行代码
当然我更倾向于后者Top
19 楼ozzzzzz（希望敏捷）回复于 2003-12-05 21:19:04 得分 0
zhaoxichao(小西)
嘿嘿，看来你还是没有我学习CMM多啊。CMM有自己带的方法了，TSP/PSP就是了，一个爸爸养的儿子自然最亲，可惜又不能强制，只好明里暗里的下功夫了。
其实那个体系总是强调量化的指标，并且是绝对量化的指标，所以你会看到很多日代码量，千行代码BUG数之类的数据。而这些东西我实在是看不出在具体实际操作中作出的预测，比我直接使用经验作的估算真的准确多少，而付出的资源代价根本就不在一个数量级。
而实际上敏捷的做法在作迭代规划的时候就必须用到需求评估，其中一个最重要的部分，就是评估一个需求的规模有多大。如果太大不能很容易估算，就把大需求划分为小需求，从而得出其要花费多少资源的结论。客户也就是根据我们这个估算来判断是不是要马上开发这个功能。
Top
20 楼zhaoxichao（小西）回复于 2003-12-08 09:26:29 得分 0
TSP/PSP只是SEI的一个私生子，当然有血缘关系，和CMM一起构成了组织/小组/个人三个层次的过程。但是这个私生子现在并没有被让所有人承认，往往CMM评估并不会提倡你使用TSP和PSPTop
21 楼rolandash（慢鱼）回复于 2003-12-08 10:10:55 得分 10
代码行也好，功能点也好，用例点也好，本质上都没有区别，他们的估计精度在没有先验数据的帮助下，都是差不多的。没有哪个占优势。但用代码行方法的一个表面上好处是，他至少是可以完全量化做纯粹的数字运算的。
但是在有经验数据的帮助时，代码行的精度是好于其他方法的。特别是针对一些专业性比较强的应用。
把代码行理解为仅仅是代码计数器是片面的。代码行方法既可以包含对程序结构的差异考虑，也能包括对重用、修订已有模块的考虑。其实本质上，代码行，功能点，只是一个统计方法而已，所有其他的方法都是可以适用的。
TSP/PSP和CMM是没什么关系的。其实现在软件行业对CMM比较反感，和行业的发展程度是有很大关系的。CMM是在传统的IT制造企业里发展出来的，带着明显的成熟行业的气息。而新兴的软件企业在现有的行业环境下，CMM似乎要沉重了些。但再新兴的行业也会走向成熟，高额的利润也会逐步衰微，这是市场充分竞争的必然结果。软件企业向传统企业的转型也是必然的结果。而现在我们已经清楚地看到了这种趋势。
Top
22 楼MayaMyth（MayaのMythos）回复于 2003-12-08 10:45:31 得分 0
： ozzzzzz(希望敏捷) :"现在很多人又去搞用例点"
这个是什么东东？
估计开发规模，我的做法是把系统细分成小功能，凭经验分配每个小功能所需的工时。
“用例点”，这个不懂，给位给讲讲吧！Top
23 楼ozzzzzz（希望敏捷）回复于 2003-12-08 11:11:05 得分 0
rolandash(慢鱼)
代码行虽然准确，但是却无意义。根本愿意在于实际设计者会选择不同的设计思想，而不同的设计思想带来的代码数量并不一致。可是项目的规模不是建立在这些基础上的，应该建立在需求的基础上。而功能点等方法直接计量的是需求，他们更好的反映的实际的项目规模情况。而对于项目规模的评估，主要是客户方面的最迫切的要求。而作为设计者的我们必须服务于客户的需求，我们采用同一方式进行计量就是尊重客户的一种体现。而实际上，代码的数量已经不能很好的反映你到底作了多少工作。例如BUG的处理，性能的优化调整，很多工作都不可能用代码行来反映。而由于不同的设计思路，这些工作在项目中的比重会有很大的不同。项目的规模如果不考虑这些因素是不合适的。而且设计和分析可以说是现代软件开发中最重要的部分，但是代码行却完全不能反映这两个方面的工作量。所以代码行这个东西，早就被大多数人所抛弃了。
CMM所反映的情况是70年代IBM这样的企业的软件开发情况，它既不是什么传统的，更不是成熟的企业的开发情况。软件企业会走像成熟，但是他们会沿着简单－复杂－简单的这样的途径走下去，而简单才是软件行业最合适的管理和运行手段。CMM不论从什么方面来说都不是一个简单的标准，它带来的手段也不可能是一些简单的手段。
但再新兴的行业也会走向成熟，高额的利润也会逐步衰微，这是市场充分竞争的必然结果。你这段话说的很好，可是这正好是CMM的最大的弱点所在，过高的管理成本。有句关于CMM的笑话，CMM对软件企业是很有好处的，当然是在软件企业还没有破产的情况下。现在任何人包括SEI，也承认实施CMM的成本是很高的。我就怎么也看不出，一个利润逐步逐步走下坡路的行业还会使用一个高成本的手段。况且实际情况刚好和你说的相反，敏捷方法发展最迅速的就是最近几年，而CMM发展遇到最大问题的也是最近几年。为什么在网络泡沫的时候CMM会大发展，而衰退的时候会让敏捷大发展。原因没有别的，就刚好说明在泡沫时期，很多不懂软件的人进入软件行业，他们迫切需要一个标准性的东西执导他们的实践。而CMM这种看似和传统行业方法近似的标准就正好符合他们的胃口。而当他们实际操作一段时间以后，要么随着泡沫的破碎离开软件行业，要么被迫去遵从软件行业的固有规律。
而CMM作用就在于可以判断一个企业是不是可以完成外包工作的要求，如果你不作外包，你就不要去考虑这个标准。DoD也不是所有的东西都要求CMM的，win他们也用，现在linux也要用，就更不要说数据库等等工具。其实看看ADA的情况就可以明白CMM到底会有什么样的未来。Top
24 楼ghthlz（涛涛）回复于 2003-12-08 23:05:46 得分 0
我不想结贴，讨论继续吧，这些都是我们要学习的。Top
25 楼rolandash（慢鱼）回复于 2003-12-09 15:10:14 得分 0
ozzzzzz(希望敏捷) :
如果说不同的设计思想带来的代码数量并不一致的话，那么同一个功能点同样可以有不同的设计思想。需求是项目规模估算的入口点，虽然我很希望仅仅用需求的几个功能点就可以向客户刻画一下项目的规模，但是实际上但最终还是要落实到如何设计和实现这些需求上。那么如何评估对同一个功能点的不同设计方案的工作量呢？如果答案是根据经验直接给出个时间的话，那么我想说的是，实际上在估计者的脑子里的计算过程被有意的忽略了。对于重用、修改的情况也是一样的。
举个例子再看看这个过程。比如现有的客户的一个功能点可以用我现有的一个模块来实现，只要“增加一个对象，修改一个属性，和增加几个相应的接口方法”。这个时候会如何来估算工作量呢？是直接想了想，说“恩，2天吧”吗？那么我想问的是，2天这个数字是如何得来的呢？你的脑子里是否经过了一个想象了需要做多少“动作”，和自己做这个动作的速度呢？还是“2天”就直接地跳了出来？
实际上，脑子里一定是想过了“我”需要改动（增加？删除？）多少对象的属性、方法，那些方法的复杂度和规模如何？而“我”自己在这方面的技能如何（熟练吗？不熟练？）。这样的结果，才能算基本上可靠的数据。而这个过程，就是代码行方法的”规模/生产率=时间“的最朴素的过程。
所以我觉得对于代码行方法的误解在于：
1。代码行不只是个记数器，仅仅数一下实际模块的绝对长度就完了。代码行是程序员工作量的抽象和数值化体现和象征，和程序具体的尺寸间并没有必然的联系。对一个很大的模块的改动的工作也许却很小，而很小的模块改动的工作量却比较大。无论是软件结构更改也好，增加对象也好，删除代码也好，都可以折算成代码行。
2。功能点可以取代代码行。至少在现在这是不现实的。功能点分划得再细，得到的数据都不可能准确。而如果有人认为可以分的足够细然后再象我上面说的一样直接给个时间的话，实际上脑子里还是在用了代码行的方法计算，只是故意地忽略掉这个过程而已。这就是我为什么一直强调，功能点也好，用例点也好，代码行也好，本质上都是一样的，纯粹是在玩弄文字游戏，最后都逃不掉这一步，如果还希望获得准确一些的数据的话。
至于代码行的折算问题，其实并不困难，只是比较麻烦一些。很多公司不用这个方法，而只满足于粗粗地拍脑袋估计一下，那是和他们公司具体的情况和管理者自身的想法和素质有关。这个就很难说的清楚了。
Top
26 楼ozzzzzz（希望敏捷）回复于 2003-12-10 00:41:22 得分 0
http://expert.csdn.net/Expert/topic/2520/2520088.xml?temp=.5660059
rolandash(慢鱼)
我在上面这个贴讨论了类似的问题，可以参考一下。
我想你的很多东西都是没有经过深入思考，而得到的表面文章。原因可能在于你的时间经验的匮乏。
工作量的含义其实是很复杂的，而我们说一个工程的工作量的时候，也往往是又不同的含义。比如我在作车间主任的时候，一个班组的工作量就是处理若干1099粉末。而车间的工人看来，她的工作量可能更多的是说她干了多长时间的活，出了多少力。我不知道对于这两个数字你是怎么看的，也许你认为工人的那个数字更反映实际的情况。但是在管理上看，当然是我的那个数字更有价值。而我想你可能把准确和精确的的含义混淆了，精确度更高的数据未必就比精确度低的数字更加准确。
实际上在评估那些工作我到底会化多少时间完成的时候，我可能是直接告诉我会用“2天”。而这个直觉建立的基础就是经验，无法依靠直觉的人，我想唯一的问题就在于他对于是否能完成这个工作会那不定主意，这样的人作出的估算不管在什么情况下都可信度不高。这也就是初学者不可信的一个理由，因为他们的经验还不足以支持他们有一个合适的直觉。
而对于你说的“对一个很大的模块的改动的工作也许却很小，而很小的模块改动的工作量却比较大。”你说的很对，但是你还没有看到后面还有是事实，也许你更改了只有一行代码，他更改了1k行，但是这并不能说你修改这一行代码就比他修改1k行会更加轻松。有一个真实的故事，我的一个岁数很大朋友，他们的一台设备坏掉了，他去修理，结果就是换了一个集成块。很多不懂行的人就说这算什么水平，就是一个集成块坏了。可是他化了多少时间去寻找那个集成块那些人就没有考虑。其实问题往往出在一些所谓的软件工程学者以为，开发软件和搬砖头没有本质区别，搬砖头可以按照块了数，写程序自然就可以按行来算。
而你似乎不很熟悉功能点在说什么，因为功能点没有什么划分细还是不细的区别，它只是一套对于程序规模的计算方法，CMM2对于需求的管理中和CMM4的计量中都一般会使用这个体系，这也是现在美国外包收费的主要计算方法，其实就是发包方和设计方计算有多少功能点，然后按照一个点多少钱谈价钱（这在美国有大概的一个标准行情）。谈好后设计者会把功能点乘以一个功能点代表的代码行（这个也有一个标准，不同的语言在不同的行业项目中有不同的标准。但是只能以功能点推测代码行，不能以代码行反推功能点）发包给下一级。为什么会这样玩我想有点脑子的人都明白。
而实际上代码行无法反映实际分析设计的难度，也无法反映调试维护的规模，更无法反映编码阶段的工作量－－因为编码阶段最多的时候是在DEBUG，而不是在CODING。常识性的东西，往往被学者忽视。
Top
27 楼feigmin（慢刀浪子）回复于 2003-12-10 18:29:19 得分 0
“有一个真实的故事，我的一个岁数很大朋友，他们的一台设备坏掉了，他去修理，结果就是换了一个集成块。”＝＝“更换一个电阻收费1美元，找到这个坏电阻收费9999美元”
这两个故事一样经典。Top
28 楼liutygt（）回复于 2003-12-11 10:35:23 得分 0
各位的讨论真是令我获益非浅！！Top
29 楼rolandash（慢鱼）回复于 2003-12-12 10:22:19 得分 0
结贴了？找了半天。。。
我觉得你有几个个概念需要纠正一下，第一，“实际上在评估那些工作我到底会化多少时间完成的时候，我可能是直接告诉我会用“2天”。而这个直觉建立的基础就是经验，无法依靠直觉的人，我想唯一的问题就在于他对于是否能完成这个工作会那不定主意，这样的人作出的估算不管在什么情况下都可信度不高。”
在这个观点里，什么是你的“经验”呢？这些经验到底包含那些内容？如果你把这个“经验”展开的话，那就是我上面说的估算的过程。如果你脑子里没有这些的话，我想的确充其量只是直觉，而不能算是“经验”。对于有经验的人，做一个估计可能很快，不会超过1分种，但不是因为这个过程短，就否认这个过程应当具有的科学性和准确性。经验和直觉的区别就在于，一个是需要数据支持的，有相当的可信度，而一个没有数据支持，可信度不高。把经验和直觉混为一谈是不妥当的。而使用数据和公式来估计，一是跟“拿不定主意”毫无关系，二是可信度和你说的恰恰相反。
这些其实都是西方管理思想的精髓。为什么？直觉有的时候固然可以准确，但是人的直觉是不可靠而风险大的。即使是工作了几十年的老工程师，他的直觉也常常会犯错。管理的目的就是要降低这些风险，10%还不够低，要更小，在直觉的基础上建立可靠的分析体系，把直觉升级为可靠的经验数据，因为你每犯一次错，我就可能少挣很多钱。在我们很多国有企业改革的过程中，这种思想的建立看起来很简单，但其实非常的艰难。尤其是那些自认很有经验的老工人，不习惯，以前估计这个估计哪个，只要嘴皮动动就好了么，现在又要算这个又要算哪个，很烦啊，抵触情绪很大。这些工人技术上很好，但在职业化程度上却比西方的同行们差了许多。从“直觉”到“经验数据”的转化，正反映了一个人的职业化程度。为什么美国人做最简单的算术也要用计算器？其实就是这种文化的一个附带产品。很多人嘲笑他们笨，不过就是这些笨人，做的软件几乎占领了全球的市场。
第二，设计和编码是两个不同的阶段，这两者也不能混为一谈。没有人会用代码行来描述设计的工作量。代码行是用来描述编码过程中的工作量的。当然你可以辩论说，设计和编码能绝对分开吗，难道编码过程中就没有一点点设计了吗？但你无法否认设计的层次，编码过程中的设计是在程序员可控的范围之内了，是程序员的技能之一。所以这个问题是体现在“生产率”上，依靠积累的经验数据来算出比较准确的生产率的值，而不是把这些都混在“工作量”的概念里。那样你解不出这道题。至于Debug，也是一样。这些都是很基本的代码行方法的思想。
你所说的“他更改了1k行，但是这并不能说你修改这一行代码就比他修改1k行会更加轻松”，以及那个换芯片的故事，实际上说的就是公式里的“生产率”这个因素。当然生产率不是永远不变的，个人也不同，但可以有一个统计的平均值。
第三。你下面提到了目前美国外包的做法。“设计者会把功能点乘以一个功能点代表的代码行（这个也有一个标准，不同的语言在不同的行业项目中有不同的标准。但是只能以功能点推测代码行，不能以代码行反推功能点”
这里我不太明白你真实的意思，因为你说的这些不正是我前面说的观点吗？最终你是绕不开代码行的。代码行的方法也从来都是从需求入手，做功能分解，然后设计并估算工作量。从来没有过从"代码行反推功能点“的说法。所以我觉得不太理解你的观点。
至于前面你提到第一承包直接用功能点结算，我想你可能是没有仔细考虑直接用功能点结算的两个前提，一是应用领域解决方案比较成熟，基本不需要做大量新的设计和改动。二是功能点趋于相似。但这不能说明功能点就可以脱离代码行而存在，只是因为领域内大家已经建立了比较稳定可靠的经验数据，可以把每个点折算成直接可用的类似价格列表这样的东西供大家使用，否则不是你亏就是你的客户要亏。这就好比我们以前有对数表可以直接差出对数计算结果，但这绝不是说求对数的方法就过时和没用了。因为毕竟还有大量的软件系统是无法套用现成的解决方案的。
其实这些并不是学术上的问题，是很纯粹的工程问题。但是工程问题并不代表不需要精确，因为归根到底，钱是精确量化的啊。。。
Top
