閱讀屋>圖書情報與檔案管理> 軟體工程專案管理需求分析

軟體工程專案管理需求分析

軟體工程專案管理需求分析

  導語:軟體是一系列按照特定順序組織的計算機資料和指令的集合。以下是小編為你介紹的軟體工程專案管理需求分析,歡迎參考。

  軟體工程專案管理需求分析

  摘要:科研機構、高校承擔的大型科研工程越來越多,軟體在工程專案中扮演著重要角色。結合科研領域軟體開發特點,介紹軟體開發流程管理及質量保障措施等,可為科研軟體的質量提高及創新提供一定借鑑。

  關鍵詞:科研軟體;需求分析;開發模型;質量保障

  引言

  1.隨著科研機構、高校承擔的國家大型科學工程專案越來越多,在這些大型科學工程中,軟體起到不可或缺的作用。如中國科學院高能物理研究所承擔的硬X射線調製望遠鏡專案[1]、BESIII專案[2]中的資料採集軟體、探測器和資料監測軟體是獲得物理成果的基礎,而模擬軟體和分析軟體則直接關係到物理成果的處理和精度。這類軟體專案有較深的物理學背景,需要使用一些物理分析和設計方法,實現手段必須符合領域特點。

  2.例如,資料儲存在粒子物理實驗和空間天體物理實驗中的要求不同,前者主要採用ROOT[3]格式,而後者則以FITS[4]格式為主,開發所用的常見庫和工具也因資料存取格式不同而不同。此外,該類軟體應用面較窄,僅限於某一科研領域,其開發很難由軟體公司承擔,因為軟體公司必須投入大量的學習成本,而產品應用又受侷限。因此,這類軟體的開發一般由科研院所、高校自行承擔。

  3.然而,目前我國軟體整體實力與創新性還不強,人才結構也需要改善[5],一些從事基礎研究的機構,軟體人才緊缺,且缺乏軟體開發管理經驗,造成軟體質量不高。科研機構從事軟體開發的科研人員學習能力強,熱衷於追求新技術,如果在方法上給予指導,可幫助其開發出高質量的軟體。依託大型工程培養所需的軟體人才,不僅有利於大型工程專案的實施,而且還能為國家培養大批軟體人才。本文結合該類軟體專案的特點和科研機構現狀,探討其軟體開發特點,並提出流程管理和質量保障措施。

  一、科研領域軟體開發及其特點

  1.1軟體專案特點

  (1)軟體提出者。一般是專案科學家、顧問,他們具有較強的科學洞察力,也能較好地把握軟體開發方向,但他們大多隻關注宏觀問題,而非技術細節,對軟體不是很瞭解,不能用計算機語言和思維描述專案,也無法很好地理解和描述實現流程、細節,因此不能準確估計軟體開發難度和工作量。

  (2)軟體開發者。一般為青年職工和學生,他們熟悉軟體開發,但往往不能完全理解專案目標,也不能深刻理解其物理過程,理解過程中往往思維侷限性大,缺乏方向。

  (3)軟體測試者。多數情況下單元測試由開發者承擔,整合或系統測試由其他人員完成,部分由使用者完成。與開發人員相比,測試人員往往物理基礎較好,掌握基本測試方法,但是沒有建立起完整的測試體系,而且將軟體測試當作“副業”,測試以功能實現為主,對軟體細節不瞭解。

  (4)使用者。使用者一般是物理工作者,他們熟悉研究領域的物理要求,但不能用計算機語言描述需求,往往需求不實際或不夠明確。他們對軟體要求較高,要求透過物理測試對軟體效能和輸出結果精度進行測試。如透過執行大資料量檢查軟體記憶體和時間消耗,以促進開發者進行演算法最佳化等。

  1.2軟體專案開發特點

  (1)軟體需求不夠明確。科研領域軟體專案一般都涉及到探測器和資料,涉及領域較廣,而且需求不斷變化。無論是軟體提出者還是使用者,往往難以用計算機思維或語言清楚描述問題;軟體開發者對專案物理目標,特別是物理過程缺乏深刻理解,不能很好地理解軟體功能細節及需求。比如,對於一些資料分析軟體,提出者或使用者難以描述出軟體需要完成的功能,而開發者對資料處理流程中進行的資料轉換、修正、資料結構重組也缺乏深刻理解。

  (2)人員結構較為單一。軟體開發中通常一人需要承擔多種角色,包括軟體需求分析員、設計者和開發者,甚至測試者。這樣的職位設定,人員分工不明確,難以深入把握某一領域(比如測試)的特點和方法,從而影響了整個軟體開發過程。

  (3)軟體實現細節難以把握。此類軟體一般涉及複雜的物理過程,需要用一定的物理方法解決,但方法並不唯一,不同方法會對結果帶來一定影響,而且不同型別資料所依賴的方法也不同。軟體開發中還有些研究性課題,只能以介面形式存在於軟體中,但預留介面時往往設計較為簡單,考慮的情況過於理想,難以滿足實際需求。然而,如果設計時考慮得比較複雜,介面較多,又往往缺乏必要的軟體技術和經驗,不能有效把握細節。

  (4)硬體頻繁改動增加軟體開發風險。軟體依賴於硬體,設計初期軟體是在理想的.硬體設計狀態下執行,但如果硬體發生變更或者執行影響因素增加,軟體也隨之變動,從而加大開發風險。

  (5)軟體測試及評估缺乏專業水平。由於開發者、測試者與使用者的專業測試能力都比較欠缺,難以涉及到核心質量問題,往往無法全面對軟體作出專業評估。

  (6)人員管理難度大。科研機構、高校一般熱衷於科學研究而不是工程專案本身,因此難以兼顧兩方面工作。軟體提出者和管理人員往往對軟體工程缺乏深入瞭解,難以對開發工作作出客觀評價,因此對軟體開發的進度和質量帶來一定影響。

  (7)軟體不確定性因素多。隨著工程實施,軟體提出者、使用者會不斷改變、增加需求,加上開發者及測試者缺乏相關經驗,程式碼開發不規範、開發人員流動性強等增加了軟體開發的不穩定性。另外,為降低開發成本和難度,開發人員通常會引入現成的工具,這可能給軟體開發帶來隱患。然而,面向某一科研領域的軟體開發專案也有自身的優勢。如和大型專業軟體相比,所需的專案功能不是特別多,部分開發平臺具有可移植性,開發人員綜合素質較高,學習能力強,英語基礎較好。此外,很多工程與國外合作開發,可參考國外成熟軟體,並方便引進一些免費的軟體框架和平臺,如Gaudi[6]框架、天文分析工具庫Ftool[7]等。

  二、軟體開發流程管理

  2.1確定軟體開發模型

  科研機構,尤其是一些缺少經驗的團隊,習慣採用瀑布模型進行開發,主要由於該模型分階段,且各階段間存在因果關係,比較符合思維模式。但它會產生大量文件,到開發後期會凸顯軟體開發缺陷。適合科研領域的開發模型有迭代式模型[8-9](需求變更驅動型)、增量模型(功能驅動型)及快速原型開發[10]等。對於科研軟體而言,模型選擇需綜合考慮軟體框架穩定性和開放性、構件獨立性以及專案組開發經驗等。比如對於需求不明確、流程不清晰、演算法不確定的專案(如資料處理軟體、分析軟體和標定軟體等)採用迭代模型或者快速原型開發較好。此外,採用一種模型為主,其它模型為輔,也會得到很好的效果。

  2.2加強開發流程控制

  無論採用何種開發模型,開發人員必須在每一次開發或迭代中完整實現需求分析、設計、編碼和測試等步驟。各階段的評審或專案報告尤為重要,專案前期要確保軟體開發人員準確理解專案需求以及軟硬體環境;中期階段要確保開發流程和方法可靠;後期要透過測試確保軟體執行符合要求。

  2.3需求分析中注重物理分析

  科研軟體中一般涉及大量資料操作,而且過程比較複雜,一些原始資料要經過轉換、重建、標定及修正等步驟,而且處理不一定是線性的,即相鄰資料之間可能有關聯。這些功能和效能需求不容易明確,需要著重把握。軟體中還可能涉及一些物理演算法(比如影象修正、頻率分解等),因此在需求分析中需要著重進行物理分析,包括流程梳理、特殊方法和條件選擇等。

  2.4採用序列開發方式

  科研機構人員結構比較單一,往往多項工作並行執行,給軟體開發質量提升及人才培養帶來不利影響,可將相關性比較強的軟體以序列方式開發,資料產品生成軟體和資料分析軟體可以依次開發。

  2.5提高開發人員的主觀能動性

  軟體開發過程中,保障軟體專案負責人在經費使用及績效考核中的話語權,組建凝聚力強的研發團隊,對軟體開發的進度、質量進行考核。

  三、軟體質量保障措施

  (1)加強開發過程中的溝通。科研專案的不確定性帶來軟體開發需求的變動,使用者往往只注重專案需求功能滿足,而不關心軟體的實現細節,所提出的功能或介面可能不切實際,因此需要加強與使用者的溝通,明確軟體開發目標。

  (2)充分調動開發人員積極性。科研機構軟體開發人員往往是科研專案的幕後工作者,其工作成果容易被科研專案成果所掩蓋,所以充分調動軟體開發人員的工作積極性尤為必要。一方面,為其提供成果展示平臺,尤其是展示創新性成果,如將開發中的文件整理成冊等;另一方面,在基金申請、職稱評定等方面提供支援。科研機構職稱評定主要依據取得的科研成果,由於工作內容不同,如採取同樣的評審條件,軟體開發人員與其他研究人員在同一層次上競爭將缺乏競爭力。可能導致部分人員不願意從事軟體開發工作,或者開發軟體的同時還從事其它研究,從而影響軟體開發進度和質量。因此,需要根據軟體開發人員工作的特殊性,透過有效的激勵措施調動其積極性。

  (3)培養既懂管理又懂技術的專案負責人。優秀的軟體工程專案負責人不僅是一個好的軟體設計師,對軟體實現細節能夠很好的掌控,還是一名優秀的管理者,能科學配置資源。

  四、結語

  面向科研領域的軟體具有較深的行業背景,其設計方法、實現手段有很強的領域依賴性。本文從科研領域特點及軟體提出者、開發者、測試者、使用者的角度出發,探討了其需求難以明確、人員結構較單一且管理難度大的特點。在軟體開發管理過程中,需要採用合適的軟體開發模型,注重流程管理,充分調動開發人員的工作積極性。

  參考文獻:

  [1]LITIPEI,WUMEI.ThehardX-raymodulationtelescopemission[J].Physics,2008,37(9):648-651.

  [2]LITIPEI.HXMT:achinesehigh-energyastrophysicsmission[J].NuclearPhysicsB,2007(166):131-139.

  [3]BESCOLLABORATION.PreliminarydesignreportoftheBESIIIDetector[Z].2003.

  [4]TheROOTTeam.ROOTuser'sguide[EB/OL].https://root.cern.ch/drupal/content/users-guide.

  [5]WELLSDC,GREISENEW,HARTENRH.FITS:aflexibleim-agetransportsystem[J].A&AS,1981,(44):363-370.

  [6]APrimerontheFITSDataFormat[EB/OL].http://fits.gsfc.nasa.gov/fits_primer.html.

  [7]劉麗梅.中國軟體產業市場競爭力分析[M].北京:對外經濟貿易大學,2007.

  [8]BARRANDG.Gaudi-asoftwareconfigurationmanagementtool[C].ProceedingofCHEP2000,2000.

  [9]FTOOLS.Ageneralpackageofsoftwaretomanipulatefitsfiles[EB/OL].http://heasarc.gsfc.nasa.gov/docs/software/ftools/ftools_menu.html.

  [10]張海籓.軟體工程導論[M].北京:清華大學出版社,2005.

  [11]師迎海,何雪慧.迭代式軟體開發模型研究及應用[J].微處理機,2015(1):55-57.

  [12]劉玉仁,董震曜.快速原型法在軟體設計中的應用[J].光電對抗與無線干擾,2002(4):6-9.

【軟體工程專案管理需求分析】相關文章: