智慧園區軟件項目建設的質量管理策略研究

發布時間：2023-03-09 11:04

摘要 I

ABSTRACT III

第一章緒論 1

1.1研究背景及意義 1

1.1.1研究背景 1

1.1.2研究意義 2

1.2國內外相關研究現狀 3

1.2.1智慧園區建設的研究現狀 3

1.2.2軟件項目質量管理的研究現狀 3

1.2.3智慧園區軟件項目建設質量管理研究述評 4

1.3主要內容與方法 5

1.3.1研究的主要內容 5

1.3.2研究的主要方法 5

1.4研究的技術路線與章節安排 6

第二章智慧園區軟件項目建設質量管理的相關概念及理論 8

2.1相關概念 8

2.1.1軟件項目建設 8

2.1.2軟件項目質量管理標準 8

2.2相關理論 10

2.2.1 德爾菲法 10

2.2.2根因分析法 10

2.2.3層次分析法 11

第三章智慧園區軟件項目建設的質量管理現狀及存在問題 13

3.1智慧園區軟件項目建設的質量管理現狀 13

3.2智慧園區軟件項目建設質量管理問題識別 14

3.2.1 數據收集 14

3.2.2 數據分析 15

3.2.2根本原因識別 16

3.3智慧園區軟件項目建設質量管理問題分析 19

3.4本章小結 20

第四章智慧園區軟件項目建設的質量管理策略設計 21

4.1智慧園區軟件項目建設的質量管理策略的設計原則 21

4.2智慧園區軟件項目建設的質量管理策略的構建 21

4.2.1質量管理體系構建 21

4.2.2需求管理策略構建 30

4.2.3系統集成管理策略構建 34

4.2.4軟件運營管理策略構建 35

4.3智慧園區軟件項目建設的質量管理策略的實施保障 37

4.3.1 組織架構 37

4.3.2管理措施 38

4.3.3研發環境 39

4.4本章小結 39

第五章基于A智慧園區軟件項目建設的質量管理策略應用實例 41

5.1A 智慧園區軟件項目建設質量管理實例 41

5.2A 智慧園區軟件項目建設的質量管理策略實施過程 44

5.2.1質量管理體系 44

5.2.2需求管理策略實施 44

5.2.3系統集成管理策略實施 53

5.2.4軟件運營管理策略實施 59

5.3A 智慧園區軟件項目建設的質量管理策略的實施成效 65

5.3.1A智慧園區軟件項目建設的質量管理策略的實施成效定性分析 65

5.3.2A智慧園區軟件項目建設的質量管理策略的實施成效定量分析 67

5.4本章小結 76

第六章總結與展望 77

6.1全文總結 77

6.2研究展望 78

致謝 80

參考文獻 81

作者簡介 85

第一章緒論

1.1 研究背景及意義

1.1.1研究背景

近年來,“智慧城市”的建設逐步興起,在采集、整合各類城市運行數據的基礎上, 構建城市的“智慧大腦”,不斷提升城市建設和管理的智慧化水平。在智慧城市發展的背景下,智慧園區作為智慧城市建設的縮影受到了高度的重視,進入到大跨步發展階段, 各地也不斷出臺了相關政策。2019年國務院出臺《關于推進國家級經濟技術開發區創新提升打造改革開放新高地的意見》，持續推動我國產業園區蓬勃發展。智慧園區的建設既有著智慧城市建設的特點,又有著其獨特的一面,通過與物聯感知、云服務等新興信息技術相結合，匯聚、整理園區內部智能化設備運行指標數據和園區運營指標數據，生成具有決策支撐意義的信息和應用，提升園區管理的高效性、產業發展的創造性、公眾生活的便利性。

智慧園區軟件項目建設是智慧園區建設的主要內容，不僅僅是純粹的軟件開發，其建設內容復雜，一方面需要整合園區內部火災報警系統、求助對講系統、停車管理系統、車位引導系統、客流統計系統、建筑自動系統（包括制冷站集成控制系統、空調機組集成控制系統、給排水控制系統）等各類專業化子系統。另一方面面對園區的各類用戶需要建設滿足不同需求的應用軟件，比如針對園區內的居住人員，需要能夠提供園區內部餐飲、物業等日常生活服務。針對園區內部的入駐企業，提供軟件項目管理、產品營銷等企業服務。對于園區管委會提供能夠滿足管委會日常工作需要的管理軟件。

智慧園區軟件項目建設的質量管理通常采用軟件工程質量管理的方法，這種方法在一定程度上能夠提高智慧園區軟件項目建設的效果，但是由于智慧園區軟件項目涉及面廣、復雜度高、數據量大，使用傳統的軟件工程質量管理方法，很難完全滿足在智慧園區特定背景下軟件項目建設的質量管理要求，在質量管理體系方面，CMMI、敏捷開發模型在軟件研發過程及過程質量管理上應用較多，但由于智慧園區軟件類型多樣，導致了無法完全適用于智慧園區軟件項目過程及過程質量管理。在需求管理方面，軟件研發中需求管理主要指軟件功能調研、研發及實現，更加側重于需求能否實現，需求實現的效果如何，而對于智慧園區軟件項目，面向用戶多，需求來源廣，如何在需求研發的前期對需求進行管理顯得格外重要。在系統集成質量管理方面，管理的重心往往放在了接口開發和調試上，忽略了接口開發前相關環節的管理。在軟件運營質量管理方面，各種類型的園區運營的側重點有所不同，運營過程中存在的問題難以被發現，導致運營能力無法持續提升。如何針對智慧園區軟件項目建設設計更加科學的質量管理策略，如何持續提升智慧園區軟件運營的效果，使得智慧園區軟件項目質量管理策略研究成為了一個非常具有研究價值的課題。本文針對智慧園區的軟件項目建設中，傳統軟件質量管理模式存在的不足，提出相應的質量管理策略，助力智慧園區更好的建設。

1.1.2研究意義

隨著越來越多智慧園區軟件項目的建設，研究適合于智慧園區軟件項目建設的質量管理策略日趨重要。傳統的針對軟件項目的質量管理策略難以適用智慧園區背景下的軟件項目。筆者在學術平臺檢索“智慧園區軟件質量管理”關鍵詞時，發現相關的文獻數量很少，大部分的研究主要集中在智慧園區的發展趨勢、智慧園區的建設方案等方面，因此，本文針對智慧園區軟件項目建設的質量管理進行研究，具有重要的意義，具體如下：

（1）理論意義。智慧園區軟件項目建設核心是軟件，其軟件規模較大，各軟件系統的性質和作用不同，有基礎的支撐服務軟件、應用軟件、數據接入軟件、數據分析軟件等，照搬某一種軟件質量管理體系，很難滿足整個軟件項目的質量管理要求。比如對于底層支撐軟件，需求變化小，建設周期長，建設的內容比較明確，通常采用基于 CMMI 的質量管理體系。對于應用軟件，需求變化較大，為了給用戶更好的體驗，需要經常進行版本的迭代和升級，對于這類軟件項目通常采用敏捷開發的質量管理體系。本文通過將 CMMI 與敏捷開發相融合構建了適用于智慧園區軟件項目建設的質量管理體系，最大程度地滿足智慧園區軟件項目建設的質量管理要求，對智慧園區軟件項目建設的質量管理策略研究提供理論支撐作用。

（2）現實意義。本文在對現有智慧園區軟件項目建設質量管理中存在問題進行分析的基礎上，針對智慧園區軟件項目建設中需求管理存在的問題，將需求管理的重心前置，加強對需求的可行性、優先級及變更的評審工作，確保進入研發階段的需求都是客戶的真實需要或對提升園區運營、管理等起著重要作用的需求。針對智慧園區軟件項目建設中系統集成管理存在的問題，構建系統集成管理流程，讓系統集成工作開展的更加高效有序，為后期軟件運營提供底層的基礎支撐。對于智慧園區的軟件運營，從運營服務提升、運營體驗提升和運營決策提升三個方面進行分析，設計運營提升的管理策略。針對智慧園區軟件項目建設中需求管理、系統集成管理、軟件運營管理三個方面設計了質量管理策略，有助于提高智慧園區軟件項目建設質量管理水平，具有一定的現實意義。

1.2國內外相關研究現狀

1.2.1 智慧園區建設的研究現狀

通過梳理國內外針對智慧園區的相關研究，其切入點主要為智慧園區發展趨勢及智慧園區的建設方案。智慧園區以物聯感知為基礎，以軟件服務為核心，以新興技術為驅動力，在園區內部搭建縱橫交錯的智慧通道，實現園區內部數據的共享與交換，對海量的園區基礎信息進行匯聚、整理及分析，不斷提升園區管理的高效性、產業發展的創造性以及公眾生活的便利性。李玉琳,張婧,高琨,孫九成,李浩［1］提出了基于數字孿生的智慧園區建設，基于數據孿生技術構建虛擬園區，在虛擬園區中展示各類園區的運行及運營指標數據，為園區內部的物業管理提供更加直觀、形象的管理界面。李青山,王洪鋒, 梁向鋒，司博章,孫希法，黃飛［2］提出了一種基于IBA融合(物聯網、大數據和人工智能技術的融合應用)的智慧園區的建設思路，通過IBA融合進一步提高智慧園區的智慧化水平，為園區用戶提供更便捷的服務和更宜居的環境。尚寶麒［3］強調在智慧園區的建設需要以物聯網技術為基礎，通過物聯網技術讓園區內部的人、物、管理三個方面相融合，實現園區的自動化和智能化管理。徐明曉［4］分析認為隨著產業結構的不斷升級和優化, 產業園區成為繼傳統地產產業后最受地方政府歡迎的經濟模式；孟月［5］分析認為在 5G 技術的驅動下，5G智慧園區是未來智慧園區發展的主要方向，通過5G網絡強大的信息傳輸能力構建更寬的智慧通道，使得園區不僅僅可以匯聚園區內部的各類信息化設備數據，還能夠與園區外部進行數據交互，讓園區與園區之間互聯互通。金程，沙默泉，郭中梅，單斐等［6］提出了以城市信息模型(City Information Model,CIM)平臺為"數字底座"，從CIM技術的發展和應用狀況入手，提出基于CIM的智慧園區整體設計思路，并闡述了應用與發展建議。何雙鈴，侯林，陳波，石磊等［7］提出了綠色智慧化工園區建設的功能定位與架構設計，探討了泉惠石化工業園區綠色智慧化工園區建設的頂層設計和智慧環保平臺架構。

1.2.2軟件項目質量管理的研究現狀

軟件項目質量指軟件項目中交付的軟件與軟件需求說明書的一致性，其中既包括軟件的功能需求，也包括軟件的非功能需求，目前應用較多的軟件質量管理標準主要有 ISO9001 和 CMMI。 ISO9001 質量管理體系是對組織的產品或服務進行質量管理和控制的標準體系。是對內部人員、機構、設備、文件、軟件項目審批、研發、實施交付、售后服務等進行管理的標準流程體系。CMMI旨在提高軟件開發和改進的能力，從而在合理的進度和成本要求內開發出高質量的軟件產品°IS09001和CMMI都可以作為軟件企業軟件工程過程改進的質量管理框架。IS09001的應用范圍更廣，而CMMI主要用于軟件行業。

趙耀，朱建軍,龍笑宇［8］在對ISO9001和CMMI/CMM兩種質量管理體系的對比分析的基礎上，給出了兩種管理體系融合的建議。黃敏珍［9］具體描述了 CMMI、敏捷開發和DevOps 三種管理體系各自的特點，以及如何在軟件研發過程中進行應用，讓三種管理體系優勢互補，進一步提升軟件研發過程的的效率。蔡泉［10］在對敏捷開發和 CMMI 進行實踐的基礎上，分析了兩者的相同點和不同點，進一步提出了在敏捷開發中融合CMMI，從而提咼敏捷開發性能的管理思路。張碩［11］在對CMMI理論研究的基礎上，研究了 CMMI與軟件度量在軟件開發過程化管理中的應用。俞蔚［12］對 CMMI 在實際的軟件研發過程管理中的應用提出了新的建議，通過分析企業內部應用CMMI存在的問題，提出了解決問題的思路。嚴艦［13］將 CMMI 具體地應用在了汽車行業軟件開發中，使得汽車行業的軟件開發取得了較為理想的效果。張璇［14］0 從 CMMI 出發,選定網絡學習空間軟件項目為特定研究對象, 分析了項目實施中遇到的問題和原因，結合CMMI第二級和CMMI第三級的關鍵過程域，提出了改進網絡學習空間軟件項目管理的策略。付東普［15］基于約束理論,提出了一種基于軟件開發項目風險的質量管理過程控制模型，有效提升了軟件研發過程管理的效果。

1.2.3智慧園區軟件項目建設質量管理研究述評

通過對國內外有關智慧園區和軟件項目質量管理的研究現狀進行綜述，可以看出智慧園區的研究主要集中在智慧園區發展趨勢及智慧園區的建設方案，軟件項目質量管理的研究主要集中在軟件過程改進的方法、策略及預警模型，軟件質量量化的評價準則和評價指標等，在智慧園區和軟件項目質量管理的研究取得了較為顯著的成果，對智慧園區軟件項目建設的質量管理策略研究提供了重要的參考價值，但對于智慧園區軟件項目建設質量管理體系、需求管理、系統集成管理、軟件運營管理等方面仍然存在著可以繼續深入探討和研究的部分，主要有以下兩方面。

（1）針對智慧園區軟件項目建設質量管理體系的研究，軟件工程的質量管理體系，通常有一定的適用范圍，比如 CMMI 適用于平臺類的軟件，這類軟件通常作為底層支撐平臺，建設周期長，需求變化小，上線發布后幾乎不會進行較大的改動。敏捷開發模型適用于應用類的軟件，這類軟件需要頻繁地發布軟件版本，研發周期短，需求變化大，上線發布后需要根據用戶的實際使用情況進行頻繁的改動。智慧園區軟件項目既包含平臺類軟件又包含應用類軟件，因此需要構建適合智慧園區軟件項目建設的質量管理體系。

（2）針對智慧園區軟件項目建設具體的質量管理策略研究，在需求管理方面，國內外學者的關注點主要集中在需求變更、需求跟蹤、需求實現、需求管理效果評估等方面，較少有學者關注需求研發前期環節的質量管理。在系統集成管理方面，國內外學者的關注點主要集中在接口設計、接口開發、接口對接和接口測試等技術層面的內容，較少有學者研究系統集成的需求調研、集成對接規劃等非技術層面的內容，以及系統集成質量管理流程。在軟件運營管理方面，國內外學者的關注點主要在軟件運營的效果評價，鮮有學者分析軟件運營中發現問題，持續提升運營能力的方法。

針對以上研究不足，本文通過構建適用于智慧園區軟件項目建設的質量管理體系，并針對需求管理、系統集成管理、軟件運營管理三個方面設計對應的質量管理策略，以期能夠為智慧園區軟件項目建設的質量管理提供更加科學的管理方法，更好地助力智慧園區的建設。

1.3 主要內容與方法

1.3.1 研究的主要內容

本文以提高智慧園區類軟件項目建設質量管理水平和建設效果為目標，重點研究了智慧園區軟件項目建設的質量管理體系和質量管理策略，首先對智慧園區軟件項目建設的質量管理現狀及存在問題進行分析。然后在此基礎上，分別針對質量管理體系、需求管理、系統集成管理及軟件運營管理四個方面設計了質量管理策略。接著，以A智慧園區軟件項目為例，詳細描述了質量管理策略的實施過程。最后對A智慧園區軟件項目質量管理策略實施后的成效進行了定性和定量的分析和討論，以期進一步助力智慧園區的建設。

1.3.2 研究的主要方法

本文的研究方法主要包括：

（1）文獻分析與問卷調查相結合：首先大量閱讀前人的研究成果，結合智慧園區軟件項目建設的特征，建立了 CMMI、敏捷開發相融合的質量管理體系。

（2）根因分析法：針對智慧園區軟件項目建設的質量管理中存在的問題采用根因分析法進行分析，從而找到影響智慧園區軟件項目建設質量管理的主要原因，根因分析法主要包括頭腦風暴、魚骨圖、柏拉圖、散點圖等。

（3）層次分析法：針對智慧園區軟件項目建設的質量管理策略實施成效，采用層次分析法構建評價模型，進行定量分析評價。

1.4 研究的技術路線與章節安排

本文首先對國內外智慧園區軟件項目建設現狀進行了歸納整理，提出了本文的研究問題和研究目標。其次對智慧園區軟件項目建設質量管理現狀及存在問題進行分析，進一步明確了本文的研究思路及解決問題的方法。然后針對前文得到的智慧園區軟件項目建設的質量管理存在問題的原因，設計了智慧園區軟件項目建設的質量管理策略。最后以A智慧園區軟件項目建設為例，詳細闡述了質量管理策略的實施過程及成效。本文的研究框架及技術路線如圖 1-1 所示。

圖 1-1 研究框架及技術路線圖

本文的章節安排如下：

第1章為緒論。首先介紹了本文的研究背景，通過對國內外關于智慧園區軟件項目建設的相關研究現狀進行綜述，指出了現有研究中存在的不足，探討了本文的研究意義。緊接著介紹了本文研究的主要內容和方法，并對每一章進行簡要闡述，描繪了本文研究的技術路線，最后，提出了本文擬解決的問題。

第2章為智慧園區軟件項目建設質量管理的相關理論和方法回顧。首先對本文中涉及到的相關概念進行了介紹，闡明了軟件項目建設、軟件項目質量管理標準的內涵。緊接著詳細介紹了根因分析法和層次分析法，分別為第三章智慧園區軟件項目建設的質量管理現狀及存在問題分析，第五章A智慧園區軟件項目建設的質量管理策略的實施成效評價提供了理論支撐。

第 3章為智慧園區軟件項目建設的質量管理現狀及存在的問題。收集當前智慧園區軟件項目建設質量管理策略中存在的問題，在此基礎上，使用根因分析法分析問題的成因，進一步明確后文質量管理策略設計的思路。

第4章為智慧園區軟件項目建設的質量管理策略設計。在CMMI和敏捷開發模型質量管理體系的基礎上設計了一種兩者相互融合的質量管理體系，克服了單獨應用 CMMI 或敏捷開發模型進行軟件項目建設質量管理的缺點。在需求管理方面，針對需求研發的前期環節，設計了需求三階段評審策略，對需求的可行性、優先級及變更的評審進行重點管理，克服了軟件研發階段需求管理的盲目性。在系統集成管理方面，設計了系統集成質量管理的流程，重點對系統集成需求調研、數據分類、對接流程規劃、接口管理等方面進行闡述，通過量化的數據和接口清單使得系統集成工作能夠高效有序進行。在軟件運營管理方面，從運營服務、運營體驗、運營決策三個方面設計了質量管理的策略，解決了軟件運營問題難發現，運營能力無法持續提升的問題。

第5章為基于A智慧園區軟件項目建設的質量管理策略應用實例。基于A智慧園區軟件項目建設的實際情況，結合第四章所設計的智慧園區軟件項目建設的質量管理策略，從質量管理體系、需求管理、系統集成管理、軟件運營管理四個方面介紹具體的質量管理策略實施過程。接著對A智慧園區軟件項目建設的質量管理策略的實施效果進行定性和定量的分析與評價。

第 6 章為總結與展望。對全文研究工作進行概述和總結，針對本文研究中存在的不足和值得改進的地方作出了展望。

第二章智慧園區軟件項目建設質量管理的相關概念及理論

本章首先介紹本文研究所涉及的相關概念，對智慧園區、軟件項目建設、軟件項目質量管理標準進行了詳細介紹，確定了本文研究的內容邊界。其次分別介紹了德爾菲法、根因分析法、層次分析法，其中德爾菲法和根因分析法為智慧園區軟件項目建設的質量管理現狀及存在問題分析時主要用到的方法，層次分析法為智慧園區軟件項目建設的質量管理策略實施成效定量分析評價中主要用到的方法。

2.1相關概念

2.1.1軟件項目建設

工程項目建設的過程通常包括策劃、評估、決策、設計、施工、驗收、投產使用等過程。軟件工程過程通常指軟件研發交付的全過程，主要包括項目啟動、項目策劃、需求開發、設計開發、軟件測試及上線發布等。軟件項目建設不同于軟件開發過程，其涵蓋的范圍更加廣泛，可以看作是工程項目建設和軟件開發全過程的結合，涉及軟件策劃、評估、立項、計劃、需求、概要設計、數據庫設計、詳細設計、開發、測試、集成、交付、維護、運營直至軟件項目消亡或升級的全生命周期過程，本文所探討的智慧園區軟件項目建設包括上述所有過程。

2.1.2 軟件項目質量管理標準

ISO9000的質量管理體系中關于質量的定義，質量是指一組固有特性滿足要求的程度。質量目標并非越高越好，通常是達到客戶要求和行業的技術標準為宜。

2.1.2.1CMMI

CMMI 的最佳實踐覆蓋了產品構思、交付和維護的整個生命周期，是國際公認的對軟件公司進行成熟度等級認證的重要標準。CMMI通過建立一個規范和成熟的軟件研發過程，提高交付軟件的質量。CMMI共分五級，在每一級中，定義了達到該級過程管理水平所應解決的關鍵問題和關鍵過程。每一較低級別是達到較高級別的基礎。其中五級是最高級，即優化級，達到該級的軟件研發過程可自發地不斷改進，防止同類問題二次出現。四級稱為已管理級，達到該級的軟件公司已實現過程的量化管理。三級為已定義級，即過程實現標準化。二級為可重復級，達到該級的軟件公司過程已制度化，有紀律，可重復。一級為初始級，軟件研發過程無序，進度、預算、功能和質量等方面不可預測。

CMMI 質量管理體系的核心理念：

（1）提高軟件質量。實施CMMI的目的是為了提高軟件的質量，在進度、質量、成本要求的范圍內完成軟件開發任務， CMMI 以響應客戶的需求并提升軟件產品質量為目的。

（2）規范軟件開發的過程。 CMMI 關注軟件開發過程的規范化和組織級的完善， CMMI 級設置了 22個過程域，過程域是一類相關實踐活動的集合，是CMMI模型的基礎，軟件開發過程的規范化管理主要通過過程域的管理來實現。軟件能力成熟度模型成熟度等級與過程域如表 2-1 所示。

表 2-1 軟件能力成熟度模型成熟度等級與過程域

成熟度等級過程域

第5級：優化級組織革新與部署

原因分析與解決方案

第4級：量化管理級定量項目管理

組織過程績效

第3級：己定義級需求開發

技術解決方案

產品集成

驗證

確認

組織過程焦點

組織過程定義

組織培訓

集成化項目管理

風險管理

決策分析與解決方案

第2級：己管理級需求管理

項目規劃

項目監控

供應商協議管理

度量分析

配置管理

過程和產品質量保證

第1級：初始級無

2.1.2.2 敏捷開發

20 世紀 90 年代，敏捷開發［16］因能快速應對需求的變更，逐漸引起關注，敏捷開發倡導一種“頻繁地交付可工作的軟件”的軟件開發理念，不同于大規模的瀑布式軟件開發模型，敏捷開發更注重軟件開發中“人”的作用，強調面對面的溝通，隨著業務的深入不斷深化初始的軟件架構設計。

敏捷開發的核心理念：

（1）逐步深化的軟件架構。敏捷開發團隊初始軟件架構往往比較輕量級，隨著業務的深入開展，逐步細化和擴展架構中的軟件功能，出現這種情況的原因主要是因為敏捷項目的需求往往不確定，需要及時研發出成果，交付后再根據變化不斷進行迭代開發。而 CMMI 主要面向大型項目，需求較明確，需要保證每個過程都是嚴謹的、能通過驗證評審的。

（2）快速響應需求。敏捷開發的理念是及時響應客戶不斷變化的需求，盡快交付滿足客戶質量要求的產品。

2.2相關理論

2.2.1德爾菲法

德爾菲法［17］是專家調查法中很重要的一種方法，根據經過調查得到的情況，憑借專家的知識和經驗，經過簡單的推算，對研究對象進行綜合分析研究，尋求其特性和發展規律并進行預測的一種方法。通過反復多次地讓專家發表意見，收集專家意見，讓專家修正評估結果的過程，最終將得到基本一致的專家意見作為評估的結論，在評估過程中，專家采用匿名的方式發表意見，同時專家與專家之間不能進行溝通，德爾菲法對于復雜問題的評估具有廣泛的代表意義，結果較為可靠，其最大的優點是簡單直觀，無需建立復雜的數據模型，特別在缺乏足夠統計數據和沒有類似案例可參考的情況下，也能夠對研究對象的未知或未來的狀態作出有效的預測。

2.2.2根因分析法

根本原因分析（RCA）［18］是一種尋找分析問題根本原因的方法，問題存在的原因總是來自多方面的，有些是主要原因，有些是次要原因，根因分析的本質就是從這些原因中找到產生問題的主要原因，分析過程如下：

（1）理解問題和定義問題，可采用的工具有流程圖、雷達圖、關鍵事件分析以及性能矩陣等。

（2）通過頭腦風暴法、數據收集等方法找出導致事件發生的直接原因。

（3）數據分析，借助親和圖、關系圖等工具厘清不同原因之間的關系，并篩掉不相關原因。

（4）根本原因識別，即找出導致80%問題產生的原因，制定問題解決方案，可以采用魚骨圖、矩陣圖、 Pareto 圖以及 5whys 分析等工具。

（ 5）根據研究結果提出政策建議。

本文在智慧園區軟件項目建設的質量管理問題分析中采用了頭腦風暴、親和圖、魚骨圖和 Pareto 圖四個工具。

頭腦風暴［19］最初用于精神病理學，是指精神病人的精神障礙。現在它已成為無限制自由交往和討論的代名詞。它的目的是產生新的想法或激發創新的想法。由于問題產生的原因多種多樣，根因分析的第一步是盡可能多地列出產生問題的原因，通過召開會議，讓參會的所有人員自由發表自己的意見，提出盡可能多的問題存在的原因。

親和圖［20］是全面質量管理的七大新工具之一。運用語言文字的內在聯系（親和力）對處于混亂狀態的語言文字材料進行了歸納和整理，為解決問題找到了一條新的途徑。為了對頭腦風暴提出的各種各樣的原因進行進一步分析，需要對原因進行分類，親和圖工具就是充分吸收參加會議人員的經驗和知識的基礎上，利用各個原因之間的關系，做出分類合并圖，實現原因的分類。

魚骨圖［21］，又叫做"石川圖"或"因果圖"。它具有簡潔、實用、深刻、直觀的特點。它看起來像魚骨,待分析的問題標記在"魚頭"，在“魚身”上畫出“大魚刺”和對應的“小魚刺”，“大魚刺”表示原因的種類，“小魚刺”表示各種具體的原因，通過魚骨圖可以更全面地發現和總結問題出現的原因。

帕累托圖［22］，又叫做排列圖，將導致質量問題出現的原因按照其發生的頻率的高低從左到右進行排列，并繪制出頻率累加曲線圖，對于累加頻率0-80%的原因認為是問題的主要原因，帕累托圖和帕累托規則是一致的，常被稱為二八原理,即 80%的問題是由 20%的原因引起的，通過帕累托圖進一步對頭腦風暴提出的各種各樣的原因中進行分析，找出其中出現頻率累加在 0-80%范圍的原因，認為是問題初選的主要原因。

2.2.3層次分析法

層次分析法（ Analytic Hierarchy Process， AHP）［23］是將決策相關要素分解為目標、準則、方案等層次，并在此基礎上進行定性和定量分析的一種決策方法，將決策問題按總目標、各級子目標、評價標準和具體儲備方案的先后順序分解為不同的層次，構建判斷矩陣，通過求解判斷矩陣的特征向量，從而得到每層元素對上一層某個元素的權

重，然后通過加權求和的方法合并每一種方案的權重到總目標中，最終可以判斷權重最

大的方案為最優的方案。

第三章智慧園區軟件項目建設的質量管理現狀及存在問題

前文介紹了本文的研究背景及研究意義，通過國內外研究綜述，提出了本文擬解決的主要問題。第二章對本文涉及的相關理論及方法進行了介紹，為后文質量管理策略的設計及應用奠定了理論基礎。本章撰寫的目的是對智慧園區軟件項目建設的質量管理中存在的不足和成因進行分析，為第四章質量管理策略的設計及第五章質量管理策略的應用實例明確了思路。

3.1智慧園區軟件項目建設的質量管理現狀

近些年，我國智慧園區的建設速度激增，智慧園區成為助力我國經濟高速發展的中堅力量。智慧園區是對傳統園區的進行全面的信息化，并在該基礎上實現園區的智能管理和運營。隨著智慧園區軟件項目的大體量、大規模的建設，智慧園區軟件項目的質量管理問題日益凸顯。我國的智慧園區軟件項目建設整體來看，仍處于發展前期，還沒有形成成熟的頂層設計，不少智慧園區軟件項目建設還處于基礎搭建以及信息化碎片整合過程中，很多智慧園區軟件項目建設還在探索可落地的、可復制的、質量可控的方式。

本文研究的智慧園區軟件項目建設質量管理現狀，存在諸多問題，導致了智慧園區軟件項目建設效果不理想。主要表現如下：

（1）信息化建設程度參差不齊。隨著科學技術的飛速發展，智慧園區在全國各地逐步發展，但信息化建設的程度卻不盡相同。主要有兩個方面的原因，一是園區的類型多種多樣、各具特色，因此園區的建設沒有完全可類比的先例進行參考，另一個是缺乏智慧園區的頂層設計規劃，大多數園區只考慮了部分基本功能，如物業管理系統、停車系統等。系統與系統間存在著信息屏障，信息不能交互，數據無法共享。

（2）功能同質化現象嚴重。大部分園區管理方都是園區運營的專家，缺乏智慧園區建設的經驗，信息化建設沒有明確的方向，因此很容易造成系統功能同質化的問題。根本原因是沒有根據園區自身的類型和性質進行分析，在園區定位不明確的情況下，照搬市場上其他園區或現有系統會造成嚴重的同質化，不但沒有達到智慧園區建設的目的，而且還要承擔額外的運營成本和費用。

（3）園區生態不豐富。智慧園區的建設要考慮到園區的生態問題，園區內部有多種生態鏈和產業鏈。每個生態要形成一個閉環，生態與生態間要建立聯系，從而使每個生態在應用層、管理層、分析層、服務層發揮作用。

（4）缺少遠期規劃。在智慧園區信息化建設的初期，大多數園區在功能方面都會有自己的初步需求，主要是園區在運營中經常遇到的問題，希望通過信息化手段進行優化。但在建設初期，僅僅考慮一些眼前的需求點往往是不夠的。園區總體規劃要有前瞻性。既能考慮到前期建設的功能拓展，又能考慮到后期開發對接中平臺框架的各種因素。在智慧園區項目建設中，首先要對園區自身的類型、產業等進行分析，并與同類項目進行比較，明確定位和需求，做出前瞻性、科學性、系統性、專業性的園區規劃，確保園區的先進性、完整性，項目的可行性和風險可控性。

3.2智慧園區軟件項目建設質量管理問題識別

本文研究的智慧園區軟件項目建設，在項目建設初期，客戶抱怨人員技術能力有限，不能很好的理解需求，不能很好的和客戶進行溝通等問題；在項目建設過程中，客戶經常抱怨階段性成果提交不及時，園區的一些智能化設備的數據展示總是使用模擬數據，不能展示真實數據等問題；在項目交付后，客戶也抱怨軟件運營的效果不太好，離預期的效果有一定的距離。針對智慧園區軟件項目建設現狀，為了能夠找到導致這些問題發生的主要原因，采用根因分析法對質量管理中存在的問題進行分析，分析步驟包括數據收集、數據分析和根本原因識別。

3.2.1 數據收集

本文采用了數據收集的方法，數據收集主要來自三個途徑：

（ 1 ）問卷調查

對智慧園區軟件項目建設過程中的參與人員（包括建設方、監理、分包單位等）采用問卷調查的方式進行數據收集，問卷調查主要圍繞質量管理理念、質量管理核心力量、質量檢查制度、影響質量管理的內外因素、質量獎懲制度、質量管理的關鍵環節、系統集成質量管理等方面展開調查，收集相關數據。

（ 2 ）頭腦風暴

組織相關人員（包括項目經理、項目總工程師、軟件需求調研人員、軟件設計人員、軟件研發人員、測試人員等），通過頭腦風暴的方式對智慧園區軟件項目建設質量管理中存在問題的原因進行羅列。

（ 3 ）文章檢索

通過檢索有關軟件項目質量管理相關的文章，整理出其中列舉的影響軟件項目質量

管理的原因，形成研究數據，為了保證數據的質量，在文章檢索過程中，文章的篩選、檢索引擎和關鍵詞等均有明確的規定，選取的文章均為學位論文，主要是因為學術論文結構較為完整，原因分析有據可依，可以保證收集原因的有效性，為了保證檢索結果的全面性，以中國知網作為檢索引擎，以“軟件項目質量管理”“軟件質量管控”“軟件質量管理”作為關鍵詞進行檢索，排除掉學位論文以外的類型，其中以“軟件項目質量管理”為檢索關鍵詞的學位論文 193篇，以“軟件質量管控”為檢索關鍵詞的學位論文 7 篇，以“軟件質量管理”為檢索關鍵詞的學位論文 291 篇，共得到學位論文 491 篇，仔細查閱每一項檢索結果，剔除其中未分析質量管理原因的文章及全文相似度極高的文章，最終得到 25 篇數據來源文章，仔細研讀數據來源文章，記錄其中列舉的關于軟件項目質量管理問題產生的原因。

通過上述問卷調查、頭腦風暴、文章檢索方式，共收集了影響智慧園區軟件項目質量管理的原因共263 條，將這263 條數據制成表格，形成本文研究的基礎數據。

3.2.2 數據分析

數據分析是為了整理已經收集到的各原因數據之間的關系，由于收集的原因數據數量較多，共 263條，為了對原因數據進行分類管理，為后面的研究工作做準備，首先采用親和圖法對原因進行分類整理，親和圖法是一種能夠根據相似性將收集到的信息進行分類綜合分析的一種方法，能夠對復雜的原因進行分類，避免在接下來的研究中陷入混亂。采用親和圖法進行原因分類，首先成立了質量管理原因分類討論組，將原因寫在一個個小卡片上，討論組對卡片上的原因進行討論，將認為相似或存在聯系的原因貼在一起，該步驟完成后，為相似原因的組歸納主題，根據主題和原因卡片上的排列，繪制原因分類圖。在原因進行分類討論過程中，部分原因所屬的組別存在爭議，研究小組采用德爾菲方法進行原因分類的確定，具體步驟如下：

（1）組成專家小組。根據難以分類的原因數據，確定專家。專家人數可根據帶分類數據量和涉及的范圍來確定，一般不超過20 人。

（2）向專家提供有關問題及問題分類的背景材料。

（3）各個專家根據他們所收到的材料，提出自己的意見，并說明自己是怎樣對這些原因進行判斷和分類的，匯總專家進行第一次判斷的結果以及具體意見，并進行整理。

（4）將匯總整理后的意見再次分發給專家，讓專家們進行第二次修訂。德爾菲法就是反復收集意見并反饋給專家進行結論修改的過程，通常需要反復三到四次。

（5）對專家的意見進行綜合處理。

經過該步驟，將所收集到的原因分成了8 個小組，分別是質量管理體系、需求管理、

系統集成、軟件運營、軟件研發過程管理、溝通管理、軟件測試以及其他因素，每個分類下再將相似的原因進一步分類，保證每個小組中有 3-6 個小類，通過此次分組，效果明顯，所有質量管理原因均完成了分類。智慧園區軟件項目建設質量管理問題原因分類示意圖如圖 3-1 所示。

A智慧園區軟件項目建設質量管理問題原因分類示意圖

圖 3-1 智慧園區軟件項目建設質量管理問題原因分類示意圖

3.2.3 根本原因識別根本原因識別的目的是為解決該問題提供行動依據，智慧園區軟件項目建設是復雜的系統工程，影響其項目質量管理的因素復雜，不像傳統的純軟件研發項目那樣具體，容易使本研究結果存在爭議，因此需要首先找出導致 80%質量管理問題產生的原因，在上一步原因分類的基礎上，運用魚骨圖與帕累托圖相結合的方法進行質量管理問題根本原因識別。

本文采用原因型魚骨圖，具體步驟如下：

（1）先畫出主骨，表示智慧園區軟件項目建設質量管理這一問題。

（2）畫出大骨表示大要因，圖中的質量管理體系、需求管理、系統集成、軟件運營、研發過程管理、溝通管理、軟件測試管理等構成大要因。

（3）畫出中骨表示中要因，如質量管理體系不適用、質量管理體系難以實施、需求不明確等屬于中要因。

（4）統計每種大要因在數據總量中所占的比重以及各中要因占大要因的比重，并以百分比形式表示。

智慧園區軟件項目建設質量管理問題原因分析魚骨圖如圖3-2所示。針對A智慧園區軟件項目建設質量管理存在問題原因進行分析，針對魚骨圖中的大要因，其中質量管理體系方面的原因共63條，占比為24%，需求管理方面的原因共52條，占比19.8%，系統集成方面的原因共47條，占比17.9%，軟件運營方面的原因共42條，占比16%，軟件研發過程管理方面的原因共 24 條，占比 9.1%，溝通管理方面的原因共 15 條，占比5.7%，軟件測試方面的原因共13條，占比4.9%，其他因素共7條，占比2.7%。對于中要因進行分析，質量管理體系方面中要因包括質量管理體系不適用，質量管理體系難以實施、質量管理體系沒有評價手段、質量管理體系部分過程未得到組織支持，占比分別為 55.5%，23.8%，12.7%和 7.9%。需求管理方面中要因包括需求不明確，需求調研未達到預期效果，需求變更較大，需求變更評審與跟蹤，占比分別為 48.1%，30.8%， 15.4%和 5.8%。系統集成方面中要因包括對接協議復雜，對接系統較多導致難以管理，對接進度難控制，對接系統的數據質量難保證，占比分別為42.6%，31.9%，21.3%和 4.3%。軟件運營方面中要因包括運營存在問題無法識別，運營無法持續改善，運營中用戶體驗不好，運營規范不完善，占比分別為 42.9%，35.7%，14.3%和 7.1%。軟件研發過程管理方面中要因包括設計文檔評審不充分，功能未完全滿足要求，研發過程缺少關鍵質量檢查，軟件研發缺少效率較高的研發平臺，占比分別為 41.7%，33.3%，12.5%和 12.5%。溝通管理方面中要因主要有研發測試人員溝通問題，與建設方的溝通問題，與分包廠家溝通問題及領導層面的溝通問題，占比分別為 33.3%，33.3%，20%和 13.3%。軟件測試方面中要因包括測試計劃不合理，測試方案評審不充分，測試計劃執行不到位和缺少用戶現場的軟件測試，占比分別為 38.5%，23.1%，23.1%和15.4%。其他因素方面中要因包括研發人員質量意識薄弱，缺少日常的軟件質量宣貫，軟件兼容能力，軟件響應速度，占比分別為28.6%，28.6%，28.6%和 14.3%。

質量管理體系難以實施，贏(訂求調研未:達到預期效果,=16(30.”接系統較多,難以管理，呷31”運營無法持續改善，F1鯉£

質量管理體系沒有評價手段,n=8(l2. 7%)[ 需求變更較大，=8區4£ 對接進度難控制,n=10(21. 3%(運營中用戶體驗不好,n=6(14. 3*

質量管理體系部分過程未得到組織支持,11=5(7.9%)需求變更評審與跟蹤n=3(5.8打待對接系統的數據質量難保證n%：*)運營規范不完善，n=址』*

設計文檔評審不充分,n=10(417%)/研發測試人員 —測試計劃不合理,1=5(38.5%'發人員質量意識薄弱,1=2(28哼)

功能未完全滿足需求，=空0與建設方的溝通問題,n=5(33.；)：測試方不充分, 1=3(23.1%)缺少日常的軟件質量宣貫,趙滅'

研發過程缺少咲鍵質量檢查，會與分包廠家溝通問題,n=3(20%「測試計劃執行不到位,1=3(23.1/軟件的兼容能力‘Ay 軟件研發缺少效率較高的研發領導層面的溝通問題,1=2(13.嶺少用戶現場的軟件測試,n=2(15.4%/軟件的響應速度二 J

圖3-2智慧園區軟件項目建設質量管理問題原因分析魚骨圖

以魚骨圖的分析結果為基礎可用8 大要因占數據總量的比重數據制成帕累托圖智慧園區軟件項目建設質量管理問題原因分析帕累托圖如圖 3-3 所示。

A智慧園區軟件項目建設的質量管理分析

120.00%

100.00%

80.00%

60.00%

40.00%

20.00%

0.00%

圖 3-3 智慧園區軟件項目建設質量管理問題原因分析帕累托圖

由圖可知質量管理體系、需求管理、系統集成和軟件運營出現的頻數分別是 63、

52、47和42，總占比達77.57%,按照80 : 20的原則，是導致智慧園區軟件項目建設質量管理的主要原因。由圖可知在質量管理體系因素中占比最大的為質量管理體系不適用出現頻數為35 占質量管理體系因素總數的55.5%；在需求管理因素中占比最大的是需求不明確出現頻數25 占需求管理因素總數的48.1%;在系統集成因素中占比最大的是對接協議復雜出現頻數20 占系統集成因素總頻數的42.6%；在軟件運營質量管理因素中占比最大的是運營存在的問題無法識別和跟蹤導致了軟件運營質量很難得到改善，出現頻數18，占比 42.9%。

可見，質量管理體系、需求管理、系統集成、軟件運營是導致智慧園區軟件項目建設質量管理出現問題的主要原因，而質量管理體系不適用、需求不明確、系統集成對接協議復雜和運營存在的問題無法識別和跟蹤分別是各大要因中應重點關注的問題。

3.3智慧園區軟件項目建設質量管理問題分析

通過對智慧園區軟件項目建設質量管理問題的識別，可以發現質量管理體系、需求管理、系統集成、軟件運營是導致智慧園區軟件項目建設質量管理問題的主要原因，也是后文中質量管理策略設計需要重點考慮的因素。

（1）質量管理體系適用性。質量管理體系方面存在的問題主要有軟件質量管理體系不適用，軟件質量管理體系難以直接應用，軟件質量管理體系沒有評價手段，軟件質量管理體系部分過程未得到組織支持。由于智慧園區軟件項目需要研發的軟件類型多樣，主要包括平臺類和應用類，對于平臺類的軟件建設周期長，上線后變動小，可以采用 CMMI 的質量標準體系進行質量管理。而對于應用類軟件，直接面向客戶，需求變化較大，使用CMMI質量管理體系進行質量管理，需求變更響應不及時，軟件版本迭代周期較長，導致用戶體驗不好，對于這類軟件項目通常采用敏捷開發方式進行管理。

（2）需求管理精細化。需求管理方面存在的問題主要包括需求不明確，需求調研未達到預期效果，需求變更較大，需求變更評審與跟蹤。在軟件項目建設過程中，需求管理的好壞直接決定了軟件最終的使用效果。需求管理不善，不僅會造成時間的浪費，而且嚴重影響最終軟件的交付質量。

（3）系統集成規范化。系統集成方面存在的問題主要包括對接協議復雜，對接系統較多導致難以管理，對接進度難控制，對接系統的數據質量難保證。在智慧園區項目建設中需要對接大量的智能化子系統，匯聚智能化設備的運行指標數據和告警數據并在平臺中進行展示，智能化子系統的對接是智慧園區項目主要數據來源，由于需要對接的子系統數量較多，對接方式多樣、對接協議復雜，如何管理好智能化子系統的對接對于智慧園區軟件的展示和運營顯得極為重要，是智慧園區類軟件項目建設中質量管理的重要組成部分。

（4）軟件運營協同化。軟件運營方面存在的問題主要包括運營存在問題無法識別，運營無法持續改善，運營中用戶體驗不好，運營規范不完善。隨著產品的迭代速度越來越快，對于產品快速交付的要求越來越高。軟件測試是保障軟件研發質量的重要環節，對軟件產品的版本發布質量起到了不可或缺的作用，而傳統軟件測試主要對軟件的功能及非功能需求進行測試，對軟件的運營效果、用戶體驗度等軟件實際的運營情況沒有有效的手段進行管理，導致個別軟件交付后很長時間無法進入運營狀態，運營效果難以持續提升。

3.4 本章小結

本章在智慧園區軟件項目質量管理現狀的基礎上，通過數據收集、數據分析、根本原因識別等步驟，采用了親和圖、魚骨圖、帕累托等根因分析法，對本文所研究的智慧園區軟件項目質量管理存在問題的原因進行了分析，明確本文對智慧園區軟件項目建設的質量管理策略研究的重點將聚焦在質量管理體系、需求管理、系統集成、軟件運營四大主要因素上，為第四章智慧園區軟件項目建設的質量管理策略設計和第五章基于A智慧園區軟件項目建設的質量管理策略應用奠定了基礎。

第四章智慧園區軟件項目建設的質量管理策略設計

第三章主要對智慧園區軟件項目建設的質量管理現狀及存在問題進行了分析，總結出影響智慧園區軟件項目建設質量管理問題的主要原因包括質量管理體系、需求管理、系統集成、軟件運營四個方面。本章則首先介紹了智慧園區軟件項目建設的質量管理策略的設計原則，在此基礎上從質量管理體系、需求管理、系統集成、軟件運營四個方面構建智慧園區軟件項目建設的質量管理策略，為第五章質量管理策略的應用實例打下了基礎。

4.1智慧園區軟件項目建設的質量管理策略的設計原則

（1）標準化和規范化原則。嚴格遵循國家、軟件行業有關法律法規和技術規范的要求，從業務、技術、運行管理等方面對項目的整體質量管理策略進行設計，充分體現標準化和規范化。

（2）先進性和成熟性原則。在進行質量管理策略的設計時，既要考慮到先進性，同時也要考慮到成熟性，避免設計出難以實施落地的質量管理策略。

（3）可擴展性和可裁剪性。智慧園區軟件項目建設質量管理策略的設計，能夠根據不同類型的智慧園區軟件項目建設進行擴展和裁剪，從而適用于不同類型智慧園區軟件項目質量管理的需要。

（4）完整性原則。在智慧園區軟件項目建設的質量管理策略設計中，應考慮軟件項目建設的全過程。除了軟件開發的全過程外，還應考慮系統集成和軟件運營等軟件項目建設的全過程，及時發現并解決存在的問題。

4.2智慧園區軟件項目建設的質量管理策略的構建

在上述原則的基礎上，結合第三章對智慧園區軟件項目建設的質量管理現狀及存在問題的分析，重點從質量管理體系、需求管理、系統集成、軟件運營四個方面，構建智慧園區軟件項目建設的質量管理策略。

4.2.1 質量管理體系構建

4.2.1.1基于CMMI的質量管理體系構建

基于CMMI質量管理的核心是用于評估并改善組織過程能力，強調“人+技術+流程” 在軟件項目研發中的作用，但在實際的軟件研發中， CMMI 更多地還是強調通過流程的規范性達到保證開發交付質量的目的，其核心思想包括兩個方面：

1、過程的規范性決定軟件交付質量。通過 CMMI 開發活動的 22 個過程域 (ProcessArea:過程域)構建軟件研發的標準化流程，通過規范性的研發流程保證軟件

研發成果的質量。

2、持續改進組織能力。在 CMMI 標準中，組織的能力被分為了五個層次，各個層次都有詳細的標準。組織可以根據自身能力以及實際需求確定優化和改進目標。

CMMI中的22個過程域屬于四個主要的管理領域，即項目管理、工程管理、過程管理以及支持管理。

(1)項目管理。對項目計劃、項目跟蹤與控制、風險管理、供貨協議管理等描述本質上沒有脫離美國項目管理協會(Project Management Institute，PMI)的標準。

(2)工程管理。工程技術方法對于不同的行業有很大差異。雖然都叫做軟件編程， C 語言和 Java 語言之間存在著很大的區別。因此， CMMI 只定義了工程管理中最常用的方法，而每種方法如何實施？哪種方法合適？ CMMI并沒有給出明確的指導。

(3)過程管理。過程管理描述了一種非常通用的流程優化和改進方法，確定組織流程的改進點，然后號召團隊設計未來的業務流程。在全面實施前，先進行試點，再對試點進行修訂，確保全面實施前沒有大的風險。因此， CMMI 的過程管理離不開行業內過程改進和過程優化的范圍。

(4)支持管理。在CMMI標準中，支持管理領域包括配置管理、測量與分析、質量保證等， CMMI 在支持管理部分描述得非常詳細，可以為支持管理的實施提供非常具體的指導。

由于CMMI過程域間相互獨立，為了能夠在軟件項目建設中能夠很好地將22個過程域銜接起來，往往以項目為主線將它們串聯起來，從實際項目建設的角度實施CMMI，而不是站在評估的角度，這樣的 CMMI 體系才能真正意義上運作起來，具有強大的生命力，否則僅僅是為了評估而評估。以軟件項目為主線，基于CMMI的軟件項目質量管理體系如圖4-1 所示。

工程過程及文檔

項目啟動

項目策劃

需求開發設計開發

軟件測試

上線發布

支持過程及文檔

配置管理質量保證項目跟蹤與監控度量與分析根因分析決策分析

制定配置管理計劃識別配置項定義和管理基線建立配置管理庫配置項控制版本發布變更配置配置設計 ? 對項目策劃階段的支持制定質量保證計劃促進評審配置項控制版本發布分析、評審或審計結果 ? 任務分配任務執行項目例會項目風險管理項目計劃變更管理項目里程碑管理

項目總結 ? 項目度量活動 ? 根因分析活動 ? 決策分析活動

V 《配置管理計劃》

《基線發布記錄》

《配置狀態報告》《變更追蹤表》

《配置審計報告》已標識的配置項項目配置管理庫

《版本發布記錄》《變更請求審批表》《項目過程定義》《質量保證計劃》《評審報告》禪道系統禪道系統或jira系統《項目周報》變更后的項目計劃《項目里程碑報告》《項目會議紀要》《風險管理列表》《項目估算書》《項目總結報告》《項目提交給過程資產庫的資料清單》《項目度量規格定義》《項目質量目標跟蹤表》《問題根因分析與解決記錄》

《項目質量目標跟蹤表》《決策分析評議表》丿

圖 4-1 基于 CMMI 的軟件項目建設質量管理體系

上圖所示為 CMMI 在一般軟件項目建設中的應用，包括主要的軟件項目工程、支持過程域，以及主要過程域對應產出的文檔。

( 1)工程過程

工程過程主要包括項目啟動、項目策劃、需求開發、設計開發、軟件測試及上線發布。項目啟動包括公司下達項目的啟動、軟件產品研發的立項和啟動、預研項目啟動及小微項目啟動。項目策劃過程包括項目定義、項目拆分、風險分析、軟件評估、定制項目計劃、項目評審。需求開發過程包括需求開發計劃、需求調研/培訓、需求分析、用戶確定需求、需求測試、建立需求基線、提出需求bug。設計開發過程包括需求培訓、系統架構設計、概要設計、詳細設計、編碼、單元測試、代碼走查、設計變更。軟件測

試過程主要包括制定軟件測試計劃、設計軟件測試用例、軟件測試程序設計、軟件測試、缺陷管理。上線發布過程主要包括版本發布計劃、建立版本基線、版本發布記錄、發布現場。

（2）工程過程文檔

項目啟動階段產生的工程過程文檔包括《預研項目立項申請書》、《部門項目任務書》、《項目啟動會會議紀要》。項目策劃階段產生的文檔包括《項目過程定義》、禪道或 JIRA 系統、《風險管理列表》、《軟件估計書》、《軟件開發計劃》。需求開發階段產生的文檔包括《需求開發計劃》、《項目培訓記錄》、《提問單》、《用戶界面需求》、《軟件需求規格說明書》或《單個模塊需求文檔》、《需求評審報告》、《需求評審會議紀要》。設計開發階段產生的文檔包括《項目培訓記錄》、《項目架構設計備選方案》、《決策分析報告》、《采購申請單》、《概要設計說明書》總體架構設計部分、《概要設計說明書》、《概要設計說明書評審報告》、《詳細設計說明書》、《詳細設計說明書評審報告》、代碼、《單元測試用例》、《單元測試報告》、《變更請求與審批表》、變更的內容（文檔與代碼）、《安裝手冊》、《用戶手冊》。軟件測試階段產生的文檔包括《軟件測試計劃》、《軟件測試用例》、測試程序、腳本設計說明書、軟件測試報告、已錄入缺陷管理系統得到管理的缺陷、《驗證與確認計劃》。版本上線階段產生的文檔包括月度版本發布計劃、禪道記錄版本發布、建立版本基線、現場bug 錄入禪道。

（3）支持過程

支持過程主要包括配置管理、質量保證、項目跟蹤與監控、度量與分析、根因分析、決策分析。配合管理過程包括制定配置管理計劃、識別配置項、定義和管理基線、建立配置管理庫、配置項控制、版本發布、變更配置、配置設計。質量保證過程包括對項目策劃階段的支持、制定質量保證計劃、促進評審、配置項控制、版本發布、分析評審或審計結果。項目跟蹤與監控過程包括任務分配、任務執行、項目例會、項目風險管理、項目計劃變更管理、項目里程碑管理、項目總結。

（4）支持過程文檔

配置管理產生文檔包括《配置管理計劃》、《基線發布記錄》、《配置狀態評估》《變更跟蹤表》、《配置審計報告》、已標識的配置項、項目配置管理庫、《版本發布記錄》、《變更請求審批表》。質量保證過程產生的文檔包括《項目過程定義》、《質量保證計劃》、《評審報告》、禪道系統。項目跟蹤與監控過程產生的文檔包括禪道系統或 JIRA 系統、《項目周報》、變更后的項目計劃、《項目里程碑報告》、《項目會議紀要》、《風險管理列表》、《項目估算書》、《項目總結報告》、《項目提交給過程資產庫的資料清單》。度量與分析過程產生的文檔包括《項目度量規格定義》、《項目質量目標跟蹤表》。根因分析過程產生的文檔包括《問題根因分析與解決記錄》、《項目質量目標跟蹤表》。決策分析過程產生的文檔包括《決策分析評議表》。

4.2.1.2 基于敏捷開發的質量管理體系構建

軟件生命周期模型與軟件工程理論的發展相輔相成早期的時候為了對處于無序和混亂狀態下的軟件開發過程進行管理軟件開發被嚴格按照幾個不同的階段進行劃分并在劃分的各個階段之間進行嚴格的檢查希望通過這樣的方式嚴格控制軟件研發的質量這樣的軟件管理模式就是早期的瀑布式開發模型。瀑布式開發模型需要在項目的早期就能夠準確地對軟件的需求進行定義在實際的軟件項目建設過程中項目初期就能夠對需求準確把握是一件很困難的事情因此使用瀑布式開發模型進行軟件開發成功率往往不高敏捷開發則不同它是一個增量和迭代的開發框架逐步取代了傳統的基于文檔驅動的瀑布式開發模型基于敏捷開發的軟件研發過程通常由幾個短的迭代周期構成每個迭代周期結束后對本次迭代周期的軟件需求的研發情況進行檢查和評價對于沒有完成的功能需求放入到下一個迭代周期中進行研發通過幾個這樣的迭代周期能夠快速地迭代出最新的軟件交付版本大大提高了軟件研發的效率軟件的需求也在迭代開發的過程中不斷的被細化敏捷開發模型克服了瀑布式開發模型在項目建設初期就需要充分了解需求的缺點。

在智慧園區軟件項目建設質量管理中對于直接面向客戶使用的軟件需求變化較大，基于CMMI的質量管理體系在實際項目建設過程中周期較長，需求變更響應慢，因此對于這類應用軟件開發采用敏捷開發模型在敏捷開發的過程中更多地依賴于自動化工具幾乎不要求文檔輸出為了能夠對敏捷開發的質量進行管理和跟蹤采用角色和文檔相互結合的方式實現軟件項目質量管理方法敏捷開發模型中角色通常分為產品負責人、開發團隊和敏捷開發過程管理人員。

（1）產品負責人負責確定軟件的驗收標準與交付時間負責維護項目需求文檔包括需求的詳細描述需求版本計劃等。

（2）敏捷開發過程管理人員從用戶的角度出發確保用戶的需求可以清楚地傳達給研發團隊同時對敏捷開發的流程進行管理確保敏捷開發的各項活動能夠順利開展和產品負責人共同維護概要設計的更新對于新項目、軟件功能重構和新功能的研發需要輸出相應的概要設計文檔。

(3)研發團隊，負責按需求開發功能，人數通常控制在 5-10 人左右，在研發過程中對概要設計和接口文檔進行維護，接口文檔主要包括接口說明、字段定義、字段類型、值定義、錯誤碼等。

4.2.1.3CMMI 與敏捷開發相融合的質量管理體系

在軟件質量管理體系中，CMMI強調軟件開發的標準流程規范在軟件開發中的作用，敏捷強調協同、變更及快速響應需求，特別強調自動化工具在軟件開發中的作用， CMMI 和敏捷都是比較好的軟件開發模型，但是對于不同的軟件項目、項目的不同階段來說，往往有所差異，比如對于大型的基礎平臺軟件，使用 CMMI 更加合適，而對于需求變化快，需要快速進行需求響應的軟件，使用敏捷開發更加合適。 CMMI 也可以和敏捷進行融合，相互之間取長補短，既克服了 CMMI 研發周期長、需求響應慢的缺點，也克服了敏捷研發過程中不關注文檔的缺點。將 CMMI 與敏捷相互結合，構建了一種同時適用于平臺類軟件和應用類軟件的質量管理體系， CMMI 與敏捷相融合的質量管理體系如圖 4-2 所示。

圖 4-2 CMMI 與敏捷相融合的質量管理體系

在CMMI與敏捷開發相融合的質量管理體系中，敏捷開發模式主要應用在CMMI體系中的項目級活動，過程管理類、量化管理類、過程資產庫、項目管理和支持類等組織級活動仍然采用CMMI體系中的管理模式。如上圖所示，公司組織級管理采用CMMI體系，對公司的過程管理領域、過程資產庫和組織級的項目管理類和支持類活動強調流程制度化重視風險可控性對知識和經驗從組織級進行整體把控。公司智慧園區軟件項目則采用敏捷方式需求變化大人員分解成不同小組整體素質較高每次通過2-4次迭代,完成每輪迭代。基于CMMI與敏捷相融合的質量管理體系,一方面在CMMI質量管理體系中引入了敏捷開發提升了軟件研發迭代的速度提高了研發效率；另一方面通過 CMMI 組織級活動的運作能夠不斷優化項目管理過程彌補了敏捷開發模式下弱化文檔的缺點。

組織級質量管理主要包括過程管理類活動、量化管理類活動、過程資產庫、項目管理類和支持類活動。

（1）過程管理類活動。過程管理類活動主要包括收集過程改進建議、分析確認改進機會、定義/制定過程改進方案、制定過程改進計劃、過程試點與完善、過程發布通過過程管理類活動不斷地改進企業的軟件研發的過程。過程改進意見來自多方面可以是A智慧園區軟件項目的過程改進建議,也可以是本企業其他軟件項目的過程改進建議。

（2）量化管理類活動。量化管理類活動為過程管理類活動和過程資產庫提供量化的過程改進數據主要包括收集過程度量數據、分析過程性能、建立與完善過程性能模型、更新組織級過程性能基線。過程度量數據主要包括項目進度度量、項目工作量與成本度量、規模與生產率度量、評審缺陷度量四部分項目進度度量指對項目建設各階段的計劃完成時間、實際完成時間及偏差進行度量。項目工作量與成本度量指對項目各階段計劃工作量、實際工作量、工作量偏差、成本偏差進行度量。規模與生產率度量對軟件項目的需求設計、系統設計、測試用例編寫、代碼編寫、用戶手冊等完成的規模、工時及生產率進行度量。評審缺陷度量針對需求評審、設計評審、測試用例評審、代碼走查、用戶手冊評審等花費的時間、發現的缺陷數及單位規模里缺陷的個數進行度量。針對過程度量的數據可以發現建設過程是否存在問題為過程改進提供量化的數據支撐。

（3）項目管理類和支持類活動。項目管理類和支持類活動指軟件項目建設過程中起著輔助作用的活動，主要包括過程與產品質量保證（Process and Product Quality Assurance , PPQA）、決策分析、度量分析、問題管理、風險管理、人員管理、配置管理、培訓管理和評審管理項目管理類和支持類活動的開展為軟項目級活動提供保障。

（4）過程資產庫。 A 智慧園區軟件項目建設單位已形成的過程資產庫主要包括標準過程庫、優秀案例庫、制度規范庫、風險列表庫、度量數據庫、裁剪指南庫、研發環境庫、培訓資料庫、文檔模板庫、軟件重用組件庫、重用算法庫、經驗教訓庫、評審檢查單庫、專家庫及改進建議庫等 15 個庫，匯集了組織的各種過程文檔、組織級標準、規范、指南、模板、項目的經驗教訓和軟件開發過程中產生的各種數據和優秀案例等信息資料，這些信息資料在規范化管理軟件開發、內部培訓、信息交流等方面都發揮著重要的作用。

1）標準過程庫。標準過程庫主要包括CMMI中22個過程域的標準過程，以及項目建設過程中產生的標準過程，比如在智慧園區軟件項目建設中形成的需求評審標準過程、系統集成標準過程等，通過對標準過程進行裁剪，可以獲得項目所適用的標準過程。

2）優秀案例庫。優秀案例庫包括有典型代表意義的優秀案例，可以為其他項目的建設提供借鑒，為組織級實施過程改進提供輸入。

3）制度規范庫。制度規范庫包括項目建設過程中形成的各類制度和規范信息，對于軟件項目而言，研發交付的成果物能夠正常的運營和使用，往往需要建設和軟件項目配套的制度和規范，配置相應角色的人員，讓軟件能夠正常運作。另外，對于軟件項目建設過程的管理同樣需要相應的制度和規范進行保障。

4）風險列表庫。風險列表庫包括各類組織級風險信息，包括風險的類型、風險的影響、風險具體的防范措施等，風險列表庫為項目級的風險識別提供參考。

5）度量數據庫。度量數據庫包括各種公共測量項和測量數據，包括研發投入的人員成本、研發投入的時間、研發投入產出率等，通過度量數據庫為項目級的過程改進提供量化數據的參考。

6）裁剪指南庫。裁剪指南庫描述了組織級標準過程進行裁剪的準則和規程，指導具體的項目根據自身特點對組織的標準過程集進行裁剪。

7）研發環境庫。研發環境庫描述了軟件研發過程中使用的工具，主要包括標準硬件工具、標準軟件工具，詳細描述各種工具的版本、功能等。為項目級提供軟件研發的標準工作環境。

8）培訓資料庫。培訓資料庫主要包括培訓需求、培訓計劃、培訓課程、培訓講師、培訓資源等，為組織層面和項目層面的實施培訓提供參考。

9）文檔模板庫。文檔模板庫包括項目總體計劃、需求說明書、概要設計、數據庫設計、詳細設計、安裝部署手冊、源碼配置手冊、測試計劃等文檔模板庫，為項目層面的文檔編制提供了指南。

10）軟件重用組件庫。軟件重用組件庫包括可重用的軟件模塊，項目級使用軟件重用組件庫可以減少軟件開發的工作提高軟件開發的質量。

11）重用算法庫。重用算法庫包括可重用的算法信息包括算法的功能、所采用的的數據結構、步驟、使用范圍和使用項目級可以直接使用重用算法或進行少量修改后使用提高軟件項目研發的效率。

12）經驗教訓庫。經驗教訓庫記錄了項目執行過程中存在的經驗和教訓為具體項目的實施提供借鑒。

13）評審檢查單庫。評審檢查單庫包括對過程、需求、功能等進行評審的檢查單項目通過使用相應的檢查單進行評審和審查能夠提高評審的針對性和有效性為組織層的實施過程改進提供依據。

14）專家庫。專家庫包括本單位軟件方面的專家信息便于實施同行評審時邀請合適的專家。

15）改進建議庫。改進意見庫為相關人員提交的過程改進的意見為組織級實施過程改進提供參考。

項目級工程類活動在參考組織級質量管理過程資產庫中標準過程的基礎上開展同時項目級工程類活動中產生的過程改進建議和過程度量數據可以作為過程管理類活動和量化管理類活動的輸入不斷改進組織過程資產項目級工程類活動的具體過程如下：

（1）構建軟件產品需求池。需求會來自于外部（市場需求、用戶反饋）或內部（戰略規劃）以敏捷的方法來收集需求可以采用用戶故事的方法。根據收集的需求梳理產品需求池產品需求池的梳理貫穿敏捷開發項目的整個生命周期。

（2）確定下一個迭代需要完成的需求。對需求池中的內容進行分解產品負責人首先需要確定每一個迭代需求的內容通常按照迭代開發的周期來確定一般都是按照一周的時間安排然后需要規劃出接下來的一個個迭代要開發的需求形成迭代開發需求列表。

（3）迭代需求分解為待開發功能清單。產品負責人和開發團隊對迭代需求進一步進行分解形成本次迭代需求待開發功能清單也就是具體的開發任務。

（4）預測待開發功能的完成時間。當整個團隊對待開發功能清單沒有疑問或意見后，即可繪制燃盡圖，將待開發功能清單按照日程分配到看板上，安排進行開發。

（5）開始開發。開始進行待開發功能清單上的功能研發。

（6）每日站會。在一個迭代需求的研發進程中每天舉行一次站會站會的目的是跟進當前迭代需求的研發進度解答團隊成員的疑惑及時解決問題避免對進度產生影響。

（7）迭代需求完成情況評審。當一個迭代需求的功能研發完成后，項目組對此需求進行評審，過審通過則發布版本，如果不通過評審則推入下一個迭代需求中繼續進行研發。在當前迭代需求中無法完成的任務，也應該推入到下一個迭代需求中進行研發。

（8）迭代需求研發過程回顧和總結。迭代需求研發過程回顧和總結會議，審視上一個迭代需求研發過程中存在的問題，吸取教訓，總結經驗，然后推動下一個迭代需求的研發。

4.2.2 需求管理策略構建

1991 年由 J.Martin 提出了 “需求工程"（requirement engineering，RE）概念：以工程化（過程、方法、工具）的方法解決需求相關的問題，需求管理主要包括需求定義、需求分析、需求跟蹤、需求變更等，需求管理的目標是項目參與各方對項目需求達成共識，有效應對需求可行性、優先級、變更控制三個主要的制約因素，使得需求最終能夠滿足業務目標的要求，能夠如期的、保質的上線運營，否則則會出現客戶需求理解錯誤；開發人員主觀臆斷，比用戶“更清楚需求”；新需求沒完沒了；因為修改某需求，導致其他需求失效或引入新的缺陷；不合理的進度要求和計劃等各種各樣的問題。需求管理通常包括如下工作：

（1）準備工作。在準備工作階段，需要熟悉項目建設的內容，尤其是項目建設目標、項目相關干系人、軟件功能架構、軟件技術架構、需求池管理方案、需求優先級策略等。

（2）需求定義。需求的定義指確定項目的宏觀需求，即項目的目標和范圍。需求獲取有很多方法，主要包括用戶訪談、文檔研究、原型設計、現場觀摩等。

（3）需求分析。需求分析指開發人員通過研究和分析，準確了解用戶和項目的功能、性能、可靠性等具體需求，并將用戶的非正式需求轉化為完整的需求定義。需求分析本質上是業務分析，即選擇一種業務導向的線索將零散的用戶需求串起來，形成一個體系完整、內容清晰的需求框架。需求分析的任務并不是分析系統如何實現用戶的需要，而是解決目標系統“做什么”的問題。

（4）需求設計。在需求分析的基礎上，需求的具體實現方案進行設計。

（5）需求評審。需求評審在需求管理中起著承上啟下的作用，通常通過需求評審會議的形式對需求進行評審，評審的目的是讓項目的相關方對項目需求的業務目標、技術方案、交互細節、優先級、責任人、排期計劃七個方面達成共識。下文將對需求的主要評審策略的構建進行詳述。

（6）需求研發。技術經理帶領研發人員按照研發計劃研發需求對應的軟件功能。

（7）需求測試。測試人員依據需求場景進行測試用例設計和評審。

（8）需求上線。需求經過研發測試后上線試運行項目經理對上線的需求功能進行驗收。

（ 9）階段復盤。項目經理組織相關方定期對項目工作進行復盤積累經驗總結教訓。

需求評審是需求管理的重要組成部分其目的是讓項目干系人了解需求的背景和目的提前確定項目需求實現的過程和方法讓參與人員清楚地了解工作內容和交付時間讓研發和測試人員對產品的研發周期進行評估讓項目經理做決定是否再進行任務拆分增加資源等。在評審過程中一些常見的問題往往會導致需求評審會議的失敗和評審次數的增加一般會采取分級評審、階段評審、建立標準評審流程、充分利用需求評審檢查表等相關策略包括做好評審前的溝通和準備認真挑選評審人員培訓評審人員做好評審后的跟蹤工作正式評審與非正式評審相結合等。需求評審通常需要分析需求的充分性、一致性、可修改性、可追溯性、完整性、可行性、必要性、優先級、模糊性、可測試性和標準化。最重要的部分是需求的可行性、優先級和變更。針對智慧園區軟件項目規模龐大需求復雜多變的情況下構建了需求的三階段評審策略對需求的可行性、優先級和變更進行評審智慧園區軟件項目建設需求管理三階段評審流程如圖 4-3 所示對于新申報的需求進行可行性評審通過可行性評審的需求進入到業務需求池未通過可行性評審的需求將被拒絕。對于需求的變更或撤銷進行需求的變更評審通過變更評審的需求變更進入到業務需求池未通過變更評審的需求將拒絕變更。針對通過可行性評審和變更評審的需求進入到業務需求池對業務需求池中的需求進行優先級評審優先級評審完成后輸出需求池列表。需求池列表中的需求將進入到軟件研發階段通過軟件開發實現具體的功能。

I需求變更p

I需求撤銷p

圖 4-3 智慧園區軟件項目建設需求管理的三階段評審流程圖

需求的可行性評審主要從技術、業務領域、資源、工期和質量五個角度進行考慮。

（1）技術。從技術的角度對需求進行可行性評審，主要考慮需求項的技術實現是否存在技術障礙，技術障礙消除的難度，如果技術要求在園區軟件項目技術框架的范圍內，那么技術障礙可以消除，反之，如果超出了技術框架范圍，技術問題很難得到解決，可能會投入大量的資源。

（2）業務領域。從業務領域的角度對需求進行可行性評審，主要考慮需求項的實現是否存在業務領域的障礙，業務領域障礙消除的難度。比如針對智慧園區企業服務中，園區管委會通常需要對企業的經營指標情況和企業的能耗情況進行關聯分析，從而發現企業上報的經營數據和實際運營情況是否符合，其中企業經營指標數據是智慧園區軟件項目中的建設內容，能夠直接獲取到，而能耗使用情況，需要與電力、自來水、燃氣等公司進行數據交互，存在跨業務領域的情況，針對這樣的需求需要考慮電力、自來水、燃氣等公司是否能夠配合提供相關數據。

（3）資源。從資源的角度對需求進行可行性評審，主要考慮需求項的實現是否存在資源不足的情況，該資源不足的情況是否能夠解決。這里的資源主要指經濟和人力資源，需求項的開發是否超出了軟件項目本身的建設成本。

（4）工期。從工期的角度對需求進行可行性評審，主要考慮需求項的實現是否存在影響進度的情況，是否可以通過壓縮工期、加班等方式進行解決，解決的難易程度如何。

（5）質量。從質量的角度對需求進行可行性評審，需要考慮需求項目是否存在因質量要求過高而無法實現的情況。

需求的優先級評審的步驟主要分為三步：

（1）確定優化級劃分的原則和標準。需求的優先級劃分，主要根據需求在軟件項目中產生的價值和開發成本兩個因素決定，對于A智慧園區軟件項目而言，需求的價值可以從用戶量、使用頻率、迫切程度、企業服務提升、管委會日常管理效率提升等方面進行考慮；需求開發的成本主要指需求項開發工作量、外部資源協調等對于開發工作量需要在對需求充分理解的基礎上讓開發人員參與一起進行工作量的評估。

根據需求價值和需求開發成本進行需求項優先級劃分的規則如圖 5-2 所示坐標系的橫軸代表需求開發的成本越往右代表需求的開發成本越高縱軸代表需求的價值越往上代表需求的價值越高通過坐標系四個象限的劃分將需求的優先級分為三類：

Pa優先級，代表需求價值高、開發成本低，需求項的優先級最高；

PB 優先級有兩類分別是需求價值低開發成本也低和需求價值高開發成本也高的情況對于這類需求項的優先級處于中間；

Pc優先級，代表產品價值低、開發成本高，這類需求項的優先級最低。

需求價值+

PA PB

PB Pc

需求開發成本

圖 4-4 根據需求價值和需求開發成本進行需求項優先級劃分示意圖上述的對需求進行優先級分類的方法在實際項目運用過程中很難明確地界定需求的優先級為了對需求的優先級進行量化分析根據需求價值和需求開發成本進行需求項優先級劃分的原理構建需求優先級量化計算公式：

需求價值（設計工作量+研發工作量+測試工作量）其中需求的價值根據用戶量、使用頻率、迫切程度、企業服務提升、管委會日常管理效率提升等因素綜合判斷后進行打分得分范圍為 1-10 分。設計、研發及測試工作量為對應的人天數。

（2）根據定義的原則和標準對需求項劃分優先級。根據需求優先級量化的計算公式。

（3）需求優先級評審檢查。通過檢查確定是否所有通過可行性評審的需求項都設定了優先級不存在沒有設定優先級的需求項。

需求的變更評審在軟件項目建設過程中經常會發生需求變更需求變更的原因有外部原因也有內部原因其中外部原因主要有需要解決的問題本身發生了變化、用戶改變了主意、外部環境發生了變化等內部原因主要有需求收集與分析的缺陷、變更管理失當等。需求變更的類型主要有以下幾種。

(1)功能性需求變更。簡單的講，就是解決一個業務問題，需要上線什么功能。比如公共信息平臺中，為了保證系統能夠在各個系統間進行交換和流轉，需要上線數據共享與交換功能。

(2)體驗型需求變更。一般產品介紹CS端產品和BS端產品的區別時，一般會提及 CS 端注重交互體驗，而 BS 端注重企業降本增效，這里的交互體驗，就是體驗型需求的一種，為非功能性需求，體驗型需求主要涉及界面的變動。

(3)數據類需求變更。數據類需求變更，主要是與數據處理、數據展示等相關的需求變更，比如根據角色做數據隔離；報表系統上線，協助業務部門分析決策；系統遷移、對接，接口字段的定義、互傳等。

(4)規則類需求變更。規則類需求變動，一般和數據類需求、功能類需求變更一同出現，大的規則類需求的變動，可能會導致產品架構大規模的調整，甚至推到重來。

4.2.3 系統集成管理策略構建

智慧園區軟件項目的系統集成通常指軟件系統集成，基于物聯網技術將火災報警系統、求助對講系統、車位引導系統、建筑自動系統等各類專業化子系統進行整合，一方面構建統一的園區智能化設備運維和管理平臺，實現管理的集成化，為園區物業管理提供便捷的信息化手段；另一方面通過匯聚園區內部智能化設備的運行指標數據和告警數據，實時展示園區智能化設備運行態勢，為園區智慧化運營提供底層的數據支持。

智慧園區軟件項目建設中系統集成主要指軟件系統間的集成，通過接口開發的方式接入第三方系統的數據，或向第三方系統輸出數據，針對系統集成的質量管理，往往只關注了接口開發、對接、測試等階段，忽視了接口開發前各種環節的質量管理，智慧園區軟件項目需要集成的子系統較多，為了能夠有效對軟件系統集成進行管理，構建了包括集成需求調研、集成數據分類、對接流程規劃、接口設計、接口管理、搭建環境、接口開發、對接測試等環節的軟件系統集成管理流程，并重點對集成需求調研、集成數據分類、對接流程規劃、接口管理進行重點管理。智慧園區軟件項目系統集成質量管理流程如圖 4-5 所示，首先對系統集成進行需求調研，通過與智能化設備廠家進行溝通交流，了解系統的基本情況、對接協議等，形成調研記錄。然后開發工程師針對調研記錄對需要集成的數據進行梳理和分類，設計工程師梳理各智能化子系統的對接流程，形成文檔。集成數據分類和系統對接流程規劃通過項目經理審查后，由設計工程師對接口進行設計，形成設計文檔，在接口設計的同時由于環境的變化可能導致接口發生變更，比如智

能化廠家對軟件進行了升級因此需要對接口進行管理記錄接口的變更情況。接口設計文檔通過項目經理審查后開發工程師搭建集成環境并在此環境中進行接口的開發與測試。開發測試完成后由設計工程師和項目經理對集成的數據進行質量檢查確保接入的數據符合要求。最后對開發的接口程序進行打包并上線發布。

圖 4-5 智慧園區軟件項目系統集成質量管理流程圖

4.2.4 軟件運營管理策略構建

智慧園區軟件項目的建設不僅完成軟件項目的交付還要能夠讓軟件或服務在園區內正常運營因此軟件運營階段的管理也是智慧園區軟件項目建設的一部分通過構建有效的軟件運營管理策略提升智慧園區軟件或服務的運營能力運營管理策略主要從運營服務提升、運營體驗提升、運營決策提升三個方面進行構建智慧園區軟件項目軟件運營質量管理流程如圖 4-6 所示。

圖 4-6 智慧園區軟件項目軟件運營質量管理流程

智慧園區軟件項目建設最終面向用戶的服務主要包括公共技術服務、產業公共服務、園區增值服務、園區基礎服務、產業招商服務、社會化服務、企業服務、園區生活服務等為了能夠更加聚焦軟件服務提高軟件運營管理的效果從運營服務、運營體驗、運營決策三個方面構建軟件運營管理策略。

（1）運營服務提升

通過識別運營主要對象重點關注其所對應的軟件服務在運營過程中對服務的運作情況進行跟蹤并持續優化服務的運作機制確保運營服務能力的持續提升對于不同類型的產業園區運營的主要對象和軟件服務有一定的差異。以工業型智慧園區為例園區管委會的主要職責是通過產業招商吸引企業入駐生產因此園區管委會、園區企業是智慧園區主要的運營對象對于園區管委會來說為了能夠更好地對產業招商進行管理可以引入“金字塔模式”的產業招商逐級管理策略實現產業招商各階段的精細管理提高產業招商管理效率；管委會為了能夠吸引更多的企業入駐園區通常會采取企業稅收、財政扶持、安商穩商等一系列招商政策因此需要提供各類企業服務通過引入持續跟蹤的企業服務機制提高智慧園區企業服務的能力。

（2）運營體驗提升運營體驗指用戶在使用園區提供的軟件或服務時的用戶體驗度提供良好的用戶體驗是軟件或服務成功的關鍵因素為了能夠提高園區用戶使用軟件或服務的用戶體驗引入的眾測模式對運營體驗方面的問題進行收集和管理通過優化軟件功能有效提升用戶的體驗，增加用戶在園區服務上的使用粘度。

( 3)運營決策提升對于園區管委會，從園區長期運營和發展的角度，構建全面、動態的運營數據庫，在此基礎上對園區運營過程中產生的數據進行統計分析，為園區管委會優化和完善園區管理制度的決策提供數據支撐。

4.3智慧園區軟件項目建設的質量管理策略的實施保障

4.3.1組織架構

圖 4-7 智慧園區軟件項目建設的三級組織架構

為了保障智慧園區軟件項目建設的質量管理策略順利實施，構建了智慧園區軟件項目建設的三級組織架構，如圖 4-7 所示，第一級為項目領導小組，對整個軟件項目的建設和質量管理負全面領導責任，第二級是項目經理和技術總監，對軟件項目的建設負直接管理職責，第三級由商務組、設計規劃組、平臺開發組、培訓組、系統驗收組、文檔組、質量管理組、支持服務組構成，通過三級組織架構，保障智慧園區軟件項目建設工作的順利開展。

各組說明如下：

(1)項目領導小組。對智慧園區軟件項目組負全面領導責任，對項目建設的全過程進行管理，根據建設需要做出決策，從而確保軟件項目的順利實施交付。

(2)項目經理(項目總負責人)。領導項目實施小組，對項目進行計劃、組織、協調和控制，并向項目領導小組匯報，具體工作職責包括識別項目特點，識別并確定項目生命周期階段和階段產物，制定和更新項目管理計劃，監督項目執行狀況，發現問題并確保問題被解決，識別風險、制定風險控制策略，規劃項目團隊的培訓和組織實施內部培訓，決定項目產品版本的發布，向QA經理提交度量數據等。

（3）技術總監（技術負責人）。協助項目經理，監督各職能小組運作及項目的實施進度，及時發現和解決問題。定期召開評審會議，定期向項目經理匯報項目實施進度。

（4）商務組。負責與軟硬件設備制造商的合同簽訂、商務談判，確保設備按時、安全到達客戶現場。

（5）設計規劃組。完成軟件項目的設計規劃、參數制定等工作，對所有參加實施人員進行培訓，負責解決實施過程中的技術問題。

（6）平臺開發組。根據設計規劃組對平臺的設計，負責平臺的全部開發工作，并根據實施中出現的問題調整開發。

（7）培訓組。負責培訓教材的編寫以及培訓的具體安排、組織和協調。

（8）系統驗收組。負責協助項目單位組織完成系統測試驗收。

（9）文檔組。負責收集整理項目實施過程中產生的所有文件（書面文件和電子文件），并及時交付客戶。

（10）質量管理組。對項目實施的各個環節進行質量監督。

（11）支持服務組。負責系統驗收后的技術支持和售后服務。

4.3.2管理措施

為有效管理智慧園區軟件項目建設，對實施中存在的問題進行及時解決，主要采取以下管理措施：

（1）定期項目審查會議。通過審查會議對項目建設過程中的關鍵節點進行審查，避免項目建設出現較大的偏差。

（2）項目分階段控制。在對項目建設目標進行分解和細化的基礎上，實現項目進度和質量控制。

（3）全過程文檔記錄。質量管理組和設計策劃組確定各階段需要提交的所有文件，以及相應的編制人、文件模板、提交和批準方式，形成項目實施管理文件清單。

（4）定期匯報制度和及時匯報制度。定期匯報制度和及時匯報制度主要包括項目實施全過程采取項目周報制度，對軟件需求管理情況采取每日匯報制度，技術方案的制定情況采取隔日匯報制度，對智能化子系統對接情況采取隔日匯報制度，對現場聯調測試情況采取每日匯報制度，對各種應急情況采取實時直報項目經理制度。

（5）項目建設中重點、難點指派專人跟蹤。針對項目建設中存在的重點及難點問題，對項目建設的影響較大，是項目建設的主要風險點，比如項目建設過程中外部對接系統眾多，問題和風險有可能在聯調期間暴露，在過程的組織和溝通將引入難點。與外部系統的對接，實時進度不可控，在數據交互、數據整合等實施過程存在潛在難點。軟件中需要展現的數據來源眾多，數據交互關系及統一規范規劃至關重要，數據標準化、接口標準等規范需要統一制定，否則將會對后期對接數據的完整性、及時性、有效性引入難點等問題，針對重點、難點問題指派專人進行跟蹤。

4.3.3研發環境

為了保證智慧園區軟件項目建設的質量管理策略能夠順利實施，快速構建軟件迭代版本，通過 DevOps（Development 和 Operations 的組合詞）構建研發運維一體化的持續集成、持續發布的環境來實現。 Devops 是一組過程、方法和系統。其概念從 2009 年發展到現在，具有豐富的內容、理論和實踐，通過把開發和運維進行整合，實現開發和運維的自動化，從而加速項目從研發到測試再到發布版本的過程，與CMMI、敏捷開發等關注軟件開發過程的系統不同， DevOps 更注重開發與運維的關系，更加注重如何通過自動化的工具提高研發團隊間的協作和溝通能力，從而更快、更頻繁地交付穩定的軟件版本。 DevOps 的核心理念包括注重溝通協作、持續集成及全生命周期的工具鏈。智慧園區軟件項目軟件研發流程如圖4-8 所示， DevOps 主要對軟件研發的過程進行管理，構建了自動化的測試環境、預發布環境和生產環境，實現軟件的自動編譯、測試及上線發布， DevOps 為智慧園區軟件項目建設質量管理策略的實施提供了研發環境的保障。

圖 4-8 智慧園區軟件項目軟件研發流程

4.4 本章小結

本章主要針對智慧園區軟件項目建設質量管理存在的不足，首先描述了智慧園區軟件項目建設的質量管理策略的設計原則。接著從質量管理體系、需求管理、系統集成、軟件運營四個方面設計了質量管理策略，對于質量管理體系，分別構建了基于 CMMI 和敏捷開發模型的質量管理體系，在此基礎上，提出了一種 CMMI 和敏捷開發模型相融合的質量管理體系。對于需求管理，針對需求管理中重點關注的需求可行性、優先級、變更設計了需求三階段評審策略。對于系統集成管理，從系統集成全過程管理的角度設計了系統集成質量管理流程。對于軟件運營質量管理，從運營服務、運營體驗和運營決策三方面設計了軟件運營質量管理策略。最后對從組織架構、管理措施和研發環境三個方面闡述了智慧園區軟件項目建設質量管理策略的實施保障。

第五章基于A智慧園區軟件項目建設的質量管理策略應用實例

第四章從質量管理體系、需求管理、系統集成、軟件運營四個方面對智慧園區軟件項目建設的質量管理策略進行了設計。本章在此基礎上以A智慧園區軟件項目建設的質量管理為實例，進一步詳細闡述了智慧園區軟件項目建設的質量管理策略的實施過程。最后對質量管理策略的實施成效從定性和定量兩方面進行分析和評價。

5.1 A智慧園區軟件項目建設質量管理實例

A 智慧園區是工業類型的產業園區，主要服務對象為園區管理方、入駐園區的企業，其建設內容主要包括園區公共信息管理平臺、園區地理信息基礎服務系統、指揮中心大屏綜控系統、園區統一服務門戶等基礎平臺，以及園區物聯感知大數據綜合展現系統、園區綜合指標體系分析展現系統、園區管理業務系統、園區服務手機APP應用、BIM三維可視化展現系統以及園區IT運維管理系統等擴展應用內容。Z公司負責A智慧園區軟件項目的建設工作，作為一家致力于通信、建筑、信息化等領域的服務商，針對通信、建筑及節能環保工程項目的建設,公司內部形成了一整套基于IS09000的質量管理體系。對于軟件研發管理，Z公司先后通過了 CMMI3、CMMI5質量管理體系認證。功能架構如圖 5-1 所示：

圖 5-1 A 智慧園區軟件項目功能架構圖

（1）園區公共信息管理平臺。園區公共信息管理平臺提供了目錄管理與服務、數據的共享與交換服務、數據整合服務、對外數據服務接口以及基礎數據管理服務等底層管理功能。

（2）園區統一服務門戶。園區統一服務門戶為智慧園區智能化系統中的各軟件子系統及平臺提供統一登錄入口和信息展現界面，方便園區各類使用者通過平臺完成園區管理的相關工作，并且提供統一的身份認證和管理功能，同時也提供園區辦事大廳等面向社會公眾開放的服務。園區統一服務門戶為平臺管理員、數據服務用戶和智能應用開發者提供了基于公共信息平臺數據的一些公共功能，將人、數據、信息等各種信息化要素有效結合。門戶系統的建立可以大大減少開發量，提高系統的靈活性，快速響應政府信息的變化，為用戶提供統一的良好體驗。功能主要包括園區公告、通知、新聞、園區網上辦事大廳、園區信息管理、信息查詢、辦公入口服務等相關應用服務及身份管理、統一認證、授權管理、安全審計、服務集成等基礎配置功能。

（3）園區地理信息基礎服務系統。園區地理信息基礎服務系統建設一個能夠滿足智慧園區各類業務應用的統一 GIS公共服務平臺，作為各類信息的靜態、動態展示基礎, 將園區監控、園區管理、園區服務等業務要素，結合地理信息進行呈現，為智慧園區各種態勢信息的展示提供支撐。

（4）指揮中心大屏綜控系統。指揮中心大屏綜控系統，通過大屏綜合控制管理，實現指揮中心大屏展示服務與平臺各智慧專題內容整合聯動，對投影場景、業務操作以及演示編排等提供一體化服務，避免在指揮調度、領導匯報等應用場景下繁瑣的人工控制操作，同時還提供靈活便捷的移動控制終端，可通過平板電腦實現大屏展現的遠程操作。

（5）園區物聯感知大數據綜合展現系統。基于公共信息管理平臺統一采集融合園區物聯感知數據，實現園區樓宇、安防、交通、能耗、環境等相關的數據和視頻信息的綜合展示和管理，對園區領導和管理人員提供綜合監控管理界面，實時、直觀、便捷地了解園區中各軟件項目、各建筑等運行情況，為跨建筑、跨園區聯動指揮奠定基礎。

（6）園區綜合指標體系分析展現系統。基于新型智慧城市建設中的園區管理研究成果，在指揮中心大屏上進行園區綜合指標顯示。

1）經濟治理評價指標。可用于評價人均地區生產產值、 CPI 和居民收入狀況等園區經濟治理方面的評價指標。

2）社區治理評價指標。可用于評價失業率、基尼系數、醫療、住房保障等社區治理方面的評價指標。

3）生態治理評價指標。可用于評價包括水、空氣、土壤和綠化的園區環境綜合質量狀況的指標，同時還能夠對園區的污染防治情況進行評價的園區生態治理方面的評價指標。

4）安全治理評價指標。可用于評價包括刑事案件、治安案件、交通事故和信息安全情況等園區安全治理方面的評價指標。

5）能源治理評價指標。可用于評價園區產業用能水平、用能結構、產值能耗等方面的評價指標。

（7）園區管理業務系統。軟件項目孵化器平臺主要包括軟件項目信息管理、政府信息管理、服務流程管理等。提供軟件項目、軟件項目群組、園區維度的全方位管理，積累各種運營類信息，為園區制定管理措施提供直接依據。園區信息發布指通過多種信息化溝通方式，將信息快速準確地送達園區內指定人群。發布的信息主要包括軟件項目信息、業務信息、通知信息等。

（8）園區服務手機 APP 應用。搭建園區服務手機 APP 應用，針對園區管理人員提供基礎服務應用，提供APP登錄、園區新聞、公告通知、園區基礎信息查詢、項目信息查詢、停車場信息查詢、用戶信息維護、系統管理功能。手機APP應用作為園區管理業務系統和統一服務門戶在移動端的延伸，需提供完善的管理功能，與 PC 端系統做好銜接和互補，充分利用移動終端的便攜性、通知的準確及時性、拍照取證的便捷性等優勢，和 PC 端園區管理業務系統做到優勢互補，更好地發揮園區管理業務系統和同一服務門戶的服務中樞作用。

（9） BIM三維可視化展現系統。基于BIM技術的三維可視化是園區建筑各種智能系統的上層建筑和智能大腦，起著溝通者、監督者、管理者和決策者的作用。依托于 BIM 技術的三維可視化展現系統，綜合應用物聯網技術，打通園區建筑智能化建設的“最后一公里”，是保證園區內建筑運維服務品質和高效運營管理的重要工具，最終實現BIM 與園區建筑運營相結合，BIM與維護管理計劃相鏈接，安全、智慧、綠色建筑的綜合管理需求，實現園區內部建筑模型、隱蔽管網、設備資產、智能化設備運行態勢的三維可視化展現。

（10）園區 IT 運維管理系統

園區 IT 運維管理系統實現對園區機房所有軟硬件設備的監控，當軟硬件設備的運行指標出現異常時候能夠進行告警通知和工單派發，讓運維人員能夠快速進行響應，確保智慧園區各業務系統正常、穩定、高效運行。

5.2A智慧園區軟件項目建設的質量管理策略實施過程

5.2.1質量管理體系

A 智慧園區軟件項目建設按照 CMMI 與敏捷開發相融合的質量管理體系執行，組織級以 CMMI 模式為主，項目級以敏捷開發模式為主。

5.2.2需求管理策略實施

在 A 智慧園區軟件項目建設過程中，由于需求不明確、需求分析不充分、需求變更管理流程混亂、缺乏及時的需求跟蹤等原因，造成了軟件項目建設的質量問題。為了提高A智慧園區軟件項目建設的質量管理，實施應用需求三階段評審策略，避免過度開發, 加快開發進度，提高客戶滿意度，最終提高建設質量。下面從需求獲取、需求可行性評審、需求優先級評審、需求變更評審、需求跟蹤、需求交付等方面詳細說明具體的實施過程。

5.2.2.1 需求獲取

需求獲取方法很多，各有優缺點，使用的時機與具體的執行活動也不相同，在A智慧園區軟件項目需求獲取階段主要采用了用戶訪談、原型設計和現場觀摩相結合的方式，針對園區管委會、工程建設管理部、運營部、物業管理部等部門進行用戶訪談，初步了解用戶的大致需求。邀請園區各業務管理部門去已經建設的智慧園區進行觀摩學習，了解最新的智慧園區建設情況，通過觀摩學習對智慧園區建設的感知，結合用戶訪談的內容進一步深化用戶需求。對于深化后的用戶需求通過原型設計的方式進行展示，進一步明確最終建設的軟件的界面及功能情況，最終將多方確認的需求記錄在需求登記表上，并讓具體的業務部門簽字確認，A智慧園區軟件項目需求登記表如表5-1所示。

表 5-1 A 智慧園區軟件項目需求登記表

A智慧園區軟件項目需求登記表

上報單位上報時間

提岀人聯系電話

需求名稱

需求描述

需求背景

業務場景描述

涉及業務及相關專業規范

時間要求

其他要求

審核意見需求管理部門審核意見：

簽字：日期

對應需求編號接收人

5.2.2.2 需求分析

A 智慧園區軟件項目建設采用的需求分析方法是基于用戶的使用場景對需求進行分析，比如針對園區大屏綜合控制系統，第一種應用場景是上級領導來園區進行觀摩學習，通過大屏綜合控制軟件對大屏的展現內容進行切換，展示園區業務系統的實時運行態勢，根據展示的需要對大屏的區域進行分割，一部分用來展示軟件系統界面，一部分展示ppt、圖片等介紹材料。第二種場景是在移動端對大屏進行控制，為了考慮大屏內容切換的便利性，在PC端的大屏綜合控制軟件的基礎上，將綜合控制能力延伸到ipad 或手機等移動端，在陪同上級領導參觀的過程中隨時根據需要遠程切換大屏的展示內容。大屏綜合控制系統對大屏的控制通過對接視頻矩陣控制器來實現，與視頻矩陣控制器的對接也是園區大屏綜合控制軟件的功能需求。A智慧園區大屏綜合控制系統的功能需求清單如表 5-2 所示。

表 5-2 A 智慧園區大屏綜合控制系統的功能需求清單

序號一級二級功能說明

1 大屏信號對接處理大屏場景展現切換系統可方便地與各種主流品牌大屏進行對接，采用文件配置方式方便控制指定屏幕。具有極強的擴展性及適配彈性。包括對大屏幕的場景展現切換、信號源控制以及其它必要的接口適配功能。

2 信號源控制

3 應用管理應用管理創建和管理應用以及應用的不同版本一個應用主要包括供在大屏上展示的場景和場景分類

4 客戶端管理客戶端注冊該模塊實現大屏工作站客戶端的管理

5 客戶端物理位置編輯、顯示

6 客戶端狀態顯示

7 重啟客戶端及工作站

8 關閉客戶端及工作站

9 工作站異常狀態監測與處理

10 信號源管理內容控制主要實現大屏上顯示內容的控制

11 顯示控制

12 場景編制及管控場景編制及管控 (1)在目標應用下創建場景分類，在目標場景分類下創建場景；

(2)管理各工作站顯示器的物理信號； (3)將每個工作站的多個物理信號組合成邏輯上的一個組合信號；

13 工作站客戶端狀態報告及發送客戶端主程序主要是接受服務器端命令實現網頁、圖片、視頻等操作命令

14 系統信息顯示

15 子進程啟動與管理

16 屏幕截圖與傳輸

17 工作站客戶端守護進程客戶端管理客戶端守護進程主要實現對客戶端管理，包括啟動，關閉客戶端，更新客戶端文件等

18 客戶端狀態監視及報告

19 配置文件及程序更新

20 移動控制終端程序場景切換為工作站控制臺的一種簡化版本，實現通過Pad對大屏展現的控制，其充分利用Pad的便攜性，幫助用戶獲得更好的大屏控制體驗。

21 播放控制

5.2.2.3 需求可行性評審

需求的可行性評審主要從技術、業務領域、資源、工期和質量五個角度進行考慮。

A智慧園區軟件項目根據上述五個需求可行性的評價指標，采用德爾菲法對軟件需求的可行性進行評審。選取 9 個專家對企業經營指標數據分析、企業能耗數據分析、企業社保繳納人數及繳納金額統計分析、園區人口及交通熱力圖展示、園區租售管理五個需求功能進行可行性分析，采用德爾菲法進行了三次評審，如表所示，其中0表示需求項不可行， 1 表示需求項可行，每次評審完將專家的意見匯總后發給專家作為評審的參考意見，通過三輪評審發現，企業經營指標數據分析和園區租賃管理兩個功能，專家達成了可行的一致意見，而對于企業能耗數據分析、企業社保數據統計分析、園區人口及交通熱力圖展示三個功能專家未達成一致，其中認為不可行的專家占多數，主要是因為這三個統計分析的數據來源來源于外部單位，是否能夠得到相關數據暫時還不能確定，因此評審的結果認為不可行。A智慧園區軟件項目需求評審過程記錄如表5-3所示。

表 5-3 A 智慧園區軟件項目需求評審過程記錄表

專家編號審評次一第評次二第審評次三第審

企業經營指標數據分析企業能耗數據分析企業社保數據統計分析園區人口及交通熱力圖展示園區租售管理企業經營指標數據分析企業能耗數據分析企業社保數據統計分析園區人口及交通熱力圖展示園區租售管理企業經營指標數據分析企業能耗數據分析企業社保數據統計分析園區人口及交通熱力圖展示園區租售管理

1 1 1 1 1 0 1 1 1 1 1 1 1 1 0 1

2 1 0 0 1 1 1 0 0 1 1 1 0 0 1 1

3 1 1 1 0 1 1 0 1 0 1 1 0 1 0 1

4 1 0 0 1 1 1 0 0 1 1 1 0 0 1 1

5 1 1 1 1 1 1 1 0 1 1 1 0 0 0 1

6 0 0 1 0 1 1 0 1 0 1 1 0 0 0 1

7 1 1 0 1 1 1 1 0 1 1 1 0 0 1 1

8 1 1 1 1 0 1 0 1 0 1 1 0 1 0 1

9 1 1 0 1 1 1 1 0 0 1 1 1 0 0 1

5.2.2.4 需求優先級評審

A智慧園區軟件項目的需求的優先級評審，對基于需求價值和需求開發成本的需求優先級評分表如表5-4所示。

表 5-4 基于需求價值和需求開發成本的需求優先級評分表

需求項優先級列表

功能模塊子模塊需求描述價值得分

（1-10）工作量（人天）優先級（需求價值十（設計工作量+研發工作量+測試工作量）備

注

設計研發測試

資源目錄管理與服務系統資源分類管理實現資源分類的增刪改查，以實現信息

分類標準的建立。 8 3 10 5 0.44

共享與交

換服務交換配

置管理實現對接系統以及共享資源的配置管理等 9 5 12 3 0.45

系統管理配置管

理實現平臺相關基礎數據的管理、字典管理等。 4 2 5 2 0.44

公共信息

庫管理人口庫

建設實現人口數據的匯聚、形成人口基礎數據庫 8 4 20 5 0.28

法人庫建設實現法人數據的匯聚、形成法人基礎數據庫 8 4 20 5 0.28

GIS庫建設實現GIS數據的匯聚、形成 GIS 基礎數據庫 8 4 20 5 0.28

企業信息管理企業信息管理企業信息的增刪改查及導入導出功能 7 2 5 2 0. 78

招商引資

信息招商補貼政策

管理招商補貼政策、細則的添加、修改、刪除和查看，關聯招商補

貼政策和細則 9 2 5 2 1.00

招商補貼明細管理招商補貼明細信息的添加、修改、刪除和查看 6 3 6 3 0.50

招商補貼統計分析展示指定企業所享受的園區所有招商補貼優惠政策發放和落實情況 4 5 8 5 0.22

IT設施運行監控主機及操作系統監控對采集得到園區各類 IT 基礎資源（服務器、操作系統、數據庫、中間件、應用系統等）的運行監控數據進行監控，當指標高于某個閾值時進行告警。 2 3 8 5 0.13

數據庫監控 2 5 12 5 0.09

中間件及應用監控 2 5 10 5 0.10

從表格中可以看出，招商補貼政策管理優先級最高，招商補貼政策是管委會產業招商的重要信息，需要第一時間進行更新，加上該功能的設計、開發、測試所需的工作量適中，因此優先級最高。對于多個專家的需求優先級得分，選擇中位數作為最終的優先級得分。

5.2.2.5 需求變更評審

對于A智慧園區軟件項目建設中的需求變更，主要是功能性需求變更，項目組通過成立專門的變更評審小組，構建需求評審流程，重點關注需求基線、需求變更影響分析報告等因素，完成對需求變更的評審。

（1）成立專門的變更評審小組。項目變更控制小組，主要負責需求變更的評審工作。該小組應該由參與項目的多方人員組成，變更評審小組負責評審活動的執行。

（2）建立變更評審流程。明確要求變更評審流程、評審人員、評審項目。這樣做有兩個目的：一是盡可能規范需求評審流程，減少高層領導無意的不必要、不緊急、不合理、無效的變更。第二是為將來可能發生的費用變動和索賠留下書面依據。未履行評審程序的“變更”視為無效。需求變更應確保需求、設計、測試等環節的一致性。A智慧園區軟件項目需求變更評審流程如圖 5-2 所示。首先提出變更請求，針對變更的需求進行影響評估，生成需求變更影響評估報告。然后將需求變更影響評估報告提交給變更評審小組進行評審，對于未通過評審的需求變更不予采納，對于通過評審的需求部分，進一步與用戶進行確認，得到用戶認可后，修訂項目建設計劃，實施需求變更，需求變更實施完成后對需求功能進行驗證，滿足變更的要求則需求變更流程結束，否則繼續進行需求變更的實施，直到需求變更得到驗證。

圖 5-2A 智慧園區軟件項目需求變更評審流程

（3）建立需求基線。通常在第一次對需求進行確定和評審后建立需求基線，以后的每次變更都需要對需求基線進行維護，確保當前的需求基線反映了最新的需求情況。

（4）變更影響分析報告。需求變更需要付岀代價，要和客戶一起對需求變更帶來的影響進行評估，評估需求變更的技術及成本的必要性和可行性、可能的變更工作量和對進度的影響、可能受變更影響的項目等。對變更影響的分析通過變更影響分析報告進行記錄，作為需求變更評審的一個輸入材料。A智慧園區軟件項目需求變更影響分析報告模板如表 5-5 所示。

表 5-5 A 智慧園區軟件項目需求變更影響分析報告模板

變更影響分析報告

項目名稱項目經理

變更主題變更編號

變更描述分析日期

分析者工作量（人時）

市場必要性變更帶來的價值

不變更引起的損失

來源

技術可行性

穩定性

優先級

估計總工作量人時

估計對進度的影響天

估計增加的研發成本萬元

沖突的需求

對其他分項的影響

其他風險

初步結論

5.2.2.6 需求跟蹤

A智慧園區軟件項目建設中，需求跟蹤環節的作用非常重要，它可以幫助找到每個需求找到依賴的其他需求或部件，從而確保部件滿足每個需求。它可以從部件或其他需求回溯到依賴它們的需求，指出每個部件或需求存在的原因。它可以評估變更對項目其他部分的沖擊、變更的規模和難度等。由于A智慧園區軟件項目建設中軟件體量大，需求跟蹤的工作量也很大，傳統的需求跟蹤矩陣的管理方式難以有效地進行管理，經常會出現忘記實現了某個需求，需求變更時不清楚要變動的地方，無法評估需求變動的影響，用戶已經取消的需求仍然在設計開發中等問題，因此需要對需求跟蹤環節的管理進行優化。

通過構建前向、后向、直接、間接追蹤相結合的需求跟蹤模型， A 智慧園區軟件項目的需求跟蹤模型如圖5-3所示，前向追蹤指從需求說明書到測試用例的需求跟蹤過程，前向追蹤用于檢查項目是否朝著期望的方向發展，確保每個要求都適用于項目，并且每個要求都經過徹底測試，它將需求映射到測試用例，對需求說明書中的需求進行檢查，確定在后續交付的工作成果中能夠找到對應項。后向追蹤是從測試用例到需求說明書的跟蹤，用于確保當前項目是否保持在正確的軌道上，驗證是否通過添加代碼、設計元素、測試或其他需求中未指定的工作擴大了軟件需求的范圍，它將測試用例映射到需求，對設計文檔、代碼、測試用例等工作成果進行檢查，確定這些成果能在需求說明書中找到具體出處。直接追蹤指從需求說明書到測試用例的跟蹤，間接跟蹤指從需求說明書到系統設計的追蹤，通過直接追蹤和間接追蹤，實現設計、需求及測試用例之間的映射。通過前向、后向、直接、間接追蹤相結合的需求跟蹤模型實現從需求到設計到用例的映射。

5.2.2.7 需求交付

A智慧園區軟件項目建設的需求交付的過程主要分為五個階段，分別是版本內測、

聯調測試、業務穿越測試、業務上線、客戶驗收。

1）版本內測。研發人員、測試人員對需求版本進行功能及非功能性測試，并生

成測試報告。

（2）聯調測試。協調相應的廠家人員，根據事先制定的測試案例、接口協議，進行功能驗證測試，輸出測試報告。

（3）業務穿越測試。協調相應的廠家人員、相關用戶，根據制定的測試案例場景，模擬真實的業務場景進行驗證測試。

（4）業務上線。業務穿越測試結果得到相關人員簽字確認之后，擇機發布生產，發布之前需要制定上線方案、以及上線通知等。

（5）客戶驗收。業務上線運營穩定之后，提供需求上線文件，由相關人員進行簽字確認備案。

5.2.3 系統集成管理策略實施

在A智慧園區軟件項目建設中，需要集成安防管理、建筑管理、信息化等相關專業的智能化子系統19個，A智慧園區軟件項目系統集成內容如表5-6所示，集成的工作量非常大，加上系統集成涉及建設方、分包方、設備供應商等多個單位，協調難度高。為了能夠在項目建設過程中能夠更好地對系統集成進行管理，構建了系統集成管理的流程體系，下面主要從系統集成需求調研、集成數據分類、系統對接流程規劃、接口管理等方面詳細描述質量管理策略的實施情況。

表 5-6 A 智慧園區軟件項目系統集成內容

集成專業智能化子系統集成內容

安防管理火災報警系統通過硬件接口（如RS232）或軟件接口（如OPC）與火災報警系統進行集成，獲取火災報警設備信息。

視頻監控系統通過視頻監控系統提供的SDK集成視頻監控系統。

門禁系統通過OPC接口協議集成門禁系統。實時監測岀入口狀態并記錄電鎖或門磁的開關狀態、岀入口的開關控制、異常的進岀記錄。

入侵報警系統通過OPC，SDK等方式集成入侵報警子系統。實時顯示并記錄系統狀態和報警信息。

求助對講系統通過SDK二次開發包與求助對講系統進行集成。

停車管理系統通過通訊接口方式（如OPC或ODBC）集成停車管理系統。

車位引導系統運維系統通過OPC或TCP/IP的通信接口方式對車位引導系統進行集成。

客流統計系統運維系統通過TCP/IP、ODBC協議對客流統計系統進行集成。

建筑管理建筑自控系統-制冷站通過OPC或BACnet等接口協議與制冷站監控子系統進行集成，完成制冷站各設備的監測和控制，提供實時的運行參數、歷史運行記錄的查詢以及設備的故障信息。

建筑自控系統-空調機組通過OPC或BACnet等接口協議與空調機組進行集成，監測空調機組設備的運行狀態和故障報警信息。

建筑自控系統-給排水控

制通過Bacnet或OPC集成給排水系統，實現給水泵、污水泵、浮球閥開啟數量、狀態監測，水泵房空氣、給水、壓力、頻率監測，給排水液位報警和相應的故障報警。

能源管理系統通過統一的接口（如OPC）集成能源管理系統監控軟件。

智能照明系統通過OPC或者EIB接口接入智能照明子系統，實現對建筑室內照明的回路（基礎照明回路、裝飾燈照明回路、導向標識回路等）、夜景照明回路的狀態監測。

電力監控系統通過OPC方式與電力監控系統進行集成，獲取包括10KV高壓柜、 0.4KV低壓柜、樓層配電柜、UPS系統、柴發監控系統、火災漏電報警系統等運行狀態信息，及變配電管理系統關鍵統計信息。

智能抄表系統通過以太網數據通訊與智能抄表系統進行集成。

信息化信息發布系統通過通訊接口（如OPC接口等）集成信息發布系統。

廣播系統通過TCP/IP協議通信接口方式與公共廣播系統進行集成。

會議系統通過TCP/IP和RS485方式與會議系統進行集成。

物業管理系統通過webservice或者ODBC方式與物業系統進行集成。

5.2.3.1 系統集成需求調研

在系統對接準備階段，需要與廠家人員進行溝通交流，初步了解對接系統及數據的情況，形成文檔作為后期系統對接的依據，對溝通交流的過程及內容記錄的情況很難進行質量管控，如果在這個階段溝通交流不充分，會直接影響系統集成的進度。A智慧園區軟件項目系統集成需求調研表模板如表 5-7 所示，該需求調研表主要分為項目基本信息、組織結構、子系統信息、提供資料、備注五個部分，其中子系統信息和提供資料是重點，子系統信息中記錄了智能化子系統的供應商品牌、現場聯系人及聯系方式、技術聯系人及聯系方式、接口要求、通信協議、點位表基本情況、 CAD 圖紙基本情況、測試環境信息等。提供資料中主要是智能化設備的詳細點位圖、設備清單。通過子系統信息和提供資料可以詳細了解智能化子系統需要對接的內容及工作量，作為編制系統集成計劃的依據。

表 5-7 A 智慧園區軟件項目系統成需求調研表模板

一、項目基本信息

項目名稱：商務項目經理：

項目地址：項目合同金額：

項目甲方單位：

項目合同甲方單位：

建設單位：聯系人：

施工單位：聯系人：

建立單位：聯系人：

商管：聯系人：

弱包：聯系人：

機電包：聯系人：

項目類型：

□國家重點□省市重點

項目進場時間：項目竣工時間：項目工期：

項目目前階段：

□招標□集成測試□前期需求□試運行

項目子系統：.

□暖通空調□夜景照明□其他□停車管理□防盜報警□門禁管理□視頻監控□電咨詢更□信息發布

計量信息類型：

□電量□二氧化碳

設計深度：

□二氧化碳□概況統計

項目軟件名稱（基礎軟件）：

二、組織結構

項目經理：技術負責人：商務協調人：

信息溝通人員：

項目實施人員： *明確標注現場項目實施負責人

技術支持人員： *明確標注現場技術支持人員

子系統廠家負責人員

三、子系統信息（己選）（*請填入己選項目子系統的詳細配置信息）

3.1暖通空調/給排水/變配電/公共照明/夜景照明/電梯監控/消防管理/視頻監控/防盜報警/門禁管理/ 電子巡更/客流統計/信息發布/背景音樂/停車管理/能源管理等供應商品牌：（*標注代

理商、廠家）聯系人及聯系方式（*現場、技術各一

名聯系人）

現場：

技術：

進場時間：

子系統接口要求：

□ TCP/IPDRS232 或 RS485D0PCDBACNet □其他

子系統通信協議：

□ TCP/IPDSDKDOPC □BACNe t□其他

點位表：檢測項—個,控制項—個, *需提供完整測點位表與地址碼提供時間

點：

CAD圖紙： 1、設計圖紙（*完成、最終版本）圖紙要求：包含暖通空調的控制系統原理圖；

2、設備清單（電子版）（清單內容：完成的設備列表、設備的基本信息（包括供貨方，供貨日期）、設備的位置（包括所在建筑、所在樓層、所在區域）、設備的技術規范（設備額定參數）；提供時間

點：

□項目所在地提供測試環境 □總部所在地提供測試環境

（ *提供系統通訊接口測試軟件、測試腳本或者測試語句等）

四、提供資料

□變配電系統圖、干線圖、設備清單聯系人：

□樓間（樓層）配電系統圖、配電柜系統圖、設備清單聯系人：

□空調系統圖、原理圖、設備清單聯系人：

□給排水系統圖、設備清單聯系人：

□室外氣象站系統、原理圖、設備清單聯系人：

□公共照明點位圖、照明回路表、設備清單聯系人：

□夜景照明點位圖、照明回路表、設備清單聯系人：

□電梯監控點位圖、設備清單聯系人：

□消防管理點位圖、設備清單聯系人：

□視頻監控點位圖、設備清單聯系人：

□防盜報警點位圖、設備清單聯系人：

□門禁管理點位圖、設備清單聯系人：

□電子巡更線路圖（在線、離線）、設備清單聯系人：

□客流統計點位圖、設備清單聯系人：

□信息發布點位圖、設備清單聯系人：

□背景音樂點位圖、設備清單聯系人：

□停車管理點位圖與車位引導點位圖、設備清單聯系人：

五、備注

簽字：時間：

5.2.3.2 集成數據分類

目前一些較為大型的系統，都設有標準的第三方接口，如空調自控系統，一般會提

供基于支持TCP/IP或OPC協議方式的數據服務調用，會大大提高數據調用的方便性。但部分系統未考慮到數據的上傳交互，因此需要編寫相應的程序進行數據對接。在上述系統集成需求調研的基礎上，可以對需要集成的數據進行如下分類：

（1）直接從傳感器獲取（以下稱第一類傳輸）。需要傳感器本身有通訊模塊，可

以對數據進行遠傳。部分傳感器有國際（或行業）通用的標準傳輸協議，可以通過485

線或無線傳輸的方式，經過現場的數據采集模塊直接上傳到遠端的服務器，對數據包進

行解碼并寫入數據庫。一些較為特殊的傳感器或沒有標準協議的傳感器，需要設備廠商提供相應的傳輸規約，開發相應的程序，對數據包進行編譯。

（2）提供數據傳輸服務的系統（以下稱第二類傳輸）。對于一些版本較新的大型系統，系統本身提供數據傳輸服務，有標準的數據調用模塊，其系統內部已經有完善的功能。一般這類系統會提供國際（或行業）通用的數據傳輸協議，這類系統的數據解析只需要遵循其傳輸協議，對數據包進行解析即可。這類數據調用不需要通過中間的硬件系統，直接通過網絡傳輸即可，較為方便。

（3）需要編寫傳輸軟件的系統（以下稱第三類傳輸）。相對于提供數據傳輸服務的系統，一些版本較早或本身沒有數據交互需求的系統，往往不提供標準的數據接口，這就需要與系統供應商協商，編寫相應的傳輸軟件進行數據的傳輸。

對于第一類和第二類具有標準傳輸協議或規約、標準接口的數據接入，主要關注接入文檔資料是否齊全，數據接入測試程序是否完整可用等。對于第三類傳輸，需要廠商配合開發程序，需要重點關注這部分的開發費用是否已經包含在合同中，廠家是否愿意配合進行軟件開發，具體的開發對接的計劃等。

5.2.3.3 系統對接流程規劃

在系統集成數據分類的基礎上，對系統對接的流程進行規劃， A 智慧園區軟件項目系統集成流程規劃如圖 5-4 所示，首先確定數據的獲取方式，按照前文的數據分類原則，分為第一類、第二類和第三類數據傳輸方式，分別對應直接從設備傳感器獲取、從數據傳輸系統獲取以及廠家配合編寫數據傳輸軟件后獲取數據三種方式。對于需要直接對接智能化設備傳感器獲取數據的場景，需要詳細了解設備的數據傳輸協議，針對傳輸協議編寫協議解析軟件獲取數據，這種場景主要針對 OPC、 BACnet 等數據傳輸方式。對于從系統中獲取數據的場景，同樣需要詳細了解傳輸協議，根據協議編寫數據獲取及解析代碼，這種場景主要針對 ODBC、 TCP/IP、 SDK 等數據傳輸方式，與直接對接傳感器相比，對接系統方式協議相對簡單，減少了直接與硬件進行對接的復雜度。對于需要廠商配合編寫數據傳輸軟件的系統，確定數據傳輸軟件的編寫方，也可以通過約定中間庫的方式，完成數據傳輸軟件的編寫。接著對系統集成的數據傳輸軟件進行數據傳輸測試和調試，通過調試對傳輸過程中存在的問題進行修改，最終完成系統集成的工作。

圖5-4A智慧園區軟件項目系統集成流程規劃

5.2.3.4 接口開發管理

1、數據接口管理原則

（1）安全性原則。接口設計應確保不會影響到第三方子系統及其他系統的正常運行。

（2）實時性原則。為了保證安全,系統間接口采用 TCP/IP、 OPC、 Bacnet 通訊協議方式進行構建,采用"請求-應答"模式進行開發設計,收到請求后立即同步應答,各系統之前應確保無異步應答及反向推送的任何行為,以確保各個系統的安全運行。

（3）需求方請求原則。各個系統之間,數據交互的會話由有需求一方主動發起,發起方遵從雙方約定的接口規范進行數據請求,任何不符合接口規范的請求都將被拋棄。

2、接口管理

為了能夠與各類智能化子系統進行對接集成，需要開發針對各類智能化子系統的數據接口，同時由于智能化子系統也會更新升級，因此接口需要進行管理，使接口能夠不斷地進行升級優化，A智慧園區軟件項目系統集成接口管理流程如圖5-5所示。

圖5-5 A智慧園區軟件項目系統集成接口管理流程

首先設計工程師根據需求規格說明書對需要開發的接口進行設計，輸出接口設計文檔。緊接著開發工程師根據接口設計文檔進行接口的開發，在接口開發過程中，通常會搭建仿真和正式兩個環境，在仿真環境下完成接口的開發和調試后，將接口軟件遷移到正式的生產環境，這樣做的好處是在正式進行系統對接前通過仿真環境進行驗證，提高正式生產環境下接口對接測試工作的效率，確保系統集成的進度有所保障。在接口開發過程中，智能化子系統的接口會進行版本的更新和升級，因此需要對接口進行變更管理， A智慧園區軟件項目系統集成接口變更管理如表5-8所示。接口變更管理表中重點記錄接口的變更狀態及具體的變更內容，通過該表格，研發人員可以重點對變更的接口進行管理。

表5-8 A智慧園區軟件項目系統集成接口變更管理

項目名稱制表人制表時間文件編碼

編號接口名稱接口類型接口實現版本是否變更變更內容主要功能備注

5.2.4 軟件運營管理策略實施

5.2.4.1 運營服務管理

（1）“金字塔模式”的產業招商逐級管理策略

為了對園區產業招商項目進行有效管理，引入了“金字塔模式”的逐級管理策略，

金字塔模式”的逐級管理策略如圖 5-7 所示。

圖 5-6“金字塔模式”的逐級管理策略

產業招商階段分為匯集項目、洽談跟蹤、遷入辦理、正式遷入四個階段，按照四個階段把項目分為意向項目、洽談項目、在辦項目及遷入項目，對不同階段的項目進行管理的側重點不同，對于意向項目，主要對項目信息來源渠道進行管理，實現項目信息共享，當項目信息發生變化時能夠動態更新。對于洽談項目，對領導批示項目、重點項目進行重點關注，同時對洽談的進度進行跟蹤。對在辦項目實行核定名稱、專項審批、三證管理。對正式入住項目實行合同管理、協議管理、項目備案管理。通過“金字塔模式” 的逐級管理策略，可以對項目的每一階段進行有針對性的管理和跟蹤，提高產業招商工作管理的精細化程度，形成產業招商的高效管理機制。

（2）持續跟蹤的企業服務機制

企業服務是A智慧園區的主要運營業務，在企業全生命周期的各個階段，需要提供不同類型的企業服務，比如在孕育期，需要為企業提供企業策略輔導、技術產品評估、企業項目孵化等服務。在成長期，需要為企業提供技術資源合作、宣傳推廣服務、市場拓展服務、風險投資服務等。在擴張期，需要為企業提供企業發展策略、人力資源服務等。為了能夠提升企業服務質量，在原園區運營管理部門中增設企業服務管理部門，建立一套“7x24”的企業服務跟蹤機制，主要包括以下環節：

1）服務受理。設置專門的服務受理崗位人員，服務受理人員可以通過電話、微信、郵件以及園區配套建設的信息化平臺等方式為企業在日常經營和運作過程中提供服務。

2）服務跟蹤。對企業服務的運行狀態進行跟蹤。

3）服務反饋。及時向企業反饋企業服務的進展情況。

4）時效控制。對企業提供服務，要求在 5 個工作日內解決企業服務所遇到的問題，如果暫時不能解決，與企業相關人員進行溝通，確定后續的解決方案。

5）過程記錄。企業服務的所有環節進行過程記錄，便于后期對服務的環節進行追溯。

6）信息共享。對于不涉及企業商業秘密的和服務相關的內容，可以進行信息共享，建立企業服務知識庫，為其他企業在類似問題的處理提供參考。

5.2.4.2運營體驗管理

隨著產品的迭代速度越來越快，對于產品快速交付的要求越來越高。傳統的軟件測試工作，在軟件功能開發完成后，研發人員對功能進行自檢，然后提交給測試人員進行測試，測試通過后上線。由于公司內部的測試人力有限，對于測試范圍、測試點并不能做到完全的覆蓋，有些公司缺少硬件設備或者環境，導致非功能性測試、兼容性測試都無法得到很好的保證，另外傳統軟件測試主要對軟件的功能及非功能需求進行測試，無法針對用戶使用過程中的軟件實際體驗情況進行測試和評估，而用戶的體驗往往是一個軟件產品質量是否滿足要求的關鍵評價因素，直接影響了軟件產品的實際運營效果。為提升A智慧園區軟件項目的運營體驗，項目采用了眾測模式，即利用大眾碎片化的時間進行測試的一種方式，其優點如下：

（1）縮短軟件測試周期。傳統的軟件測試受限于項目團隊中測試人員數量的多少，眾測模式則依托眾測平臺在短期內招募的大量測試人員，在較短的時間內能夠得到大量的測試結果，有效地縮短了軟件測試的周期。

（2）降低測試成本。大量的測試人員使用碎片化時間來測試產品，這部分測試的成本比傳統測試要低。另外，由于測試周期縮短，整個產品生產的時間成本也降低了。與傳統的測試方式相比，眾測模式能更有效地控制測試成本。

（3）提高產品質量。在傳統的測試中，測試依賴于測試者的經驗，受測試者主觀意愿的限制，有些產品的隱患可能沒有及時發現。眾測模式下的測試人員數量眾多，行業范圍廣，方法不同，環境不同。產品檢測更全面，能發現更深入、更隱蔽的問題，從而更有效地提高產品質量。

（4）改善用戶體驗。眾測模式中，大多數測試人員都有一定的測試知識，對產品有一定的了解和興趣。通過不同的測試方法可以對軟件的各個方面進行測試，在軟件上線前收集用戶的真實體驗，進行優化完善，可以有效地提升軟件的用戶體驗度。

（5）測試人員更有活力。測試人員在眾測平臺提交軟件使用中用戶體驗存在的問題，后臺管理人員進行審核，如果后臺管理員審核通過，則給予測試人員一定的獎勵，通過這樣的模式，測試人員在測試過程中更有活力，測試成本的花費也更有價值。

與傳統的軟件測試方法相比，眾測是一種新的測試方法。隨著互聯網技術的不斷創新，眾測技術將在未來不斷發展。主要方向如下：

（1）測試人員的選配更加專業化、智能化。目前，大多數測試人員通過平臺注冊參與測試任務，隨著平臺的運營，積累的測試人員和測試任務不斷增多，通過數據挖掘和分析可以構建測試人員的用戶畫像，對于新的測試任務，可以根據用戶的過往經驗智能化匹配，使得測試人員的選擇更加有針對性。眾測的核心資源是眾測人員，眾測任務具有多樣性的特點，有聚焦于安全、性能、功能等，也有聚焦于某個特殊領域的，而現有的眾測模式還沒有建立對垂直領域人員的結構優化，比如工業智慧園區軟件測試專家，物流智慧園區軟件測試專家等。建立眾測人員的多層結構，可將測試人員和軟件項目更好地融合。

（2）測試任務更加多樣化。眾測平臺測試任務既可以是用戶體驗度測試，也可以是功能測試、探索測試、安全漏洞測試等。但是由于環境、能力要求、風險要求的局限性使得眾測還無法大范圍的推廣使用，未來眾測技術的發展將聚焦于測試項目的多樣化上。

采用眾測模式實現對A智慧園區軟件項目運營體驗的質量管理，A智慧園區軟件項目運營體驗眾測流程如圖5-7 所示。

圖5-7 A智慧園區軟件項目運營體驗眾測流程圖

主要業務流程如下：

（1）園區管理方在線提交軟件體驗度測試任務，包括測試范圍、測試周期等信息，經平臺審核通過后在測試平臺主頁發布測試任務，如平臺未通過，將流程退回到園區管理方處，重新修改提交。

（2）眾測平臺中的任務分為普通測試任務和競賽任務。普通測試任務指測試任務在平臺發布后，由眾測用戶在任務大廳進行任務認領來申請參與測試項目，測試人員資格審核分為后臺管理人員人工審核和系統自動審核兩種，測試資格審核通過后，系統將測試內容以消息形式發送給眾測用戶，如果人員資格審核不通過，則后臺自動將審核結果推送到測試用戶的消息中心。競賽任務指后臺將測試資格人員導入，自動認領所有的測試任務。

（3）測試人員完成測試后，將測試發現的軟件用戶體驗缺陷在平臺上進行結果提交（系統設置為單個項目可以多次提交不同用戶體驗缺陷，直至項目測試周期結束）。經后臺對體驗缺陷審核通過后進行缺陷確認及評級并反饋到園區管理方（單個體驗度缺陷的提交不設置時間點，即發現體驗缺陷即可提交），等待園區管理方缺陷等級確認及回復核實消息。如果園區管理方和眾測用戶對缺陷等級的評級出現爭議，雙方均可提交管理后臺進行缺陷等級評定，由后臺針對缺陷評級說明給出評定結果。體驗缺陷的最終評級及積分由測試組織方來確定。

（4）測試周期結束或者園區管理方單方提出測試結束，眾測平臺將匯總本次軟件體驗查驗情況，并生成測試報告發送給園區管理方，測試報告的內容包括用戶體驗的總體情況、系統整體得分和當期測試成本核算結果。

（5）園區管理方根據軟件體驗缺陷報告對軟件進行整改及優化，提升軟件產品的用戶體驗度。

5.2.4.3運營決策管理

1、構建全面、動態的企業數據庫。構建包括企業基本信息、變更記錄、股權出質登記、清算、經營異常、行業分類、動產抵押、抽查、行政處罰、行政許可、企業分支機構信息、股東信息等數據的企業數據庫，為關聯分析決策提供數據支撐。

2、關聯分析輔助決策。在收集園區經營指標數據的基礎上，對企業各類經營數據進行統計分析，為園區管委會的經營決策提供數據支撐。企業運營數據主要包括研發企業投入資金情況、軟件企業業務收入情況、企業分組情況、工業產值情況、各行業月累計經營情況、工業經營情況、固定資產投資情況、進出口總額情況、企業納稅情況、招商引資到位資金、工業總產值、企業能耗情況等數據。為了能夠對園區管委會產業招商的運營提供輔助決策，通常會在企業招商前、企業入駐后、企業續租及后期招商前進行分析，企業在招商前，對園區整體產業發展情況進行分析和評價，以獲得潛在的投資企業和未來產業升級方向，促進當地經濟發展。企業入駐后，通過積累大量的經營數據，對企業進行綜合分析，能夠為園區企業的孵化、招商引資優惠等政策提供更加合理的規劃。通過對園區生產指標、運營指標、環境指標、能源消耗和產出指標的分析，對企業的續租及后期招商起到輔助決策作用。

（1）產業招商前輔助決策。產業招商前，園區管委會需要對產業的科學發展進行合理的規劃，通過主導及特色產業的分析，重點考慮如何在園區中引導各業態企業的聚集，促進產業集群的發展。分析步驟如下：

1）產業定位分析。結合大數據、空間分析等方法，獲取勞動力和人才的分布情況，確定影響產業集聚的因素，預測產業集群的發展方向，根據區域化水平和投入產出分析，確定主導產業，分析招商引資的方向、可引進的互補型和差異型企業的類型以及產業之間的關聯度。

2）構建產業招商方案。根據園區的實際情況、主導產業和園區自身定位，提出了構建不同產業鏈的解決方案，并對未來五年園區的整體績效、工業產值等經濟指標進行了評估。

3）方案比選。綜合各個產業招商方案不同維度的分析結論，選擇產業招商方案。A 智慧園區位于中國某省，近年來，隨著國家在當地進行的大數據產業布局，為園區產業招商提供了重要參考，當地夏季天氣涼爽，平均氣溫為16°C-24°C，特別適合數據中心建設，能夠大大節約數據中心空調的能源消耗，因此優先考慮吸引三大運營商入駐園區，建設數據中心項目。數據中心的建設為大數據產業的招商提供了基礎，可以吸引大數據產業相關業態的企業入駐，大數據產業分為三類業態，分別是：大數據核心業態、大數據關聯業態以及大數據衍生業態。大數據核心業態圍繞數據的采集、匯聚、整理、分析等數據全生命周期管理、大數據關鍵技術及核心業務為主，針對核心業態可以吸引以大數據業務為核心的企業入駐園區。大數據關聯業態指以大數據產業為核心的上下游電子信息產業鏈，對于關聯業態可以吸引包括智能終端、電子元器件、互聯網金融、軟件和服務外包等相關企業入駐園區。大數據衍生業態指大數據在各行業和各領域的應用所產生的業態，是大數據與傳統經濟相互融合的產物，是核心業態和關聯業態的主要服務對象，對于衍生業態可以吸引智慧農業、智慧健康、智慧教育等企業進入園區入駐。通過產業招商前的決策分析，確定A智慧園區產業招商主要集中在三大運營商、大數據各業態相關企業的入駐，以構建大數據產業集群為智慧園區建設的目標。

（2）年度綜合評估

1）企業生產指標分析。對園區內部的企業的生產經營指標進行分析，了解企業的生產經營情況，大數據核心業態、關聯業態及衍生業態的發展情況。

2）園區綜合競爭力評估。從園區產業形成時間、規模結構、產業鏈等指標分析園區企業的關聯度和聚集發展程度，并以園區空間績效和生產指標為基礎，確定了園區企業的綜合競爭力，作為企業的優惠政策或補貼發放的依據。

（3）續租及后期招商決策。經過一段時間的發展，通過對園區企業的監測和年度績效考核，可以對現階段企業的整體經營狀況進行更新和排名。同時，可以確定當前工業園區產業集群階段的集聚程度。對比產業投資前的情景模擬，提出了大數據產業鏈優化方案。

5.3A智慧園區軟件項目建設的質量管理策略的實施成效

5.3.1 A 智慧園區軟件項目建設的質量管理策略的實施成效定性分析

5.3.1.1質量管理體系實施成效

Z公司在軟件研發過程管理方面，雖然先后通過了 CMMI3、CMMI5質量管理體系認證，但在實際的軟件項目管理過程中質量管理效果不顯著，特別針對A智慧園區軟件項目這樣進度要求緊、質量要求高、軟件建設規模大的項目中更是難以發揮作用，主要原因是CMMI體系較龐大，無法直接照搬套用，同時CMMI體系中各過程域需要編寫大量的文檔材料，在研發團隊人力資源有限的情況下，往往影響軟件研發效率。通過構建CMMI與敏捷相互融合的質量管理體系，有效地提升了質量管理的效果。

（1）提高了軟件研發過程的效率。在組織級質量管理中，主要基于CMMI質量管理體系，通過過程管理類活動、量化管理類活動、項目管理類活動、項目支持類活動、過程資產庫等不斷優化和改進過程資產庫；在項目級質量管理中，一方面結合敏捷敏捷開發模型，另一方面基于不斷改進的過程資產庫，有效提升了軟件研發的效率，克服 CMMI體系需求響應慢，研發周期長，以及敏捷開發模型弱化文檔等缺點，通過反復的迭代生成更加接近真實需求的軟件建設成果，軟件項目研發的效率與未實施該策略時相比有較明顯的提升。

（2）質量管理體系更具有可操作性。根據項目的實際情況對CMMI質量管理體系進行裁剪，并與敏捷敏捷開發模型相融合，通過與實際軟件項目建設緊密結合，在項目建設過程中更加容易操作執行，發揮的作用更加顯著。

5.3.1.2需求管理策略實施成效

需求管理是軟件項目的初始環節，也是最重要的環節，本文針對需求管理中評審環節構建了三階段評審策略，重點對需求的可行性、優先級以及變更進行評審，通過該策略的實施有效提高了質量管理的效果。

（1）減少大量無效需求。從技術、業務領域、資源、工期和質量五個方面，結合德爾菲法對需求的可行性進行分析，有效地減少了大量無效的需求，對比策略實施前，總需求數下降約 15%，通過可行性分析的重點管理，一方面確保進入研發需求池的需求一定具有可行性，在項目建設中可以更加集中在需求功能的開發上，另一方面對于不確定是否可行的需求，能夠在需求開發的前期充分解決研發所需條件，避免在后期的研發過程中影響研發進度。

（2）研發計劃的調整更有依據。綜合考慮需求價值、設計工作量、研發工作量、測試工作量等因素，通過量化評分的方式進行需求優先級的評審，評審結果更加客觀，對需求進行準確的優先級排序能夠有效地指導研發計劃的調整和優化，以及資源的合理分配，對確保項目建設的進度和質量起到了關鍵作用。

（3）有效降低了需求變更帶來的影響。需求變更評審是需求三階段評審中最重要的一個評審環節，因為需求的變更往往比新需求的研發更加耗費時間和資源，通過對需求變更的影響進行充分分析，構建需求變更評審流程，讓園區管理方、項目建設方、使用方等多方參與到需求變更評審中來，嚴格管控需求變更。

5.3.1.3系統集成管理策略實施成效

通過構建系統集成管理流程從總體上提升了軟件系統集成質量，為智慧園區的運營提供底層數據支撐。

（1）系統集成的進度得到了保障。在未實施系統集成管理策略前，系統集成的進度往往落后于項目建設的進度要求。通過對系統集成的內容進行充分調研，詳細記錄了各智能化子系統的對接協議、數據類型、對接流程、接口變更情況等，有效保證了系統集成的進度要求。

（2）提高了數據對接的效率。接口初次對接測試在仿真環境中進行，測試通過后，再進入到正式環境中進行對接測試，通過兩階段對接測試，有效地提高了數據對接的效率。

5.3.1.4軟件運營管理策略實施成效

軟件運營管理通過運營服務管理策略、運營體驗管理策略及運營決策管理策略的實施得到了較好的管理效果。

（1）管委會的管理工作更加精細化。通過在管委會產業招商項目工作中引入“金字塔模式”的項目逐級管理策略，將項目按照產業招商的各個階段進行劃分，對于不同階段的項目進行有側重點的管理，產業招商工作更加精細化，有效提升產業招商的效率，以及企業的入駐率，意向項目到遷入項目的轉換率在原基礎上提高了約6個百分點。

（2）優化了園區管委會產業招商部門的組織架構。為了與“金字塔模式”的項目逐級管理策略相適應，園區管委會產業招商部門進行了組織結構優化，將原來統一的產業招商管理部門拆分為意向項目管理部門、洽談項目管理部門、在辦項目管理部門及遷入項目管理部門，在組織結構上為產業招商精細化管理提供了支撐。

（3）企業服務能夠持續跟蹤和優化。企業入駐后，在企業發展的不同階段提供不同的企業服務，通過建立一套“7x24”企業服務跟蹤機制，及時跟蹤企業服務的進展情況，持續提升企業服務的能力，為園區內部企業創造更好的發展環境。通過“人工+信息化”的企業服務跟蹤方式有效提高了園區內部企業服務辦理的效率，企業服務平均完成時間從原來的5-7天縮短為2-3天。

（4）用戶體驗不斷提升。通過眾測模式不斷收集并解決用戶在使用軟件中遇到的與體驗相關的問題，不斷提升用戶體驗度，增加用戶的粘性。眾測平臺上對于新發布的單個測試任務平均每天能夠收到30-50個的用戶體驗問題，其中通過審核需要解決的問題大約有 10個左右，通過這種方式不斷收集用戶體驗問題，提升了用戶滿意度。

（5）管委會決策有據可依。通過對園區內部企業經營情況、園區綜合實力等進行統計分析，分析企業和園區后期的發展方向，為產業招商政策和方案優化提供參考依據。

5.3.2 A智慧園區軟件項目建設的質量管理策略的實施成效定量分析

智慧園區軟件項目建設的質量管理策略在A智慧園區軟件項目實施后，達到了良好的效果，為了對實施成效進行量化評價，根據園區管理方、園區用戶、園區內部企業等進行項目建設滿意度調查的結果，建立了基于層次分析法的智慧園區軟件項目質量管理評價模型。

5.3.2.1 評價指標體系設置原則

對A智慧園區軟件項目建設的質量管理策略實施成效定量分析的關鍵是評價指標的確立，設定的評價指標必須能夠代表項目建設質量的基本情況和主要特征，建立評價指標需要遵循以下原則：

（1）指標具有可采集性，指標數據的收集是可靠方便和科學的。

（2）指標具有代表性，可較全面的反映智慧園區軟件項目建設質量某個方面的總體水平。

（3）指標具有可比性，所收集的指標之間可以對其重要程序進行定性的比較。

（4）客觀原則，評價指標的選取應該盡量降低人為主觀因素對評價指標產生的影響。

5.3.2.2 評價指標的具體內容

A 智慧園區軟件項目建設的質量管理策略實施成效定量分析是一個典型的多目標決策問題，涉及內容多、涉及面廣，對其影響的因素也比較復雜。本文所研究的質量評價指標是基于園區管理方、園區用戶、園區內部企業等對項目的滿意度為關注點，經過項目的實際經驗總結，結合專家建議，篩選并整理出來的，對于A智慧園區軟件項目而言，因此設定了 18 個評價指標，從交付質量和運營質量兩大方向進行考慮，分為需求符合情況（BJ、系統集成質量（B2）、質量管理體系（B3）、項目運營質量（B4）四個維度對 A 智慧園區軟件項目建設的質量管理策略實施成效進行評價， A 智慧園區軟件項目建設的質量管理策略實施成效定量評價指標詳情見表 5-9。

表 5-9 A 智慧園區軟件項目建設的質量管理策略實施成效定量評價指標

項目交付需求符合情況（BQ 功能符合需求的程度（Bn）

操作流程符合需求的程度（B12）

操作界面的友好程度（B13）

交付文檔符合需求的程度（B14）

軟件性能符合需求的程度（B15）

系統集成質量（B2）園區智能化設備運行指標數據的實時性（B21）

園區智能化設備運行指標數據的準確性（B22）

園區智能化設備運行告警數據的準確性（B23）

園區智能化設備綜合控制的有效性（B24）

設備間聯動的有效性（B25）

質量管理體系（B3）質量體系水平（B31）

質量體系實施效果（B32）

質量體系過程文件完整性和有效性（B33）

質量體系的適用程度（B34）

項目運營項目運營質量（B4）通過眾測發現問題的能力（B41）

開發單位解決問題的能力（B42）

信息安全保證能力（B43）

用戶體驗持續提升能力（B44）

（ 1 ）需求符合情況

需求符合情況是項目最終交付給客戶成果物的結果體現，也是軟件項目建設完成結果的最直接的體現，沒有符合需求的軟件成果物，無法得到客戶的認可。需求符合情況包括了功能符合需求的程度（B11），操作流程符合需求的程度（BJ,操作界面的友好

程度（BQ，交付文檔符合需求的程度（B14），軟件性能符合需求的程序（B15）五個指標，如果交付的軟件成果物無法滿足用戶的需求，那么軟件項目建設的質量是不合格的。

（2）系統集成質量

系統集成的管理是A智慧園區軟件項目建設中重要的組成部分，直接決定了項目后期運營和展示的效果，因此系統集成質量的好壞直接關系到該軟件項目建設的質量，系統集成質量包括了園區智能化設備運行指標數據的實時性（B21）,園區智能化設備運行指標數據的準確性（B22），園區智能化設備運行告警數據的準確性（B23），園區智能化設備綜合控制的有效性（B24），設備間聯動的有效性（B25）五個指標。

（3）質量管理體系

質量管理體系是A智慧園區軟件項目順利實現用戶需求的重要保障，也是此項目管理方法區別于其他軟件項目管理方法的重要指標項，質量管理體系包括了質量體系水平（B31），質量體系實施效果（B32），質量體系過程文件完整性和有效性（B33），質量體系的適用程度（B34）四個指標。

（4）項目運營質量項目運營是檢驗軟件項目建設是否成功的最直接指標項，如果交付成果物完全滿足

用戶的需求，但卻無法運營和使用起來，發揮其作用，那么這樣的軟件項目的建設也是不合格的，項目運營質量包括了通過眾測發現問題的能力（B41），開發單位解決問題的能力（B42），信息安全保證能力（B43），用戶體驗持續提升能力（B44）。

5.3.2.3基于層次分析法的質量管理評價模型的構建

通過上一節確定的 A 智慧園區軟件項目建設的質量管理策略實施成效定量評價指標，就可以通過二級指標來創建質量評價模型的因素集，設定一級因素集為B，即｛B1， B2, B3, B4｝，則二級因素集B=｛Bn，B12, B13, B14,…，B43, B44｝，同時將評價的結果分為四個級別。

1 、確定評價指標權重

在決策問題中，通常要把變量 Z 變成變量 x1， x2， …， xn 的線性組合：，其中，，則 w1， w2， … ， wn 叫各元

素對于目標 Z 的權重，叫權向量。

層次分析法從問題分解、判斷和最終綜合三個方面反映了評估分析過程，是一種多屬性決策分析方法。在綜合統計評價中，權重決定了評價指標的重要性，權重指標越大，指標越重要，應用層次分析方法來確定評價指標權重的步驟如下：

(1)建立層次結構模型，通常最高層次為目標層次，即A智慧園區軟件項目建設質量評價，中間層為因素層，最底層是具體的指標層，是對質量管理策略實施成效進行評價的18個具體指標,A智慧園區軟件項目建設的質量管理策略實施成效定量評價指標如圖5-8所示。

圖 5-8 A 智慧園區軟件項目建設的質量管理策略實施成效定量評價指標

(2)通過比較各元素在同一層次上的重要程序，構造了判斷矩陣 B=(bij) ,其中。根據一級因素中各指標的相對重要性，構建一級因素判斷矩陣，指標相對重要性量化表見表 5-10。

表 5-10 指標相對重要性量化表

因素i比因素j 量化值

同等重要 1

稍微重要 3

較強重要 5

強烈重要 7

極端重要 9

兩相鄰判斷的中間值 2, 4, 6, 8

根據重要性等級及其賦值，構建一級因素判斷矩陣，如表5-11 所示：

表 5-11 一級因素判斷矩陣表

B1 1 1 1

B2 1

B3 1

B4 1

對每一列向量進行歸一化，得到向量歸一化矩陣：

0.25 0.13 0.30 0.30

0.25 0.13 0.10 0.10

0.25 0.38 0.30 0.30

然后對按行求和，得：

0.98'

0.57

1.23

.1.23.

將歸一化，，即為近似特征根（權向量）

ro.241

0.14

0.31

0,31.

1.28

1(丄+058+旦+竺卜413

4 0 24 0 14 0 31 0 31

在判斷矩陣中，bij的確定是建立在參與分析的專家經驗和資料信息的基礎之上的, 可能會有主觀判斷因素的存在，因此，應用層次分析法時需要檢驗結果的一致性，即確定 B 的允許不一致范圍。

久一H

一致性指標CI = —一，值越小說明矩陣的一致性越高，當CI=0說明具有完 n — 1

全的一致性，對于一級因素判斷矩陣計算CI =久 …廠=牛 « 0?04。

n — 1 3

考慮到隨機因素導致的矩陣一致性偏離的情況，通過計算檢驗系數CR進行一致性

校驗，CR = ¥，RI表示隨機一致性指標，隨機一致性指標如表5-12所示。 RI

表 5-12 隨機一致性指標

由于一級因素判斷矩陣為4階矩陣，因此通過計算可以得出CR =

004

0.9

0 044

0 1，因此確定該判斷矩陣具有一致性。

完成了對A智慧園區軟件項目建設的質量評價體系一級因素集各指標權重的計算，再采用同樣的方法對該項目質量評價體系中的二級因素集各指標的權重計算如下：

(1)需求符合情況

對需求符合情況B1的二級因素集｛B11,B12,B13,B14,B15｝建立判斷矩陣，需求符合情況二級因素判斷矩陣如表5-13所示。

表 5-13 需求符合情況二級因素判斷矩陣表

B11 B12 B13 B14 B15

B11 1 1 3 3 3

B12 1 1 1 1 1

B13 0.33 1 1 1 1

B14 0.33 1 1 1 1

B15 0.33 1 1 1 1

對需求符合情況二級因素判斷矩陣進行計算得到權重為：

w=(0.3 6,0.1 9, 0. 1 5,0.1 5, 0. 1 5 ) J 最大特征根為：= 5.17 , 一致性指標 "I Cv 尤

CI=0.04, CR = 咅 0.036 < 0.1,可判斷此矩陣具有一致性特征。

R / 1.12

(2)系統集成質量

對系統集成質量B2的二級因素集｛B21,B22,B23,B24,B25｝建立判斷矩陣，系統集成質量二級因素判斷矩陣如表5-14所示。

表 5-14 系統集成質量二級因素判斷矩陣表

B21 B22 B23 B24 B25

B21 1 1 1 1 1

B22 1 1 1 1 1

B23 1 1 1 1 1

B24 1 1 1 1 1

B25 1 1 1 1 1

對系統集成質量二級因素判斷矩陣進行計算得到權重為：，

最大特征根為：x = 5, 一致性指標CI=0, CR = 0 < 0 .1,可判斷此矩陣具有一致性特征。

（3）質量管理體系

對質量管理體系B3的二級因素集｛B31,B32,B33,B34｝建立判斷矩陣，質量管理體系二級因素判斷矩陣如表5-15 所示。

表 5-15 質量管理體系二級因素判斷矩陣表

B31 B32 B33 B34

B31 1 0.33 0.33 0.33

B32 3 1 3 1

B33 3 0.33 1 1

B34 3 1 1 1

對質量管理體系二級因素判斷矩陣進行計算得到權重為：

最大特征根為：ma x = 4 .18, 一致性指標 CI=0.06, CR =冷=006« 0.067 < 0.1, 可判斷此矩陣具有一致性特征。

（4）項目運營質量

對項目運營質量B4的二級因素集｛B41,B42,B43,B44｝建立判斷矩陣，項目運營質量二級因素判斷矩陣如表5-16 所示。

表 5-16 項目運營質量二級因素判斷矩陣表

B41 B42 B43 B44

B41 1 1 1 0.33

B42 1 1 1 0.33

B43 1 1 1 0.33

B44 3 3 3 1

對項目運營質量二級因素判斷矩陣進行計算得到權重為：

最大特征根為：ma x = 4.06, 一致性指標 CI=0.02, CR =冷0.022 < 0.1, 可判斷該矩陣具有一致性特征。

經過一致性判斷發現所有指標計算的權重均符合一致性原則，由上述計算結果可以得到一、二級因素各個指標的權重，質量管理策略實施成效定量評價指標權重分布表如表 5-17 所示。

表 5-17 質量管理策略實施成效定量評價指標權重分布表

B1 w=0.24 B2 w=0.14 B3 w=0.31 B4 w=0.31

B11 0.36 B21 0.2 B31 0.1 B41 0.17

B12 0.19 B22 0.2 B32 0.38 B42 0.17

B13 0.15 B23 0.2 B33 0.23 B43 0.17

B14 0.15 B24 0.2 B34 0.29 B44 0.5

B15 0.15 B25 0.2

2、構建評估模型

根據上述由層次分析法得到的各指標，結合對A智慧園區軟件項目建設的質量管理策略實施成效的問卷調查結果，構建指標的評價矩陣，其中評價等級的設定為V={非常滿意，滿意，一般，不滿意，非常不滿意} = {V1，V2，V3, V4, V5},根據問卷調查結果中每個二級指標的評價等級的占比確定B1，B2, B3, B4的模糊評價矩陣Z1，Z2, Z3, Z4。綜合子因素層的各評價矩陣Zk的結果，可以得到因素層各指標Bk對于評語集V的隸屬度向量 Yk=WkZk。

1）需求符合情況 B1 的評價矩陣為：

rO.6 0.3 0.1 0 01

0.6 0.3 0.10 0

Z、= 0.7 0.2 0.10 0

0.5 0.3 0.2 0 0

L0.7 0.2 0.10 0J

可以得出需求符合情況的隸屬度向量Y1：

0.6 0.3 0.1 0 0

0.7 0.2 0.1 0 0

0.5 0.3 0.2 0 0

L0.7 0.2 0.1 0 0」

(2)系統集成質量B2的評價矩陣為：

rO.6 0.2 0.2 0 01

0.5 0.4 0.10 0

Z2 = 0.6 0.3 0.10 0

0.7 0.2 0.10 0

Lo.7 0.2 0.1 OOJ

可以得出系統集成質量的隸屬度向量：

0.6 0.2 0.2 0 0

0.5 0.4 0.10 0

Y2 = W2Z2 = (0.2,0.2,0.2,0.2) 0.6 0.3 0.10 0 = (0.62,0.26,0.12,0,0)

0.7 0.2 0.10 0

L0.7 0.2 0.1 OOJ

（3）質量管理體系B3的評價矩陣為:

0.5 0.3 0.2 0 O'

7 = 0.6 0.3 0.10 0

3 _ 0.7 0.2 0.10 0 .0,8 0,10.10 0.

可以得出系統集成質量的隸屬度向量：

Y3 = W3Z3 = (0.1,0.38,0.23,0.29)

0.5 0.3 0.2 0 0

0.6 0.3 0.10 0

0.7 0.2 0.10 0

_0.8 0.10.10 0

(4)項目運營質量B4的評價矩陣為:

Z4 =

=(0.671,0.219,0.11,0,0)

0.7 0.2 0.10 0

0.5 0.3 0.10.10

0.7 0.2 0.10 0

0.6 0.3 0.10 0

可以得出項目運營質量的隸屬度向量：

'0.7 0.2 0.1 0 0 '

Y4 = W4Z4 = (0.17,0.17,0.17,0.5) =(°?773,0.269,0.101,0.017,0)

.0.6 0.3 0.1 0 0 .

通過前面隸屬度向量的計算結果，可以得到 A 智慧園區軟件項目建設質量的評價矩

陣，見式。

■ 0.615 0.27 0.115 0 0 '

0.62 0.26 0.12 0 0

0.671 0.219 0.11 0 0

.0.773 0.269 0.1010.017 0.

3、評價與分析

通過得出的評價矩陣，可以看出需求符合情況對應的非常滿意的隸屬度最高，為

0.615，系統集成質量對應非常滿意的隸屬度最高，為0.62，質量管理體系對應非常滿意

的隸屬度最高，為0.671，項目運營質量對應非常滿意的隸屬度最高，為0.773，由此可

以看出A智慧園區軟件項目在實施了質量管理策略后，整體評價對應非常滿意的隸屬度

為最高。

對目標層指標B對應評價集V的綜合評定向量Y進行計算，得出:

Y = WZ = (0.24,0.14,0.31,0.31)

0.615 0.27 0.115 0 0 '

0.62 0.26 0.12 0 0 =

0.671 0.219 0.11 0 0 _

0.773 0.269 0.1010.017 0.

(0.682,0.252,0.11,0.005,0)

按照百分制標準設定評定項目的對應評價結果等級V={非常滿意，滿意，一般，不

滿意，非常不滿意},可以得到評價結果向量V={100, 80, 60, 30, 0},計算A智慧園

區軟件項目質量的綜合得分為：

通過計算得到 95.11 的評價分數，可以看出 A 智慧園區軟件項目建設質量的綜合評價為非常滿意，說明項目所采取的質量管理策略達到了較好的效果。

5.4 本章小結

本章在第四章智慧園區軟件項目建設的質量管理策略設計的基礎上，首先介紹了 A 智慧園區軟件項目建設質量管理實例。接著以A智慧園區軟件項目為例，詳細闡述了質量管理策略實施的過程，對于質量管理體系的實施，從組織級質量管理和項目級質量管理描述了質量管理策略的實施過程。針對需求管理，從需求獲取、需求分析、需求可行性評審、需求優先級評審、需求變更評審、需求跟蹤、需求交付等環節詳細闡述了需求管理的實施過程。針對系統集成管理，從系統集成需求調研、集成數據分類、系統對接流程規劃、接口開發管理等環節詳細闡述了系統集成管理的實施過程。針對軟件運營管理，從運營服務管理、運營體驗管理和運營決策管理三個方面介紹了質量管理策略的實施過程。最后對A智慧園區軟件項目建設質量管理策略的實施成效進行定性和定量分析

第六章總結與展望

6.1 全文總結

本文針對智慧園區軟件項目質量管理的現狀及存在的問題，分別從質量管理體系、需求管理、系統集成、軟件運營四個方面提出了質量管理策略，并以A智慧園區軟件項目建設質量管理為例，詳細描述了質量管理策略的實施過程和應用成效。基于第一章提出的幾個擬解決的主要問題，本文的主要研究內容與結論包括以下方面：

（1）通過問卷調查、頭腦風暴和文章檢索，對智慧園區軟件項目建設的質量管理現狀進行分析，使用根因分析法對存在的問題進行分析，找出了影響智慧園區軟件項目建設質量管理的主要因素包括質量管理體系、需求管理、系統集成、軟件運營。針對質量管理體系，單一的軟件工程質量管理體系無法適用智慧園區軟件項目的質量管理。針對需求管理，往往忽視需求開發前期環節的質量管理工作，比如需求可行性、優先級及變更的評審，導致在需求開發階段存在需求管理失控的風險。針對系統集成管理，將管理的重心放在了系統對接、對接測試等技術環節，忽略了前期系統集成需求調研、數據分類等非技術環節的管理，導致系統集成的總體進度和質量難以管理。針對軟件運營，運營過程中存在的問題難以被發現，缺少持續提升軟件運營能力的手段。

（2）針對智慧園區軟件項目建設質量管理存在的問題，分別從質量管理體系、需求管理、系統集成、軟件運營四個方面對質量管理策略進行設計。對于質量管理體系，分別構建了基于CMMI和敏捷開發模型的質量管理體系，提出了一種CMMI和敏捷開發模型相融合的質量管理體系，既克服了 CMMI質量管理體系需求響應慢、軟件版本發布不及時等問題，也克服了敏捷開發模型質量管理體系中忽略文檔的缺點。對于需求管理，提出了包括需求可行性、需求優先級和需求變更的三階段需求評審策略，通過三階段評審減少了大量的無效需求，提高了需求開發的效率。對于系統集成，構建了一整套系統集成質量管理的標準流程，從系統集成需求調研、集成數據分類、對接流程規劃、接口開發管理四個方面設計了系統集成質量管理策略，使項目建設過程中系統集成工作的開展更加高效有序，克服了系統集成進度總是落后于項目建設總體進度的問題。對于軟件運營，提出了運營服務提升、運營體驗提升、運營決策提升的管理策略，全面提高園區的運營服務能力，園區用戶的體驗及園區管委會的決策能力。

（3）以A智慧園區軟件項目質量管理為例，詳細描述了質量管理策略的實施過程。針對質量管理體系，從組織級質量管理活動和項目級質量管理活動闡述了 CMMI 和敏捷開發模型相融合的質量管理體系的實施過程。針對需求管理，從需求獲取、需求分析、需求可行性評審、需求優先級評審、需求變更評審、需求跟蹤和需求交付等方面闡述了需求管理策略的實施過程。針對系統集成管理，從系統集成需求調研、集成數據分類、系統對接流程規劃和接口開發管理四個方面描述了系統集成質量管理策略的實施過程。針對軟件運營管理，從運營服務管理、運營體驗管理和運營決策管理三個方面描述了軟件運營質量管理策略的實施過程。

(4)對 A 智慧園區軟件項目質量管理策略實施后的成效進行定性和定量的分析評價。從質量管理體系、需求管理、系統集成管理和軟件運營管理四個方面對質量管理策略實施成效進行定性分析。通過構建基于層次分析法的質量管理策略實施成效定量評價指標和評價模型，對質量管理策略的實施成效進行定量分析。

6.2 研究展望

針對本文研究中存在的不足和值得進一步研究探討的地方，做出如下展望：

(1)本文設計的智慧園區軟件項目質量管理策略應用在A智慧園區軟件項目建設質量管理上收到了較好的成效，然而A智慧園區是典型的工業型園區，其建設的側重點主要在如何能夠通過產業招商讓更多的企業入駐，聚集構建產業集群，使園區內各企業構成完整的工業生產產業鏈，在園區內部實現工業生產的循環體系等，本文設計的智慧園區軟件項目質量管理策略應用在其他類型智慧園區軟件項目建設中不一定得到較好的成效，本文的研究內容有一定的局限性，為了能夠將園區建設的經驗在各類型園區的建設中進行推廣，可以結合大數據技術，通過大數據技術對各類型園區的運營及建設情況進行分析，研究更具有普適性的智慧園區軟件項目建設的質量管理策略，而不僅僅局限于工業型園區。

(2)本文提出的 CMMI 和敏捷開發模型相融合的質量管理體系，其中組織級的管理基本上沿用了 CMMI組織級管理活動的內容，項目級的管理采用了敏捷開發模型，組織級活動和項目級活動能夠相互促進，持續改進軟件項目建設的過程管理。在實際的軟件項目建設的應用上，應該根據項目建設的需要對組織級和項目級管理活動進行裁剪，未來可以針對裁剪的內容進行深入研究，針對不同的軟件項目構建更加精細的質量管理體系，進一步提升軟件項目的質量管理效率。

(3)本文對A智慧園區軟件項目質量管理策略實施后的成效進行定量分析中，構建了基于層次分析法的定量評價指標、評價模型，及評價指標和分析目標的關系矩陣，但由于構建的評價指標有限且調查問卷的樣本數據不夠多，導致了定量分析結果的準確性有待進一步驗證，在未來的研究中可以增加評價指標項，加大問卷數據樣本容量，進一步提高質量管理策略定量分析的準確性。

致謝

經過三年的學習和一年的論文準備，期間還遇到 2020 年至今的疫情等特殊情況，終于完成本文的研究工作。感謝東南大學經濟與管理學院的各位老師給予知識的教授，感謝 2018（6）班同學們的支持和幫助，這三年的學習和經歷將豐富我的個人成長，讓我獲益匪淺。

本文是在莊亞明教授的精心指導下完成的。在我進行本論文的研究期間，莊亞明教授學識淵博，治學嚴謹。他善于把握問題的本質和關鍵，雖然受限于疫情原因，仍從開題論證、編寫、完善，直至論文完成的每一環節給予了我很大的幫助，每一個環節都傾注了莊亞明教授大量的心血和經歷，在此謹向莊亞明教授表示深深的敬意，并對他為學生所付出的大量心血表示由衷的感謝。

同時，我還要感謝孔慶善、黃超、葛滬飛等任課教師，對于我提出的專業課內的疑問，都耐心、認真地為我解答，對于我論文的完成給予了莫大的幫助和鼓勵。

還有MBA的同學們，以及公司的同事們在研究中都給予我的熱情幫助。

再次對關心、幫助、支持和鼓勵我的所有老師、同學、同事表示最誠摯的謝意。

參考文獻

[1]李玉琳，張婧，高琨，孫九成，李浩.基于數字孿生的智慧園區物業管理基礎服務研究J].智

能建筑與智慧城市,2021(03):9-12.

[2]李青山，王洪鋒,梁向鋒，司博章,孫希法，黃飛.基于IBA融合的智慧園區AI應用思考J].

科技創新與應用,2021(11):185-187.

⑶尚寶麒基于物聯網技術的企業智慧園區建設J].中國管理信息化,2021,24(05):97-98.

[4]徐明曉.關于產業園區的發展模式及趨勢簡單分析[J].特區經濟,2020(09):116-119. ⑸孟月.華為邱真：5G+“新基建”打造智慧園區新“生態” J].通信世界,2020(20):26-27.

[6]金程，沙默泉,郭中梅,單斐.基于CIM的智慧園區建設探析J].信息通信技術與政策,2020(11):34-38.

⑺何雙鈴,侯林，陳波，石磊.綠色智慧化工園區架構設計與建設初探[J].廣東化工,2020,47(21):244-245.

[8]趙耀，朱建軍,龍笑宇.ISO 9001與CMMI/CMM在組織執行中的差異淺析J].核標準計

量與質量,2020(04):2-6.

[9]黃敏珍.CMMI、敏捷開發和DevOps在項目管理實踐中的應用[J].項目管理技

術,2020,18(09):91-95.

[10]蔡泉論敏捷與CMMI的異同及敏捷中融合CMMI思想以提高敏捷性能的思路[J].科學技術創新,2020(19):27-28.

[11]張碩.探析基于CMMI的軟件質量管理與控制[J].農家參謀,2020(11):155.

[12]俞蔚.基于CMMI的企業軟件項目質量管理研究[J].中國新通信,2019,21(21):158.

[13]嚴艦.CMMI在汽車軟件開發中的應用[J].電腦編程技巧與維護,2019(08):50-52.

[14]張璇.CMMI在網絡學習空間軟件項目中的應用研究[J].中國電化教育,2017(10):84-88.

[15]付東普.基于約束理論的軟件項目開發過程模型構建[J].科技管理研究,2014,34(12):185-188.

[16 ]王倩，唐蘭文,吳海燕.基于敏捷的敏捷測試研究與應用J].科技視界,2020(33):87-8 8.

[17]徐燎宇，賈楊，陳陵，康乾.基于德爾菲法的基層中醫藥服務評價體系研究J].湖南中醫藥大學學報,2021,41(03):485-489.

[18]劉姣姣，毛子駿,徐曉林.基于根因分析法的大數據企業個人信息泄露案例研究J].中國科技論壇,2020(11):110-119.

[19 ]李蒙蒙，秦偉，劉藝，刁興春.結合頭腦風暴優化的混合蟻群優化算法[J/OL].計算機應用:1-7[2021-04-01].

[20]賈先國，何海濤,劉大鵬.基于親和圖和系統圖的建筑施工安全事故分析[J].山西建筑,2010,36(20):193-195.

[21]徐曉軍，扶俊，陳琳.基于魚骨圖的取水實時監控系統的改善分析一一以桐廬縣為例J]. 浙江水利科技,2016,44(03):84-87.

[22]馬金榮，郭毅軒.帕累托圖在三調質量管理中的應用[J]城市勘測,2019(05):149-152.

[23]袁世明，溫忠軍.基于層次分析法和模糊綜合評價的BIM三維協同設計模式分析J].工程經濟,2020,30(07):44-48.

[24]董海峽.A公司軟件項目質量管理體系建設與評價研究[D].吉林大學,2017.

[25]武智.HTGR公司信息化平臺開發項目質量控制研究[D].哈爾濱理工大學,2017.

[26]朱岸舜.H公司軟件項目質量管理研究[D].北京郵電大學,2019.

[27]段鍇.J醫療器械企業的質量管理策略研究[D].蘇州大學,2020.

[28]褚婷.N公司軟件外包項目質量管理體系建設及成效評價研究[D].華北電力大學(北京),2019.

[29]張仕學，丁曉明.基于粗糙集理論的軟件項目質量管理研究J].西南大學學報(自然科學版),2011,33(03):118-121.

[30]李志偉.軍用軟件開發工程化質量管理研究[J].制造業自動化,2011,33(05):17-20.

[31]趙小松，張婷，張哂卿，張哲.平衡計分卡在軟件企業績效管理中的應用J].天津大學學報(社會科學版),2008(01):39-42.

[32]武占春,王青,李明樹.一種基于PDCA的軟件過程控制與改進模型[J].軟件學報,2006(08):1669-1680.

[33]樊孝云.基于CMMI的M軟件企業項目管理實施方案研究[D].南昌大學,2018.

[34]劉原序.面向CMMI模型的軟件項目開發質量管理方法研究[D].戰略支援部隊信息工程大學,2018.

[35]郭維維.ADCR軟件產品開發過程中的質量控制策略研究[D].東南大學,2018.

[36]馬營.移動終端產品軟件測試質量控制效果評價及策略研究[D].華北電力大學(北京),2018.

[37]張瑩.信用信息系統中的軟件質量控制[D].東南大學,2015.

[38]B. Jiang,Y.D. Huang,S. He,L.X. Xing,H.L. Wang. Quality analysis and control strategies for epoxy resin and prepreg[J]. Trends in Analytical Chemistry,2015,74.

[39]Silva, Pedro,Moreno, Ana M,Peters, Lawrence. Software Project Management: Learning from Our Mistakes [Voice of Evidence][J]. IEEE Software,2015,32(3).

[40]Qitao Zhang,Li Chen. Implementation Processes Based on CMMI Software

Configuration Management[J]. Energy Procedia,2011,13.

[41]Alireza Shokri,Farhad Nabhani. Quality management vision of future early career operations managers[J]. The International Journal of Quality & Reliability Management,2019,36(2).

[42]Christine Bundell,Elina Tan,Anna Brusch,Louise Wienholt. Quality assurance and quality control highlight the variability between and within assay methods[J]. Pathology,2019,51.

[43]Pedro Serrador,Jeffrey K. Pinto. Does Agile work? — A quantitative analysis of agile

project success[J]. International Journal of Project Management,2015,33(5).

[44]Greg Indelicato. A guide to the project management body of knowledge

(PMBOK® guide), fourth edition[J]. Project Management Journal,2009,40(2).

[45]申梅杰，李慧，汪金滿,劉海靖.一種ISO 9000與CMMI的體系融合方法研究[J].石油工業技術監督,2017,33(11):70-74.

[46]宋生宇.一種基于軟件行為分類的動態完整性度量模型 [J]. 通信技術,2017,50(09):2055-2059.

[47]王定濤，賀濤，祝國錦.基于需求管理工具的軟件文檔追溯管理[J].科技風,2017(08):276-277.

[48]楊陽,汪海濤，姜瑛，陳星.基于模糊層次分析法的軟件質量評價模型的研究J].計算機與數字工程,2017,45(04):620-623+691.

[49]俞蔚.軟件項目管理中的風險識別與管理分析[J].中國新通信,2019,21(14):172.

[50]陳陽，王嘉霖.基于CMMI的軟件測試過程度量研究[J].電子技術與軟件工程,2015(24):70.

[51]夏岡IJ,樓文高，婁元英.軟件質量綜合評價的投影尋蹤模型[J].信息技術,2014(03):72-75+84.

[52]李芳頌，王鋒，高曉峰,盛鵬.軟件質量度量過程及模型研究[J].中國新通信,2016,18(09):151.