A. 修復成本與重置成本區別
修復成本是在機器設備等已存在的基礎上，增加修理材料和修理人工等修理費用發生的成本；
重置成本是假設機器設備不存在，現在要重新購置這樣一台成新度的機器需要花費的成本。
就好比你自行車胎壞了，一條鋼絲斷了，修復成本可能就是換個胎，加根鋼絲的成本；
而重置成本就是你到二手自行車市場買輛類似自行車的成本。
B. 一個文件恢復軟體為什麼要錢是因為開發難度大還是成本高
一般來說，像「文件恢復」、「數據還原」這類需求都是很迫切的剛需，因為只有很重要的文件和數據才需要恢復和還原，所以收費高也是正常的，這跟開發難度和開發成本沒有半毛錢關系。就像你用一根繩子把一個落水的小孩救起來，這本身沒有什麼技術含量，也不需要什麼成本，但你救起的卻是一條實實在在的生命啊，所以事後你獅子大開口別人也不會說什麼啊，對吧？
你如果覺得收費高不可接受，你完全可以不用啊，但你的文件可能就永遠和你拜拜了！
C. APP軟體運營 維護成本有哪些
APP軟體運營 維護成本有哪些
簡單點來說，要視手機APP的需求及質量而言，價位一般在幾千到十幾萬左右，更高端的價格更高。
四、APP開發公司的所在地
需要注意的是，同樣實力的APP開發公司，在不同的城市也會導致APP的成本費用高一些，如在北京、深圳和上海等地的開發公司開發成本費用就會比較高，因為當地開發人員的薪資和其他支出相對更高。
D. 目前有哪些軟體維護成本估算方法它們分別有什麼特點
常用的有4種估算方法。
這4種軟體成本估算方法分別是：
以「估」為主的——經驗法和類推法
以「算」為主的——類比法和方程法。
經驗法：經驗法也叫專家法，是由行業內經驗豐富的專家背靠前一起依據自己的行業經驗對軟體項目進行整體的估算。前期的經驗法基本上屬於拍腦袋來進行項目的大概估算，後續的經驗法便基於WBS的軟體進行估算和加進了DELPHI/加權平均。這種方法依賴評估人員的主觀性過大，所以估算出的結果誤差較大。
類推法：類推法是基於量化的經驗進行估算的。採用類推法時，所選擇的歷史項目與待評估的項目一定要是高度相似的，歷史數據也要盡量選擇本組織內的數據，並且一定要對差異之處進行調整。類推法雖然是迄今為止理論上最可靠的估算方法，由於它是以「估」為主的，脫離不了評估人員的主觀性，所以使用類推法的估算結果經常產生極大偏差。
類比法：類比法是基於大量歷史項目樣本數據來確定目標項目的預測值，通常是以50百分位數為參考而非平均值。當待評估項目與已完成項目在某些項目屬性（如應用領域、系統規模、復雜度、開發團隊經驗等）類似時，可以使用類比法。類比法的行業基準較少，此時可以通過選擇單個項目屬性進行篩選比對，根據結果再進行工作量調整。
方程法：方程法是基於基準數據建模，可以行業數據與企業數據相結合，通過輸入各項參數，確定估算值。
E. 在軟體生命周期的哪一階段，軟體缺陷修復費用最低
你提出的問題，很有水平！軟體工程師編程寫作都需要防範缺陷的問題。因此，一般存在缺陷的軟體生命周期是指一個好的軟體缺陷被發現後，要接收到報告到這個缺陷被修復、驗證的過程。直至最後關閉的完整過程階段。 關閉這個軟體是對這一階段中的應用，但不能說「關閉」這個軟體是失敗。希望能夠幫助到你並對你的啟發。
F. 軟體測試哪個階段修復缺陷的成本最低
需求階段，在需求階段可能只需要改幾個字的事，在後面要能就需要幾千到幾萬的修復成本，BUG越往後修復的顧本越高~
G. 成本維修是什麼意思
成本維修就是保修范圍外的維修。
維修有三種釋義，分別為更換配件、維修配件、根據功能改修，維護和恢復，維護、保養、修理。
家電維修常識包括手機維修、電腦維修、家電維修汽車維修。對於手機而言，軟體更新升級也納入了維修項目之內，對於汽車而言撬鉚噴漆也屬於維修范圍。
設備維修是指設備技術狀態劣化或發生故障後，為恢復其功能而進行的技術活動，包括各類計劃修理和計劃外的故障修理及事故修理。又稱設備修理。設備維修的基本內容包括：設備維護保養、設備檢查和設備修理。
是對維修活動的分類，以便於管理與作業，從不同的角度出發，維修有多種不同的分類方法。
（1）按維修的定義，分為維護與修理，其中，維護也稱為保養。
（2）按維修目的與時機，分為預防性維修與修復性維修。
（3）按維修活動計劃與否，分為計劃維修與非計劃維修。
（4）其他維修類別。改進性維修和戰場搶修。
H. 軟體缺陷的修復代價
在討論軟體測試原則時，一開始就強調測試人員要在軟體開發的早期，如需求分析階段就應介入，問題發現的越早越好。發現缺陷後，要盡快修復缺陷。其原因在於錯誤並不只是在編程階段產生，需求和設計階段同樣會產生錯誤。也許一開始，只是一個很小范圍內的錯誤，但隨著產品開發工作的進行，小錯誤會擴散成大錯誤，為了修改後期的錯誤所做的工作要大得多，即越到後來往前返工也越遠。如果錯誤不能及早發現，那隻可能造成越來越嚴重的後果。缺陷發現或解決的越遲，成本就越高。
平均而言，如果在需求階段修正一個錯誤的代價是1，那麼，在設計階段就是它的3～6倍，在編程階段是它的10倍，在內部測試階段是它的20～40倍，在外部測試階段是它的30～70倍，而到了產品發布出去時，這個數字就是40～1000倍，修正錯誤的代價不是隨時間線性增長，而幾乎是呈指數增長的。
軟體未達到產品說明書表明的功能。
軟體出現了產品說明書指名不會出現的錯誤。
軟體功能超出產品說明書指名范圍。
軟體未達到產品說明書雖未指出但應達到的目標。
軟體測試人員認為軟體難以理解、不易使用、運行速度緩慢，或者最終用戶認為不好。
一般我們都認為測出一個問題就是一個bug，其實這是不對的，假設測試10個問題就10個bug，而修改一出就全解決了，程序員肯定認為冤枉自己。
所有軟體是文檔，代碼等組成的，最初的錯誤是來自於這些軟體錯誤(software error)，如代碼中加法寫成減法。軟體錯誤導致軟體缺陷(software defect)，如設計缺陷，代碼缺陷等，可用靜態測試，如走查，靜態檢查，測試床（軍事軟體用的技術）等，軟體的缺陷導致一個或多個軟體故障 (software fault)，故障有內部故障，外部故障，也就是我們所說的bug，軟體故障導致了軟體在功能操作等方面的失效(software failure)。
我們平時測的bug實際上是軟體故障於失效的體現。一旦軟體錯誤得到修改，相應的故障與失效也就解除了。這樣分有助於我們定位問題，找到問題。
詳見《軟體可靠性工程》