軟體工程工作量的估算

這段時間在想關於軟體工程的問題。

記得以前看過軟體工程方面的書，但是很多東西都已經忘了，所以我也就從自己的實際出發來思考軟體工程的問題。首先，從最近的北京報表之行吧，記得大/r 約兩三周前，我數了一下我那時已完成的工作。因為我習慣會給自己列一個詳細的功能點，完成了就打個勾。結果我數了一下，並按照實際完成情況，發現我大約也 就是一天完成一兩個功能點左右，也就是我一個月下來大約30-40個點。

我自己定義的點粒度大概為介面上一個滑鼠或者鍵盤操作帶來的其它變化，譬如拖動一個Tree的節點到一個列表中放開，則列表有對應的項；又如，添加 一個過濾字串的選擇，則可以過濾掉Tree的對應節點。當然有的功能點和已經完成的功能點比較相似的話，完成就是複用代碼的事情，所以還是比較容易的， 如果想對比較容易的話，就不算功能點了；當然如果一些已經很熟悉的架構代碼也就不算什麼功能點了；所以功能點在我的定義中是，讓我覺得我必須花時間去設計 才可完成的功能。

當然我也不會覺得一兩個功能點一天有什麼不妥，只是覺得好像這些功能點如果有個比較傻的機器人來寫倒是不錯。之後我又覺得，是不是我的工作效率一直 就是這個一兩個功能點每天呢？於是我就想，我可以考慮數一下之前花了大約3個多月時間寫的文檔產生的那個項目。但是一時我不高興數，於是估計了一下，20 天*3.5月*2個大約是140個功能點，之後我又想如果我這個是平均效率的話，那麼另外一個組在做的jsp編輯器的功能點是150個*4人大約600多/r 個吧，不過當時只是這麼想著，並沒有立刻去數。

今天覺得，如果把東西給記錄下來，估計會忘掉的。於是我決定數一下文檔產生我大約實現了多少個功能點。數的結果是介面上大概40個左右，三種文檔本 身大約有50個左右，而底層文檔產生工具實現的功能點大約20多個，效能方面的功能點10-20個，總體的功能點個數和我之前估算的相差不是很大。再想去 數那個jsp編輯器的功能點，大概數了一百多個的時候，我放棄了，因為我發現我不知道很多實現方面的細節，而我又知道這個編輯器用了ibm的一個架構，所/r 以具體該如何數只屬於這個四個人在這段時間添加的功能點，我無法判定。不過我相信功能點也在我估算的範圍。

之後我也就想起了原來尚未擴充的jsp編輯器，我稍微想一下，那個編輯器大概也就是10個功能點左右吧（主要是eclipse的text editor吧），那麼從10個功能點一下子擴充到600多個（或者實際上是1500多個？）功能點，這裡面的開發模式應該是如何處理的呢？這個好像，還 是挺有學問的，我認為。首先擴充功能點到10倍，可能是一種情況；再在10倍的基礎上擴充10倍，這也是一種情況；而一下子擴充100倍，也是一種情況。 10倍10倍地擴充，則屬於一般人可以控制的範圍，但是如果一下擴充100倍（甚至1000倍）的話，已經不能算是簡單的功能擴充了，而更多的是涉及到新 的架構的編寫或者介入，新的工程管理員模式，所以也是存在比較大的風險。

其實任何一個東西，都可以進行功能點的擴充，很熟悉的“記事本”，有人擴充為“ultraedit”，則這裡面的功能點擴充至少是1000倍了。這/r 就要求一個軟體工程在功能點數上的限定了，譬如說我這個東西我本來就只是想弄得簡單點的，你就甭給我擴充了。一個編碼人員沒有節制地給你添加新的功能點只 會增加總體成本，成本的增加可能並不能夠在軟體的收益上得到回報，所以從一定程度上說，你老實點給我把必須的一些功能做好了就夠了，甭天馬行空了。這個我 在文檔產生的實現上是有教訓的。文檔產生的東西確實你可以無限的做，大不了還可以引入一套類似編輯word文檔的編輯架構來做。但是這絕對是不對的，絕對 是錯誤的。

但是還有另外一個問題，所謂的設計完整性問題。一個設計，如果就設計那麼不多不少的功能點，那麼可能會帶了設計完整性的問題。就如一個jsp編輯 器，如果你從15個功能點開始擴充10倍到150個功能點，那麼這沒有質的變化，甚至給人的感覺是怎麼這個東西總是那麼讓人彆扭，提供了一些比較有用的功 能，可是確不做好，只做了一半，沒有做完整。這個對於設計者來說，應該注意的，要麼你就直接擴充100倍，要麼你別擴充了。所以有時候編碼人員很容易不注 意地擴充了功能點，造成設計和過程管理的衝突。另外的是給編碼人員一個閾值，譬如可以跟編碼人員說：嘿，你把這裡面的一些功能擴充一倍就到頂了，別多弄了 啊。當然編碼人員從那些方面和如何擴充功能點，以及設計人員設定擴充多少倍的功能點，就要看人員的水平了。

說了這麼多，說回來我的實際經曆的情況。我重新查看了一下之前幾個月的代碼情況，突然發現我平均每個月貢獻的程式碼數大概是10000多行，平均下 來每天500多行，當然如果去掉一些無用程式碼片段和注釋的話，大概在每天400行左右，之後想想，好像太多了點，是不對的，代碼品質不能保證。想查一下大概 什麼範圍的程式碼數是正常的，不過倒是發現其實程式碼數多少是無所謂的，有兩篇文章寫的還不錯：
1．It's Not About Lines of Code --By Charles Connell
http://www.developer.com/java/other/article.php/988641
2．軟體開發過程的定量監理 作者：中國軟體評測中心 陳兵
http://tech.ccidnet.com/pub/article/c29_a77106_p1.html
雖/r 然程式碼數不是什麼問題，還是值得關注的，譬如我在剛過去的9月份，就往報表的項目裡添加了20000行新代碼！而報表還準備10月初封代碼的，這個…… 我添的代碼是否太多了？是否我這個月來擴充的功能點倍數太大了，是否應該重新調整一下產品的品質，以保證軟體工程管理能按時按點進行？這個是值得深思的問 題。

記錄下來，以免以後忘了自己曾這麼思考過軟體工程的問題。

October 02 12:42 PM