導語：在信息系統(tǒng)質(zhì)量管理論文的撰寫旅程中，學習并吸收他人佳作的精髓是一條寶貴的路徑，好期刊匯集了九篇優(yōu)秀范文，愿這些內(nèi)容能夠啟發(fā)您的創(chuàng)作靈感，引領您探索更多的創(chuàng)作可能。

第1篇

關鍵詞:軟件需求;領域分析;質(zhì)量屬性

中圖分類號:TP311文獻標識碼:A文章編號:1009-3044(2010)16-4424-02

Research and Application of Software Quality Improved Based on Software Requirement

WANG Yan-xing, YE Jing-fa

(College of Computer, Beijing University of Technology, Beijing 100124, China)

Abstract: Software is applied in more and more domain with the quickly development and application of the computer technology. At the same time, scale and complexity of software requirement is increasing day by day. Requirements analysis is a key activity in software life cycle,quality of software requirement can affect quality software directly. It selected an effective approach with the use of objected domain analysis to verification quality of requirement.

Key words: software requirement; domain analysis; qualityproperty

隨著科學技術和社會生產(chǎn)力的不斷發(fā)展,信息技術最快的發(fā)展速度和最強的滲透能力,廣泛應用于社會各個領域。軟件的規(guī)模越來越大,與此相對應軟件的需求也越來越復雜。正如“軟件危機”(software crisis)所闡述的兩方面:如何開發(fā)軟件以滿足不斷增長日趨復雜的需求和如何維護數(shù)量不斷膨脹的軟件產(chǎn)品。截至到目前, 如Brooks所言,解決軟件危機的“Silver Bullet” 還沒有出現(xiàn)[1]。需求分析是軟件研發(fā)的起始階段,高質(zhì)量的需求分析是軟件項目邁向成功的第一步。

1 需求是軟件質(zhì)量的根源

ISO9126的信息技術標準[2]中定義軟件質(zhì)量:與軟件產(chǎn)品滿足明確或隱含需求的能力有關的特征和特征總和,它充分表明軟件系統(tǒng)是滿足用戶需求的實體。在研究中發(fā)現(xiàn)軟件缺陷產(chǎn)生的原因分布在軟件研發(fā)的各個階段,軟件產(chǎn)品說明書(需求)占56 %,設計占了27%,編寫代碼占7%;其他占10%。可見軟件缺陷的最大原因是軟件產(chǎn)品產(chǎn)品說明書和軟件設計。在生命周期中發(fā)現(xiàn)缺陷越早,修正問題的成本越低。軟件質(zhì)量的管理不是IT自身的需求,而是業(yè)務應用的需求[5]。需求階段的問題不解決,相當于在錯誤的方向上不斷浪費人力物力[6]。Jones在報告中聲稱擴展需求對80%的管理信息系統(tǒng)和70%的軍事軟件造成風險[7],需求的質(zhì)量將直接影響軟件質(zhì)量[8]。協(xié)調(diào)統(tǒng)一的高質(zhì)量需求是軟件開發(fā)成功的首要條件,需求質(zhì)量的改進則成為軟件開發(fā)的首要任務。

軟件需求是指用戶對目標軟件系統(tǒng)在功能、行為、性能、設計約束等方面的期望。需求階段包括了需求開發(fā)和需求管理兩個部分。而需求工程是一個不斷反復的需求定義、記錄和演進的過程。軟件需求包括三個不同的層次--業(yè)務需求、用戶需求和功能需求--也包括非功能需求[9]。需求是軟件開發(fā)中最復雜的環(huán)節(jié),現(xiàn)在軟件需求分析中發(fā)現(xiàn)需求具有明顯不完整性、不確定性及變化性等特點。提高需求質(zhì)量在于如何改進和克服需求上述特征因素。

2 領域分析對軟件需求改進

了解顧客的需求是軟件質(zhì)量管理的第一步。無論是領域工程還是應用工程,領域分析都是至關重要的。在應用工程中,軟件開發(fā)的首要任務是在特定的范圍內(nèi),針對一組特定的需求產(chǎn)生一組特定的設計和實現(xiàn)。因此在設計之前,必須正確獲得和理解軟件需求,而正確獲得和理解軟件需求的前提是對應用系統(tǒng)的工作領域有充分的認識和理解。

2.1 領域和領域分析方法

領域是指一組具有相似或相近軟件需求的應用系統(tǒng)所覆蓋的功能、問題、問題解決方案或知識區(qū)域[10]。領域工程則為一組相似或相近系統(tǒng)的應用工程建立基本能力和必備基礎的過程,它覆蓋了建立可復用軟件構件的所有活動[11]。領域工程包括三個主要的階段:領域分析、領域設計、領域實現(xiàn)。

領域分析(Domain Analysis)是Neighous1981 年在他的博士論文“使用部件的軟件構筑”中首次提出的[12],它的含義是指“識別、捕獲和組織特定領域中一類相似系統(tǒng)內(nèi)對象、操作等可復用信息的過程”。領域分析是基于已經(jīng)存在的系統(tǒng)和它們的發(fā)展開發(fā)歷史、基于從領域專家獲得的知識、背景理論、領域中新技術的基礎上,識別、收集、組織以及表示領域中相關信息的過程。領域分析進行識別領域邊界,通過分析領域需求,提取出某領域內(nèi)系統(tǒng)的共性及可變部分從而建立領域模型。

2.2 面向領域方法的需求分析

提高軟件需求質(zhì)量的最有效方法是準確獲取用戶的真實需求(功能和性能)。領域分析方法中涉及到廣泛的涉眾:如最終用戶、領域專家、領域分析員、系統(tǒng)投資人、需求分析員等等。領域專家對行業(yè)信息化有豐富經(jīng)驗。最終用戶則能反應系統(tǒng)應用的典型業(yè)務需求,系統(tǒng)投資人則更多關注領域的發(fā)展和運營。以最終用戶中心,面向領域的需求分析方法有效捕獲從應用專業(yè)領域別是直接從最終用戶的需求,并完整、準確地予以描述與分析。軟件的需求從用戶中來,軟件的使用又到用戶中去。Harwell強調(diào)今天的用戶和開發(fā)者必須協(xié)同工作,以成功完成開發(fā)過程[13]。領域分析中參與涉眾的廣泛性和代表性解決需求的不完整性、使用領域語言對問題闡述保證問題的一致性。對領域問題分析的深度和廣度,防止了需求的頻繁變化和變更。而且即使變化也會在預先可控范圍內(nèi)的調(diào)整和擴展,減少對領域模型的沖擊。領域分析立足于滿足現(xiàn)有業(yè)務的需求同時它還代表系統(tǒng)的一種發(fā)展方向和系統(tǒng)對未來業(yè)務發(fā)展的適應能力。保證應用工程需求的穩(wěn)定性和系統(tǒng)性。通過分析領域需求的共性和可變性有利軟件產(chǎn)品線形成和演化。

領域工程是建立系統(tǒng)家族及支持系統(tǒng)演化的基礎和前提。面向領域的需求分析從需求問題的分布可以將領域為縱向(垂直)領域和橫向(水平)領域,其中垂直領域是指具有相似業(yè)務需求的一組相似應用系統(tǒng)所覆蓋的業(yè)務區(qū)域。水平領域是指根據(jù)應用系統(tǒng)內(nèi)部模塊的功能性分類而得到的相似問題空間。領域分析方法從問題域出發(fā)將問題逐步深入逐步求精,通過橫向拓展和縱向拓展對需求進行挖掘。借鑒和學習國內(nèi)外同行業(yè)和相近行業(yè)的經(jīng)驗,并在此的基礎上不斷提出創(chuàng)新方向引導需求和發(fā)展需求。領域分析在一定程度上預測未來需求的發(fā)展趨勢,使軟件的需求能方便、快速適應市場的變化。

軟件的功能需求滿足了業(yè)務需求和用戶需求,而非功能需求則是軟件質(zhì)量的內(nèi)在體現(xiàn)。非功能需求是保證業(yè)務流程正常運轉的前提和保障。是衡量軟件能否良好運行的定性指標。質(zhì)量屬性是軟件質(zhì)量的綜合體現(xiàn)。質(zhì)量屬性是客戶希望的特征,屬性并不是單獨存在的,而是一個或多個功能的附屬特征。軟件的整體質(zhì)量是各種質(zhì)量屬性之間的權衡和優(yōu)化。為了達到產(chǎn)品特性的最佳平衡,在需求獲取階段識別和確定相關的質(zhì)量屬性,領域涉眾需要確定質(zhì)量屬性之間的優(yōu)先級,已達到系統(tǒng)整體質(zhì)量的合理優(yōu)化。

3 領域分析方法的應用案例分析

隨著經(jīng)濟全球化和新技術革命發(fā)展,數(shù)字化、融合化、全球化發(fā)展和媒介競爭是世界文化傳媒業(yè)的發(fā)展大勢。廣電傳媒業(yè)要打造核心競爭力,實現(xiàn)可持續(xù)發(fā)展,就必須通過體制改革,強化管理,整合企業(yè)流程,創(chuàng)新服務模式。數(shù)字電視業(yè)務的逐步深入,原來的業(yè)務系統(tǒng)正成為制約廣播電視發(fā)展的瓶頸,主要表現(xiàn)為以下幾個方面:廣播電視各業(yè)務系統(tǒng)各自獨立運行,數(shù)據(jù)和業(yè)務管理分散。無法實現(xiàn)客戶資料的統(tǒng)一管理,無法實現(xiàn)業(yè)務統(tǒng)一規(guī)劃運營。無法從業(yè)務數(shù)據(jù)中挖掘有價值的信息,更不能為企業(yè)管理層提供決策支持,企業(yè)很難推出快速響應市場的高效運營方案。因此廣電需要一個功能完善的、面向未來的綜合業(yè)務運營支撐系統(tǒng)(BOSS系統(tǒng))來整合替代原來各個分散的系統(tǒng)。對廣電領域的分析成為建設多業(yè)務綜合運營支撐系統(tǒng)的首要問題。應用面向領域分析方法對廣電行業(yè)進行需求探索和研究,提出了廣電綜合業(yè)務支撐系統(tǒng)的業(yè)務模型如圖1。

領域分析方法為業(yè)務模型建立提供有效的思路。領域縱向分析中充分參考了電信行業(yè),電信行業(yè)與廣電行業(yè)有很多相似之處而且有很多成熟的運營經(jīng)驗,也充分借鑒了國際電信管理論壇(Tele Management Forum)。領域橫向分析全面整合廣電企業(yè)目前的系統(tǒng),建立“以客戶為中心”的模擬、數(shù)字、增值多業(yè)務廣電運營支撐平臺。以多種接入方式滿足現(xiàn)有業(yè)務、未來數(shù)字整體轉換和增值業(yè)務的需求。以客戶為中心為客戶提供個性化、社會化、信息化的產(chǎn)品營銷模式。調(diào)整企業(yè)內(nèi)部組織結構和整合企業(yè)內(nèi)部資源,同時加強企業(yè)產(chǎn)品提供商的合作產(chǎn)業(yè)鏈。在新的業(yè)務平臺和市場競爭中尋求企業(yè)運營的商業(yè)模式。隨著運營商區(qū)域并購聯(lián)盟、廣電業(yè)務和用戶規(guī)模將劇增,業(yè)務系統(tǒng)數(shù)據(jù)量將更加龐大,為能滿足不斷發(fā)展的用戶需求和提高服務質(zhì)量。系統(tǒng)運行的安全可靠性和事務的高性能處理成為系統(tǒng)整體質(zhì)量的體現(xiàn)。

通過領域分析方法提出的模型滿足運營商的組織結構管理、業(yè)務需求和業(yè)務管理模式,完成企業(yè)信息化建設實現(xiàn)資源和信息的共享。實現(xiàn)業(yè)務規(guī)范、責權明確、各部門間的協(xié)同的管理?；诖诵枨蠓治龅南到y(tǒng)能全面降低企業(yè)運作成本,提高公司的整體運作效率,大幅拓展業(yè)務,進一步提高企業(yè)的核心競爭力。

4 總結

軟件需求的質(zhì)量將直接影響軟件產(chǎn)品的質(zhì)量,改善需求的質(zhì)量是非常必要和有效的環(huán)節(jié)。本分探討了領域分析方法對軟件需求的改進,并在廣電業(yè)務支撐系統(tǒng)需求分析中進行了應用和探索。

參考文獻:

[1] BROOKS F P.THE MYTHICAL MAN-MONTH[M].北京:清華大學出版社,2002:42-43.

[2] International Organization for Standardization.International Electro-technical Commission ISO/IEC9126:Information Technology--Software Product Evaluation:Quality Characteristicd and Guidelines for Their Use[S].Chicago:Thomson,1991.

[3] Little wood B.Software Reliability Achievement and Assessment[M].Henley-on-Thames,England:Alfred Waller,Ltd,1987.

[4] Mizuno O,Kikuno T,Inagaki K,et al.Analyzing effects of cost estimation accuracy on quality and productivity[C]//Proceedings of the 1998 20th International Conference on Software Engineering.Kyoto,Japan:IEEE Comp Soc,1998:410-419.

[5] 張郁.軟件質(zhì)量源自應用需求[N].每周電腦報,2005-11-21:90.

[6] 杰拉爾德?溫伯格.探索需求-設計前的質(zhì)量[M].章柏幸,王媛媛,謝攀,譯.北京:清華大學出版社,2004:175-176.

[7] Jones C.Estimating Software Costs[M].Boston:Addison-Wesley,2000.

[8] BERKI E,GEORGIADOU E,HOLCOMBE M.Requirements Engineering and Process Modeling in Software Quality Management―Towards a Generic Process Metamodel[J].Software Quality Journal,2004(12):265-283.

[9] 陸麗娜.軟件需求[M].北京:機械工業(yè)出版社,2002:35-39.

[10] Tracz W.Domain-specific software architecture (DSSA) frequently asked questions (FAQ)[J].Software Engineering Notes,1994,19(2):52-56.

[11] Tracz W.Confessions of a UsedProgram Salesman Institutionalizing Software Reuse[M].New York:Addison Wesley Publishing Co.,1995.