2023年11月10日，由工業和資訊化部電子工業標準化研究院指導、北京軟體造價評估技術創新聯盟主辦的2016(第一屆)中國軟體估算大會暨2016軟體行業基準資料發布會在北京麗亭華苑酒店拉開帷幕。
本次大會由工信部電子工業標準化研究院、北京軟體造價評估聯盟、北京軟交所三方聯合發布的「2023年中國軟體行業基準資料」引起了業界的廣泛關注。會後賽迪網記者也有幸採訪到了北京軟體造價評估技術創新聯盟代寒玲秘書長、首席度量專家王海青以及中國郵儲銀行總行資訊科技部專案管理處副處長段永政。
三位被訪人站在聯盟、專家、使用者的角度解讀了軟體行業基準資料發布的背景和價值。
軟體市場缺失的那架「軟體價值公平秤」
北京軟體造價評估技術創新聯盟代寒玲秘書長
北京軟體造價評估技術創新聯盟代寒玲秘書長為賽迪網記者介紹了聯盟成立的背景和意義。近些年我國軟體和資訊服務業發展很快，2023年年收入額已經超過4萬億。而在各行業資訊化過程中，如何對軟體價值進行衡量、如何度量和評估軟體專案的成本，是大家普遍關心的問題，因為這牽扯到資訊化建設單位的預算管理，影響到軟體專案的招投評標活動，也影響到甲乙方之間的商務結算。
過去大家都普遍採用的專家經驗法，雖然能起到一些作用，但是侷限性也很明顯，使用這種方法時會受到專家經驗的侷限性影響。在評審會上，對同乙個專案，不同專家估算出來的結果有時會差距非常大，而且也沒有很好的辦法來評價哪個專家的估算結果更準確，這就給主辦方的決策帶來極大風險。最關鍵的一點，等專案做完了發現實際發生費用與計畫費用差距很大時，也不知道究竟是什麼原因導致的偏差，究竟是軟體規模估的不准呢，開發團隊的效率發生偏差呢，還是需求變更導致的。就更談不上用量化的方法來管理和改進提公升了。
這些年因為軟體造價評估技術、方法和標準的缺失，在軟體專案招投標活動中常常會發生「0元中標」、「10元中標」的現象；同乙個招標專案，不同廠商**相差幾倍的現象也常常發生；專案結項時甲乙方因為對專案的造價數額達不成一致、進而引發糾紛甚至進入司法程式也屢見不鮮。
因此，為了促進對軟體費用和造價評估技術、方法和標準的研究，傳播和推廣科學的軟體造價評估理念和方法技術，提公升軟體專案的量化管理水平，規範資訊化軟體專案費用造價的管理，北京科信深度科技****聯合中國科學院軟體研究所、神州數碼等單位共同發起成立了北京軟體造價評估技術創新聯盟。聯盟的性質是非盈利性社團法人，在北京市民政局登記成立。也是國內唯一乙個專注於軟體造價評估的社團組織。
代秘書長在受訪時介紹了國內軟體造價相關標準的研製情況。工業和資訊化部於2023年下半年發布了行業標準《軟體研發成本度量規範》，北京市質監局於2023年下半年發布了《資訊化專案軟體開發費用測算規範》。但這僅僅是乙個開始，後面工信部電子工業標準化研究院還將成立標準工作組來整體推進，軟體造價聯盟將會積極參與並發揮其技術優勢。聯盟當前的核心工作也是緊緊圍繞軟體造價評估技術和標準的研究與推廣展開，不斷地推進軟體造價評估技術的創新，使軟體造價評估更加專業化、科學化。目前正在以核心單位身份參與編寫的標準有三項，工信部標準化研究院牽頭編制的《軟體成本度量標準實施指南》的軟體研發費用部分，預計2023年上半年會正式出版；與北京軟交所、北京科信深度公司共同牽頭制定兩項北京市地方標準《資訊化專案軟體運維費用測算規範》《資訊科技軟體專案測量元》目前正在徵求意見，預計2023年上半年能正式發布。聯盟另外一項非常重要的工作就是建設和維護中國軟體行業基準資料庫，每年發布行業資料，供廣大使用者和廠商參考使用，支撐以上各項標準的落地。
行業基準資料：軟體造價評估的基礎和保障
已經發布的和正在研製的軟體成本度量相關標準倡導使用量化方法、使用行業基準資料來估算軟體專案的成本和費用。因此權威的行業基準資料是標準落地實施的重要支撐與依據。
北京軟體造價評估技術創新聯盟首席度量專家王海青
由於測算出來的費用涉及到甲乙雙方的經濟利益，所以權威、可信的行業基準資料不但可以幫助甲方進行合理的費用測算和預算，還能使得乙方獲得乙個合理的利潤。最終使得乙方專注於提高生產率和管理水平，獲得公允價值之上的利潤，形成乙個迴圈受益的良性發展趨勢。軟體行業基準資料的出台，將使得甲乙雙方獲得共贏。 因此，甲乙丙方都希望有乙個中立的組織，能夠維護乙個權威的、中立的行業基準資料庫，發布權威的行業基準資料。
據王海青介紹，本次發布的2023年中國軟體行業基準資料，所依賴的是國內最大的行業級基準資料庫的分析結果，資料來自國際相關組織、聯盟內的成員單位以及標準落地為企業提供評估或諮詢服務中收集。
這些資料涵蓋了電子政務、金融、電信、能源、製造、交通等行業的高可信度資料約7000套。在資料採集過程中，為了保證資料的安全性和真實性，聯盟還會對這些資料進行匿名處理，並且基於提供資料的成員單位提供的資料為他們提供一些免費的諮詢服務。為保證資料的質量，會嚴格執行審核資料的相關流程，對資料的完整性、一致性、合理性等方面進行可信度評價。
王海青提到，目前行業基準資料庫建設的最大難點在於，很多企業都想成為資料的「消費者」而不是「捐獻者」，希望大家能積極地參與資料的提交。對於未來資料庫的建設，王海青表示將擴大資料採集的範圍，並逐步實現平台化資料分析，提高審核的效率。
最後，王海青還透露，未來聯盟會定期發布我國軟體行業基準資料，大家可以通過登入聯盟**免費獲取這些資料。
功能點字典庫：郵儲銀行成本度量有道
在發布會現場，賽迪網記者還有幸採訪到了本次獲得「工信部標準軟體研發成本度量規範2023年應用示範單位」的郵政儲蓄銀行總行資訊科技部專案管理處副處長段永政，作為銀行業軟體成本評估的先行者之一，段永政表示隨著該行組織級量化管理的不斷提公升，以及銀行合規性的需求日益嚴苛，高層領導對資訊化管理的量化提出了新的要求，金融資訊化每年投入了大量的人力進行開發，那麼多工作量投入，如何能客觀地量化評價相應的產出，成為乙個亟待解決的問題。
郵儲銀行投入了段永政領導的乙個小組，在北京科信深度公司的幫助下，總共八人歷時一年，詳細梳理了郵儲銀行歷史專案資料，分析出郵儲銀行自己的生產率，最後完善了管理制度及人員崗位等方面工作，從而建立了一套「基於功能點方法的軟體成本評估體系」。在建立體系之前，郵儲銀行通常採用模擬、類推及專家經驗法，由於這些方法沒有一套標準的體系，很容易受到主觀因素的影響，不能保證評估結果的科學性、準確性。建立基於行業標準的軟體評估體系後，使用客觀的功能點估算方法保證了軟體研發成本度量的準確性以及客觀性，最終促進了合規性。
中國郵儲銀行總行資訊科技部專案管理處副處長段永政
談到這套體系的實施難點，段永政表示最初門檻比較高，需要既懂技術又懂業務的複合型人才，但隨著資訊化投入的增加，需要投入的軟體估算團隊也會越來越龐大，針對如何降低資源投入這個問題，郵儲銀行專家進行了「客戶化改造」：建立一整套的功能點字典庫，通過功能點字典庫，將功能項進行封裝，至今為止已經封裝了17萬多個功能項，功能點數有**十萬個。未來業務人員只需輸入功能名稱就能自動查詢出這項功能的功能點數、工作量、費用等引數，不能查詢到的功能項，再交給專職的人員處理，通過相關流程加入到功能點字典庫中，從而大大降低了功能點使用的門檻，減少了對專業估算人員的依賴。
段永政表示，這套「基於功能點方法的軟體成本評估體系」很有價值。在評估體系建立後的試點應用階段，前三個月裡，郵儲銀行對比了與傳統方法及標準方法得出結果的差異，發現這套體系是非常科學與準確的，通過與實際專案資料的對比後，決定所有的專案都使用這套體系進行評估。目前所有專案都實現了量化管理。目前體系已經在郵儲銀行資訊中心內部、外包商管理及招投標管理等多方面全面實施。在內部，郵儲銀行對自身的開發成本及開發工期實現了精細化控制；在外部，對外包商的管理也提供了依據，特別是在功能點復用開發方面有了很好的管控；在招投標階段，能客觀地評估出專案金額，作為選擇**商的客觀依據。
下一階段，段永政團隊計畫做乙個後評價體系。在專案結束後對比預算時的計畫功能點，檢查功能點的實現情況，從而及時發現有可能的災難性漏洞，避免風險的發生，同時也有效的管理廠商。但這件事情做起來是有難度的，要建立後評價體系，必須通過大量的歷史資料的分析，得出過行**對應的功能點數，得出這個相應的比例，然後再通過**行來評價功能點的質量。
本次軟體估算大會，開啟了軟體度量新篇章，中國軟體行業基準資料發布的三方：工信部標準化研究院、北京軟體造價評估聯盟、北京軟交所將會發揮各自資源優勢、加強合作，進一步擴充行業基準資料庫，完善資料採集、發布、資料共享機制，按照規範透明的資料收集、分析和發布流程向公眾發布權威行業基準資料，供各方參考使用。
軟體專案規模評估
顧名思義軟體評估就是對軟體專案的規模進度做出乙個合適評估以判斷軟體專案的預算以及專案計畫。軟體評估是軟體工程的乙個最底層基礎，也是在軟體專案實施時必經非常核心的乙個步驟。對於乙個軟體專案，只有對其大致的評估後，才能掌握大致的軟體成本，人力資源配備，同時也是做專案計畫的基礎。軟體評估，評估的是軟體規模...
什麼是軟體評估？
以下是個人理解，如有錯誤請勿見怪！在現代軟體開發行業中，軟體的需求 質量 開發周期都存在一定不穩定性，而開發費用都是不用性質了，這裡面有公司效應，但也大多數還是有水分的。所以軟體評估在個人理解上就是對軟體的規模 軟體專案工作量 軟體專案開發成本 軟體質量等事項進行量化考核，給出乙個數位化的維度，這是...
軟體質量評估模型
軟體質量評估模型大概分3個主要方向 1.需求的覆蓋度 需求的覆蓋度計算方法可以用測試用例覆蓋需求來計算，這裡的需求是從需求規格說明書裡提取的測試需求，每條測試需求要控制好一定的範圍，差不多2條用例覆蓋一條測試需求 1個正常用例，1個異常用例 一般要求需求覆蓋度要達到100 可以根據工具來計算這個需求...