PS:本文是由半導結合國外資料和自己經驗總結的

懇請各位網友批評指正

發言人 semicon 

    軟件開發是一項復雜的工作,對于軟件開發的管理和控制,發

展出一門專門的學科:軟件工程。在這方面有許多的國家標準和

國際標準。但軟件工程更多的是從技術的角度來規范軟件開發的

管理和控制,本文試圖從管理者和實踐的角度來闡述一些軟件開發

的管理和控制所應遵循的基本原則。

    在軟件開發項目中經常出現二種極端情況:一種是創造了新的

生產率和質量的紀錄;一種則完全是一場災難,不是被取消就是拖

延很長時間。通過提煉這些成功和失敗的例子,軟件項目成功或失

敗的根本原因可能會更清晰一些。

    在討論這些原因之前,我們先來定義一下什么情況可以稱為失

敗的軟件項目。

    1. 由于費用超支或計劃執行超時而終止。

    2. 完成計劃的時間或費用超過了原計劃的50%。

    3. 由于質量或性能上的原因引起和客戶的糾紛。

    下面我們將按其影響大小的順序排列說明5種錯誤的實踐方式。

錯誤1:沒有軟件開發的歷史數據

    缺乏軟件開發的歷史數據是大多數軟件項目失敗的關鍵所在,

這樣的結論也許使很多人感到吃驚,但事實就是如此。沒有一個可

靠的軟件開發的歷史數據會使項目經理,程序員,客戶對于軟件開發

的過程缺少清醒的認識。

        假設現在你正在管理一個軟件項目,而這個項目還沒有一

個公司在36個月內完成。作為一個負責的經理,你作了一個比較細

致和保守的估計,然后告訴你的客戶和你的手下說你認為這個項目

需要36―38個月完成。然而常常有這樣的情況發生：你的客戶和程

序員要求把時間壓縮到18個月。客戶一方面希望軟件盡早投入使用

而產生經濟效益,一方面也想壓縮項目時間作為一個討價還價的籌

碼;而程序員一方面可能過于自信,一方面盡早結束項目也能使他們

多賺點錢。而此時你的手頭上也沒有一個可靠的軟件開發的歷史數

據,在他們的壓力下你同意了18個月的計劃,于是一場災難開始了。

在項目的開始階段你發現計劃被拖延了,于是開始向程序員們施加

壓力,要求他們加快進度,程序員為了追求進度而不得不把其它指標

放在一邊,這些問題不斷的積累下來而項目經理卻蒙在鼓里。到了項

目中后期這些質量問題會不斷暴露出來,而且互相關聯并且難以解決,

甚至有些是系統設計的問題,這時才發現好多模塊要推倒重來,18個月

完成計劃變成了天方夜譚。雖然上面只是一個虛擬的例子,但在實際

中這種情況比比皆是。問題的關鍵就在于軟件開發的歷史數據是反映

軟件開發隊伍的能力的標尺,沒有了這個標尺,就無法對軟件的開發過

程有一個清醒的認識。

錯誤2:不重視使用軟件費用估值工具軟件和計劃工具軟件

    國內的軟件公司大多數是處在“十幾條槍,一個手工作坊”

的水平上,在承接軟件開發的項目之后往往是幾位骨干人物討論之后

對費用和進度作一個大致的估計,然后就開始進入項目的執行。這種方

法帶有明顯的主觀性。在作一個精確的軟件費用估計和作一個比較現

實的項目開發計劃時需要考慮許多因素。對于一個大的軟件項目,用手

工作費用估計和作計劃是不能勝任的。現在國外市場上有大約50種商

業軟件費用估計工具包和大約100種商業項目計劃工具包,使用他們作

精確的估計比手工的估計更可能獲得成功。常用的軟件費用估計工具

軟件有Checkpoint,Colomo,Estimacs,PRice_s,Slim。 常用的項目管

理軟件有MS Project,Primavera,Project Manager*s Workbench,

Timeline。把這二種工具軟件聯合使用可以互為補充,幫助經理駁回

客戶和程序員的無理要求并且能精確的控制項目的執行。

錯誤3:忽視用戶的需求的變動

    盡管最初的用戶需求在簽定開發合同時已經包含在需求說明書中,

但在整個開發周期中期望用戶的需求一直保持不變是不大可能的,因

為用戶對于如何應用計算機軟件并沒有一個成熟的經驗。在項目進行

中用戶的需求會不斷的增長,一般情況下用戶的需求以每月1%的速率增

加,如果一個項目在12個月內完成,最終將有超過10%的改動,如果項目

要持續36個月,最后將增加1/3的功能。每月1%也只是一個經驗數據,一

個缺乏計算機應用經驗的用戶會更頻繁的改變和增加他的要求。因此

在作項目的費用和時間估計時一定要考慮用戶需求的變化。一種比較

明智的方法是在簽定開發合同時把用戶需求的改動和經濟利益掛鉤,如

果用戶增加或改動了需求,那么軟件的交付日期可以推遲,費用也應增加。

錯誤4:忽視監督項目的進度

    到目前為止,軟件產業還沒有一個標準的項目進度的檢查標準。一

個比較清晰的尺度是用已經實現的軟件功能反映項目的進度。但這種方

法是否就是最科學的衡量標準,現在還不能定論,畢竟在一個軟件項目中

軟件功能只是一個主要而非全部的任務。因此一個項目經理在監控項目

執行時不應該只關注實現的軟件功能,還要關心文檔,測試,技術支持這些

因素。在實際工作中我們經常聽到經理或程序員說這樣的話:“項目已經

完成了90%”,這種結論帶有明顯的主觀性,一個優秀的項目經理不應該被

手下的判斷所迷惑,而應該按照一個比較客觀的標準去深入檢查。

錯誤5:忽視設計復查和代碼復查

    很多程序員習慣于這樣一種工作方式:只做不想。他們更關心每天

可以寫多少行代碼,完成幾個模塊。在這種態度下,他們都很不愿意復查

自己的工作,而習慣于在軟件測試階段把隱藏的錯誤改正過來。但設計復

查和代碼復查在大型的軟件項目中已經有30年的應用歷史,而且已經被證

明在設計和代碼編寫階段的復查比軟件測試更能有效的消除錯誤,一些經

驗數據表明,在設計和代碼復查時發現的錯誤是在同等工作量下軟件測試

發現的錯誤的兩倍。

結論:

    軟件開發是一個帶有一定風險的工作,為了把風險降到最低, 在項目

的執行中項目經理必須嚴格的監督項目的進度,對程序員不愿復查的壞習

慣要給予糾正。項目經理必須要從軟件開發的歷史數據和輔助工具包提

供的數據中作出精確的估計,在作估計時他應該考慮為不斷變化的用戶需

求留出富余量。

摘自： bbs.net.tsinghua.edu.cn