更新時間：2025-06-08 12:47:20
網站建設
440
網站建設現在是一個信息的載體，把有用的信息傳播給需要的人。網站建設包括軟件。在擔任多起軟件訴訟案件專家證人的工作中，筆者注意到一個長期存在的軟件項目管理問題。許多失敗的項目，以及進度嚴重延誤或重大質量問題的項目，都是在開發過程中通過正常的進度報告發現的。從各種證人證言和案件證據中可以看出。軟件工程師和一線項目經理都知道自己的項目存在問題，但是當這些問題第一次被發現時，項目經理并沒有將這些問題寫入給客戶的報告和高層的狀態報告中。直到很久以后，當嚴重的進度延誤、質量問題或其他重大問題真正被高層管理人員或客戶認識到時，情況往往是不可逆轉的。
當被問及為什么要隱藏項目中存在的問題時。我得到的大部分答案是，下級管理人員不希望高級管理人員看到項目的糟糕狀態。當然，當問題最終浮出水面時，底線管理人員實際上相形見絀。成功的軟件項目總是以更理性的方式處理項目中的問題。他們及早發現問題，組建專門的工作組來解決問題，并經常在問題變得嚴重到無法解決之前將其控制住。敏捷方法的一個有趣特征是每天討論項目中的問題，團隊軟件過程(TSP) 也是如此。
軟件項目的問題有點像嚴重的醫療問題。它們通常不會自行消失，需要許多專業的“療法”才能消除它們。軟件項目的問題有點像嚴重的醫療問題。它們通常不會自行消失，需要許多專業的“治療”才能擺脫它們。軟件項目啟動后，通常沒有固定、可靠的準則來判斷項目的實際進展速度。民用軟件行業長期以來一直使用特定的里程碑來確定項目進度，例如設計完成或編碼完成。但這些里程碑也是出了名的不可靠。
軟件項目狀態跟蹤需要解決以下兩個不相關的問題：(1) 達到特定的、定義的里程碑； (2) 在規定的預算金額內使用項目資源和資金。由于軟件項目里程碑和成本受到需求變更和“范圍擴展”的影響，因此擴大需求變更變得很重要，因為這些變更會影響功能點的總數。但是，正如本章上一節所述，一些稱為“需求波動”的需求變化并不影響功能點總數，而需求蠕變和需求波動往往是隨機出現的。需求波動比需求蠕變更難衡量，只能通過“回火分析”或程序代碼語句數與功能點指標之間的數學換算來衡量。
截至2009 年，有許多自動化工具可以幫助項目經理記錄項目里程碑報告所需的各種重要信息。這些工具能夠記錄項目進度、資源、規模變化和各種項目問題。對于一個擁有60 年悠久歷史的行業來說，沒有一套通用或通用的項目里程碑來標記項目的實際進展，這多少有些令人驚訝！
我們專注高端建站，小程序開發、軟件系統定制開發、BUG修復、物聯網開發、各類API接口對接開發等。十余年開發經驗，每一個項目承諾做到滿意為止，多一次對比，一定讓您多一份收獲！
