網(wǎng)站建設(shè)軟件進(jìn)度與問題跟蹤

2019-04-22

網(wǎng)站建設(shè)在現(xiàn)在是一種信息的載體，給需要的人傳播有用的信息，網(wǎng)站建設(shè)就包括了軟件這塊，在很多軟件訴訟案件中擔(dān)任專家證人的工作中，筆者注意到一個(gè)長期存在的軟件項(xiàng)目管理問題。很多失敗項(xiàng)目以及出現(xiàn)嚴(yán)重進(jìn)度延誤或重大質(zhì)量問題的項(xiàng)目在開發(fā)期間通過正常的進(jìn)度報(bào)告并沒有發(fā)現(xiàn)任何問題。從各種證人證詞和案件舉證中可知.軟件工程師和一線項(xiàng)目經(jīng)理均知道他們的項(xiàng)目中存在問題，但是當(dāng)首次發(fā)現(xiàn)那些問題時(shí)，項(xiàng)目經(jīng)理并沒有第一時(shí)間將這些問題寫進(jìn)匯報(bào)給客戶和高級管理層的狀態(tài)報(bào)告里。直到很晚之后，當(dāng)更高管理層或客戶真正認(rèn)識到嚴(yán)重進(jìn)度延誤、質(zhì)量問題或其他重大問題時(shí)，形勢通常已無法扭轉(zhuǎn)。

當(dāng)問到為什么要隱瞞項(xiàng)目中存在的問題時(shí)。得到的答案大多數(shù)都是基層經(jīng)理們不希望高級管理層看到項(xiàng)目的糟糕狀況。當(dāng)然，當(dāng)問題最終浮出水面時(shí)，實(shí)際上基層經(jīng)理們看起來更糟糕，相比之下.那些成功的軟件項(xiàng)目總是以更加理性的方式處理項(xiàng)目中存在的問題。他們能盡早發(fā)現(xiàn)問題，組建專門任務(wù)小組來解決這些問題，且通常在這些問題變得嚴(yán)重到無法解決之前就能控制住局面。敏捷方法一個(gè)有趣的特色是每天討論項(xiàng)目中存在的問題，團(tuán)隊(duì)軟件過程(TSP)同樣如此。

軟件項(xiàng)目的問題有點(diǎn)兒像嚴(yán)重的醫(yī)療問題。它們通常不會白己消失，為消除這些問題，需要許多專業(yè)的“治療“方法，軟件項(xiàng)目的問題有點(diǎn)兒像嚴(yán)重的醫(yī)療問題。它們通常不會自己消失，為消除這些問題，需要許多專業(yè)的“治療“方法。軟件項(xiàng)目一旦啟動，通常沒有固定、可靠的指導(dǎo)性方法來判斷項(xiàng)目實(shí)際進(jìn)展速度。長期以來，民用軟件行業(yè)一直使用特定里程碑的方法來確定項(xiàng)目進(jìn)度，比如設(shè)計(jì)完成或編碼完成等。但是，這些里程碑也是出了名的不靠譜。

軟件項(xiàng)目狀態(tài)跟蹤需要涉及以下兩個(gè)彼此不相關(guān)的問題:：(1)達(dá)到具體、確定的里程碑；(2)在明確的預(yù)算金額內(nèi)消耗項(xiàng)目資源和資金。由于軟件項(xiàng)目里程碑和成本受需求變更和“范圍鑒延”的影響，當(dāng)這些變化影響了功能點(diǎn)總數(shù)時(shí)，對需求變更的規(guī)模增長進(jìn)行度最就變得非常重要。然而，正如本章上一節(jié)提到的.某些稱為“需求波動”的需求變更不影響功能點(diǎn)規(guī)?？倲?shù)，而需求蔓延和需求波動往往又都隨機(jī)出現(xiàn)。需求波動比需求蔓延更加難以度量，往往只能通過程序派代碼語句數(shù)量和功能點(diǎn)指標(biāo)之間的“逆火分析”或者數(shù)學(xué)轉(zhuǎn)換來進(jìn)行度量。

截至2009年.已有許多可用的自動化工具幫助項(xiàng)目經(jīng)理記錄項(xiàng)目里程碑報(bào)告所需要的各種重要信息。這些工具能夠記錄項(xiàng)目進(jìn)度、資源、規(guī)模變化以及各種項(xiàng)目問題。對于一個(gè)具有60年悠久歷史的行業(yè).卻沒有一套通用的或普遍的項(xiàng)目里程碑來標(biāo)示項(xiàng)目實(shí)質(zhì)性進(jìn)展情況，這多少有些令人吃驚！

文章內(nèi)容來源于網(wǎng)絡(luò)，侵刪

知識產(chǎn)權(quán)

工商財(cái)稅

數(shù)字化建設(shè)

資質(zhì)認(rèn)證

人事服務(wù)

網(wǎng)站建設(shè)軟件進(jìn)度與問題跟蹤

推薦閱讀